The DevOps Handbook
Chapitre 4 / 14 · 15 min de lecture

La Troisième Voie : apprentissage continu et expérimentation

Instaurer une culture générative et à haute confiance où l'amélioration du travail quotidien, l'expérimentation et la résilience deviennent des réflexes partagés.

Là où la Première Voie organise le flux du travail de gauche à droite et où la Deuxième Voie instaure un retour d'information rapide et constant de droite à gauche, la Troisième Voie s'attache à créer une culture d'apprentissage et d'expérimentation continus. Ce sont les principes qui permettent la création permanente de savoir individuel, lequel se transforme ensuite en savoir d'équipe puis en savoir organisationnel. Ce chapitre referme la première partie du DevOps Handbook en posant la dimension la plus humaine, et sans doute la plus difficile, de la transformation : faire de l'amélioration un réflexe partagé plutôt qu'une corvée occasionnelle.

Dans les usines aux problèmes systémiques de qualité et de sécurité, le travail est généralement défini de façon rigide et imposé d'en haut. À l'usine GM de Fremont, évoquée au chapitre précédent, les ouvriers n'avaient quasiment aucune latitude pour intégrer améliorations et apprentissages dans leur travail quotidien, et leurs suggestions « se heurtaient au mur de brique de l'indifférence ». À l'inverse, les opérations industrielles très performantes exigent et encouragent activement l'apprentissage : au lieu d'un travail figé, le système de travail est dynamique, les opérateurs de ligne menant des expériences dans leur quotidien pour générer de nouvelles améliorations, le tout rendu possible par une standardisation rigoureuse des procédures et une documentation systématique des résultats.

Dans la chaîne de valeur technologique (technology value stream), notre objectif est de bâtir une culture à haute confiance (high-trust culture), où chacun se considère comme un apprenant à vie qui doit prendre des risques dans son travail. En appliquant une approche scientifique à l'amélioration des processus comme au développement produit, nous apprenons de nos succès et de nos échecs, écartant les idées qui ne fonctionnent pas et renforçant celles qui marchent. Mieux : tout apprentissage local est rapidement transformé en amélioration globale, afin que les nouvelles techniques bénéficient à l'organisation entière.

Permettre l'apprentissage organisationnel et une culture de la sécurité

Lorsque nous travaillons au sein d'un système complexe, il est par définition impossible de prédire parfaitement toutes les conséquences de nos actions. C'est ce qui produit des résultats inattendus, voire catastrophiques, dans notre travail quotidien, même lorsque nous prenons toutes les précautions. Quand ces accidents touchent nos clients, nous cherchons à comprendre pourquoi. La cause racine est trop souvent déclarée « erreur humaine », et la réponse managériale la plus courante consiste à « nommer, blâmer et humilier » (name, blame, and shame) la personne fautive, à laisser entendre qu'elle sera punie, puis à empiler procédures et approbations pour empêcher la récidive.

Le Dr Sidney Dekker, qui a codifié plusieurs éléments clés de la culture de sécurité et forgé le terme de « culture juste » (just culture), met en garde : « Les réponses aux incidents et accidents perçues comme injustes peuvent entraver les enquêtes de sécurité, semer la peur plutôt que la vigilance chez ceux qui font un travail critique, rendre les organisations plus bureaucratiques que prudentes, et cultiver le secret professionnel, l'évitement et l'auto-protection. » Ces dérives sont d'autant plus problématiques dans la technologie que notre travail s'effectue presque toujours au sein d'un système complexe : la façon dont le management réagit aux échecs engendre une culture de la peur, qui rend improbable la remontée des signaux de problème. Résultat : les problèmes restent cachés jusqu'à ce qu'une catastrophe éclate.

Le modèle de Westrum : trois cultures, trois manières de traiter l'information

Le Dr Ron Westrum fut l'un des premiers à observer l'importance de la culture organisationnelle sur la sécurité et la performance. Étudiant les organisations de santé, il constata que la présence d'une culture « générative » était l'un des meilleurs prédicteurs de la sécurité des patients. Il distingua trois types de culture, qui se différencient surtout par la manière dont l'information y circule.

