devfool/studio
← blog
article2026-09-20·11 min de lecture

Le second quatre-vingt-dix pour cent : sur l'art de terminer

Établi d'atelier éclairé par une lampe, couvert d'épreuves corrigées et d'une maquette inachevée, devant un sablier presque vide

Il existe, dans tout projet, un instant très reconnaissable : celui où l'on se dit que c'est presque fini. Le manuscrit tient debout du début à la fin, le prototype se lance sans planter, la maquette ressemble enfin à quelque chose. On s'accorde une semaine, deux tout au plus, pour « boucler ». Puis trois mois passent, et la chose est toujours presque finie.

Ce phénomène est si régulier qu'il a des noms, des dates et une petite littérature. Il m'intéresse parce qu'il dit quelque chose d'inconfortable sur l'artisanat : commencer est une compétence, mais terminer en est une autre, distincte, et qu'on n'apprend jamais en commençant.

Une blague d'ingénieur qui n'en est pas une

Dans les couloirs des Bell Labs circulait une formule attribuée à l'ingénieur Tom Cargill. Elle tient en deux propositions absurdes : les premiers quatre-vingt-dix pour cent du code consomment les premiers quatre-vingt-dix pour cent du temps de développement ; les dix pour cent restants consomment les autres quatre-vingt-dix pour cent. Cent quatre-vingts pour cent au total. L'arithmétique est fausse, et c'est précisément le propos.

La formule a été diffusée par Jon Bentley dans sa rubrique « Programming Pearls » des Communications of the ACM, en septembre 1985, sous un intitulé qui mérite d'être retenu : la règle de crédibilité. Le Jargon File, cette mémoire écrite de la culture informatique, la conserve depuis sous le nom de ninety-ninety rule. On la cite en riant, dans les équipes, au moment exact où elle cesse d'être drôle.

Ce que j'y trouve de remarquable, c'est qu'elle ne parle pas de paresse ni d'incompétence. Elle décrit une asymétrie structurelle entre deux moitiés de travail qui portent le même nom. Écrire une fonction et faire tenir cette fonction au milieu de quarante autres ne sont pas la même activité. Écrire un chapitre et faire tenir ce chapitre au milieu de trente autres, non plus.

Deux lois publiées la même année

L'année 1979 a produit, presque simultanément, deux énoncés de la même intuition, dans deux mondes qui ne se parlaient pas.

Le premier vient d'un livre monumental : Gödel, Escher, Bach, de Douglas Hofstadter, qui recevra le prix Pulitzer de l'essai en 1980. On y trouve une loi autoréférentielle que tout créateur finit par se réciter : une tâche complexe prend toujours plus de temps qu'on ne l'avait prévu, y compris lorsqu'on a tenu compte de la loi de Hofstadter. La formule boucle sur elle-même, et cette boucle est son contenu : l'optimisme résiste même à la connaissance de l'optimisme.

Le second vient de la psychologie cognitive. La même année, Daniel Kahneman et Amos Tversky nomment le planning fallacy, le biais de planification : la tendance systématique à sous-estimer les délais, les coûts et les risques d'un projet, tout en surestimant ses bénéfices. Ce n'est pas un défaut de caractère, c'est un mode de fonctionnement par défaut du jugement. Nous planifions en nous représentant le déroulement nominal (le chemin où rien ne dérape) parce que c'est le seul scénario que nous savons nous raconter avec précision.

Le reste, les imprévus, les ajustements, les dix mille petits frottements, n'a pas de visage. On ne peut pas l'imaginer en détail, donc on ne le budgète pas. Et c'est lui qui occupe le second quatre-vingt-dix pour cent.

La vue du dedans et la vue du dehors

Kahneman a donné à ce problème une solution élégante, reprise et systématisée par le chercheur Bent Flyvbjerg pour les grands projets d'infrastructure : cesser d'estimer de l'intérieur.

