Avant-propos

  • Votre architecture logicielle n’est pas « conçue » par votre équipe technique, elle « pousse » selon votre structure organisationnelle. Cette loi, formulée en 1968, est constamment vérifiée à l’ère de l’IA.
  • Des recherches empiriques de la Harvard Business School démontrent que la distance organisationnelle prédit mieux le taux de défauts logiciels que la complexité du code. Ce que vous croyez être une « dette technique » est, en réalité, probablement une « dette organisationnelle ».
  • L’empire des microservices d’Amazon, le modèle des équipes autonomes de Spotify, la crise de Siri chez Apple — trois entreprises de mille milliards de dollars illustrent, par des destins radicalement différents, la même loi.
  • Les agents IA entrent désormais dans les organigrammes. Lorsque les « nœuds » de vos équipes ne sont plus uniquement humains, la loi de Conway sera réécrite d’une manière que vous n’imaginez pas.

En 1968, un programmeur inconnu a rédigé un article rejeté par Harvard Business Review pour « n’avoir pas prouvé son argument ». 56 ans plus tard, l’idée centrale de cet article est devenue une loi universellement reconnue dans l’ingénierie logicielle — et en 2026, à l’ère où l’IA redéfinit tout, elle est plus cruciale que jamais.

I. Comment un article rejeté est devenu la « loi de la gravitation » de l’ingénierie logicielle

Le prophète rejeté par HBR

En avril 1968, Melvin Conway a publié dans la revue Datamation un article au titre modeste : How Do Committees Invent? (Les comités inventent-ils ?).
La thèse centrale de cet article ne tient qu’en une phrase, suffisante pour faire perdre le sommeil à n’importe quel CTO :

« Les organisations qui conçoivent des systèmes sont contraintes de produire des conceptions qui sont des homomorphismes de la structure de communication de ces organisations. »

Traduit en langage courant : Votre organigramme est la copie conforme de votre architecture logicielle.

Conway illustre cette idée par un cas précis. Une entreprise confie à huit personnes la tâche de construire deux compilateurs, répartis en deux équipes : une de cinq personnes et une de trois. Résultat ? L’équipe de cinq a produit un compilateur en cinq étapes ; celle de trois, un compilateur en trois étapes. Ce n’était pas une exigence technique, mais parce que chacun avait besoin de « posséder » son propre unité de travail.

Conway formalise cette relation par le terme mathématique « homomorphisme » — une correspondance structurelle préservée entre la structure organisationnelle et la conception du système. Ce n’est ni une coïncidence, ni un accident : c’est une loi presque mathématiquement inévitable.

Ironiquement, Conway a initialement soumis cet article à la Harvard Business Review, mais il a été rejeté par les éditeurs pour « n’avoir pas prouvé son argument ». Sept ans plus tard, Fred Brooks a cité officiellement ce point dans son ouvrage classique, The Mythical Man-Month, et lui a donné le nom formel de « Loi de Conway ».
Depuis lors, une observation rejetée par les plus prestigieuses revues commerciales est devenue l’une des lois les plus largement citées en ingénierie logicielle. Timeline de l'existence et de la vie de la loi de Conway ## Le « dernier mot » de Martin Fowler
Si Conway est le Copernic ayant formulé l’hypothèse, alors les recherches empiriques des vingt dernières années en sont le télescope.
En 2022, Martin Fowler, scientifique en chef chez ThoughtWorks, a rédigé une évaluation largement diffusée dans l’industrie : « S’il existe une seule loi dans le domaine de l’architecture logicielle que tous les praticiens reconnaissent, c’est la loi de Conway. Elle est suffisamment importante pour avoir influencé chaque système que j’ai vu ; suffisamment puissante pour que tout effort visant à la contrecarrer soit voué à l’échec. »
Il ne s’agit pas d’une théorie élaborée dans un ivory tower. Fowler a observé à maintes reprises, dans ses consultations auprès de centaines d’entreprises mondiales, le même phénomène : l’organigramme d’une entreprise est l’ombre du schéma logiciel, peu importe que la direction en soit consciente ou non.