Type de cultureComment l'information y circuleRéponse à l'échec
Pathologique (pathological)La peur et la menace dominent ; on thésaurise l'information, on la retient pour des raisons politiques ou on la déforme pour se mettre en valeurL'échec est dissimulé
Bureaucratique (bureaucratic)Les règles et les processus prévalent, souvent pour que chaque département défende son « territoire »L'échec passe par un système de jugement : punition, ou justice et clémence
Générative (generative)On recherche et partage activement l'information pour mieux servir la mission ; les responsabilités sont partagées tout au long de la chaîne de valeurL'échec mène à la réflexion et à une véritable enquête

Tout comme dans la santé, une culture générative à haute confiance s'est révélée prédictive de la performance informatique et organisationnelle dans les chaînes de valeur technologiques. Nous établissons les fondations d'une telle culture en nous efforçant de créer un système de travail sûr : quand survient un accident, au lieu de chercher l'erreur humaine, nous cherchons comment reconcevoir le système pour empêcher que l'accident ne se reproduise.

Concrètement, nous menons un post-mortem sans blâme (blameless post-mortem) après chaque incident, pour comprendre au mieux comment il s'est produit et nous accorder sur les meilleures contre-mesures, idéalement pour prévenir le problème mais aussi pour accélérer sa détection et son rétablissement. Ce faisant, nous produisons de l'apprentissage organisationnel.

À retenir

Bethany Macri, ingénieure chez Etsy qui a piloté la création de l'outil Morgue pour consigner les post-mortems, résume tout l'enjeu d'une phrase : « En supprimant le blâme, vous supprimez la peur ; en supprimant la peur, vous permettez l'honnêteté ; et l'honnêteté permet la prévention. »

Le Dr Steven Spear observe que le fruit de cette substitution — l'apprentissage organisationnel à la place du blâme — est que « les organisations deviennent toujours plus auto-diagnostiquantes et auto-améliorantes, expertes à détecter les problèmes et à les résoudre ». Beaucoup de ces attributs avaient déjà été décrits par le Dr Peter Senge dans La Cinquième Discipline comme ceux des organisations apprenantes : ils aident les clients, garantissent la qualité, créent un avantage concurrentiel et une force de travail engagée, et font émerger la vérité.

Institutionnaliser l'amélioration du travail quotidien

Les équipes sont souvent incapables ou peu disposées à améliorer les processus dans lesquels elles opèrent. Conséquence : non seulement elles continuent de souffrir de leurs problèmes actuels, mais cette souffrance s'aggrave avec le temps. Mike Rother l'a observé dans Toyota Kata : en l'absence d'améliorations, les processus ne restent pas stables — sous l'effet du chaos et de l'entropie, ils se dégradent.

Dans la chaîne de valeur technologique, lorsque nous évitons de régler nos problèmes en multipliant les contournements quotidiens (workarounds), nos problèmes et notre dette technique (technical debt) s'accumulent jusqu'à ce que tout notre temps passe en contournements, à éviter le désastre, sans aucun cycle disponible pour du travail productif. C'est pourquoi Mike Orzen, auteur de Lean IT, formule cette idée-force :

Note

« Plus important encore que le travail quotidien est l'amélioration du travail quotidien. » L'amélioration ne se fait pas à côté du travail : elle est le travail. Sans cycles réservés à payer la dette et à corriger les causes profondes, le système ne stagne pas — il régresse.

Nous améliorons le travail quotidien en réservant explicitement du temps pour rembourser la dette technique, corriger les défauts, refactorer et améliorer les zones problématiques de notre code et de nos environnements. Cela peut prendre la forme de cycles réservés dans chaque itération de développement, ou de kaizen blitzes — des périodes où les ingénieurs s'organisent spontanément en équipes pour s'attaquer au problème de leur choix. Le résultat : chacun trouve et corrige les problèmes dans son périmètre, en permanence, comme partie intégrante de son travail. Une fois réglés les problèmes contournés depuis des mois ou des années, nous pouvons éradiquer les problèmes moins évidents — en détectant et en traitant des signaux d'échec toujours plus faibles, nous corrigeons quand c'est plus facile, moins coûteux, et quand les conséquences sont plus petites.

L'exemple d'Alcoa : des signaux toujours plus faibles

