Les trois voies du DevOps

Gene Kim publie en 2012 chez IT Revolution un billet intitulé The Three Ways: The Principles Underpinning DevOps, et c’est là que les trois principes reçoivent un nom, à un moment où le mot DevOps circulait depuis trois ans sans que personne ait pris la peine de dire de quels principes il découlait exactement.

L’année suivante, il les met en scène dans The Phoenix Project, ce qui explique une bonne part de leur diffusion, parce qu’un roman où l’on reconnaît sa propre entreprise circule infiniment mieux qu’un cadre méthodologique en douze chapitres ; The DevOps Handbook les systématise ensuite et les relie aux pratiques concrètes.

Rien de tout cela ne tombe du ciel, puisque les trois voies appliquent au logiciel ce que le Lean manufacturing et la théorie des contraintes avaient déjà établi en atelier, à savoir qu’un système ne va jamais plus vite que son goulot et que l’occupation de chaque poste ne dit rigoureusement rien de ce qui sort au bout de la chaîne.

La Première Voie s'appelle Flow, parfois « Flow / Systems Thinking », et c'est là que les choses deviennent tout de suite irritantes pour les organisations qui adorent mesurer ce qui se voit, parce que l'objet n'est pas de rendre une équipe performante, mais le système performant. On comprend vite la scène, même sans roman : tout le monde court, tout le monde est occupé, tout le monde a un dashboard, et pourtant rien n'arrive en production sans douleur, parce que l'occupation n'est pas le flux, et que la « vitesse » locale est souvent le nom pudique de la création de stock, de files d'attente, de tickets, de handoffs, de « je te ping quand c'est prêt », bref, de l'inertie déguisée en process.

Dans The Phoenix Project, cette Première Voie est mise en récit à travers le « value stream » technologique, ce trajet qui commence quand le besoin est identifié, passe par la construction en Dev, puis transite en Ops pour délivrer de la valeur au client sous forme de service. Et ce détail est moins académique qu'il n'en a l'air, parce qu'il force une question violente : « où est le début et où est la fin ? » Si ta chaîne de valeur se termine à « ça marche sur mon poste », tu ne fais pas du Flow, tu fais de l'auto-satisfaction assistée par IDE ; si elle se termine à « déployé », tu ne fais pas du Flow, tu fais du cargo cult de livraison ; le Flow ne s'arrête pas avant que le client ne reçoive réellement la valeur, et c'est précisément pour ça que les problèmes « Ops » sont presque toujours des problèmes « Dev » qui ont voyagé, ou des problèmes « Dev » qui ont été rendus invisibles jusqu'à ce que la production, cette créature rancunière, décide de les matérialiser.

La Première Voie, quand on la prend au sérieux, impose des conséquences qui ressemblent à des règles morales, et c'est là que ça fait mal, parce que « ne jamais passer un défaut connu en aval » n'est pas une maxime décorative, c'est un principe d'hygiène systémique. Le truc, c'est que « défaut connu » est plus large que ce que ton cerveau veut admettre : ce n'est pas seulement un test rouge, c'est aussi une dette technique qu'on repousse « parce qu'on verra plus tard », une config approximative « parce que ça passe », une absence de runbook « parce que les seniors savent », une alerte bruyante « parce que flemme », un déploiement manuel « parce que c'est plus rapide », et chaque fois que tu fais ça, tu écris une lettre d'amour à toi-même dans le futur, sauf qu'elle arrive en prod à 2h du matin, et qu'elle est signée « cordialement, ton toi passé ».

Le Flow, ce n'est donc pas « livrer vite » comme un slogan LinkedIn, c'est réduire le temps de traversée du travail à travers le système en diminuant les tailles de lot, en limitant le WIP, en rendant visibles les goulots, en arrêtant de commencer vingt trucs pour en finir zéro, parce que la fluidité n'est pas une impression, c'est un état du système ; et quand on commence à le voir comme ça, on redécouvre une vérité managériale très peu flatteuse, que Deming résume par une phrase qui devrait être tatouée sur le front de certaines org charts :

La Deuxième Voie s'appelle Feedback, ou « Amplify Feedback Loops », et c'est probablement la plus mal comprise, parce qu'on la confond avec « faire une rétrospective » comme on coche une case, alors qu'ici on parle d'une architecture du retour d'information, un mouvement « de droite à gauche », dont l'objectif est de raccourcir et d'amplifier les boucles pour que les corrections nécessaires puissent être faites continuellement. C'est une idée presque brutale : si tu n'apprends qu'à la fin, tu apprends trop tard ; si tu n'apprends qu'en prod, tu as choisi la forme de pédagogie la plus chère, la plus humiliante, et, curieusement, la plus répandue.

Dans la réalité, la Deuxième Voie n'est pas une injonction à « mettre du monitoring », c'est une exigence d'alignement entre ceux qui produisent un changement et ceux qui en subissent les effets, et même entre ceux qui paient le changement et ceux qui encaissent la facture technique, parce que le feedback, ce n'est pas seulement un graphe, c'est une conversation entre le code et le monde, entre l'intention et le résultat. Les outcomes associés à cette Deuxième Voie incluent explicitement le fait de comprendre et de répondre à tous les clients, internes et externes, de raccourcir et amplifier les boucles, et « d'embarquer la connaissance là où on en a besoin », ce qui est une façon diplomate de dire : arrête de concentrer la compétence dans la tête de trois personnes, puis de faire comme si c'était une stratégie de résilience.

