DOSSIER_DE_RECHERCHE
La science des incidents d'ingénierie et de l'identité
"Qui a cassé la prod ?"
VOIR LA PRATIQUE
Transforme une pensée expliquée par cette recherche en un geste clair.
LA PENSÉE
“Corriger les petits bugs se sent comme réarranger les chaises longues du Titanic”
TA RÉPONSE ENREGISTRÉE
“Ce bug peut être corrigé. La forme du système est distincte.”
UN PAS PRIVÉ
Trouve un petit bug dans le code qui n'a pas de dépendances architecturales—une faute de frappe, un message d'erreur, un contrôle nul manquant. Corrige-le complètement, y compris un test. Envoie-le en tant que PR sans justifier pourquoi tu n'as pas corrigé le système entier. Ne…
semble être la bonne question après une panne. La recherche sur les systèmes donne une réponse moins satisfaisante mais bien plus utile : les systèmes complexes échouent par l'alignement de nombreuses petites conditions, pas par un seul acteur imprudent (Reason 1990 ; Google SRE 2016). Pendant ce temps, les personnes les plus responsables du bon fonctionnement de ces systèmes — celles qui font le travail d'infrastructure, les astreintes et le travail de liant — sont systématiquement sous-reconnues (Champion et al. 2024). Et maintenant une nouvelle menace pour l'identité s'y ajoute : les outils d'IA qui promettent de remplacer les ingénieurs sont dignes de confiance pour une minorité décroissante de développeurs (Stack Overflow 2025). Le vieux scénario — 'quelqu'un ici est le coupable' — est presque toujours mal interprété.
Comment la science a changé
- 1983
The Managed Heart d'Arlie Hochschild forge le concept de travail émotionnel — un travail qui exige de gérer ses émotions dans le cadre de son emploi mais qui n'est comptabilisé dans aucune comptabilité formelle. Le concept ancre plus tard la recherche sur le travail de liant invisible dans les équipes logicielles. ↗
- 1990
James Reason publie Human Error, introduisant le modèle du fromage suisse de la causalité des accidents : les défaillances surviennent quand les trous dans plusieurs couches défensives s'alignent, pas parce qu'une personne a fait une erreur. Le modèle devient fondamental pour l'aviation, la médecine et, plus tard, la fiabilité logicielle. ↗
- 2006
The Field Guide to Understanding Human Error de Sidney Dekker recadre 'l'erreur humaine' comme un symptôme, pas une cause — l'ingénieur qui a cliqué sur le mauvais bouton l'a fait au sein d'un système qui permettait ou encourageait cette action. La recherche de coupable, argue Dekker, arrête les enquêtes au mauvais niveau. ↗
- 2012
John Allspaw et Jesse Robbins popularisent les post-mortems sans reproche chez Etsy, arguant que les ingénieurs qui craignent les sanctions cachent des informations — et les informations cachées tuent la fiabilité. Leur approche influence ensuite la pratique du Site Reliability Engineering de Google. ↗
- 2016
Google publie son SRE Book, consacrant un chapitre entier à la culture des post-mortems. Le chapitre codifie l'absence de reproche comme politique organisationnelle : 'les objectifs principaux de la rédaction d'un post-mortem sont de s'assurer que l'incident est documenté, que toutes les causes profondes contributives sont comprises et que des actions préventives efficaces sont mises en place.' ↗
- 2018
Forsgren, Humble et Kim publient Accelerate, mettant en corrélation les pratiques organisationnelles avec les performances de livraison logicielle de milliers d'équipes. Leurs données montrent que les équipes performantes se distinguent non pas par des héros sans faute, mais par la sécurité psychologique, des boucles de rétroaction rapides et une propriété distribuée de la fiabilité. ↗
- 2024
Champion et al. publient une vaste étude empirique sur le travail invisible dans les écosystèmes logiciels open source : la maintenance de l'infrastructure, la documentation, la révision du code et la gestion de la communauté sont systématiquement sous-reconnues par rapport aux commits de fonctionnalités — et cet écart pénalise les ingénieurs qui se spécialisent dans la fiabilité plutôt que dans la nouveauté. ↗
Ce que les gens croient vs. ce que montrent les données
La croyance“Quand un incident de production survient, il y a toujours une cause fondamentale et une personne responsable.”
Les donnéesLe modèle du fromage suisse de Reason et le guide de terrain de Dekker montrent tous deux que les défaillances de systèmes complexes nécessitent l'alignement simultané de plusieurs trous dans plusieurs couches défensives. Le SRE Book de Google rejette explicitement la pensée de cause fondamentale unique : les incidents sont le produit de conditions latentes, pas de coupables individuels. ↗
La croyance“Si vous voulez de la responsabilisation après un incident, quelqu'un doit être blâmé et puni.”
Les donnéesAllspaw et Robbins ont documenté l'inverse : la peur des sanctions pousse les ingénieurs à retenir des informations, ce qui rend les incidents futurs plus probables. Le cadre de post-mortem sans reproche de Google montre que la vraie responsabilisation — causes documentées, corrections du système, actions préventives — est en réalité incompatible avec le blâme individuel. ↗
La croyance“Les ingénieurs qui travaillent sur l'infrastructure, les astreintes et la documentation font un travail moins précieux que ceux qui livrent des fonctionnalités visibles.”
Les donnéesL'étude empirique de Champion et al. de 2024 sur les écosystèmes open source a montré que la maintenance de l'infrastructure, la documentation et la révision du code sont systématiquement sous-reconnues bien qu'elles soient le fondement sur lequel s'appuient les fonctionnalités visibles. Les données Accelerate de Forsgren et al. montrent que le travail de fiabilité — pas seulement la vélocité des fonctionnalités — prédit la haute performance organisationnelle. ↗
La croyance“La bonne réponse à un incident est de trouver la personne d'astreinte et de la tenir responsable.”
Les donnéesLe cadre de post-mortem SRE de Google sépare explicitement la personne qui répond des conditions permettant la défaillance. L'ingénieur d'astreinte est souvent celui qui a mis le problème en lumière, pas celui qui a créé les conditions. Le traiter comme la cause décourage les futurs répondants de s'engager honnêtement. ↗
La croyance“Les outils de codage IA sont maintenant suffisamment fiables pour que les ingénieurs qui s'inquiètent d'être remplacés par l'IA soient irrationnels.”
Les donnéesL'enquête Stack Overflow Developer Survey 2025 a révélé que la confiance des développeurs dans les sorties d'IA est à un niveau historiquement bas — la majorité des développeurs ne fait pas entièrement confiance au code généré par l'IA. L'anxiété face aux outils d'IA est une réponse professionnelle bien fondée à une technologie immature commercialisée comme mature. ↗
TESTE-TOI · Connais-tu vraiment cette science ?
01 Que dit le modèle du fromage suisse de James Reason sur la façon dont les systèmes complexes échouent ?
Le modèle de Reason montre que les défaillances de systèmes complexes sont multicausales : une série de trous dans des couches défensives autrement robustes doit s'aligner pour qu'un accident atteigne son résultat. Aucune personne seule ne crée tous les trous. source ↗
02 Selon le chapitre du SRE Book de Google sur la culture des post-mortems, quel est l'objectif principal d'un post-mortem sans reproche ?
Le SRE Book de Google indique que les objectifs principaux d'un post-mortem sont de s'assurer que l'incident est documenté, que toutes les causes profondes contributives sont comprises et que des actions préventives efficaces sont mises en place — pas d'attribuer la faute à des individus. source ↗
03 Qu'a trouvé l'étude de Champion et al. de 2024 sur le travail d'infrastructure et de liant dans les écosystèmes logiciels open source ?
Champion et al. ont constaté que la maintenance de l'infrastructure, la documentation, la révision du code et la gestion de la communauté sont structurellement invisibles dans la plupart des systèmes de reconnaissance — malgré leur rôle essentiel au fonctionnement de l'écosystème — tandis que les commits de fonctionnalités attirent un crédit disproportionné. source ↗
04 Selon l'enquête Stack Overflow Developer Survey 2025, qu'arrive-t-il à la confiance des développeurs dans le code généré par IA ?
L'enquête Stack Overflow Developer Survey 2025 a trouvé la confiance des développeurs dans les sorties d'IA à un niveau historiquement bas — la majorité des développeurs ne fait pas entièrement confiance au code généré par l'IA, malgré la prolifération rapide des outils de codage IA. source ↗
05 Qu'ont trouvé Allspaw et Robbins sur l'effet de la culture du blâme sur les enquêtes sur les incidents d'ingénierie ?
Allspaw et Robbins ont documenté que la peur des sanctions pousse les ingénieurs à cacher des informations sur ce qui s'est passé lors d'un incident. Ces informations cachées empêchent l'organisation de comprendre et de corriger les conditions réelles — rendant le prochain incident plus probable. source ↗