Culture juste, résilience et apprentissage quotidien

Les deux premières voies (Ways) cherchaient à créer un flux rapide vers la production, puis du feedback en abondance et au plus tôt. La troisième voie — les pratiques techniques de l'apprentissage — installe les rituels qui transforment les accidents, inévitables dans les systèmes complexes, en occasions d'apprendre. Ce chapitre ouvre cette partie en posant sa pierre angulaire : faire de la sécurité psychologique une réalité grâce à une culture juste (just culture), puis renforcer délibérément la résilience en injectant des pannes dans nos propres systèmes.

Quand nous travaillons au sein d'un système complexe, il nous est impossible de prédire tous les effets de nos actions. Les listes de contrôle (checklists) et les manuels d'exploitation (runbooks) codifient notre compréhension du moment, mais ne suffisent pas : des accidents surviennent, parfois catastrophiques. Pour évoluer sans danger dans cette complexité, l'organisation doit exceller dans l'autodiagnostic et l'auto-amélioration — détecter les problèmes, les résoudre, puis multiplier l'effet de la solution en la diffusant partout. Le Dr Steven Spear appelle organisations résilientes celles qui savent se soigner elles-mêmes : « Pour une telle organisation, répondre aux crises n'est pas un travail singulier. C'est quelque chose qu'elle fait tout le temps. Et c'est cette réactivité qui est la source de sa fiabilité. »

Netflix face à la panne géante d'AWS

Le 21 avril 2011, toute la zone de disponibilité (availability zone) US-EAST d'Amazon AWS s'effondre, emportant avec elle la quasi-totalité des clients qui en dépendaient — Reddit, Quora et bien d'autres. Une exception déconcertante : Netflix, qui semble traverser la tempête sans broncher. La rumeur veut alors qu'en tant que gros client d'Amazon, l'entreprise ait bénéficié d'un traitement de faveur. La réalité, exposée sur le blog d'ingénierie de Netflix, est tout autre : ce sont des choix d'architecture pris dès 2009 qui ont permis cette résilience.

En 2008, le service de streaming tournait sur une application J2EE monolithique hébergée dans l'un de leurs centres de données. À partir de 2009, ils ont entrepris de réarchitecturer ce système en mode « natif du cloud » (cloud native) : conçu pour s'exécuter entièrement dans le cloud public d'Amazon et survivre à des pannes majeures. L'un de leurs objectifs explicites : que Netflix continue de fonctionner même si une zone de disponibilité entière tombait, exactement comme US-EAST. Cela exigeait un système faiblement couplé (loosely-coupled), chaque composant étant doté de délais d'expiration (timeouts) agressifs pour qu'une défaillance locale ne fige jamais l'ensemble. Chaque fonctionnalité était conçue pour se dégrader gracieusement : lors des pics de charge, plutôt qu'une liste de films personnalisée et coûteuse à calculer, on servait du contenu statique, mis en cache ou non personnalisé.

Mais le plus audacieux restait à venir. Netflix avait construit et faisait tourner en permanence un service nommé Chaos Monkey, qui simulait les pannes d'AWS en tuant continuellement et au hasard des serveurs de production. L'intention : habituer toutes les équipes d'ingénierie « à un niveau constant de défaillance dans le cloud » afin que les services se rétablissent « automatiquement, sans aucune intervention manuelle ». Comme on pouvait s'y attendre, les premières exécutions de Chaos Monkey en production ont fait échouer des services de façons jamais imaginées. En les trouvant et les corrigeant pendant les heures de bureau, les ingénieurs ont itérativement bâti un service plus résilient — tout en générant des apprentissages organisationnels qui ont propulsé leurs systèmes loin devant la concurrence.

Établir une culture juste pour rendre la sécurité possible

L'un des prérequis d'une culture d'apprentissage, c'est que la réponse aux accidents — qui surviendront, inévitablement — soit perçue comme juste. Le Dr Sidney Dekker, qui a contribué à codifier les éléments clés de la culture de sécurité et a forgé l'expression just culture, écrit : « Lorsque les réponses aux incidents et aux accidents sont perçues comme injustes, elles peuvent entraver les enquêtes de sécurité, semer la peur plutôt que la vigilance chez ceux qui font un travail critique pour la sécurité, rendre les organisations plus bureaucratiques plutôt que plus prudentes, et cultiver le secret professionnel, l'évitement et l'auto-protection. »