Il y a une implication subtile mais cruciale que beaucoup ignorent : Fowler parle de « toute personne qui tente de s’opposer à elle » et non de « toute personne qui tente de l’exploiter ». Quelle est la différence ? S’opposer à la loi de Conway signifie imposer un changement d’architecture sans modifier la structure organisationnelle ; l’exploiter, en revanche, signifie ajuster d’abord l’organisation pour permettre à l’architecture de « croître naturellement ».
Cette distinction détermine le succès ou l’échec des projets de transformation numérique. Nous développerons cette idée dans le deuxième article, consacré aux Team Topologies, en exposant la stratégie clé appelée « Inverse Conway Maneuver » — qui consiste fondamentalement à exploiter, et non à s’opposer, à cette loi.

II. Du laboratoire au champ de bataille : trois études confirment cette loi Tableau de comparaison des découvertes centrales de trois études

L’« hypothèse du miroir » de la Harvard Business School

En 2012, MacCormack et ses collègues de la Harvard Business School ont publié une étude majeure, connue dans le milieu académique sous le nom d’« hypothèse du miroir » (Mirroring Hypothesis).

Leur méthode était ingénieuse : ils ont comparé des logiciels commerciaux et des logiciels open source qui exécutaient exactement les mêmes fonctions. Les logiciels commerciaux étaient développés par des équipes hiérarchiques au sein d’entreprises, tandis que les logiciels open source étaient créés par des communautés décentralisées.

Le résultat correspond exactement à la loi de Conway : les produits développés par des organisations à faible couplage sont nettement plus modulaires. Même les équipes d’entreprises fortement couplées, qui poursuivent activement une conception modulaire, produisent finalement des systèmes présentant des caractéristiques de couplage étroit, en parfait accord avec leur structure organisationnelle.

La structure organisationnelle agit comme un « champ gravitationnel » — vous pouvez la contrecarrer temporairement, mais avec le temps, l’architecture du système finit toujours par se réaligner sur la structure de l’organisation.

Quelle est la véritable implication de cette étude pour les décideurs ? Lorsque votre équipe technique vous répète régulièrement « Nous devons refactoriser », ce qui nécessite peut-être une refonte, ce n’est pas tant le code que l’organisation elle-même. Mais comment distinguer une « dette technique » d’une « dette organisationnelle » ? Cela exige une méthode diagnostique systématique — nous présenterons un modèle d’évaluation complet dans le 12ᵉ article, « Cadre de décision pour l’adoption d’outils d’IA en entreprise ».

L’« expérience Windows Vista » de Microsoft Research

En 2008, Nagappan et ses collègues de Microsoft Research ont mené une vaste étude quantitative sur le projet Windows Vista. Ils cherchaient à répondre à une question cruciale : quel facteur prédit le mieux la présence de défauts (bugs) dans un logiciel ?

Les candidats potentiels incluaient : la complexité du code, le nombre de lignes de code, la fréquence des modifications, l’expérience des développeurs… et une variable qui semblait étrangère à la « technique » — la distance organisationnelle (c’est-à-dire la distance hiérarchique entre les équipes chargées de développer des modules interconnectés).

Les conclusions de l’étude ont mis mal à l’aise de nombreux technophiles : la distance organisationnelle prédit mieux le taux de défauts logiciels que la complexité du code. Organisation - complexité du code Autrement dit, un module développé conjointement par deux équipes éloignées sur l’organigramme est plus sujet aux bogues qu’un module extrêmement complexe mais maintenu par une équipe étroitement collaborative. Ce que vous croyez être un bug causé par un code mal écrit est peut-être en réalité dû à une mauvaise conception organisationnelle.

Cette découverte a des implications bien plus profondes à l’échelle entreprise qu’il n’y paraît. Elle signifie que votre stratégie de QA doit suivre l’organisation, et non la complexité du code. Les modules impliquant plusieurs équipes nécessitent une couverture de tests plus stricte et des processus de revue plus rigoureux, même si le code lui-même semble simple. Aujourd’hui, où la quantité de code généré par l’IA explose (Copilot génère déjà 46 % du code écrit par les utilisateurs), ce principe devient encore plus critique — nous l’illustrerons en détail avec le cas de Coinbase dans le chapitre 8, lors de notre discussion sur le « paradoxe de la productivité ».

L’« accélération » et les « inquiétudes » de l’étude DORA

