Les Lois Universelles de l'Informatique

Introduction

Principe : Certaines lois sont universelles et s'appliquent à TOUS les projets SI, quelle que soit la techno.

"Ceux qui ne connaissent pas l'histoire sont condamnés à la répéter." - George Santayana

Les lois présentées ici sont le résultat de 50+ ans d'observation empirique sur des milliers de projets. Les ignorer = refaire les mêmes erreurs.

A) Loi de Conway (1967)

Énoncé original

"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."
— Melvin Conway, 1967

Traduction simple

"Votre architecture reflétera votre organigramme."

Implications concrètes

Exemple 1 : Organisation en silos techniques

Organisation (Silos) :
┌─────────────┐  ┌─────────────┐  ┌─────────────┐
│   Équipe    │  │   Équipe    │  │   Équipe    │
│  Frontend   │  │   Backend   │  │  Database   │
│ (5 devs)    │  │ (8 devs)    │  │ (2 DBAs)    │
└─────────────┘  └─────────────┘  └─────────────┘
      ↓                 ↓                 ↓
      
Architecture produite (Conway) :
┌─────────────┐       ┌─────────────┐       ┌─────────────┐
│     UI      │──────▶│   API/BL    │──────▶│     DB      │
│  (Angular)  │       │   (Java)    │       │ (Oracle)    │
│             │       │             │       │             │
│ Couche 1    │       │ Couche 2    │       │ Couche 3    │
└─────────────┘       └─────────────┘       └─────────────┘

Problèmes induits :
❌ Couplage en couches rigides (3-tiers classique)
❌ Une feature = coordination obligatoire entre 3 équipes
❌ Goulot d'étranglement DBA (toutes les modifs DB passent par 2 personnes)
❌ Vélocité faible (temps attente entre équipes)
❌ Frustration (devs frontend bloqués par backend, etc.)

Résultat chiffré :
- Time to market feature : 6-8 semaines
- Vélocité : 15 story points/sprint (pour 15 devs !)
- Bugs d'interface : Élevés (handoffs multiples)

Exemple 2 : Feature teams par domaine métier

Organisation (Feature Teams) :
┌──────────────────────────────────────────────┐
│   Squad SALES (autonome end-to-end)          │
│   • 2 devs frontend (React)                  │
│   • 2 devs backend (Node.js)                 │
│   • 1 QA                                     │
│   • 1 Product Owner                          │
│   Total : 6 personnes                        │
└──────────────────────────────────────────────┘

┌──────────────────────────────────────────────┐
│   Squad INVENTORY (autonome end-to-end)      │
│   • 2 devs frontend (React)                  │
│   • 2 devs backend (Node.js)                 │
│   • 1 QA                                     │
│   • 1 Product Owner                          │
│   Total : 6 personnes                        │
└──────────────────────────────────────────────┘

┌──────────────────────────────────────────────┐
│   Platform Team (infrastructure commune)     │
│   • 3 DevOps/SRE                             │
│   • 1 DBA                                    │
│   • 2 Archi/Sécu                             │
│   Total : 6 personnes                        │
└──────────────────────────────────────────────┘
      ↓
      
Architecture produite (Conway) :
┌──────────────────┐       ┌──────────────────┐
│  Sales Service   │       │Inventory Service │
│  (Bounded Ctx)   │◀──────│  (Bounded Ctx)   │
│                  │ Events│                  │
│  • UI            │       │  • UI            │
│  • API           │       │  • API           │
│  • Domain        │       │  • Domain        │
│  • DB Schema     │       │  • DB Schema     │
└──────────────────┘       └──────────────────┘

Avantages :
✅ Équipes autonomes end-to-end (UI → DB)
✅ Une feature = 1 seule équipe mobilisée
✅ Pas de coordination overhead
✅ Vélocité élevée (chaque squad optimisée)
✅ Ownership clair (Sales = Squad Sales)

Résultat chiffré :
- Time to market feature : 1-2 semaines
- Vélocité : 45 story points/sprint (pour 18 devs = 3 squads × 6)
- Bugs d'interface : Faibles (équipe intégrée)

Tableau comparatif : Impact organisation sur architecture

Structure organisation	Architecture résultante	Vélocité	Coordination	Scalabilité équipes	Exemple
Silos fonctionnels (Frontend/Backend/DBA)	Monolithe 3-tiers couplé	⭐⭐ Faible	⚠️⚠️⚠️ Élevée	❌ Difficile	Banques traditionnelles
Équipe unique (<10 personnes)	Monolithe modulaire cohérent	⭐⭐⭐⭐⭐ Très élevée	✅ Minimale	❌ Non scalable	Startups early-stage
Feature teams (domaine métier)	Microservices alignés métier	⭐⭐⭐⭐ Élevée	✅ Faible	✅✅ Excellente	Spotify, Amazon
Component teams (par techno)	Services techniques fragmentés	⭐⭐ Faible	⚠️⚠️⚠️⚠️ Très élevée	⚠️ Moyenne	Anti-pattern à éviter

Cas réels d'application

Amazon (2002) : Two-Pizza Teams

Contexte :
2001 : Amazon = monolithe géant, équipes 20-30 personnes, vélocité catastrophique

Décision Jeff Bezos (2002) :
Mandate "Two-pizza teams" = équipes max 6-8 personnes (nourries par 2 pizzas)

Règles imposées :

