La Deuxième Voie : les principes du Feedback

Si la Première Voie décrit les principes qui permettent le flux rapide du travail de gauche à droite, la Deuxième Voie décrit ceux qui rendent possible le retour réciproque, rapide et constant, de droite à gauche, à toutes les étapes de la chaîne de valeur (value stream). L'objectif est de bâtir un système de travail toujours plus sûr et plus résilient. Cela importe d'autant plus que nous travaillons dans des systèmes complexes où la première occasion de détecter et de corriger une erreur survient, trop souvent, quand la catastrophe est déjà en cours — l'ouvrier blessé sur la chaîne, le réacteur en fusion, la panne massive en production ou la fuite de données clients.

Nous rendons notre système de travail plus sûr en créant un flux d'information rapide, fréquent et de haute qualité à travers toute la chaîne de valeur et toute l'organisation, sous forme de boucles de rétroaction (feedback) et d'anticipation (feedforward). Cela nous permet de détecter et de corriger les problèmes quand ils sont encore petits, peu coûteux et faciles à résoudre ; d'éviter qu'ils ne dégénèrent en catastrophe ; et de produire un apprentissage organisationnel que nous réinjectons dans le travail futur. Quand surviennent les pannes et les accidents, nous les traitons comme des occasions d'apprendre, et non comme un prétexte à la sanction et au blâme.

Travailler en sécurité dans les systèmes complexes

Une caractéristique déterminante d'un système complexe est qu'il défie la capacité de quiconque à embrasser le système comme un tout et à comprendre comment toutes les pièces s'emboîtent. Ces systèmes présentent un haut degré d'interconnexion entre des composants fortement couplés (tightly-coupled), et leur comportement d'ensemble ne s'explique pas par le seul comportement de leurs composants pris séparément.

Le Dr Charles Perrow, dans son étude de la crise de Three Mile Island, a observé qu'il était impossible à quiconque de comprendre comment le réacteur se comporterait en toutes circonstances ni comment il pourrait défaillir. Lorsqu'un problème naissait dans un composant, il était difficile de l'isoler des autres : il se propageait rapidement par les chemins de moindre résistance, de façon imprévisible. Le Dr Sidney Dekker, qui a par ailleurs codifié certains éléments-clés de la culture de sécurité (safety culture), a relevé une autre propriété : faire deux fois la même chose ne conduit pas nécessairement, ni de façon prévisible, au même résultat. C'est précisément ce qui rend les listes de contrôle statiques et les bonnes pratiques, certes utiles, insuffisantes pour empêcher les catastrophes.

Après avoir décodé le mécanisme causal du système de production Toyota dans sa thèse à la Harvard Business School, le Dr Steven Spear a conclu que concevoir des systèmes parfaitement sûrs dépasse probablement nos capacités, mais que l'on peut rendre le travail plus sûr dans un système complexe lorsque quatre conditions sont réunies :

• le travail complexe est piloté de telle sorte que les problèmes de conception et d'exploitation sont révélés ;
• les problèmes sont essaimés et résolus (swarmed), produisant rapidement de nouvelles connaissances ;
• la nouvelle connaissance locale est exploitée globalement dans toute l'organisation ;
• les dirigeants forment d'autres dirigeants capables de cultiver continuellement ces aptitudes.

Spear a étendu ce constat pour expliquer les succès durables d'autres organisations, comme le réseau de fournisseurs Toyota, Alcoa, ou le programme de propulsion nucléaire de l'US Navy. Ce chapitre développe les deux premières capacités ; les deux dernières relèvent du chapitre suivant.

Voir les problèmes au moment où ils surviennent

Dans un système de travail sûr, nous devons constamment tester nos hypothèses de conception et d'exploitation. L'objectif est d'augmenter le flux d'information depuis le plus grand nombre de zones possibles, plus tôt, plus vite, à moindre coût, et avec le plus de clarté possible entre cause et effet. Plus nous invalidons d'hypothèses, plus vite nous trouvons et corrigeons les problèmes — gagnant en résilience, en agilité et en capacité d'apprendre et d'innover. Nous y parvenons en intégrant des boucles de rétroaction et d'anticipation à notre système de travail. Le Dr Peter Senge, dans The Fifth Discipline, décrivait ces boucles comme une part critique des organisations apprenantes et de la pensée systémique : elles font que les composants d'un système se renforcent ou se contrebalancent les uns les autres.

