PAROLE D’EXPERT : DevOps, c’est l’alpha et l’oméga ? …Quelques points de vigilance

C’est décidé, vous allez engager ou accélérer votre DSI sur la voie de DevOps. Vous avez raison, de beaux succès seront au rendez-vous. Sur quoi porteront les résultats les plus tangibles ? Time to Market, agilité, fiabilité, sécurité. Où se manifesteront les évolutions les plus intenses ? Un fonctionnement transversal et apaisé, fédéré autour d’une culture du Lean et de la Valeur.

Si l’adoption de DevOps peut être envisagée en douceur, votre DSI finira par être transformée très en profondeur. Son degré de transversalité est élevé… mais pas maximal : DevOps a aussi des limites à bien appréhender !

Ce qui est gênant avec DevOps, c’est son côté protéiforme. Il est officiel qu’il n’en existe pas de définition officielle. Ici, par principe, je resterai sur une interprétation au pied de la lettre : le rapprochement des équipes Dev et des équipes Ops. Voici mes hypothèses :

• Le rapprochement est fédéré autour d’une obsession centrale, celle de la Valeur générée par le SI. Comment, en tant que Dev, puis-je optimiser la valeur transverse de toute la DSI (et pas simplement de mes activités de développement) ? Comment, en tant qu’Ops, puis-je optimiser la valeur de toute la DSI (et pas simplement de mes activités « infra ») ?
• De façon liée, DevOps est d’abord une question de culture, celle du Lean, de l’agilité, avec la conviction que la Valeur se crée dans le partage.
• DevOps s’appuie sur une intimité très forte entre organisation et technologies. Ceci ne signifie pas que DevOps se limite à la mise en œuvre de CI/CD ou d’automatisation intense[1].

[1] Voir cette autre Parole d’expert : « Comment singer sa transformation DevOps ? »

Malgré ce qui précède, admettons temporairement que DevOps se limite à la mise en œuvre d’un pipeline CI/CD. Faisons semblant d’oublier que la vraie motivation du CI/CD, c’est de réconcilier Dev et Ops sur la question de l’agilité et de l’innovation : assurer aux Dev que les fonctionnalités qu’ils ont créées vont effectivement arriver en production (ça a de la Valeur), garantir que ces mises en production préservent la disponibilité, la sécurité du SI (ça a de la Valeur), grâce à un testing garanti.

Admettons, et tirons ensemble la pelote de ce qu’implique vraiment le seul déploiement d’un pipeline CI/CD. Au minimum, il s’agit de demander :

• aux différentes équipes DEV : adopter des modes de fonctionnement et des outillages suffisamment convergés pour rentrer dans un même pipeline CI/CD, déléguer aux OPS la maintenance de leurs plateformes de développement (y compris les outils de développement).
• aux OPS : accepter ce rôle de fournisseur de solutions aux DEV, avec toute la capacité d’écoute du besoin nécessaire, accueillir l’irruption du tempo de l’Agilité dans leur mode de fonctionnement, revendiquer plus encore leur place très amont des projets pour garantir l’efficacité de la chaîne technique et anticiper ses éventuelles évolutions.

Nous ne sommes pas vraiment dans la simple installation d’objets techniques, n’est-ce pas ?

Alors, généralisons. Les points précédents vous auront permis de pressentir les principaux axes d’une véritable transformation DevOps.

• Transformation culturelle et humaine: imbiber vos collaborateurs de cette idée que les acteurs de la DSI, Dev et Ops, sont tous investis d’une légitimité forte dans la Valorisation du SI. Et donc que l’écoute, le partage entre eux est indispensable. Les clés sont ici l’accompagnement au changement poussé jusqu’au coaching.
• Organisation, management opérationnel: dès lors que la conviction précédente est devenue intime à chacun, l’organisation de votre DSI va inéluctablement évoluer, puisque Dev et Ops auront besoin de solutions pour accroître leur collaboration. Les initiatives viendront du terrain. Il appartiendra à toute la chaîne managériale, jusqu’à vous, d’accueillir, catalyser et encourager même un tel fonctionnement bottom up, plutôt que de chercher à le juguler.
  Avant cela, les fonctions induites par l’agilité des Devs (Product Owner, Scrum Master par exemple) auront l’intérêt, le devoir même, d’étendre leur champ d’action aux activités Ops.
• Rapport aux technologies et aux pratiques de formation: DevOps aborde les technologies innovantes comme autant de gisements de valeur. La formation aux nouvelles technologies devient un moyen efficace vis-à-vis la création de Valeur et à la réduction du Time To Market : vaut-il mieux passer 2 à 3 jours en formation pour comprendre à coup sûr, ou 1 mois à tâtonner ? La DSI a ici besoin, en bonne intelligence avec la DRH, de s’extraire du cadre standard de l’entreprise et de dépenser au-delà du budget institutionnel de formation. Comment déclencher à l’instant T une formation pertinente, si le budget et le programme de formation ont été arrêtés à l’année N-1 ?
• Pilotage stratégique et financier: comment piloter son portefeuille de projets, comment décider de lancer ou d’arrêter un projet, comment arbitrer ses budgets de fonctionnement et d’investissement, quand la notion même de projet est sérieusement ébranlée ? Il s’agit en effet de passer d’une gestion de projets à un management de produits. Il ne s’agit plus de piloter une dépense mais un scoring de valeur au fil du temps.

La liste ci-dessus est susceptible d’évoquer lourdeur, complexité. L’objectif n’est pourtant pas de vous dissuader, mais de vous permettre de mesurer la réalité de l’ambition.

