La productivité des développeurs n'a jamais vraiment progressé (et pourquoi ça va changer)

Frederick Brooks publie en 1975 The Mythical Man-Month, un recueil d'essais devenu culte en informatique et en gestion de projets.

Ce livre traînait dans ma bibliothèque et, après l'avoir relu récemment, j'ai été profondément marqué. En le refermant, j'ai réalisé qu'en vingt-cinq ans de carrière, dans les différentes entreprises que j'ai côtoyées, j'ai constamment observé les mêmes schémas se répéter, ceux-là mêmes que Brooks décrit et qui ruinent la productivité des projets. Moi le premier, en tant que manager ou team lead, j'ai souvent essayé, avec mes collègues, de maintes manières et avec différentes approches, d'améliorer notre productivité. Mais systématiquement, quelle que soit l'entreprise, le projet ou l'équipe, et malgré les meilleures volontés, toujours, un retard survenait, un imprévu jaillissait, et au bout du compte, à chaque fois, la roadmap mentait.

Comment est-ce possible ? Notre industrie a pourtant fait du chemin depuis le Cycle en V… Il y a eu la révélation de l'agilité, le Scrum Manifesto et tant de méthodes qui ont fleuri.

Oui, mais soyons lucides : malgré tout ça, nous en sommes toujours au même point. Au même point que ce que décrivait Brooks en 1975 :

• Les projets informatiques sont toujours en retard.
• Faire grossir une équipe ne la rend pas plus rapide (spoiler : c'est l'inverse).
• Estimer le temps nécessaire à la réalisation (totale et effective) d'un projet est quasi impossible (on se trompe systématiquement).

Pourquoi ? Parce que toutes les méthodes modernes n'ont pas changé les trois raisons fondamentales qui provoquent cet état de fait.

1. La loi de Brooks : ajouter des gens ralentit le projet

Le premier piège, c'est le mythe de l'homme-mois : croire qu'on peut compenser le retard d'un projet en y ajoutant des développeurs. En réalité, plus une équipe grandit, plus la communication devient un gouffre. Ce principe, connu sous le nom de loi de Brooks, énonce qu'ajouter des personnes à un projet en retard ne fait que le retarder davantage. La raison est mathématique : le coût de la coordination explose de manière exponentielle avec la taille de l'équipe, car le nombre de canaux de communication (n × (n - 1) / 2) augmente de façon démesurée.

Par exemple, une équipe de 5 personnes implique 10 canaux de communication distincts (pour que chaque personne échange avec chacune des autres). À 10 personnes, ce nombre monte à 45, et à 15, 105…

