Cartographie

Carte Context Mapping #2 : Anticorruption Layer

📇 Carte #2 : Anticorruption Layer (ACL)

Vue Rapide

🎯 Objectif : L’équipe downstream crée une couche d’isolation pour protéger son modèle

👥 Relation d’équipe : Upstream/Downstream (asymétrique)

📊 Couplage : Bas (isolation complète)


Concept

L’équipe downstream crée une couche de traduction (ACL) qui :

  • Traduit le modèle upstream en modèle downstream
  • Isole le domaine downstream des changements upstream
  • Protège l’indépendance du downstream
Upstream (modèle compliqué/différent)
        ↓
Anticorruption Layer (translation)
        ↓
Downstream (modèle propre et indépendant)

Quand l’Utiliser ? ✅

  • ✅ Les modèles upstream et downstream sont radicalement différents
  • ✅ Vous voulez protéger votre domaine des pollutions upstream
  • ✅ L’upstream change fréquemment ou est mal conçu
  • ✅ Vous avez besoin d’indépendance maximale
  • ✅ L’interface upstream est imposée et immuable

Exemples

  • Legacy System Integration : Intégrer un vieux système avec ACL
  • Third-party API : Adapter une API externe à votre domaine
  • Big Ball Of Mud : Isoler votre domaine du chaos upstream

Quand l’Éviter ? ❌

  • ❌ L’interface upstream est simple et stable
  • ❌ Vous pouvez vous permettre d’adopter le modèle upstream (Conformist)
  • ❌ La complexité de traduction est excessive
  • ❌ Vous avez besoin de synchronisation temps-réel très serrée

Questions Clés à se Poser 💭

  1. Le modèle upstream pollue-t-il notre domaine ?
  2. Pouvons-nous nous permettre de créer une couche de traduction ?
  3. La traduction est-elle complexe ou simple ?
  4. Comment maintenons-nous la synchronisation entre les deux modèles ?
  5. Où plaçons-nous l’ACL : au niveau de l’équipe ou du service ?

Implications pour l’Équipe Downstream

Responsabilités

  • Concevoir l’ACL : mapper upstream → downstream
  • Maintenir l’ACL : gérer les évolutions upstream
  • Documenter les mappings : pourquoi cette traduction ?
  • Tester l’ACL : validation des conversions

Avantages

  • Indépendance totale : votre domaine est protégé
  • Flexibilité : vous pouvez changer sans affecter l’upstream
  • Clarté : votre code est clair, la traduction est centralisée
  • Évolutivité : remplacer upstream ne casse pas votre logique

Risques

  • ⚠️ Complexité : maintenir une couche de traduction
  • ⚠️ Performance : la traduction peut avoir un coût
  • ⚠️ Synchronisation : gérer les changements upstream
  • ⚠️ Duplication : code de mapping qui peut devenir lourd

Patterns de Traduction Courants

1. Mapping Simple

Upstream: Order { items: [], total: 0 }
       ↓
ACL: convertOrderToOurModel()
       ↓
Downstream: PurchaseOrder { lineItems: [], grossAmount: 0 }

2. Enrichissement

Upstream: minimal data
       ↓
ACL: enrichir avec contexte (user, country, etc.)
       ↓
Downstream: complete domain object

3. Agrégation

Upstream 1: User data
Upstream 2: Address data
       ↓
ACL: combiner les sources
       ↓
Downstream: Customer aggregate

4. Transformation

Upstream: Legacy format
       ↓
ACL: parser, validator, transformer
       ↓
Downstream: Modern format

Exemple Concret : Integration d’un Legacy System

Contexte Downstream : Nouvelle Commande Service

Votre domaine clair et moderne :

Carte Context Mapping #3 : Conformist

📇 Carte #3 : Conformist

Vue Rapide

🎯 Objectif : L’équipe downstream adopte le modèle upstream sans traduction

👥 Relation d’équipe : Upstream/Downstream (asymétrique)

📊 Couplage : Haut (adhérence au modèle upstream)