Cette logique de punition imprègne, subtilement ou ouvertement, la manière dont beaucoup de managers ont opéré au siècle dernier. Le raisonnement : pour atteindre les objectifs, les dirigeants doivent commander, contrôler, établir des procédures pour éliminer les erreurs et en imposer le respect. Dekker nomme théorie de la pomme pourrie (Bad Apple Theory) l'idée d'éliminer l'erreur en éliminant les personnes qui la commettent. Il la juge fausse, car « l'erreur humaine n'est pas la cause de nos ennuis ; elle est au contraire une conséquence de la conception des outils que nous avons donnés aux gens ».

En transformant l'information en connaissance et en intégrant le fruit de l'apprentissage dans nos systèmes, on atteint les objectifs d'une culture juste : équilibrer les besoins de sécurité et de responsabilité (accountability). Comme le résume John Allspaw, CTO d'Etsy : « Notre but, chez Etsy, est de considérer les fautes, erreurs, lapsus et autres avec une perspective d'apprentissage. » Lorsqu'un ingénieur commet une erreur et se sent en sécurité pour en détailler les circonstances, non seulement il accepte d'en répondre, mais il devient enthousiaste à l'idée d'aider toute l'entreprise à éviter la même erreur. À l'inverse, le punir dissuade chacun de fournir les détails nécessaires à la compréhension du mécanisme de la défaillance — ce qui garantit qu'elle se reproduira.

Deux pratiques contribuent puissamment à cette culture juste : les post-mortems sans blâme et l'introduction contrôlée de pannes en production.

Les post-mortems sans blâme

Lorsqu'un accident ou un incident significatif survient — déploiement raté, incident en production affectant les clients —, on organise un post-mortem sans blâme (blameless post-mortem) une fois l'incident résolu. Le terme, forgé par John Allspaw, désigne un examen des erreurs « qui se concentre sur les aspects situationnels du mécanisme d'une défaillance et sur le processus décisionnel des personnes proches de cette défaillance ». On programme la réunion au plus tôt après l'accident, avant que les souvenirs et les liens de cause à effet ne s'estompent — mais après la résolution, pour ne pas distraire ceux qui sont encore à la manœuvre.

Au cours de la réunion, on s'attache à :

• reconstruire une chronologie (timeline) et rassembler les détails depuis plusieurs perspectives, sans jamais punir l'erreur ;
• donner à chaque ingénieur le pouvoir d'améliorer la sécurité en rendant compte en détail de sa contribution à la défaillance ;
• faire de ceux qui commettent des erreurs les experts qui apprennent au reste de l'organisation à les éviter ;
• accepter qu'il existe toujours un espace de décision discrétionnaire où l'humain choisit d'agir ou non, et que juger ces choix relève du recul a posteriori ;
• proposer des contre-mesures (countermeasures) pour empêcher un accident similaire, en les consignant avec une date cible et un responsable de suivi.

Pour y parvenir, certains acteurs doivent être présents : les personnes impliquées dans les décisions ayant pu contribuer au problème, celles qui l'ont identifié, celles qui y ont répondu, celles qui l'ont diagnostiqué, celles qui en ont subi les effets — et toute personne souhaitant assister à la réunion. La première tâche consiste à consigner la meilleure compréhension de la chronologie : toutes les actions menées et leur horodatage (idéalement appuyés sur des journaux de discussion comme IRC ou Slack), les effets observés (de préférence sous forme de métriques issues de la télémétrie de production, plutôt que de récits subjectifs), les pistes d'investigation suivies et les résolutions envisagées.

On réserve assez de temps pour réfléchir aux contre-mesures, les prioriser et leur attribuer un responsable et un calendrier — ce qui démontre une fois de plus qu'on valorise l'amélioration du travail quotidien autant que le travail lui-même. Dan Milstein, ingénieur principal chez HubSpot, ouvre toutes ses réunions en disant : « Nous essayons de nous préparer à un futur où nous serons aussi bêtes qu'aujourd'hui. » Autrement dit, une contre-mesure ne peut se résumer à « être plus prudent » ou « être moins bête » : il faut concevoir de vraies parades. Par exemple, de nouveaux tests automatisés détectant les conditions dangereuses dans le pipeline, davantage de télémétrie de production, l'identification des catégories de changements exigeant une relecture supplémentaire, ou des répétitions de ce type de panne lors des exercices de Game Day.

Publier les post-mortems le plus largement possible

