Quatorze catastrophes logicielles majeures des dix dernières années, et pas une ligne d’IA dedans. Des ports ouverts sans mot de passe, des identifiants par défaut, des sauvegardes que personne n’avait jamais testées.
Nous n’avons en réalité jamais fait confiance aux développeurs, mais à une chaîne de revues, de tests et de post-mortems. Toute la question est de savoir ce qu’elle attrape encore, et à quel prix.
Analyse1 septembre 2026Par Anthony Capirchio15 min lecture
Opérateur de perforatrice, 1950. Domaine public (National Archives, États-Unis).
En octobre 2021, un journaliste découvre plus de 100 000 numéros de sécurité sociale d’enseignants dans le code source d’un site web de l’État du Missouri. Sa technique d’intrusion : la touche F12 de son navigateur. Le gouverneur promet des poursuites contre ce « hacker » coupable d’avoir « décodé le code source par un processus en plusieurs étapes ». Le processus en plusieurs étapes s’appelle « afficher la page ».
Il n’y a pas d’intelligence artificielle dans cette histoire. Il n’y en a dans aucune de celles qui suivent.
Pourtant, la question qui revient aujourd’hui dans toutes les organisations qui déploient des outils de génération de code est toujours la même : peut-on faire confiance à du code écrit par une machine ? La question est légitime. Elle repose simplement sur un présupposé qui ne survit pas à dix minutes d’archives : l’idée qu’avant, la confiance allait de soi.
Dix ans de catastrophes, zéro IA
Prenez les incidents logiciels les plus connus des dix dernières années. Laissez de côté les attaques sophistiquées d’États et les zero-days d’orfèvre : gardez les catastrophes ordinaires, celles qui ont fait la une. Elles se rangent presque toutes dans six familles de bêtises structurelles.
Le port ouvert sur Internet, sans authentification. En 2015, la Jeep Cherokee expose un port de son système embarqué avec un service tournant en root, sans authentification : deux chercheurs pilotent la direction et les freins à distance. Entre 2015 et 2017, des dizaines de milliers de bases MongoDB écoutent sur Internet sans mot de passe, configuration par défaut : en janvier 2017, plus de 33 000 d’entre elles sont effacées et rançonnées par de simples scripts. On en recensait encore 3 100 exposées sans restriction d’accès en janvier 2026.
L’identifiant par défaut. Le botnet Mirai (2016) n’exploite aucune faille : il essaie 62 couples identifiant/mot de passe du type root/root et admin/admin, enrôle 380 000 appareils et fait tomber une partie de l’Internet américain. Ses auteurs sont trois étudiants. Chez Equifax (2017), pendant que 147,9 millions de dossiers fuient par une faille non corrigée, le portail argentin de l’entreprise est protégé par admin/admin. SolarWinds a laissé « solarwinds123 » traîner dix-sept mois sur un dépôt GitHub public. Colonial Pipeline s’est arrêté à cause d’un compte VPN sans second facteur.
La donnée sensible en évidence. Le Missouri, donc. Mais aussi First American Financial (2019) : 885 millions de documents accessibles par simple incrément d’URL, faille connue en interne des mois avant sa révélation. Ou Optus (2022) : une API publique sans authentification, corrigée sur le domaine principal en 2021, jamais sur le domaine secondaire. 9,8 millions de clients.
La faute de première année. CrowdStrike (2024) : un template attend 21 champs, le code en fournit 20, la lecture hors limites met à terre 8,5 millions de machines Windows. L’écart a traversé plusieurs couches de validation et de tests. L’incident est postérieur à ChatGPT et n’a strictement rien à voir avec l’IA. Cloudflare (2019) : une expression régulière à backtracking catastrophique sature les CPU du réseau mondial pendant 27 minutes ; la protection qui aurait dû limiter les dégâts avait été retirée par erreur lors d’un refactoring… destiné à réduire la consommation CPU.
La commande unique qui coule tout. Facebook (2021) : une commande de maintenance erronée, un outil d’audit censé la bloquer mais lui-même bogué, et l’entreprise s’efface d’Internet, au point que ses employés ne peuvent plus badger pour entrer dans leurs propres salles serveurs. GitLab (2017) : un rm -rf sur le mauvais serveur, 300 Go effacés, et surtout la découverte que pas une seule des cinq techniques de sauvegarde déployées ne fonctionnait.
Le classique. macOS High Sierra (2017) : tapez « root », laissez le mot de passe vide, cliquez deux fois. Vous êtes administrateur.
Trois constats traversent ces quatorze incidents. Aucune de ces catastrophes n’était sophistiquée : un correctif appliqué à temps, un mot de passe changé, un port fermé auraient suffi dans presque tous les cas. Les défaillances sont organisationnelles : un correctif oublié sur un domaine pendant quatre ans, une faille documentée en interne sans suite, cinq systèmes de sauvegarde jamais testés, autant de défauts de chaîne. Et la bêtise survit à toutes les vagues technologiques : si l’IA avait introduit une classe de bug inédite, nous saurions la nommer. Nous ne le savons pas, parce qu’elle n’existe pas.
“
Quatorze catastrophes, aucune sophistiquée, aucune écrite par une machine. La constante n’est pas la technologie, c’est l’organisation.
Les bugs n’ont donc pas attendu l’IA. Ce qui est nouveau, c’est autre chose : notre intolérance. La même erreur, commise par un humain, se pardonne ; commise par une machine, elle disqualifie. Cette asymétrie est mesurée depuis vingt ans, et elle a deux étages : un étage psychologique et un étage comptable.
Premier étage : la machine n’a pas droit à l’erreur
L’expérience fondatrice date de 2015. Berkeley Dietvorst, Joseph Simmons et Cade Massey, à Wharton, font travailler des participants avec deux prévisionnistes : un humain et un algorithme. Résultat central : après avoir vu les deux commettre la même erreur, les participants perdent confiance beaucoup plus vite dans l’algorithme que dans l’humain, et continuent de le fuir même lorsqu’il reste objectivement plus performant. Les auteurs baptisent le phénomène aversion algorithmique. Deux ans plus tard, Prahl et Van Swol isolent le mécanisme dans sa forme la plus pure : tant que personne ne se trompe, les participants suivent indifféremment le conseiller humain ou le conseiller machine ; dès qu’un conseil erroné identique est délivré par les deux, seule la machine est sanctionnée. Conseil identique, erreur identique, punition différente.
La recherche sur les facteurs humains explique cette asymétrie par ce qu’elle appelle le schéma d’automatisation parfaite, décrit par Dzindolet dès 2002 puis formalisé par Madhavan et Wiegmann : nous abordons les machines avec deux croyances implicites, des attentes de performance très élevées et une pensée en tout ou rien. La conséquence est contre-intuitive : avant tout incident, la confiance accordée à un système automatisé est souvent supérieure à celle accordée à un humain. Mais cette confiance initiale est fragile par construction. L’erreur humaine confirme notre modèle du monde (l’humain est faillible, tout le monde le sait) ; l’erreur machine brise un schéma (la machine devait être parfaite). Une erreur attendue s’absorbe. Une erreur qui contredit le modèle mental disqualifie : « le système s’est trompé » devient « le système est cassé ».
Trois circonstances aggravantes s’ajoutent. D’abord, une fois le schéma brisé, nous surestimons durablement le taux d’erreur réel du système : la mémoire de l’incident pèse plus lourd que la statistique. Ensuite, et c’est le point qui devrait intéresser toute personne ayant lu le corpus ci-dessus : ce sont les erreurs faciles qui détruisent le plus la confiance. Madhavan, Wiegmann et Lacson l’ont montré expérimentalement en 2006 : une aide automatisée qui échoue sur une tâche qu’un humain réussit sans effort est jugée globalement incompétente, bien plus sévèrement qu’une aide qui échoue sur une tâche difficile. Voilà pourquoi une bourde triviale générée par IA fait le tour des réseaux en quelques heures, quand vingt ans d’admin/admin n’ont disqualifié personne. Le corpus de cet article est composé exclusivement d’erreurs faciles. C’est précisément la catégorie d’erreur que nous pardonnons sans fin aux humains, et jamais aux machines.
Enfin, la barre que nous fixons à la machine est celle de l’humain que nous croyons être. Le terrain le mieux documenté est le véhicule autonome. Les études d’acceptabilité convergent : le public exige d’une voiture autonome qu’elle fasse plusieurs fois mieux que le conducteur moyen ; des travaux situent le seuil d’adoption à quatre ou cinq fois la sûreté humaine, et le comité d’éthique des données britannique notait qu’aligner l’exigence sur celle du train ou de l’avion supposerait de faire cent fois mieux que le conducteur moyen. Une vaste étude de 2021 (plus de 4 500 participants) identifie le ressort : l’aversion algorithmique se combine à l’effet « meilleur que la moyenne » ; plus les gens se jugent bons conducteurs, plus ils exigent de la machine. Transposez au développement logiciel, domaine où personne ne se pense en dessous de la moyenne : le développeur qui évalue du code généré le compare à l’image qu’il a de lui-même, loin de la production humaine réelle du corpus ci-dessus.
Reste la couche sociale, inscrite dans l’architecture même de nos organisations : l’erreur humaine a un récit (la fatigue, le délai, le contexte) et surtout un responsable, quelqu’un qui peut rendre des comptes, s’excuser, promettre de faire mieux. Notre tolérance à l’erreur humaine est adossée à cette possibilité de recours. L’erreur machine paraît sans visage et sans excuse : on ne convoque pas un modèle de langage en comité de crise. Là où il n’y a personne à qui pardonner, il n’y a pas de pardon.
Second étage : une intolérance comptable
Il serait confortable de s’arrêter là et de conclure que notre sévérité envers les machines n’est qu’un biais à corriger. Ce serait rater la moitié du sujet. Car l’exigence de quasi-perfection envers l’automatisation a aussi un fondement parfaitement rationnel : l’économie de la délégation.
L’erreur humaine est déjà dans le prix. Toute organisation paie, depuis toujours, une infrastructure complète de rattrapage de l’humain : encadrement, revue de code, QA, recette, audit, contrôle de gestion. Ces coûts sont si anciens et si diffus qu’ils sont devenus invisibles : personne ne les impute à la « non-qualité humaine », ils s’appellent masse salariale et organigramme. Quand un humain se trompe, le coût de sa surveillance était provisionné.
L’automatisation, elle, est vendue sur la promesse inverse. Le business case d’un outil de génération de code, d’un agent, d’une chaîne automatisée repose précisément sur le travail de supervision qu’on n’aura plus à faire. Chaque erreur de la machine réintroduit donc exactement le coût que l’investissement devait supprimer : il faut relire, vérifier, tester, reprendre. L’erreur machine abîme le livrable, et elle attaque aussi la rentabilité de la délégation elle-même. Nous ne pardonnons pas à la machine parce que sa fiabilité est le produit même que nous avons acheté.
Ce point d’équilibre est quantifié. En 2007, Wickens et Dixon compilent vingt études expérimentales sur les aides diagnostiques automatisées et trouvent un point de bascule net : en dessous d’environ 70 % de fiabilité, travailler avec l’automatisation donne de moins bons résultats que travailler sans elle. Une perte nette, parce que le coût de surveillance et de rattrapage dépasse le bénéfice de l’aide. La fiabilité est la condition d’existence économique de l’automatisation. Et Lisanne Bainbridge avait décrit dès 1983, dans ses « ironies de l’automatisation », le piège structurel qui s’ensuit : plus on automatise, plus ce qui reste à l’humain est ingrat et difficile, surveiller un système qui fonctionne presque toujours et rattraper ses défaillances rares. Tâche pour laquelle nous sommes notoirement mauvais, et qu’automatiser davantage déplace sans la réduire.
“
« Le concepteur qui cherche à éliminer l’opérateur lui laisse encore à faire les tâches qu’il n’a pas su automatiser. »
Lisanne Bainbridge, Ironies of Automation, 1983
Le plus dangereux dans ce coût de vérification est qu’il est invisible à celui qui le paie. À l’été 2025, l’organisme METR publie un essai randomisé contrôlé sur seize développeurs open source expérimentés et 246 tâches réelles : autorisés à utiliser les outils d’IA, ils mettent en moyenne 19 % de temps en plus pour livrer, tout en restant persuadés, après coup, d’avoir été environ 20 % plus rapides. METR a depuis relativisé la portée du chiffre lui-même (les vagues suivantes de l’étude souffrent d’effets de sélection), mais le résultat qui a tenu est l’écart entre perception et mesure : près de quarante points. Personne ne sent le temps qu’il passe à vérifier. Les données d’usage racontent la même histoire à l’échelle des équipes : là où le volume de code fusionné explose, le temps de revue enfle presque d’autant, et les enquêtes développeurs placent en tête des frustrations les solutions « presque justes », celles qui coûtent plus cher à corriger qu’à réécrire.
L’intolérance envers l’erreur machine est donc à la fois un biais et un calcul. Le biais fixe la barre à la perfection ; le calcul exige que la vérification coûte moins que le travail délégué, sans quoi l’automatisation détruit de la valeur. Et les deux étages convergent vers une même question, que presque aucune organisation ne s’est jamais posée frontalement : combien coûte, chez vous, la production de confiance ?
La confiance n’a jamais reposé sur l’auteur
Car c’est le point aveugle de toute la discussion : nous n’avons jamais réellement fait confiance aux développeurs. Aucune organisation sérieuse ne met en production du code au motif que son auteur est quelqu’un de bien. Ce à quoi nous faisons confiance, quand le système fonctionne, c’est à une chaîne : des revues, des tests, des environnements d’intégration, des déploiements progressifs, des post-mortems. La chaîne est la réponse historique au problème économique du paragraphe précédent : elle mutualise et industrialise le coût de vérification. Elle le transforme de coût variable (chaque livrable inspecté artisanalement par quelqu’un) en coût fixe (des mécanismes qui inspectent tout, tout le temps, au même prix).
Le corpus permet de distinguer deux régimes de cette chaîne. Chez CrowdStrike, les couches de validation existaient et l’écart les a toutes traversées : des contrôles qui n’attrapent rien, du rituel de conformité, ce que nous appelons ici de la friction parasite. Chez GitLab, à l’inverse, la catastrophe a bien eu lieu, six heures de données perdues définitivement ; mais le post-mortem intégralement public et la restauration diffusée en direct ont été largement salués, au point de devenir un cas d’école de transparence. Même portante, la friction laisse passer des accidents ; elle garantit qu’ils enseignent quelque chose, et que le système peut le prouver.
La recherche sur l’aversion algorithmique éclaire d’ailleurs la sortie du piège. Dans une seconde série d’expériences (2018), Dietvorst et ses collègues montrent que les participants recommencent à utiliser un algorithme imparfait dès qu’on leur donne la possibilité, même marginale, d’ajuster ses sorties. C’est le contrôle qui ramène la confiance. Transposé à nos organisations : on fera durablement confiance à une chaîne de production largement automatisée si elle expose des points de contrôle dont on peut vérifier qu’ils attrapent ce qu’ils doivent attraper. Jurer que le modèle est fiable n’y suffira jamais.
L’IA écrit des bugs, comme tout le monde. La bonne question est double, à l’image des deux étages : votre chaîne est-elle capable d’attraper les défauts, quel que soit leur auteur ? Et le fait-elle à un coût inférieur à la valeur de ce que vous déléguez ? Une organisation qui répond oui aux deux peut absorber du code généré sans trembler. Une organisation qui répond non n’était déjà pas en état de faire confiance à ses humains ; elle ne le mesurait simplement pas, parce que le coût en était dilué dans la masse salariale.
Ce que l’IA change vraiment
L’IA n’a pas inventé les bugs. Elle a changé deux choses : le débit, et la visibilité du prix de la confiance.
Le débit d’abord. Imaginons une équipe qui passe, grâce à la génération de code, de dix évolutions par semaine à cinquante. Chaque maillon décoratif de la chaîne, chaque revue expédiée, chaque test qui ne teste rien était tolérable à faible volume : le nombre limité de changements laissait aux humains le temps de compenser informellement. À haut débit, la compensation informelle ne suit plus. Ce qui était un défaut latent devient une défaillance visible.
Le prix ensuite. Tant que la vérification était un geste humain diffus, noyé dans les salaires et les rituels, aucune direction n’avait à la financer explicitement. L’automatisation la fait apparaître en pleine lumière : chaque heure passée à relire du code généré est une ligne que le business case de l’outil n’avait pas prévue. La confiance cesse d’être un sentiment pour devenir un poste comptable. C’est inconfortable, et c’est une excellente nouvelle : ce qui a un coût mesurable peut enfin être industrialisé, arbitré, amélioré.
C’est la thèse de ce magazine appliquée à la qualité logicielle : l’IA ne crée pas le dysfonctionnement, elle le révèle. Les organisations qui découvrent aujourd’hui qu’elles « ne peuvent pas faire confiance au code de l’IA » découvrent en réalité qu’elles n’ont jamais construit les mécanismes qui produisent de la confiance, pour personne, et qu’elles n’en ont jamais connu le prix. Le corpus ci-dessus en est la démonstration empirique sur dix ans ; la psychologie expérimentale explique pourquoi nous ne l’avons pas vu ; l’économie de l’automatisation explique pourquoi nous ne pouvons plus l’ignorer.
Ralentir la machine ou attendre qu’elle devienne parfaite ne mène nulle part : le schéma d’automatisation parfaite est précisément le piège. La suite logique est d’industrialiser enfin ce qui aurait dû l’être depuis longtemps : des contrôles qui contrôlent, des sauvegardes qui restaurent, des post-mortems qui circulent, et un coût de vérification connu, budgété, décroissant. Les équipes qui feront ce travail pourront déléguer massivement, à des machines comme à des humains. Les autres continueront de débattre de la confiance en regardant leurs ports ouverts.
Aversion algorithmique : Dietvorst, Simmons & Massey, Algorithm Aversion : People Erroneously Avoid Algorithms After Seeing Them Err, Journal of Experimental Psychology : General, 2015 (PubMed) et Overcoming Algorithm Aversion, Management Science, 2018 ; Prahl & Van Swol, Understanding algorithm aversion : When is advice from automation discounted ?, Journal of Forecasting, 2017.
Schéma d’automatisation parfaite : Dzindolet et al., 2002, puis Madhavan & Wiegmann, Similarities and differences between human-human and human-automation trust, Theoretical Issues in Ergonomics Science, 2007 ; Merritt et al., Measuring Individual Differences in the Perfect Automation Schema, Human Factors, 2015 (Sage) ; Madhavan, Wiegmann & Lacson, Automation Failures on Tasks Easily Performed by Operators Undermine Trust in Automated Aids, Human Factors, 2006 (Sage) ; Hoff & Bashir, Trust in Automation, Human Factors, 2015 (surestimation du taux d’erreur perçu).
Exigence de sûreté envers la machine : Liu, Yang & Xu, How Safe Is Safe Enough for Self-Driving Vehicles ?, Risk Analysis, 2019 (PubMed) ; How safe is safe enough ? Psychological mechanisms underlying extreme safety demands for self-driving cars, Transportation Research Part C, 2021 (ScienceDirect) ; Centre for Data Ethics and Innovation (Royaume-Uni), 2022, via BBC News (facteur 100 pour une exigence alignée sur le train ou l’avion).
Économie de la supervision : Wickens & Dixon, The benefits of imperfect diagnostic automation : a synthesis of the literature, Theoretical Issues in Ergonomics Science, 2007 (seuil de fiabilité de 0,70) ; Bainbridge, Ironies of Automation, Automatica, 1983.
Mesures d’usage : METR, essai randomisé contrôlé, juillet 2025 (The Register) et nuances méthodologiques ultérieures, février 2026 (ScienceBlog) ; volume de pull requests contre temps de revue et frustrations développeurs (synthèse).
Le diagnostic est posé : l’IA ne crée pas la dette organisationnelle, elle la rend exigible. Restait à écrire la suite : comment on rembourse. Cet article transpose l’appareil du redressement financier à l’organisation : des covenants plutôt qu’un inventaire, trois régimes de remboursement, un triage entre avalanche et boule de neige, et l’option que personne n’ose, la restructuration. Un plaidoyer pour tenir un registre de dettes organisationnel au même rang que le registre des risques.
L’ère de l’interface comme « cache-misère » de la complexité organisationnelle touche à sa fin. Avec l’agentique, le design quitte la surface de l’écran pour la structure du contrat, où seule la clarté sémantique fait foi. Un plaidoyer pour passer du dessin de parcours à l’architecture de modèles métier solides.
L’essor des agents IA révèle et amplifie un besoin ancien : savoir manager. La valeur de l’IA se joue dans la capacité à organiser, déléguer et piloter son utilisation.