Concept

L’équipe downstream accepte simplement le modèle et les conventions de l’équipe upstream.

Upstream (modèle de référence)
    ↓ (pas de traduction)
Downstream (adopte le même modèle)

La philosophie : “Ce que vous donnez, nous l’utilisons tel quel”


Quand l’Utiliser ? ✅

  • ✅ Le modèle upstream est suffisamment bon pour votre besoin
  • ✅ Créer une ACL serait trop complexe ou non rentable
  • ✅ L’upstream est stable et bien conçu
  • ✅ Vous avez une dépendance forte et c’est acceptable
  • ✅ L’équipe upstream a du poids politique ou est essentielle

Exemples

  • API publique stable : Adopter directement une API bien conçue
  • Plateforme core : Tous les services acceptent le modèle core
  • Standard industrie : Utiliser un standard reconnu (ISO, RFC, etc.)

Quand l’Éviter ? ❌

  • ❌ Le modèle upstream est incompatible avec votre domaine
  • ❌ L’upstream change fréquemment sans coordination
  • ❌ Vous avez besoin de dépendances croisées (Partner pattern est meilleur)
  • ❌ C’est une dépendance temporaire (better: Anticorruption Layer)
  • ❌ Le modèle upstream est mal conçu (Big Ball Of Mud)

Questions Clés à se Poser 💭

  1. Est-ce que le modèle upstream nous convient vraiment ?
  2. Allons-nous devoir le modifier plus tard ?
  3. Quels sont les risques de cette adhérence ?
  4. Comment restons-nous informés des changements ?
  5. Qui décide des évolutions du modèle shared ?

Implications pour l’Équipe Downstream

Responsabilités

  • Accepter le modèle tel qu’il est
  • ✓ Communiquer rapidement si le modèle pose problème
  • Collaborer avec upstream pour améliorations
  • Supporter les changements d’upstream

Avantages

  • Simple : pas de couche de traduction
  • Rapide à intégrer : implémentation directe
  • Couplage intentionnel : c’est du domaine partagé
  • Moins de bugs : une seule source de vérité

Risques

  • ⚠️ Pollina votre modèle : compromis sur votre pureté
  • ⚠️ Couplage fort : difficile à défaire
  • ⚠️ Bloqué par upstream : changements lents
  • ⚠️ Conflit de visions : deux domaines, une structure

Implications pour l’Équipe Upstream

Responsabilités

  • Maintenir une API stable : les downstream dépendent de vous
  • Communicer les changements : informer rapidement
  • Respecter la compatibilité : ou avoir un processus de migration
  • Écouter les besoins downstream

Avantages

  • Influence : votre modèle devient référence
  • Couplage maîtrisé : par design

Risques

  • ⚠️ Responsabilité : you break it, you own all the consequences
  • ⚠️ Évolution lente : devoir négocier avec tous les conformists

Exemples de Conformist Patterns

1. Shared Business Model

Upstream Team (Orders Domain)
    ├── Order { id, customerId, items, status }
    ├── OrderItem { productId, quantity, price }
    └── Status enum

Downstream Team (Invoicing)
    └── Adopte exactement le même modèle
        ├── Invoice utilise Order directement
        ├── InvoiceItem utilise OrderItem
        └── Respecte Status enum

2. API Publique Standard

Upstream: REST API (JSON well-known)
    {
      "id": "...",
      "name": "...",
      "type": "...",
      "metadata": { ... }
    }

Downstream Services:
    └── Tous utilisent exactement cette structure
        Pas de traduction

3. Industrie Standard (XML/JSON Schema)

Standard: UBL Invoice
    Upstream (supplier): génère UBL
    Downstream (customer): consomme UBL
    → Pas de traduction

Exemple Concret : Plateforme E-commerce

Contexte

Vous avez une équipe Product Core qui gère l’essai central.

Cartographie de Contexte : Visualiser l'Architecture Socio-Technique

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 :

