Le bug à un milliard de dollars, avoué par celui qui l'a créé

Une confession peu commune

Mars 2009, conférence QCon à Londres. Sir Tony Hoare, 75 ans, est l’une des figures les plus respectées de l’informatique mondiale : inventeur du tri rapide (Quicksort), créateur de la logique de Hoare, lauréat du prix Turing en 1980 — l’équivalent du Nobel dans la discipline. Il monte sur scène pour une présentation dont le titre annonce la couleur : “Null References: The Billion Dollar Mistake”.

Le contenu est encore plus inhabituel que le titre. Hoare y explique qu’il considère l’invention de la référence nulle, en 1965, comme son “erreur à un milliard de dollars”. Il raconte qu’il concevait alors le premier système de types complet pour les références dans un langage orienté objet, ALGOL W, avec pour objectif que toute utilisation de référence soit absolument sûre et vérifiée automatiquement par le compilateur. Et qu’il n’a pas résisté à la tentation d’y ajouter la référence nulle, pour une raison très prosaïque : c’était simplement facile à implémenter¹.

Le détail qui rend l’aveu marquant : la présentation était programmée dans une session de la conférence intitulée “Historically Bad Ideas” — les mauvaises idées de l’histoire².

C’est quoi, un “null”, concrètement ?

Le concept est d’une simplicité désarmante, et c’est précisément ce qui le rend dangereux.

En programmation, une variable pointe généralement vers une donnée : un nom d’utilisateur, une date, un objet en mémoire. Mais il arrive qu’on ait besoin d’exprimer une absence : cet utilisateur n’a pas renseigné d’adresse, cette recherche n’a retourné aucun résultat, cet objet n’existe pas encore.

La solution de Hoare : réserver une valeur spéciale, null, signifiant “il n’y a rien ici”. Élégant, économique, immédiat à implémenter.

Le problème est que cette valeur circule ensuite exactement comme n’importe quelle autre. Rien, dans le type de la variable, ne signale au développeur qu’elle pourrait être vide. Le compilateur laisse passer. Et le jour où le programme, en cours d’exécution, tente d’utiliser un null comme s’il s’agissait d’une vraie donnée — lire une propriété, appeler une méthode — il plante.

Chaque développeur reconnaîtra la famille de messages d’erreur qui en découle : NullPointerException en Java, segmentation fault en C, Cannot read property of undefined en JavaScript, NoneType object has no attribute en Python. Des variations sur un seul et même thème, hérité d’une décision prise en 1965.

Ce que les résumés oublient souvent

La version courte de l’histoire est séduisante : un génie fait un choix de facilité, l’humanité en paie le prix pendant soixante ans. La réalité est un peu plus nuancée, et plus intéressante.

D’abord, Hoare n’a pas inventé le concept d’absence de valeur : le NIL existait déjà dans le langage Lisp depuis la fin des années 50³. Ce qu’il a introduit, c’est sa généralisation dans un système de types moderne pour un langage orienté objet, ce qui a servi de modèle à des générations de langages ultérieurs.

Ensuite, une alternative existait déjà à l’époque : les types “union disjointe”, qui obligent à traiter explicitement le cas de l’absence de valeur avant de pouvoir accéder à la donnée. Hoare la connaissait. Selon des récits ultérieurs, des contraintes commerciales ont pesé dans la balance : son employeur vendait des ordinateurs, et les clients voulaient avant tout que leurs programmes Fortran existants continuent de fonctionner plutôt que de devoir être réécrits⁴.

Autrement dit, ce n’est pas seulement une erreur d’ingénieur : c’est un arbitrage entre rigueur technique et pression du marché. Un dilemme que n’importe quelle équipe de développement de 2026 reconnaîtra instantanément.

Un milliard de dollars, vraiment ?

Le chiffre est évidemment une image plutôt qu’une estimation comptable. Mais il est loin d’être absurde.

Les erreurs de déréférencement de null ne se contentent pas de faire planter des applications. Elles figurent parmi les catégories de vulnérabilités recensées par l’OWASP, car un plantage provoqué à distance peut servir de vecteur de déni de service ou de porte d’entrée vers d’autres failles. Additionnez les crashs en production, les heures de débogage, les incidents de sécurité et les régressions sur plusieurs décennies et à l’échelle de l’industrie : le milliard de dollars ressemble plutôt à un plancher qu’à un plafond.

Comment l’industrie a fini par répondre

Le plus intéressant, c’est que l’aveu de Hoare a coïncidé avec un vrai mouvement de fond. Les langages conçus ou modernisés ces vingt dernières années ont largement cherché à corriger le tir, avec plusieurs approches distinctes :

• Kotlin rend la “nullabilité” visible dans le type lui-même. Une variable déclarée String ne peut jamais être nulle ; pour autoriser l’absence, il faut écrire String?. Le compilateur refuse alors tout accès direct sans vérification préalable.
• Rust supprime purement et simplement la notion de null du langage. L’absence de valeur s’exprime via le type Option<T>, qui contraint le développeur à traiter explicitement les deux cas possibles.
• Swift utilise un mécanisme comparable avec ses types optionnels.
• Java, contraint par des décennies de compatibilité ascendante, a introduit Optional en 2014 et travaille sur des types valeur non nullables — une correction progressive plutôt qu’une rupture.
• TypeScript a ajouté le mode strictNullChecks, qui transforme une bonne partie des erreurs de null JavaScript en erreurs détectées à la compilation.

Le point commun de toutes ces approches : déplacer la détection du problème de l’exécution vers la compilation. Faire en sorte que ce soit le compilateur, et non l’utilisateur final, qui découvre le problème.

L’épilogue

Sir Tony Hoare s’est éteint le 5 mars 2026, à l’âge de 92 ans, à Cambridge⁵. La plupart des hommages ont mis en avant Quicksort, l’algorithme qu’il a conçu à 26 ans et qui reste, deux tiers de siècle plus tard, l’une des méthodes de tri les plus employées au monde.

Mais la phrase qui a le plus circulé dans les jours suivants, sur les forums de développeurs comme dans les nécrologies, reste celle de 2009 : celle où un géant de sa discipline a choisi, publiquement, de désigner sa propre création comme une mauvaise idée.

La morale de l’histoire

Cette anecdote prolonge exactement la même logique que le “tiret” de Mariner 1 ou l’epoch Unix : une décision de conception minuscule, prise pour de bonnes raisons pratiques dans un contexte donné, qui se propage pendant des décennies dans des systèmes que son auteur n’aurait jamais pu imaginer.

Mais elle ajoute quelque chose de plus rare. Dans un secteur où l’on communique volontiers sur les réussites, Hoare a fait la démarche inverse : documenter publiquement son erreur pour que d’autres puissent la corriger. Les langages modernes qui éliminent aujourd’hui le null existent en partie grâce à cette honnêteté-là. C’est peut-être, au fond, la partie la plus utile de l’héritage.

Sources

1. InfoQ — Null References: The Billion Dollar Mistake (présentation vidéo de Tony Hoare, QCon London 2009)
2. Lambda the Ultimate — Tony Hoare / Historically Bad Ideas
3. Bertrand Meyer — Avoid a Void: The eradication of null dereferencing (PDF)
4. Java Code Geeks — Null Safety and the Billion-Dollar Mistake
5. ACM Communications — In Memoriam: C.A.R. Hoare
6. Wikipédia — Tony Hoare