L’équipe DevOps Research and Assessment (DORA), filiale de Google dirigée par Nicole Forsgren, Jez Humble et Gene Kim, a publié la plus grande étude jamais réalisée sur la performance du livraison logicielle.

La découverte centrale est hautement cohérente avec la loi de Conway : « Si nous mettons en œuvre une architecture à faible couplage et bien encapsulée, accompagnée d’une structure organisationnelle correspondante, nous pouvons à la fois accélérer le rythme de livraison et améliorer la stabilité, tout en conservant une croissance de la productivité linéaire, voire superlinéaire, même lorsque les équipes d’ingénierie s’agrandissent considérablement. » Toutefois, le rapport DORA de 2022 a également révélé un effet secondaire fascinant : bien que l’architecture à faible couplage améliore l’efficacité de livraison, elle peut augmenter le burnout des équipes. La raison pourrait être que, lorsque les équipes sont hautement autonomes et isolées les unes des autres, leurs membres perdent le sentiment d’appartenance à un ensemble plus vaste, ressentant une solitude du type « Je ne suis qu’un rouage ».

C’est un rappel important — l’alignement entre architecture et organisation n’est pas une solution miracle : il résout les problèmes d’efficacité, mais peut créer des problèmes culturels. Une implication profonde émerge : si une architecture à faible couplage combinée à une organisation à faible couplage fait déjà se sentir isolés les développeurs humains, que se passe-t-il lorsque des agents IA rejoignent ces équipes ? Les IA ne « ressentent » pas l’isolement, mais les humains le ressentiront encore plus. Ce point est rarement discuté, mais dans nos sources, un rapport BCG de 2025 évoque le « dilemme d’orchestration des managers intermédiaires » — ce qui constitue précisément le sujet central de notre 11e article.

III. Les « moments Conway » de trois entreprises de mille milliards de dollars

Amazon : un e-mail du PDG qui a tout changé

Autour de 2002, Jeff Bezos a envoyé à l’intérieur d’Amazon ce célèbre « API Mandate » : tous les équipes devaient communiquer uniquement via des interfaces de service (API), et il était strictement interdit d’accéder directement aux bases de données d’autres équipes.
La dernière ligne de cet e-mail aurait été : « Les personnes ne respectant pas ces règles seront licenciées. »
Beaucoup considèrent l’architecture microservices d’Amazon comme une décision technique. Mais selon la loi de Conway, ce que Bezos a réellement fait est une décision organisationnelle : il a d’abord imposé, par la gestion, la coupure des « raccourcis de communication » entre les équipes, et l’architecture logicielle s’est naturellement transformée en modules de services isolés.
Schéma de chaîne de causalité d'Amazon
C’est ce qui a conduit plus tard Bezos à proposer les « Two-Pizza Teams » — chaque équipe ne doit pas dépasser le nombre de personnes qu’on peut nourrir avec deux pizzas (généralement 5 à 8 personnes) ; chaque équipe possède son propre service, le déploie indépendamment, et interagit avec l’extérieur uniquement via des API.
L’empire microservices d’Amazon n’a pas été dessiné par des architectes : il a grandi par l’organisation. C’est le cas le plus classique et positif de la loi de Conway.

Mais il existe ici un aspect que beaucoup d’articles omettent : la réussite de Amazon ne tient pas seulement au fait que Bezos a compris la loi de Conway, mais aussi à ce qu’il a résolu simultanément le problème de l’alignement des incitations. Chaque « équipe de deux pizzas » possède son propre P&L (compte de résultat), et elle est autonome non seulement sur le plan technique, mais aussi sur le plan commercial. Cela signifie que les équipes ont un moteur interne pour maintenir des frontières de services claires — car une frontière floue implique une ambiguïté des responsabilités, et une ambiguïté des responsabilités implique une évaluation floue. L’alignement triangulaire entre structure organisationnelle, structure d’incitation et architecture technique constitue la pleine image du modèle Amazon. Les entreprises qui n’imitent que la structure organisationnelle sans copier la conception des incitations ne retiennent que la forme, pas l’essence.

Spotify : le modèle idéal confronté à l’« entropie » de la réalité

