Cartographie de Contexte : Visualiser l'Architecture Socio-Technique

Pourquoi la Cartographie de Contexte ?

La cartographie de contexte est une technique fondamentale du Domain-Driven Design (DDD) qui permet de visualiser les relations entre les contextes délimités (bounded contexts) et les équipes qui les gèrent. Elle répondrait à une problématique majeure en architecture logicielle : comment comprendre et gérer les dépendances dans un système complexe composé de multiples services ou modules ?

Le problème architectural traditionnel

En architecture logicielle, on observe souvent :

  • Des couplages implicites : Les équipes ne savent pas exactement comment leurs systèmes interagissent
  • Des dépendances cachées : Les impacts des changements ne sont découverts que trop tard
  • Un mauvais alignement socio-technique : L’architecture logicielle ne reflète pas la réalité organisationnelle
  • Des frictions dans la collaboration : Les équipes travaillent sans langage commun

“Loi de Conway” : L’architecture d’un système reflète la structure organisationnelle qui l’a produite.

La réalité de la complexité distribuée

En réalité, les systèmes complexes modernes sont composés de :

  • Plusieurs contextes métier distincts avec leurs propres modèles de domaine
  • Plusieurs équipes avec des cultures, compétences et rythmes différents
  • Plusieurs patterns de collaboration possibles selon le contexte
  • Des relations socio-techniques qui évoluent constamment

La Cartographie de Contexte dans le DDD Starter Modelling Process

La cartographie de contexte n’est pas un exercice isolé. Elle s’inscrit dans une démarche structurée et progressive du DDD Starter Modelling Process - un processus de 8 étapes pour apprendre et appliquer le Domain-Driven Design de manière systématique.

Les 8 Étapes du DDD Starter Modelling Process

Le processus complet comprend :

  1. Understand (1h) - Aligner avec le modèle métier et les objectifs business
  2. Discover (2-8h) - Découvrir le domaine visuellement et collaborativement (ex: EventStorming)
  3. Decompose (1-2h) - Décomposer en sous-domaines loosely-coupled
  4. Strategize (1h) - Identifier les core domains stratégiques
  5. Connect (2-3h) - Connecter les sous-domaines en architecture cohérente (ex: Domain Message Flow)
  6. Organise (2-3h) - ← LA CARTOGRAPHIE DE CONTEXTE EST ICI
  7. Define (4-6h) - Définir les rôles et responsabilités de chaque bounded context
  8. Code (∞) - Implémenter le modèle de domaine

Position de la Cartographie de Contexte : L’Étape “Organise”

La cartographie de contexte est une technique clé de l’étape 6 “Organise” du processus. À ce stade :

  • ✅ Vous avez découvert et compris le domaine (étapes 1-5)
  • ✅ Vous avez identifié les sous-domaines et leurs stratégies
  • ✅ Vous avez modélisé les flux de messages entre domaines
  • ❓ Maintenant : Comment organiser les équipes et clarifier les relations entre contextes ?

L’objectif de l’étape “Organise”

L’étape “Organise” vise à :

  • Organiser des équipes autonomes optimisées pour le flow rapide
  • Aligner les équipes avec les limites des contextes (socio-technical architecture)
  • Clarifier les patterns et relations d’intégration entre équipes

C’est précisément le rôle de la cartographie de contexte : visualiser ces relations et sélectionner les patterns appropriés pour chaque collaboration.

Flux typique du DDD Starter Modelling Process

1. Understand (Business Model Canvas, User Story Mapping)
2. Discover (EventStorming) 
3. Decompose (Sous-domaines, identifiant les limites)
4. Strategize (Core Domain Chart, Wardley Mapping)
5. Connect (Domain Message Flow, flux end-to-end)
              ↓
6. Organise ← VOUS ÊTES ICI
    ├─ Context Mapping (cette technique !)
    ├─ Identifier les équipes
    ├─ Valider les patterns d'intégration
    └─ Aligner structure organisationnelle + technique
              ↓
7. Define (Bounded Context Canvas)
8. Code (Aggregate Design Canvas, implémentation)

La Cartographie de Contexte : Visualiser la Socio-Technologie

La cartographie de contexte (context mapping) est une technique proposée par Eric Evans dans son ouvrage “Domain-Driven Design” pour rendre ces relations explicites et navigables.

Qu’est-ce qu’une Carte de Contexte ?

Une carte de contexte est une représentation visuelle des bounded contexts et de leurs relations qui capture :

  1. Les contextes délimités : Des frontières explicites autour de domaines ou services
  2. Les relations d’équipes : Comment les équipes travaillent ensemble
  3. Les patterns d’intégration : Les stratégies techniques et organisationnelles de collaboration

