Gestion & Stratégie. Loi de Conway : pourquoi l'organisation dicte le code

Loi de Conway: pourquoi l’organisation dicte le code

C’est une conséquence directe de la structure de communication du groupe.

La loi de Conway résume cette mécanique: l’architecture d’un système logiciel tend à reproduire les frontières de communication de l’organisation qui le construit. Une équipe Frontend séparée d’une équipe Backend, elle-même isolée d’une équipe DBA ou SRE, ne fabrique pas spontanément un système modulaire. Elle fabrique un système distribué entre ces silos, avec des interfaces, des tickets, des réunions et des dépendances qui matérialisent l’organigramme.

La question n’est donc pas seulement de savoir si l’architecture cible est élégante. Il faut vérifier si l’organisation est capable de la produire et de la maintenir.

Une observation sociologique devenue contrainte d’architecture

Melvin Conway a formulé sa thèse en 1967 dans l’article How Do Committees Invent?. Le texte a d’abord été soumis à la Harvard Business Review, qui l’a rejeté faute de preuves empiriques suffisantes. Il est finalement publié en avril 1968 dans Datamation.

En 1975, Frederick Brooks popularise l’expression « loi de Conway » dans The Mythical Man-Month. Le terme est resté. La formulation, elle, est souvent simplifiée jusqu’à devenir un slogan de conférence. C’est une erreur. La loi ne dit pas que toute architecture est déterminée mécaniquement par l’organigramme. Elle décrit une tendance observable: les décisions techniques suivent les canaux par lesquels les équipes échangent de l’information, arbitrent les conflits et coordonnent les livraisons.

La nuance est essentielle.

Une entreprise peut afficher une architecture hexagonale, des bounded contexts DDD et une stratégie de microservices. Si les équipes restent organisées par spécialité — une équipe PHP, une équipe JavaScript, une équipe base de données, une équipe exploitation — le code conservera les traces de cette séparation. Les frontières métiers seront théoriques. Les frontières de responsabilité, elles, seront opérationnelles.

La conception logicielle devient alors une projection de la conception organisationnelle.

Une architecture ne suit pas l’organigramme officiel. Elle suit les conversations nécessaires pour livrer et modifier le système.

Cette distinction explique pourquoi deux entreprises utilisant les mêmes frameworks PHP peuvent aboutir à des architectures radicalement différentes. Le langage, le framework et le moteur de base de données contraignent le système. Ils ne définissent pas ses frontières de collaboration.

Le couplage organisationnel devient du couplage logiciel

Le couplage ne se mesure pas uniquement dans le code. Il existe aussi dans les dépendances entre équipes.

Prenons une plateforme web découpée en trois groupes:

• l’équipe Frontend possède l’interface et les parcours;
• l’équipe Backend développe les API et la logique applicative;
• l’équipe DBA contrôle le schéma, les migrations et les performances SQL.

Sur le papier, la répartition semble rationnelle. En pratique, une évolution métier simple peut traverser les trois périmètres. Un nouveau statut de commande exige une modification de l’interface, un changement de contrat API et une migration de base de données. Aucun groupe ne possède réellement le flux complet. Le déploiement dépend d’une séquence de validations et de transferts.

Le code reproduit cette dépendance. Les contrôleurs deviennent des points de passage entre équipes. Les contrats API se transforment en zones de négociation. Le schéma de données devient une interface partagée par plusieurs équipes qui ne peuvent pas le faire évoluer indépendamment.

Ce phénomène produit plusieurs symptômes techniques reconnaissables:

1. Des modèles de données transverses.

Une même table ou un même objet métier est utilisé par plusieurs domaines, avec des règles de validation dispersées dans les contrôleurs, les services et les tâches asynchrones.

2. Des API conçues comme des compromis organisationnels.

Les endpoints ne suivent pas forcément les capacités métier. Ils exposent ce que chaque équipe peut fournir dans son périmètre, au prix de multiples appels côté client.