Le modèle « Squad » de Spotify a un temps été considéré à la Silicon Valley comme la bible de la conception organisationnelle : des équipes autonomes de 5 à 8 personnes (Squads), regroupées en tribus (Tribes), des experts techniques transversaux formant des chapitres (Chapters), et des communautés basées sur l’intérêt formant des guildes (Guilds). Modèle classique de quatre niveaux de l'organisation Spotify
Cette architecture repose sur une logique profondément cohérente avec la loi de Conway — en structurant des équipes petites et autonomes, elle encourage la création de services logiciels petits et autonomes.

Mais Spotify a ensuite admis que la réalité était bien plus complexe que le modèle. À mesure que l’entreprise grandit, les dépendances entre équipes deviennent inévitables, et l’autonomie pure engendre des coûts de coordination.
Cela révèle une conséquence souvent négligée de la loi de Conway : la structure organisationnelle n’est pas conçue une fois pour toutes ; elle présente, comme le logiciel, une tendance à l’augmentation de l’entropie. À mesure que la complexité métier croît, les frontières organisationnelles s’effacent progressivement, les chemins de communication s’allongent, et l’architecture système se dégrade.
Une organisation technique excellente n’est pas celle qui « a conçu une bonne architecture », mais celle qui a établi la capacité d’ajuster en continu l’alignement entre organisation et architecture. Cette capacité sera approfondie dans le deuxième article sur les Team Topologies — qui propose un cadre plus systématique et plus opérationnel que le modèle Spotify.

Apple : Pourquoi Siri a été “battue” par ChatGPT

Entre 2024 et 2025, le projet de mise à niveau IA de Siri chez Apple est devenu presque un « contre-exemple » de la loi de Conway.

La racine du problème n’est pas technologique. Apple dispose d’une équipe de recherche en IA parmi les meilleures au monde et de ressources financières abondantes. Mais le développement de Siri implique deux équipes dont la structure organisationnelle présente une fracture structurelle : l’équipe de recherche en IA (dirigée par John Giannandrea) et l’équipe de développement produit (dirigée par Craig Federighi).

Ces deux équipes ont des priorités différentes, des rythmes différents, des critères de succès différents. L’équipe de recherche en IA cherche à pousser les limites des capacités des modèles ; l’équipe produit vise à livrer une expérience utilisateur stable. Lorsque la structure de communication entre ces deux « nœuds » organisationnels est fragmentée, le système produit est inévitablement fragmenté.

Qu’obtient finalement l’utilisateur avec Siri ? Un « assistant médiocre assemblé » — chaque module semble fonctionnel, mais leur intégration manque d’une expérience intelligente cohérente. C’est exactement ce que la loi de Conway prédit : les fissures du système reflètent les fissures de l’organisation.

Le cas d’Apple mérite particulièrement l’attention des décideurs chinois. De nombreuses entreprises traversent exactement la même crise — les équipes IA et les équipes métier relèvent de VP différents ; les projets d’implémentation de l’IA deviennent des « conflits politiques entre deux départements » plutôt que des « livraisons collaboratives d’un seul produit ».

Si votre entreprise pousse à la mise en œuvre de l’IA, jetez un coup d’œil à votre organigramme : la capacité IA est-elle structurée comme un département indépendant, ou est-elle intégrée aux équipes opérationnelles ? La réponse à cette question pourrait déterminer le succès ou l’échec de votre projet bien plus que le choix du modèle d’IA lui-même.

IV. L’ère de l’IA : La loi de Conway est en train d’être réécrite

Quand les « nœuds organisationnels » ne sont plus tous humains

En 2026, la loi de Conway fait face à son défi le plus profond depuis 1968. Conway, en énonçant cette loi, supposait implicitement que chaque « nœud » au sein d’une organisation était un être humain : la structure de communication était une communication entre humains.

Mais aujourd’hui, des agents IA pénètrent les organigrammes. Claude Code accomplit de manière autonome des tâches de développement en plusieurs étapes ; le système Minions de Stripe produit plus de 1 000 pull requests fusionnées chaque semaine ; Cursor a transformé la manière de travailler de 100 % des ingénieurs de NVIDIA. Selon Gartner, les demandes de conseil sur l’orchestration multi-agents IA chez les entreprises ont augmenté de 1445 % en 2025.