Une fois le post-mortem tenu, on annonce largement la disponibilité des notes et des artefacts associés (chronologies, journaux IRC, communications externes). Idéalement, tout cela est placé dans un emplacement centralisé accessible à toute l'organisation. Les post-mortems sont si importants qu'on peut même interdire de clore un incident de production tant que la réunion n'a pas eu lieu. C'est ce qui permet de transformer des apprentissages locaux en améliorations globales. Randy Shoup, ancien directeur de l'ingénierie de Google App Engine, le décrit : « Chez Google, tout est cherchable. Tous les documents de post-mortem sont à des endroits visibles par les autres Googlers. Et croyez-moi, dès qu'un groupe rencontre un incident qui ressemble à quelque chose de déjà arrivé, ces documents sont parmi les premiers lus et étudiés. »

Publier largement augmente l'apprentissage organisationnel, et il devient de plus en plus courant que les entreprises de services en ligne publient leurs post-mortems pour les pannes ayant touché les clients — ce qui accroît la transparence et, par ricochet, la confiance des clients internes comme externes.

Le Dr Amy C. Edmondson, titulaire de la chaire Novartis de leadership et de management à la Harvard Business School, rappelle que réduire la stigmatisation de l'échec n'est ni coûteux ni chronophage. Eli Lilly organise depuis le début des années 1990 des « fêtes de l'échec » (failure parties) pour honorer les expériences scientifiques intelligentes et de grande qualité qui n'aboutissent pas — un moyen peu onéreux de redéployer plus tôt des ressources précieuses, économisant des centaines de milliers de dollars et amorçant parfois de nouvelles découvertes.

Abaisser le seuil de tolérance pour capter les signaux faibles

À mesure qu'une organisation apprend à voir et résoudre les problèmes, elle doit abaisser le seuil de ce qui constitue un problème pour continuer d'apprendre. Le but : amplifier les signaux faibles de défaillance (weak failure signals). Chez Alcoa, lorsque le taux d'accidents du travail eut suffisamment baissé pour ne plus être banal, le PDG Paul O'Neill se fit notifier non plus seulement les accidents, mais aussi les quasi-accidents (near-misses). Comme l'observe Spear : ce qui avait commencé par des problèmes de sécurité révéla une ignorance des processus qui se manifestait aussi ailleurs — qualité, délais, rendement.

L'exemple de la NASA illustre l'enjeu vital de cette amplification. En 2003, seize jours après son décollage, la navette Columbia explose lors de sa rentrée dans l'atmosphère. On sait aujourd'hui qu'un morceau de mousse isolante s'était détaché du réservoir externe au décollage. Avant la rentrée, une poignée d'ingénieurs de niveau intermédiaire avait signalé l'impact, observé sur les moniteurs lors d'une revue post-lancement. Leurs voix ne furent pas entendues : on leur répondit que le problème de mousse n'avait rien de nouveau. Des détachements de mousse avaient déjà endommagé des navettes sans jamais causer d'accident ; c'était considéré comme un problème de maintenance, et rien ne fut fait avant qu'il ne soit trop tard.

Dans un article de la Harvard Business Review (2006), Michael Roberto, Richard Bohmer et Amy Edmondson distinguent deux modèles d'organisation : le modèle standardisé, où routine et systèmes gouvernent tout dans le respect strict des plannings et budgets, et le modèle expérimental, où chaque exercice et chaque information sont évalués et débattus comme dans un laboratoire de R&D. « Les entreprises s'attirent des ennuis quand elles appliquent le mauvais état d'esprit. Dès les années 1970, la NASA avait créé une culture de standardisation rigide, vantant auprès du Congrès la navette comme un engin bon marché et réutilisable. » Leur conclusion est sans appel : « la vigilance seule n'empêchera pas les menaces ambiguës [signaux faibles] de se muer en échecs coûteux, parfois tragiques. » C'est la culture et l'état d'esprit qui comptent, pas le seul fait « d'être prudent ».

Notre travail dans la chaîne de valeur technologique, comme le voyage spatial, doit être abordé comme une démarche fondamentalement expérimentale. Chaque tâche est une hypothèse potentiellement importante et une source de données, et non une simple application de pratiques passées.

Culture du blâme	Culture juste
L'erreur est la cause des ennuis	L'erreur est la conséquence d'un système mal conçu
« Nommer, blâmer, faire honte » au coupable	Maximiser l'apprentissage et la sécurité psychologique
Théorie de la pomme pourrie : éliminer les gens	Améliorer les outils et le système qui ont rendu l'erreur possible
L'information est cachée par peur de la sanction	L'information est partagée librement et publiée largement
« Sois plus prudent », « sois moins bête »	Contre-mesures concrètes, datées, avec un responsable
Les signaux faibles sont ignorés	Les signaux faibles sont amplifiés et traités tôt