Bien sûr on ne s'attend pas à ce que chaque personne parle systématiquement à toutes les autres, alors on invente… les réunions. Mais le problème de fond n'est pas résolu. La communication reste de plus en plus complexe à mesure que l'équipe grandit. On connaît tous le « meeting qui aurait pu être un email », les discussions qui dérivent, la réunion pour préparer la réunion, ou encore celle qu'on ne cesse de refaire tous les six mois… Sans parler du temps passé à synchroniser les agendas, à jongler entre les personnes sur site et les autres en visio (ce qui introduit d'autres problèmes de communication), etc.

Mais au-delà de tous ces points, le problème est plus profond : la réunion crée une illusion de clarté, ce que les chercheurs en sciences cognitives appellent l'illusion de transparence. On se réunit à huit en pensant que l'information sera partagée de manière homogène. En réalité, c'est l'inverse qui se produit, à cause de plusieurs biais cognitifs :

• Le biais de conformité : une fois qu'une idée est émise (souvent par la personne la plus assurée), il devient difficile de la contredire.
• Le syndrome de l'imposteur : par peur de paraître incompétent, on tait ses doutes ou ses questions.
• Le biais de statut : les personnes les plus gradées ou les plus extraverties monopolisent la parole, créant un faux consensus qui masque les désaccords latents.

Au final, plus on ajoute de membres, plus l'enjeu de communication cannibalise le temps de travail, mais surtout, plus les décalages d'information s'installent. Ces malentendus invisibles se transforment en imprévus, en blocages et en bugs qui émergent, presque toujours, beaucoup trop tard.

2. Le code n'est que la partie émergée de l'iceberg

Le second piège, et non des moindres, est notre tendance collective à la sous-estimation. C'est un biais cognitif si répandu qu'il porte un nom : le biais de planification. Il décrit notre propension à sous-évaluer systématiquement le temps nécessaire pour accomplir une tâche, même en sachant que les tâches similaires ont pris plus de temps par le passé.

Si je devais prendre un exemple récent et spectaculaire, je citerai le cas d'Apple Intelligence, dont les fonctionnalités d'IA ont été repoussées à 2026, alors qu'elles devaient initialement sortir avec iOS 18. Le retard a été tel qu'Apple a dû annuler une campagne publicitaire déjà en production, un aveu d'échec rare pour une entreprise si coutumière de l'excellence en matière de produit.

On pourrait aussi parler du fiasco de Google avec sa Privacy Sandbox, projet annoncé en grande pompe puis maintes fois repoussé, pour finalement être abandonné en 2025 après des années de développement et un bouleversement monumental de l'industrie du marketing en ligne.

Et on peut tout à fait remonter bien plus loin, avec le cas emblématique de Netscape 6, refonte totale du navigateur le plus populaire de son temps, qui finira par s'étaler sur plus de deux ans de développement, pour finalement sortir un produit si instable qu'il précipitera la chute de l'entreprise.

Depuis la publication de The Mythical Man-Month par Brooks il y a cinquante ans, force est de constater que nous n'avons pas fait de progrès significatifs sur ce point. Les méthodes ont évolué, les langages de programmation et les environnements de développement se sont considérablement améliorés, mais les projets finissent toujours par faire mentir les roadmaps.

D'ailleurs, si on regarde bien, la situation a même évolué vers une normalisation des retards. Les engagements sur les livrables se sont progressivement estompés. Les éditeurs de logiciels, particulièrement dans le B2B, ont adopté des cycles de développement plus flous : "Beta", "Private Preview", "General Availability". Les roadmaps communiquées aux clients évitent désormais tout engagement temporel précis et se contentent d'indiquer des objectifs annuels, toujours assortis de clauses de non-responsabilité…

En somme, le retard est donc devenu la norme. D'une certaine façon, (inconsciemment ?) nous l'avons institutionnalisé. Scrum en est l'illustration parfaite : face à l'échec systématique du modèle en cascade et de ses retards chroniques, nous avons en réalité supprimé les engagements à long terme.

En découpant les projets en sprints de quelques semaines, Scrum offre une solution élégante à court terme : davantage de micro-engagements réalistes, plus de flexibilité, plus d'adaptabilité. C'est indéniablement une amélioration par rapport aux promesses irréalistes du Cycle en V.

Mais cette approche induit un coût caché non négligeable : l'abandon de toute vision stratégique à long terme.

J'imagine que cette formule peut choquer, mais prenons un peu de recul : en se concentrant sur l'immédiat, nous avons sacrifié la capacité à planifier et à ancrer une direction claire et pérenne. Le projet devient une succession de sprints sans véritable destination définie, où l'équipe avance sans certitude sur le point d'arrivée. Certes, on peut tout à fait greffer une vision long terme par-dessus Scrum. C'est une pratique courante : le backlog est nourri d'idées, le Product Owner donne le cap, etc. Oui. Mais dans les faits, la manière de fonctionner induit une tendance au changement de sujets. Le vent souffle un peu fort par ici, on priorise cette fonctionnalité, il change de sens trois semaines plus tard, un autre objectif prend le lead, etc.

La question mérite à mon sens d'être posée : est-ce que l'agilité n'a finalement pas – elle aussi – créé un biais ? Sommes-nous en réelle capacité d'anticiper un grand objectif stratégique lorsqu'on part en Scrum pour des années de développement ?

Je ne prétends pas avoir la réponse. Mais je réalise en écrivant ces lignes que cette question n'est quasiment jamais posée.

Brooks (en 1975 !) pointait déjà du doigt la racine du mal concernant la planification erronée de projets. Il dit, dès le début du livre, qu'un projet se compose de quatre grands types de tâches (toujours d'actualité aujourd'hui, cinquante ans plus tard) :

1. La conception du travail à réaliser (les specs)
2. L'écriture du code
3. Les tests unitaires (tests de chaque composant, tests API)
4. Les tests d'intégration (tests du système complet, ou black box)

Or, il précise que ces quatre types de tâches ne prennent pas du tout le même temps au sein du projet. Les temps se répartissent ainsi :

• Conception : 1/3 du temps
• Écriture du code : 1/6 du temps
• Tests unitaires : 1/4 du temps
• Tests d'intégration : 1/4 du temps

Ainsi, selon Brooks, seulement 1/6e du temps total est consacré à l'écriture du code (environ 17 %). À l'inverse, la moitié (50 % !) du temps du projet sera in fine utilisée pour tester et valider la cohérence d'ensemble (et procéder aux innombrables ajustements qui vont s'imposer pour que le tout fonctionne). La moitié du temps passée à tester, valider, corriger…

Pire : Brooks précise que si on se trompe rarement sur l'estimation du temps nécessaire à coder une partie, en revanche, on néglige (voire on oublie littéralement) d'estimer la partie consacrée aux tests… et celle-ci sera la plus importante du temps passé.

C'est même l'inverse que l'on constate dans nombre d'entreprises. Souvent, le test et la validation sont les parents pauvres des projets.

Lorsqu'on présente un planning à sa direction, on veut montrer du concret, et inconsciemment, on omet de parler des tests, car cela sous-entendrait que c'est du luxe ou du temps perdu. On peut même être tenté de penser que si on a besoin de tests, c'est que le développeur ou la développeuse a mal travaillé. Une telle affirmation est révélatrice d'une profonde méconnaissance du métier. Je renvoie au découpage de Brooks : la personne qui développe pourra exceller dans ses tests, mais elle ne pourra pas – par définition – valider l'entièreté du système, puisque son intervention se cantonne à une de ses multiples parties.

3. Le logiciel, cet objet immatériel et insaisissable