Exemple simplifié :

Un système e-commerce composé d’un contexte Catalogue géré par une équipe, un contexte Commandes géré par une autre, et un contexte Facturation distinct.

Les Relations d’Équipes (3 types)

  1. Mutuellement Dépendants : Les deux contextes/équipes doivent livrer ensemble pour réussir
  2. Upstream / Downstream : Un contexte influence l’autre de manière asymétrique
  3. Libres : Aucune relation entre les deux contextes

Les 9 Patterns de Context Mapping

La cartographie de contexte propose 9 patterns pour décrire différentes stratégies de collaboration :

  1. Open-host Service : Un service expose une interface commune à plusieurs clients
  2. Conformist : L’équipe downstream adopte le modèle upstream pour simplifier l’intégration
  3. Anticorruption Layer : L’équipe downstream crée une couche d’isolation pour protéger son modèle
  4. Shared Kernel : Deux équipes partagent explicitement une partie du domaine
  5. Partnership : Deux équipes collaborent étroitement sur l’évolution de leurs interfaces
  6. Customer/Supplier Development : L’équipe downstream a un rôle de “client” dans la planification
  7. Published Language : Une langue commune documentée permet la traduction entre contextes
  8. Separate Ways : Les deux contextes n’ont aucune relation intentionnelle
  9. Big Ball Of Mud : Un anti-pattern : un contexte mal défini où les modèles sont mélangés

Le changement de perspective

Le vrai pouvoir de la cartographie de contexte réside dans le changement de perspective :

Avant (approche naïve) :

  • “Voici notre architecture (un grand diagramme sans relations claires)”
  • “Les équipes travaillent sur leurs trucs respectifs”
  • “Les problèmes d’intégration surgissent en production”

Après (approche cartographiée) :

  • “Voici les relations entre nos contextes et comment ils évoluent ensemble”
  • “Les équipes comprennent mutuellement leur interdépendance”
  • “Les risques d’intégration sont anticipés et gérés”
  • “L’architecture reflète et guide la structure organisationnelle”

Comment mettre cela en Pratique ?

C’est là qu’intervient l’Atelier de Cartographie de Contexte - un atelier de facilitation conçu pour co-créer la carte de contexte de votre architecture socio-technique avec tous les stakeholders.

Pourquoi un atelier ?

La cartographie de contexte n’est pas un exercice académique solitaire. C’est un processus de découverte collaborative qui nécessite :

  • Les représentants des différentes équipes
  • Les architectes et tech leads
  • Les responsables produit
  • Les décideurs organisationnels

L’Atelier de Cartographie de Contexte

Cet atelier de 2 à 3 heures (8-20 participants) est structuré pour :

  1. Introduire le concept des bounded contexts et des patterns
  2. Identifier collectivement les contextes délimités actuels
  3. Mapper les relations entre équipes et contextes
  4. Sélectionner les patterns appropriés pour chaque relation
  5. Valider et challenger la carte par tous les participants
  6. Planifier l’évolution de l’architecture socio-technique

Les 9 Patterns en Référence

La cartographie de contexte utilise 9 patterns principaux (représentés sous la forme de cartes à positionner sur le fond de carte) :

  1. Open-host Service - Exposer une interface commune
  2. Conformist - Adopter le modèle upstream
  3. Anticorruption Layer - Isoler son propre modèle
  4. Shared Kernel - Partager explicitement une partie du domaine
  5. Partnership - Collaborer sur l’évolution des interfaces
  6. Customer/Supplier Development - Relation client/fournisseur planifiée
  7. Published Language - Langage commun documenté
  8. Separate Ways - Pas de relation intentionnelle
  9. Big Ball Of Mud - Anti-pattern à éviter

Les Bénéfices de la Cartographie

Pour les équipes

  • ✅ Clarté sur les dépendances et les risques d’intégration
  • ✅ Langage commun pour discuter de l’architecture
  • ✅ Identification des inefficacités organisationnelles
  • ✅ Planification coordonnée des évolutions

Pour l’organisation

  • ✅ Alignement entre structure organisationnelle et architecture technique
  • ✅ Meilleure prévisibilité des déploiements multi-équipes
  • ✅ Identification des goulots d’étranglement
  • ✅ Facilitation des reteaming et restructurations

Pour le produit

  • ✅ Architectures plus résilientes et évolutives
  • ✅ Réduction des défauts liés aux intégrations
  • ✅ Meilleure compréhension des impacts de changements

Les 13 Cartes de Context Mapping : Jeu Physique pour Ateliers