3. Des déploiements séquentiels.

Une équipe ne peut pas livrer sans attendre une autre équipe, même lorsque le changement fonctionnel est local.

4. Des réunions de synchronisation qui remplacent les contrats techniques.

Quand l’interface entre deux composants n’est pas stable, la coordination humaine devient une dépendance d’exécution.

5. Une allocation mémoire et une consommation CPU difficiles à attribuer.

Les problèmes de performance traversent les frontières: la requête est lente, l’API sérialise trop, le client répète les appels, puis chaque équipe optimise sa partie sans posséder le chemin complet.

Le problème n’est pas le nombre d’équipes. C’est l’alignement entre leur périmètre de responsabilité et les changements que le produit doit absorber.

La structure d’équipe et l’architecture du code

La loi de Conway devient utile lorsqu’elle est appliquée à une décision concrète: comment répartir les équipes pour obtenir l’architecture souhaitée?

Si la cible est un monolithe modulaire, une équipe pluridisciplinaire peut posséder plusieurs modules métier tout en conservant un déploiement unique. Si la cible est un ensemble de services indépendants, chaque service doit disposer d’une capacité de décision, d’une compétence d’exploitation et d’un accès direct aux informations nécessaires à son évolution.

Dans les deux cas, l’autonomie est plus importante que le vocabulaire architectural.

Une équipe qui possède un microservice mais doit demander à une autre équipe chaque modification de schéma, chaque règle de sécurité et chaque mise en production ne possède pas réellement ce service. Le découpage est physique. La responsabilité reste partagée. Le système devient distribué sans obtenir les bénéfices attendus de la distribution.

La manœuvre de Conway inversée part du principe opposé. Popularisée par Thoughtworks en 2014 puis reprise dans Accelerate en 2015, elle consiste à modifier délibérément la structure des équipes afin de faire émerger l’architecture logicielle visée.

La séquence de raisonnement est simple:

• définir les capacités métier que le produit doit faire évoluer;
• identifier les frontières techniques nécessaires pour isoler ces capacités;
• former des équipes capables de couvrir ces frontières;
• limiter les dépendances de livraison entre équipes;
• observer les flux de changement et corriger les frontières.

Ce n’est pas une opération de réorganisation cosmétique. Changer les intitulés de poste ne modifie pas la topologie d’un système. Une équipe reste dépendante si elle ne peut pas prendre les décisions nécessaires, déployer son périmètre ou diagnostiquer ses incidents.

Trois formes d’organisation, trois architectures probables

Le tableau ne décrit pas une loi mécanique. Il décrit une probabilité structurelle. Une organisation peut compenser une mauvaise répartition par des contrats solides, une forte discipline d’architecture et une excellente documentation. Elle paiera néanmoins cette compensation par davantage de coordination.

La dette d’architecture n’est pas toujours dans le dépôt Git. Elle peut être stockée dans les calendriers des équipes.

DDD, microservices et équipes alignées sur les flux

Le Domain-Driven Design fournit un vocabulaire utile pour dessiner les frontières métier. Il ne résout pas automatiquement le problème organisationnel.

Un bounded context n’est pas seulement un paquet PHP, un namespace ou un schéma PostgreSQL séparé. C’est une zone dans laquelle un modèle, un langage et des règles peuvent évoluer de manière cohérente. Pour fonctionner, cette zone doit aussi correspondre à une responsabilité identifiable.

Le lien avec les microservices est direct, mais souvent mal compris. Découper une application en services ne suffit pas. Si plusieurs équipes doivent négocier chaque modification d’un service, le découpage distribue le coût sans distribuer la capacité de décision.

L’alignement recherché est triple:

• alignement métier: le composant représente une capacité compréhensible;
• alignement technique: son code et ses données peuvent évoluer sans modifier tout le système;
• alignement organisationnel: une équipe possède assez de compétences et d’autorité pour le maintenir.

