Cartographie de Contexte : Visualiser l'Architecture Socio-Technique

Cartographie
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épond à 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

Les temps sont données à titre indicatifs, davantage pour se donner une limite max pour un premier cycle et itérer pour affiner/améliorer.

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.