Le cas d'Alcoa, fabricant d'aluminium qui réalisait 7,8 milliards de dollars de revenus en 1987, illustre cette mécanique. La production d'aluminium exige chaleur extrême, hautes pressions et produits corrosifs. En 1987, le bilan sécurité d'Alcoa était effrayant : 2 % des quatre-vingt-dix mille employés étaient blessés chaque année — soit sept blessures par jour. Quand Paul O'Neill devint PDG, son premier objectif fut zéro blessure pour les employés, sous-traitants et visiteurs.

O'Neill voulait être averti dans les vingt-quatre heures de toute blessure — non pour punir, mais pour s'assurer que les apprentissages étaient générés et incorporés afin de rendre le lieu de travail plus sûr. En dix ans, Alcoa réduisit son taux de blessures de 95 %. La baisse permit ensuite de se concentrer sur des problèmes plus petits et des signaux plus faibles : au lieu de n'alerter O'Neill qu'en cas de blessure, on se mit à signaler aussi les quasi-accidents (close calls). Comme l'écrit le Dr Spear, « les Alcoans cessèrent progressivement de contourner les difficultés et les obstacles. Faire face, éteindre les incendies et bricoler furent peu à peu remplacés par une dynamique d'identification des opportunités d'amélioration. À mesure que ces opportunités étaient repérées et les problèmes investigués, les poches d'ignorance qu'elles révélaient étaient converties en pépites de savoir. » De même, dans la technologie, à mesure que notre système de travail devient plus sûr, nous pouvons élargir le post-mortem sans blâme : d'abord les seuls incidents touchant les clients, puis les incidents internes mineurs et les quasi-accidents.

Transformer les découvertes locales en améliorations globales

Quand un apprentissage est découvert localement, il faut un mécanisme pour que le reste de l'organisation puisse l'utiliser et en bénéficier. Autrement dit, lorsqu'une équipe ou un individu acquiert une expertise, notre but est de convertir ce savoir tacite (tacit knowledge) — difficile à transmettre par écrit ou par la parole — en savoir explicite et codifié, qui devient à son tour, par la pratique, l'expertise d'autrui. Ainsi, quiconque effectue un travail similaire le fait fort de l'expérience cumulée et collective de tous ceux qui, dans l'organisation, ont déjà accompli ce travail.

SAVOIR TACITE                          SAVOIR EXPLICITE / CODIFIÉ
(dans une seule tête,                  (réutilisable par tous)
 difficile à transmettre)

  expérience d'une équipe   ──┐
  expertise d'un individu   ──┤
  apprentissage d'un        ──┼──► CODIFIER ──► PARTAGER ──► RÉUTILISER
   incident local             │     (post-mortems       (au prochain
                              ┘      cherchables,         travail similaire,
                                     code partagé,        l'équipe part
                                     bibliothèques)       du savoir collectif)

Un exemple remarquable de cette conversion du local vers le global est le programme de propulsion nucléaire de la marine américaine (Naval Reactors, ou « NR »), qui totalise plus de 5 700 années-réacteur d'exploitation sans le moindre accident nucléaire ni fuite de radiation. La NR est réputée pour son engagement intense envers les procédures scriptées et le travail standardisé, et pour son exigence de rapports d'incident à la moindre déviation, aussi minime soit le signal d'échec — les procédures et les conceptions sont constamment mises à jour à partir de ces apprentissages. Lorsqu'un nouvel équipage prend la mer pour son premier déploiement, lui et ses officiers bénéficient ainsi du savoir collectif de 5 700 années-réacteur sans accident ; et leur propre expérience viendra à son tour enrichir ce savoir pour les équipages futurs.

Dans la technologie, nous devons créer des mécanismes semblables : rendre tous nos rapports de post-mortem cherchables par les équipes confrontées à des problèmes similaires, et bâtir des dépôts de code source partagés à l'échelle de l'organisation, où code, bibliothèques et configurations incarnant le meilleur savoir collectif sont aisément réutilisables. Tous ces mécanismes convertissent l'expertise individuelle en artefacts utilisables par le reste de l'organisation.

Injecter des patterns de résilience dans le travail quotidien

Les organisations industrielles peu performantes se prémunissent des perturbations en « se gonflant » — en ajoutant du gras. Pour réduire le risque qu'un poste de travail reste inactif (inventaire arrivé en retard, mis au rebut…), les managers stockent davantage d'inventaire à chaque poste ; mais ce tampon accroît l'en-cours (work in progress), avec tous les effets indésirables déjà évoqués. De même, pour réduire le risque de panne d'une machine, ils augmentent la capacité en achetant plus d'équipement, en embauchant ou en agrandissant les locaux — toutes options qui font grimper les coûts.