La troisième raison pour laquelle nous estimons si mal la durée des projets informatiques est peut-être la plus profonde : le logiciel est un objet abstrait. Impalpable. Selon Brooks, cette nature immatérielle change tout. Elle nous expose à des biais cognitifs puissants, comme l'heuristique de disponibilité.

Contrairement à une voiture ou une maison, un projet informatique s'élabore à partir du monde des idées. On pense, on conceptualise, on modélise, et tout cela s'incarne dans le code. Pour notre cerveau, conditionné au monde physique, le résultat visible (un écran qui fonctionne) est tangible, tandis que la complexité sous-jacente reste abstraite.

Ce biais nous pousse à surestimer ce qui nous vient facilement à l'esprit (la fonctionnalité visible) et à sous-estimer ce qui est flou (les tests, les effets de bord, les imprévus techniques, cette API qui ne se comportera pas tout à fait comme prévu). On pense avoir fait 80 % du travail alors qu'on a seulement posé les fondations (le fameux 1/6e de Brooks).

Mais cette nature immatérielle crée un second obstacle, encore plus redoutable, à l'industrialisation de notre métier : rien n'est vraiment réutilisable.

Malgré l'abondance de bibliothèques de code, de frameworks modernes et de templates, chaque projet réinvente une part immense de sa propre logique. Comparez avec le monde physique : un constructeur automobile, pour son nouveau modèle, réutilisera les mêmes machines-outils, les mêmes matériaux, les mêmes procédés d'assemblage, les mêmes expertises standardisées. Son innovation est incrémentale, bâtie sur un socle industriel solide et éprouvé.

En logiciel, chaque projet est une redécouverte. On repart (presque) de zéro, car l'essentiel du travail n'est pas dans l'assemblage de briques de Lego, mais dans la création des connecteurs logiques uniques qui les lient. Ce presque pareil qui semble si anodin est en réalité le cœur du problème. C'est lui qui coûte aussi cher, sinon plus, qu'une création ex nihilo.

Le logiciel ne se construit pas, il se cultive. Tiens : je réalise que j'utilise très souvent le terme « organique » pour parler de mon approche de la programmation et du développement. Je viens de faire le lien… Oui, un soft, ça se cultive… Il pousse de manière organique, des branches imprévues jaillissent par endroits, ses racines s'enchevêtrent, son tronc bifurque.

L'IA, ou la première rupture en 50 ans

Cinquante ans de méthodologies, de frameworks et de débats passionnés pour en arriver... au même point. Malgré tous nos progrès évidents en abstraction, modularisation, tenue de charge et automatisation, la loi de Brooks reste implacable : les équipes peinent de plus en plus à avancer à mesure qu'elles grossissent, nos estimations sont toujours trop optimistes, et la nature abstraite du code rend l'ensemble d'autant plus difficile à appréhender.

Mais pour la première fois en un demi-siècle, une rupture semble apparaitre. L'IA générative, couplée à la puissance d'outils agentiques comme Cursor, peut probablement incarner le premier véritable gain de productivité en informatique.

Comme je l'explore dans mon article sur la révolution du Vibe Coding, l'IA ne nous rend pas simplement plus rapides. Elle change la nature même du travail de développement en s'attaquant aux trois blocages fondamentaux :

1. La complexité de la communication (Loi de Brooks) ? L'IA la court-circuite d'une manière radicale : l'équipe est réduite à son minimum. Cela pose de sérieuses questions sociétales, mais sous le prisme du problème auquel on s'intéresse ici, c'est un début de solution. Plus besoin d'être 15 là où on peut être 3… 

2. La sous-estimation chronique ? L'IA ne supprime pas notre biais, mais elle en réduit drastiquement l'impact. En générant et en testant le code à une vitesse surhumaine, elle compresse le cycle de développement. Les 84 % de l'iceberg immergé sont explorés en heures plutôt qu'en semaines, rendant nos erreurs d'estimation moins pénalisantes.

3. La nature immatérielle du logiciel ? C'est le terrain de jeu de l'IA. Elle excelle à manipuler l'abstraction, à créer ces "connecteurs logiques" qui constituaient jusqu'alors le cœur de notre effort. Le développeur peut enfin prendre de la hauteur pour se concentrer sur l'essentiel : l'architecture, le design, la vision produit.

Le goulot d'étranglement n'a jamais été la vitesse à laquelle nous tapions du code. Le véritable frein a toujours été la vitesse à laquelle nous pouvions penser, communiquer et structurer des systèmes complexes.

Tom Blomfield, membre du board de Y Combinator, a dit que les programmeurs étaient jusqu'ici des fermiers très bien payés qui moissonnaient à la main… et qu'on venait d'inventer la moissonneuse-batteuse.

Cette analogie a bien évidemment fait hurler nombre de programmeurs sur X, certainement heurtés par l'idée que le métier puisse à ce point être transformé. Plutôt que de craindre ou rejeter cette révolution en marche, j'aurais tendance à l'accueillir avec ferveur. Peut-être sommes-nous en train de voir naître la première révolution industrielle de l'ère informatique, et si c'est le cas, c'est passionnant à vivre.