La loi de Conway et la forme des organisations

Ce que Conway a réellement dit

En avril 1968, le magazine Datamation a publié « How Do Committees Invent? » de Melvin Conway, programmeur et consultant en informatique. Sa conclusion est la phrase aujourd’hui connue sous le nom de loi de Conway : les organisations qui conçoivent des systèmes sont contraintes de produire des conceptions qui sont des copies des structures de communication de ces organisations. Le nom est venu plus tard : Fred Brooks a cité l’article dans The Mythical Man-Month (1975) et a appelé l’idée la loi de Conway.

L’argument de Conway est plus précis que le slogan. Un système se compose de sous-systèmes reliés par des interfaces. Pour que deux sous-systèmes se connectent, les personnes qui les conçoivent doivent avoir négocié et convenu de cette interface : elles doivent donc avoir communiqué. Si les concepteurs de deux sous-systèmes ne communiquent pas, il n’y a aucune interface sur laquelle s’entendre. Il existe donc une correspondance qui préserve la structure (Conway employait le terme mathématique d’homomorphisme) entre le graphe du système et le graphe de l’organisation qui l’a conçu. Son exemple : une société de recherche sous contrat disposait de huit personnes pour écrire un compilateur COBOL et un compilateur ALGOL. Cinq ont été affectées au COBOL et trois à l’ALGOL. Le compilateur COBOL fonctionnait en cinq phases ; le compilateur ALGOL en trois.

Deux autres points de l’article sont souvent oubliés. D’abord, Conway précisait explicitement que « système » s’entend au sens large : cela s’applique à tout objet conçu, pas seulement au logiciel. Ensuite, sa conclusion pratique portait sur la flexibilité. Comme la première conception est rarement la meilleure, et comme une organisation tend à figer sa structure tôt (une fois les équipes formées, la conception est déjà en partie décidée), il soutenait que les organisations de conception devaient rester légères et souples, et s’organiser selon la communication dont la conception a réellement besoin.

Les données probantes : l’hypothèse du miroir

Pendant des décennies, la loi de Conway s’est surtout appuyée sur des anecdotes. Depuis les années 2000, des chercheurs l’ont mise à l’épreuve, généralement sous le nom d’hypothèse du miroir (mirroring hypothesis) : les dépendances techniques d’un produit correspondront aux liens organisationnels (communication, proximité géographique, appartenance à un même employeur) entre les personnes qui le construisent.

L’étude la plus connue dans le domaine du logiciel est celle d’Alan MacCormack, Carliss Baldwin et John Rusnak, publiée dans Research Policy en 2012 sous le titre « Exploring the duality between product and organizational architectures: a test of the mirroring hypothesis ». Ils ont comparé des paires de produits aux fonctions similaires, l’un construit par une organisation fortement couplée (une entreprise commerciale avec une équipe réunie sur un même site) et l’autre par une organisation faiblement couplée (une communauté open source distribuée) : par exemple deux logiciels de gestion financière, deux traitements de texte, deux bases de données, et Linux comparé à des noyaux de systèmes d’exploitation commerciaux. Ils ont mesuré la modularité par le coût de propagation, c’est-à-dire la part moyenne des fichiers d’un système qu’une modification d’un fichier peut affecter directement ou indirectement. Dans chaque paire, le produit de l’organisation faiblement couplée était plus modulaire et, dans la paire la plus extrême, l’écart était de plusieurs fois. Les auteurs y voient la preuve que des équipes distribuées, qui ne peuvent pas facilement se coordonner, sont poussées vers des conceptions qui exigent moins de coordination.

Une étude de Microsoft Research sur Windows Vista, menée par Nachiappan Nagappan, Brendan Murphy et Victor Basili (2008), a abordé la question sous l’angle de la qualité. Des métriques décrivant l’organisation qui avait construit chaque binaire (combien d’ingénieurs y avaient touché, combien étaient partis, à quelle distance dans la hiérarchie se trouvaient les contributeurs) prédisaient mieux quels binaires étaient sujets aux défaillances que les métriques de code classiques comme le taux de modification (churn), la complexité, la couverture et les dépendances.

Les données ne sont pas unanimes, et un résumé honnête compte. Une revue de 142 études empiriques réalisée en 2016 par Lyra Colfer et Carliss Baldwin a constaté que l’effet miroir était fréquent dans les études portant sur des secteurs et des entreprises, mais pas universel, et que les études de projets collaboratifs ouverts ne le confirmaient souvent pas, sans doute parce que des dépôts de code partagés, des outils de suivi des tickets et des discussions ouvertes permettent à des contributeurs distribués de se coordonner sans les liens organisationnels habituels. L’effet miroir est une tendance forte, pas une loi de la physique, et de bons outils et de bonnes pratiques peuvent en partie le contrer.

Les canaux de communication et l’importance de la taille des équipes

Un groupe de n personnes compte n(n − 1) / 2 canaux de communication possibles entre deux personnes. Ce nombre croît à peu près comme le carré de la taille du groupe : doubler l’équipe quadruple les canaux. Brooks s’est servi du même calcul pour expliquer pourquoi ajouter des personnes à un projet en retard le retarde davantage : chaque nouvel arrivant doit être formé et ajoute de nouveaux canaux que tout le monde doit entretenir.

