REALITYWIPE

CHRONOLOGIE_DE_RECHERCHE

La science des incidents d'ingénierie et de l'identité : pourquoi c'est rarement la faute d'un coupable

"Qui a cassé la prod ?" 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é · 19832024

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.'

  6. 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é.

  7. 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é.

Voir le dossier de recherche completen chiffresToute la recherche