Les organisations très performantes obtiennent, elles, des résultats égaux ou meilleurs en améliorant les opérations quotidiennes, en introduisant continuellement de la tension pour élever la performance, et en gravant davantage de résilience dans leur système. Chez Aisin Seiki Global, l'un des principaux fournisseurs de Toyota, une expérience typique dans une usine de matelas en donne l'image : avec deux lignes de production capables chacune de cent unités par jour, les jours creux, toute la production était envoyée sur une seule ligne pour expérimenter des moyens d'accroître la capacité et repérer les vulnérabilités, en sachant que si la surcharge faisait tomber la ligne, la seconde prendrait le relais. À force d'expérimentation incessante, Aisin augmentait sa capacité sans ajouter d'équipement ni embaucher.

Astuce

Le pattern qui émerge de ces rituels d'amélioration n'améliore pas seulement la performance, il améliore la résilience, parce que l'organisation est en permanence en état de tension et de changement. L'auteur et analyste du risque Nassim Nicholas Taleb a nommé antifragilité (antifragility) ce processus consistant à appliquer du stress pour se renforcer.

Dans la chaîne de valeur technologique, nous introduisons la même tension en cherchant toujours à réduire les délais de déploiement, à augmenter la couverture de test, à diminuer les temps d'exécution des tests, voire à ré-architecturer pour accroître la productivité des développeurs ou la fiabilité. Nous menons aussi des Game Days — des exercices où l'on répète des pannes à grande échelle, par exemple en éteignant des centres de données entiers. Ou nous injectons des défaillances toujours plus larges dans l'environnement de production : le célèbre « Chaos Monkey » de Netflix, qui tue au hasard des processus et des serveurs en production, en est l'incarnation, garantissant que le système est aussi résilient que nous le voulons.

Attention

Ces pratiques ne s'improvisent pas dans un système fragile. Injecter délibérément des pannes suppose d'abord d'avoir les fondations des Première et Deuxième Voies — détection rapide, capacité de rétablissement, post-mortems sans blâme. Sans elles, un Game Day ne fait que transformer une faiblesse latente en incident réel, sans le filet de la confiance ni de l'apprentissage.

Les leaders renforcent une culture d'apprentissage

Traditionnellement, on attendait des leaders qu'ils fixent les objectifs, allouent les ressources et établissent les bonnes incitations — bref, qu'ils dirigent en « prenant toutes les bonnes décisions ». Or les preuves abondent : la grandeur ne naît pas de leaders qui décident de tout. Le rôle du leader est de créer les conditions pour que son équipe découvre la grandeur dans son travail quotidien. Créer la grandeur requiert à la fois les leaders et les équipiers, mutuellement dépendants.

Jim Womack, auteur de Gemba Walks, décrit la relation de travail complémentaire et le respect mutuel qui doivent s'instaurer entre les leaders et les travailleurs de première ligne. Cette relation est nécessaire parce que ni l'un ni l'autre ne peut résoudre seul les problèmes : les leaders ne sont pas assez près du travail, indispensable pour résoudre tout problème, tandis que les travailleurs de terrain n'ont ni le contexte organisationnel plus large ni l'autorité pour opérer des changements hors de leur périmètre. Leaders et équipiers sont ainsi mutuellement dépendants l'un de l'autre.

Le kata d'amélioration : la méthode scientifique au quotidien

Les leaders doivent élever la valeur de l'apprentissage et de la résolution disciplinée de problèmes. Mike Rother a formalisé ces méthodes dans ce qu'il nomme le kata de coaching (coaching kata). Le résultat reproduit la méthode scientifique : nous énonçons explicitement nos objectifs « Nord vrai » (True North), comme « maintenir zéro accident » chez Alcoa ou « doubler le débit en un an » chez Aisin. Ces objectifs stratégiques nourrissent des objectifs itératifs plus courts, cascadés puis exécutés en établissant des conditions cibles (target conditions) au niveau de la chaîne de valeur ou du poste de travail — par exemple « réduire le délai de 10 % d'ici deux semaines ».

