Échouer à échouer : la triste histoire des messages d'erreur

Sommaire

Il fut un temps où les messages d’erreur n’étaient ni esthétiques ni drôles, mais au moins, ils avaient une fonction : dire ce qui ne va pas et, parfois, indiquer ce que l’on peut faire. Aujourd’hui, on doit se débrouiller avec des “Oops”, “Something went wrong”, ou “Vérifiez votre connexion Internet”. Plus souvent que de raison, le système laisse entendre que c’est nous, les utilisateurs, qui sommes en tort ; rarement la “plateforme”, qui fait figure d’autorité, présumant de notre intelligence et de notre capacité à gérer notre matériel. Et nous fait passer des heures à diagnostiquer un problème qui ne nous concerne pas.

Cet article propose une relecture critique de l’évolution des messages d’erreur en informatique, depuis les années 1980 jusqu’aux interfaces modernes. Ce que l’on observe, ce n’est pas une simple perte de technicité ou une volonté de “mieux protéger l’utilisateur”, mais une dérive structurelle. Les messages d’erreur sont devenus de moins en moins informatifs, de plus en plus vagues, et régulièrement accusateurs, jusqu’à fabriquer des récits dans lesquels l’utilisateur devient fautif par défaut. Nous avons échoué à rendre l’erreur constructive.

L’erreur, miroir du système

Un message d’erreur est censé être un point de contact rare et révélateur. Il ne dit pas seulement que quelque chose a échoué. Il dit comment l’échec est interprété, à qui il est attribué, et quel récit on propose à l’utilisateur pour l’expliquer.

Depuis quarante ans, ces messages accompagnent chaque transformation de l’informatique. On est passé du terminal au bureau graphique, du local au web, du logiciel au service, puis au SaaS. Chaque époque a produit ses styles, ses jargons, ses masques. Mais derrière ces mutations formelles, une tendance se dessine : l’information baisse, le blâme augmente, et le diagnostic est de plus en plus externalisé, vers le support, la télémétrie, ou simplement vers le silence.

Retour en arrière

Dans les années 1980, l’utilisateur de MS-DOS ou d’un Macintosh “classic” n’était pas nécessairement un expert. Mais il était censé intervenir. Et l’informatique, à l’époque, ne prenait pas de pincettes.

Prenons le célèbre message de MS-DOS.

Annuler, réessayer ou échouer : ce message pose les termes de l’échec. Il n’y a pas de solution miracle. L’utilisateur doit faire un choix.

Côté Apple, le “Sad Mac” n’était pas plus loquace, mais le symbole était clair. L’ordinateur est en panne. Ce n’est pas l’utilisateur qui a “mal utilisé” le système. C’est le système qui échoue à fonctionner.

Dans certains cas, le “Sad Mac” était accompagné de codes hexadécimaux qui permettaient aux utilisateurs aguéris de préciser la cause.

De leur côté, les ordinateurs Amiga affichaient une “Guru Meditation” lors d’un plantage système. C’était un écran noir sur fond rouge, accompagné de valeurs hexadécimales. Le message est devenu un objet de culture, mais il remplissait sa fonction : une erreur grave s’est produite, et un contexte est fourni.

Ces exemples ont un point commun : ils ne cherchent pas à atténuer ni à masquer l’erreur. Ils n’inventent pas d’histoire. Ils l’admettent.

Années 1990 : l’erreur en boîte de dialogue

Avec les interfaces graphiques, l’erreur se matérialise en fenêtres modales. Elle coupe le flux, impose une décision, et affiche souvent un minimum d’information technique.

Sous Windows 3.1, un “General Protection Fault” signale un crash applicatif et le module concerné. C’est abrupt, mais c’est un début de diagnostic.

La même époque produit d’autres formulations tout aussi directes, comme “Unrecoverable Application Error”. Là encore, ce n’est pas élégant, mais c’est explicite : l’application est morte, et l’exécution ne peut pas continuer, ce qui laisse finalement peu d’options à l’utilisateur.

Côté Mac OS “classic”, les erreurs système s’affichent aussi de manière frontale, parfois avec l’iconographie du “bomb” et un code. Le message ne vous explique pas forcément ce que vous pouvez faire. Il vous dit surtout qu’il y a eu une rupture, et que le système n’a pas pu assurer.

Années 2000 : du diagnostic au reporting