Pour faciliter la mise en pratique de la cartographie de contexte, nous avons créé un jeu complet de 13 cartes physiques et numériques, utilisables en atelier présentiel ou hybride.

Les Cartes Disponibles

Patterns d’Intégration (9 cartes)

1. 📇 Open-host Service - Exposer une interface commune
2. 📇 Anticorruption Layer - Isoler son domaine
3. 📇 Conformist - Adopter le modèle upstream
4. 📇 Shared Kernel - Partager du code et un modèle
5. 📇 Partnership - Collaborer étroitement
6. 📇 Separate Ways - Pas de relation intentionnelle
7. 📇 Published Language - Langage commun documenté
8. 📇 Customer/Supplier Development - Co-designer l'interface
9. 📇 Big Ball Of Mud - Anti-pattern et stratégies d'évasion

Relations d’Équipes (3 cartes)

10. 👥 Mutually Dependent Teams - Équipes au même niveau
11. 👥 Upstream/Downstream Teams - Asymétrie intentionnelle
12. 👥 Independent Teams - Complète autonomie

Guide de Sélection (1 carte)

13. 🎯 Matrice de Sélection - Arbre de décision et guide de choix

Utiliser les Cartes en Atelier

Chaque carte contient :

  • Vue rapide du pattern / relation
  • Quand l’utiliser et quand l’éviter
  • Implications pour l’organisation
  • Exemple concret
  • Questions de facilitation
  • Accès à des ressources détaillées (QR code)

Composition du jeu :

  • 13 cartes imprimées (A6 ou A5)
  • Guide du facilitateur
  • Post-its et marqueurs
  • Codes couleur pour navigation rapide

Accéder aux Cartes

Format Numérique :

Format Physique :


Aller plus loin : S’inscrire dans une Démarche Globale

La cartographie de contexte n’est qu’une pièce du puzzle du DDD Starter Modelling Process. Pour vraiment tirer parti de cette technique, il faut l’inscrire dans une démarche complète et itérative :

Ce qui DOIT venir avant

  • EventStorming (étape Discover) : Vous devez avoir une compréhension partagée du domaine
  • Décomposition en sous-domaines (étape Decompose) : Vous devez identifier les délimitations naturelles
  • Analyse stratégique (étape Strategize) : Vous devez connaître vos core domains
  • Domain Message Flow (étape Connect) : Vous devez modéliser les interactions end-to-end

Ce qui peut suivre

  • ➡️ Bounded Context Canvas (étape Define) : Pour détailler chaque contexte individuellement
  • ➡️ Aggregate Design Canvas (étape Code) : Pour concevoir les entités d’agrégat dans le code
  • ➡️ Team Topologies : Pour affiner l’organisation des équipes autour des contextes

Ressources Complémentaires

Lectures Incontournables

Les fondamentaux du DDD :

L’approche socio-technique :

  • Team Topologies par Matthew Skelton & Manuel Pais
  • Dynamic Reteaming par Heidi Helfand
  • Sociotechnical Architecture - conférence par Eduardo da Silva

Prochaine Étape : Participez à l’Atelier de Cartographie

Si vous avez complété les étapes 1 à 5 du DDD Starter Modelling Process et que vous cherchez à organiser vos équipes et clarifier vos relations d’intégration, rejoignez-nous pour un atelier de cartographie de contexte.

L’atelier vous permettra de :

  • ✅ Cartographier explicitement vos bounded contexts et leurs relations
  • ✅ Identifier et sélectionner les patterns de collaboration appropriés
  • ✅ Détecter les anti-patterns (Big Ball Of Mud, couplages cachés)
  • ✅ Planifier l’évolution vers une architecture plus alignée et autonome
  • ✅ Clarifier la structure organisationnelle qui doit suivre

Avant de commencer l’atelier, assurez-vous d’avoir :

  • Une bonne compréhension du domaine (EventStorming fait)
  • Les sous-domaines identifiés et validés
  • Les participants représentant les différentes équipes/contextes

Explorez le design de facilitation et les 9 patterns en détail dans notre guide complet de l’atelier.

Customiser l’Atelier à Votre Contexte

L’atelier standard peut être adapté selon votre situation réelle :

Consultez le guide complet de customisation pour adapter l’atelier à votre structure d’équipes et vos patterns actuels.

Carte Context Mapping #6 : Separate Ways

📇 Carte #6 : Separate Ways

Vue Rapide

🎯 Objectif : Deux contextes se séparent complètement et se dupliquent

👥 Relation d’équipe : Indépendant

📊 Couplage : Nul (zero integration)


Concept

Les deux contextes abandonnent l’intégration et chacun gère sa propre version.

