Du local au global : amélioration organisationnelle

Une équipe qui apprend, c'est précieux ; une organisation qui transforme chaque apprentissage local en savoir partagé par tous, c'est un avantage décisif. Après avoir bâti une culture où l'on parle des erreurs sans accuser et où l'on injecte délibérément des pannes pour découvrir les défauts latents, il reste à répondre à une question d'échelle : comment faire pour que la découverte d'une seule équipe profite immédiatement aux milliers d'autres ingénieurs de toute l'organisation ? Ce chapitre décrit les mécanismes — salons de discussion, dépôts partagés, documentation exécutable — qui multiplient l'effet du savoir, puis les rituels qui réservent explicitement du temps pour apprendre et rembourser la dette technique.

Les salons de discussion et le ChatOps

Beaucoup d'organisations ont créé des salons de discussion (chat rooms) pour communiquer vite au sein des équipes. Mais ces salons servent aussi à déclencher de l'automatisation — c'est tout l'enjeu du ChatOps, technique pionnière chez GitHub. L'idée consiste à placer les outils d'automatisation au cœur même de la conversation, ce qui crée par construction de la transparence et de la documentation du travail accompli.

Comme l'explique Jesse Newland, ingénieur systèmes chez GitHub : « Même quand vous êtes nouveau dans l'équipe, vous pouvez parcourir les logs de discussion et voir comment tout se fait. C'est comme si vous aviez programmé en binôme (pair-programming) avec eux en permanence. » GitHub a construit Hubot, une application logicielle qui interagit avec l'équipe d'exploitation (Ops) dans les salons : on lui adresse une commande (par exemple @hubot deploy owl to production) et il exécute l'action, les résultats étant renvoyés dans le salon.

Faire exécuter ce travail par une automatisation dans le salon — plutôt que par des scripts lancés en ligne de commande — apporte des bénéfices mesurés :

Sans ChatOps (scripts en ligne de commande)	Avec ChatOps (automatisation dans le salon)
L'action est invisible aux autres	Tout le monde voit tout ce qui se passe
Le nouvel arrivant ignore le travail quotidien réel	Dès son premier jour, il voit à quoi ressemble le travail et comment il s'exécute
Demander de l'aide intimide	On demande plus volontiers de l'aide quand on voit les autres s'entraider
Le savoir reste dans une tête isolée	L'apprentissage organisationnel s'accumule rapidement

À cela s'ajoute une propriété intrinsèque : les salons enregistrent et rendent publiques toutes les communications, là où les courriels sont privés par défaut et leur contenu difficile à découvrir ou à propager dans l'organisation. Intégrer l'automatisation au salon documente et partage nos observations et nos résolutions de problèmes comme une partie naturelle du travail, renforçant une culture de transparence et de collaboration.

Hubot pouvait déclencher l'arsenal d'automatisation maison — Puppet, Capistrano, Jenkins, resque (une bibliothèque de tâches de fond adossée à Redis), graphme (génération de graphiques depuis Graphite). Les actions allaient de la vérification de santé des services aux déploiements en production, en passant par la mise en sourdine des alertes pendant les maintenances. Toute action répétée plusieurs fois — récupérer les logs de tests de fumée (smoke test) après un déploiement raté, sortir un serveur de la rotation, revenir au tronc commun (master) pour les services front-end — devenait à son tour une action Hubot. Symétriquement, les commits et les commandes de déploiement émettaient des messages dans le salon, et le statut des changements y était posté à mesure qu'ils progressaient dans le pipeline de déploiement.

Newland observe que des questions autrefois récurrentes ne se posent presque plus : « Comment avance ce déploiement ? », « C'est toi qui le déploies ou je m'en charge ? », « La charge, ça donne quoi ? ». Mais le résultat qu'il juge le plus important est ailleurs : le travail d'exploitation est devenu plus humain, les ingénieurs pouvant découvrir les problèmes et s'entraider rapidement et facilement.

Codifier les processus standardisés dans du code réutilisable

Trop souvent, nous consignons nos standards d'architecture, de test, de déploiement et de gestion d'infrastructure dans de la prose — des documents Word téléversés quelque part. Le problème est connu : les ingénieurs qui construisent de nouvelles applications ignorent l'existence de ces documents, ou n'ont pas le temps d'appliquer les standards. Résultat, ils créent leurs propres outils et processus, avec les conséquences attendues — des applications et environnements fragiles, peu sûrs, impossibles à maintenir et coûteux à faire évoluer.

