Insights · 2 juin 2026

Rien ne tombe jamais en panne. Alors que payons-nous exactement ?

Le meilleur travail logiciel est celui qu’on ne remarque jamais

Le fait que rien ne tombe en panne. Un logiciel qui marche passe inaperçu, ce qui donne l’impression que le travail derrière était inutile. Nous rendons ce travail visible : les problèmes évités, les décisions prises, et ce qui se serait passé sinon.

31 décembre 1999, 23 h 59. Le monde retient son souffle. Depuis des années, on annonce le chaos : banques bloquées, avions cloués au sol, centrales en panne.

Le problème était simple et absurde. Dans les années 60 et 70, pour économiser une mémoire hors de prix, on a stocké les années sur deux chiffres. « 99 » pour 1999. À minuit, « 00 » risquait d’être lu comme 1900.

Alors des milliers de développeurs ont passé des années à corriger des millions de lignes de code. On a rappelé des programmeurs COBOL à la retraite. Des centaines de milliards de dollars ont été dépensés dans le monde.

Minuit a sonné. Rien. Quelques bugs isolés, pas de chaos.

Et dès le lendemain, le verdict est tombé : « C’était exagéré. Tout ça pour rien. »

Non. Tout ça pour que rien n’arrive.

Le paradoxe de la prévention

C’est probablement l’un des plus grands succès de l’histoire de l’informatique, et il est resté dans les mémoires comme une fausse alerte. Cela porte un nom : le paradoxe de la prévention. Quand la prévention fonctionne, il n’y a rien à voir, donc on croit qu’elle n’était pas nécessaire.

Le logiciel n’a pas changé depuis. Un formulaire qui ne plante pas, personne ne le remarque. Une page qui s’affiche instantanément, personne n’en parle. Une migration de données sans incident, personne ne dit merci. On ne voit que ce qui casse.

La conséquence est inconfortable : plus le travail est bon, moins il se voit, et plus son prix paraît suspect.

Rendre visible ce qui ne l’est pas

La réponse n’est pas de laisser quelques bugs pour avoir l’air occupé, même si l’idée est tentante. C’est de montrer ce qui ne se voit pas :

  • Les problèmes évités, pas seulement les fonctionnalités livrées.
  • Les décisions, pas seulement le résultat : pourquoi c’est construit ainsi, et ce que l’autre choix aurait coûté.
  • Ce qui se serait passé sinon, expliqué avant que cela n’arrive plutôt qu’après.

C’est pourquoi nos démos et nos points financiers ne s’arrêtent pas à « voici le nouvel écran ». Ils disent aussi ce qui a été sécurisé, mis à jour ou évité en chemin.

Ce que cela change pour vous

Quand vous payez une maintenance et qu’il ne se passe rien, c’est qu’elle fonctionne. Vous ne devriez pourtant pas avoir à le croire sur parole. Un client ne paie pas pour ce qu’il voit. Il paie pour ce qu’il comprend, et le faire comprendre fait partie du travail.

Question suivanteNous avons essayé ChatGPT sans être convaincus. L’IA vaut-elle vraiment la peine pour notre activité ?