Il existe un vieil adage dans le développement logiciel, formulé par Melvin Conway en 1967, qui est aujourd'hui plus pertinent que jamais :
"Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations."
Cela semble abstrait ? Ça ne l'est pas. Cela signifie simplement : votre logiciel est le reflet de la structure de votre équipe.
- Vous avez trois départements séparés qui se parlent à peine ? Alors vous aurez trois modules logiciels qui collaborent mal entre eux.
- Vos équipes travaillent en silos ? Vos données aussi.
- Un seul développeur fait tout ? Le système sera un grand bloc entremêlé.
On appelle cela la loi de Conway. Et cela a des implications massives sur le coût, la vitesse et la qualité de vos projets IT, que vous soyez une startup tech ou une entreprise industrielle de taille intermédiaire.
Pourquoi est-ce un problème ?
Le fait que la structure organisationnelle se reflète automatiquement dans l'architecture logicielle ne serait pas un problème si nos organisations étaient parfaites. Mais, le plus souvent, elles ne le sont pas.
Cela entraîne des opportunités manquées et des coûts inutiles :
- Travail en double : si les équipes ne communiquent pas, elles résolvent deux fois les mêmes problèmes. L'équipe A construit la gestion des utilisateurs, l'équipe B aussi. Cela coûte deux fois plus de temps et d'argent.
- Manque d'intégration : les systèmes censés fonctionner ensemble, par exemple ventes et production, ne le font pas, car les départements sont séparés. Les données doivent être transférées manuellement, les erreurs sont presque garanties.
- Coûts de maintenance élevés : si chacun "fait sa petite cuisine", une jungle de technologies et d'outils émerge, qu'au final plus personne ne maîtrise.
Pas seulement un problème de grands groupes
On entend souvent : "Nous ne sommes pas un grand groupe, cela ne nous concerne pas." C'est une idée dangereuse. La loi de Conway s'applique partout où des personnes travaillent ensemble, ou ne travaillent pas ensemble.
Scénario 1 : la "petite" PME
Même dans de petites entreprises avec trois ou quatre partenaires externes, la loi de Conway frappe.
Imaginez :
- Une agence construit le site marketing.
- Un prestataire gère le webshop.
- Un freelance a autrefois construit un outil interne.
Comme ces prestataires ne se sont jamais parlé, et que ce n'était pas prévu dans le contrat, le paysage système ressemble à ceci :
La conséquence : vous avez des données client à trois endroits. Les changements doivent être saisis trois fois. Personne n'a une vision claire du chiffre d'affaires réel généré par un client. C'est inefficace et source d'erreurs.
Scénario 2 : la "jungle d'interfaces" dans les grands systèmes
Un classique dans des environnements plus grands : plusieurs équipes ont besoin des mêmes données provenant d'un système externe central, par exemple un ERP SAP pour les stocks ou un CRM pour les données client.
Comme les équipes "Checkout", "Customer Service" et "Marketing" travaillent en silos isolés, chaque équipe construit sa propre connexion.
Le problème :
- Maintenance triple : si l'ERP change son interface, trois équipes doivent interrompre leur travail en même temps pour corriger leurs intégrations.
- Incohérence : le service Checkout met peut-être les données en cache 10 minutes, l'outil Marketing 24 heures. Les clients voient des informations différentes.
- Problèmes de charge : le système externe est inutilement sollicité par plusieurs interfaces.
- Coûts de maintenance : les évolutions du système doivent prendre en compte chaque technologie d'interface, ce qui augmente complexité et coûts.
Un composant "Gateway" central construit par une équipe plateforme ou coordonné conjointement aurait résolu ces problèmes, mais la structure organisationnelle l'a empêché.
Comment mieux faire aujourd'hui : "autonomie des équipes" vs "chaos"
Par le passé, on essayait de tout contrôler de manière centralisée, une seule tête pense, tout le monde exécute. C'était trop lent. Aujourd'hui, nous voulons des équipes autonomes capables de décider et de livrer rapidement.
Mais l'autonomie ne doit pas signifier le chaos.
Le concept des "guardrails" (macro-architecture)
Les entreprises modernes qui réussissent utilisent une approche hybride. Elles définissent des guardrails qui s'appliquent à tous, la macro-architecture, puis laissent les équipes libres à l'intérieur de ces garde-fous, la micro-architecture.
Exemple : la startup chaotique
Une startup grandit rapidement. Chaque équipe résout le sujet "Monitoring & Logging" différemment.
Résultat négatif :
- L'équipe A écrit des logs texte non structurés dans des fichiers.
- L'équipe B utilise pour elle seule un outil SaaS coûteux.
- L'équipe C croit que "ça va tourner" et n'a pas de logs du tout.
Lorsqu'une erreur système globale survient, l'analyse de la cause racine devient impossible, car les traces existent dans trois formats différents, ou n'existent pas du tout.
La solution : définir des guardrails
Le management, ou l'architecte, impose : "Nous utilisons des logs structurés et une infrastructure de monitoring unifiée comme standard de monitoring. Tout le reste, comme le langage de programmation ou la base de données, vous en décidez vous-mêmes."
L'avantage : les équipes restent rapides car elles n'ont pas à redécider constamment des fondations. Et lorsqu'il y a le feu, l'équipe A peut aider l'équipe B.
Le "gamechanger" : l'IA générative
C'est ici que cela devient passionnant, surtout pour l'avenir : l'intelligence artificielle, comme GitHub Copilot, Claude Code et autres, change actuellement notre manière d'aborder ce sujet.
Autrefois, les critiques disaient : "Si chaque équipe cuisine sa propre soupe, on programme beaucoup de choses en double. C'est du gaspillage."
Aujourd'hui, l'IA dit : "Pas de problème, j'écris le code boilerplate pour vous en 30 secondes."
Cela signifie :
- Le "coût" de l'autonomie des équipes baisse.
- Les équipes peuvent encore davantage se concentrer sur la résolution des problèmes métier au lieu de construire l'infrastructure technique.
- Mais : la communication devient encore plus importante. Si tout le monde produit du code très vite avec l'IA, un grand chaos se crée tout aussi vite si l'on ne se parle pas ou si l'on ignore les guardrails.
Conclusion et checklist pour les décideurs
La loi de Conway n'est pas un jouet théorique pour informaticiens. C'est un facteur de coût bien réel. Si votre organisation ne communique pas, votre logiciel sera cher et source d'erreurs.
Ce que vous pouvez faire :
- Regardez votre organisation : avant de planifier un nouveau logiciel, observez vos équipes. Les personnes dont les systèmes devront ensuite échanger des données se parlent-elles ?
- Définissez des guardrails : établissez ce qui doit être identique dans toute l'entreprise, par exemple la manière de se connecter ou la base de données utilisée.
- Laissez de la liberté dans le détail : donnez aux équipes de la liberté d'implémentation tant qu'elles respectent les guardrails.
- Investissez dans la transversalité : la tâche la plus importante des seniors techniques aujourd'hui n'est plus d'écrire le code le plus complexe, mais de s'assurer que toutes les équipes se connaissent et bénéficient les unes des autres.
Une bonne architecture n'est finalement rien d'autre qu'une bonne communication.
Besoin d'aide ?
Vous avez l'impression que votre paysage IT ressemble davantage à un chaos historiquement construit qu'à un succès planifié ? Nous vous aidons à analyser les structures et à mettre en place des guardrails pragmatiques, pour plus de vitesse et moins de frustration. Contactez-nous via notre page de contact.