Au tournant des années 2000, le PC devient un objet domestique. Dans le même temps, l’écosystème logiciel grossit. Pilotes, antivirus, codecs, barres d’outils, plug-ins, tout s’empile. Et les crashs deviennent, pour beaucoup, une expérience ordinaire.

L’emblème de cette période reste le Blue Screen of Death (BSOD) de Windows. Il est anxiogène pour beaucoup, mais reste très informatif.

Le BSOD de Windows XP, par exemple, affiche un code, des indications sur le pilote fautif, et plusieurs pistes d’action dont la technicité va crescendo. L’utilisateur moyen ne comprend pas tout, mais le système prend la responsabilité du crash et expose un diagnostic qui peut servir à “quelqu’un qui s’y connait”.

Sur Mac OS X, une panique du noyau affiche aussi un écran d’arrêt. Le message demande de redémarrer. C’est utile comme consigne d’action, mais cela dit très peu de la cause. Le diagnostic détaillé existe, mais il se trouve dans des journaux.

Dans le même esprit, Microsoft publie des recommandations pour la rédaction de messages d’erreur. Elles insistent sur la clarté, la précision, et sur le fait de ne pas blâmer l’utilisateur.

Au même moment, une autre logique s’installe : l’erreur devient un signal à remonter. Sur Windows, cela se formalise avec Windows Error Reporting. Le système collecte des détails que l’utilisateur ne voit plus. L’écran sert d’embrayage vers le support.

Ce déplacement se voit aussi côté applications. Les erreurs applicatives deviennent un phénomène de masse, dans des logiciels omniprésents. Le message n’est plus un diagnostic, mais une confirmation de fermeture, suivie d’une proposition d’envoyer un rapport.

Sur les navigateurs, la même mécanique apparaît. Un plug-in plante, et l’interface propose un message standardisé, sans cause exploitable.

Les crash reporters vont plus loin. Ils demandent une description, collectent une trace, et envoient un paquet de données au fournisseur. L’utilisateur, lui, reste souvent avec une phrase générique.

Sur Linux, à la même période, l’erreur reste généralement plus verbeuse. Un crash applicatif s’exprime souvent par une “erreur de segmentation”, “Segmentation fault”, parfois accompagné de “(core dumped)”. Quand c’est le noyau qui panique, la console affiche des messages, des adresses et une pile d’appels. Ce n’est pas toujours lisible pour un non-spécialiste, mais c’est une information exploitable, au moins pour rechercher, corréler, et rapporter.

Années 2010 : le web, la marque, et le masque

Avec le web, une nouvelle contrainte s’impose : l’erreur devient une vitrine. Elle arrive chez tout le monde, en permanence, dans des contextes très variés. Et elle engage la marque.

Le protocole HTTP prévoit pourtant des signaux simples. Un serveur peut répondre “404 Not Found” quand la ressource n’existe pas, ou “500 Internal Server Error” quand il échoue de manière inattendue. Ces codes ont un mérite particulier : ils sont censés convoyer la responsabilité de l’erreur : le client (le navigateur) ou le serveur.

Mais dans la pratique, les plateformes remplacent souvent ces diagnostics par des pages personnalisées, voire falsifient les codes de retour, ou en inventent qui ne figurent pas dans les standards du web. C’est notamment le cas de Cloudflare, connu pour exploiter des erreurs 521 qui n’existent que chez eux.

Au-delà de l’aspect purement technique, on transforme ces pages d’erreur en page commerciales. L’article “The Evolution of Fail Pets” (Rintel, 2011) analyse cette évolution. Il décrit comment des erreurs “sympathiques” et illustrées deviennent un outil de branding et de désamorçage émotionnel.

Le navigateur lui-même participe à ce mouvement. Chromium affiche “Aw, Snap!” lors d’un crash d’onglet. C’est mémorable. Mais ce n’est pas un diagnostic.

En cas d’absence de réseau, l’erreur devient un mini-jeu. Le dinosaure hors ligne est iconique. Et il montre bien le basculement : on distrait, on dédramatise, mais on n’explique pas.

Années 2020 : minimalisme, télémétrie, et écran noir

Dans les années 2020, une partie de l’industrie pousse le minimalisme jusqu’au bout. On conserve un identifiant. On retire le reste.

Le BSOD évolue de cette manière depuis plusieurs versions de Windows. Windows 8 introduit notamment une présentation plus “émotive”, avec un visage triste.