Les équipes dites stream-aligned s’inscrivent dans cette logique. Elles suivent un flux de valeur ou une capacité métier, plutôt qu’une couche technique. Une équipe peut donc réunir des compétences Backend PHP, Frontend, qualité, exploitation et produit autour d’un même périmètre.

Cela ne signifie pas que chaque équipe doit tout reconstruire. Une équipe plateforme peut fournir des mécanismes communs: observabilité, déploiement, gestion des secrets, bibliothèques de sécurité, composants d’exécution. Mais cette plateforme doit réduire la charge cognitive des équipes produit, pas centraliser toutes les décisions.

Une plateforme qui impose un ticket pour chaque déploiement n’est pas un produit interne autonome. C’est une équipe d’opérations manuelles.

Ce que la loi change dans le pilotage d’un projet web

Pour un CTO ou un chef de projet technique, la loi de Conway déplace le diagnostic. Il ne suffit plus d’examiner le backlog, la vélocité ou la couverture de tests. Il faut observer les chemins de changement.

Une fonctionnalité traverse-t-elle une seule équipe ou quatre? Qui possède le contrat? Qui décide de la migration? Qui reçoit l’alerte en production? Qui peut revenir en arrière? Qui connaît le coût réel d’une requête lente?

Ces questions produisent une cartographie plus fiable que l’organigramme.

Dans un projet PHP, plusieurs indicateurs sont particulièrement révélateurs:

• la proportion de tickets nécessitant une validation d’une autre équipe;
• le nombre de dépôts modifiés pour une évolution métier donnée;
• le nombre de services appelés pendant un parcours critique;
• le délai entre le changement de code et sa disponibilité en production;
• la fréquence des migrations coordonnées;
• la part des incidents dont le diagnostic exige plusieurs équipes;
• la présence de règles métier dupliquées dans plusieurs applications.

Il ne faut pas inventer un seuil universel. La bonne valeur dépend du domaine, du niveau de criticité et de la maturité de la chaîne de livraison. En revanche, une tendance persistante est exploitable: si les mêmes équipes doivent se synchroniser pour chaque changement, l’architecture et l’organisation sont probablement mal alignées.

Le backlog donne également une information structurelle. Lorsque les items sont rédigés par couche — tâche Backend, tâche Frontend, tâche base de données — le découpage de livraison reflète déjà l’organisation. Le produit est décomposé selon les équipes disponibles, pas selon la valeur métier.

Un backlog plus robuste décrit une capacité ou un résultat observable. Les tâches techniques apparaissent ensuite comme des moyens. Cette inversion facilite la constitution d’équipes responsables d’un flux complet.

Le rôle des contrats techniques

L’autonomie ne dispense pas de contrats. Elle exige des contrats plus précis.

Pour réduire le couplage entre équipes, les interfaces doivent expliciter:

• le schéma des données échangées;
• les règles de compatibilité;
• les comportements en cas d’erreur;
• les contraintes de latence et de disponibilité;
• la stratégie de versionnement;
• la responsabilité de l’observabilité;
• la procédure de dépréciation.

Dans un écosystème PHP, cela concerne les contrats HTTP, les événements asynchrones, les commandes de files, les bibliothèques partagées et les migrations. Un typage strict améliore la lisibilité locale. Il ne remplace pas un contrat de service. Une classe correctement typée peut toujours appartenir au mauvais périmètre.

Même constat pour les tests. Une suite de tests d’intégration peut détecter une rupture, mais elle ne corrige pas la dépendance organisationnelle qui rend cette rupture fréquente.

La meilleure frontière technique est celle qu’une équipe peut expliquer, modifier, déployer et observer sans négociation permanente.

La manœuvre de Conway inversée n’est pas un exercice de découpage

La tentation est forte de partir de l’architecture cible et de dessiner immédiatement des équipes autour des composants. Cette approche produit souvent des équipes propriétaires de morceaux trop étroits.

