Management

Agilité et DevOps : pour que l'IT n'arrive pas après la bataille

« La transformation digitale sonne-t-elle le glas pour les équipes de production ? » se sont interrogés les participants au débat du CPI-B2B du 7 juin 2017.

Le 7 juin 2017, le CPI-B2B (Club de la Presse Informatique B2B) a débattu de l'émergence du modèle DevOps en lien avec la révolution digitale.

PublicitéLe séquençage traditionnel des tâches informatiques, avec développement, test, réception, déploiement et production, aboutit à des lenteurs et des lourdeurs, même en mode agile, avec des boucles de rétro-actions sur des cycles courts. Or le but premier de l'agilité, c'est de faire en sorte que l'informatique suive les besoins métiers, sans arriver après la bataille, plusieurs mois ou années après la commande.
Il faut donc aller au delà de l'agilité dans le développement et les tests pour l'étendre à tout le cycle de vie logiciel. Et, même, l'objectif est qu'il n'y ait plus séquençage mais simultanéité. C'est la philosophie du DevOps. Le CPI-B2B (Club de la Presse Informatique B2B) a débattu de l'émergence du modèle DevOps en lien avec la révolution digitale le 7 juin 2017.

Une rupture dans le mode de pensée

Le modèle du DevOps, qui, par nature, permet des cycles courts et de jauger rapidement de la pertinence d'une évolution, est de plus en plus adopté pour une raison simple. « Toutes les entreprises sont devenues des fournisseurs IT : il y a toujours, même en lien avec un produit industriel, une part de service donc de logiciel pour sous-tendre ce service » a observé Jean-Paul Alibert, directeur général chez T-Systems France. Or, si le logiciel ne répond pas aux attentes, il en sera de même du service donc de l'offre globale de l'entreprise. Le risque est donc de perdre des clients.
Or cette logique du DevOps se heurte aux schémas traditionnels d'organisation de la DSI. Ceux-ci reposent sur un duopole : d'un côté le développement/intégration, de l'autre les opérations/production. « Il y a une opposition naturelle entre les deux puisque, côté opérations, on veut de la stabilité tandis que, côté développement, on veut du mouvement et de l'évolution pour suivre les besoins métiers » a souligné Mokrane Lamari, directeur avant-vente France chez Equinix. Jean-Paul Alibert, directeur général chez T-Systems France, a renchéri : « et il ne faut pas oublier entre les deux une fonction essentielle, les tests, qu'on ne sait jamais où mettre... Et il existe aussi une seconde opposition entre les responsables du Legacy, avec ses mises en production une à deux fois par an, et ceux du Digital, avec plusieurs mises-à-jour par jour voire par heure. »

Les Anciens contre les Modernes

« Ces concepts sont obsolètes » a tranché Guillaume Leccese, directeur technique chez Oxalide. Les entreprises issues d'Internet (Google, Amazon, Facebook...) ont, selon lui, créé une nouvelle culture qui se diffuse dans les entreprises aujourd'hui, notamment les prestataires IT. Cette culture est justement celle du DevOps, où toutes ces oppositions n'existent plus. Franck Lecaillon, directeur technique d'Econocom, a tempéré : « toutes les sociétés ne sont pas prêtes à une telle réorganisation, que ce soit avec les équipes internes ou dans le travail avec les SSII ! » Les jeunes sociétés, à l'inverse -comme Pure Storage représentée par Gabriel Ferreira-, sont elles nativement organisées avec cette culture où « les développeurs testent en temps réel leurs travaux ».
Ce qui change entre les Anciens et les Modernes, c'est, en fait, ce que les Anglo-Américains appellent le « continuous ». Il s'agit de casser la séquentialité des tâches pour la remplacer par une « continuité » où l'automatisation est maximale. « Le but est de développer et d'intégrer pour aussitôt tester, le tout de manière automatisée » a expliqué Joël Depernet, executive vice-president R&D chez Axway. Lorsque l'automatisation s'arrête là, c'est de la continuous integration. Quand le déploiement sur l'infrastructure et le monitoring sont également intégrés, ajoutant donc le continuous deployment à la continuous integration, on arrive au DevOps. « Mais cela suppose que le métier ne demande pas une navette spatiale quand son besoin est une trottinette » a relevé Guillaume Leccese, directeur technique chez Oxalide.