Sur Windows 10 et Windows 11, l’écran se simplifie encore. La documentation se déporte vers le web. Et l’utilisateur ne voit souvent plus qu’un stop code et, parfois, un QR code.

Sur certaines versions de Windows 11, le “Blue” Screen devient même noir. On parle alors, par analogie, de “Black Screen of Death”. C’est la même logique, mais encore plus minimaliste visuellement.

Pendant ce temps, Linux continue généralement d’afficher des messages détaillés en cas de panique du noyau. Cela ne rend pas l’erreur moins grave. Mais cela fournit un contexte, au lieu d’une émotion.

Et côté applications, les messages génériques restent la norme. Ils disent qu’il y a eu un problème, sans dire lequel, ni où chercher. Même une erreur de runtime, très classique, peut rester opaque pour un utilisateur final.

Cette évolution prépare un dernier glissement. Quand l’erreur ne dit plus ce qui s’est passé, elle peut dire ce qu’elle veut.

Vous êtes le maillon faible

Et ce qu’elle dit de plus en plus souvent, c’est : “c’est de votre faute”. L’exemple le plus frappant, et le plus courant :

You’re offline. Check your connection.

Ce message apparaît régulièrement dans les interfaces YouTube, y compris chez des utilisateurs qui ne sont pas hors ligne. Il s’agit d’un diagnostic affirmatif côté client, sans preuve, sans incertitude admise, et sans possibilité de contredire le verdict.

Exemples documentés :

Ce message est problématique à plusieurs titres.

Il attribue la cause à l’utilisateur, sans considérer la possibilité d’une erreur côté service.
Il n’admet aucune incertitude : “vous êtes hors ligne”, et non “nous n’avons pas pu établir la connexion”.
Il ne propose aucune alternative, comme “réessayer plus tard” ou un lien vers le statut du service.
Il ne fournit aucun identifiant ni lien vers une aide concrète.

La conséquence est simple. Vous passez du temps à vous justifier auprès d’un système qui n’admet pas avoir pu se tromper. Et vous devenez, mécaniquement, la personne chargée de diagnostiquer.

Pire encore, ces messages spécifiques ne concernent pas une “mauvaise qualité de connexion”, ils ciblent les bloqueurs de publicité sans les mentionner (parce que ce serait avouer que YouTube sait que vous bloquez les publicités). Le message est donc ouvertement mensonger à plus d’un titre.

Des erreurs anxiogènes à la frustration

Adoucir une erreur n’est pas, en soi, une mauvaise idée. Une erreur peut provoquer du stress et de l’anxiété. Le concept de technostress décrit précisément cet effet dans la relation aux technologies.

Mais supprimer l’information ne supprime pas l’émotion. Cela déplace la charge. Vous n’êtes plus face à un problème, vous êtes face à un mystère. Votre ordinateur ne vous appartient plus tout à fait, quelqu’un décide pour vous ce que vous pouvez ou ne pouvez pas en faire.

Dans ce contexte, un message culpabilisant est particulièrement toxique. Il active un mécanisme d’attribution où la faute est projetée sur l’utilisateur, plutôt que sur la situation. Ce biais est proche de ce que la psychologie sociale décrit comme l’erreur fondamentale d’attribution.

Avec le temps, cette opacité peut produire une forme d’impuissance apprise. On finit par arrêter de chercher à comprendre, et on apprend des gestes de contournement.

On a ainsi remplacé une anxiété ponctuelle par une frustration chronique. Et, souvent, par de la bidouille. Vider le cache. Changer de navigateur. Désactiver des extensions. Redémarrer. Et espérer.

Une responsabilité structurelle

Pourquoi ces messages ont-ils évolué dans ce sens ? Plusieurs forces convergent :

Les interfaces doivent rester fluides

Dans une logique d’expérience utilisateur sans friction, admettre une panne est vu comme un risque. Il vaut mieux cacher l’échec, ou suggérer qu’il vient “de l’extérieur”.

Le support est coûteux

Un message trop clair peut générer des tickets, des attentes, voire des réclamations. Il vaut mieux suggérer que l’erreur vient d’un élément que l’utilisateur peut “réparer” seul (connexion, cache, bloqueur de publicités). Jusqu’à ce qu’il abandonne et finisse par se dire que l’informatique ne fonctionne jamais.

Le diagnostic est déporté ailleurs

