# 🏢 Loi de Conway — Ton archi reflète ton orga **Loi de Conway** : _"Les organisations qui conçoivent des systèmes sont contraintes de produire des designs qui sont des copies de la structure de communication de l'organisation."_ > **Ton architecture technique = miroir de ton organisation humaine.** --- ## 🎯 Le principe ### Énoncé original (1967) > _"Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations."_ > — Melvin Conway **En clair** : Si 4 équipes travaillent sur un compilateur, tu auras un compilateur en 4 parties. --- ## 🧠 Pourquoi c'est crucial ? **Implications** : - Architecture ≠ choix purement technique - Architecture = reflet de l'organisation - Changer l'archi sans changer l'orga = échec - Organisation inadaptée = architecture inadaptée **Exemple concret** : ``` Orga: 3 équipes silotées (Frontend, Backend, Database) → Archi: 3 systèmes découplés qui communiquent mal ``` --- ## 📊 Visualisation de la loi > 💡 **L'invariant** : "Si tu veux changer l'archi, commence par changer l'orga." --- ## 🔍 Exemples concrets ### Exemple 1 : Microservices mal alignés **Organisation** : ``` 1 équipe monolithique de 15 devs Communication quotidienne dans 1 open space ``` **Architecture voulue** : ``` 10 microservices découplés ``` **Résultat réel** : ``` 10 microservices TRÈS couplés - Appels synchrones partout - Déploiements interdépendants - Base de données partagée ``` **Pourquoi ?** L'équipe communique comme un monolithe → le code aussi. --- ### Exemple 2 : Frontend/Backend séparés **Organisation** : ``` Équipe A: Frontend (5 devs) Équipe B: Backend (5 devs) Communication: Tickets Jira uniquement ``` **Architecture résultante** : ``` API REST générique, pas optimisée pour le frontend Frontend fait 10 requêtes pour 1 page (N+1) ``` **Pourquoi ?** Pas de communication directe → API générique, pas de GraphQL/BFF. --- ### Exemple 3 : Amazon (inverse Conway) **Décision stratégique** : ``` Jeff Bezos (2002): "Chaque équipe expose un service API" ``` **Organisation redesignée** : ``` - Petites équipes autonomes (2-pizza teams) - Chaque équipe possède son service - Communication via APIs uniquement ``` **Architecture résultante** : ``` Microservices découplés dès le départ → Scalabilité massive ``` **Leçon** : Concevoir l'organisation POUR l'architecture voulue. --- ## 🔄 Inverse Conway Maneuver **Exemple** : ``` Cible: Microservices par domaine métier 1. Créer des équipes par domaine (User, Order, Payment) 2. Chaque équipe possède son service de bout en bout 3. Architecture microservices émerge naturellement ``` --- --- ## 🧪 Applications pratiques ### 1. **Concevoir l'organisation pour l'archi voulue** ``` Architecture cible: Microservices par domaine Organisation adaptée: ✅ Équipes par domaine métier (User, Order, Payment) ✅ Équipes autonomes (full-stack) ✅ Propriété de bout en bout (dev → prod) ✅ Communication via APIs contractuelles ``` --- ### 2. **Diagnostiquer l'archi via l'orga** ``` Problème: API trop couplée Diagnostic: - Comment communiquent les équipes ? → Quotidiennement dans le même bureau - Résultat: code couplé (normal selon Conway) Solution: - Équipes autonomes - Communication asynchrone (Slack, tickets) ``` --- ### 3. **Team Topologies (livre)** 4 types d'équipes selon la loi de Conway : ```mermaid graph TD A[Stream-Aligned Team
Feature de bout en bout] --> E[Produit] B[Platform Team
Infrastructure] --> A C[Enabling Team
Coaching] -.aide.-> A D[Complicated-Subsystem Team
Expert domaine] --> A style A fill:#10b981,stroke:#059669,stroke-width:2px,color:#fff style B fill:#3b82f6,stroke:#1e40af,stroke-width:2px,color:#fff style C fill:#f59e0b,stroke:#d97706,stroke-width:2px,color:#fff style D fill:#8b5cf6,stroke:#6d28d9,stroke-width:2px,color:#fff ``` --- ### 4. **APIs comme frontières organisationnelles** ``` Règle Amazon: "Toute équipe expose un service via API. Communication = API uniquement." Bénéfices: ✅ Contrats clairs ✅ Équipes découplées ✅ Scalabilité organisationnelle ``` --- --- --- ## 🗺️ Carte mentale de synthèse --- ## 🚀 Résultat attendu En comprenant la Loi de Conway, tu deviens capable de : - **Diagnostiquer** les problèmes d'architecture via l'organisation - **Concevoir** l'organisation pour l'architecture voulue - **Éviter** les erreurs (microservices sans équipes autonomes) - **Aligner** structure humaine et structure technique Et surtout : Tu cesses de croire que l'architecture est purement technique. **L'architecture est humaine.** Ton code reflète ton organisation. Change l'un, change l'autre.