Le 21 juillet 2026, Stephen Wolfram a publié un long essai intitulé Towards a Theory of Bugs: The Ruliology of the Unexpected. Cet article tente d’établir une “théorie formalisée” du bug informatique autour d’une thèse centrale unique : le bug est la conséquence inéluctable de l’irréductibilité calculatoire (computational irreducibility).
L’article a suscité un engouement massif sur Hacker News, accumulant 1 294 points et 508 commentaires, se hissait au sommet des discussions du jour. Cependant, une certitude flottait dans les commentaires : “De quoi parlez-vous exactement ?”
Le grand récit d’un mathématicien
Qui est Stephen Wolfram ? Même si vous ne codez pas, vous avez peut-être croisé ce nom dans un autre contexte : fondateur du logiciel Mathematica, concepteur du moteur de connaissance Wolfram Alpha et fervent défenseur de A New Kind of Science. Il possède une habitude profondément ancrée : faire entrer tous les phénomènes dans le cadre de son “Principe d’Équivalence Calculatoire” (Principle of Computational Equivalence).
Cette fois-ci, il s’est attaqué aux bugs logiciels.
La chaîne d’argumentation de Wolfram est la suivante : même des programmes extrêmement simples — par exemple une machine de Turing à 3 états et 2 couleurs — peuvent produire un “comportement inattendu” face à certaines entrées. Il donne un exemple concret dans son article : une machine de Turing censée calculer n+1 fournit un résultat correct pour les entrées de 0 à 6, mais affiche inexplicablement 9 pour l’entrée 7.
Il poursuit en présentant un cas encore plus extrême : une machine de Turing à 4 états qui fonctionne correctement pour les entrées 0 à 62, mais renvoie brusquement 72 pour l’entrée 63.
Pour Wolfram, ces “anomalies inattendues” sont l’embryon des bugs. Et leur origine profonde réside dans ce qu’il nomme l‘“irréductibilité calculatoire”.
L’irréductibilité calculatoire : la métaphore du jeu de Go
Il convient de s’arrêter un instant pour expliciter ce concept clé, car l’ensemble du débat repose sur lui.
L‘“irréductibilité calculatoire” est une notion proposée par Wolfram en 2002 dans son ouvrage A New Kind of Science. Son intuition fondamentale peut se résumer par une question : est-il possible de déterminer l’issue d’une partie de Go sans jouer chaque coup jusqu’au bout ?
La réponse est non. Chaque coup au Go dépend de la réaction de l’adversaire, qui elle-même dépend de votre coup suivant. En dehors du fait de jouer réellement la partie jusqu’à son terme, aucun raccourci ne permet de prédire avec précision le résultat final.
C’est là tout le sens d’ “irréductible” : lorsqu’un programme s’exécute, son comportement ne peut être prédit par aucune “méthode de calcul plus rapide”. La seule façon de connaître son résultat est de l’exécuter pas à pas jusqu’à la fin.
La logique de Wolfram s’avère donc très directe : si un bug est fondamentalement un “comportement inattendu”, et si l’irréductibilité calculatoire implique que tout programme suffisamment complexe générera inévitablement des comportements impossibles à connaître à l’avance — alors le bug n’est pas simplement une “erreur de développeur”, mais une nécessité mathématique.
Il avance même que dès lors qu’un programme vaut la peine d’être exécuté (c’est-à-dire qu’il effectue un calcul significatif), il comporte obligatoirement une part d’imprévisibilité et recèle donc des bugs potentiels. Cela ressemble à un dilemme existentialiste : soit vous écrivez un programme tellement trivial qu’il ne contient aucun bug, soit vous acceptez que le bug est le prix même du calcul.
La réponse des ingénieurs : “Cela ne correspond pas à mon quotidien”
Si l’histoire s’arrêtait là, il s’agirait d’une simple méditation philosophique de mathématicien. Mais le véritable spectacle a commencé dans l’espace des commentaires.
Le commentaire de l’utilisateur gjm11 a rapidement été propulsé en tête des votes. Il a soulevé une contradiction flagrante : les “bugs” décrits dans l’article de Wolfram n’ont aucun rapport avec ceux auxquels les développeurs de terrain sont confrontés jour après jour.
gjm11 distingue deux scénarios radicalement différents :
Scénario 1 : Vous souhaitez écrire un programme réalisant la fonction X. Vous réfléchissez attentivement à la logique nécessaire, puis vous rédigez le code censé produire le résultat X — mais vous commettez des erreurs en chemin. C’est l’origine de la quasi-totalité des bugs réels : erreur de logique du développeur, mauvaise gestion des cas limites, mauvaise interprétation d’une documentation d’API.
Scénario 2 : Vous générez une immense quantité de programmes aléatoires, vous les testez un par un, vous en trouvez un qui semble effectuer la fonction X sur un petit échantillon d’entrées, et vous l’utilisez — pour découvrir ensuite qu’il échoue sur certains cas limites.
L’article de Wolfram traite exclusivement du Scénario 2. Il illustre son propos avec des machines de Turing générées aléatoirement qui se comportent “la plupart du temps” correctement avant de faillir sur des entrées spécifiques. Mais cela n’a rien à voir avec le Scénario 1, où un développeur conçoit consciemment un système et commet une erreur par inadvertance.
gjm11 a qualifié l’argumentation de Wolfram d‘“un peu absurde” (silly), soulignant que Wolfram cherche simplement à plaquer son concept chéri d‘“irréductibilité calculatoire” sur un domaine auquel il ne s’applique pas.
Des divergences plus profondes
Un autre utilisateur, seanhunter, a pointé du doigt un autre écueil : Wolfram n’a jamais défini rigoureusement ses concepts fondamentaux.
Le “Principe d’Équivalence Calculatoire” et l‘“Irréductibilité Calculatoire” servent d’outils d’explication universels dans le système de Wolfram, mais ils manquent de définitions formelles. Dans la recherche scientifique classique, un concept impossible à définir ne peut être ni vérifié ni réfuté. Et une théorie non vérifiable relève davantage de la profession de foi que de la science.
L’observation de PaulHoule fait preuve d’une ironie grinçante. Il note un schéma récurrent chez Wolfram : chaque fois qu’il découvre une nouvelle famille de règles, il y déniche un phénomène curieux comme la “Règle 30” et s’empresse d’annoncer qu’il a découvert une nouvelle “théorie” — sans jamais pouvoir en dire plus que “ceci aussi est calculatoirement irréductible”.
C’est sans doute là la plus grande ironie : un mouvement qui s’est autoproclamé “Une nouvelle sorte de science” n’a produit en vingt ou trente ans qu’une seule idée centrale : beaucoup de choses sont imprévisibles.
L’écho d’un débat plus ancien
En prenant du recul, ce débat n’a rien de nouveau.
La thèse de Wolfram sur l’ “inéluctabilité des bugs” revient au fond à fournir un socle mathématique à un constat empirique bien connu des ingénieurs : il est impossible d’éliminer totalement les défauts logiciels. Sur ce point, il n’est pas le seul — le problème de l’arrêt de Turing a prouvé depuis longtemps qu’aucun algorithme général ne peut déterminer si un programme quelconque s’arrêtera. En pratique, la plupart des ingénieurs acceptent l’idée que les grands systèmes logiciels comporteront toujours des bugs.
Mais le problème réside dans le saut conceptuel : passer de “les bugs sont inévitables” à “l’irréductibilité calculatoire constitue la théorie des bugs” fait l’impasse sur de trop nombreux maillons.
Le raisonnement de Wolfram franchit plusieurs niveaux d’abstraction. Partant des propriétés mathématiques des machines de Turing, il saute directement aux bugs du développement logiciel quotidien. Ce saut fait l’impasse sur un fait essentiel : la grande majorité des bugs en production découlent des limites cognitives humaines — cas limites oubliés, spécifications mal comprises — et non d’une profonde irréductibilité calculatoire.
Ces “bugs humains” conservent certes un lien indirect avec l’irréductibilité calculatoire (la cognition humaine étant elle-même un processus de traitement de l’information), mais l’article de Wolfram ne parvient pas à établir cette passerelle. Il se contente d’enrober d’un concept mathématique impressionnant un phénomène qui s’expliquerait en des termes bien plus simples.
Pour être juste, Wolfram n’a pas tout à fait tort
En tant qu’expérience de pensée, le récit selon lequel “l’irréductibilité calculatoire engendre les bugs” n’est pas dénué d’intérêt.
D’un côté, il touche du doigt une réalité contre-intuitive : même le système de règles le plus simple peut engendrer des comportements imprévisibles. C’est particulièrement pertinent à l’ère de l’intelligence artificielle — lorsque des modèles d’apprentissage automatique génèrent du code et que même les concepteurs ne comprennent pas entièrement ce qui se passe dans l’espace latent du modèle, le cadre explicatif traditionnel “le développeur s’est trompé” devient insuffisant.
D’un autre côté, les limites de la “vérification formelle” évoquées par Wolfram sont bien réelles. Aucun système de vérification formelle ne peut couvrir l’ensemble des entrées possibles, ce qui découle des limites fondamentales de la théorie du calcul. En ce sens, pour les logiciels critiques — tels que les systèmes de conduite autonome ou les logiciels médicaux —, comprendre l’ “impossibilité d’éliminer” les bugs conserve une portée pratique.
Cependant, comme l’ont fait remarquer de nombreux intervenants, il s’agit plutôt d’un réemballage de conclusions déjà connues : l’indécidabilité de l’arrêt et le coût élevé de la vérification formelle sont des évidences depuis longtemps dans le génie logiciel. La contribution de Wolfram se limite tout au plus à coller une nouvelle étiquette sur des notions existantes.
L’orgueil du mathématicien et le pragmatisme de l’ingénieur
Derrière ce débat se cache un conflit culturel plus profond.
Wolfram raisonne en mathématicien et en théoricien. Sa démarche consiste à partir des premiers principes pour bâtir un cadre grandiose, puis à l’utiliser pour tout expliquer. Il ne recueille pas de données empiriques sur les bugs et n’analyse pas de rapports d’erreurs réels — il “simule” le phénomène des bugs en générant des machines de Turing aléatoires.
La démarche de l’ingénieur est aux antipodes. Il est confronté au désordre du monde réel : une exception de pointeur nul, une condition de concurrence, un échec de paiement dû à une mauvaise gestion du fuseau horaire. Les causes de ces bugs sont très concrètes et séparées de l’ “irréductibilité calculatoire” par de multiples couches d’abstraction. Pour l’ingénieur sur le terrain, la théorie de Wolfram ressemble moins à une explication qu’à du bruit ambiant.
C’est là le coup de grâce de la critique de gjm11 : Wolfram confond deux voies de débogage. L’ingénieur emprunte la première : comprendre le code, identifier le défaut logique, corriger l’erreur. La seconde voie décrite par Wolfram — “trouver un morceau de code aléatoire qui semble fonctionner et prier pour qu’il marche dans tous les cas” — n’est pas une méthode de débogage, c’est un anti-patron.
Conclusion : les limites de la théorie
En tentant d’apporter une “explication ultime” aux bugs par l’irréductibilité calculatoire, Wolfram a au moins le mérite d’affronter une vérité dérangeante du génie logiciel : nous ne serons jamais en mesure d’écrire des logiciels totalement exempts de bugs.
Cependant, élever le constat empirique “les bugs sont inévitables” au rang de “Théorie du Bug” exige bien plus que de beaux concepts. Cela nécessite des preuves factuelles, une capacité de prédiction opérationnelle et une compréhension intime des pratiques de développement réelles — autant d’éléments absents des travaux de Wolfram.
Cela ne signifie pas pour autant que la démarche de Wolfram soit sans valeur. L’irréductibilité calculatoire décrit avec justesse un phénomène réel de l’informatique. Simplement, pour expliquer les bugs auxquels les développeurs sont confrontés chaque jour — ceux provoqués par une inattention, un défaut de communication, un changement de spécification ou un cas particulier oublié lors de la revue de code —, ce concept est d’un grain bien trop grossier.
Comme l’a si bien résumé un commentaire : peut-être que Wolfram “a juste trouvé un endroit de plus où la Règle 30 se manifeste et s’est enthousiasmé en pensant avoir découvert une théorie”. À l’échelle de l’univers calculatoire, c’est sans doute vrai. Mais pour l’ingénieur qui corrige un bug en production au milieu de la nuit, savoir que “les bugs existent à cause de l’irréductibilité calculatoire” apporte à peu près autant d’aide que de s’entendre dire que “tous les êtres humains finissent par mourir” lorsqu’on cherche un remède contre le rhume.
Liens de référence :
- Stephen Wolfram : Towards a Theory of Bugs: The Ruliology of the Unexpected
- Discussion sur Hacker News (item?id=49033114)
- Irréductibilité calculatoire - Wikipédia
- Wolfram : Principle of Computational Equivalence
Toutes les images de cet article proviennent de la page originale de Stephen Wolfram.