Plutôt que de loger notre expertise dans des documents Word, il faut transformer ces standards — la somme de nos apprentissages organisationnels — sous une forme exécutable facile à réutiliser. Le meilleur véhicule est un dépôt de code source centralisé, où l'outil est consultable et utilisable par tous.

Justin Arbuckle, architecte en chef chez GE Capital en 2013, résumait le besoin : « Il nous fallait un mécanisme permettant aux équipes de se conformer facilement à la réglementation — nationale, régionale, sectorielle, à travers des dizaines de cadres réglementaires, des milliers d'applications, des dizaines de milliers de serveurs, dans des dizaines de centres de données. » Le mécanisme s'appelait ArchOps ; il « a permis à nos ingénieurs d'être des bâtisseurs, pas des poseurs de briques. En transformant nos standards de conception en plans automatisés (blueprints) utilisables facilement par n'importe qui, nous avons obtenu la cohérence comme sous-produit. »

Un dépôt de code source unique et partagé

Un dépôt de code source partagé à l'échelle de toute l'organisation est l'un des mécanismes les plus puissants pour intégrer les découvertes locales. Quand on met à jour quoi que ce soit dans ce dépôt — une bibliothèque partagée, par exemple — le changement se propage rapidement et automatiquement à tous les services qui en dépendent, en s'intégrant au pipeline de déploiement de chaque équipe.

Google en offre le plus grand exemple. En 2015, l'entreprise disposait d'un dépôt unique de plus d'un milliard de fichiers et de plus de deux milliards de lignes de code, utilisé par chacun de ses vingt-cinq mille ingénieurs et couvrant toutes ses propriétés : Search, Maps, Docs, Google+, Calendar, Gmail, YouTube. Rachel Potvin, qui dirige le groupe Developer Infrastructure, le résumait à Wired : chaque ingénieur accède à « une profusion de bibliothèques » parce que « presque tout a déjà été fait ». Eran Messeri, du même groupe, ajoute qu'un dépôt unique permet d'accéder à tout le code dans sa version la plus à jour, sans aucune coordination.

Dans ce dépôt, on ne range pas seulement le code source, mais aussi tous les artefacts qui encodent du savoir :

Dépôt partagé à l'échelle de l'organisation
│
├── code source applicatif
├── standards de configuration (recettes Chef, manifestes Puppet…)
├── outils de déploiement
├── standards et outils de test (dont la sécurité)
├── outils de pipeline de déploiement
├── outils de supervision et d'analyse
└── tutoriels et standards

Randy Shoup le formule sans détour : « Le mécanisme le plus puissant pour prévenir les pannes chez Google, c'est le dépôt de code unique. Chaque fois que quelqu'un commit quoi que ce soit, cela produit un nouveau build, qui utilise toujours la dernière version de tout. Tout est construit depuis les sources plutôt que lié dynamiquement à l'exécution — il y a toujours une seule version d'une bibliothèque en usage, celle qui est liée statiquement au build. » Tom Limoncelli, ancien Site Reliability Engineer chez Google, va plus loin : la valeur d'un dépôt unique est si grande qu'elle est « difficile à exprimer en mots ».

Chez Google, chaque bibliothèque a un propriétaire — libc, OpenSSL, comme les bibliothèques internes — responsable de s'assurer qu'elle compile et passe les tests de tous les projets qui en dépendent, à la manière d'un bibliothécaire ; il pilote aussi la migration de chaque projet d'une version à la suivante. Le contraste avec le désordre habituel est saisissant : pensez à cette organisation qui exécute en production quatre-vingt-une versions différentes de la bibliothèque Struts (Java) — toutes sauf une comportant des vulnérabilités de sécurité critiques. Maintenir cette variance crée une charge opérationnelle énorme, rend les montées de version risquées, ce qui décourage les développeurs de mettre à jour, et le cycle se perpétue.

Les tests automatisés comme documentation vivante

Quand des bibliothèques partagées circulent dans l'organisation, il faut accélérer la propagation de l'expertise. Doter chacune de ces bibliothèques de tests automatisés substantiels les rend auto-documentées : elles montrent aux autres ingénieurs comment les utiliser. Ce bénéfice est quasi automatique avec le développement piloté par les tests (test-driven development, TDD), où les tests s'écrivent avant le code : la suite de tests devient alors une spécification vivante et toujours à jour du système. L'ingénieur qui veut comprendre comment utiliser une API n'a qu'à consulter la suite de tests pour y trouver des exemples de code qui fonctionnent.