Chaque équipe = 1 service avec API publique
Communication UNIQUEMENT via APIs (pas d'accès DB direct entre équipes)
Chaque équipe = autonomie totale (techno, déploiement, infrastructure)

Résultat (Conway en action) :

2002 : Architecture monolithique
       Équipes réorganisées en Two-Pizza Teams

2004 : Architecture microservices émerge naturellement
       (sans directive explicite "faites des microservices")

2006 : 200+ microservices opérationnels

2024 : 10 000+ microservices

Enseignement :
Amazon n'a PAS décidé "on va faire des microservices". Ils ont décidé "on va faire des petites équipes autonomes". L'architecture microservices a émergé comme conséquence de Conway.

Spotify : Squads/Tribes/Chapters/Guilds

Modèle organisationnel :

SQUAD (6-9 personnes)
- Équipe produit autonome
- Mission : Feature/Domaine précis
- Composition : Full-stack (dev + QA + PO)

TRIBE (40-150 personnes)
- Collection de Squads liés
- Objectif business commun
- Exemple : Tribe "Discovery" (recherche musique)

CHAPTER (techno/craft)
- Même métier, squads différents
- Exemple : Chapter "Frontend" = tous les devs frontend
- Rôle : Partage pratiques, standards

GUILD (communauté d'intérêt)
- Transverse à toute l'entreprise
- Exemple : Guild "Testing", Guild "Agile"
- Rôle : Innovation, veille

Architecture résultante (Conway) :

Chaque Squad → 1 Service découplé
Communication entre Squads → APIs/Events
Résultat : 100+ services autonomes alignés domaines fonctionnels

Exemple :
Squad "Search" → Service Search (API recherche)
Squad "Recommendations" → Service Reco (API suggestions)
Squad "Playlists" → Service Playlists (CRUD playlists)

Chiffres :

100+ squads autonomes
Déploiements indépendants (1 squad = N déploiements/jour sans impacter autres)
Innovation rapide (chaque squad expérimente)

L'Inverse Conway Maneuver

Principe :

"Si votre architecture cible est claire, réorganisez vos équipes pour qu'elles la produisent naturellement."

Processus :

❌ Approche classique (subie) :
1. Équipes organisées (historique)
2. Équipes produisent architecture
3. Architecture = accident organisationnel

✅ Inverse Conway Maneuver :
1. Définir architecture cible (ex: Monolithe modulaire DDD)
2. Identifier Bounded Contexts clairs
3. Réorganiser équipes alignées sur Contexts
4. Laisser Conway opérer → Architecture émerge COMME VOULU

Exemple refonte SI :

ÉTAPE 1 : Définir architecture cible
─────────────────────────────────────
Architecture : Monolithe modulaire avec 4 Bounded Contexts
- Sales (Ventes & Commandes)
- Inventory (Stock & Approvisionnement)
- Shipping (Expédition & Livraison)
- Customer Management (CRM)

ÉTAPE 2 : Identifier compétences nécessaires par Context
─────────────────────────────────────────────────────────
Sales Context :
- 2 devs backend (logique commandes complexe)
- 2 devs frontend (UX checkout critique)
- 1 QA
- 1 PO

Inventory Context :
- 2 devs backend (logique stock temps réel)
- 1 dev frontend (backoffice simple)
- 1 QA
- 1 PO

ÉTAPE 3 : Réorganiser équipes
──────────────────────────────
Avant (silos) :
- Équipe Frontend (6 devs)
- Équipe Backend (8 devs)
- QA Team (3 QA)

Après (feature teams) :
- Squad Sales (6 personnes : 2 FE, 2 BE, 1 QA, 1 PO)
- Squad Inventory (5 personnes : 1 FE, 2 BE, 1 QA, 1 PO)
- Squad Shipping (4 personnes : 1 FE, 2 BE, 1 QA)
- Squad Customer (4 personnes : 2 FE, 1 BE, 1 QA)
- Platform Team (6 personnes : 4 DevOps, 1 DBA, 1 Sécu)

ÉTAPE 4 : Conway opère
───────────────────────
Après 3-6 mois :
- Chaque Squad a naturellement construit SON module
- Interfaces entre modules = APIs internes propres
- Bounded Contexts respectés (pas de couplage sauvage)
- Architecture produite = EXACTEMENT ce qu'on voulait !

Bénéfices mesurables :

KPI	Avant (silos)	Après (feature teams)	Amélioration
Time to market feature	6 semaines	2 semaines	-66%
Vélocité totale	25 pts/sprint	55 pts/sprint	+120%
Bugs production	18/mois	7/mois	-61%
Satisfaction équipe (NPS)	42	78	+86%

B) Lois de Lehman (1974-1996)

Contexte :
Meir M. Lehman, chercheur à Imperial College London, a étudié l'évolution de systèmes logiciels sur 20+ ans (IBM OS/360, etc.)

Résultat : 8 lois fondamentales de l'évolution logicielle

Loi 1 : Changement Continu (Continuing Change)

Énoncé :

"Un système qui est utilisé doit être continuellement adapté, sinon il devient progressivement moins satisfaisant."

Traduction :

Le business évolue → le SI doit évoluer
Freeze = obsolescence progressive
Pas d'évolution = perte de valeur

Implications refonte SI :

❌ ERREUR CLASSIQUE :
"Le nouveau SI sera stable 10 ans sans modification"

✅ RÉALITÉ :
"Le nouveau SI sera évolutif en continu"

Budget à prévoir :
─────────────────
Ne pas prévoir uniquement Build (18 mois, 2M€)
Prévoir Run + Évolution (annuel, ∞)

Formule recommandée :
Budget évolution annuel = 15-20% de l'investissement initial

Exemple :
Refonte : 2M€
Budget évolution/an : 300-400K€ (maintenance + nouvelles features)

Exemple e-commerce :

2020 : Lancement SI (fonctionnalités)
─────────────────────────────────────
✅ Catalogue produits
✅ Panier
✅ Paiement CB (Stripe)
✅ Livraison standard

2021 : Évolutions obligatoires (marché)
────────────────────────────────────────
+ Apple Pay, Google Pay (clients demandent)
+ Avis clients (concurrents ont)
+ Wishlist (standard e-commerce)
Coût évolutions : 250K€

2022 : Nouvelles attentes
──────────────────────────
+ Buy Now Pay Later - Klarna (tendance forte)
+ Click & Collect (post-COVID)
+ Programme fidélité
Coût évolutions : 180K€

2023 : Innovation
──────────────────
+ Paiements crypto (early adopters)
+ Recommandations IA
+ Chatbot support
Coût évolutions : 320K€

2024 : Réglementation + Concurrence
────────────────────────────────────
+ Open Banking / DSP2 (obligatoire UE)
+ Livraison 1h (Amazon Prime copycat)
+ AR essayage virtuel (différenciation)
Coût évolutions : 420K€

TOTAL 2021-2024 : 1.17M€ d'évolutions
(vs 2M€ investissement initial)

Sans évolution continue :
→ Clients partent vers concurrents plus modernes
→ CA perdu estimé : -15% sur 4 ans = -3M€
→ ROI évolutions : 1.17M€ investis → 3M€ CA sauvegardé = ROI 156%

KPIs à suivre :

KPI	Cible	Seuil alerte	Action si écart
% Budget IT consacré évolution	15-20%	< 10%	Risque obsolescence, augmenter
Time to market nouvelle feature	< 4 semaines	> 8 semaines	Rigidité architecture, refactoring
NPS satisfaction clients	> 50	< 30	Manque features vs concurrents
Écart features vs top 3 concurrents	< 10%	> 30%	Rattrapage urgence

Loi 2 : Complexité Croissante (Increasing Complexity)

Énoncé :

"La complexité d'un système augmente au fil du temps, sauf si on travaille activement à la réduire."

C'est l'entropie ! (déjà vu dans section précédente)

Graphique :

Complexité (Complexité cyclomatique moyenne)
    │
 30 │              ╱╱╱╱ Sans refactoring
    │             ╱╱╱   (Code spaghetti)
 25 │            ╱╱╱
    │           ╱╱╱
 20 │          ╱╱╱
    │         ╱╱╱
 15 │        ╱╱╱
    │       ╱╱╱
 10 │      ╱╱╱─────────── Avec refactoring continu
    │     ╱╱╱             (Complexité maîtrisée)
  5 │    ╱╱╱
    │   ╱╱╱
  0 │──╱╱─────────────────────────────────────▶ Temps
    0  1   2   3   4   5   6   7   8   9  10 (années)
    
Seuil intenable (complexité > 20) → Refonte obligatoire

Implications concrètes :

SANS refactoring (laissez-faire) :
──────────────────────────────────
Année 1 : Complexité moyenne = 5 (code propre initial)
Année 2 : Complexité moyenne = 7 (+40%)
Année 3 : Complexité moyenne = 10 (+100%)
Année 4 : Complexité moyenne = 15 (+200%)
Année 5 : Complexité moyenne = 23 (+360% !) → Intenable

Conséquences mesurables :
- Vélocité : -60% (de 50 pts/sprint à 20 pts/sprint)
- Bugs : +200% (corrections créent nouveaux bugs)
- Onboarding nouveaux devs : 6 mois (vs 1 mois au début)
- Turnover : 50%/an (frustration équipe)

AVEC refactoring continu (20% temps dédié) :
─────────────────────────────────────────────
Année 1 : Complexité moyenne = 5
Année 2 : Complexité moyenne = 6 (+20%)
Année 3 : Complexité moyenne = 7 (+40%)
Année 4 : Complexité moyenne = 7 (stable, refactoring compense)
Année 5 : Complexité moyenne = 7 (stable)

Conséquences mesurables :
- Vélocité : stable (50 pts/sprint maintenu)
- Bugs : stable (+10% seulement)
- Onboarding : 2 mois (documenté, code lisible)
- Turnover : 15%/an (normal)

Stratégie anti-complexité :

Action	Fréquence	Coût	ROI	Responsable
20% Rule	Chaque sprint	20% vélocité	Vélocité stable long terme	Équipe
Boy Scout Rule	À chaque commit	Gratuit (discipline)	Amélioration continue	Développeur
Code reviews	Chaque PR	30min/PR	-40% bugs	Pairs
Refactoring sprints	1×/trimestre	1 sprint complet	Dette réduite -25%	Tech Lead
SonarQube	CI/CD automatique	5K€/an licence	Mesure objective	DevOps
Architecture reviews	1×/mois	2h réunion	Éviter dérives	Architecte

KPIs complexité :

Métrique	Outil	Cible	Seuil alerte	Fréquence mesure
Complexité cyclomatique moyenne	SonarQube	< 10	> 15	Chaque commit (CI)
Duplication code	SonarQube	< 3%	> 5%	Chaque commit
Lignes code/fichier	Linter	< 300	> 500	Chaque commit
Dépendances circulaires	Archi tools	0	> 0	Hebdo
Tech debt ratio	SonarQube	< 5%	> 10%	Quotidien

Loi 3 : Auto-Régulation (Self Regulation)

Énoncé :

"Le processus d'évolution d'un système est auto-régulé par des mécanismes de feedback."

Traduction :

Vélocité tend vers un plateau (équilibre naturel)
Processus s'installent naturellement
Métriques guident les décisions (boucles feedback)

Implications DevOps :

PRINCIPE : Boucles de feedback courtes > longues

Exemple Feedback Court (BIEN ✅) :
───────────────────────────────────
Code → Tests (2min) → CI (5min) → Deploy staging (10min) → Monitoring (temps réel)
 └────────────────────────────────────────────────────────────────────────────────┘
                         Feedback loop : 17 minutes

Développeur sait en 17min si son code est OK
→ Correction immédiate si problème
→ Contexte frais en mémoire
→ Fix rapide (15min)

Exemple Feedback Long (MAL ❌) :
─────────────────────────────────
Code → Dev branch (1 semaine) → Merge (2 jours review) → Tests manuels (1 semaine) → Staging (1 semaine) → Prod (1 semaine)
 └────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
                         Feedback loop : 4.5 semaines

Développeur sait en 1 mois si son code est OK
→ Contexte oublié
→ Fix difficile (2 jours, réapprentissage)
→ Risque régression

Boucles feedback à installer :

Boucle	Délai cible	Outil	Déclencheur	Action si écart
Tests unitaires	< 2min	Jest, JUnit	Chaque commit local	Fix immédiat dev
Lint/Format	< 30s	ESLint, Prettier	Pre-commit hook	Auto-fix
CI (tests complets)	< 15min	GitHub Actions	Push branch	Bloquer merge si fail
Déploiement staging	< 30min	Terraform, K8s	Merge main	Rollback auto si fail
Smoke tests prod	< 5min	Selenium, Cypress	Déploiement prod	Alerte PagerDuty
Monitoring perf	Temps réel	Datadog, Grafana	Continu	Alerte si latency > seuil
Sprint velocity	Fin sprint (2 sem)	Jira	Fin sprint	Rétrospective si < target
NPS clients	Mensuel	Enquête	1er du mois	Action si < 50

KPIs auto-régulation :

Métrique	Formule	Cible	Signification
Lead Time	Temps commit → prod	< 24h	Agilité déploiement
Cycle Time	Temps début dev → prod	< 5 jours	Efficacité process
MTTR (Mean Time To Repair)	Temps détection bug → fix prod	< 2h	Résilience
MTBF (Mean Time Between Failures)	Temps entre incidents	> 30 jours	Stabilité
Deployment Frequency	Déploiements/jour	> 10	Maturité DevOps

Loi 4 : Conservation de la Stabilité Organisationnelle (Organisational Stability)

Énoncé :

"Le taux de travail effectif (activité productive) sur un système reste constant ou décline."

Corollaire : Loi de Brooks

"Ajouter des personnes à un projet en retard le retarde davantage."

Explication mathématique :

Communication overhead :

2 personnes : 1 lien
3 personnes : 3 liens
5 personnes : 10 liens
10 personnes : 45 liens
20 personnes : 190 liens
50 personnes : 1225 liens !

Formule : n×(n-1)/2

Temps communication = f(n²)
Temps productif = f(n)

Au-delà de 8-9 personnes :
Temps communication > Temps productif gagné
→ Productivité marginale décroissante

Graphique productivité :

Productivité (Story Points/Sprint)
    │
100 │                      ╱────────  Plateau
    │                    ╱
 80 │                  ╱
    │                ╱
 60 │              ╱
    │            ╱
 40 │          ╱
    │        ╱
 20 │      ╱
    │    ╱
  0 │───┴────────────────────────────────▶ Taille équipe
    0   5   10  15  20  25  30  35  40

Productivité optimale : 6-9 personnes (Two-Pizza Team)
Au-delà : Overhead communication annule gains

Implications pratiques :

Projet en retard de 3 mois :

❌ Solution illusoire : Doubler l'équipe (10 → 20 devs)
Résultat attendu : Diviser retard par 2 (1.5 mois retard)
Résultat réel : Retard augmente à 5 mois !

Pourquoi ?
1. Ramp-up time : Nouveaux devs productifs en 3-6 mois
2. Formation : Devs existants mobilisés (50% temps pendant 2 mois)
3. Communication : Overhead ×4 (10→20 devs = 45→190 liens)
4. Chaos temporaire : Organisation perturbée

Formule Brooks :
Temps projet avec renfort = Temps initial + (N nouveaux × Ramp-up) + Overhead

Exemple chiffré :
Retard initial : 3 mois
Ajout 10 devs :
- Ramp-up : 10 devs × 3 mois × 50% productivité = 15 mois-homme perdus
- Formation : 10 devs × 50% temps formateur × 2 mois = 10 mois-homme perdus
Total perdu : 25 mois-homme
Équipe 20 devs produit : 20 devs × 3 mois = 60 mois-homme
Mais 25 perdus → Net 35 mois-homme (vs 30 attendus)
→ Retard augmente !

✅ Solutions réalistes :
1. Réduire scope (MVP) : -30% features → Livraison à temps
2. Améliorer processus : Automatisation → +20% productivité
3. Résoudre bottlenecks : Identifier goulot (ex: DBA) → +1 DBA ciblé
4. Délai réaliste renegocié : +3 mois assumés, qualité maintenue

Taille optimale équipes :

Type équipe	Taille	Productivité	Communication	Exemple
Solo	1 dev	⭐⭐ Faible	✅ Nulle	Prototype, POC
Duo	2 devs	⭐⭐⭐ Moyenne	✅ Minimale	Pair programming
Squad	6-9 devs	⭐⭐⭐⭐⭐ Maximale	✅ Gérable	Amazon Two-Pizza
Équipe	10-15 devs	⭐⭐⭐⭐ Élevée	⚠️ Importante	Équipe produit
Département	20-50 devs	⭐⭐⭐ Moyenne	⚠️⚠️ Très élevée	Multiple squads
Division	50+ devs	⭐⭐ Faible	⚠️⚠️⚠️ Ingérable	Nécessite sous-divisions

KPIs stabilité organisationnelle :

Métrique	Formule	Cible	Interprétation
Productivité/dev	Story points / Nb devs	> 5 pts/dev	Efficacité individuelle
Overhead communication	(Meetings h/semaine) / 40h	< 30%	Temps coordination
Vélocité/squad	Story points squad	40-60 pts	Optimal si 6-9 devs
Turnover	Départs/an / Effectif	< 15%	Stabilité équipe

Loi 5 : Conservation de la Familiarité (Conservation of Familiarity)

Énoncé :

"Les changements incrémentaux doivent rester en dessous d'un certain seuil pour que les utilisateurs et développeurs restent familiers avec le système."

Traduction :

Big Bang = rupture cognitive (cerveau humain ne suit pas)
Changements progressifs > révolution brutale
Migration incrémentale > rewrite total

Implications refonte SI :

❌ BIG BANG (Vendredi soir → Lundi matin) :
────────────────────────────────────────────
Vendredi 23h59 : Ancien SI éteint
Samedi 00h00 : Nouveau SI allumé
Lundi 8h : Utilisateurs découvrent TOUT a changé

Risques :
1. Rupture cognitive utilisateurs :
   - 500 utilisateurs perdus (où est le bouton X ?)
   - Tickets support : ×10 (de 20/jour à 200/jour)
   - Productivité : -60% pendant 2 semaines
   - Frustration massive (NPS chute de 70 à 30)

2. Bugs massifs non détectés :
   - 100% fonctions changées = 100% surface à tester
   - Bugs critiques en prod (paiements KO, commandes perdues)
   - Équipe débordée (impossible tout fixer)

3. Rollback impossible :
   - Données déjà migrées (pas de retour arrière)
   - "On est obligés de réparer en live"
   - Nuits blanches pendant 2 semaines

4. Résistance au changement :
   - "C'était mieux avant"
   - Pétition utilisateurs (vu en vrai !)
   - Management sous pression

Résultat réel (cas vécu) :
- Bugs critiques : 47 en 1 semaine
- Downtime : 12h cumulées sur 5 jours
- CA perdu : 250K€
- Satisfaction clients : -40 points NPS
- Turnover équipe : 3 démissions (burnout)


✅ STRANGLER PATTERN (Migration progressive 18 mois) :
───────────────────────────────────────────────────────
Principe : Migrer module par module, utilisateurs par utilisateurs

Mois 1-3 : Module Catalogue Produits
- 20% utilisateurs pilotes (early adopters)
- Ancien SI toujours là (fallback)
- Feedback continu, corrections rapides
- Formation ciblée 50 utilisateurs

Mois 4-6 : Module Panier & Checkout
- 50% utilisateurs (si Catalogue OK)
- Cohabitation ancien/nouveau
- Synchronisation données bidirectionnelle
- Formation progressive

Mois 7-9 : Module Paiements
- 80% utilisateurs
- Ancien système en "lecture seule"
- Monitoring renforcé (criticité)

Mois 10-12 : Module Gestion Commandes
- 100% utilisateurs
- Ancien SI encore accessible (consultation)

Mois 13-18 : Migration données historiques + Décommissionnement
- Anciens modules éteints progressivement
- Archive ancien SI (lecture seule 2 ans)

Avantages :
✅ Familiarité maintenue (changement < 20% système à la fois)
✅ Rollback facile (module par module)
✅ Apprentissage progressif (pas de choc)
✅ Bugs limités (surface réduite)
✅ Validation continue (feedback utilisateurs)

Résultat mesuré :
- Bugs critiques : 8 sur 18 mois (vs 47 en 1 semaine Big Bang)
- Downtime : 2h cumulées (vs 12h)
- CA perdu : 15K€ (vs 250K€)
- Satisfaction : NPS stable 68 → 72 (vs chute 70 → 30)
- Turnover : 0 (vs 3 démissions)

Seuil de changement tolérable :

% Système changé	Réaction utilisateurs	Formation nécessaire	Risque échec	Recommandation
< 10%	✅ Transparent	Aucune	⭐ Très faible	Idéal (évolutions continues)
10-20%	🟡 Noté mais accepté	Tooltip, email	⭐⭐ Faible	OK (release trimestrielle)
20-40%	🟠 Perturbant	Formation 2h	⭐⭐⭐ Moyen	Limite acceptable (avec préparation)
40-70%	🔴 Choc cognitif	Formation 1 jour	⭐⭐⭐⭐ Élevé	Migration progressive obligatoire
> 70%	💀 Rejet massif	Formation 1 semaine	⭐⭐⭐⭐⭐ Critique	Big Bang = suicide

KPIs familiarité :

Métrique	Mesure	Cible	Seuil alerte
Taux adoption	% utilisateurs actifs nouveau SI	> 80%	< 60%
Tickets support	Nb tickets/jour post-migration	< baseline ×1.5	> baseline ×3
Time on task	Temps réaliser tâche standard	< baseline ×1.2	> baseline ×2
Net Promoter Score	NPS (recommandation)	Stable ±10 points	Chute > 20 points
Error rate utilisateurs	% actions échouées	< 2%	> 5%

Loi 6 : Croissance Continue (Continuing Growth)

Énoncé :

"Le contenu fonctionnel d'un système doit croître continuellement pour maintenir la satisfaction utilisateur."

Traduction :

Attentes utilisateurs augmentent avec le temps
Stagnation = déception
Innovation continue nécessaire

Évolution attentes clients e-commerce :

2010 : Attentes de base
───────────────────────
✅ Fiche produit avec photo
✅ Panier
✅ Paiement CB
✅ Livraison 5-7 jours
= SUFFISANT pour satisfaire clients

2015 : Nouvelles attentes (baseline relevée)
────────────────────────────────────────────
✅ Photos HD multiples + zoom
✅ Avis clients + notes
✅ Wishlist
✅ Recommandations produits
✅ Livraison express 48h
✅ Suivi colis temps réel
= Minimum syndical (pas de différenciation)

2020 : Attentes post-COVID
───────────────────────────
✅ Click & Collect (retrait magasin)
✅ Livraison 24h
✅ Chat support temps réel
✅ Réalité augmentée (essayage virtuel)
✅ Paiement fractionné (Klarna, Alma)
✅ Programme fidélité
= Baseline élevée

2024 : Attentes actuelles
──────────────────────────
✅ Livraison 1h (Amazon Prime)
✅ Personnalisation IA (recommandations hyper-ciblées)
✅ Recherche visuelle (photo → produit)
✅ Assistant vocal
✅ Carbon footprint produit (éco-responsabilité)
✅ Abonnements (vs achat one-shot)
= Différenciation compétitive

Constante : Ce qui était "wow" en 2010 est obsolète en 2024

Impact business :

Scénario 1 : Stagnation fonctionnelle
──────────────────────────────────────
2020 : Lancement SI avec features 2020
2021 : Aucune évolution
2022 : Aucune évolution
2023 : Aucune évolution
2024 : SI identique à 2020

Conséquences mesurées :
- NPS clients : 70 (2020) → 45 (2024) (-35%)
- Taux conversion : 3.2% (2020) → 2.1% (2024) (-34%)
- Panier moyen : 85€ (2020) → 78€ (2024) (-8%)
- Parts de marché : 12% (2020) → 7% (2024) (-42%)
- CA : 10M€ (2020) → 7M€ (2024) (-30%)

Scénario 2 : Innovation continue
─────────────────────────────────
2020 : Lancement SI
2021 : +Click & Collect, +Avis clients améliorés
2022 : +Chat support, +Recommandations IA
2023 : +Paiement fractionné, +Livraison 1h grandes villes
2024 : +Recherche visuelle, +Programme fidélité

Conséquences mesurées :
- NPS clients : 70 (2020) → 78 (2024) (+11%)
- Taux conversion : 3.2% (2020) → 4.1% (2024) (+28%)
- Panier moyen : 85€ (2020) → 95€ (2024) (+12%)
- Parts de marché : 12% (2020) → 16% (2024) (+33%)
- CA : 10M€ (2020) → 15.2M€ (2024) (+52%)

ROI innovation :
Investissement évolutions : 1.2M€ sur 4 ans
CA additionnel : 5.2M€ (vs stagnation)
ROI : 333%

Budget innovation recommandé :

Allocation budget IT annuel :

60-70% RUN (Maintien existant)
- Infrastructure, support, bugs, sécurité
- Exemple : 600K€/an

15-20% ÉVOLUTION (Améliorations)
- Optimisations, refactoring, minor features
- Exemple : 180K€/an

15-20% INNOVATION (Nouvelles capacités)
- R&D, POCs, nouvelles features différenciantes
- Exemple : 180K€/an

TOTAL : 960K€/an

Si 100% RUN (0% innovation) :
→ Obsolescence progressive
→ Perte compétitivité
→ Refonte nécessaire sous 5 ans (×10 coût)

KPIs croissance fonctionnelle :

Métrique	Formule	Cible	Interprétation
Feature velocity	Nouvelles features/trimestre	> 5	Innovation continue
Feature usage	% users utilisant features récentes	> 60%	Pertinence innovations
NPS évolution	Δ NPS année N vs N-1	Stable ou ↗️	Satisfaction maintenue
Écart concurrents	Features vs top 3 concurrents	< 10% écart	Compétitivité
Time to market feature	Idée → Production	< 8 semaines	Agilité

Loi 7 : Qualité Décroissante (Declining Quality)

Énoncé :

"Sauf si rigoureusement maintenue et adaptée, la qualité perçue d'un système déclinera."

Traduction :

Sans effort continu, qualité ↓
Tests automatisés obligatoires
Monitoring permanent nécessaire

Évolution qualité sans maintenance :

Système sans stratégie qualité :

Année 1 : Qualité initiale élevée
─────────────────────────────────
- Code propre (développé récemment)
- Tests : 75% couverture
- Bugs : 3/mois
- Performance : P95 150ms
- Satisfaction : NPS 75

Année 2 : Premières dégradations
─────────────────────────────────
- Hotfixes sans tests (pression business)
- Couverture tests : 68% (-7%, tests pas maintenus)
- Bugs : 8/mois (+167%)
- Performance : P95 220ms (+47%)
- Satisfaction : NPS 68

Année 3 : Dégradation accélérée
────────────────────────────────
- Code spaghetti (pas de refactoring)
- Couverture tests : 52% (nouveaux modules non testés)
- Bugs : 18/mois (+500% vs An 1)
- Performance : P95 380ms (+153%)
- Satisfaction : NPS 58

Année 5 : Crise qualité
────────────────────────
- Peur de toucher au code (régression)
- Couverture tests : 31% (inutiles car code trop couplé)
- Bugs : 42/mois (+1300% !)
- Performance : P95 850ms (+467%)
- Satisfaction : NPS 42
- Incidents majeurs : 1/mois (downtime)

Coût total qualité dégradée :
- Support bugs : 15h/semaine × 52 sem × 75€/h = 58K€/an
- Incidents : 12/an × 4h downtime × 10K€ CA/h = 480K€/an
- Clients perdus : -10% CA = -1M€/an
TOTAL : 1.54M€/an de coût qualité !

Stratégie maintien qualité :

Definition of Done (DoD) stricte :
───────────────────────────────────
Avant merge en main, OBLIGATOIRE :

- [ ] Tests unitaires écrits (couverture nouvelle feature > 80%)
- [ ] Tests intégration si interactions DB/API
- [ ] Code review approuvé (2 reviewers)
- [ ] SonarQube : 0 bugs critiques, 0 vulnérabilités
- [ ] Performance : latency < baseline +10%
- [ ] Documentation mise à jour (ADR si décision archi)
- [ ] Tests E2E si parcours critique modifié
- [ ] Déployé en staging et validé fonctionnellement

Si 1 seul critère KO → Merge BLOQUÉ

CI/CD Quality Gates :
──────────────────────
GitHub Actions / GitLab CI :

1. Build (5min)
2. Tests unitaires (5min)
   - Si couverture < 80% → ❌ BUILD FAIL
3. Tests intégration (8min)
   - Si 1 test fail → ❌ BUILD FAIL
4. SonarQube scan (3min)
   - Si bugs critiques > 0 → ❌ BUILD FAIL
   - Si vulnérabilités > 0 → ❌ BUILD FAIL
   - Si duplication > 3% → ⚠️ WARNING
5. Performance tests (10min)
   - Si latency > baseline +20% → ❌ BUILD FAIL
6. Deploy staging (5min)
7. Smoke tests (3min)
   - Si fail → ❌ ROLLBACK AUTO

Total pipeline : ~40min
Feedback développeur : Rapide (<1h)
Qualité : Garantie (impossible merger du code pourri)

KPIs qualité :

Métrique	Outil	Cible	Seuil alerte	Action si écart
Couverture tests	Coverage.py, Istanbul	> 80%	< 70%	Sprint refactoring + tests
Bugs prod/release	Jira	< 5	> 15	Renforcer tests, code reviews
Complexité cyclomatique	SonarQube	< 10	> 15	Refactoring obligatoire
Dette technique	SonarQube	< 5%	> 10%	Sprint dédié dette
Duplication code	SonarQube	< 3%	> 5%	Extraction méthodes/composants
Vulnérabilités	Snyk, Dependabot	0 critiques	> 0	Patch immédiat
P95 latency	Datadog, New Relic	< 200ms	> 500ms	Profiling, optimisation
Error rate	Logs	< 0.5%	> 1%	Investigation urgente

Loi 8 : Feedback Multi-Niveaux (Feedback System)

Énoncé :

"Les processus d'évolution logicielle constituent un système multi-niveaux, multi-boucles, multi-agents avec feedback."

Traduction :

Multiples boucles de feedback imbriquées (du dev au CEO)
Toutes interagissent
Optimiser TOUTES les boucles

Schéma feedback pyramide :

┌─────────────────────────────────────────────────────────────┐
│                 FEEDBACK STRATÉGIQUE                        │
│                  (Trimestriel : OKRs)                       │
│                                                             │
│  Inputs : NPS clients, CA, parts marché                    │
│  KPIs : ROI, VAN, Time to market                           │
│  Output : Ajustements roadmap produit                      │
│  ┌───────────────────────────────────────────────────────┐ │
│  │          FEEDBACK TACTIQUE                            │ │
│  │        (Hebdo : Sprint Review)                        │ │
│  │                                                       │ │
│  │  Inputs : Vélocité, bugs, feedback users             │ │
│  │  KPIs : Burndown, qualité, délais                    │ │
│  │  Output : Priorisation backlog, décisions techniques │ │
│  │  ┌─────────────────────────────────────────────────┐ │ │
│  │  │     FEEDBACK OPÉRATIONNEL                       │ │ │
│  │  │      (Temps réel : CI/CD)                       │ │ │
│  │  │                                                 │ │ │
│  │  │  Inputs : Tests, perf, logs, métriques         │ │ │
│  │  │  KPIs : Latency, errors, CPU                   │ │ │
│  │  │  Output : Alertes, auto-scaling                │ │ │
│  │  │  ┌───────────────────────────────────────────┐ │ │ │
│  │  │  │    FEEDBACK DÉVELOPPEUR                   │ │ │ │
│  │  │  │     (Minutes : Tests locaux)              │ │ │ │
│  │  │  │                                           │ │ │ │
│  │  │  │  Inputs : Code commit                     │ │ │ │
│  │  │  │  KPIs : Tests pass/fail, linter          │ │ │ │
│  │  │  │  Output : Fix ou commit                   │ │ │ │
│  │  │  └───────────────────────────────────────────┘ │ │ │
│  │  └─────────────────────────────────────────────────┘ │ │
│  └───────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘

Interaction boucles :
Niveau Dev → Niveau Ops : Tests fail → Alerte monitoring
Niveau Ops → Niveau Tactique : Incidents ↗️ → Sprint stabilisation
Niveau Tactique → Niveau Stratégique : Vélocité ↘️ → Investir dette technique
Niveau Stratégique → Niveau Tactique : NPS ↘️ → Pivot fonctionnel

Exemples concrets feedback :

Niveau 1 (Développeur - Minutes) :
───────────────────────────────────
Événement : Commit code
Feedback : Tests fail en 2min (CI local)
Action : Fix immédiat (5min)
Délai boucle : 7 minutes

Niveau 2 (Opérationnel - Heures) :
───────────────────────────────────
Événement : Déploiement prod
Feedback : Latency P95 passe de 150ms à 300ms
Action : Rollback automatique (5min)
Délai boucle : 10 minutes

Niveau 3 (Tactique - Jours/Semaines) :
───────────────────────────────────────
Événement : Sprint terminé
Feedback : Vélocité 30 pts (vs target 50 pts)
Action : Rétrospective → Identifier dette technique → Sprint refactoring
Délai boucle : 2 semaines

Niveau 4 (Stratégique - Mois/Trimestres) :
───────────────────────────────────────────
Événement : Trimestre écoulé
Feedback : NPS clients chute de 70 à 55
Action : Analyse → Fonctionnalités manquantes vs concurrents → Pivot roadmap
Délai boucle : 3 mois

Optimisation boucles feedback :

Niveau	Délai actuel (avant)	Délai cible (après)	Optimisation	Gain
Dev	1h (CI centralisé)	5min (CI local)	Pre-commit hooks, tests rapides	-92%
Ops	1 jour (logs analysés manuellement)	2min (alertes auto)	Monitoring temps réel, PagerDuty	-99%
Tactique	1 mois (reporting mensuel)	1 semaine (sprint review)	Agile, Jira dashboards	-75%
Stratégique	1 an (bilan annuel)	1 trimestre (OKRs)	OKRs trimestriels, NPS mensuel	-75%

C) Autres Lois Pertinentes

