Customiser l'Atelier de Cartographie: Adapter aux Types d'Équipes et Dépendances

17 novembre 2025

2514 mots soit environ 13 minutes de lecture.

🎯 Customiser l’Atelier de Cartographie: Guide Pratique

Introduction

L’atelier de cartographie de contexte n’est pas “one-size-fits-all”. Selon la structure organisationnelle actuelle, les types de dépendances en place, et les patterns existants, vous devrez adapter le design de facilitation pour être pertinent et actionnable.

Ce guide vous aide à customiser l’atelier en fonction de votre situation réelle.

Partie 1: Diagnostiquer Votre Situation Actuelle

Étape 1.1: Identifier les Types d’Équipes Présentes

Avant l’atelier, cartographiez rapidement:

Pour chaque paire d'équipes, demandez-vous:

A et B dépendent-elles l'une de l'autre?
├─ NON, zéro dépendance
│  └─ Type: INDEPENDENT TEAMS
│
└─ OUI, il y a dépendance
   ├─ C'est mutuel (A dépend de B, B dépend de A)?
   │  └─ Type: MUTUALLY DEPENDENT TEAMS
   │
   └─ C'est asymétrique (A dépend de B, mais pas l'inverse)?
      └─ Type: UPSTREAM/DOWNSTREAM TEAMS

Étape 1.2: Inventorier les Patterns Actuels

Pour chaque relation identifiée, diagnostiquez le pattern en place:

Questions rapides:

Est-ce qu'une équipe impose son modèle à l'autre?
├─ OUI, imposé → CONFORMIST (intentionnel) ou Big Ball Of Mud (accidentel)
└─ NON → Continuer

L'équipe downstream crée une couche de traduction?
├─ OUI → ANTICORRUPTION LAYER
└─ NON → Continuer

Les deux équipes se coordonnent pour l'interface?
├─ OUI → PARTNERSHIP ou CUSTOMER/SUPPLIER DEVELOPMENT
└─ NON → Continuer

Zéro couplage intentionnel?
├─ OUI → SEPARATE WAYS
└─ NON → Probablement SHARED KERNEL ou Open-host

Étape 1.3: Créer une “Matrice Diagnostic” Simple

Avant l’atelier, préparez ce tableau:

Équipe A	Équipe B	Type Relation	Pattern Actuel	Intentionnel?	Problème?
Frontend	Backend	Mutually Dep	Pas clair	❓	✓ Friction
Catalog	Inventory	Upstream/Down	Conformist	✓	-
Order	Analytics	Independent	Separate Ways	✓	-

Partie 2: Adapter l’Atelier aux Types d’Équipes

Scenario A: Équipes Mutuellement Dépendantes

Diagnostic: Frontend et Backend, Order et Billing, Platform Core et Services

Le défi: Coordination lente, changements bloquants mutuels

Customisation du Flux Atelier