Note

La condition cible cadre une expérience scientifique : on énonce le problème à résoudre, l'hypothèse sur la façon dont la contre-mesure le résoudra, la méthode pour tester cette hypothèse, l'interprétation des résultats, puis l'usage des apprentissages pour informer l'itération suivante.

Le leader coache la personne qui mène l'expérience à l'aide de questions désormais canoniques : Quelle était votre dernière étape et que s'est-il passé ? Qu'avez-vous appris ? Quelle est votre condition actuelle ? Quelle est votre prochaine condition cible ? Sur quel obstacle travaillez-vous maintenant ? Quelle est votre prochaine étape, et son résultat attendu ? Quand pourrons-nous vérifier ? Cette approche, où les leaders aident les équipiers à voir et résoudre les problèmes de leur travail, est au cœur du système de production Toyota, des organisations apprenantes, du kata d'amélioration (Improvement Kata) et des organisations à haute fiabilité. Mike Rother voit d'ailleurs Toyota « comme une organisation définie avant tout par les routines comportementales uniques qu'elle enseigne continuellement à tous ses membres ». Dans la technologie, cette méthode itérative guide nos processus d'amélioration internes, mais aussi nos expériences pour vérifier que les produits aident réellement nos clients à atteindre leurs objectifs.

Conclusion de la Partie I

Les principes de la Troisième Voie répondent au besoin de valoriser l'apprentissage organisationnel, de permettre la haute confiance et le franchissement des frontières entre fonctions, d'accepter que des échecs surviendront toujours dans les systèmes complexes, et de rendre acceptable le fait de parler des problèmes pour bâtir un système de travail sûr. Ils exigent aussi d'institutionnaliser l'amélioration du travail quotidien, de convertir les apprentissages locaux en apprentissages globaux, et d'injecter continuellement de la tension.

Bien que la culture d'apprentissage et d'expérimentation soit le propre de la Troisième Voie, elle s'entrelace aux deux premières : améliorer le flux et le feedback requiert la même approche itérative et scientifique — cadrer une condition cible, énoncer une hypothèse, concevoir et mener des expériences, évaluer les résultats. Les bénéfices ne sont pas seulement une meilleure performance : ils incluent une résilience accrue, une plus grande satisfaction au travail et une meilleure adaptabilité de l'organisation. Ainsi se referme la première partie du DevOps Handbook, qui aura parcouru les mouvements historiques ayant mené au DevOps et posé ses trois principes fondateurs — Flux, Feedback et Apprentissage continu ; la deuxième partie s'attaquera à la question pratique : comment démarrer une transformation DevOps dans votre organisation.

À retenir

  • La Troisième Voie institue une culture d'apprentissage et d'expérimentation continus, qui transforme le savoir individuel en savoir d'équipe puis organisationnel — elle s'entrelace aux Voies du Flux et du Feedback.
  • Le modèle de Westrum distingue les cultures pathologique, bureaucratique et générative par la façon dont l'information y circule ; la culture générative, à haute confiance, prédit la sécurité comme la performance organisationnelle.
  • On bâtit un système de travail sûr par le post-mortem sans blâme : « En supprimant le blâme, vous supprimez la peur ; en supprimant la peur, vous permettez l'honnêteté ; et l'honnêteté permet la prévention » (Bethany Macri, Etsy).
  • « Plus important encore que le travail quotidien est l'amélioration du travail quotidien » : réserver des cycles pour payer la dette technique et corriger les causes profondes, sous peine de voir les processus se dégrader (cas Alcoa, des signaux d'échec toujours plus faibles).
  • Convertir le savoir tacite en savoir codifié et partagé (post-mortems cherchables, dépôts de code communs) transforme les découvertes locales en améliorations globales — à l'image des 5 700 années-réacteur sans accident de la marine américaine.
  • Injecter des patterns de résilience — tension délibérée, Game Days, « Chaos Monkey » de Netflix — rend le système antifragile : le stress contrôlé renforce au lieu de fragiliser.
  • Le rôle du leader n'est pas de tout décider mais de créer les conditions de la réussite : leadership serviteur, kata d'amélioration et kata de coaching ancrent la méthode scientifique (PDCA, conditions cibles, True North) dans le travail quotidien.