Que se passe-t-il lorsque certains nœuds au sein de l’organisation ne sont plus humains ? Schéma d'organisation traditionnel vs organisation de l'ère AI

La discussion de cette question traversera la seconde moitié de notre série — l’article 10 sur le phénomène « One-Person Unicorn », l’article 11 sur « La loi de Conway rencontre les agents IA », et l’article 14 sur « Agentic Engineering » — mais voici trois jugements préliminaires pour vous aider à construire un cadre de réflexion :

Premièrement, la structure de communication deviendra une structure de stratégie. La communication entre humains repose sur la culture, la complicité et les échanges informels. Mais entre humains et agents IA, il n’existe pas de « complicité » — vous devez définir les limites d’interaction par des stratégies, règles et permissions explicites. La capacité de gouvernance remplacera la capacité de communication comme variable centrale de la conception organisationnelle.

Deuxièmement, l’organigramme deviendra une carte de permissions. Les organigrammes traditionnels décrivent les relations de hiérarchie et la répartition des fonctions. L’« organigramme » de l’ère IA ressemble davantage à un graphe orienté acyclique (DAG), qui définit les capacités et les contraintes : quel agent peut accéder à quelles données, effectuer quelles opérations, et dans quelles conditions nécessiter une approbation humaine.

Troisièmement, les connaissances institutionnelles passeront des personnes aux stratégies. Autrefois, « quand un ancien employé partait, il emportait les connaissances » était la douleur de chaque entreprise. À l’avenir, les connaissances clés seront codifiées dans les stratégies et le contexte des agents IA — ce qui constitue à la fois une opportunité (les connaissances ne s’évaporent plus) et un risque (une erreur de stratégie peut être amplifiée de manière systémique).

Chaque jugement repose sur de nombreuses pratiques industrielles et des données concrètes. Par exemple, le troisième point concernant le « transfert de connaissances institutionnelles » offre un exemple saisissant, à la fois positif et négatif, avec le cas de Klarna : après avoir licencié 40 % de ses employés, ils ont découvert que leur système IA ne pouvait pas remplacer les connaissances implicites emportées par les personnes départies, les obligeant à réembaucher. Cette histoire sera entièrement développée dans le 9e article, « La leçon de Klarna ».

La première et la deuxième affirmation ne sont pas uniquement les nôtres. Dans le podcast d’a16z de juillet 2026, « Software in the Age of Agents », Seema Amble, partenaire de l’équipe enterprise d’a16z, et Steven Sinofsky, ancien président de Windows chez Microsoft, sont arrivés à des conclusions hautement convergentes à partir de leur observation directe des investissements. Steven a résumé l’essentiel de la première affirmation en une phrase : « Le plus grand effet de réseau dans le logiciel d’entreprise se trouve à l’intérieur d’une entreprise » (The biggest network effect in enterprise software is inside of a company) : le réseau tissé par les relations humaines, les processus et les systèmes au sein de l’organisation constitue le véritable levier de fidélisation. Un agent ne peut pas s’insérer dans ce réseau par «默契» — il ne peut y accéder que par des stratégies et des autorisations explicites — c’est précisément cette pression concrète qui pousse la structure de communication à devenir une structure de stratégie. Seema, quant à elle, confirme la deuxième affirmation du point de vue de l’accès des agents aux systèmes d’entreprise : dès qu’un agent doit « exécuter » (écrire dans les enregistrements du système, modifier des comptes), il se heurte immédiatement à toute une série de problèmes — identité, certificats, places facturables, autorisations d’approbation — l’organigramme de l’entreprise est en train d’être transformé en une carte d’autorisation : « Qui peut accéder à quoi, et qui autorise quoi ». Ces deux affirmations ne sont pas des prédictions : ce sont des phénomènes déjà en cours dans les projets que les investisseurs de terrain financent actuellement. (Invités : partenaires d’a16z / anciens cadres de Microsoft, position VC.)

Cinq : Auto-évaluation comparative : Quelle « erreur de Conway » votre organisation commet-elle ?

Si vous êtes arrivé jusqu’ici en pensant « Je connais déjà tout ça », alors je vous invite à faire cet exercice.

Voici cinq modèles courants de décalage organisationnel-architectural, dérivés de la loi de Conway et de ses extensions. Comparez-les à votre propre entreprise : combien en reconnaissez-vous ?