Team A        Team B
(duplique)    (duplique)
     ↓ ↓ ↓ ↓ ↓ ↓
  Chemin séparé

La philosophie : “On se sépare, c’est plus simple”


Quand l’Utiliser ? ✅

  • ✅ Le coût de l’intégration dépasse les bénéfices
  • ✅ Les contextes évoluent différemment et indépendamment
  • ✅ La duplication est acceptable (pas critique)
  • ✅ Les équipes veulent une autonomie totale
  • ✅ Les données peuvent être synchronisées via batch (pas temps-réel)

Exemples

  • Legacy System vs. Nouveau Système : on les laisse cohabiter sans parler
  • Rapport de gestion vs. Système de facturation : même données, deux lectures
  • Analytics vs. Production : duplication OK, latence acceptable
  • Deux variantes régionales : chacun son instance

Quand l’Éviter ? ❌

  • ❌ L’intégration est vraiment nécessaire
  • ❌ Les données doivent être synchronisées en temps-réel
  • ❌ La duplication coûte trop cher (complexité, maintenance)
  • ❌ Vous devez garder les données cohérentes
  • ❌ C’est une fuite d’architecture (vraiment du même domaine)

Questions Clés à se Poser 💭

  1. Pouvez-vous vraiment vous permettre de dupliquer ?
  2. Quel est le coût de maintenir 2 versions ?
  3. Comment gérez-vous la divergence entre les deux ?
  4. Qu’arrive-t-il quand un changement métier affecte les deux ?
  5. Comment synchronisez-vous les données critiques ?

Implications pour les Équipes

Chaque Équipe Indépendante

Avantages

  • Autonomie totale : chacun progresse à son rythme
  • Zéro couplage : changements sans impact mutuel
  • Simplicité : pas d’interface complexe
  • Pas de réunions de coordination !

Risques

  • ⚠️ Duplication : maintenance coûteuse
  • ⚠️ Divergence : à long terme, les deux dérivent
  • ⚠️ Incohérence : les données ne correspondent plus
  • ⚠️ Coût caché : bug fixes doivent se répéter

Stratégies de Séparation

1. Complète (Clean Break)

Before: Service A ↔ Service B (intégration)
After:  Service A    Service B (indépendant)

→ Chacun a sa DB, son code, ses workflows
→ Zéro partage

2. Partielle (avec Batch Sync)

Service A (Commandes)
    ↓ (batch export chaque nuit)
Data Lake
    ↓ (batch import chaque nuit)
Service B (Analytics)

→ Services indépendants mais données synchronisées
→ Acceptable delay: 24h

3. Avec Archive

Legacy System (ancien)
    ↓ (migration progressive)
New System (nouveau)

→ Legacy continue de tourner
→ New prend du trafic progressivement
→ Un jour legacy s'éteint

Exemple Concret : Migration Vers Nouveau Système

Avant (Separate Ways Forcés - mauvais)

Legacy Order System (10 ans)
    ↓ (désuet, lent)
Couplé fortement à: 
    - Inventory System
    - Billing System
    - Reporting System

→ Impossible à modifier sans casser tout
→ Vraiment besoin de découpler!

Stratégie de Séparation

Phase 1: Créer New Order System (indépendant)
├── Copier la data du legacy
└── Tester en parallèle

Phase 2: Dual-write (transition)
├── Writes vont aux deux systèmes
├── New System est primary source of truth progressivement
└── Reports lisent à partir du New

Phase 3: Legacy read-only (legacy devient archive)
├── Legacy continue de tourner en read-only
├── Données historiques toujours accessibles
└── Queries récentes pointent vers New