L'absence de rétroaction efficace est, dans l'industrie, à l'origine de problèmes majeurs de qualité et de sécurité. Le cas bien documenté de l'usine General Motors de Fremont l'illustre : faute de procédures pour détecter les problèmes pendant l'assemblage, et faute de consignes sur la conduite à tenir une fois un problème trouvé, on a vu des moteurs montés à l'envers, des voitures sans volant ni pneus, et même des véhicules qu'il fallait remorquer hors de la chaîne parce qu'ils refusaient de démarrer. À l'inverse, dans les usines performantes, le flux d'information est rapide, fréquent et de haute qualité tout au long de la chaîne : chaque opération est mesurée et surveillée, et tout défaut ou écart significatif est aussitôt repéré et traité.

Dans la chaîne de valeur technologique, les mauvais résultats viennent souvent de l'absence de feedback rapide. Dans un projet en cascade (waterfall), on peut développer du code pendant une année entière sans aucun retour sur la qualité jusqu'à la phase de test — voire jusqu'à la livraison au client. Un retour aussi tardif et aussi rare est trop lent pour empêcher les dénouements indésirables.

Boucle longue (waterfall)
Dév. ──────────────────────────────────────► Test ──► Prod
 (1 an de code)                                 │
                                                ▼ premier feedback : trop tard

Boucle courte (fast feedback)
Dév. ─► build ─► test auto ─► télémétrie prod
  ▲                              │
  └──────── minutes ◄────────────┘  feedback immédiat, à chaque étape

À l'inverse, notre objectif est de créer des boucles de rétroaction rapide partout où le travail s'effectue, à toutes les étapes de la chaîne — gestion produit, développement, assurance qualité (QA), sécurité de l'information (Infosec) et exploitation. Cela passe par des processus automatisés de build, d'intégration et de test, afin de détecter immédiatement qu'un changement nous a sortis d'un état correctement fonctionnel et déployable. Nous créons aussi une télémétrie omniprésente (pervasive telemetry) pour voir comment chaque composant se comporte en production et repérer vite ce qui dévie. Cette télémétrie mesure si nous atteignons nos objectifs et, idéalement, rayonne vers toute la chaîne de valeur, pour que chacun voie comment ses actions affectent le reste du système.

Essaimer et résoudre pour bâtir de la connaissance

Détecter l'inattendu ne suffit pas. Quand un problème survient, nous devons l'essaimer (swarm) — mobiliser sur-le-champ toutes les personnes nécessaires à sa résolution. Selon Spear, le but de l'essaimage est de contenir le problème avant qu'il ne se propage, puis de le diagnostiquer et de le traiter pour qu'il ne puisse plus se reproduire. « Ce faisant, dit-il, on bâtit une connaissance toujours plus profonde de la manière de piloter nos systèmes de travail, convertissant l'ignorance initiale inévitable en savoir. »

Le parangon de ce principe est le cordon Andon de Toyota. Au-dessus de chaque poste de travail pend un cordon que chaque ouvrier et chaque responsable est formé à tirer dès que quelque chose cloche : une pièce défectueuse, une pièce manquante, ou même un travail qui prend plus de temps que documenté. Quand le cordon est tiré, le chef d'équipe est alerté et s'attaque aussitôt au problème ; si celui-ci n'est pas résolu dans un délai imparti (par exemple cinquante-cinq secondes), la chaîne s'arrête (stop the line) pour mobiliser l'organisation entière jusqu'à l'obtention d'une contre-mesure efficace.

Plutôt que de contourner le problème ou de planifier un correctif « quand on aura le temps », on l'essaime pour le corriger immédiatement — l'exact opposé du comportement observé à l'usine GM Fremont. Cette discipline est nécessaire pour trois raisons :