PublicitéUn défi pour la GRH

Changer à ce point les modes de fonctionnement implique de grands bouleversements dans l'organisation de la DSI mais aussi dans les compétences nécessaires des ressources humaines employées. « Le vrai défi à relever est de changer la culture des collaborateurs » a ainsi jugé Franck Lecaillon, directeur technique d'Econocom. Côté organisation, les tâches sont parcellisées pour les rendre rapides et faciles à gérer. « C'est la logique Pizza Team [Toute équipe doit être d'une taille maximale pour pouvoir se nourrir avec une seule pizza, NDLR], c'est à dire que l'on opte pour une grande quantité de petits projets au lieu d'un seul grand » a rappelé Jean-Paul Alibert, directeur général chez T-Systems France.
Pour aller plus vite, beaucoup d'entreprises ont opté pour l'externalisation des infrastructures, avec les équipes associées confiées au prestataire. Du coup, c'est le prestataire qui a les problèmes. Gagner en vitesse passe ainsi par une logique d'achat sur étagère au lieu d'une fabrication sur mesure. Mais Jean-Paul Alibert a relevé : « aller plus vite suppose aussi de faire en interne un maximum de choses, ce qui implique d'opter pour DevOps afin d'atteindre les objectifs assignés. » La France est plutôt moins avancée dans cette logique du « Buy » au lieu du « Make » que d'autres pays mais le mouvement est le même partout.

Requalifier les collaborateurs

Aux Etats-Unis, la promotion du DevOps repose sur le nombre de postes que l'on peut économiser. En France, cette logique anti-emploi n'a évidemment pas la même popularité. L'une des possibilités est donc de faire évoluer les développeurs afin qu'ils soient capables de tester et de déployer puis de faire la mise en production et même les opérations (ou la gestion des opérations sur IaaS). Quant aux spécialistes de la production, leurs postes ne disparaissent pas. Comme l'ont rappelé Gabriel Ferreira et Guillaume Leccese, ils passent simplement de l'entreprise au prestataire, ce dernier ayant du mal à recruter toutes les compétences dont il a besoin.
Si la requalification des personnels peut être compliquée, une autre option existe : regrouper développeurs, testeurs et responsables de la production en petites équipes multidisciplinaires. Et où chacun pourra apprendre de la culture des autres. « La rapidité, c'est bien, mais elle ne doit jamais être choisie au détriment de la sécurité et de la performance » a relevé Gabriel Ferreira, directeur technique chez Pure Storage France. Cela suppose de ne pas se priver de compétences au nom de l'agilité. Le grand drame des entreprises, utilisatrices comme fournisseurs de technologies, c'est que les personnels bien formés à DevOps s'arrachent car ils sont peu nombreux. Une approche peut donc être de former des gens à la tête bien faite et jeunes, en sortie des écoles.

Les métiers s'impliquent au travers d'un ambassadeur plus que d'un directeur

Il reste qu'intégrer les métiers dans la démarche agile itérative peut paraître une bonne idée pour bien répondre à leurs besoins. Mais encore faut-il que les métiers jouent le jeu et ne se réfugient pas derrière un « je n'ai pas le temps ». « Pour éviter cela, l'idée est de recourir au Product Owner qui est un ambassadeur du métier concerné : ce n'est certainement pas le DAF qui va participer aux réunions DevOps » a convenu Guillaume Leccese. Selon les types d'entreprises et de projets, le Product Owner est un poste spécifique à temps plein ou bien une fonction avec des tâches identifiées qui fait partie d'une fiche d'un poste plus vaste.
Jean-Paul Alibert a renchéri : « les projets d'un bloc de plusieurs dizaines de millions d'euros n'existent plus. Les projets sont plus petits et donc plus faciles à faire valider par les métiers. » Le Product Owner, pour lui, n'est pas une révolution : le Key User, dont il est une évolution, a toujours existé.