09.10.2026 · Signal Titans Editorial

Joe Armstrong a bâti Erlang autour d’une règle étrange : laissez planter. Ses célèbres « neuf neuf » méritent une note de bas de page.

Joe Armstrong souriant, casquette sur la tête, lors d’une conférence, à côté d’un panneau lumineux montrant un arbre de supervision avec un processus planté et son nom.

La plupart des conseils de programmation sur les erreurs se résument à un mot : prévenir. Vérifier l’entrée, protéger le pointeur, encadrer l’appel. Le conseil de Joe Armstrong, écrit dans sa thèse de doctorat de 2003, sonne à l’inverse : « Si vous ne pouvez pas faire ce que vous voulez faire, mourez. Laissez planter. Ne programmez pas de façon défensive. »

Il ne parlait pas de code d’amateur. Il parlait de la façon dont Ericsson construisait des commutateurs téléphoniques, des machines censées tourner pendant des années. La formule « let it crash » est devenue le slogan le plus célèbre d’Erlang, et l’un des plus mal compris. Il en va de même pour le chiffre fameux qui lui est associé : neuf neuf de fiabilité.

Une machine qui n’a pas le droit de s’arrêter

Armstrong a rejoint le Computer Science Laboratory d’Ericsson à Stockholm en 1985. Son chef, Bjarne Däcker, lui a confié une mission qu’Armstrong a plus tard citée dans son histoire du langage : « résoudre le problème logiciel d’Ericsson ». L’objectif du labo, tel qu’il le décrivait, était « de fournir une meilleure façon de programmer les applications de téléphonie ».

La téléphonie était une cible difficile. Un seul commutateur doit gérer « des dizaines ou des centaines de milliers de transactions simultanées », écrivait Armstrong. Son logiciel devait pouvoir être modifié en cours de fonctionnement, « sans perte de service ». Et une règle venait tout droit des centraux AXE d’Ericsson : la défaillance d’un processus « ne doit influencer que la transaction immédiate concernée ». Un appel défectueux ne devait pas pouvoir entraîner tous les autres dans sa chute.

Quand Armstrong et son collègue Robert Virding demandaient à des chercheurs, lors de conférences, ce qui se passait si l’un de leurs nœuds plantait, les réponses n’avaient rien d’encourageant. Les réponses habituelles, se souvenait Armstrong, étaient « le système ne marchera pas » ou « notre modèle suppose qu’il n’y a pas de pannes ».

D’un modèle Smalltalk lent à un nouveau langage

Armstrong a d’abord modélisé la téléphonie en Smalltalk, mais « Smalltalk était très lent ». Quand il a montré sa notation à un collègue, Roger Skagervall, la réponse a été brève : « c’est un programme Prolog ». Erlang a commencé, selon les mots d’Armstrong, comme un « ajout de la concurrence à Prolog », sous la forme d’un interpréteur écrit en Prolog lui-même. Le développement a débuté en 1986.

Ce n’était bientôt plus un projet individuel. Virding a écrit une deuxième implémentation. Mike Williams a trouvé les premiers utilisateurs internes en 1987 et a écrit plus tard l’émulateur en C pour la machine virtuelle d’Erlang. Williams a aussi apporté l’idée des liens entre processus, qu’Armstrong attribue au « mécanisme de libération des anciens téléphones analogiques ». Ce détail compte : le cœur de la gestion d’erreurs d’Erlang a été emprunté au matériel qu’il devait remplacer.

Ce que « let it crash » veut vraiment dire

Pris isolément, « let it crash » ressemble à un permis d’ignorer les erreurs. La thèse dit quelque chose de plus précis. Sa liste complète de slogans commence par « Laissez un autre processus s’occuper de la récupération d’erreur. » Le modèle, expliquait Armstrong, c’est deux ordinateurs qui se surveillent l’un l’autre : « Nous utilisons exactement la même méthode dans Erlang, sauf qu’au lieu d’ordinateurs nous utilisons des paires de processus. »

En pratique, un processus de travail fait la tâche et un processus superviseur distinct le surveille. Les processus Erlang ne partagent aucune mémoire, donc un processus de travail qui plante ne peut pas corrompre ses voisins. Quand il meurt, le lien transmet la nouvelle au superviseur, qui le relance. Le superviseur peut même se trouver sur une autre machine, car, comme le disait Armstrong, « on ne peut pas construire un système tolérant aux pannes si l’on n’a qu’un seul ordinateur ».