• elle empêche le problème de progresser en aval, là où le coût et l'effort de réparation croissent exponentiellement et où la dette technique (technical debt) s'accumule ;
• elle empêche le poste de démarrer un nouveau travail, qui introduirait vraisemblablement de nouvelles erreurs ;
• elle évite que le même problème ne se reproduise à l'opération suivante (cinquante-cinq secondes plus tard), exigeant encore plus de correctifs.

L'essaimage semble contraire au management courant, puisqu'on laisse délibérément un problème local perturber l'activité globale. Mais c'est ce qui rend l'apprentissage possible. Il prévient la perte d'informations critiques due à l'estompement des souvenirs ou au changement des circonstances — crucial dans les systèmes complexes, où tant de problèmes naissent d'interactions imprévues et idiosyncrasiques entre personnes, processus, produits, lieux et circonstances. Le temps passant, il devient impossible de reconstituer exactement ce qui se jouait au moment de l'incident. L'essaimage relève, dit Spear, du « cycle discipliné de reconnaissance, de diagnostic et de traitement du problème en temps réel… la discipline du cycle de Shewhart — planifier, faire, vérifier, agir — popularisée par W. Edwards Deming, mais accélérée jusqu'à la vitesse supraluminique ».

Dans la chaîne de valeur technologique, nous devons créer l'équivalent du cordon Andon et de la réponse d'essaimage associée. Cela suppose une culture rendant sûr — et même encouragé — de tirer le cordon dès qu'une anomalie survient : qu'il s'agisse d'un incident de production ou d'une erreur plus en amont, comme un changement qui casse le build ou les tests continus. Quand les conditions déclenchent une traction du cordon, on essaime pour résoudre, et on bloque l'introduction de tout nouveau travail tant que l'incident n'est pas réglé. Ce dispositif offre un feedback rapide à toute la chaîne — surtout à la personne dont le changement a provoqué la défaillance —, permet d'isoler et de diagnostiquer vite, et évite les facteurs aggravants qui brouillent le lien de cause à effet. Empêcher l'arrivée de travail neuf est précisément ce qui rend possibles l'intégration et le déploiement continus, équivalents du flux pièce-à-pièce (single-piece flow) dans la chaîne technologique : tout changement qui passe le build et les tests d'intégration part en production, et tout changement qui en fait échouer un déclenche notre cordon Andon.

Pousser sans cesse la qualité vers la source

Nous risquons de perpétuer involontairement des systèmes de travail dangereux par la façon dont nous réagissons aux accidents. Dans les systèmes complexes, ajouter des étapes d'inspection et des processus d'approbation augmente en réalité la probabilité des défaillances futures. L'efficacité d'une approbation décroît à mesure que l'on éloigne la décision du lieu où le travail s'accomplit : non seulement la qualité de la décision baisse, mais le temps de cycle augmente, ce qui affaiblit le lien entre cause et effet et amoindrit notre capacité à apprendre de nos succès comme de nos échecs.

Le tableau suivant oppose les contrôles qualité inefficaces et la démarche que prône la Deuxième Voie.

Inspection a posteriori (à éviter)	Qualité à la source (à privilégier)
Faire exécuter à une autre équipe des tâches manuelles, fastidieuses et faillibles	Automatiser ces tâches pour que l'équipe qui en a besoin les lance à la demande
Exiger l'aval de personnes occupées et éloignées du travail, contraintes de décider sans connaissance suffisante ou de simplement approuver pour la forme (rubber stamp)	Confier la décision à ceux qui font le travail, via la revue par les pairs
Produire de gros volumes de documentation au détail douteux, vite obsolète	Codifier des exigences exécutables, tests automatisés faisant foi
Pousser de gros lots vers des comités spéciaux et attendre leurs réponses	Trouver et corriger les problèmes dans son périmètre, au quotidien

