Demandez à n’importe quelle liste des « logiciels les plus importants jamais créés », et quatre catégories reviennent toujours : le système d’exploitation, le courrier électronique, le traitement de texte et le tableur. Des quatre, le tableur est le plus étrange. Il est à la fois l’outil le plus émancipateur jamais confié à quelqu’un sans formation d’ingénieur, et le plus vaste dépôt de logique métier non gouverné de la planète. VisiCalc, puis Lotus 1-2-3, puis Excel, ont réussi ce qu’aucun compilateur ni aucun environnement de développement n’a jamais réussi : laisser un analyste financier, un responsable des opérations, un administrateur scolaire coder un savoir de domaine réel — modèles de tarification, logique de prévision, règles de stock — sans demander la permission à personne et sans écrire une seule ligne de ce qu’un programmeur reconnaîtrait comme du code. Voilà le cadeau. Et c’est aussi, par la loi d’Emerson, exactement là que la facture arrive.

I. La Compensation d’Emerson, Appliquée au Logiciel

L’essai « Compensation » de Ralph Waldo Emerson, tiré d’Essays: First Series, soutient que tout avantage dans la nature est taxé par un coût égal et opposé : rien ne s’obtient gratuitement. Le tableur en est un cas d’école, presque trop net pour avoir besoin de la théorie. Sa vertu définitoire est qu’il supprime toute barrière entre une idée et un calcul qui tourne : pas de compilateur, pas de schéma, pas de revue de code, pas de pipeline de déploiement. Son passif définitoire est qu’il supprime toute barrière entre une idée et un calcul qui tourne. Cette même absence de friction, qui permet à un contrôleur de gestion de bâtir en un après-midi un modèle à trois états financiers fonctionnel, est celle qui permet à ce modèle de métastaser, sans commentaires ni contrôle de version, jusqu’à devenir le système d’enregistrement réel de la reconnaissance du chiffre d’affaires d’une division entière. Dan Bricklin a construit VisiCalc en 1979 pour effacer la corvée de recalculer un grand livre à la main ; il n’a rien construit, et ne pouvait rien construire, pour empêcher ce grand livre de devenir silencieusement critique. La proposition de valeur entière de l’outil, c’est zéro cérémonie. Son passif entier est inséparable de cette même absence de cérémonie. On ne peut pas soustraire la taxe sans soustraire le cadeau — ce qui explique pourquoi quarante ans de « meilleurs tableurs » n’ont jamais déplacé l’original : ils essaient tous de réintroduire la gouvernance, et la gouvernance est précisément la friction que ce format existe pour supprimer.

II. Une Cacophonie de Feuilles

Entrez dans presque n’importe quelle entreprise de taille moyenne ou grande et demandez où vit réellement la logique métier ; la réponse honnête est rarement l’ERP ni les outils internes construits par l’équipe d’ingénierie. C’est un drive partagé, ou une page de wiki qui pointe vers un drive partagé, contenant des centaines de tableurs : un modèle de tarification à quatorze onglets et une chaîne de recherches que personne ne peut retracer jusqu’à sa source, un plan d’effectifs avec des valeurs collées à la main par-dessus des formules parce que quelqu’un devait « juste corriger ça » avant un conseil d’administration, une feuille de rapprochement que seule une personne — souvent quelqu’un à quelques années de la retraite — comprend de bout en bout. Chaque feuille fut un acte raisonnable, voire admirable, d’initiative individuelle : quelqu’un a modélisé un problème que personne d’autre n’avait modélisé, avec le seul outil qu’il avait la permission et la formation d’utiliser. La cacophonie n’est pas l’échec d’une feuille en particulier. C’est la propriété émergente de milliers de décisions individuellement rationnelles prises sans schéma commun, sans contrôle de version, sans suite de tests et sans propriétaire unique — plus proche d’une ville qui a poussé sans plan d’urbanisme que d’un système conçu, au sens où l’entendait Jane Jacobs lorsqu’elle décrivait les quartiers qui fonctionnent comme l’accumulation de choix individuels non coordonnés plutôt que comme un plan directeur.

