Un mois après l’explosion de la navette challenger en 1986, le physicien Richard Feynman avait reçu le mandat d’identifier qui avait bien pu être coupable de cet événement désastreux pour l’ensemble du programme spatial américain. Quelle ne fut pas la surprise des membres de la commission de se faire dire qu’il était pratiquement impossible de pointer du doigt un quelconque coupable. En fait, Feynman, devant la Commission d’enquête, s’était affairé à démontrer comment le joint O-Ring — une petite pièce de caoutchouc servant à sceller les joints entre la navette et les propulseurs à carburant solide —, une fois plongé dans un verre d’eau froide, perdait particulièrement de sa résilience et de son efficacité. Le constat était simple : le type de caoutchouc utilisé était particulièrement sensible aux variations de température, le rendant ainsi incapable d’accomplir la tâche pour laquelle il avait été conçu.

Toujours dans le même ordre d’idée, en 2007, dans l’état de l’Oklahoma, une dame de 76 ans, au volant de sa Toyota Camry, est confrontée à un événement tout à fait particulier qui allait lui infliger des blessures importantes et provoquer la mort de sa passagère. Sans avertissement, la voiture s’emballe et accélère de façon incontrôlée. Malgré tous ses efforts — freiner, utiliser le frein manuel, éteindre le moteur —, rien n’y fait, et la voiture se dirige droit dans le mur d’une digue[1].

Ce cas n’est pas un cas unique pour Toyota, et c’est là que les choses commencent à devenir intéressantes du point de vue technologique. Les spécialistes de chez Toyota ont tout d’abord commencé par imputer le problème à la conductrice elle-même. Par la suite, ils ont commencé à émettre différentes hypothèses, dont un tapis de plancher ajouté par la propriétaire et qui aurait pu bloquer la pédale d’accélération, ou bien, que la pédale d’accélération aurait pu rester coincée. Mais après vérification, ce fut dans moins de la moitié des cas que ces problèmes furent répertoriés. À l’évidence, le problème était d’une tout autre nature.

Le jour ou Toyota fut sommée par la justice de laisser les experts examinés le code informatique embarquée à bord du véhicule, l’équipe de l’informaticien Michael Barr, composé de plus de six experts, ainsi qu’un autre informaticien indépendant, Philip Koopman, en sont arrivés à une conclusion qui ne devrait pas nous surprendre outre mesure. Selon ces derniers, la complexité et la conception bâclée du logiciel servant à réguler l’ensemble des fonctions du groupe motopropulseur avaient entraîné une accélération incontrôlée et incontrôlable.

Conclusion : aucune pièce mécanique ni aucune partie du logiciel embarqué n’étaient en fait responsable de la situation, car le problème se situait plutôt dans l’incroyable enchevêtrement des interactions entre tous les composants du système, à la fois électromécanique et informatique. En fait, le système était à ce point complexe, qu’il fut pratiquement impossible d’identifier de façon précise ce qui avait pu être à l’origine exacte du problème. Au regard des preuves apportées et de l’analyse effectuée, le rapport avait conclu que Toyota aurait dû être beaucoup plus vigilante dans la conception même de ses logiciels et aurait dû éviter de concevoir un système d’une aussi grande complexité.

Quand on y regarde de près, et quand on compare l’explosion de la navette Challenger et celui du problème d’accélération des Toyota Camry, il faut vraisemblablement admettre que la complexité des systèmes technologiques en jeu est susceptible de fragiliser ces mêmes systèmes. D’autre part, l’autre constat qu’il faut poser, c’est qu’il est de plus en plus difficile de pointer un seul composant ou élément dans ces systèmes d’une grande complexité qui seraient susceptibles de provoquer des défaillances. En fait, et il faut s’y faire, les défaillances sont, par défaut, profondément imbriquées dans l’ensemble de toutes les technologies que nous concevons.

Par exemple, en 1996, une fusée Ariane 5, avec à son bord quatre satellites, explose 30 secondes à peine après son décollage. L’enquête déterminera par la suite qu’une ancienne routine informatique, qui n’avait pas été mise à jour pour les nouvelles conditions dans lesquelles elle serait utilisée, avait été responsable du problème. L’enquête démontrera également que de tous les constructeurs impliqués dans le développement de la fusée, aucun n’était à blâmer, que l’explosion n’était pas le fait d’une mauvaise décision, et que l’événement était tout bêtement lié à la grande complexité du système, ce qui nous amène à formuler une seconde hypothèse de travail :

Deuxième hypothèse à propos de la complexité technologique
Lorsqu’une défaillance ou une anomalie informatique survient, celle-ci n’est pas le seul fait d’un code informatique en particulier ou d’un composant spécifique : elle émerge tout simplement de la complexité massive qui constitue intrinsèquement une quelconque technologie et à plus forte raison l’IA.

Même si nous pensons être en mesure, en décortiquant la moindre routine informatique ou le moindre composant, d’arriver à identifier ce qui cause le problème, la chose relève désormais du vœu pieux. En effet, toute technologie hautement intégrée et interconnectée devient le siège d’accidents « normaux », c’est-à-dire inévitables — non pas à cause d’erreurs humaines isolées, mais du fait même de la complexité couplée du système[2]. Dans le domaine logiciel, cette complexité prend la forme d’une combinatoire quasi infinie d’interactions entre modules, bibliothèques, dépendances et couches d’abstraction.