Loi de Brooks (1975) - Détails

Énoncé complet :

"Ajouter des ressources humaines à un projet en retard le retarde davantage."
— Frederick Brooks, "The Mythical Man-Month"

Formule mathématique :

Temps projet avec renfort = 
    Temps initial 
  + (Nombre nouveaux × Temps ramp-up × Inefficacité initiale)
  + Overhead communication
  - Gain parallélisation (si tâches parallélisables)

Overhead communication = f(n²)
Gain parallélisation = f(n) mais limité (pas toutes tâches parallélisables)

Résultat : Overhead > Gain → Délai augmente

Raisons détaillées :

1. Ramp-up time (Montée en compétence)
───────────────────────────────────────
Nouveau dev productif en : 3-6 mois
Mois 1 : 20% productivité (découverte codebase)
Mois 2 : 40% productivité (comprend archi)
Mois 3 : 60% productivité (première PR conséquente)
Mois 4-6 : 80-100% productivité

10 nouveaux devs × 3 mois × 50% productivité moyenne
= 15 mois-homme PERDUS

2. Formation (Temps devs existants mobilisés)
──────────────────────────────────────────────
Chaque nouveau dev nécessite :
- 1 senior mentor (50% temps pendant 2 mois)
- Code reviews détaillées (×3 temps normal)
- Réunions explication archi