Au lieu de cela, nous attendons de chacun dans la chaîne de valeur qu'il trouve et corrige les problèmes de son périmètre dans le cadre du travail quotidien. Nous repoussons ainsi la responsabilité et la décision de qualité et de sécurité là où le travail s'effectue, plutôt que de dépendre de l'aval d'exécutifs lointains. Nous recourons à la revue par les pairs (peer review) de nos changements proposés pour gagner l'assurance qu'ils opéreront comme prévu, et nous automatisons autant que possible les vérifications habituellement réalisées par un département QA ou Infosec. Au lieu de demander ou de planifier l'exécution d'un test, les développeurs le lancent à la demande, testant leur propre code et déployant eux-mêmes leurs changements.

Faire partager aux développeurs la responsabilité de la qualité des systèmes qu'ils bâtissent améliore non seulement les résultats, mais accélère l'apprentissage — décisif pour eux, qui sont d'ordinaire l'équipe la plus éloignée du client. Comme l'observe Gary Gruver : « Il est impossible pour un développeur d'apprendre quoi que ce soit quand on lui crie dessus pour quelque chose qu'il a cassé il y a six mois — voilà pourquoi il faut donner du feedback à chacun le plus vite possible, en minutes, pas en mois. »

Optimiser pour les postes en aval

Dans les années 1980, les principes de conception pour la fabricabilité (Designing for Manufacturability) cherchaient à concevoir pièces et procédés afin d'obtenir des produits finis au coût le plus bas, à la qualité la plus haute et au flux le plus rapide : des pièces volontairement asymétriques pour qu'on ne puisse pas les monter à l'envers, des vis impossibles à trop serrer. C'était une rupture avec une conception centrée sur le seul client externe, négligeant les parties prenantes internes — ceux qui fabriquent.

Le lean distingue deux types de clients pour lesquels concevoir : le client externe (qui paie le service) et le client interne (qui reçoit et traite notre travail juste après nous). Selon le lean, notre client le plus important est notre étape suivante en aval. Optimiser pour lui exige de l'empathie pour ses problèmes, afin de mieux repérer les défauts de conception qui entravent un flux rapide et fluide.

Dans la chaîne de valeur technologique, optimiser pour les postes en aval, c'est concevoir pour l'exploitabilité (designing for operations) : les exigences non fonctionnelles d'exploitation — architecture, performance, stabilité, testabilité, configurabilité, sécurité — sont priorisées aussi haut que les fonctionnalités utilisateur. On crée ainsi la qualité à la source, sous la forme d'un jeu d'exigences non fonctionnelles codifiées que l'on intègre proactivement à chaque service que nous bâtissons.

À retenir

• Dans les systèmes complexes, où la défaillance est inhérente et inévitable (Perrow, Dekker), les listes de contrôle ne suffisent pas : il faut concevoir un système de travail sûr où l'on œuvre sans crainte et où les erreurs sont détectées tôt, avant la catastrophe.
• Voir les problèmes au moment où ils surviennent suppose des boucles de feedback courtes — build, intégration et tests automatisés, plus une télémétrie omniprésente qui rayonne vers toute la chaîne de valeur — à l'opposé du feedback tardif du waterfall.
• Essaimer et résoudre (swarming) contient le problème avant qu'il ne se propage et bâtit de la connaissance ; le cordon Andon de Toyota en est le modèle : arrêter la chaîne (stop the line) plutôt que laisser le défaut filer en aval.
• L'équivalent technologique du cordon Andon bloque tout nouveau travail tant qu'un build ou un test cassé n'est pas réparé — c'est ce qui rend possible le flux pièce-à-pièce de l'intégration et du déploiement continus.
• Pousser la qualité vers la source : multiplier les inspections et approbations en aval aggrave les défaillances ; mieux vaut la revue par les pairs et l'automatisation, pour faire de la qualité l'affaire de tous plutôt que celle d'un département distinct.
• Méfiance envers les comités déconnectés et les gros lots d'approbation : éloigner la décision du travail dégrade sa qualité, allonge le cycle et affaiblit le lien cause-effet — « le feedback en minutes, pas en mois » (Gruver).
• Optimiser pour les postes en aval, c'est concevoir pour l'exploitabilité dès le développement : traiter le poste suivant comme notre client le plus important et hisser les exigences non fonctionnelles au rang des fonctionnalités.