Le jour où 45 minutes ont suffi à faire tomber un géant de Wall Street
Le 1er août 2012, à l’ouverture de Wall Street, les serveurs de Knight Capital (alors l’un des plus gros teneurs de marché américains) se mettent à passer des millions d’ordres erratiques sur près de 150 valeurs. Le temps que les équipes identifient et coupent la source du problème, 45 minutes se sont écoulées et la facture s’élève à environ 440 millions de dollars. L’entreprise, au bord de la faillite, sera rachetée quelques mois plus tard.
Une défaillance sans coupable unique :
La cause ? Ni un krach, ni un piratage, ni un trader fou. Lors d’un déploiement, un ancien module de test resté dans le code (un fragment baptisé Power Peg, conçu des années plus tôt pour des environnements de simulation) a été réactivé par erreur sur l’un des huit serveurs de production. Sept serveurs exécutaient le nouveau code ; le huitième rejouait un comportement de test face à de vrais marchés, avec de vrais ordres et de vrais millions.
Le plus troublant dans cette histoire, c’est qu’on peine à désigner l’erreur. Le technicien qui a oublié un serveur lors du déploiement ? Le code de test jamais nettoyé ? L’absence de procédure de vérification post-déploiement ? Le système qui n’imposait aucun garde-fou entre un comportement de simulation et un marché réel ? Chaque maillon, pris isolément, n’a commis qu’une faute impardonnable. C’est leur enchaînement et l’absence de tout mécanisme pour le contenir qui a produit la catastrophe.
Quatorze ans plus tard, cette question devient celle de l’intelligence artificielle. Nous passons notre temps à nous demander qui, de l’humain ou de l’IA, se trompe le plus, sondages à l’appui, benchmarks en bandoulière. Mais cette comparaison passe à côté de l’essentiel : les systèmes que nous construisons ne sont plus ni humains, ni artificiels. Ils sont hybrides. Des copilotes IA assistent des médecins, des agents logiciels s’échangent des tâches sans supervision, des chaînes de décision entières mêlent modèles, interfaces et opérateurs. Ce qu’il faut comparer, ce ne sont pas les taux d’erreur, mais les natures et les causes des erreurs ; mais surtout il faut comprendre la catégorie qui émerge à l’interface : l’erreur de coordination, celle qui n’appartient à personne mais que tout le monde subit. Décortiquons les quatre familles.
L'erreur humaine : une affaire de chair, de fatigue et de raccourcis mentaux
La psychologie cognitive, notamment depuis les travaux de James Reason, distingue plusieurs types d’erreurs humaines bien identifiés :
- Les ratés (slips) : l’intention est bonne, l’exécution dérape. L’infirmière veut administrer 0,5 mg et prélève 5 mg en fin de garde de douze heures. Le développeur veut déployer en recette et pousse en production.
- Les oublis (lapses) : une étape disparaît de la mémoire de travail. On oublie un serveur sur huit lors d’un déploiement, une compresse en fin d’intervention, un flag de debug avant la mise en ligne.
- Les omissions : on ne fait pas ce que l’on aurait dû faire, souvent parce que rien, dans l’interface ou le processus, ne signalait qu’il fallait le faire.
- Les erreurs de jugement : la situation est correctement perçue, mais mal évaluée. On sous-estime un risque, on surestime une marge, on se dit que « ça passera ».
- Les décisions biaisées : le biais de confirmation pousse un décideur à écarter les données qui contredisent son hypothèse ; le biais d’ancrage le rive à la première estimation entendue.
Une erreur graduelle et contextuelle :
Les causes, elles, sont profondément biologiques et contextuelles : la fatigue, le stress, l’émotion, la distraction, la pression temporelle, et surtout les limites de notre mémoire de travail (environ quatre éléments manipulables simultanément, d’après les estimations de la recherche en sciences cognitives). L’humain n’est pas une machine défectueuse : c’est un système optimisé par l’évolution pour la frugalité cognitive, qui prend des raccourcis (les fameuses heuristiques) remarquablement efficaces 99 % du temps… et catastrophiques le reste du temps.
Point essentiel : l’erreur humaine est graduelle et contextuelle. Un humain fatigué se trompe un peu plus, un humain reposé un peu moins. Et il sent généralement quand il est en zone d’incertitude, ce qui, on va le voir, n’est pas du tout le cas de son homologue artificiel.
L'erreur de l'IA confiante, brûlante et statistique
Les systèmes d’IA produisent des erreurs d’une toute autre nature :
La misclassification : le système range une entrée dans la mauvaise case. En 2020, Robert Williams est arrêté à Détroit sur la foi d’une reconnaissance faciale qui l’a confondu avec un suspect ; les systèmes de l’époque présentant des taux d’erreur nettement plus élevés sur les visages sous-représentés dans les données d’entraînement.
L’hallucination : le modèle génère une information plausible mais fausse, avec un aplomb parfait. En 2023, dans l’affaire Mata v. Avianca, des avocats new-yorkais déposent un mémoire citant des jurisprudences entièrement inventées par ChatGPT (décisions, numéros de dossiers et citations inclus).
Le surapprentissage (overfitting) : le modèle a mémorisé ses données d’entraînement au lieu d’en extraire des régularités généralisables. Excellent en laboratoire, médiocre dans le monde réel.
La fragilité (brittleness) : une perturbation minime (quelques pixels modifiés, une formulation légèrement différente) fait basculer la prédiction du tout au tout.
L’échec sous distribution décalée (distribution shift) : le monde change, le modèle non. Zillow l’a appris à ses dépens en 2021 : son modèle d’estimation immobilière a continué d’acheter des maisons à des prix déconnectés d’un marché qui se retournait. Coût de l’aventure : plus de 500 millions de dollars de dépréciations et la fermeture de l’activité Zillow Offers.
Les causes sont elles aussi spécifiques : données biaisées ou incomplètes (le modèle ne peut pas apprendre ce qu’on ne lui a pas montré), objectifs mal spécifiés (optimiser le clic n’est pas optimiser la satisfaction), absence de contexte (le modèle ne sait pas ce qu’il ne sait pas), et absence de méta-cognition : un classifieur peut afficher 99 % de confiance sur une réponse absurde.
C’est la différence fondamentale avec l’erreur humaine : là où l’humain se dégrade progressivement et ressent le doute, l’IA échoue en falaise abrupte et sans le moindre signal d’alerte. Un radiologue fatigué hésite ; un modèle hors de son domaine d’entraînement répond avec la même assurance qu’au cœur de sa zone de compétence. L’erreur d’IA n’est pas une erreur humaine en plus rapide : c’est une espèce différente.
Humain + IA : quand le bug se loge dans l'interface
On pourrait croire qu’associer un humain vigilant et une IA performante donne le meilleur des deux mondes. La littérature en facteurs humains raconte une histoire plus nuancée : la collaboration crée ses propres modes de défaillance, que ni l’humain ni la machine ne produiraient seuls.
- Le biais d’automatisation (automation bias) : face à une recommandation algorithmique, l’humain a tendance à abdiquer son propre jugement. Des études sur les systèmes d’aide au diagnostic ont montré que des cliniciens pouvaient suivre une recommandation erronée alors qu’ils auraient posé le bon diagnostic sans assistance. L’IA ne remplace pas le médecin : elle peut, mal intégrée, le rendre moins bon.
La sur-confiance et la sous-confiance : le problème n’est pas de faire confiance ou non, mais de calibrer cette confiance. Trop de confiance, et l’on valide des hallucinations (les avocats de l’affaire Avianca). Trop peu, et l’on ignore des alertes pertinentes, jusqu’au jour où, lassé des faux positifs, on désactive le système (le phénomène bien connu de la fatigue d’alerte).
La mauvaise interprétation des sorties : un score de 0,87 est-il une probabilité ? Un indice de similarité ? L’utilisateur projette souvent sur le chiffre un sens que le modèle ne lui donne pas.
L’opacité du raisonnement : impossible de challenger une recommandation dont on ne comprend pas la logique. Le conseiller bancaire ou le médecin face à une boîte noire n’a que deux options : obéir ou ignorer. Aucune des deux n’est de la collaboration.
Les passations (handoffs) floues et les vides de responsabilité : qui est responsable quand le système fait « presque » tout, tout seul ? Les accidents impliquant des systèmes de conduite assistée illustrent ce no man’s land : le constructeur affirme que le conducteur devait rester vigilant, le conducteur croyait que la machine gérait. Entre les deux, personne ne tenait vraiment le volant.
Le point commun de ces défaillances : aucune ne vient d’un composant défectueux. Le modèle peut être précis, l’humain compétent, mais le tandem médiocre. Des travaux récents sur la complémentarité humain-IA montrent d’ailleurs un résultat contre-intuitif : dans certainesconfigurations, l’équipe humain + IA performe moins bien que l’IA seule, parce que la couche de collaboration est mal conçue. L’erreur d’interaction est une propriété émergente du système, pas la somme des erreurs de ses parties. Exactement comme chez Knight Capital : le déploiementincomplet n’était que le déclencheur ; c’est l’interface entre les procédures humaines et le système automatisé qui a fourni la portée des dégâts.
IA + IA : l'erreur de coordination, ou le bug sans coupable
Reste la frontière la plus récente : les systèmes multi-agents, où plusieurs IA spécialisées s’échangent des tâches, des résumés et des décisions : un agent qui lit les e-mails, un autre qui interroge la base de données, un troisième qui rédige la réponse. C’est l’architecture vers laquelleconvergent les workflows d’automatisation modernes, et elle fait émerger des pannes d’un genre nouveau :
- La dérive sémantique : l’agent A résume un document avec une légère approximation ; l’agent B traite ce résumé comme un fait établi ; l’agent C bâtit une décision dessus. Chaque maillon est « presque correct », le résultat final est faux. C’est le téléphone arabe, version API.
- L’état partagé périmé (stale state) : deux agents travaillent sur des versions différentes de la même réalité : l’un sur le stock de ce matin, l’autre sur celui d’hier soir. Chacun a raison dans son référentiel ; le système a tort.
- Les erreurs en cascade : une sortie erronée devient l’entrée de dix processus en aval. Le Flash Crash du 6 mai 2010 en reste l’illustration la plus spectaculaire : des algorithmes de trading réagissant aux réactions d’autres algorithmes ont fait évaporer environ 1 000 milliards de dollars de capitalisation boursière en quelques minutes, avant un rebond presque aussi rapide. Aucun algorithme n’était « cassé » ; c’est leur boucle d’interaction qui a divergé.
- Le travail dupliqué et le travail perdu : sans contrat clair, deux agents traitent le même ticket pendant qu’un deuxième ticket tombe dans une faille de routage et n’est jamais traité. Quiconque a vécu une réorganisation d’entreprise mal pilotée reconnaîtra le schéma.
- Les rôles ambigus : « l’agent de vérification » vérifie-t-il les faits, le format, ou la conformité ? Si chaque agent suppose qu’un autre s’en charge, personne ne s’en charge.
Le point décisif est ici : ces défaillances ne sont pas des erreurs de modèle. Vous pouvez remplacer chaque agent par un modèle deux fois plus performant, la dérive sémantique et l’état périmé subsisteront. Ce qui fait défaut, c’est l’infrastructure de coordination : les contratsd’interface, la synchronisation d’état, les boucles de vérification. En somme, tout ce que le génie logiciel distribué a mis trente ans à apprendre et que l’on redécouvre, parfois douloureusement, avec des agents qui communiquent en langage naturel, c’est-à-dire dans le format le plus ambigu jamais inventé.
Il y a une dimension supplémentaire, propre à l’automatisation : la vitesse de propagation. Une erreur humaine se diffuse au rythme des humains : un e-mail mal adressé, un document mal classé, quelques personnes touchées avant qu’on s’en aperçoive. Une erreur dans un système automatisé se diffuse au rythme des machines : des millions d’ordres en 45 minutes chez Knight Capital, des millions d’utilisateurs touchés en quelques secondes quand un système de notification s’emballe. Demain, un agent IA pourra exécuter parfaitement son instruction dans le mauvais contexte (mauvaise permission, état périmé, environnement de production au lieu d’un bac à sable) et son action atteindra son audience maximale avant que quiconque ait pu cligner des yeux. Le danger n’est pas toujours l’intelligence de l’acteur : c’est le rayon d’action qu’on lui confie sans périmètre de sécurité, ce que les ingénieurs fiabilité appellent le blast radius.
Le prochain chantier : concevoir le système, pas seulement le modèle
Si l’on accepte cette taxonomie, une conclusion s’impose : la course à la précision des modèles, aussi nécessaire soit-elle, ne traite qu’une seule des quatre familles d’erreurs. Les trois autres relèvent de la conception de systèmes. Le chantier ressemble à ceci :
- Des rôles explicites : chaque acteur (humain ou IA) sait ce qu’il doit produire, pour qui, et ce qui ne relève pas de son périmètre.
- Des handoffs structurés : une passation de tâche transmet le contexte, le niveau de confiance et les hypothèses, pas seulement un résultat brut. L’aviation a codifié ses checklists de transfert de contrôle après des décennies d’accidents ; les systèmes d’agents devront faire de même.
- Le reporting d’incertitude : un modèle qui dit « je ne sais pas » ou « confiance faible, source unique » vaut infiniment mieux qu’un modèle légèrement plus précis mais toujours péremptoire.
- Des pistes d’audit : quand le résultat final est faux, il faut pouvoir remonter la chaîne et identifier le maillon où l’information s’est corrompue. Sans traçabilité, pas de diagnostic ; sans diagnostic, pas d’amélioration.
- La synchronisation d’état : une source de vérité partagée, datée, versionnée, soit le b.a.-ba du data engineering, qui devient une exigence de sûreté.
- La maîtrise du rayon d’action : séparation stricte des environnements, permissions au plus juste, déploiements progressifs, confirmation proportionnée à l’impact de l’action. Tout ce qui transforme un incident potentiellement majeur en non-événement vu par trois testeurs internes.
- Des points de reprise humaine : non pas un humain qui valide tout (autant supprimer l’automatisation), mais des seuils définis (enjeu critique, confiance faible, situation hors distribution) où le système doit escalader.
- Des boucles de vérification : un agent qui contrôle n’est utile que si son rôle de contrôle est spécifié, outillé et indépendant de l’agent contrôlé.
Rien de tout cela n’est de la recherche fondamentale en IA. C’est de l’ingénierie des systèmes, de l’ergonomie, de la gouvernance. C’est moins spectaculaire qu’un nouveau modèle de fondation mais c’est probablement là que se joueront les prochains gains de fiabilité.
Conclusion
Et si la bonne question n’était plus « qui se trompe le plus, l’humain ou la machine ? » mais « qui s’occupe de l’espace entre les deux ? » L’humain restera fatigable, distrait, biaisé. C’est le prix de son intelligence frugale. L’IA restera statistique, confiante et aveugle à ses propres limites. C’est le prix de sa puissance. Aucun des deux ne sera jamais « corrigé ». En revanche, le tissu qui les relie (interfaces, contrats, protocoles, environnements, institutions) est, lui, entièrement de notre ressort.
La fiabilité de demain ne viendra donc pas d’une intelligence isolée, humaine ou artificielle, mais d’un système socio-technique bien conçu, où humains, modèles, interfaces et organisations se surveillent et se rattrapent mutuellement. Knight Capital n’a pas sombré parce qu’un humain a oublié un serveur, ni parce qu’un programme a mal calculé : l’entreprise a sombré parce que rien, entre les deux, n’était conçu pour rattraper l’erreur. À l’heure où nous confions à des agents IA des rayons d’action toujours plus larges, c’est exactement cette leçon qu’il serait coûteux d’apprendre une seconde fois.
(Note aux chefs de projet : non, « c’est l’agent IA qui a dérivé sémantiquement » ne sera pas une excuse plus recevable que « c’est la faute du stagiaire ». Dans les deux cas, la vraie question sera : qui a conçu le handoff ? Désolé.)
FAQ
L'IA fait-elle moins d'erreurs que l'humain ?
La question est mal posée. Sur des tâches étroites et stables, un modèle bien entraîné peut afficher un taux d’erreur inférieur à celui d’un expert humain. Mais les erreurs ne sont pas de même nature : l’humain se dégrade progressivement et ressent le doute, l’IA échoue brutalement et avec assurance. Comparer les taux sans comparer les natures, c’est comparer la fréquence des rhumes et celle des pannes de courant.
Qu'est-ce qu'une erreur de coordination exactement ?
C’est une défaillance qui ne peut être attribuée à aucun composant pris isolément : chaque humain, chaque modèle, chaque service a fonctionné « correctement » dans son périmètre, mais leur enchaînement a produit un résultat faux ou dommageable. Dérive sémantique entre agents, état partagé périmé, handoff sans contexte, responsabilité diluée : le bug se loge dans les interactions, pas dans les acteurs.
Comment réduire le biais d'automatisation dans une équipe ?
Trois leviers fonctionnent bien en pratique : exiger que le système expose son niveau de confiance et ses sources plutôt qu’une réponse péremptoire ; former les utilisateurs sur les cas où le système se trompe (pas seulement sur ceux où il excelle) ; et maintenir des exercices réguliers sans assistance pour préserver la compétence autonome. Un humain qui n’exerce plus son jugement le perd et ne peut plus jouer son rôle de filet de sécurité.
Les systèmes multi-agents sont-ils prêts pour la production ?
Techniquement, oui : les frameworks d’orchestration d’agents se multiplient et fonctionnent. La vraie question est celle de la maturité de l’infrastructure autour : traçabilité des échanges entre agents, synchronisation d’état, contrats d’interface, points d’escalade humaine. Une règle prudente consiste à commencer par des périmètres à faible blast radius (tâches internes, réversibles, à audience limitée) avant d’élargir le rayon d’action.
Qu'est-ce que le « blast radius » et comment le limiter ?
Le blast radius désigne l’étendue maximale des dégâts qu’une action erronée peut causer avant d’être contenue. On le limite par des mécanismes bien connus du génie logiciel : séparation stricte des environnements (test, recette, production), permissions au plus juste, déploiements progressifs (canary releases), plafonds d’action (montants, volumes, audience) et interrupteurs d’arrêt d’urgence. Le principe est simple : dimensionner les conséquences possibles d’une erreur avant de se demander si elle se produira.
Sources :
[1] SEC, “In the Matter of Knight Capital Americas LLC”, Administrative Proceeding File No. 3-15570, 2013
[2] J. Reason, “Human Error”, Cambridge University Press, 1990
[3] N. Cowan, “The magical number 4 in short-term memory”, Behavioral and Brain Sciences, 2001
[4] Mata v. Avianca, Inc., U.S. District Court, Southern District of New York, 2023
[5] NIST, “Face Recognition Vendor Test (FRVT) Part 3: Demographic Effects”, NISTIR 8280, 2019
[6] CFTC & SEC, “Findings Regarding the Market Events of May 6, 2010”, rapport conjoint, 2010
[7] K. Goddard et al., “Automation bias: a systematic review of frequency, effect mediators, and mitigators”, JAMIA, 2012
[8] R. Parasuraman, V. Riley, “Humans and Automation: Use, Misuse, Disuse, Abuse”, Human Factors, 1997
Chakib KAZI TANI
Data Engineer