Une équipe dédiée au panier, une autre au paiement, une troisième aux promotions: le découpage peut être pertinent, mais il dépend du flux de changement et des contraintes métier. Si chaque commande traverse les trois composants pour une modification courante, la séparation augmente le coût de coordination. Si les règles sont réellement indépendantes et les cycles d’évolution distincts, elle peut être justifiée.

La manœuvre de Conway inversée doit donc être conduite par les changements, pas par les boîtes du diagramme.

Une démarche opérationnelle comporte généralement plusieurs étapes:

1. Cartographier les flux de valeur.

Il faut partir des parcours et des capacités que le produit doit faire évoluer. Le nom des équipes actuelles ne doit pas servir de découpage initial.

2. Mesurer les dépendances de livraison.

Les dépôts, les composants, les migrations et les validations traversés par chaque évolution révèlent le couplage réel.

3. Identifier les frontières stables.

Une frontière utile sépare des règles qui changent à des rythmes différents et dont les responsabilités peuvent être attribuées sans ambiguïté.

4. Attribuer une équipe responsable du flux.

L’équipe doit disposer des compétences nécessaires, y compris pour le déploiement, la supervision et la gestion des incidents.

5. Réduire les dépendances obligatoires.

Les équipes plateforme fournissent des capacités réutilisables. Elles ne doivent pas devenir une autorité centrale sur chaque décision locale.

6. Réévaluer après les changements d’organisation.

Une nouvelle structure produit de nouveaux flux de communication. L’architecture doit être observée après la réorganisation, pas seulement dessinée avant.

Cette méthode ne garantit ni la réussite d’un programme de transformation ni une baisse chiffrée des coûts. Aucune donnée universelle ne permet d’attribuer à la seule loi de Conway une amélioration précise de la productivité. Elle fournit un cadre de diagnostic. C’est déjà beaucoup.

Les limites: Conway n’explique pas tout

La loi est puissante parce qu’elle est générale. Elle est dangereuse lorsqu’elle est traitée comme une loi physique.

D’autres forces structurent une architecture:

• les contraintes réglementaires;
• les exigences de sécurité;
• la latence réseau;
• la disponibilité des compétences;
• les choix historiques de stockage;
• les coûts d’exploitation;
• les limites d’un fournisseur cloud;
• les contraintes de compatibilité avec un système ancien;
• les exigences de performance et de montée en charge.

Une organisation peut être correctement alignée et conserver un monolithe. Ce choix peut être rationnel. Un monolithe modulaire bien maîtrisé offre parfois une surface opérationnelle plus faible qu’un ensemble de microservices mal découpés.

À l’inverse, une organisation peut adopter des équipes alignées sur le métier et produire une architecture médiocre. Les frontières métier peuvent être mal comprises. Les équipes peuvent manquer d’expertise. Les contrats peuvent être instables. L’observabilité peut être absente. La topologie d’équipe crée une condition favorable, pas un résultat automatique.

Le risque principal consiste à transformer Conway en justification après coup. Une direction technique annonce une réorganisation, puis attribue à la loi la forme obtenue par le système. Ce n’est pas une stratégie. C’est une explication.

La bonne utilisation est prédictive: si l’entreprise veut des composants indépendants, elle doit vérifier que les équipes peuvent travailler avec un niveau d’indépendance comparable. Si elle conserve des équipes en silos, elle doit accepter une architecture où les interfaces et la coordination deviennent des éléments centraux du système.

Verdict

La loi de Conway est une contrainte d’architecture exploitable, pas un théorème et pas une recette de transformation.

Pour un programme PHP complexe, ignorer la structure des équipes revient à ignorer une partie du système à concevoir. Les namespaces, les services, les files de messages et les bases de données ne suffisent pas à définir une architecture. Les canaux de communication, les responsabilités de livraison et les mécanismes d’arbitrage y participent directement.

Verdict binaire: à utiliser en production pour diagnostiquer et concevoir l’organisation, oui. À utiliser comme preuve automatique qu’une réorganisation produira la bonne architecture, non.