Idéalement, chaque bibliothèque a un propriétaire unique — équipe ou personne — où résident le savoir et l'expertise, et une seule version est autorisée en production, garantissant que ce qui tourne tire parti de la meilleure connaissance collective. Ce propriétaire est aussi responsable de migrer chaque groupe d'une version à la suivante, ce qui exige une détection rapide des régressions par des tests automatisés complets et une intégration continue sur tous les systèmes consommateurs.

Pour propager le savoir plus vite encore, on crée des communautés de pratique : groupes de discussion ou salons dédiés à chaque bibliothèque ou service. Quiconque a une question obtient une réponse des autres utilisateurs — souvent plus prompts que les développeurs eux-mêmes. On évite ainsi les poches d'expertise isolées au profit d'un échange continu de connaissances et de patterns.

Concevoir pour l'exploitation

Lorsque les développeurs suivent leur travail en aval et participent à la résolution des incidents de production, l'application devient progressivement mieux conçue pour l'exploitation. En cherchant délibérément à rendre le code déployable et compatible avec un flux rapide, on identifie un ensemble d'exigences non fonctionnelles (non-functional requirements) à intégrer dans tous les services. Les codifier permet à chaque service, nouveau ou existant, de tirer parti de l'expérience collective :

Exigences non fonctionnelles à codifier dans tout service
│
├── télémétrie de production suffisante (appli + environnements)
├── suivi précis des dépendances
├── résilience et dégradation gracieuse en cas de panne d'un composant
├── compatibilité ascendante ET descendante entre versions
├── archivage des données pour maîtriser la taille du jeu de production
├── logs facilement consultables et compréhensibles entre services
├── traçabilité d'une requête utilisateur à travers plusieurs services
└── configuration d'exécution centralisée (drapeaux de fonctionnalité…)

Ces exigences relèvent toutes de la responsabilité de l'équipe qui construit le service. À leurs côtés, on intègre des « user stories Ops » réutilisables. Quand un travail d'exploitation ne peut être ni automatisé ni rendu en libre-service, l'objectif est de le rendre aussi répétable et déterministe que possible : on le standardise, on automatise le maximum, et on documente clairement les rares étapes manuelles (par exemple le câblage physique d'un serveur par une autre équipe) pour réduire les délais et les erreurs. Des outils comme Rundeck automatisent les flux de travail, et des systèmes de tickets comme JIRA ou ServiceNow tracent les transferts.

Idéalement, pour tout travail d'exploitation récurrent, nous savons : quel travail est requis, qui doit l'exécuter, et quelles en sont les étapes. Par exemple : « Un déploiement haute disponibilité prend quatorze étapes, mobilise quatre équipes différentes, et les cinq dernières fois il a duré trois jours en moyenne. » Tout comme on crée des user stories de développement qu'on place dans le backlog, on crée des user stories Ops bien définies — déploiement, capacité, sécurité — réutilisables à travers tous les projets. Le travail d'exploitation apparaît ainsi aux côtés du travail de développement, ce qui autorise une meilleure planification et des résultats plus reproductibles.

Aligner les choix technologiques sur les objectifs

Quand l'objectif est de maximiser la productivité des développeurs avec une architecture orientée services, de petites équipes peuvent en principe construire et exploiter leur service dans le langage qui les sert le mieux. Parfois, c'est exactement ce qui sert les objectifs de l'organisation. Mais l'inverse arrive : quand l'expertise d'un service critique ne réside que dans une seule équipe, qui seule peut le modifier ou le réparer, on a créé un goulet d'étranglement. On a optimisé la productivité d'une équipe au détriment des objectifs globaux.

