Cartographie

🎯 Qu’est-ce qu’une Opportunity Solution Tree?

L’OST est une représentation visuelle qui relie:

        OUTCOME (Objectif métier + user)
              ↓
      OPPORTUNITIES (Obstacles/Besoins)
        ↙   ↓   ↘ 
   Sol.1 Sol.2 Sol.3    (Solutions à tester)
              ↓
        EXPERIMENTS
              ↓
        LEARNING

Chaque niveau répondent à:

OUTCOME: Où veut-on aller d’ici 6-12 mois?
OPPORTUNITIES: Qu’est-ce qui nous bloque d’y arriver?
SOLUTIONS: Comment lever chaque obstacle?
EXPERIMENTS: Quelle solution tester en priorité?

Avantage clé: Une seule question centrale (OUTCOME) peut avoir 10+ chemins différents (combinations opportunités + solutions). Ça force à explorer avant de coder.

L’écosystème numérique avec l’arrivée des IA génératives ressemble à une nébuleuse où la matière s’agrège, s’enflamme, puis donne naissance à une myriade de planètes encore instables. Dans ce chaos créatif, la bonne question n’est pas de trouver « la meilleure étoile », mais sûrement davantage de choisir sur quelle planète peut-on ou doit-on poser ses valises numériques pour un temps donné. Gardons aussi en tête, l’option du non usage ou du moins de la réversibilité de nos choix.

C’est quoi ? Pourquoi faire ?

Event Storming est un atelier collaboratif, rapide et visuel, conçu pour rendre explicite la logique métier d’un domaine complexe. Inventé par Alberto Brandolini, il permet de mettre en commun connaissances, hypothèses et risques, et de transformer ce travail collectif en décisions actionnables.

C’est l’atelier idéal si votre équipe doit :

Clarifier un processus métier obscur ou dispersé.
Faire émerger un langage commun (Ubiquitous Language).
Définir frontières de contexte (Bounded Contexts) et premières pistes d’architecture.
Prioriser des chantiers produit ou techniques.

Pour en savoir plus sur les bonnes pratiques et le glossaire Event Storming, voyez le travail de la communauté DDD Crew : https://github.com/ddd-crew et en particulier leur cheat-sheet : https://github.com/ddd-crew/eventstorming-glossary-cheat-sheet. Le livre d’Alberto Brandolini reste la référence pour la méthode et l’esprit de l’atelier.

🎯 Intention de Cette Section

Combiner deux outils puissants pour rendre la transformation agile concrète et visible:

Wardley Maps = Langage stratégique spatial (où est-on? où aller? comment y aller?)
Fresque de l’Agilité = une représentation cartographique de composants choisis (patterns, antipatterns, principes agiles)

Objectif: Montrer qu’on peut passer de tayloriste à agile en 2 mois avec 4 mouvements stratégiques simples, plutôt que des injonctions abstraites.

Il s’agira de cartographier avec la Wardley Map une équipe qui passe du taylorisme à l’agilité, cas peu probable, mais à valeur pédagogique pour apprendre Wardley, tester la consistance des éléments de la fresque, et accessoirement voir de quoi l’IA est capable.

🎯 Objectif: Relier Wardley Maps et Agilité

Cet article répond à une question centrale:

Comment cartographier l’évolution d’une équipe qui passe du management traditionnel à l’agilité?

Le Défi Pédagogique

Habituellement, on parle d’agilité de manière abstraite:

❌ “Soyez agiles!” (injonction vague)
❌ “Appliquez Scrum” (recette mécanique)
❌ “Changez de culture” (idéalisme)

Avec les Wardley Maps, on peut montrer concrètement:

✅ État initial (tayloriste/command-control)
✅ État cible (auto-organisation/empirisme)
✅ Chemins de transition (patterns vs antipatterns)
✅ Points critiques (dépendances, risques)

📚 Source: Fresque de l’Agilité

Cet article s’appuie sur la Fresque de l’Agilité de agileradical.org:

🎯 Pourquoi cette Carte?

Habituellement, on parle d’agilité de manière abstraite:

❌ “Soyez agiles!” (vague)
❌ “Appliquez Scrum” (mécanique)
❌ “Changez la culture” (idéalisme)

Avec une Wardley Map, on voit concrètement:

✅ État initial: tayloriste/command-control
✅ État cible: auto-organisation/empirisme
✅ 4 mouvements: ce qui change CONCRÈTEMENT

🗺️ État Initial: Équipe Tayloriste

Situation Typique

Taille: 8-12 développeurs
Org: Par spécialité (frontend/backend/infra)
Management: Hiérarchique (Directeur → Leads → Devs)
Processus: Cascade (Spec → Dev → Test → Prod)
Problèmes: Lenteur, silos, surprises, décalage client

Carte Wardley (Axe Y puis X)

                    HAUT (VISIBLE CLIENT)
                              │
                 ★ Livraison (tous les 12 mois)
                              │
                 ◆ Tests externes (caché)
                 ◆ Code développé (invisible)
                              │
          ─────────────────────────────────
                              │
                 ◆ Specs écrites (planning)
                 ◆ Réunions lancement
                 ◆ Contrats SLA
                              │
                    BAS (INVISIBLE)
                 ♦ Hiérarchie imposée
                 ♦ Contrôle qualité (fin cycle)
                 ♦ Reporting d'heures

Position sur X (Gauche-Droite):

🎯 Bienvenue dans l’Écoconception

Cette section rassemble une démarche complète d’écoconception numérique avec:

✅ Guide complet 5 étapes
✅ 5 cartographies pratiques à chaque phase
✅ Outils et sources fiables
✅ Pièges courants à éviter

📚 Ressources Principales

👉 Guide Complet: Écoconception en 5 Étapes

Le document de référence couvrant:

Étape 1: Alignement Valeurs-Fonctionnalités
- Cartographie: Identifier alignements positifs/négatifs
Étape 2: Audit de l’Existant
- Cartographie: Analyse d’impacts actuels (ACV simplifiée)
Étape 3: Cartographie Détaillée (CENTRALE)

Design de l’atelier “Paris Produit” / “Product Bets”

Pourquoi un atelier ?

Les Product Bets ne sont pas un simple exercice académique. C’est un processus de collaboration intense entre :

Les responsables produit
Les leaders techniques
Les sponsors métier
Les stakeholders clés

L’Atelier Paris Produits

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

Introduire le concept des Product Bets et leurs bénéfices
Identifier collectivement les opportunités métier réelles
Construire collaborativement les cartes de chaque pari (hypothèses, risques, ressources, métriques)
Confronter les idées à travers des challenges croisés entre équipes
Prioriser visuellement les paris selon leur valeur estimée vs. leur risque
Capturer l’énergie et engager tous les participants dans l’ownership du résultat

Les 7 cartes en référence

L’atelier utilise 7 zones principales à renseigner pour structurer la réflexion sur chaque Product Bet :

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 :

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.

🌳 Opportunity Solution Tree: La Recette Pas à Pas