Dix ans de catastrophes, zéro IA
Prenez les incidents logiciels les plus connus de la décennie qui précède la généralisation des assistants de code. Pas les attaques sophistiquées d'États, pas les zero-days d'orfèvre : 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 trouvait encore 3 100 exposées en 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, pas techniques : 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 ; des défauts de chaîne, pas de syntaxe. Et la bêtise survit à toutes les vagues technologiques : si l'IA avait introduit une classe de bug véritablement 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 n'est pas une impression de couloir. Elle 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.
Pourquoi cette asymétrie ? La recherche sur les facteurs humains l'explique 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 : ce n'est plus « le système s'est trompé », c'est « 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 n'est pas celle de l'humain réel : c'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 n'exige pas d'une voiture autonome qu'elle fasse mieux que le conducteur moyen, il exige qu'elle fasse plusieurs fois mieux ; 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é ne le compare pas à la production humaine réelle, celle du corpus ci-dessus. Il le compare à l'image qu'il a de lui-même.
Reste la couche sociale, qui n'est pas un biais mais une architecture : 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 n'abîme pas seulement le livrable. Elle attaque la rentabilité de la délégation elle-même. Nous ne pardonnons pas à la machine parce que sa fiabilité n'est pas une qualité d'agrément : c'est le produit que nous avons acheté.
Ce point d'équilibre n'est pas une intuition, il 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. Pas un demi-gain : une perte nette, parce que le coût de surveillance et de rattrapage dépasse le bénéfice de l'aide. La fiabilité n'est pas un raffinement de l'automatisation ; c'est sa condition d'existence économique. 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 qui ne se réduit pas en automatisant davantage : elle se déplace.
“
« 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 la ligne éditoriale de ce magazine appelle 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 produit un effet paradoxal : la confiance dans l'entreprise en est sortie renforcée. La friction portante ne garantit pas l'absence d'accident. Elle garantit que l'accident enseigne 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. La confiance ne revient pas par la promesse de perfection. Elle revient par le contrôle. Transposé à nos organisations : personne ne fera durablement confiance à une chaîne de production largement automatisée parce qu'on lui jure que le modèle est fiable. On lui fera confiance parce qu'elle expose des points de contrôle dont on peut vérifier qu'ils attrapent ce qu'ils doivent attraper.
La bonne question n'est donc pas « l'IA écrit-elle des bugs ? ». Elle en écrit, 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. Là où une équipe produisait dix évolutions par semaine, la génération de code permet d'en produire 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.
La suite logique n'est pas de ralentir la machine, ni d'attendre qu'elle devienne parfaite : le schéma d'automatisation parfaite est précisément le piège. C'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.