La vue du dedans consiste à décomposer son propre projet et à additionner les durées supposées de chaque étape. Elle est naturelle, elle est motivante, et elle est presque toujours fausse. La vue du dehors consiste à traiter son projet comme un exemplaire d'une classe (« les romans que j'ai écrits », « les outils que j'ai terminés », « les livres-jeux de cette taille ») et à regarder combien de temps ces projets ont réellement pris. Flyvbjerg appelle cela la prévision par classe de référence. C'est une façon polie de dire : fiez-vous à votre historique plutôt qu'à votre enthousiasme.

L'exemple canonique est l'Opéra de Sydney. Le projet est estimé en 1957 à sept millions de dollars australiens, pour une inauguration prévue en janvier 1963. Le bâtiment ouvre en octobre 1973, après une facture d'une centaine de millions. Dix ans de retard sur un édifice dont la silhouette est aujourd'hui l'emblème d'un pays : la morale n'est pas qu'il ne fallait pas le construire, mais que personne, au départ, n'a regardé la classe de référence des bâtiments à géométrie inédite.

À l'échelle d'un studio d'une personne, les proportions changent, la mécanique non. Si les trois derniers projets ont demandé le double du temps annoncé, le quatrième le demandera aussi, et aucune bonne résolution n'y changera rien. La seule réponse honnête consiste à intégrer le coefficient dans le plan, pas dans la culpabilité.

Ce qui se cache réellement dans les dix pour cent

Je trouve plus utile encore de demander de quoi ces dix pour cent sont faits. Car ils ne sont pas une version plus lente du travail précédent : ils en sont le négatif.

Pendant quatre-vingt-dix pour cent du temps, on ajoute. On produit de la matière : des scènes, des salles, des fonctions, des personnages. Chaque ajout est gratifiant parce qu'il est visible. Pendant les dix pour cent restants, on ne produit presque plus rien : on fait tenir ensemble ce qui existe déjà. Et faire tenir ensemble est un travail dont la progression est invisible, y compris pour celui qui l'accomplit.

Dans un récit linéaire, cela s'appelle la continuité : le personnage dont les yeux changent de couleur au chapitre dix-neuf, la blessure qu'on oublie de faire cicatriser, la chronologie qui ne ferme pas. Dans un récit à embranchements, le problème est multiplié par la structure même : chaque paragraphe doit être cohérent non pas avec un passé, mais avec tous les passés possibles qui y mènent. Le lecteur arrivé par la ruelle ne sait pas ce que sait le lecteur arrivé par le port, et l'auteur, lui, est censé savoir les deux. C'est un travail de vérification combinatoire qui ne s'improvise pas à la fin.

Dans un logiciel, la même chose porte le nom de cas limites : l'entrée vide, le fichier corrompu, la connexion perdue au milieu d'une écriture. Aucun de ces cas n'est intéressant. Tous sont indispensables. Et leur nombre ne se déduit pas du nombre de fonctionnalités : il se déduit du nombre d'interactions entre elles, qui croît beaucoup plus vite.

D'où le sentiment si particulier de la dernière ligne droite : on travaille beaucoup, on avance réellement, et rien ne se voit. L'œuvre ne grandit plus, elle se resserre.

Polir n'est pas finir

Il y a cependant un piège symétrique, et c'est le plus dangereux des deux, parce qu'il ressemble à de la conscience professionnelle.

Quand l'ajout de matière s'arrête, beaucoup de créateurs remplacent la production par le polissage indéfini. On reprend la même scène pour la onzième fois, on déplace un bouton de trois pixels, on refait la palette. Le projet n'avance plus, mais il bouge, et le mouvement ressemble assez au progrès pour tromper celui qui le produit. Pire : la frontière se brouille entre finir et améliorer, et l'on se met à ajouter de nouvelles idées sous prétexte de finition, ce que les développeurs appellent le dérapage du périmètre.

Derek Yu, le créateur de Spelunky, en a fait le cœur de ses conseils aux indépendants. Pour lui, l'étape la plus difficile n'est ni l'idée ni le prototype : c'est d'apprendre à terminer des jeux de façon fiable et régulière, en dépassant le stade du game jam sans pour autant s'enliser des années dans un projet unique. Il va plus loin, et son conseil est contre-intuitif : si un jeu reçoit un accueil tiède, il vaut souvent mieux le finir plus vite et passer au suivant, plutôt qu'allonger le développement pour réparer ce qui est probablement un problème de fondation.