PHASE 1: Introduction (10 min)
  Focus: Montrer que la mutuelle dépendance existe
  Cartes à montrer: 
    - Mutually Dependent Teams (#10)
    - Partnership (#5)
    - Shared Kernel (#4)

PHASE 2: Identification (20 min)
  Question clé: "Comment communiquez-vous aujourd'hui?"
  Exercice: Lister les dépendances que chaque équipe voit

PHASE 3: Cartographie (40 min)
  Décision clé: Partnership ou Shared Kernel?
  Arrangemement cartes: 
    - Mettez Partnership et Shared Kernel en face-à-face
    - Posez questions: "Avez-vous du code partagé?"
    - Mettez l'arrangement sur le mur

PHASE 4: Validation (20 min)
  Questions critiques:
    ├─ "Vous vous faites vraiment confiance?"
    ├─ "Combien de réunions sync par semaine?"
    ├─ "Qui décide en cas de conflit?"
    └─ "Pourquoi c'est pas Separate Ways?" (challenger)

PHASE 5: Analyse (15 min)
  Focus: Gouvernance et processus
  Questions:
    ├─ "Quel est votre process de décision?"
    ├─ "Comment gérez-vous les changements?"
    └─ "Y a-t-il une escalade process?"

PHASE 6: Conclusion (15 min)
  Actions immédiates:
    ├─ Établir réunion bi-weekly sync
    ├─ Documenter l'interface
    └─ Définir qui arbitre les conflits

Matériel recommandé:

Cartes #4, #5, #10
Post-its pour “questions non résolues”
Feuille “Governance Process” à remplir

Durée totale: 120 min

Scenario B: Équipes Upstream/Downstream

Diagnostic: Platform → Services, Catalog → Pricing/Inventory, Legacy → New System

Le défi: Upstream est goulot, downstream bloqué ou mal aligné

Customisation du Flux Atelier

PHASE 1: Introduction (15 min)
  Focus: Clarifier l'asymétrie
  Cartes à montrer:
    - Upstream/Downstream Teams (#11)
    - Published Language (#7)
    - Anticorruption Layer (#2)
    - Conformist (#3)

PHASE 2: Identification (15 min)
  Question clé: "Qui est vraiment upstream, qui est downstream?"
  Exercice: Voter (souvent les gens en désaccord!)

PHASE 3: Cartographie (50 min)
  Décision clé: Quel pattern pour cette asymétrie?
  
  Sub-décisions selon contexte:
  
  A) Peu de downstream (1-2)?
     ├─ Collaborer sur l'interface?
     │  └─ CUSTOMER/SUPPLIER DEVELOPMENT (#8)
     └─ Imposer le modèle?
        ├─ OUI → CONFORMIST (#3)
        └─ NON → ANTICORRUPTION LAYER (#2)
  
  B) Beaucoup de downstream (5+)?
     └─ PUBLISHED LANGUAGE (#7)
  
  Arrangement: Mettez les cartes pattern en triangle:
    Upstream (en haut)
        ↓
    Votre Pattern (au milieu)
        ↓
    Downstream (en bas)

PHASE 4: Validation (20 min)
  Questions de pouvoir:
    ├─ "Upstream, êtes-vous overloadé?"
    ├─ "Downstream, êtes-vous frustrés?"
    ├─ "C'est volontaire ou accidentel?"
    └─ "Y a-t-il un power imbalance?"

PHASE 5: Analyse (15 min)
  Pour PUBLISHED LANGUAGE:
    ├─ "Comme on scale, ça peut devenir complexe"
    └─ "Besoin d'une versioning strategy"
  
  Pour CUSTOMER/SUPPLIER DEV:
    ├─ "Timing des changements?"
    └─ "Processus de feedback?"
  
  Pour CONFORMIST:
    ├─ "Vous pouvez vraiment vivre avec ce modèle?"
    └─ "Et si ça change?"
  
  Pour ANTICORRUPTION LAYER:
    ├─ "Complexité acceptable?"
    └─ "Qui maintient l'ACL?"

PHASE 6: Conclusion (15 min)
  Si PUBLISHED LANGUAGE:
    └─ Action: Documenter le langage
  
  Si CONFORMIST:
    └─ Action: Établir process de communication (breaking changes)
  
  Si ANTICORRUPTION LAYER:
    └─ Action: Identifier qui va maintenir l'ACL
  
  Si CUSTOMER/SUPPLIER DEV:
    └─ Action: Planifier feedback sessions régulières

Matériel recommandé:

Cartes #2, #3, #7, #8, #11
Feuille “Inventory of Downstream”
Template “Published Language Spec”

Durée totale: 130 min

Scenario C: Équipes Indépendantes

Diagnostic: Analytics vs Core, Legacy vs New, Completely Separate Services

Le défi: Risque de duplication, ou dépendances cachées

Customisation du Flux Atelier

PHASE 1: Introduction (10 min)
  Focus: Confirmer l'indépendance intentionnelle
  Cartes à montrer:
    - Independent Teams (#12)
    - Separate Ways (#6)

PHASE 2: Identification (20 min)
  Question clé: "Êtes-vous vraiment indépendants?"
  Exercice: Lister toutes les dépendances possibles
    ├─ Data sharing?
    ├─ API calls?
    ├─ Shared infrastructure?
    ├─ Shared knowledge/tools?
    └─ Coordination needs?

  Verdict: Si dépendances trouvées → Probablement pas Independent!
  Ajuster le diagnostic et suivre Scenario A ou B

PHASE 3: Cartographie (30 min)
  Si vraiment indépendants:
    ├─ Arrangez les équipes séparées sur le mur
    ├─ Aucun lien entre eux
    └─ Mettre "Independent Teams" au milieu

  Focus: Documenter comment elles peuvent rester indépendantes
    ├─ Séparation des données
    ├─ Zéro appels synchrones
    ├─ Communications par événements (async) seulement?
    └─ Isolation complète du failure?

PHASE 4: Validation (20 min)
  Questions critiques:
    ├─ "Vraiment zéro besoin de coordination?"
    ├─ "Qu'arrive-t-il si une équipe crash?"
    ├─ "Duplication code/logic: acceptable?"
    └─ "Peut-on vraiment déployer indépendamment?"

PHASE 5: Analyse (10 min)
  Coûts d'indépendance:
    ├─ Infrastructure: Chacun sa DB, services, monitoring
    ├─ Développement: Possibilité de divergence
    └─ Opération: Plus de systèmes à maintenir

  Bénéfices:
    ├─ Vitesse: Pas d'attendre l'autre
    ├─ Scaling: Indépendant des limitaitons de l'autre
    └─ Résilience: Failure isolation

PHASE 6: Conclusion (10 min)
  Actions:
    ├─ Valider séparation des données
    ├─ Établir communication mode (events/batch/none)
    └─ Monitoring indépendant de chaque service

Matériel recommandé:

Cartes #6, #12
Feuille “Dependency Audit”
Diagram template: “Communication Interfaces”

Durée totale: 100 min

Partie 3: Adapter l’Atelier aux Patterns Existants

Cas 1: Vous Avez un CONFORMIST

Situation: Une équipe accepte simplement le modèle upstream

Question durant atelier:

“C’est volontaire ou c’est juste par défaut/impuissance?”

Adaptations facilitatoi:

Si volontaire et sain:
  ✓ Montrer pourquoi c'est un bon choix
  ✓ Documenter le pattern explicitement
  ✓ Établir process pour les breaking changes upstream
  ✓ Escalade si upstream casse le contrat

Si accidentel ou frustrant:
  ✗ Challenger: "Pourriez-vous faire une ACL?"
  ✗ Évaluer: Coût de traduction vs bénéfice d'indépendance
  ✗ Décision: Rester Conformist avec gouvernance OU passer à ACL

Cas 2: Vous Avez une ANTICORRUPTION LAYER

Situation: Une équipe traduit le modèle upstream

Question durant atelier:

“La traduction est-elle maintenable? Trop complexe?”

Adaptations facilitation:

Si ACL simple et stable:
  ✓ Continuer, c'est bon
  ✓ Documenter les mappings
  ✓ Tester les conversions
  ✓ Planner la maintenance

Si ACL devient complexe:
  ✗ Red flag: L'upstream est peut-être mal conçu
  ✗ Alernatives:
     ├─ Négocier avec Upstream pour meilleur modèle
     ├─ Passer à Published Language (si many consumers)
     ├─ Ou accepter la complexité comme justifiable tradeoff

Cas 3: Vous Avez du SHARED KERNEL

Situation: Deux équipes partagent du code

Questions durant atelier:

“Qui est responsable? Ça diverge-t-il? Trop gros?”

Adaptations facilitation:

Si Shared Kernel sain:
  ✓ Garder, c'est du partage intentionnel
  ✓ Documenter: Responsables du kernel
  ✓ Processus: Comment valider les changements
  ✓ Taille: Réduire au vraiment partagé

Si Shared Kernel mal défini:
  ✗ Red flag: Équipes en conflit sur le kernel
  ✗ Alternatives:
     ├─ Réduire le kernel (enlever le débattu)
     ├─ Passer à Partnership (moins de code partagé)
     ├─ Ou Separate Ways (dupliquer plutôt)

Cas 4: Vous Avez une PARTNERSHIP

Situation: Deux équipes collaborent étroitement

Questions durant atelier:

“La collaboration est-elle productive? Ou ralentit-elle?”

Adaptations facilitation:

Si Partnership productif:
  ✓ Formaliser: Réunions régulières (bi-weekly)
  ✓ Documenter: Interface and decision process
  ✓ Metrics: Time to decision, incident frequency
  ✓ Continuer

Si Partnership frustrant:
  ✗ Red flag: Trop de réunions, pas de décisions
  ✗ Alternatives:
     ├─ Ajouter Shared Kernel (partager du code pour sync)
     ├─ Ou découpler avec ACL/Separate Ways
     ├─ Ou clarifier qui a le vrai pouvoir (→ Upstream/Downstream)

Cas 5: Vous Avez une BIG BALL OF MUD

Situation: Frontières floues, responsabilités mélangées

Questions durant atelier:

“C’est récent ou ancien? Pouvez-vous en extraire des contextes?”

Adaptations facilitation:

PHASE 1: Reconnaissance
  ✗ Nommer le problème: "C'est un Big Ball Of Mud"
  ✗ Valider ensemble: "Oui, c'est chaotique"

PHASE 2: Cause Root
  Pourquoi c'est devenu BBOM?
  ├─ Absence de frontières claires (design)
  ├─ Trop de couplage (technique)
  ├─ Équipes qui se croisent (org)
  ├─ Legacy et nouveau mélangés
  └─ Accumulation d'années

PHASE 3: Strategy d'Évasion
  ├─ Strangler Pattern: Extraire progressivement
  ├─ ACL Bubble Context: Isoler les nouveaux services
  ├─ Rewrite Complet: Risqué, souvent échoue
  └─ Liaisser mourir: Abandon pur

PHASE 4: Priorités
  ├─ Identifier le contexte à extraire en PREMIER
  ├─ Isoler les données: Qui en est responsable?
  ├─ Tester avant séparation
  ├─ Planifier sur 12-24 mois, pas une semaine

PHASE 5: Next Steps
  ├─ Nommer responsable de la restructuration
  ├─ Plaquer une architecture transitoire
  ├─ Commencer Extraction #1 au sprint prochaine

Matériel recommandé:

Carte #9 (Big Ball Of Mud)
Carte #6 (Separate Ways)
Carte #2 (Anticorruption Layer)
Feuille “Strangler Pattern Timeline”

Partie 4: Customisation Avancée - Les Dépendances “Problématiques”

Cas 1: Trop de Dependances (Spaghetti)

Symptôme: Tout appelle tout

Diagnostic: Probablement mélange de patterns et manque de clarité

Adaptation atelier:

PHASE 1: Dessin du Chaos
  Exercice: Chaque équipe dessine ce qu'elle pense être les dépendances
  Résultat: 5 dessins différents du même système = CHAOS!

PHASE 2: Vérité Partagée
  Créer UNE cartographie agréée avec tous
  ├─ Surprises souvent découvertes
  ├─ "On pensait pas que ça dépendait de ça"
  └─ "Mais on DOIT dépendre pour X"

PHASE 3: Réduction
  Pour chaque dépendance:
  ├─ Est-elle intentionnelle?
  ├─ Peut-elle être supprimée?
  ├─ Peut-elle être mieux gérée (pattern clair)?

PHASE 4: Plan de Désentation
  ├─ Garder seulement les dépendances critiques
  ├─ Pour chaque: Appliquer le pattern le plus approprié
  ├─ Ordre de priorité pour le travail

Cas 2: Dépendances Cachées

Symptôme: “On pensait être indépendants, mais…”

Adaptation atelier:

Exercice "Dependency Audit":

Pour chaque équipe, lister:
├─ API calls qu'on fait vers d'autres services
├─ Données qu'on lit chez quelqu'un d'autre
├─ Code qu'on partage
├─ Infrastructure qu'on utilise ensemble
├─ Coordination qu'on doit faire

Révélations: "Oh, on n'avait pas envisagé ça"

Verdict: Probablement pas vraiment Independent!

Cas 3: Dépendances Critiques vs Résiduelles

Objectif: Distinguer ce qui est vraiment important

Adaptation atelier:

Matrix 2x2:

             Fréquence Élevée | Fréquence Basse
Impact Élevé |   CRITIQUE      | À OPTIMISER
Impact Bas   |   À RÉDUIRE     | IGNORER


Dépendances CRITIQUE:
  └─ Requiert le pattern le plus attentif
  └─ Dépendances synchrones OK
  └─ Besoin de coordination forte

Dépendances À RÉDUIRE:
  └─ Réduire la fréquence (caching, batch)
  └─ Ou changer le pattern (Separate Ways)

Dépendances À OPTIMISER:
  └─ Rendre asynchrone (events)
  └─ Ou améliorer le pattern

Dépendances À IGNORER:
  └─ Vraiment besoin de les cuter?

Partie 5: Livrable Post-Atelier

Créer une “Carte Décision”

Après l’atelier, produisez ce document:

┌─────────────────────────────────────────────────────┐
│ CARTOGRAPHIE DE CONTEXTE: [NOM DU PROJET]          │
├─────────────────────────────────────────────────────┤

1. CONTEXTES IDENTIFIÉS
├─ Frontend Service
├─ Backend Service
├─ Catalog Service
├─ Inventory Service
└─ Analytics Service

2. RELATIONS D'ÉQUIPES
├─ Frontend ↔ Backend: MUTUALLY DEPENDENT
├─ Catalog → Inventory: UPSTREAM/DOWNSTREAM
├─ Analytics → *: INDEPENDENT

3. PATTERNS APPLIQUÉS
├─ Frontend ↔ Backend: PARTNERSHIP (API négociée)
├─ Catalog → Inventory: PUBLISHED LANGUAGE (Spec v1.2)
├─ Analytics → Core: SEPARATE WAYS (Batch export nightly)

4. PROBLÈMES DÉTECTÉS
├─ ❌ Frontend/Backend: Trop de réunions de sync (4/semaine)
│    → Action: Réduire à 1 sync par semaine
│
├─ ❌ Catalog/Inventory: Breaking changes sans notification
│    → Action: 2 semaines de deprecation avant breaking change

4. PROCHAINES ÉTAPES
├─ Sprint N+1: Formaliser partnership frontend/backend
├─ Sprint N+2: Versionner Published Language de Catalog
├─ Sprint N+3: Audit des dépendances analytiques

5. RESPONSABILITÉS
├─ Frontend Lead: Établir sync schedule
├─ Catalog Lead: Publier langage documenté
├─ Analytics Lead: Vérifier isolation
└─ Arch Lead: Monitor l'évolution

6. MÉTRIQUES DE SUIVI
├─ Incidents causés par mauvaise intégration: [nombre]
├─ Temps d'une équipe bloquée: [jours/sprint]
├─ Clarté du pattern (1-5): [score]
└─ Satisfaction équipes (NPS): [score]

Partie 6: Timing & Durée Recommandée

Durée Totale par Scenario

Scenario A (Mutually Dependent):    120-150 min
Scenario B (Upstream/Downstream):   130-180 min
Scenario C (Independent):           100-120 min

Extra si problèmes détectés:
  + BBOM détecté:                   +30-60 min
  + Spaghetti/Trop de dépendances:  +30 min
  + Dépendances cachées:             +20 min

Agenda Recommandé

Atelier 1 jour (4-5h):
  ├─ Matin (2h30): Intro + Identification + 60% Cartographie
  ├─ Pause (30 min)
  └─ Après-midi (2-2.5h): 40% Cartographie + Validation + Conclusion

Atelier 2 jours (complet):
  ├─ Jour 1 (4h): Focus sur Identification + Cartographie
  ├─ Jour 2 (4h): Approfondissement patterns + Design futur + Actions

Checklist de Customisation

Avant l’atelier, vérifiez:

Diagnostic
├─ [ ] Carte les types d'équipes (Indépendant/Mutuel/Upstream-Down)
├─ [ ] Identifiez les patterns actuels (Conformist/ACL/Partnership/etc)
├─ [ ] Évaluez la santé (intentionnel vs accidentel)
└─ [ ] Listez les problèmes connus

Préparation
├─ [ ] Choisissez le scenario applicable
├─ [ ] Customisez le timeline (élongez/réduisez phases)
├─ [ ] Sélectionnez cartes pertinentes (pas besoin de 13!)
├─ [ ] Préparez matériel spécifique
└─ [ ] Testez les questions provocatrices

Animation
├─ [ ] Clarifiez l'objectif (diagnostic vs design vs validation)
├─ [ ] Assurez présence des bons stakeholders
├─ [ ] Capturez les décisions en temps réel
├─ [ ] Challengez les hypothèses
└─ [ ] Documentez les next steps

Post-Atelier
├─ [ ] Produisez la "Carte Décision"
├─ [ ] Partagez avec participants
├─ [ ] Définissez responsables par action
├─ [ ] Planifiez suivi (dans 4 semaines)
└─ [ ] Mesurez l'adoption des patterns

Exemples de Customisations Réelles

Exemple 1: E-commerce (Scenario B + BBOM)

Structure actuelle:
  ├─ 7 équipes
  ├─ Monolith legacy + 3 microservices
  └─ Chaos: Qui parle à qui? Personne ne sait

Customisation:
  ├─ Scenario B (Upstream/Downstream)
  ├─ + 30 min sur Big Ball Of Mud
  └─ + 20 min sur stratégie Strangler

Durée: 180 min (3h)

Cartes utilisées: #2, #6, #7, #9, #11

Résultat:
  ✓ Extraction du Catalog en service #1
  ✓ Published Language défini pour les 6 autres
  ✓ Plan Strangler validé: 2 ans, 3 phases
  ✓ Responsable nommé

Exemple 2: Startup Petite Équipe (Scenario C)

Structure:
  ├─ 2 équipes (Frontend, Backend)
  ├─ Tightly coupled
  ├─ Pensent être indépendants (faux!)

Customisation:
  ├─ Scenario C (Independent)
  ├─ Discover hidden dependencies
  └─ Revéler vraiment Mutually Dependent
  
Puis switch to Scenario A (Partnership)
  ├─ Comment meieux collaborer?
  ├─ Shared APIs ou Shared Kernel?
  ├─ Governance process?

Durée: 120 min (2h)

Résultat:
  ✓ Reconnaître l'interdépendance
  ✓ Partnership formalisé (1 sync/week)
  ✓ Interface API documentée

Ressources Complémentaires

Atelier Baseline - Design standard (6 phases)
Les 13 Cartes - Toutes les cartes disponibles
Matrice de Sélection - Choisir le pattern
Team Relationships - Comprendre les types
DDD Starter Process - Contexte plus large

Créé pour: Facilitateurs animant des ateliers Context Mapping adapté aux réalités du terrain
Version: 1.0
Licence: CC-BY-SA