Redéfinir l'échec et encourager la prise de risque calculée

Les dirigeants renforcent, volontairement ou non, la culture et les valeurs par leurs actes. Les experts de l'audit et de l'éthique l'observent depuis longtemps : le « ton donné au sommet » (tone at the top) prédit la probabilité de fraudes et de pratiques déloyales. Pour ancrer une culture d'apprentissage et de prise de risque calculée, les dirigeants doivent rappeler sans cesse que chacun doit se sentir à l'aise avec la mise au jour des défaillances et responsable d'en tirer des leçons.

Sur les échecs, Roy Rapoport, de Netflix, fait une observation tirée du State of DevOps Report 2014 : « Les organisations DevOps très performantes échouent et se trompent plus souvent. Non seulement c'est acceptable, mais c'est ce dont les organisations ont besoin ! On le voit dans les données : si les meilleurs déploient trente fois plus fréquemment avec seulement la moitié du taux d'échec des changements, ils ont forcément plus de défaillances. » Il poursuit avec une anecdote frappante : une panne majeure chez Netflix, causée par une « erreur idiote » d'un ingénieur qui avait déjà fait tomber Netflix deux fois en dix-huit mois. « Bien sûr, c'est une personne que nous ne licencierions jamais. » Dans ce même laps de temps, cet ingénieur avait fait progresser leurs opérations et leur automatisation « non de quelques kilomètres, mais d'années-lumière » — un travail qui leur permettait désormais de déployer sereinement chaque jour. Sa conclusion : « Le DevOps doit autoriser ce type d'innovation et le risque qui l'accompagne. Oui, vous aurez plus de pannes en production. Mais c'est une bonne chose, et cela ne doit pas être puni. »

Injecter des pannes pour bâtir la résilience

Injecter des défaillances dans l'environnement de production, comme le fait Chaos Monkey, est l'un des moyens d'accroître notre résilience. Il s'agit de répéter et de provoquer des pannes pour confirmer que nos systèmes sont conçus et architecturés correctement, de sorte que les défaillances se produisent de façon spécifique et contrôlée. Michael Nygard, auteur de Release It!, file une métaphore éclairante : « Comme on intègre des zones de déformation aux voitures pour absorber les chocs et protéger les passagers, vous pouvez décider quelles fonctionnalités sont indispensables et bâtir des modes de défaillance qui éloignent les fissures de ces fonctionnalités. Si vous ne concevez pas vos modes de défaillance, vous récolterez ceux, imprévisibles et généralement dangereux, qui émergeront d'eux-mêmes. »

La résilience exige donc qu'on définisse d'abord nos modes de défaillance, puis qu'on teste qu'ils opèrent comme prévu — en injectant des fautes en production et en répétant des pannes à grande échelle, idéalement sans même impacter les clients.

Le « Grand Redémarrage Amazon de 2014 » (Great Amazon Reboot) en offre une démonstration spectaculaire. Près de 10 % de la flotte de serveurs EC2 d'Amazon dut être redémarrée pour appliquer un correctif de sécurité Xen d'urgence. Christos Kalantzis, de l'ingénierie des bases de données cloud de Netflix, se souvient : « En apprenant la nouvelle, nos mâchoires sont tombées. Quand on a vu combien de nœuds Cassandra seraient touchés, je me suis senti mal. » Puis : « Je me suis rappelé tous les exercices Chaos Monkey que nous avions traversés. Ma réaction est devenue : "Qu'ils viennent !" » Sur plus de 2 700 nœuds Cassandra en production, 218 furent redémarrés et vingt-deux échouèrent à redémarrer. Bilan : « Netflix a connu zéro temps d'arrêt ce week-end-là. » Plus surprenant encore, personne chez Netflix ne traitait d'incident — personne n'était même au bureau : tous fêtaient une acquisition à Hollywood. Preuve qu'en se concentrant proactivement sur la résilience, une entreprise gère comme une routine ce qui plongerait la plupart des autres en crise.

Instituer des Game Days pour répéter les pannes