10 devs × 1 senior × 50% × 2 mois = 10 mois-homme PERDUS

3. Communication overhead
──────────────────────────
10 devs → 20 devs = 45 liens → 190 liens (×4.2)
Meetings hebdo : 2h → 4h
Coordination : +50% temps

20 devs × 50% temps coordination × 3 mois = 30 mois-homme PERDUS

4. Partitionnement limité
──────────────────────────
Toutes les tâches ne sont PAS parallélisables
Exemple : "9 femmes ne font pas un bébé en 1 mois"

Module critique nécessite 1 expert senior
Ajouter 10 juniors n'accélère PAS ce module

TOTAL PERDU : 55 mois-homme
GAIN ATTENDU : 10 devs × 3 mois = 30 mois-homme
NET : -25 mois-homme → RETARD AUGMENTE !

Loi de Parkinson (1955)

Énoncé :

"Le travail s'étend de manière à remplir le temps disponible pour son achèvement."
— Cyril Northcote Parkinson

Implications Agile :

Sans deadline (laissez-faire) :
────────────────────────────────
Tâche : "Développer API commandes"
Temps réel nécessaire : 3 jours
Temps sans deadline : 2 semaines !

Pourquoi ?
- Perfectionnisme (sur-engineering)
- Procrastination ("j'ai le temps")
- Scope creep ("et si j'ajoutais aussi...")