Autrement dit, l’erreur est constitutive de l’informatique, puisque tout code est avant tout un artefact symbolique qui repose sur une logique binaire imparfaite et sur des interprétations contextuelles instables : « computational systems are inherently fallible, not because of poor design, but because representation itself is an act of reduction »[3]. Chaque ligne de code opère un compromis entre la précision logique et la contingence du réel.

Ainsi, nous sommes entrés dans une ère de la non-maîtrise computationnelle, où il devient humainement impossible de saisir l’ensemble des interactions qui se produisent dans les architectures numériques contemporaines. En fait, nous avons basculé vers une « épistémologie distribuée », c’est-àdire que le savoir ne réside plus dans la tête des concepteurs, mais dans les interactions entre couches logicielles, infrastructures matérielles et réseaux d’agents artificiels[4], d’où quatre types de tension.

Type de tension	Description
Dominante	Montée de la complexité algorithmique et perte de maîtrise cognitive humaine.
Structurante	Opacité computationnelle et déplacement de la causalité vers les architectures distribuées.
Émergente	Nouvelles formes d’intelligence non explicables mais performantes.
Compensatoire	Tentatives de régulation (audit, transparence, XAI) pour restaurer la confiance dans les systèmes.

En ce sens, les grands modèles de langage (LLM) accentuent radicalement cette situation. En s’appuyant sur des milliards de paramètres ajustés statistiquement, ils incarnent une forme d’opacité systémique[5], car ces modèles produisent des résultats plausibles sans offrir de traçabilité interprétable de leurs processus internes. Nous ne sommes plus dans la logique du code déterministe, mais dans celle du comportement émergent, où les interactions entre les couches neuronales artificielles donnent lieu à des régularités imprévues, parfois inintelligibles même pour leurs concepteurs[6].

Cette imprévisibilité évoque la situation dite « à la Toyota », empruntée aux analyses des défaillances industrielles : un système si optimisé, si interconnecté et si automatisé qu’aucune instance humaine ne peut en comprendre le fonctionnement global. Concrètement, les anomalies technologiques contemporaines ne sont plus de simples « pannes », mais des effets émergents de la dynamique interne des systèmes complexes[7].

Il faut donc accepter deux conséquences majeures :

• des anomalies émergent inévitablement de la complexité croissante des architectures technologiques, qu’il s’agisse d’un système embarqué, d’un réseau d’apprentissage profond ou d’une infrastructure nuagique (cloud) interopérable ;
• il devient épistémiquement impossible d’identifier la cause précise d’une défaillance donnée. Comme le note Nassim Taleb, nous devons apprendre à vivre dans un monde où « the more complex the system, the less we understand the chain of causality »[8].

En d’autres termes, les LLM ne sont pas des outils que l’on « débogue » : ce sont des écosystèmes computationnels auto-organisés, où la notion même d’erreur se déplace de la faute localisable à la turbulence systémique. Nous ne sommes plus face à des programmes, mais face à des processus opaques de génération du sens qui, tout comme nos sociétés techniques, deviennent de moins en moins explicables, mais de plus en plus performants.

© Pierre Fraser (PhD), linguiste et sociologue / 2025

Balado tiré de cet article

---

[1] Fisk, M. C. (2013 [25 octobre]). Toyota Settles Oklahoma Acceleration Case After Verdict. Bloomberg. URL : http://bloom.bg/2fe4Gz9.

[2] Perrow, C. (1984). Normal Accidents: Living with High-Risk Technologies. Basic Books. URL : Normal Accidents: Living with High Risk Technologies – Updated Edition on JSTOR.

[3] Cantwell Smith, B. (2019). The Promise of Artificial Intelligence: Reckoning and Judgment. MIT Press. URL : https://direct.mit.edu/books/book/4564/The-Promise-of-Artificial-IntelligenceReckoning.

[4] Humphreys, P. (2004). Extending Ourselves: Computational Science, Empiricism, and Scientific Method. Oxford University Press. URL : https://academic.oup.com/book/11160.

[5] Crawford, K. (2021). Atlas of AI: Power, Politics, and the Planetary Costs of Artificial Intelligence. Yale University Press. URL : https://www.jstor.org/stable/j.ctv1ghv45t.

[6] Bender, E. M., Gebru, T., McMillan-Major, A., & Shmitchell, S. (2021). “On the Dangers of Stochastic Parrots: Can Language Models Be Too Big?” Proceedings of FAccT. URL : https://dl.acm.org/doi/10.1145/3442188.3445922.

[7] Leveson, N. (2011). Engineering a Safer World: Systems Thinking Applied to Safety. MIT Press. URL : https://direct.mit.edu/books/oa-monograph/2908/Engineering-a-Safer-WorldSystems-Thinking-Applied.

[8] Taleb, N. N. (2012). Antifragile: Things That Gain from Disorder. Random House.