Les Game Days sont des répétitions de reprise après sinistre, terme popularisé par Jesse Robbins — l'un des fondateurs de la communauté Velocity Conference et cofondateur de Chef, surnommé en interne chez Amazon le « Maître du Désastre » (Master of Disaster). Le concept de Game Day est issu de la discipline de l'ingénierie de la résilience (resilience engineering), que Robbins définit comme « un exercice conçu pour accroître la résilience par l'injection de fautes à grande échelle dans des systèmes critiques ». Comme il le dit : « un service n'est vraiment testé que lorsqu'on le casse en production. »

Le déroulé suit une logique précise.

  1. Planifier un événement catastrophique futur
     (ex. destruction simulée d'un centre de données entier)
            │
            ▼
  2. Laisser aux équipes le temps de se préparer
     (éliminer les points de défaillance uniques, créer
      monitoring et procédures de bascule / failover)
            │
            ▼
  3. Répéter des manœuvres : bascule de base de données,
     coupure d'un lien réseau important...
            │  problèmes rencontrés → identifiés, corrigés, retestés
            ▼
  4. Exécuter la panne réelle à l'heure prévue
     (« couper le courant d'un site, sans préavis »)
            │
            ▼
  5. Exposer les défauts latents → apprendre → recommencer
     (exercices de plus en plus intenses, jusqu'à la routine)

Chez Amazon, on « coupait littéralement le courant d'un site — sans préavis — puis on laissait les systèmes défaillir naturellement et les gens suivre leurs procédures jusqu'au bout ». On expose ainsi les défauts latents (latent defects), ces problèmes qui n'apparaissent qu'une fois les fautes injectées : un système de supervision crucial qui se retrouve coupé par la panne orchestrée, ou un point de défaillance unique insoupçonné. Répétés de manière toujours plus intense, ces exercices finissent par ressembler à une journée ordinaire.

Krishnan insiste sur un angle souvent négligé : les processus métier et les communications. Systèmes et processus sont étroitement imbriqués — la défaillance d'un système métier affecte le processus, et un système fonctionnel sans le bon personnel ne sert pas à grand-chose. En créant la panne dans un cadre contrôlé, on s'entraîne et on rédige les manuels d'intervention (playbooks) dont on a besoin. Autre bénéfice essentiel : les gens savent enfin qui appeler. Ils tissent des relations avec d'autres départements pour collaborer pendant un incident, transformant des actions conscientes et laborieuses en réflexes routiniers.

Pour créer une culture juste qui rend l'apprentissage possible, il faut recontextualiser les soi-disant échecs. Traitées correctement, les erreurs inhérentes aux systèmes complexes engendrent un environnement d'apprentissage dynamique où chacun se sent assez en sécurité pour proposer idées et observations, et où les groupes rebondissent plus vite. Et lorsqu'on réduit suffisamment le nombre d'accidents, on abaisse encore notre tolérance afin de continuer d'apprendre. Comme le dit Peter Senge : « Le seul avantage concurrentiel durable est la capacité d'une organisation à apprendre plus vite que la concurrence. »

À retenir

• Une culture juste (Dekker, Allspaw) considère l'erreur humaine comme la conséquence d'un système mal conçu, jamais comme sa cause ; elle remplace le « nommer, blâmer, faire honte » par la maximisation de l'apprentissage et la sécurité psychologique.
• Le post-mortem sans blâme se tient au plus tôt après résolution : on reconstruit une chronologie factuelle, on bannit les énoncés contrefactuels (« aurait dû »), et on produit des contre-mesures concrètes, datées et attribuées — jamais un simple « soyons plus prudents ».
• Publier les post-mortems le plus largement possible convertit les apprentissages locaux en améliorations globales ; faciliter leur documentation (l'outil Morgue d'Etsy) en augmente fortement le nombre.
• Il faut abaisser sans cesse le seuil de tolérance pour amplifier les signaux faibles de défaillance — la tragédie de Columbia montre que « la vigilance seule » ne suffit pas face aux menaces ambiguës.
• Redéfinir l'échec : les organisations très performantes échouent plus souvent, et c'est sain ; un ingénieur qui fait tomber le service mais fait avancer l'automatisation « d'années-lumière » ne se licencie pas (Rapoport, Netflix).
• Injecter des pannes en production bâtit la résilience : Chaos Monkey de Netflix, les Game Days de Jesse Robbins (Amazon), le DiRT de Google — on définit ses modes de défaillance, puis on les répète jusqu'à ce qu'ils deviennent une routine.
• La répétition contrôlée renforce autant le système que l'organisation : les gens apprennent qui appeler et tissent des liens inter-équipes, transformant la gestion de crise en réponse ordinaire.