En ingénierie logicielle, faire évoluer un projet ne fonctionne pas comme augmenter une ligne de production. Recruter davantage de développeurs peut accroître la capacité globale sans accélérer proportionnellement la livraison d’une seule fonctionnalité ou d’un seul projet.

Fred Brooks a formulé cette idée dans The Mythical Man-Month : ajouter des personnes à un projet logiciel en retard tend à le retarder davantage. Une femme peut porter un bébé pendant neuf mois, mais neuf femmes ne peuvent pas le faire en un mois. Cette loi ne parle pas de biologie ; elle décrit les contraintes inhérentes au travail complexe.

Pourquoi ajouter des personnes produit souvent l’effet inverse

La loi de Brooks avance trois raisons :

  1. Temps d’intégration. Les nouveaux membres doivent apprendre le code, le domaine et le contexte. Les personnes expérimentées interrompent leur travail pour les accompagner, ce qui réduit temporairement la productivité et augmente le risque de défauts.
  2. Coût de communication. Les chemins de coordination croissent rapidement. Trois personnes ont trois connexions possibles ; six en ont quinze. Réunions, alignements et transferts de contexte consomment le temps de livraison.
  3. Divisibilité limitée. Tout travail ne se découpe pas en parties indépendantes. La conception, l’architecture et l’intégration exigent souvent une séquence cohérente. Fragmenter un problème complexe en petits tickets ne garantit pas une solution cohérente.

À partir d’un certain point, le coût de coordination et d’intégration dépasse le bénéfice des ressources supplémentaires.

Plaidoyer pour de petites équipes concentrées

Les approches agiles défendent depuis longtemps les petites équipes pluridisciplinaires. Jeff Bezos a popularisé chez Amazon la règle de l’équipe à deux pizzas : si deux pizzas ne suffisent pas à nourrir l’équipe, elle est probablement trop grande.

Une petite équipe communique moins, décide plus vite et conserve une responsabilité claire. Les analyses de projets logiciels situent souvent entre quatre et cinq personnes une zone d’efficacité. Le chiffre varie selon le domaine, mais la tendance reste la même : agrandir le groupe n’apporte pas un gain linéaire et peut accroître les défauts et les coûts.

Mon nombre pratique : trois développeurs

Après avoir expérimenté plusieurs compositions comme CTO chez EITS, j’ai retenu une variante pragmatique : trois développeurs peuvent produire des résultats remarquables pendant un sprint de deux semaines.

Un trio ne compte que trois chemins de communication. Il peut s’organiser sans coordination excessive, et chacun garde un sens clair de sa responsabilité. Le partage du contexte, les revues et les décisions de conception deviennent plus simples.

Il ne s’agit pas seulement d’efficacité, mais aussi de créativité. Les problèmes complexes profitent d’une concentration profonde. Avec trop de participants, le travail se fragmente et la vision d’ensemble se perd. Un trio peut collaborer sur l’architecture, l’implémentation et les tests tout en préservant la cohérence.

Les contraintes extérieures à l’équipe

Ajouter des développeurs suppose qu’il existe assez de travail parallélisable. Dans la pratique, les exigences métier, la conception produit et les décisions des parties prenantes limitent souvent le débit.

Sans tâches bien définies, les ingénieurs supplémentaires attendent ou travaillent sur des hypothèses fragiles, ce qui augmente les reprises. La créativité et la conception ne progressent pas non plus linéairement avec le nombre de participants.

Résister à l’envie d’agrandir l’équipe

  • Investissez tôt. Renforcer une équipe en fin de projet est particulièrement coûteux.
  • Privilégiez la capacité à l’effectif. Une personne expérimentée et adaptée au contexte peut apporter davantage que plusieurs recrutements sans le bon bagage.
  • Clarifiez architecture et exigences. De nombreux retards viennent d’exigences ambiguës ou de mauvaises frontières architecturales.
  • Préservez l’autonomie. Pour plusieurs petites équipes en parallèle, définissez des interfaces claires et réduisez leurs dépendances.

Conclusion

La métaphore du bébé perdure parce qu’elle résume la dynamique centrale : tout travail ne peut pas être comprimé en ajoutant des personnes. Au-delà d’une limite naturelle de parallélisation, la communication, l’intégration et la charge cognitive ralentissent le projet.

Avant d’agrandir une équipe pour respecter une échéance, demandez-vous si les ressources supplémentaires feront réellement avancer la livraison ou ajouteront simplement de la complexité. Parfois, la stratégie la plus efficace consiste à donner à une petite équipe des objectifs clairs, de l’autonomie et la confiance nécessaire pour livrer.