Phase 4: Sunset legacy (éteindre l'ancien)
├── Archive les données du legacy
├── Décommissionner le système
└── Sauvegardes long-term seulement

Co-existence Pendant Transition

Frontend
    ↓
API Gateway (routing intelligent)
    ├→ New System (80% du trafic)
    └→ Legacy System (20% du trafic, migration progressive)

Batch Job (chaque nuit)
    ├→ Exporte du New
    ├→ Importe dans Analytics
    └→ Archive du Legacy

Données Critiques: Synchronisation Required

Scenario: Commandes et Facturation

Vous avez décidé de découpler Order ↔ Billing

Carte Context Mapping #7 : Published Language

📇 Carte #7 : Published Language

Vue Rapide

🎯 Objectif : Upstream publie un langage standard pour tous les downstream

👥 Relation d’équipe : Upstream/Downstream (nombreux downstream)

📊 Couplage : Bas (via langage public)


Concept

L’équipe upstream publie un langage commun (formats, événements, API) que tous les downstream adopent.

Upstream Service
    ↓
Published Language (JSON Schema, Events, OpenAPI)
    ↓ ↓ ↓ ↓ ↓
Downstream 1, 2, 3, 4, 5... (nombreux)

La philosophie : “Voici notre langage public. Si vous le respectez, ça fonctionne.”

Carte Context Mapping #8 : Customer/Supplier Development

📇 Carte #8 : Customer/Supplier Development

Vue Rapide

🎯 Objectif : Upstream co-concevoir des interfaces avec downstream

👥 Relation d’équipe : Upstream/Downstream (avec engagement)

📊 Couplage : Moyen (interface négociée)


Concept

L’équipe upstream et l’équipe downstream collaborent pour concevoir une interface optimale pour les deux.

Upstream Team          Downstream Team
(Supplier)    ↔       (Customer)
       ↓ Négociation ↓
   Interface optimale

La philosophie : “Je fournisseur, tu es client. Parlons de ce que tu as besoin.”

Carte Context Mapping #9 : Big Ball Of Mud (BBOM)

📇 Carte #9 : Big Ball Of Mud (BBOM)

Vue Rapide

🎯 Objectif : Reconnaître et documenter une zone chaotique sans structure claire

👥 Relation d’équipe : Sans structure (amorphe)

📊 Couplage : Extrêmement haut (tout touche à tout)


Concept

Une partie du système où les limites sont floues, les responsabilités mélangées, et les dépendances partout.

🌀 BBOM 🌀
├─ Code legacy sans structure
├─ Domaines entrelacés
├─ "Je sais pas comment ça marche"
├─ "Peur de toucher"
└─ Tout change partout

La philosophie : “C’est pas un pattern, c’est un symptôme d’absence de pattern”

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

🎯 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:

Dependency Breakers: Identifier et Briser les Dépendances Problématiques

🔗 Dependency Breakers: Identifier et Briser les Dépendances Problématiques

Introduction

Toute architecture complexe accumule des dépendances. Mais pas toutes les dépendances sont bonnes. Certaines deviennent problématiques : elles ralentissent, bloquent, créent du risque, ou violent l’autonomie des équipes.

Ce guide vous aide à :

  1. Identifier les dépendances problématiques
  2. Comprendre pourquoi elles posent problème
  3. Appliquer des patterns pour les “briser” (dependency breakers)

Partie 1: Diagnostiquer les Dépendances Problématiques

Qu’est-ce qu’une Dépendance Problématique?

Une dépendance est problématique si elle a une ou plusieurs de ces caractéristiques:

Guide de Matérialisation: Cartes Context Mapping Physiques

📚 Guide de Matérialisation: Cartes Context Mapping Physiques

Vue d’Ensemble

Ce guide explique comment créer un jeu de cartes physiques pour animer des ateliers Context Mapping. Le système inclut :

  • 9 cartes Pattern (Open-host Service, Anticorruption Layer, etc.)
  • 3 cartes Team Relationship (Mutually Dependent, Upstream/Downstream, Independent)
  • 1 carte Matrice de Sélection
  • Accessoires (post-its, marqueurs, diagrammes)

📐 Spécifications de Carte

Dimension Recommandée

Format standard: A6 (10.5 cm × 14.8 cm)
- Facile à manier
- Visible pour groupe de 8-20 personnes
- Empilable et stockable

Alternative pour atelier grand format: A5 (14.8 cm × 21 cm)

Papier

Poids: 250 gsm (grammage suffisant)
Type: Carton blanc ou ivoire
Finition: Mat (anti-reflet)
Raison: Durabilité, impression claire, facilité d'écriture

Alternative premium: Carton 300 gsm (plus rigide, plus cher)

Couleur & Coding

Pattern Cards (Cartes #1-9)

Cadre couleur: Bleu/Violet
Justification: Integration patterns (niveau technique)

Dégradé suggéré:
├─ Conformist & ACL (bleu foncé) - isolation
├─ Open-host & Published Language (bleu clair) - public
├─ Partnership & Shared Kernel (violet) - collaboration
├─ Separate Ways (gris) - indépendance
└─ BBOM (rouge) - danger/urgence

Team Relationship Cards (Cartes #10-12)

Cadre couleur: Orange/Vert
Justification: Team dynamics (niveau org)

Schéma:
├─ Mutually Dependent (vert) - collaboration
├─ Upstream/Downstream (orange) - asymétrie
└─ Independent (blanc/vert pâle) - autonomie

Selection Matrix Card (#13)

Cadre couleur: Jaune/Or
Justification: Guide de décision (utility)

Structure de Carte Physique

Recto (Vue Rapide)

┌─────────────────────────────────────┐
│ 📇 #[N]: [NOM PATTERN]              │
│ 🎯 Objectif                         │
│ 👥 Relation d'équipe                │
│ 📊 Couplage: [NIVEAU]               │
├─────────────────────────────────────┤
│ Vue Rapide (3 lignes max)           │
│                                     │
│ ✅ Quand l'utiliser                 │
│ ❌ Quand l'éviter                   │
│                                     │
│ 💭 Questions Clés (2-3)             │
│                                     │
│ [Icône/Diagramme Simple]            │
└─────────────────────────────────────┘

Verso (Référence Rapide)

┌─────────────────────────────────────┐
│ 📇 #[N]: [NOM PATTERN] - VERSO      │
├─────────────────────────────────────┤
│                                     │
│ Exemple Concis (2 phrases)          │
│                                     │
│ Avantages | Risques                 │
│ • +      | • -                      │
│ • +      | • -                      │
│                                     │
│ Lien vers page web:                 │
│ agileboarding.fr/context-mapping    │
│ /[pattern-name]                     │
│                                     │
│ [QR Code vers page détaillée]       │
└─────────────────────────────────────┘

🎨 Design Recommandations

Typographie

Titre (Recto): 16pt, Bold, Sans-serif
Sous-titres: 11pt, Semi-bold
Corps: 9pt, Regular
Notes: 8pt, Italic

Icônes

Utiliser des icônes simples pour scanner rapidement:
├─ 📇 Carte
├─ 🎯 Objectif
├─ 👥 Équipe
├─ 📊 Couplage
├─ ✅ Oui
├─ ❌ Non
├─ 💭 Question
├─ 💰 Coût
├─ ⚠️ Risque
└─ ⚡ Bénéfice

Espace Blanc

Important pour lisibilité physique:
- Marges: 0.5 cm
- Espacement vertical: 1.5x hauteur police
- Pas de texte à plus de 60% de la carte

📦 Composition du Jeu de Cartes

Jeu Complet (Recommandé)

Cartes de Pattern (9 cartes)

1. Open-host Service
2. Anticorruption Layer
3. Conformist
4. Shared Kernel
5. Partnership
6. Separate Ways
7. Published Language
8. Customer/Supplier Development
9. Big Ball Of Mud

Cartes de Relation d’Équipe (3 cartes)

10. Mutually Dependent Teams
11. Upstream/Downstream Teams
12. Independent Teams

Cartes d’Aide à la Décision (2 cartes)

13. Matrice de Sélection (recto/verso)
    a. Arbre de décision
    b. Tableau comparatif

Accessoires (Non-cartes)

Référence Rapide:
- Glossaire (1 feuille A4)
- Checklists (1 feuille A4)

Facilitation:
- Post-its (3 pads × 100 feuilles)
- Marqueurs (8 couleurs)
- Ruban adhésif (painter's tape)

Documentation:
- Guide de facilitation (couleur, A4)
- Exemples de cartographies (couleur, A4)

Jeu Minimal (Budget Limité)

Cartes essentielles:
├─ 1 exemplaire de chaque pattern (9)
├─ 1 exemplaire de chaque team relation (3)
└─ Matrice de sélection

Accessoires:
├─ Imprimés en noir/blanc
├─ Post-its
└─ Marqueurs simples

🖨️ Instructions d’Impression

Préparation des Fichiers

Option 1: Impression Professionnelle (Recommandée)

Fournisseur: Imprimerie locale ou en ligne
├─ Envoyez fichiers PDF haute-résolution
├─ Demandez:
│  ├─ Format A6 (ou personnalisé)
│  ├─ Carton 250 gsm
│  ├─ Finition mat
│  ├─ Recto/verso (2 designs différents)
│  └─ Découpe professionnelle
├─ Tirage: 10 jeux minimum (économie d'échelle)
└─ Coût estimé: 50-100€ pour 10 jeux

Avantages:
✓ Qualité professionnelle
✓ Découpe nette
✓ Finitions meilleures
✓ Scalable pour distributions

Option 2: Impression DIY (Budget)

Imprimante: Couleur A4 standard
Papier: Carton blanc 200 gsm (Canson, Clairefontaine)

Processus:
1. Imprimer sur feuilles A4 (2 cartes par feuille)
2. Collage sur carton (adhésif spray)
3. Découpe manuelle (cutter, règle)
4. Lamination (plastifier: protège l'usure)

Coût: 20-30€ pour 10 jeux
Temps: 2-3h (équipe de 2)

Avantages: Personnalisable, rapide pour petit tirage
Inconvénients: Moins professionnel, moins durable

Option 3: Hybrid (Meilleur Compromis)

Imprimez papier A4 chez vous
Envoyez scans à imprimerie pour:
  - Reliure (deck reliée)
  - Boîtage
  - Finitions premium

Coût: 30-50€ + envoi

📏 Template d’Impression (Dimensions)

Pour 2 cartes par feuille A4

Feuille A4: 210 × 297 mm
Disposition 2×1:

┌─────────┐┌─────────┐
│ Carte 1 ││ Carte 2 │
│ A6-R    ││ A6-R    │
│ 10.5×14.8││10.5×14.8│
└─────────┘└─────────┘
   (marge 5mm)

Fichier à imprimer:
- 2 cartes par page
- 1 cm de marges
- Recto/verso: imprimer faces séparément
  (Page 1: tous les rectos)
  (Page 2: tous les versos, orientation inversée)

Pour 4 cartes par feuille A4 (compact)

┌─────┐┌─────┐
│ C1  ││ C2  │
├─────┼─────┤
│ C3  ││ C4  │
└─────┘└─────┘

Dimension par carte: 10cm × 14.5cm
(Compacte, convenable pour impression simple)

📦 Packaging & Stockage

Boîte de Rangement

Recommandé: Boîte de jeu de cartes standard
├─ Dimension: 12 cm × 9 cm × 3.5 cm
├─ Type: Carton rigide avec fermeture magnétique
└─ Coût: 5-10€ par boîte

Contenu:
├─ Cartes (13) × 1.5 jeu (pour facilitation + remplacements)
├─ Post-its (3 pads)
├─ Marqueurs (5 mini-versions)
├─ Petit guide imprimé (A5)
└─ QR code vers ressources web

Étiquetage

Étiquette sur boîte:
┌───────────────────────────┐
│ 🎯 CONTEXT MAPPING        │
│ Cartes Ateliers           │
│ 13 Cartes + Accessoires   │
│ agileboarding.fr          │
│                           │
│ QR → Guide Facilitateur   │
└───────────────────────────┘

Stockage à Long Terme

Conditions:
├─ Endroit sec (humidité < 50%)
├─ Température stable (18-24°C)
├─ Pas de lumière directe (décoloration)
├─ Boîtes fermées (poussière)

Durée de vie: 5+ ans (conditions optimales)

🎯 Usage en Atelier

Mise en Place

Pour groupe de 10 personnes:
├─ 1 jeu de cartes (13 cartes) visible pour tous
├─ Tableau blanc / paperboard derrière
├─ Espace pour arranger les cartes
└─ Post-its + marqueurs à disposition

Arrangement:
├─ Cartes patterns au centre
├─ Team relations à droite
├─ Matrice sélection en reference
└─ Espace pour notes/diagrammes

Dynamique de Facilitation

Phase 1: Présentation (15 min)
├─ Montrer chaque carte
├─ Lire la vue rapide
├─ Recueillir réactions rapides

Phase 2: Identification Actuels (30 min)
├─ Équipes examinent leurs contextes
├─ Identifient patterns actuels
├─ Arrangements cartes sur tableau

Phase 3: Discussion (30 min)
├─ Évaluer intentionnel vs accidentel
├─ Identifier problèmes
├─ Brainstorm améliorations

Phase 4: Design Futur (30 min)
├─ Réarranger cartes pour state cible
├─ Identifier risques/efforts
├─ Définir étapes de transition

📊 Variantes de Jeux de Cartes

Jeu Léger (5 cartes essentielles)

Pour introduction rapide (< 1h):
1. Shared Kernel (collaboration)
2. Upstream/Downstream (asymétrie)
3. Separate Ways (indépendance)
4. Anticorruption Layer (isolation)
5. Mutually Dependent Teams (relation)

+ Matrice simplifié (choix rapide)

Jeu Complet (13 cartes)

Tous les patterns + relations + guide
Pour atelier profond (3h+)

Jeu Étendu (15+ cartes)

Jeu complet +
├─ Flashcards avec antipatterns courants
├─ Exemples de cartographies réelles
└─ Templates de décision

🎓 Ressources Complément Ateliers

Imprimer aussi:

1. Guide du Facilitateur (A4, couleur)

Sections:
├─ Timeline (comment utiliser cartes durant atelier)
├─ Questions par phase
├─ Exemples et cas-types
├─ Checklist facilitation
└─ Ressources pour approfondir

2. Glossaire (A4, 2 pages)

Définitions rapides de:
├─ Bounded Context
├─ Ubiquitous Language
├─ Integration Pattern
├─ Team Relationship
└─ Autres termes-clés

3. Exemples de Cartographies (A3 plié)

Cas réels:
├─ E-commerce (qui parle avec qui?)
├─ SaaS Platform (architecture type)
├─ Startup en croissance
└─ Legacy Migration

💡 Conseils Pratiques

Pour Éviter les Erreurs

❌ Ne pas: Cartes trop petites (illisibles)
✅ Faire: A6 minimum, ou A5 pour grand groupe

❌ Ne pas: Pli dans cartes (casse facilitation)
✅ Faire: Espace de rangement à plat

❌ Ne pas: Une seule couleur (confus)
✅ Faire: Codes couleur pattern vs relations

❌ Ne pas: Texte trop petit (sans lunettes!)
✅ Faire: Police ≥ 9pt

❌ Ne pas: Images compliquées
✅ Faire: Icônes simples, diagrammes clairs

Entretien

Entre ateliers:
├─ Vérifier pas de plis
├─ Nettoyer si markers partout (gomme douce)
├─ Replacer dans boîte propre
└─ Vérifier complet (13 cartes?)

Si dégradé:
├─ Imprimer remplacement
├─ Ou laminer si légérement usé
└─ Jeter si inutilisable

📱 Intégration avec Ressources Digitales

QR Codes sur Cartes

Chaque carte a QR code vers:
├─ Page web détaillée (3-4 pages)
├─ Exemples vidéo (5 min)
├─ Templates Excel/Figma
└─ Lecteur du jour: liens ressources

Application Compagnon (Optionnel)

Développer app simple:
├─ Browse 13 cartes digitalement
├─ Quiz: "Quel pattern pour votre situation?"
├─ Dessiner carte (diagramme simple)
├─ Exporter cartographie en PDF
└─ Share avec équipe

🎉 Résumé Check-list

Avant Impression

  • Fichiers PDF générés et vérifiés
  • Dimensions confirmées (A6 ou A5)
  • Codes couleur définis
  • QR codes validés (liens corrects)
  • Devis fournisseur approuvé

Après Réception

  • Cartes contrôlées (couleur, découpe, texte)
  • Pas de dommage transport
  • Boîtes préparées
  • Accessoires ajoutés (post-its, marqueurs)
  • Guides imprimés
  • Stockage adéquat

Avant Premier Atelier

  • Familiarisation avec cartes (les lire!)
  • Préparation salle (espace tableau)
  • Matériel complet (markers, post-its)
  • Tests QR codes
  • Guide facilitateur relu

📞 Support & Ressources

Pour plus d’infos:

Index des cartes: Les 13 Cartes de Context Mapping

📇 Index Complet : Les 13 Cartes de Context Mapping

Les 9 Patterns d’Intégration

Chaque pattern décrit une stratégie de collaboration entre deux contextes délimités (bounded contexts).

# Pattern Relation d’Équipe Couplage Vue Rapide
1 🟦 Open-host Service Upstream/Downstream Moyen Un service expose une interface commune documentée
2 🟦 Anticorruption Layer Upstream/Downstream Bas Downstream crée une couche de traduction protectrice
3 🟦 Conformist Upstream/Downstream Haut Downstream adopte simplement le modèle upstream
4 🟪 Shared Kernel Mutuellement Dépendant Très Haut Deux équipes partagent du code et un modèle
5 🟪 Partnership Mutuellement Dépendant Élevé Deux équipes équivalentes collaborent sur les interfaces
6 ⬜ Separate Ways Indépendant Aucun Deux contextes se séparent complètement
7 🟦 Published Language Upstream/Downstream (many) Bas Upstream publie un langage standard pour tous
8 🟪 Customer/Supplier Dev Upstream/Downstream Moyen Upstream et Downstream co-conçoivent l’interface
9 🔴 Big Ball Of Mud Amorphe EXTRÊME Anti-pattern : zones sans frontières claires

Les 3 Relations d’Équipes

Chaque relation décrit le type de dépendance entre deux équipes et ce que cela implique organisationnellement.

Outil: Matrice de Diagnostic Rapide des Dépendances

🔍 Outil: Matrice de Diagnostic Rapide des Dépendances

Mode d’Emploi

Utilisez cet outil pendant l’atelier pour diagnostiquer rapidement les dépendances problématiques.

Pour chaque paire d’équipes/contextes, remplissez ce formulaire collaborativement.


Formulaire de Diagnostic

1. IDENTIFICATION

Équipe/Service A: ___________________
Équipe/Service B: ___________________

Y a-t-il une dépendance?

  • NON (pas de relation)
  • OUI, A dépend de B
  • OUI, B dépend de A
  • OUI, mutuellement dépendants

Si NON: Fin du diagnostic. Archivez comme “Indépendant”.