Il faut donc identifier les technologies qui : entravent ou ralentissent le flux du travail ; créent une part disproportionnée de travail non planifié ; génèrent un volume disproportionné de demandes de support ; sont les plus incohérentes avec les résultats architecturaux visés (débit, stabilité, sécurité, fiabilité, continuité d'activité). En retirant ces plateformes problématiques de la liste des technologies supportées par l'exploitation, on libère celle-ci pour se concentrer sur l'infrastructure qui sert le mieux les buts globaux.

Étude de cas : standardiser la pile chez Etsy (2010)

Dans beaucoup d'organisations adoptant DevOps, les développeurs racontent : « L'exploitation ne nous fournissait pas ce dont nous avions besoin, alors on l'a construit et supporté nous-mêmes. » Etsy a pris le chemin inverse. Après une saison de fêtes 2010 quasi catastrophique, l'équipe a décidé de réduire massivement le nombre de technologies en production, n'en gardant que quelques-unes que toute l'organisation pouvait pleinement supporter.

L'une des premières décisions fut de migrer toute la plateforme vers PHP et MySQL — un choix avant tout philosophique, non technique : ils voulaient que développeurs comme exploitants comprennent la pile entière, que chacun puisse lire, réécrire et corriger le code des autres. Comme s'en souvient Michael Rembetsy, alors directeur de l'exploitation, « nous avons retiré d'excellentes technologies de la production », dont lighttpd, Postgres, MongoDB, Scala, CoffeeScript et Python. Dan McKinley, développeur de l'équipe qui avait introduit MongoDB, raconte sur son blog que tous les bénéfices d'une base sans schéma furent annulés par les problèmes opérationnels à résoudre — journalisation, graphiques, supervision, télémétrie, sauvegardes et restauration. Verdict : abandon de MongoDB et portage du service vers l'infrastructure MySQL déjà supportée.

Réserver du temps pour l'apprentissage et la dette technique

Codifier le savoir ne suffit pas : encore faut-il réserver explicitement du temps pour s'améliorer. Le système de production Toyota en a fait un rituel, l'improvement blitz (ou kaizen blitz) : une période dédiée et concentrée, souvent de quelques jours, pour s'attaquer à un problème précis. Le Dr Steven Spear le décrit ainsi : « Un groupe se rassemble pour se concentrer intensément sur un processus défaillant… Le blitz dure quelques jours, l'objectif est l'amélioration du processus, et le moyen est l'usage concentré de personnes extérieures au processus pour conseiller celles qui y sont normalement. »

Le principe : une semaine est choisie où tout le monde dans l'organisation technologique travaille en même temps sur une activité d'amélioration — aucun travail de fonctionnalité n'est autorisé. Ces équipes s'étendent sur toute la chaîne de valeur, combinant développement, exploitation et sécurité (Infosec) — des gens qui d'ordinaire ne travaillent pas ensemble. À la fin, chaque équipe présente à ses pairs le problème attaqué et ce qu'elle a construit. Cela renforce la culture du « réparer les problèmes fait partie du travail quotidien » et démontre qu'on valorise le remboursement de la dette technique.

Ce qui rend l'improvement blitz si puissant, c'est qu'il donne à ceux qui sont au plus près du travail le pouvoir d'identifier et de résoudre leurs propres problèmes en continu. On peut filer la métaphore : notre système complexe est comme une toile d'araignée, dont les fils s'affaiblissent et se rompent constamment. Si la bonne combinaison de fils casse, toute la toile s'effondre. Aucun management de type commandement-et-contrôle ne peut diriger les travailleurs pour réparer chaque fil un par un. Il faut au contraire créer la culture et les normes organisationnelles qui amènent chacun à trouver et réparer continuellement les fils brisés dans le cadre du travail quotidien. Comme l'observe le Dr Spear : « Pas étonnant que les araignées réparent les déchirures à mesure qu'elles surviennent, sans attendre que les défaillances s'accumulent. »

Facebook en offre une illustration célèbre. En 2008, avec plus de cent millions d'utilisateurs actifs et une croissance fulgurante, l'entreprise affrontait de graves problèmes de capacité. Lors d'un hack day, Haiping Zhao, ingénieur serveur senior, se mit à expérimenter la conversion de code PHP en C++ compilable. Sur deux ans, une petite équipe en fit le compilateur HipHop, qui permit à la plateforme de supporter une charge six fois supérieure au PHP natif. Drew Paroski, l'un des ingénieurs, témoigne : « Sans HipHop, nous aurions été dans de sales draps. Il nous aurait fallu plus de machines que nous n'aurions pu en obtenir à temps. C'était une passe désespérée qui a réussi. » Plus tard, le même esprit donna naissance à la machine virtuelle HHVM. Mark Zuckerberg le confirme : « Beaucoup de nos produits les plus réussis sont nés de hackathons — Timeline, le chat, la vidéo, notre framework mobile, et une part de notre infrastructure la plus importante comme le compilateur HipHop. »

Permettre à chacun d'enseigner et d'apprendre

Une culture d'apprentissage dynamique crée les conditions pour que chacun puisse non seulement apprendre, mais aussi enseigner — par des méthodes didactiques classiques (cours, formations) comme par des méthodes plus ouvertes (conférences, ateliers, mentorat). Steve Farley, VP de la DSI chez Nationwide Insurance, décrit leur dispositif : « Nous avons cinq mille professionnels de la technologie, que nous appelons des associés. Depuis 2011, nous nous sommes engagés à créer une culture d'apprentissage — dont le Teaching Thursday, où chaque semaine nous dégageons du temps. Pendant deux heures, chaque associé est censé enseigner ou apprendre. Les sujets sont ceux qu'ils choisissent. La chose la plus précieuse qu'un associé puisse faire, c'est mentorer un autre associé ou apprendre de lui. »

Certaines compétences deviennent nécessaires à tous les ingénieurs, pas seulement aux développeurs : gestion de version, tests automatisés, pipelines de déploiement, gestion de configuration, automatisation. La familiarité avec ces techniques aide les ingénieurs d'exploitation à rester pertinents. La perspective d'apprendre peut intimider, mais elle ne le devrait pas. Karthik Gaekwad, de la transformation DevOps de National Instruments, rassure : « Pour les gens de l'exploitation qui essaient d'apprendre l'automatisation, ça ne devrait pas faire peur — demandez simplement à un développeur sympa, il adorera aider. » On enseigne aussi par le travail quotidien : revues de code croisées entre dev et ops, résolution conjointe de petits problèmes, jusqu'à intégrer ensemble un nouveau test automatisé dans le pipeline.

Partager au-delà de l'organisation

Dans beaucoup d'organisations focalisées sur les coûts, on décourage les ingénieurs d'assister aux conférences. Pour bâtir une organisation apprenante, c'est l'inverse qu'il faut faire : les encourager à y assister, à y intervenir, voire à organiser des conférences internes ou externes. DevOpsDays reste l'une des séries de conférences auto-organisées les plus vivantes, gratuite ou presque, portée par une communauté de praticiens. Le DevOps Enterprise Summit, créé en 2014, est organisé autour de retours d'expérience de responsables technologiques engagés dans le voyage DevOps au sein de grandes organisations complexes.

Étude de cas : les conférences internes (2014)

Plusieurs entreprises ont créé leurs propres conférences. Nationwide Insurance, opérant dans des secteurs très régulés, a lancé TechCon en 2011 : « Nous voulions une meilleure façon de nous enseigner à nous-mêmes, tout en garantissant un contexte Nationwide, plutôt que d'envoyer tout le monde à une conférence externe », explique Farley. Capital One a tenu sa première conférence interne d'ingénierie logicielle en 2015 — treize pistes d'apprentissage, cinquante-deux sessions, plus de 1 200 employés. Le Dr Tapabrata Pal, technical fellow, précise : « Nous avions même un hall d'exposition avec vingt-huit stands où des équipes internes montraient leurs réalisations. Nous avons délibérément décidé qu'il n'y aurait aucun fournisseur, pour garder le focus sur les objectifs de Capital One. » Chez Target, Heather Mickman et Ross Clanton ont tenu six DevOpsDays internes depuis 2014, sur le modèle de celui d'ING à Amsterdam ; après le DevOps Enterprise Summit, raconte Clanton, « 2015 fut l'année où nous avons obtenu l'attention des dirigeants et construit notre élan ».

Former des coachs et consultants internes

Créer une organisation interne de coaching et de conseil est une méthode courante pour diffuser l'expertise. Chez Capital One, des experts désignés tiennent des permanences (office hours) où chacun peut les consulter. L'exemple le plus abouti reste le Testing Grouplet de Google. À l'époque, la politique des « 20 % de temps d'innovation » permettait aux développeurs de consacrer environ un jour par semaine à un projet hors de leur périmètre. Certains formaient des grouplets — équipes ad hoc d'ingénieurs partageant les mêmes idées, qui mutualisaient leur temps pour des improvement blitzes ciblés.

Le Testing Grouplet, fondé par Bharat Mediratta et Nick Lesiecki, avait pour mission de généraliser les tests automatisés — sans budget ni autorité formelle. Comme le décrit Mike Bland : « Aucune contrainte explicite ne nous était imposée non plus. Et nous en avons profité. » Leur outil le plus célèbre, Testing on the Toilet (TotT), était un bulletin hebdomadaire publié dans presque toutes les toilettes de presque tous les bureaux Google du monde. Bland : « Le but était d'élever le niveau de connaissance des tests dans toute l'entreprise. Il est douteux qu'une publication en ligne aurait impliqué les gens au même degré. »

Le programme Test Certified fournissait une feuille de route en trois niveaux — établir une mesure de base, fixer un objectif de couverture, viser un objectif à long terme — exploitant délibérément la culture métrique de Google : « les trois niveaux étaient quelque chose dont les gens pouvaient discuter et se vanter au moment des évaluations de performance ». Le grouplet finit par obtenir le financement des Test Mercenaries, une équipe à plein temps de consultants internes appliquant directement leurs outils au code des équipes. Bland : « Ce fut une étape importante, car le management était désormais pleinement impliqué — non par décrets, mais par un financement réel. » Les Fixits — « des sprints d'une journée où des ingénieurs ordinaires, mus par une idée et un sens de la mission, recrutent toute l'ingénierie Google » — généraient l'énergie et l'enthousiasme nécessaires : le dernier mobilisa plus de cent volontaires dans plus de vingt bureaux de treize pays.

Étude de cas : le DevOps Dojo de Target

Chez Target, Ross Clanton, directeur de l'exploitation chargé d'accélérer l'adoption de DevOps, s'appuie sur le Technology Innovation Center, plus connu sous le nom de DevOps Dojo : environ 1 700 mètres carrés d'espace ouvert où des coachs aident les équipes de toute l'organisation à élever leur pratique. Le format le plus intensif, le « défi de 30 jours » (30-Day Challenge), accueille une équipe interne un mois durant. Elle apporte son propre travail, avec l'objectif de résoudre un problème dont elle souffre depuis longtemps et de réaliser une percée en trente jours, en travaillant côte à côte avec les coachs par sprints de deux jours.

Ravi Pandey, manager de développement chez Target, témoigne du changement : « Avant, nous attendions six semaines pour obtenir un environnement de test. Maintenant, nous l'obtenons en minutes, et nous travaillons côte à côte avec des ingénieurs d'exploitation qui nous aident à augmenter notre productivité. » Clanton complète : « Il n'est pas rare que des équipes accomplissent en jours ce qui leur prendrait habituellement trois à six mois. » Le Dojo propose aussi des formats plus légers — Flash Builds d'un à trois jours pour livrer un produit minimum viable (MVP), et Open Labs toutes les deux semaines, ouverts à tous.

À retenir

• Le ChatOps (Hubot chez GitHub) place l'automatisation au cœur de la conversation : tout le monde voit tout, les nouveaux arrivants apprennent par les logs, et le salon devient « la fontaine à eau » qui convertit l'apprentissage local en savoir global.
• Codifier les standards sous forme de code exécutable plutôt que dans des documents Word garantit leur adoption ; « la conformité réelle est proportionnelle au degré auquel les politiques sont exprimées en code » (Arbuckle).
• Un dépôt de code unique et partagé (le monorepo de Google : un milliard de fichiers) propage instantanément les améliorations, donne une connaissance à 100 % des dépendances, et évite le cauchemar des quatre-vingt-une versions vulnérables d'une même bibliothèque.
• Les tests automatisés font office de documentation vivante (surtout en TDD) ; on conçoit pour l'exploitation via des exigences non fonctionnelles codifiées et des user stories Ops réutilisables, et l'on aligne les choix technologiques sur les buts globaux (« des bouées, pas des frontières »).
• Les improvement blitzes (kaizen blitz, hack days) réservent du temps pour rembourser la dette technique — pas pour innover sur le produit — en mobilisant toute la chaîne de valeur, comme l'araignée qui répare sa toile à mesure qu'elle se déchire (Spear).
• Permettre à chacun d'enseigner et d'apprendre — Teaching Thursday chez Nationwide, conférences internes chez Capital One et Target, DevOpsDays — et former des coachs internes (Test Mercenaries de Google, DevOps Dojo de Target) diffusent l'expertise à grande échelle.
• En communiquant activement chaque nouvelle découverte, on élève l'état de la pratique de toute l'organisation, de sorte que quiconque travaille le fasse avec l'expérience cumulée de l'ensemble.