Avec deadline stricte (Time-boxing) :
─────────────────────────────────────
Tâche : "Développer API commandes"
Deadline : 1 semaine
Temps réel : 1 semaine exactement

Pourquoi ?
- Priorisation forcée (MVP d'abord)
- Focus (pas de distractions)
- Parkinson inversé ("deadline = motivateur")

Avec deadline trop courte :
────────────────────────────
Tâche : "Développer API commandes"
Deadline : 2 jours (impossible)
Temps réel : 2 jours (qualité sacrifiée)
Dette technique créée : 5 jours (×2.5 !)

Risque : Quick & dirty → Dette technique

Solutions Agile :

Pratique	Mécanisme anti-Parkinson	Exemple
Sprints	Time-box 2 semaines fixe	Sprint 10 jours, pas 1 jour de plus
Daily Standup	Time-box 15min max	Debout (inconfort physique)
Story Points	Estimation collective (pas temps)	3 pts = 1 jour idéal (focus)
Definition of Done	Critères clairs (pas infini)	Tests + Review + Deploy = DONE
Sprint Planning	Commitment équipe	"On livre X points, pas plus"

Loi de Metcalfe (Effet Réseau)

Énoncé :

"La valeur d'un réseau est proportionnelle au carré du nombre d'utilisateurs connectés."
— Robert Metcalfe (inventeur Ethernet)

Formule :
Valeur réseau = k × n²
où n = nombre de nœuds (utilisateurs, systèmes)

Implications SI :

Intégrations systèmes :

1 système isolé : Valeur = 1
2 systèmes connectés : Valeur = 4 (×4)
3 systèmes connectés : Valeur = 9 (×9)
5 systèmes connectés : Valeur = 25 (×25)
10 systèmes connectés : Valeur = 100 (×100)

Croissance exponentielle !

Exemple concret :
─────────────────
ERP seul : Valeur = Gestion interne
ERP + CRM : Valeur = ×4 (données clients enrichies)
ERP + CRM + E-commerce : Valeur = ×9 (parcours client complet)
ERP + CRM + E-commerce + Compta + Logistique : Valeur = ×25

Mais attention :
Complexité intégration = f(n²) aussi !
→ Nécessite gouvernance forte (APIs, standards)

Application APIs publiques :

Stripe (plateforme paiement) :

2011 : 100 intégrations
Valeur = 100²  = 10 000

2024 : 100 000+ intégrations
Valeur = 100 000² = 10 000 000 000 (×1 million !)

Effet lock-in naturel :
Plus d'intégrations → Plus de valeur → Plus difficile de partir
→ Dominance marché

Stratégie SI :

Favoriser intégrations (Metcalfe) :
───────────────────────────────────
✅ APIs publiques bien documentées
✅ Standards ouverts (REST, GraphQL)
✅ Webhooks (notifications événements)
✅ SDKs multiples langages
✅ Sandbox développeurs
✅ Programme partenaires

Éviter silos fermés :
─────────────────────
❌ Formats propriétaires
❌ Pas d'APIs (accès direct DB)
❌ Licences restrictives
❌ Pas de documentation

Exemple :
Salesforce : 3000+ intégrations AppExchange
→ Écosystème = barrière sortie
→ Valeur exponentielle

Principe de Pareto (80/20)

Énoncé :

"80% des effets proviennent de 20% des causes."
— Vilfredo Pareto (économiste, 1896)

Applications multiples SI :

1. Features

Analyse usage (Google Analytics) :

100 features développées
20 features = 80% du trafic
80 features = 20% du trafic

Implication :
───────────
Prioriser impitoyablement les 20% critiques (RICE, MoSCoW)
MVP = 20% features qui apportent 80% valeur

Exemple e-commerce :
Features critiques (20%) :
- Catalogue produits
- Recherche
- Panier
- Paiement
→ 80% CA

Features secondaires (80%) :
- Wishlist, comparateur, alertes prix, etc.
→ 20% CA

Stratégie :
MVP = Features critiques (3 mois)
Puis itérations features secondaires selon usage réel

2. Bugs

Analyse tickets support :

1000 bugs remontés sur 1 an
20% bugs (200) = 80% tickets support (8000)
80% bugs (800) = 20% tickets support (2000)

Implication :
───────────
Fixer prioritairement les 20% bugs critiques récurrents
→ Réduction massive tickets support

Exemple :
Bug "Paiement échoue avec carte X" : 2000 tickets
→ Fix : 2 jours dev
→ ROI : -83% tickets (économie 150K€/an support)

3. Code (Hotspots)

Analyse complexité (SonarQube) :

100 000 lignes code
20% code (20K lignes) = 80% complexité totale
80% code (80K lignes) = 20% complexité

Implication :
───────────
Refactoring ciblé sur 20% code complexe
→ Impact maximal qualité

Exemple :
Module "CalculPrix" : 2K lignes, complexité 450
→ Refactoring 1 semaine
→ Complexité réduite à 120 (-73%)
→ Bugs module -80%

4. Utilisateurs (Règle VIP)

Analyse CA par client :

10 000 clients
20% clients (2000) = 80% CA (8M€)
80% clients (8000) = 20% CA (2M€)

Implication :
───────────
Optimiser parcours pour 20% clients VIP
Support dédié, features premium

Exemple :
Clients B2B (2000) : commandes moyennes 4K€
→ Interface dédiée B2B (investissement 200K€)
→ Satisfaction +25% → Rétention +15% → CA +600K€/an
→ ROI : 200K€ investi → 600K€/an = 300% ROI

Synthèse : Tableau Récapitulatif Lois Universelles

Loi	Principe	Action Manager SI	Impact Refonte	KPI à suivre
Conway	Architecture = Organisation	Réorganiser équipes AVANT archi (Inverse Conway)	Feature teams > Silos	Vélocité/équipe > 40 pts
Lehman 1	Changement continu	Budget évolution 15-20%/an	SI évolutif pas figé	Budget évolution/Budget total
Lehman 2	Complexité croissante	20% temps refactoring	Dette remboursée continu	Complexité cyclomatique < 10
Lehman 3	Auto-régulation	Métriques + feedback loops courts	DevOps, CI/CD < 15min	Lead time < 24h
Lehman 4	Stabilité équipes	Équipes 6-9 personnes (Two-Pizza)	Pas +50 devs d'un coup	Productivité/dev > 5 pts
Lehman 5	Familiarité	Migration progressive (Strangler)	Big Bang = JAMAIS	Adoption > 80%
Lehman 6	Croissance fonctionnelle	Roadmap innovation (15% budget)	Nouvelles features régulières	Features/trimestre > 5
Lehman 7	Qualité décroissante	Tests auto 80%, CI quality gates	Couverture tests > 80%	Bugs prod/release < 5
Lehman 8	Feedback multi-niveaux	Dashboards 3 niveaux (Strat/Tact/Ops)	Pilotage permanent	Tous KPIs temps réel
Brooks	Plus de gens ≠ Plus vite	Limiter taille équipes, éviter sureffectif	Recrutement ciblé (seniors)	Overhead communication < 30%
Parkinson	Travail remplit temps	Time-boxing (sprints 2 sem, daily 15min)	Deadlines strictes	Respect deadlines > 90%
Metcalfe	Valeur réseau = n²	APIs publiques, intégrations, standards	Écosystème ouvert	Nb intégrations ↗️
Pareto	80/20	Priorisation RICE, MVP, focus critical path	20% features = 80% valeur	Usage features > 60%

Exercices Pratiques

Exercice 1 : Appliquer Conway

Contexte :
Refonte SI, 24 personnes disponibles

Question :
Comment organiser les équipes pour produire l'architecture suivante ?

Architecture cible :
- Monolithe modulaire
- 3 Bounded Contexts : Sales, Inventory, Logistics
- 1 Platform (infra/DevOps)

Réponse :

Squad Sales : 8 personnes (2 FE, 3 BE, 1 QA, 1 PO, 1 UX)
Squad Inventory : 6 personnes (1 FE, 3 BE, 1 QA, 1 PO)
Squad Logistics : 6 personnes (1 FE, 2 BE, 1 QA, 1 PO, 1 Ops)
Platform Team : 4 personnes (2 DevOps, 1 DBA, 1 Sécu)

Total : 24 personnes

Conway garantit : Architecture produite = Architecture voulue

Exercice 2 : Calculer Brooks

Contexte :
Projet en retard de 2 mois
Équipe actuelle : 8 devs
Proposition management : Ajouter 6 devs

Question :
Calculer si l'ajout accélère ou ralentit le projet

Réponse :

Hypothèses :
- Ramp-up nouveaux devs : 3 mois à 50% productivité
- Formation : 50% temps 1 senior × 2 mois

Calcul :
Travail restant : 8 devs × 2 mois = 16 mois-homme

Scénario ajout 6 devs :
- Nouveaux devs : 6 × 3 mois × 50% = 9 mois-homme (sur 3 mois)
- Formation : 3 seniors × 50% × 2 mois = 3 mois-homme PERDUS
- Devs existants : 8 × 2 mois = 16 mois-homme
- Overhead communication : 14 devs vs 8 = +75% meetings = -3 mois-homme

Total produit : 16 + 9 - 3 - 3 = 19 mois-homme en 3 mois
Besoin : 16 mois-homme

Conclusion : Projet livré en 2.5 mois (vs 2 mois initial)
→ Ajout devs RALENTIT (+25% délai) !

Alternative :
Réduire scope -20% → Livraison en 1.6 mois (plus rapide)

Prochaine section : Le Pilotage : La Vraie Clé du Succès

Les Lois Universelles de l'Informatique ​

Introduction ​

A) Loi de Conway (1967) ​