Sur le plan de l’architecture, ce calcul explique deux choses. D’abord, une équipe unique ne peut pas grandir indéfiniment tout en gardant une compréhension partagée de son code ; au-delà d’une certaine taille, elle se fragmente en sous-groupes informels et, selon la loi de Conway, le code se fragmente selon les mêmes lignes, que quelqu’un ait conçu ces coutures ou non. Ensuite, le nombre de canaux entre les équipes compte autant que le nombre de canaux en leur sein : si chaque équipe doit parler à toutes les autres pour livrer une modification, la structure du système forme en pratique une seule grande unité couplée, quel que soit son nombre de services.

La manœuvre de Conway inversée

Si les organisations tendent à produire des systèmes qui reflètent leur structure, vous pouvez utiliser cette tendance délibérément : concevez la structure des équipes et les canaux de communication en fonction de l’architecture que vous voulez, et laissez le système prendre cette forme en grandissant. Jonny LeRoy et Matt Simons ont nommé cette approche la manœuvre de Conway inversée dans un article du Cutter IT Journal en décembre 2010, et elle est depuis devenue une technique courante dans les programmes de microservices et de plateformes.

En pratique, il s’agit de décider d’abord des frontières visées (par exemple les commandes, les paiements, le suivi des livraisons et l’intégration des restaurants comme services distincts), puis de former une équipe durable autour de chacune, de lui confier la responsabilité du code, des données et du pipeline de déploiement, et de faire en sorte que les équipes interagissent principalement par des API et des événements publiés plutôt que par du code ou des bases de données partagés. Là où un contact entre équipes est réellement nécessaire, rendez-le explicite : une équipe plateforme qui propose un produit en libre-service, une équipe facilitatrice qui apporte son aide pour une durée limitée.

La manœuvre a ses limites. Elle n’épouse le grain d’un système existant que lentement : réorganiser les équipes ne restructure pas une base de code fortement couplée, et pendant un temps les nouvelles équipes lutteront contre l’ancienne architecture. Martin Fowler note qu’elle ne peut pas réparer rapidement un système existant rigide. Elle suppose aussi que vous connaissez les bonnes frontières ; si vous les tracez mal puis les figez dans des structures d’équipes, la loi de Conway reproduira fidèlement l’erreur et la rendra coûteuse à corriger. C’est pourquoi les équipes commencent souvent par un monolithe modulaire et déplacent les frontières avant de les inscrire dans l’organisation.

Charge cognitive de l’équipe

La loi de Conway vous dit que les frontières entre équipes deviennent des frontières du système. Une seconde contrainte vous dit quelle taille peut avoir la partie de chaque équipe. La charge cognitive de l’équipe, un concept que Matthew Skelton et Manuel Pais ont introduit dans la conception des organisations logicielles avec Team Topologies (2019 ; deuxième édition en 2025), est la quantité totale qu’une équipe doit avoir en tête pour construire, exploiter et faire évoluer ce dont elle est responsable : le domaine métier, le code, l’infrastructure, les outils, les astreintes.

Ils empruntent à la psychologie la distinction entre la charge intrinsèque (la difficulté inhérente à la tâche, comme comprendre le domaine), la charge extrinsèque (l’effort imposé par l’environnement, comme une procédure de déploiement manuelle ou un build obscur) et la charge pertinente (l’effort d’apprentissage qui améliore le travail futur). L’objectif de conception est de réduire au minimum la charge extrinsèque, par exemple grâce à des plateformes et à l’automatisation, afin que la capacité aille aux charges intrinsèque et pertinente.

Pour les architectes, la conséquence est directe. Une frontière de service ou de composant doit donner à l’équipe qui en est responsable une partie du système qu’elle peut entièrement comprendre. Si une équipe est responsable de douze services répartis sur quatre domaines, elle est surchargée, et la qualité, la vitesse ou la santé des astreintes en pâtira, aussi propre que soit le code de chaque service. À l’inverse, un domaine si compliqué qu’aucune équipe orientée flux ne peut l’absorber (un moteur de tarification à modèles actuariels, un codec vidéo) peut justifier une équipe spécialisée et une frontière claire autour de son sous-système.

Laisser la structure des équipes façonner les frontières

Prises ensemble, ces idées donnent aux architectes un ensemble de règles pratiques :

Alignez les frontières sur la responsabilité des équipes. Chaque module, service, stockage de données et pipeline doit avoir une seule équipe responsable. En pratique, une responsabilité partagée signifie une absence de responsabilité, et le code reflétera ce dont le dernier contributeur avait besoin.

Réduisez au minimum la communication qu’exige chaque modification. Une frontière est bien placée si la plupart des modifications d’une capacité métier peuvent être faites, testées et déployées par une seule équipe. Surveillez les modifications qui exigent régulièrement la coordination de trois équipes : elles montrent que la structure du système et celle des équipes ne concordent pas.

Rendez les interfaces entre équipes explicites et stables. Les interfaces entre équipes méritent un versionnage, une documentation et des tests de contrat ; les interfaces au sein d’une équipe peuvent rester informelles et évoluer librement.

Réexaminez les deux ensemble. Les réorganisations sont des décisions d’architecture ; les décisions d’architecture sont des décisions organisationnelles. Un architecte que l’on ne consulte pas sur les changements d’équipes, ou un manager qui réorganise sans tenir compte du code, ignore une force qui agira quoi qu’il arrive.

Les modèles de types d’équipes et de modes d’interaction, ainsi que la manière de les faire évoluer, sont traités dans Team Topologies et conception sociotechnique.