Dans un exploit défiant la logique binaire, nous avons obtenu un entretien exclusif avec le légendaire Frederick Brooks Jr ! Le père de la loi la plus célèbre de la gestion de projet logiciel nous accorde une interview pour discuter de l'état de l'art, cinquante ans après la publication de son ouvrage culte, The Mythical Man-Month.
Thibaut Rety : Professeur Brooks, merci de nous accorder cet entretien. Votre livre The Mythical Man-Month reste encore un incontournable pour les ingénieurs du monde entier. Cinquante ans plus tard, on pourrait le juger obsolète. Qu'en est-il vraiment ?
Frederick Brooks : L'étonnant n'est pas que le livre soit toujours pertinent, mais que nos organisations continuent de commettre les mêmes erreurs avec une constance admirable. L'Homme-Mois est un mythe, une unité de mesure fallacieuse qui suppose que les hommes et les mois sont interchangeables. Or, l'expérience, notamment celle du projet OS/360 chez IBM, m'a appris que le développement logiciel n'est pas une tâche mécanique, mais un exercice de création complexe.
Thibaut Rety : Cela nous amène à votre fameuse loi, "Ajouter des personnes à un projet logiciel en retard accroît son retard". Pourriez-vous nous en rappeler la genèse et le contexte pour nos lecteurs ?
Frederick Brooks : Avec plaisir. Cette loi est née de l'observation directe et douloureuse. Lorsque nous développions le système d'exploitation OS/360, nous avons pris du retard. Le réflexe naturel de la direction, comme dans toute industrie, a été d'allouer plus d'ingénieurs au projet pour "rattraper" le temps perdu. Le résultat fut catastrophique : le projet prit encore plus de retard.
L'explication tient en trois points fondamentaux :
- L'intégration et la formation : Les nouveaux arrivants ne sont pas immédiatement productifs. Il faut qu'ils montent en compétence sur le projet. Et qui les forme ? Les développeurs les plus expérimentés, qui sont par conséquent détournés de leur travail principal. L'effort à court terme est donc négatif.
- La surcharge de communication : Le véritable cancer des projets. Le nombre de canaux de communication dans une équipe n'augmente pas de façon linéaire, mais selon la formule n(n-1)/2. Une équipe de 5 personnes a 10 canaux de communication. Passez à 10 personnes, et vous bondissez à 45 canaux ! Le temps passé à se coordonner, en réunions, par emails ou à résoudre des conflits d'intégration explose.
- La divisibilité de la tâche : C'est le point le plus simple à comprendre. Certaines tâches sont séquentielles par nature et ne peuvent être parallélisées. L'analogie que j'ai utilisée à l'époque est toujours valide : neuf femmes ne peuvent pas faire un bébé en un mois.
Thibaut Rety : Pourtant, aujourd'hui, le monde du logiciel est dominé par les méthodes agiles qui prônent des équipes et des itérations rapides. Est-ce que cela ne contredit pas votre loi ?
Frederick Brooks : Au contraire ! Je vois ces méthodes comme une excellente réponse à la complexité que je décrivais. L'agilité ne contredit pas ma loi, elle en est une formidable confirmation. Elle admet que la communication est cruciale et difficile, c'est pourquoi elle favorise de petites équipes et une communication constante (daily stand-ups). En découpant le travail en sprints courts, elle rend le retard visible beaucoup plus tôt, avant que la tentation d'ajouter une armée de développeurs ne devienne irrésistible. C'est une discipline pour gérer le mal, pas une potion magique pour l'éradiquer.
Thibaut Rety : Dans votre essai "No Silver Bullet", vous affirmiez qu'il n'y avait pas de "balle d'argent", pas de solution miracle pour décupler la productivité. Que penseriez-vous aujourd'hui de l'Intelligence Artificielle générative qui promet de révolutionner le développement ?
Frederick Brooks : Ah, la "balle d'argent" moderne ! Le concept reste le même. Je distinguais la complexité essentielle (la conception intellectuelle de la logique) de la complexité accidentelle (les outils, les frameworks, le boilerplate). L'IA est, je pense, un outil particulièrement efficace pour réduire la complexité accidentelle. Elle peut écrire des tests, générer du code répétitif, expliquer des erreurs…
Cependant, la complexité essentielle demeure. Définir ce qu'un logiciel doit faire, concevoir son architecture conceptuelle, cela reste une tâche profondément humaine. L'IA est un partenaire extraordinairement doué, un exosquelette pour l'esprit de l'ingénieur, mais pas un substitut. La balle n'est pas en argent, mais elle est certainement très bien usinée.
Thibaut Rety : Un dernier conseil pour un chef de projet en 2025 qui sentirait son planning déraper ?
Frederick Brooks : N'ajoutez pas d'hommes. Jamais. Redéfinissez le périmètre. Repoussez la date de livraison. Ou, si vous le devez absolument, restructurez l'équipe pour créer une "équipe chirurgicale", un petit groupe d'experts mené par un "chirurgien" (le lead dev), qui se concentre sur la partie critique, isolé du bruit du reste du projet. Préservez à tout prix l'intégrité conceptuelle de votre produit.
Thibaut Rety : Professeur Brooks, merci infiniment.
Même après son départ, les enseignements de Fred Brooks résonnent avec une précision troublante. Ils nous rappellent qu'en dépit des avancées technologiques, la création de logiciels reste, et restera sans doute toujours, une entreprise fondamentalement humaine.
Contributeurs aux projets Wikimedia
alefebvre