Énoncé original ​

Traduction simple ​

Implications concrètes ​

Exemple 1 : Organisation en silos techniques ​

Exemple 2 : Feature teams par domaine métier ​

Tableau comparatif : Impact organisation sur architecture ​

Cas réels d'application ​

Amazon (2002) : Two-Pizza Teams ​

Spotify : Squads/Tribes/Chapters/Guilds ​

L'Inverse Conway Maneuver ​

B) Lois de Lehman (1974-1996) ​

Loi 1 : Changement Continu (Continuing Change) ​

Loi 2 : Complexité Croissante (Increasing Complexity) ​

Loi 3 : Auto-Régulation (Self Regulation) ​

Loi 4 : Conservation de la Stabilité Organisationnelle (Organisational Stability) ​

Loi 5 : Conservation de la Familiarité (Conservation of Familiarity) ​

Loi 6 : Croissance Continue (Continuing Growth) ​

Loi 7 : Qualité Décroissante (Declining Quality) ​

Loi 8 : Feedback Multi-Niveaux (Feedback System) ​

C) Autres Lois Pertinentes ​

Loi de Brooks (1975) - Détails ​

Loi de Parkinson (1955) ​

Loi de Metcalfe (Effet Réseau) ​

Principe de Pareto (80/20) ​

1. Features ​