Traduit en langage d'atelier : la finition répare ce qui est cassé, elle ne sauve pas ce qui est mal conçu. Et seul un projet terminé vous apprend quelque chose, parce que seul un projet terminé rencontre quelqu'un.

Les métiers qui savent finir ont inventé un geste

Ce qui me frappe, c'est que les artisanats anciens n'ont pas résolu ce problème par la volonté. Ils l'ont résolu par un rituel.

L'édition a le bon à tirer. C'est une épreuve contractuelle : la dernière version du texte mis en page, que l'on relit, puis que l'on signe de sa main avec la mention et la date. Après cette signature, l'imprimeur tire l'ouvrage tel quel, et les corrections ultérieures coûtent de l'argent. Le geste n'a rien de mystique, et tout est là : il transforme une décision psychologique impossible (« est-ce parfait ? ») en un acte daté et irréversible. Le développement logiciel a réinventé la même chose sous le nom de gel des fonctionnalités : à partir de telle date, plus rien de neuf n'entre, on ne corrige que ce qui est cassé.

La littérature a produit la formulation la plus juste de cette idée, et c'est Paul Valéry qui l'a écrite : « Un poème n'est jamais achevé — c'est toujours un accident qui le termine. » Il ajoutait que l'accident s'appelle lassitude, demande de l'éditeur, ou poussée d'un autre poème. Valéry savait de quoi il parlait : Le Cimetière marin, dont on connaît une quinzaine d'états manuscrits, était encore en cours d'élaboration lorsque Jacques Rivière le lui a pris pour le publier dans La Nouvelle Revue française, en juin 1920. Le chef-d'œuvre le plus ciselé de la poésie française du siècle n'a pas été terminé : il a été arraché.

Je trouve cela curieusement réconfortant. Si Valéry avait besoin d'un Rivière, nous avons tous besoin d'une date.

Décomposer la fin comme on décompose le début

La programmation m'a appris une chose avant toutes les autres : un problème énorme devient praticable dès qu'on le découpe en sous-problèmes accessibles. On applique volontiers cette méthode au commencement d'un projet : le plan, le découpage en chapitres, l'architecture. On l'applique beaucoup plus rarement à sa fin, qu'on continue à traiter comme un bloc opaque nommé « finir ».

Or la fin se découpe très bien, à condition de s'y prendre tôt. Définir, avant même d'avoir commencé, ce que « terminé » voudra dire. Pas « bon », pas « satisfaisant » : terminé, sous forme de liste vérifiable. Écrire cette liste pendant que la lucidité est encore disponible, c'est-à-dire avant d'être épuisé par le projet. Y faire figurer ce qui n'est jamais dans les plans : la relecture intégrale, la vérification des chemins, les cas limites, les métadonnées, les fichiers d'accompagnement, la couverture, le dépôt, la page de description. Et tenir la liste pour close : tout ce qui arrive après elle est une idée pour le projet suivant, pas une correction du projet en cours.

Le reste est une affaire d'honnêteté arithmétique : accorder à ce dernier segment un budget de temps comparable à celui de tout ce qui précède. Pas par pessimisme : parce que c'est ce que montrent cinquante ans d'observations, d'une plaisanterie des Bell Labs aux devis des opéras.

Ce que vaut une chose terminée

Une œuvre inachevée n'existe que pour son auteur. C'est peut-être la seule raison suffisante de traverser le second quatre-vingt-dix pour cent : non pas la perfection, qui n'arrive jamais, mais le passage du côté des choses qui peuvent être lues, jouées, exécutées par quelqu'un d'autre. Rhaelos et Nous sommes un existent parce qu'à un moment, quelque chose a joué le rôle de Jacques Rivière.

Et vous, comment arrêtez-vous ? Par une date, par une liste, par la lassitude, ou parce que quelqu'un vous prend le manuscrit des mains ? Je crois que la réponse à cette question en dit plus long sur un créateur que son carnet d'idées.

Sources