Carte Context Mapping #5 : Partnership

17 novembre 2025

📇 Carte #5 : Partnership

Vue Rapide

🎯 Objectif : Deux équipes avec besoin mutuel s’engagent à se coordonner

👥 Relation d’équipe : Mutuellement Dépendant

📊 Couplage : Élevé (interfaces négociées)

Concept

Deux contextes aussi importants l’un que l’autre s’engagent à :

Collaborer sur les interfaces
Se consulter avant changements majeurs
Synchroniser leurs efforts

Team A (contexte équivalent)
    ↔ Partnership ↔
Team B (contexte équivalent)

La philosophie : “Nous avons besoin l’un de l’autre, donc on se coordonne”

Quand l’Utiliser ? ✅

✅ Deux équipes avec poids politique équivalent
✅ Interdépendances mutuelles et inévitables
✅ Aucune des deux ne veut être dominée par l’autre
✅ Les équipes se font confiance et veulent collaborer
✅ Les interfaces changent ensemble

Exemples

Deux microservices qui s’appellent beaucoup
Équipes au même niveau hiérarchique
Frontend/Backend d’un même produit
Deux domaines interconnectés (Commande ↔ Facturation)

Quand l’Éviter ? ❌

❌ Une équipe est clairement upstream
❌ Une équipe peut fonctionner indépendamment
❌ Les équipes ne se font pas confiance
❌ C’est une dépendance temporaire (plutôt: Anticorruption)
❌ Les équipes ne sont pas au même niveau (plutôt: Upstream/Downstream)

Questions Clés à se Poser 💭

Est-ce vraiment un besoin mutuel ou une équipe dépend juste de l’autre ?
Les équipes peuvent-elles se consulter facilement ?
Qu’est-ce qui se passe si les besoins divergent ?
Qui décide des changements aux interfaces ?
Quels sont les coûts de cette coordination ?

Implications pour les Deux Équipes

Responsabilités Communes

✓ Communiquer régulièrement : changements, blocages
✓ Négocier les interfaces ensemble
✓ Plannifier ensemble les changements majeurs
✓ Tester les intégrations continuellement

Avantages

✓ Flexibilité : vous pouvez évoluer ensemble
✓ Évolutivité : pas de couche de traduction
✓ Ownership partagé : responsabilité mutuelle
✓ Collaboration : force la communication

Risques

⚠️ Couplage fort : changements coordonnés nécessaires
⚠️ Synchronisation : les deux équipes doivent être “prêtes”
⚠️ Conflits : même poids = risque d’impasse
⚠️ Lenteur : besoin de consensus

Implied Governance

Comité de Coordination

Chaque sprint (ou bi-weekly):
├── Rep Team A
├── Rep Team B
└── Agenda: futures changes, blockers, alignment

Process de Changement

1. Proposition d'une équipe
2. Feedback de l'autre équipe
3. Négociation et décision mutuelle
4. Communication à toutes les autres équipes affectées
5. Implémentation coordonnée

Escalade en Cas de Conflit

Désaccord sur interface?
    ↓
Essayer de négocier (1-2 jours)
    ↓
Si pas de consensus, escalader au management
    ↓
Mais garder la bonne volonté de partnership

Exemple Concret : Commande ↔ Facturation

Contexte

Order Context : gère les commandes, confirmations
Billing Context : gère la facturation, paiements
Interdépendance mutuelle et au même niveau

Interfaces Négociées

// Ordre → Facturation
interface OrderPlacedEvent {
  orderId: string
  customerId: string
  items: OrderItem[]
  totalAmount: Money
  placedAt: Timestamp
}

// Facturation → Ordre
interface BillingStatusUpdated {
  orderId: string
  status: "pending" | "paid" | "failed"
  receipt: Receipt
}

Processus Partnership

Jour 1: Équipe Facturation propose:
  "On voudrait aussi le shippingAddress"

Jour 2: Équipe Commande répond:
  "OK mais on peut pas faire OrderItem.weight ?"

Jour 3: Réunion, accord:
  "Oui aux deux, avec impact timing sur sprint N+1"

Jour 4: Les deux équipes mettent à jour leurs interfaces

Co-evolution

Sprint N
├── Order Service v1.3
└── Billing Service v2.1 (compatible avec Order v1.3)

Sprint N+1 (ensemble)
├── Order Service v2.0 (breaking change!)
└── Billing Service v3.0 (adapté à Order v2.0)

Coordination: Merge au même moment!

Signes de Partition Saine vs. Malsaine

Partnership Sain ✅

✓ Réunions régulières (bi-weekly)
✓ PRs revue par l'autre équipe avant merge
✓ Changements planifiés avec au minimum 2 sprints d'avance
✓ Communication proactive sur les blocages
✓ Respect mutuel des contraintes

Partnership Malsain ❌

❌ Changements unilatéraux sans discuter
❌ "On fait et on verra"
❌ Une équipe attend l'autre (bloquée)
❌ Conflits non résolus, escalade fréquente
❌ Dépendances cachées découvertes après

Gouvernance: De Partnership à Upstream/Downstream

Quand ça change:

Si une équipe devient dominante dans les décisions
    ↓
Partnership → Upstream/Downstream (avec ACL)

Si une équipe veut l'indépendance
    ↓
Partnership → Anticorruption Layer (séparation)

Si collaboration cesse
    ↓
Partnership → Separate Ways (duplication)

Outils de Coordination

Communication

Sprint planning partagé (30 min)
Bi-weekly sync sur l’architecture
Shared Kanban ou dashboard des dépendances

Code

Tests d’intégration automatisés
Contract testing (tu changes quoi, je teste)
Version management clair

Checklist de Mise en Place ✓

Les deux équipes sont vraiment au même niveau
Il existe un processus de communication régulier
Les interfaces sont documentées clairement
Vous avez une stratégie de changement
Un escalade process pour les conflits
Des tests d’intégration automatisés

Ressources et Lectures

Domain-Driven Design par Eric Evans - Partnership
Team Topologies par Matthew Skelton - Team Interaction Modes
DDD Crew - Context Mapping

Notes de Facilitation pour l’Atelier

Animation

Demandez : “Vous dépendez vraiment l’un de l’autre ?”
Testez : “À quel point communiquez-vous ?”
Documentez : “Comment vous gérez les changements ?”

Pièges Communs

⚠️ Une équipe domine : pas vraiment du partnership
⚠️ Pas de communication : découvrir les changements par surprise
⚠️ Trop de réunions : coordination qui ralentit
⚠️ Pas de consensus : conflits permanents

Questions Provocatrices

“Vous vous faites vraiment confiance ? Prouvez-le.”
“Combien de temps vous passez à vous synchroniser ?”
“Et si une équipe voulait partir ?”
“Qui arbitre quand vous n’êtes pas d’accord ?”