Le Mythe du mois-homme

1Le tar pit : neuf fois plus cher que prévu

La métaphore d'ouverture résume tout. Les grands projets logiciels ressemblent aux tar pits de La Brea : les bêtes les plus fortes s'y débattent, et plus elles luttent, plus elles s'enfoncent. Ce n'est pas une cause unique. C'est « l'accumulation simultanée et interactive de facteurs ». (ch.1)

Avant même la métaphore, Brooks pose un fait arithmétique. Un programme écrit pour soi coûte une unité d'effort. Un programming systems product (testé, documenté, généralisé, intégrable à d'autres composants) en coûte neuf. Facteur 3x pour généraliser et documenter (il faut que quelqu'un d'autre puisse s'en servir), facteur 3x supplémentaire pour l'intégrer à un système (interfaces définies, budgets de ressources, tests de combinaisons).

Un exemple que vous connaissez : votre petit script qui marche sur votre machine, c'est 1 unité. Le publier en package npm que d'autres peuvent installer (doc, tests, cas limites, compatibilité multi-version) : ×3. L'intégrer proprement dans une grosse app avec ses contraintes de perf et ses interfaces : ×3 encore. Le « ça marche chez moi » et le « c'est en prod chez 10 000 personnes » sont séparés par ce facteur 9, et c'est lui que les équipes sous-estiment quand elles disent « c'est presque fini ».

2Le mois-homme mythique : l'unité qui ment

L'idée la plus citée du livre tient en une phrase : « Hommes et mois ne sont interchangeables que lorsqu'une tâche peut être partitionnée entre plusieurs travailleurs sans communication entre eux. » (ch.2)

Récolter du blé : ça marche. Dix personnes font dix fois plus en une journée. Écrire un module avec cinq dépendances mutuelles : non. La formule est n(n−1)/2 : deux développeurs ont un canal de communication, quatre en ont six, huit en ont vingt-huit. Chaque personne ajoutée multiplie les interfaces, et donc les malentendus, les attentes implicites, les réunions de clarification.

Brooks chiffre aussi la répartition réaliste du temps :

• 1/3 planification ;
• 1/6 codage ;
• 1/4 tests de composants ;
• 1/4 tests système.

Le codage ne représente qu'un sixième du travail total. Les chefs de projet qui donnent du temps « pour coder » en oubliant les tests se retrouvent avec un jalon raté et six options dont cinq empirent la situation.

3L'équipe chirurgicale : peu de cerveaux, beaucoup de bras

Sackman, Erikson et Grant ont mesuré la productivité de développeurs expérimentés dans les mêmes conditions. Résultat : un facteur dix entre le meilleur et le moins bon. Dix fois. La réponse logique n'est pas de recruter plus, c'est d'organiser le projet pour que quelques cerveaux décident et que les autres amplifient leur efficacité.

Harlan Mills propose l'équipe chirurgicale. Comme au bloc opératoire, un seul tient le scalpel : le chirurgien, c'est le chief programmer. Lui seul conçoit, code et décide. Tous les autres rôles existent pour lui donner ce dont il a besoin :

• Le copilote : connaît tout le code, peut prendre la relève à tout moment
• L'administrateur : gère contrats, locaux, personnel ; le chirurgien ne manage pas
• L'éditeur : prend la documentation brute et la met en forme finale
• Le toolsmith : construit et maintient les outils et l'environnement du chirurgien
• Le testeur : conçoit les cas de test, les exécute, maintient le harness
• Le language lawyer : connaît le langage par cœur ; le chirurgien consulte, il ne mémorise pas

L'idée n'est pas une hiérarchie : c'est protéger l'intégrité du travail. Sur deux cents personnes, vingt équipes chirurgicales, c'est vingt cerveaux à coordonner, pas deux cents.

La traduction 2026 est troublante : l'équipe chirurgicale, c'est exactement le développeur qui code avec l'IA. Vous tenez le scalpel (la conception, les décisions, le jugement) ; l'assistant joue le copilote (il connaît tout le code), le toolsmith (il génère les scripts), le language lawyer (il connaît l'API par cœur, vous le consultez). Le modèle de Mills, irréalisable en 1975 faute de « bras » assez bons et assez nombreux, devient enfin praticable le jour où les bras sont une IA.

4L'intégrité conceptuelle : un seul esprit

« L'intégrité conceptuelle est la considération la plus importante dans la conception d'un système. » (ch.4) Ce n'est pas une opinion, c'est la thèse centrale du livre.

La cathédrale de Reims a été construite sur huit générations. Chaque maître d'œuvre a sacrifié ses idées propres pour que l'ensemble reste d'un seul souffle. « Cette intégrité a été atteinte par l'abnégation de huit générations de bâtisseurs. » (ch.4)

Le contre-exemple, vous le vivez : une API où l'équipe A renvoie les dates en timestamp Unix, l'équipe B en ISO 8601, l'équipe C en « JJ/MM/AAAA » ; où chacune a inventé son propre format d'erreur et son propre nom pour « identifiant » (id, userId, uid). Chaque morceau marche tout seul ; l'ensemble est imprévisible et illisible. C'est exactement ce que Brooks appelle perdre l'uno animo (« d'un seul esprit », en latin).

Brooks ne dit pas que l'architecte doit tout implémenter. Il dit que l'architecture doit sortir d'un seul esprit, ou d'un très petit groupe. L'implémenteur peut améliorer l'exécution, pas la structure. Et sa formule « la forme libère » n'est pas un paradoxe : une fois la structure d'ensemble fixée, chacun sait où sa pièce s'emboîte, et code donc plus vite, pas moins.

5L'effet du deuxième système : la revanche des idées mises de côté

Le premier système d'un architecte est sobre, presque timide. Il sait qu'il ne maîtrise pas encore le sujet, alors chaque idée brillante qui lui vient en route (« et si on ajoutait aussi… ») part dans un tiroir, pour plus tard. Le deuxième système est le plus dangereux de sa carrière : le doute du débutant a disparu, et le tiroir est plein. Il le vide d'un coup. Résultat : un système surchargé de raffinements dont personne n'a besoin.

Brooks le montre sur OS/360 avec une image cruelle : le Linkage editor, « le dernier et le plus beau des dinosaures » (ch.5). Son équipe a passé des années à perfectionner une technique de chargement de programmes… au moment précis où le matériel évoluait et la rendait inutile. Même histoire avec TESTRAN, un outil de débogage poli avec amour pour une façon de travailler déjà en train de disparaître. Dans les deux cas, le perfectionnement a continué pendant que le monde autour changeait.

Vous avez déjà vécu cet effet : c'est le syndrome de la réécriture v2, celle où « cette fois on va tout faire bien » et qui embarque toutes les fonctionnalités dont on a rêvé pendant la v1. La leçon de Brooks n'est pas de se méfier des architectes seniors : c'est de donner au deuxième système un relecteur au regard neuf, quelqu'un qui n'était pas amoureux du premier.

6La tour de Babel, et la catastrophe au jour le jour

Babel avait tout : une mission claire, de la main-d'œuvre, des matériaux, du temps, une technologie maîtrisée. Elle a échoué par manque de communication et d'organisation. « Les catastrophes de calendrier, les fonctions ratées et les bugs système surviennent tous parce que la main gauche ne sait pas ce que fait la main droite. » (ch.7)

Le remède de Brooks : des structures de communication explicites : réunions régulières de briefing technique, workbook formel dès le premier jour. Et surtout, des jalons « définis avec la précision d'un couteau ». Pas « la phase de test est terminée », mais « le module X passe 100 % des cas de test du scénario Y ».

Car les projets prennent du retard d'une seule façon : « Comment un projet arrive-t-il à prendre un an de retard ? Un jour à la fois. » (ch.14) Un développeur malade. Les serveurs en panne. Une livraison de matériel retardée d'une semaine. Aucun événement isolé ne semble grave. Ensemble, ils font le retard, et les managers les cachent parce qu'ils espèrent résoudre avant d'escalader.

7Plan to throw one away : le prototype est inévitable

« Planifiez d'en jeter un ; vous le ferez de toute façon. » (ch.11) Ce n'est pas du cynisme. En génie chimique, personne ne passe directement d'un résultat de laboratoire à une usine de deux millions de gallons par jour. On construit d'abord une installation pilote. Les informaticiens, dit Brooks, n'ont pas encore appris cette leçon.

Plus la maintenance avance, plus l'entropie augmente : chaque correction a 20 à 50 % de chances d'introduire un autre défaut (ch.11). Les modules touchés croissent de façon exponentielle à chaque release, même si le nombre de modules croît linéairement. Le code s'éloigne de sa structure d'origine à chaque intervention. Les sprints agiles et le concept de MVP sont la réponse directe à cette loi : construire en incréments pour ne pas livrer le prototype à des clients.

8No Silver Bullet : la complexité est essentielle

Le titre vient du folklore : la balle en argent est la seule arme qui tue le loup-garou, cette créature familière qui se transforme sans prévenir en monstre. Pour Brooks, le projet logiciel EST le loup-garou : familier, innocent, puis soudain monstrueux (délais explosés, budgets engloutis, bugs). Et toute l'industrie réclame la balle en argent, le remède miracle qui l'abattrait d'un coup. L'essai de 1987, ajouté au livre en 1995, démontre qu'elle n'existe pas.

L'argument repose sur une distinction d'Aristote : toute chose a une essence (irréductible) et des accidents (contingents, modifiables). Les difficultés accidentelles du logiciel (outils lents, langages bas-niveau) ont déjà été massivement réduites par cinquante ans de progrès. Ce qui reste est essentiel.

Brooks identifie quatre propriétés essentielles du logiciel, que rien ne peut faire disparaître :

• Complexité : aucun logiciel n'a deux composants identiques ; la complexité croît de façon non-linéaire avec la taille
• Conformité : le logiciel doit se plier aux caprices de systèmes humains hétérogènes, sans loi physique unificatrice
• Changeabilité : tout logiciel qui réussit est modifié en permanence ; le succès amplifie la pression au changement
• Invisibilité : aucun diagramme ne représente fidèlement un système ; l'esprit humain ne peut en voir qu'une coupe à la fois

Dans l'essai, Brooks passe en revue tous les remèdes miracles de son époque : la programmation objet, l'intelligence artificielle, les ateliers de génie logiciel (les outils CASE), la vérification formelle (prouver mathématiquement qu'un programme est correct). Verdict à chaque fois : utile, mais aucun ne rendra le développement dix fois plus productif en dix ans.

Il avait raison. Vingt ans plus tard, en 2007, un panel d'OOPSLA (la grande conférence de la programmation objet) lui a donné raison publiquement. Sa seule piste sérieuse, en 1995 : ne plus tout écrire soi-même mais réutiliser des composants existants, ce qu'on appelle aujourd'hui l'open source et les APIs. Un vrai progrès, oui ; le miracle ×10, non.