La thèse trace aussi une ligne que la plupart des résumés sautent. Si le programmeur « sait quoi faire pour corriger la condition qui a causé l’exception, alors ce n’est pas une erreur ». Un fichier manquant peut être intercepté et traité là où il se produit. Le plantage est réservé aux cas où « le programmeur ne sait pas quoi faire », ces états inattendus où le code défensif a tendance à deviner et à aggraver les choses. Armstrong était aussi honnête sur les limites : l’isolation des processus, écrivait-il, « n’est pas parfaite », et un processus peut encore monter l’équivalent d’une attaque par déni de service contre un autre.

L’AXD301 et les neuf neuf

L’idée a connu sa grande épreuve après l’effondrement du projet AXE-N d’Ericsson en décembre 1995, un événement qu’Armstrong a qualifié de « l’événement le plus important de l’histoire d’Erlang ». Erlang a été choisi pour le nouveau commutateur ATM AXD301, construit par plus de 60 programmeurs Erlang et organisé autour des « arbres de supervision » d’OTP. Un instantané de fin 2001 comptait environ 1,1 million de lignes de code Erlang.

C’est de l’AXD301 que vient la légende. Armstrong écrivait qu’il « a atteint une fiabilité de NEUF neuf », ce qui représente environ 31 millisecondes d’indisponibilité par an. Ce chiffre est répété depuis comme une propriété d’Erlang lui-même.

Les sources racontent une histoire plus étroite. La thèse d’Armstrong admet elle-même que la seule preuve à long terme était « une présentation PowerPoint » dans laquelle un grand client signalait un système de 11 nœuds à 99,9999999 %, « sans que la manière dont ces chiffres avaient été obtenus ait été documentée ». Mats Cronqvist, architecte système sur l’AXD301, a expliqué plus tard que British Telecom « revendiquait une disponibilité de service de neuf neuf intégrée sur environ 5 nœuds-années ». Il soulignait aussi qu’il y avait « beaucoup plus de C que d’Erlang dans le système » et qu’Armstrong « ne faisait pas partie de l’équipe AXD 301 ». Il jugeait l’affirmation « plutôt bidon », tout en ajoutant que, comparé à des systèmes similaires, le commutateur « était étonnamment fiable ». Ulf Wiger, qui a dirigé la conception de l’AXD301, a confirmé que le chiffre était un vrai point de données client et a dit que d’autres déploiements étaient « systématiquement meilleurs que 99,999 % ».

La version documentée est donc moins magique, mais reste impressionnante : la disponibilité rapportée par un client pour un réseau, et non une loi mesurée du langage.

Interdit, puis libéré

Le succès n’a pas protégé Erlang chez Ericsson. En février 1998, Ericsson Radio Systems l’a interdit pour les nouveaux produits. Une note de politique interne en donnait la raison : un « langage propriétaire » impliquait un effort continu pour en maintenir le support et les outils. Däcker a noté plus tard l’ironie que ce « rabâchage sur le “propriétaire” » ait rendu possible la publication d’Erlang en open source, ce qu’Ericsson a fait en décembre 1998. Armstrong et la plupart de l’équipe centrale sont alors partis fonder une start-up, Bluetail. Son verdict sur l’interdiction : Ericsson « a fait la bonne chose (utiliser la bonne technologie pour le travail) pour de mauvaises raisons ».

L’open source a donné à Erlang une seconde vie. En 2012, les ingénieurs de WhatsApp ont écrit sur leur blog qu’Erlang était un élément clé de leur infrastructure et ont montré un seul serveur tenant plus de 2 millions de connexions TCP. Armstrong est mort en avril 2019 ; la communauté Erlang s’est souvenue de lui comme du père du langage.

L’idée qui a survécu au commutateur

Peu d’équipes construisent aujourd’hui des centraux téléphoniques, mais beaucoup construisent des systèmes qui redémarrent les services défaillants, isolent les charges de travail et acceptent que quelque chose soit toujours cassé quelque part. L’apport d’Armstrong a été d’en faire le point de départ plutôt qu’une réflexion après coup.

La question utile que son travail laisse n’est pas « comment l’empêcher de tomber en panne ? ». C’est : quand cette pièce tombe en panne, qui s’en aperçoit, et qui la remet en marche ?