Cartes de diagnostic des cinq modèles d'organisation-architecture décalés

  • ❶ Microservices de surface : Le code est décomposé, mais 50 personnes continuent de se disputer dans le même groupe Slack.
  • ❷ Illusion du middle-platform : Le middle-platform est devenu le goulot d’étranglement de toutes les lignes métier.
  • ❸ Îlots AI : Les modèles produits par l’équipe AI ne peuvent pas être intégrés aux systèmes métier, car ils sont organisationnellement séparés.
  • ❹ Détérioration de la collaboration à distance : L’isolement physique engendre des fractures systémiques inutiles.
  • ❺ Mauvaise assimilation des acquisitions : L’incompatibilité culturelle organisationnelle entraîne un échec d’intégration technique.

Prochaine étape

Ceci est le premier article d’une série de 15 intitulée « La révolution de l’ingénierie logicielle à l’ère de l’IA ». À partir de la loi de Conway, nous avons établi une compréhension fondamentale : l’architecture organisationnelle détermine l’architecture système — ce n’est pas une métaphore, mais une relation causale validée par des preuves empiriques.

Mais connaître cette loi n’est qu’un point de départ. La vraie question est : peut-on l’inverser ? En concevant délibérément une structure organisationnelle pour guider l’architecture système souhaitée — c’est là l’idée centrale de l’« Inverse Conway Maneuver ».
Dans le prochain article, « Team Topologies — Une méthodologie de conception organisationnelle à l’ère post-Agile », nous explorerons en détail comment Matthew Skelton et Manuel Pais ont transformé cette idée en une méthodologie complète et opérationnelle, incluant quatre types fondamentaux d’équipes, trois modèles d’interaction, et le concept de « charge cognitive », souvent sous-estimé. Des cas d’entreprise comme Netflix, Adidas et Accenture illustreront : dans quelles conditions l’Inverse Conway Maneuver fonctionne, et dans quelles conditions il échoue.

Note sur la série : Cette série suivra en continu les évolutions les plus récentes des outils d’IA pour la programmation, des architectures organisationnelles et des paradigmes d’ingénierie logicielle, telles que les nouvelles manifestations de la loi de Conway en 2026 à l’ère des agents d’IA, ou la maturité des écosystèmes d’outils les plus récents. Abonnez-vous à cette série pour recevoir des insights mis à jour en continu.

À propos de cette série

« La transformation de l’ingénierie logicielle à l’ère de l’IA » est une série d’études approfondies destinée aux décideurs technologiques d’entreprise, composée de 15 articles. Basée sur une analyse systématique de plus de 200 articles académiques et rapports industriels, elle vous fournit des références décisionnelles annotées selon leur niveau de preuve. D’autres contenus sont à venir.

Sources de référence :

  • Conway, M. (1968). How Do Committees Invent? Datamation, 14 (4), 28-31.
  • Brooks, F. P. (1975). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley.
  • MacCormack, A., et al. (2012). Exploring the Duality between Product and Organizational Architectures: A Comparative Study of Commercial and Open Source Software. Harvard Business School Working Paper.
  • Nagappan, N., et al. (2008). The Influence of Organizational Structure on Software Quality. ICSE ‘08 Proceedings.
  • Forsgren, N., et al. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press.
  • Fowler, M. (2022). Conway’s Law. Martinfowler.com/bliki/ConwaysLaw.html.
  • Gartner (2025/26). Predicts 2026: AI Agents in Software Engineering.
  • a16z (2026). Software in the Age of Agents. The a16z Podcast. (Citation de Steven : « The biggest network effect in enterprise software is inside of a company » + observation de Seema Amble sur les agents qui rencontrent des obstacles de permissions, d’identifiants et de licences lors de l’accès aux systèmes d’entreprise, soutenant les jugements 1 et 2 de la section 4 ; source primaire : enregistrement original du podcast. Positionnement : Partenaire a16z / ancien cadre Microsoft, position VC. Invités vérifiés : Seema Amble, partenaire de l’équipe entreprise a16z ; Steven Sinofsky, ancien président de Windows chez Microsoft (board partner) ; Elena Burger, rédactrice a16z ; diffusion en juillet 2026.)