Cartographie des Paris Produits : De la Théorie à la Pratique

Cartographie des Paris Produits : De la Théorie à la Pratique

Pourquoi les “Product Bets” ?

En octobre 2025, James Shore a prononcé un discours majeur à la conférence Agile Cambridge intitulé “The Accountability Problem”. Ce discours adresse une problématique fondamentale que tout leader d’ingénierie connaît bien : comment démontrer l’accountability de l’équipe de développement logiciel ?

Le problème traditionnel

Généralement, les équipes de développement se voient imposer une forme d’accountability basée sur :

  • Les fonctionnalités à livrer : “Pouvez-vous me promettre la feature X ?”
  • Les dates : “Quand sera-ce terminé ?”
  • La pression budgétaire : “Nous avons X dollars, combien de features cela nous achète-t-il ?”

Or, ce modèle repose sur une fausse prémisse : la croyance que le développement logiciel ressemble à faire un devoir scolaire - une tâche linéaire avec un début, une fin clairement définie, et un chemin prévisible de A à B.

Expérimentations : Apprendre vite sur ses paris

Carte 7 : Itérations clés / Expériences

Définition

Lister les premières boucles d’apprentissage ou “build-measure-learn” à mener, avec une intention claire de valider rapidement les hypothèses du pari.

Exemples issus du terrain

Pour les “baby elephants”, James Shore propose une série d’expériences : tester l’appétence du marché, la logistique, la réceptivité via des versions pilotes ou des tests[attached_file:1].

Conseils

  • Commencer par les risques clés (prioriser les tests qui pourraient “tuer” le pari)
  • Privilégier les petits pas, retours rapides[web:8][web:3]
  • Impliquer toute l’équipe et les parties prenantes[web:6]

Ressources associées


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.

KPIs : Mesurer le succès du pari

Carte 6 : Indicateurs de validation

Définition

Choisir les indicateurs qui permettront d’évaluer la réussite ou l’échec du pari produit, sur toute la chaîne de valeur.

Exemples issus du terrain

James Shore : “On se concentre sur l’évaluation collective de la réussite via des KPIs pertinents, pas sur une preuve isolée de la valeur de chaque feature.”[attached_file:1]

Exemples d’indicateurs

  • Valeur délivrée / ROI estimé
  • Qualité perçue, utilisation réelle
  • Prédictibilité (ratio planned-to-done)
  • Rétention, croissance[web:10]

Ressources associées

Levier Produit : Choisir la solution stratégique

Carte 2 : Mécanisme / Solution / Moyen / Levier

Définition

Décrire brièvement comment l’équipe va tenter d’atteindre le résultat business : nouveau service, évolution de l’offre, partenariat, lancement d’une nouvelle fonctionnalité…

Exemples issus du terrain

Dans la “famille des war elephants”, James Shore propose : “Ouvrir le marché des activités familiales… en lançant des expériences éléphant baby-friendly.”[attached_file:1]

Conseils pour la rédaction

  • Garder le mécanisme à un niveau macro (“Lancer un nouveau produit”, pas “Faire un formulaire”)
  • Favoriser la formulation par hypothèse (“Nous pensons que … conduira à …”)
  • Se référer aux étapes de découverte produit, pas uniquement delivery[web:4][web:6].

Ressources associées

Mise maximale : Définir le risque accepté

Carte 4 : Mise maximale / Maximum Wager

Définition

Le maximum wager représente le plafond d’investissement (temps, argent, effort) que l’équipe accepte de risquer sur le pari produit.

Exemples issus du terrain

“On ne sait pas combien le pari va coûter, mais on fixe un plafond. Si la valeur estimée d’un bet est de $6M, l’équipe peut décider d’allouer jusqu’à $5M.”[attached_file:1]

Conseils de facilitation

  • Décision collective management/équipe
  • Ancrer la discussion sur l’impact business, non sur les micro-coûts
  • Rendre explicites les arbitrages (“Combien sommes-nous prêts à perdre ?”)

Ressources associées