Aujourd’hui, les équipes techniques disposent d’outils puissants pour observer les erreurs. Logs, traces, corrélation, télémétrie, tout cela existe. Mais ces outils sont internes. Le diagnostic se fait dans les backends. L’utilisateur, lui, reçoit un message standardisé, souvent vide.

Citons par exemple :

Un exemple frappant : Cloudflare fournit un identifiant unique ("Ray ID") pour chaque requête. Il est utile au support, mais il est affiché sans explication à l’utilisateur qui ne peut rien en faire.

Ce que l’on pourrait faire, sans danger

On n’a pas besoin d’une stack trace. On n’a pas besoin d’un chemin de fichier interne. Mais on peut donner un minimum d’outillage, sans exposer le système.

Par exemple :

Un message qui admet l’incertitude, comme “nous n’avons pas pu charger la page”.
Un identifiant d’erreur, accompagné d’une phrase expliquant à quoi il sert.
Une action concrète (ou même, mieux, plusieurs actions cohérentes, pertinentes et utiles), adaptée au contexte, et pas une liste de réflexes.
Un lien vers une page de statut, quand il s’agit d’un service, ou au moins vers une page de documentation.
Une date, un horaire, et un point de contact, quand c’est un incident.

La question de la sécurité

On objectera : on ne peut pas tout dire, pour des raisons de sécurité, et c’est vrai. OWASP recommande de ne pas afficher de stack traces, de chemins internes, ou d’informations sensibles dans les messages d’erreur. De telles informations doivent exister et être accessibles pendant le développement de l’application, du site ou de l’outil. Pas en production.

Mais cette prudence ne justifie pas l’obfuscation totale. Il existe un compromis : admettre une erreur, suggérer des causes possibles, fournir un identifiant ou un lien vers une aide réelle.

La Common Weakness Enumeration (CWE-209) le dit explicitement : trop d’informations est un risque, mais trop peu d’informations rend le système confus, voire inutilisable.

Ce compromis est rarement respecté. On ne fournit ni cause, ni incertitude, ni code, ni guide. Seulement une formule vague… ou, pire, une accusation.

Un silence orienté

La dérive des messages d’erreur ne tient pas seulement à des choix de design. Elle révèle une logique plus profonde : ne pas assumer les pannes, ne pas outiller l’utilisateur pour comprendre, et, par défaut, lui faire porter la charge.

Nous sommes passés de messages bruts mais honnêtes, à des messages polis mais mensongers.

Les fournisseurs de services se désolidarisent de leur responsabilité à fournir un outil qui fonctionne. Et l’utilisateur non-technicien (et parfois même le technicien) fini par se persuader qu’il est trop bête pour l’informatique, qu’elle devient trop compliquée, et que tout le monde sait mieux que lui.

La technologie sait. Les systèmes sont instrumentés. Les erreurs sont corrélées. Les équipes reçoivent des événements enrichis. Et pourtant, l’utilisateur, celui qui subit l’échec, n’en reçoit rien.

Ce silence n’est pas neutre : c’est un déplacement de responsabilité. Une ruse pour éviter de dire : “ça vient de nous”. C’est l’instrumentalisation de l’abrutissement des utilisateurs.

Ce qu’on attend d’un message d’erreur n’est pas qu’il expose le backend. Mais qu’il dise, au minimum : il s’est passé quelque chose, et ce n’est pas forcément chez vous.

Conclusion

Tout le monde ou presque a échoué à échouer. La plupart par obfuscation, par dilution, par honte, ou par excès de confiance. Ceux qui ne cachent pas l’information la montrent brute.

Ni le minimalisme ni l’exhaustivité ne permettent de résoudre un problème. En cela, je considère que le BSOD de Windows XP est un modèle du genre : informatif, honnête, humble, et il propose plusieurs solutions. Il n’est pas parfait dans la mesure où rebooter ne peut pas être la solution à tout, mais il ne prend pas l’utilisateur pour plus bête qu’il n’est.

D’un autre côté, aucun utilisateur ne lit ce qui est affiché sur son écran. Autant en afficher le moins possible.

Mais, non : aucune de ces positions est défendable.

Et lorsque l’on n’aura plus aucun message d’erreur, on vivra dans un monde de licornes et d’arcs-en-ciel, persuadés d’avoir atteint un nouveau sommet technique de l’informatique, alors que, comme d’habitude, on aura appliqué un pansement sur une jambe de bois.