Et comme les systèmes adorent la cruauté, la Deuxième Voie te force aussi à accepter un paradoxe : plus tu veux aller vite, plus tu dois multiplier les points de retour, parce que la vitesse sans feedback n'est pas de la vitesse, c'est de l'élan, et l'élan finit toujours dans le décor. C'est la logique derrière des pratiques qui semblent « ralentir » sur le papier - tests automatisés, intégration continue, déploiements fréquents, canary releases, feature flags, chaos engineering - mais qui, en réalité, transforment le « gros bang trimestriel » en petites unités de changement, chacune observable, mesurable, réversible, ce qui revient à remplacer le théâtre du courage par l'ingénierie du contrôle.

À ce moment-là, on tombe souvent sur un autre livre-fossile qui continue d'avoir raison : Continuous Delivery de Jez Humble et David Farley, où l'idée de « ramener la douleur vers l'avant » revient comme une discipline, avec une formule devenue célèbre :

La Troisième Voie, enfin, c'est la partie que tout le monde applaudit en keynote et que tout le monde trahit en comité de pilotage, parce qu'elle s'appelle « Culture of Continual Experimentation and Learning », et qu'elle suppose une culture réelle, pas un poster « fail fast » collé à côté d'un process disciplinaire. Elle se définit comme la création d'une culture qui favorise deux choses : l'expérimentation continue, la prise de risques et l'apprentissage à partir de l'échec, et la compréhension que la répétition et la pratique sont le prérequis de la maîtrise. Le détail « les deux également » est crucial : d'un côté tu as le droit d'explorer, de l'autre tu as le devoir de t'entraîner, parce que l'expérimentation sans maîtrise est juste de l'improvisation dangereuse, et la maîtrise sans expérimentation finit en musée.

C'est ici que les organisations se racontent des histoires, parce qu'elles confondent « apprendre » avec « faire une formation Kubernetes », alors que la Troisième Voie parle d'un système d'apprentissage intégré au quotidien, où l'on alloue du temps à l'amélioration du travail journalier, où l'on crée des rituels qui récompensent le risque assumé, et où l'on va jusqu'à introduire volontairement des défauts pour augmenter la résilience, ce qui veut dire : on accepte d'avoir des incidents contrôlés pour en éviter des incontrôlés, on préfère des surprises en laboratoire à des surprises en prod, et on arrête de punir les messagers parce qu'ils ont eu l'audace de voir la réalité.

La Troisième Voie, si on la prend au sérieux, exige aussi un concept qu'on retrouve plus tard dans les « Five Ideals » revisités dans The Unicorn Project : la sécurité psychologique, cette condition sans laquelle personne ne signale les problèmes, personne ne propose d'amélioration, et tout le monde ment poliment jusqu'à l'explosion. Et là, on touche un point que les gens « très process » détestent : l'apprentissage organisationnel n'est pas une conséquence automatique du temps qui passe, c'est une propriété émergente d'un environnement où dire la vérité ne déclenche pas une chasse aux sorcières, où un post-mortem n'est pas un tribunal, où « qui a fait ça ? » est remplacé par « pourquoi le système a permis ça ? », et où l'on admet enfin que l'on peut avoir des adultes compétents et néanmoins des incidents, parce que, surprise, « un mauvais système battra une bonne personne à chaque fois ».

Ce que les Three Ways racontent, au fond, c'est une physique du travail : le Flow décrit comment le travail traverse le système, le Feedback décrit comment l'information remonte et corrige la trajectoire, et l'Apprentissage décrit comment le système se transforme avec le temps au lieu de répéter ses erreurs comme un rituel de pénitence. C'est pour ça que c'est plus puissant que n'importe quelle mode d'outillage : tu peux faire du Flow avec un monolithe et des scripts shell si tu sais limiter le WIP, réduire les handoffs et livrer en petites unités ; tu peux avoir Kubernetes et ne faire aucun Flow si tu utilises le cluster comme un paravent à une org dysfonctionnelle ; tu peux acheter une stack d'observabilité hors de prix et n'avoir aucun Feedback si personne ne regarde les signaux ou si l'équipe qui peut agir ne reçoit jamais l'info ; tu peux organiser des « innovation days » et n'avoir aucun Apprentissage si le droit à l'erreur s'arrête à la slide 12.

Et comme on est entre gens polis mais lucides, la vérité c'est que les Three Ways sont aussi un miroir : si ta prod est un champ de ruines, ce n'est pas que « les devs codent mal » ou que « les ops sont lents », c'est que ton Flow est entravé, ton Feedback est étouffé, et ton Apprentissage est remplacé par du blâme, avec parfois une couche de « compliance » pour rendre le tout plus solennel. C'est précisément pour ça que DevOps, dans sa version non-mème, n'est pas un rôle, pas un outil, pas un département, mais une tentative de réduire la friction entre silos, de remettre le système au centre, et d'éviter ce scénario répétitif où l'on confond l'agitation avec la progression, le contrôle avec la sécurité, et la punition avec l'amélioration.