Ce qui est en jeu n’a rien d’hypothétique. En 2012, le modèle de risque d’un desk de trading de JPMorgan — un tableur, copié-collé à la main entre plusieurs onglets — a sous-estimé le risque d’un ensemble de positions sur produits dérivés parce qu’une formule divisait par la somme de deux valeurs au lieu de leur moyenne, alimentant ce qui allait devenir la perte de la « Baleine de Londres », plus de six milliards de dollars. Un an plus tôt, un étudiant de troisième cycle nommé Thomas Herndon avait été chargé de reproduire un article d’économie très cité, « Growth in a Time of Debt » de Carmen Reinhart et Kenneth Rogoff, et découvrit que la conclusion centrale de l’article sur un seuil dette-croissance reposait en partie sur une formule Excel qui avait tout simplement exclu cinq pays d’une moyenne — une erreur de tableur qui, à ce moment-là, avait déjà façonné des années de débat public sur les politiques d’austérité. Aucune des deux erreurs n’impliquait de mathématiques fausses. Les deux impliquaient un outil sans aucun mécanisme permettant à quelqu’un d’autre de voir ce que faisait réellement la formule.

III. Pourquoi « Tout Réécrire Proprement » Échoue

La solution évidente — extraire la logique, construire une vraie application, mettre le tableur à la retraite — est l’endroit où un principe d’ingénierie solide se heurte à un fait inconfortable sur le calendrier. Le tableur d’un expert de domaine est rarement statique ; il est modifié en temps réel pour répondre à la question de ce trimestre, ce qui en fait une cible mouvante pour quiconque tente de le spécifier formellement. Domain-Driven Design d’Eric Evans repose sur le principe que le domaine doit guider la technologie, que le modèle dans le code doit suivre de près le modèle dans la tête de l’expert de domaine. Ce principe suppose que le modèle de l’expert change à un rythme qu’une équipe de développement peut suivre. Le tableur casse ce postulat à la racine : le temps qu’un système bien conçu capture la version 40 de la logique tarifaire, l’entreprise est déjà passée à la version 47, et le tableur « historique », toujours ouvert dans l’onglet du navigateur de quelqu’un, redevient la véritable source de vérité. Le développement logiciel formel tourne sur des cycles de livraison mesurés en semaines. La logique métier portée par les tableurs tourne à l’échelle de temps d’une seule réunion. Ce décalage, plus que toute déficience technique d’Excel en soi, explique pourquoi tant de projets de « migration du tableur » échouent en silence, engloutissent un budget de deux ans et finissent classés dès que change le dirigeant qui les parrainait.

IV. La Décision, Pas l’Artefact

Ce décalage suggère que « migrer le tableur vers un vrai système » est peut-être le mauvais cadrage dès le départ — qu’il traite l’artefact comme l’unité de discipline d’ingénierie alors que l’unité réelle est le processus de décision que l’artefact ne fait qu’enregistrer. Un modèle de tarification n’est pas dangereux parce qu’il vit dans un fichier .xlsx plutôt que dans une base de données ; il est dangereux parce que la séquence de jugements qui l’a produit — quelles hypothèses ont été testées, quels chiffres ont été écrasés à la main, sur quelle version une décision a réellement été prise — ne laisse de trace nulle part. Un remplaçant bien conçu qui reproduit la logique du tableur mais pas sa provenance n’a fait que déplacer le calcul sans toucher au risque réel, qui n’a jamais été l’arithmétique. Ce qui devrait changer, ce n’est pas le logiciel mais la discipline : un historique de versions et un registre de qui a changé quoi et pourquoi, attaché à la décision plutôt que vissé sur un format de fichier conçu, explicitement et avec succès, pour n’avoir rien de tel. Aucun outil ne s’est imposé largement sur cette base, ce qui mérite d’être noté en soi : cela suggère que le marché, jusqu’ici, a valorisé le cadeau du zéro cérémonie plus qu’il n’a redouté le coût non gouverné — jusqu’au moment où une division découvre combien de son risque reposait, sans audit, dans l’onglet de navigateur que seul un analyste bientôt retraité avait fini par comprendre entièrement.

J’ai une vraie dette envers Lotus 1-2-3, et pas une dette abstraite. Mon premier travail rémunéré, alors que j’étais étudiant, venait d’une petite entreprise qui avait besoin de suivre ses matériaux et ses coûts ; elle ne pouvait se permettre rien qui ressemble à un processus de développement formel, et son fonctionnement, à l’époque, était assez simple pour ne pas en avoir besoin. Je les ai convaincus d’utiliser un tableur plutôt qu’une application, et c’était la bonne décision, exactement à l’échelle où le cadeau dépasse le coût. La dette remonte un outil plus loin, jusqu’à celui qui a rendu possible l’existence de 1-2-3. Dan Bricklin, si jamais tu passes par le Massachusetts et que tu lis ceci : le café est pour moi.

Pour aller plus loin