Par Sylvain Bernard, Consultant senior CG2 Conseil
En tant que DSI, de multiples voix vous ont sans doute déjà incité à mettre en œuvre DevOps. Mais elles invoquent des motivations hétérogènes : fluidifier le fonctionnement entre équipes Dev et Ops comme son nom l’exprime, étendre l’agilité à toute la DSI comme les Dev ou les métiers l’y enjoignent, réduire le Time to Market comme l’entreprise le réclame, automatiser tous azimuts comme les profils techniques le mettent en avant.
Déroutant, non ? Cet article ne va pas vous proposer ici une définition ultime de DevOps, d’autant plus qu’elle n’existe pas. Il s’agit avant de vous mettre en garde contre une erreur aussi fréquente que sévère : envisager DevOps comme une approche essentiellement fondée sur les technologies et l’automatisation. « Je monte une usine DevOps et hop, l’affaire est dans le sac, ma DSI est DevOps ? » Eh bien non.
Les origines possibles de la confusion
Lors de salons, de Customer Days, les conversations autour de DevOps peuvent s’avérer perturbantes. Vous entendez « DevOps, mon cher, c’est d’abord une question de culture ! ». Mais pourquoi, la plupart du temps, les conversations autour de DevOps dérivent souvent et rapidement pour ne plus parler que de technique ? Docker, Ansible, Kubernetes, Jenkins, Azure DevOps, Terraform, Grafana, CircleCI… finissent sur toutes les lèvres.
Il faut bien admettre que DevOps s’illustre de façon spectaculaire avec la mise en œuvre des plateformes techniques de CI/CD (Continuous Intergration / Continuous Delivery). Bien construites, bien exploitées, ces machineries sophistiquées de pipelines fonctionnent de façon impressionnante. Un développeur crée du code, en fait le commit et quelques minutes plus tard, le composant correspondant est en production, après avoir franchi tous les tests nécessaires, automatiquement. Vous percevez aisément l’effet sur le Time to Market : passer à des projets dont la durée pourrait avoir fondu de 2 ans à quelques mois, dont les livraisons pourraient ne nécessiter que 1 à 2 heures et non plus des nuits ou des week-ends entiers.
Le plus satisfaisant, c’est qu’il n’est plus nécessaire de chercher bien loin aujourd’hui pour trouver ces dispositifs CI/CD. Il suffit d’aller faire son marché chez les hébergeurs et les infogérants. Chez les plus grands hébergeurs (Amazon, Microsoft et Google, typiquement), comme chez de plus petits infogérants, les offres CI/CD font désormais partie des portefeuilles de services. Les offres, qui se financent de plus en plus d’autour d’Unités d’Œuvre, ont déjà atteint un niveau de maturité industrielle intéressant.
Alors, faites ce test : demandez à un infogérant s’il peut vous proposer une plateforme de CI/CD clés en mains. Il y a fort à parier qu’il vous répondra : « Oui, j’ai une offre DevOps ».[1] Voilà, c’est clair. Le marché de l’infogérance lui-même entretient l’idée que la machinerie CI/CD et DevOps, c’est la même chose.
[1] A titre personnel, j’en suis à 100% de réussite.
Les risques d’une approche classique trop « techno »
Redisons-le : les technos CI/CD sont sophistiquées. En pareille situation, le réflexe managérial classique est souvent le suivant : ajouter à l’organigramme de la DSI une nouvelle équipe et la former jusqu’à obtention de l’expertise requise. L’autre possibilité consiste à sous-traiter. Le point commun est la constitution d’une nouvelle structure, bien délimitée, extérieure aux DEV et aux OPS. Sa mission : opérer la machinerie CI/CD, trop complexe pour les DEV, trop complexe pour les OPS, utile aux deux.
Et c’est là qu’est le danger : la mise en place définitive d’une équipe – mal – nommée DevOps. Car voici le modèle de fonctionnement ainsi institutionnalisé au sein de la DSI :
à
En d’autres termes, entre DEV et OPS s’insère une troisième entité, la fameuse « Usine DevOps », qui possède seule la compétence et l’outillage techniques. Quant à eux, les DEV et les OPS ont été exemptés de transformation. Et c’est ainsi que quelques funestes scénarios se dessinent, notamment :
- L’Usine DevOps se limite précisément à sa fonction d’usine : elle n’est pas en contact avec les besoins métiers, elle en a davantage éloigné les Ops. Son impact sur la flexibilité du SI demeurera modeste.
- L’Usine DevOps impressionne par sa réactivité et sa modernité, se voit confier les projets où vitesse et innovation sont clés (Digital, vous avez dit Digital ?). Pendant ce temps, les Dev et les Ops, intacts, restent cantonnées au legacy.
Faisons le bilan. A court terme, l’automatisation CI/CD améliore certainement le Time To Market. A moyen terme, la rigidification, le cloisonnement supplémentaire de la DSI font peser une lourde menace sur sa capacité d’adaptation. Oui, cette approche-là aura fait régresser l’agilité de la DSI ! Dans ces conditions, pendant combien de temps les gains sur le Time To Market peuvent-ils subsister ?
Dans les DevOps Days auxquels j’ai participé en 2019, les témoignages étaient assez unanimes : la mise en œuvre d’une telle équipe DevOps était perçue au mieux comme un mal nécessaire, au pire comme une erreur à ne pas reproduire. Dans tous les cas, la perspective était bien de la faire disparaître.
Les risques d’une approche classique trop « orga »
Nous venons de la voir, une approche trop « techno » conduit à réduire la transformation DevOps à la constitution d’un pôle d’expertise technologique autour du CI/CD et, pis, de les dénommer « usines devops ». Le résultat à terme s’oppose aux objectifs initiaux : éloignement des Dev et des Ops au lieu de les rapprocher, rigidification au lieu d’agilisation…
Une autre démarche peut alors être entreprise, sur un précepte également classique : « la techno n’est qu’un outil, qui doit s’aligner sur l’organisation. Travaillons l’orga, nous verrons les outils ensuite ». Pour avoir tenu ce discours pendant 20 ans et le tenir encore, j’aurais du mal à le taxer d’erreur absolue.
Mais de nouveau, une mise en pratique trop mécanique peut nous conduire à passer à côté d’une évolution profonde. Depuis 10-15 ans environ, nous redécouvrons que la techno peut créer le besoin, bouleverser les organisations les plus établies. Adapter l’organisation sur un fondement techno, n’est plus si inapproprié. (Après tout, quand les ingénieurs IT ont inventé la virtualisation sur x86, je doute qu’ils l’aient fait sur un cahier des charges annonçant le Cloud Computing… et imagineriez-vous votre Production hier, vos Ops aujourd’hui, être organisés, processés de la même manière, avec ou sans Cloud ?)
Ce qui achève de vraiment changer la donne, c’est que le rythme de l’innovation technologique est devenu affolant. Dès lors, est-il si judicieux de penser de nouvelles organisations parfaites pendant des semestres puis de bétonner le choix et la mise en œuvre des outils les plus adaptés, quand en parallèle de nouveaux outils porteurs de nouveaux principes ne manqueront pas d’apparaître ?
DevOps, c’est vraiment une question de culture
C’est maintenant qu’il faut rappeler qu’un des piliers conceptuels de DevOps, c’est le Lean. Face à la fausse opposition entre techno et orga, la culture Lean de DevOps apporte sa réponse : appréhender toute nouvelle techno en tant que gisement de Valeur (davantage de richesse fonctionnelle du SI, de plasticité face aux nouveaux besoins, de disponibilité voire de sécurité…) Rechercher la Valeur dans la techno, savoir s’emparer rapidement des good techs, savoir se débarrasser rapidement des bad techs. C’est dans son ADN Agile, c’est l’essence du caractère congénital du lien entre la technologie et DevOps.
En corollaire, et je le vois chez nos clients, les démarches DevOps sont souvent impulsées par des acteurs de terrain plus que par une intention top down. Ils peuvent être enclins à mettre sur la table des projets, des actions d’une forte coloration technique. Attention à la tentation de n’y voir que de la précipitation immature d’informaticien technophile ! Soyons honnêtes, c’est peut-être le cas. Mais pourquoi n’auriez-vous pas aussi la chance d’avoir des collaborateurs matures, avides de bons filons de Valeur facile et rapide à extraire ?
Ainsi, DevOps ne vise pas simplement à rapprocher les Dev et les Ops, comme fin en soi. DevOps entraîne ces équipes à se fédérer autour de la Valeur produite par le SI. DevOps élève cette notion de Valeur SI en principe structurant.
Concernant la Valeur à espérer, un fonctionnement cloisonné entre Dev et Ops est restrictif. Un modèle RH où la formation reste perçue comme un coût et non comme un efficace moyen de valoriser de la good tech, est restrictif…
La liste des entraves levées par DevOps est longue. Il en est une qu’il me reste à souligner : le modèle où la Valeur se pense au sommet de la hiérarchie est restrictif. Au-delà de cette formule caricaturale, il est une certitude : vous-même, en tant que DSI, serez sponsor, acteur et sujet de la transformation DevOps. Même si ça doit commencer par la mise en œuvre d’un CI/CD.