En prérequis, il est donc indispensable de savoir si le jeu en vaut la chandelle. Vos métiers sont-ils prêts à une transformation continue de leurs solutions logicielles ? En sont-ils demandeurs ? Ça n’est pas vrai pour toutes les entreprises. Ça n’est pas vrai pour tous les métiers. Je garde encore un souvenir un peu douloureux d’une mission d’accompagnement DevOps où, au bout de quelques semaines, il nous aura été enfin possible de rencontrer le métier, pour entendre que « l’Agilité, on n’en a pas grand-chose à f…e ».

C’est pourquoi votre cible sera vraisemblablement un barycentre entre le « tout agile » et le « on ne change rien ». Ainsi, pour bien servir votre entreprise, votre DSI aura certainement nécessité à conserver sa capacité à adresser les métiers qui ne trouvent pas de Valeur dans l’Agilité (Oui, c’est possible !).

D’ailleurs, il faut être lucide : vous aurez des collaborateurs pour qui le choc culturel pourrait être trop grand et qui dans lequel ils ne se reconnaîtront jamais. Il sera cohérent avec DevOps non pas de leur imposer un moule mais de leur trouver une position, une fonction où ils resteront en capacité de créer de la Valeur. Pourquoi pas vis-à-vis des métiers qui n’ont pas besoin d’agilité ?

Il en résulte une DSI dite « duale », prévue par DevOps.

Résumons les caractéristiques d’une transformation DevOps : elle porte sur un large spectre, elle est profonde, elle n’a pas besoin d’être jusqu’au-boutiste. En conséquence, l’approche « Big Bang » n’est ni requise, ni même souhaitable.

Pour réussir une telle transformation, les méthodes Agiles fournissent d’ailleurs un état d’esprit simple et puissant : plutôt que de nous faire peur en essayant d’atteindre un objectif lointain et complexe, avançons vers lui petits pas par petits pas, itérativement. Le rythme de ces petits pas doit s’accorder sur un rythme de transformation soutenable par tous : la DSI, les métiers, l’entreprise.

Dès lors, pourquoi pas définir des sprints de transformation DevOps ? Assigner à chacun d’entre nous une marche de progrès sur la transformation culturelle et humaine, l’organisation et le management opérationnel, la sélection et le déploiement de nouvelles technologies, de nouvelles pratiques de pilotage stratégique et financier ? En corollaire, de cette façon, le mode Dual se met en place by design.

Par un investissement cohérent, progressif en moyens, en hommes… et votre implication personnelle, garante de l’évolution culturelle et de l’accroissement de transversalité, vous aurez tiré un maximum du potentiel de DevOps. Ne pourriez-vous pas même vous convaincre d’avoir atteint un modèle ultime de transformation, l’alpha et l’oméga du fonctionnement opérationnel d’une DSI contemporaine performante ? Hélas, quelques précautions s’imposent maintenant.

Notons tout d’abord que, pour DevOps, les OPS, ce sont les équipes d’Infrastructure Management. DevOps laisse une activité classique d’une DSI sur le bord du chemin : les End User Services. Effet d’une trop grande ambition : des applications en telle adéquation continue avec le besoin utilisateur et si bien écrites, que le support à l’utilisateur serait devenu superflu ? Gros oubli ? Effet de caste sur cette activité qui reste encore en 2021 souvent perçue comme peu porteuse de Valeur ? Pas très dans l’esprit DevOps, tout ça, non ? Quoiqu’il en soit, DevOps n’entraîne donc pas une transversalité opérationnelle absolue.

Plus sévère : DevOps reste, à mon sens, imprégné de l’illusion que lorsqu’un DEV produit du code, il crée de la Valeur. Or, son code, son application n’ont de Valeur que lorsque des métiers en font un usage effectif. Pourtant, DevOps ne dit rien sur l’appropriation par les utilisateurs, leur accompagnement.

À la limite, il faudrait pouvoir évaluer dans quelle mesure l’usage d’un code, d’un composant IT, d’un service IT contribue clairement à ce à quoi l’entreprise accorde de la Valeur : le chiffre d’affaires, tel ou tel objectif stratégique… C’est une tarte à la crème : c’est encore le métier qui décide de ce qui a de la Valeur, pas l’IT.

(DevOps, par son obsession de la métrologie, propose déjà des plateformes et des réflexes opérationnels intéressants.)

Je vous le disais en introduction : si vous empruntez le chemin de DevOps, ma conviction profonde est que vous avez bien raison. Tout l’objet de cet article est de vous aider à toucher du doigt votre destination : bien plus qu’une automatisation à tout crin, pas tant qu’une solution ultime de fonctionnement, mais bien une DSI apaisée, fluide et au fonctionnement créateur de Valeur.

Mais si le principal risque était en réalité que le chemin ne devienne une vaste autoroute aux embranchements multiples ? Je m’explique. Il est d’ores et déjà remarquable que DevOps :

• s’étend. Le succès de la culture et des démarches collaboratives ont donné l’idée d’y incorporer la sécurité. Ainsi est né DevSecOps. L’association est devenue si naturelle que DevOps et DevSecOps sont pratiquement synonymes aujourd’hui.
• fait l’objet de passerelles : avec ITIL dans sa très attendue version 4, avec l’agilité à l’échelle SAFe, avec l’UX Design…
• est à l’origine de la tendance phonétique de la rime en OPS : FinOps, SysOps…

Ici, une petite phrase commence à me trotter dans la tête : « toujours plus de la même chose[1] ». Faut-il déjà prêter vigilance à ce que DevOps, approche fondamentalement Lean, ne se perde dans un capharnaüm étouffant sous sa masse ? Ce serait un comble !

C’est une spéculation. Nous n’y sommes pas encore. Restons vigilants.

[1] Formule récurrente du fameux livre de Paul Watzlawick, Comment réussir à échouer, 1988