L'équipe chirurgicale

Dans le développement logiciel, il y a des textes qui, même des dizaines d'années plus tard, sont toujours d'actualité car ils ne sont pas aveuglés par la hype du moment mais traitent de sujets intemporels.

Le mythe du mois homme de Fred Brooks est de ceux là. Il date de 1975. On y trouve de nombreuses idées et celle de l'équipe chirurgicale me semble particulièrement pertinente en 2025.

L'idée majeure, c'est que le code d'une partie d'un système est placé sous la responsabilité d'un programmeur en chef, le chirurgien, qui écrit la majorité du code de la partie concernée, et que ce programmeur en chef dirige une équipe qui l'aide à faire son boulot. On parle d'équipe chirurgicale par analogie à ce qui se passe dans une salle d'opération : le chirurgien opère lui-même et dirige l'équipe qui l'assiste.

Le concept n'est pas de Brooks lui-même mais d'un de ses collègues chez IBM, Harlan Mills, dans un texte de 1971 intitulé Chief Programmer Teams: Principles and Procedures¹. Sa raison d'être est de maitriser la réalisation d'un gros projet sans faire reposer les choix de conception sur un trop grand nombre de personnes.

En 2025, une telle organisation semble impensable. Les développeurs de logiciels sont plus souvent vus comme des ouvriers du code que comme des chirurgiens. Mais ça ne veut pas dire qu'une telle organisation ne serait pas utile. En fait, par certains aspects, elle est déjà en train de se mettre en place.

L'assistant, appelé aussi Archiviste, se concentre sur l'historisation et l'archivage de tous les codes sources et de tous les binaires au cours du temps. Dans les faits, tous les développeurs actuels ont des assistants pour cela : ils s'appellent git, subversion, nuget, npm, pipy, etc. On a transformé ce rôle tenu, il y a longtemps, par un humain en outils informatiques suffisamment avancés.

L'outilleur est chargé de fournir au programmeur tous les outils, génériques ou spécialisés, dont celui-ci a besoin pour faire son travail. Dans les petites structures, les programmeurs doivent souvent tenir ce rôle eux-mêmes mais, dans des organisations suffisamment grandes, on trouve désormais des équipes de developper experience pour faire ce travail.

Pour les autres rôles, on n'y est pas encore, l'écriture de la documentation technique (le rédacteur), l'écriture des jeux de tests (le testeur) et la connaissance des bonnes pratiques d'une stack technique (le spécialiste du langage) sont des tâches, soit dévolues au programmeur lui-même, soit prises en charge par des personnes ou des équipes sur lesquelles le programmeur n'a que peu de prise.

Mais l'IA générative est très prometteuse sur ces tâches là, très ciblées, et où le programmeur peut se contenter d'évaluer le résultat.

Reste le copilote. Dans le modèle de Mills, le copilote est l'alter ego du chirurgien. Il a une connaissance tout aussi complète du code, il confronte le chirurgien dans ses choix et il est capable, dans le pire des cas, de prendre le relai si le chirurgien venait à disparaître.

Pour les développeurs qui pratiquent le pair programming, cette situation est anodine. Dans le pair programming, on parle déjà de pilote pour le développeur qui a le clavier en mains et de copilote pour celui qui l'accompagne. La seule différence est que, contrairement à l'équipe chirurgicale, les développeurs permutent régulièrement les rôles de pilote et copilote.

Donc, si on a un contexte favorable, on n'est déjà pas si loin de cette équipe chirurgicale. Le plus gros risque est, à mon avis, de se tromper dans l'utilisation de l'IA. Le nom copilot donné par github à son outil d'assistance à la programmation est d'ailleurs assez stupide. Les assistant de programmation propulsés à l'IA générative ont un rôle à jouer pour aider les développeurs mais pas n'importe lequel. Ils sont très efficaces pour aider sur des tâches ciblées mais ils sont incapables de concevoir un logiciel.