2. Bugs ​

3. Code (Hotspots) ​

4. Utilisateurs (Règle VIP) ​

Synthèse : Tableau Récapitulatif Lois Universelles ​

Exercices Pratiques ​

Exercice 1 : Appliquer Conway ​

Exercice 2 : Calculer Brooks ​

Les Lois Universelles de l'Informatique

Introduction

A) Loi de Conway (1967)

Énoncé original

Traduction simple

Implications concrètes

Exemple 1 : Organisation en silos techniques

Exemple 2 : Feature teams par domaine métier

Tableau comparatif : Impact organisation sur architecture

Cas réels d'application

Amazon (2002) : Two-Pizza Teams

Spotify : Squads/Tribes/Chapters/Guilds

L'Inverse Conway Maneuver

B) Lois de Lehman (1974-1996)

Loi 1 : Changement Continu (Continuing Change)

Loi 2 : Complexité Croissante (Increasing Complexity)

Loi 3 : Auto-Régulation (Self Regulation)

Loi 4 : Conservation de la Stabilité Organisationnelle (Organisational Stability)

Loi 5 : Conservation de la Familiarité (Conservation of Familiarity)

Loi 6 : Croissance Continue (Continuing Growth)

Loi 7 : Qualité Décroissante (Declining Quality)

Loi 8 : Feedback Multi-Niveaux (Feedback System)

C) Autres Lois Pertinentes

Loi de Brooks (1975) - Détails

Loi de Parkinson (1955)

Loi de Metcalfe (Effet Réseau)

Principe de Pareto (80/20)

1. Features

2. Bugs

3. Code (Hotspots)

4. Utilisateurs (Règle VIP)

Synthèse : Tableau Récapitulatif Lois Universelles

Exercices Pratiques

Exercice 1 : Appliquer Conway

Exercice 2 : Calculer Brooks