Cartographie - Agile Boarding

🎯 Introduction: L’Ordre Pédagogique Correct

Beaucoup de gens disent:

“Je comprends les concepts, mais par où commence?”

Ce guide répond précisément: comment passer de la théorie à la pratique concrète.

CE QUI CHANGE: L’ordre des axes!

❌ ANCIEN ORDRE (moins intuitif):
   1. Lister éléments
   2. Dépendances
   3. Axe X (Évolution) - RÉALISÉ AVANT
   4. Axe Y (Visibilité)
   
✅ NOUVEAU ORDRE (plus logique):
   1. Lister éléments
   2. Dépendances
   3. Axe Y (Visibilité) - PREMIÈREMENT
      └─ Comprendre flux de valeur verticalement
      └─ Qui dépend de qui (client → infrastructure)
   4. Axe X (Évolution) - DEUXIÈMEMENT
      └─ APRÈS avoir compris la structure Y
      └─ Appliquer la maturité horizontalement

Pourquoi ce changement?

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

🌐 Ressources Officielles

🎓 Learn Wardley Mapping (Officiel)

URL: https://learnwardleymapping.com/
Type: Portal officiel
Contient:

Livre complet (free + paid)
Cours en ligne
Glossaire détaillé
Outils et ressources
Communauté

Recommandation: Point de référence officiel, excellentes ressources

📖 Livre: “Wardley Maps” par Simon Wardley

Auteur: Simon Wardley (créateur de Wardley Maps)
Format:

PDF gratuit: https://medium.com/wardleymaps
Livre papier: Amazon
MOBI/EPUB: GitHub

Contenu: 19 chapitres couvrant:

On Being Lost (fundamendals)
Finding a Path (navigation)
Exploring the Map (practice)
Doctrine (universal principles)
Scenarios (anticipation)
Climate & Culture (adaptation)

Recommandation: Complémentaire à ce système, plus détaillé

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

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.

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

Build-Measure-Learn – Lean Startup[web:8]
Scrum.org – Small calculated bets[web:3]

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

Agile Metrics – Balanced KPIs[web:10]
Age of Product – Agile Metrics & Bets[web:11]