🎴 Article 5: Construire Votre Première Carte Wardley
🎯 Vue d’Ensemble
Cet article répond à la question: Comment construire ma première carte Wardley?
🔴 NOUVEL ORDRE APPLIQUÉ (Y→X):
Ce guide vous mènera avec l’ordre pédagogique correct:
- ✅ Étape 1: Lister tous les éléments
- ✅ Étape 2: Identifier les dépendances
- ✅ Étape 3: Positionner sur Axe Y (visibilité) D’ABORD
- ✅ Étape 4: Positionner sur Axe X (évolution) ENSUITE
- ✅ Étape 5: Assigner mouvements Build/Buy/Partner
- ✅ Étape 6: Interpréter & agir
Pourquoi cet ordre?
Axe Y D'ABORD = Comprendre structure (client→infrastructure)
Axe X ENSUITE = Appliquer maturité (innovation→commodité)
Résultat: Carte 2D stratégiquement utile!
Durée d’apprentissage: 30-40 minutes
Niveau: Pratique (après Articles 1-4)
Prérequis: Concepts + Axes Y et X
Outil: Papier ou onlinewardleymaps.com
📊 Vue d’Ensemble: 6 Étapes
Étape 1: Étape 2: Étape 3:
LISTER DÉPENDANCES AXLE Y (PREMIER!)
├─ Éléments ├─ Qui dépend de qui? ├─ Visible vs
├─ Features ├─ Chaînes │ Invisible
├─ Services ├─ Points critiques └─ Position Haut/Bas
└─ Infrastructure └─ Risques
↓ Matériel: Feuille ou Miro
Étape 4: Étape 5: Étape 6:
AXLE X (DEUXIÈME!) MOUVEMENTS INTERPRÉTATION
├─ Innovation vs ├─ BUILD? ├─ Stratégie
│ Commodité ├─ BUY? ├─ Changements
├─ Position Gauche/Droite├─ PARTNER? ├─ Roadmap
└─ Pour chaque Y déjà └─ Par élément └─ Risques
positionné
↓ Résultat: Carte 2D complète avec actions
🔧 Matériel Nécessaire
Options pour Créer Votre Carte
Option 1: Papier-Crayon ✓ Recommandé pour apprendissage
Avantages:
✓ Rapide & flexible
✓ Itération facile
✓ Pas de tech distraction
Inconvénients:
✗ Pas digitalisé
✗ Difficile partager
✗ Hard d'itérer après
Option 2: Miro / Mural ✓ Recommandé pour équipes
Avantages:
✓ Collaboratif en temps réel
✓ Facile itération
✓ Can export/share
Inconvénients:
✗ Prise d'apprentissage
✗ Internet requis
Option 3: Google Slides / PowerPoint
Avantages:
✓ Familier
✓ Easy export
Inconvénients:
✗ Pas bien pour collaboration live
✗ Layout rigide
Recommandation: Commencez papier, puis Miro pour partager!
⭐ ÉTAPE 1: LISTER LES ÉLÉMENTS
Qu’est-ce qu’un “Élément”?
Un élément = quelque chose de nommable:
✓ OUI = Élément:
├─ Features (homepage, search, checkout)
├─ Services (backend, payment API, auth)
├─ Infrastructure (AWS, database, CDN)
├─ Personas clés (utilisateurs, admin)
└─ Dépendances externes (payment gateway, email)
✗ NON = Pas un élément:
├─ "Performance" (trop vague)
├─ "Technology" (trop générique)
├─ "Strategy" (pas tangible)
└─ "Culture" (trop abstrait)
1.1: Brainstorm Exhaustif
Rassembler l’équipe et lister TOUT:
15 minutes de brainstorm libre:
FEATURES CLIENT:
├─ Homepage
├─ Product browsing
├─ Search
├─ Shopping cart
├─ Checkout
├─ Order tracking
├─ Reviews
└─ Wishlist
BACKEND SERVICES:
├─ User authentication
├─ Payment processing
├─ Inventory management
├─ Recommendation engine
├─ Search indexing
├─ Email notifications
└─ Analytics tracking
INFRASTRUCTURE:
├─ Web servers (EC2)
├─ Database (RDS)
├─ Cache (ElastiCache)
├─ CDN (CloudFront)
├─ Storage (S3)
├─ Monitoring (CloudWatch)
└─ Internet connection
THIRD-PARTY:
├─ Stripe (payment)
├─ SendGrid (email)
├─ Twilio (SMS)
└─ Google Analytics
1.2: Déduplication & Consolidation
Nettoyer la liste:
Avant:
├─ Search UI
├─ Search box
├─ Search functionality
└─ Search results
Après (consolidé):
└─ Search (feature complète)
Raison: Trop de granularité = carte illisible
Granularité correcte: "Je peux assigner BUILD/BUY à ça"
1.3: Valider le Périmètre
Scope check:
Question: "Est-ce au-dedans de notre périmètre?"
Oui? → Inclure
Non? → Exclure
Exemple Amazon:
✓ Inclure: App, recommendations, warehouse management
✗ Exclure: Internet infrastructure, physical trucks
Exemple Netflix:
✓ Inclure: App, algorithms, streaming quality
✗ Exclure: Internet backbone, electricity generation
Résultat Étape 1
Liste de 15-25 éléments:
Vous avez une LONGUE liste
Pas encore organisée
Pas encore positionnée
🔗 ÉTAPE 2: IDENTIFIER DÉPENDANCES
2.1: Cartographier Dépendances
Pour chaque élément, demander:
"Cet élément dépend-il d'autres éléments?"
Exemple:
├─ Product homepage
│ └─ dépend de ← Recommendation engine
│ └─ dépend de ← Database utilisateurs
│ └─ dépend de ← AWS servers
│
├─ Checkout
│ └─ dépend de ← Payment API (Stripe)
│ └─ dépend de ← Database (orders)
│ └─ dépend de ← AWS servers
│
└─ AWS servers
└─ dépend de ← Électricité
└─ dépend de ← Internet
2.2: Visualiser Chaînes
Créer chaînes de dépendances:
CHAÎNE 1 (Recommendation):
Homepage
→ Recommendation engine
→ ML training data
→ Database
→ AWS
→ Electricity
CHAÎNE 2 (Checkout):
Checkout page
→ Payment verification
→ Stripe API
→ Database (orders)
→ AWS
→ Electricity
CHAÎNE 3 (Performance):
Homepage
→ Cache layer
→ CDN
→ AWS
→ Electricity
2.3: Identifier Points Critiques
Demander: “Si ceci casse, quoi casse?”
Si AWS casse? → TOUT casse
Si Payment casse? → Checkout impossible
Si Homepage casse? → Just homepage broken
Si Database casse? → Multiple chaînes down
CRITICITÉ:
1 AWS = CRITIQUE (single point of failure)
2 Database = CRITIQUE
3 Payment = IMPORTANT (but not everything)
4 Homepage = MOINS IMPORTANT (other pages work)
Résultat Étape 2
Vous comprenez maintenant:
- Qui dépend de qui
- Points critiques (SPOF)
- Chaînes de valeur
- Où concentrer stabilité
📍 ÉTAPE 3: POSITIONNER AXLE X (ÉVOLUTION)
3.1: Pour Chaque Élément, Demander
"Cet élément est-il Innovant ou Commodité?"
QUESTIONS:
├─ Peu de gens le font? → Gauche (Innovant)
├─ Plusieurs le font pareil? → Centre (Produit)
├─ Tous le font identique? → Droite (Commodité)
│
└─ C'est notre différenciation? → Gauche
C'est support function? → Centre-Droite
3.2: Positionnement Pratique
Template pour chaque élément:
Élément: Homepage
├─ Innovation? "Très différent de competitors"
├─ Position: GAUCHE (Innovant)
└─ Raison: C'est notre brand, nos recommendations
Élément: Payment Processing
├─ Innovation? "Stripe fait la même chose"
├─ Position: DROITE (Commodité)
└─ Raison: Interchangeable, commodity service
Élément: ML Recommendation Engine
├─ Innovation? "Propriétaire, brevet possible"
├─ Position: GAUCHE (Innovant)
└─ Raison: Source de différenciation clé
Élément: AWS Servers
├─ Innovation? "AWS/Azure/Google identique"
├─ Position: CENTRE-DROITE (Produit→Commodité)
└─ Raison: Infrastructure commodity
3.3: Placer sur Axe X
Sur votre feuille/Miro, créer axe horizontal:
GAUCHE (INNOVANT) CENTRE (PRODUIT) DROITE (COMMODITÉ)
│ │ │
│ │ │
├─ App UI ├─ Auth ├─ Payment (Stripe)
├─ ML Engine ├─ Analytics ├─ Email (SendGrid)
├─ Recommendations ├─ Notifications ├─ CDN
│ │ ├─ Database
│ │ └─ AWS
│ │
←─ Beaucoup innovation Zéro différenciation ──→
Résultat Étape 3
Chaque élément a une position horizontale:
- Éléments innovants à gauche
- Éléments commoditisés à droite
- Éléments en transition au centre
👁️ ÉTAPE 4: POSITIONNER AXLE Y (VISIBILITÉ)
4.1: Pour Chaque Élément, Demander
"L'utilisateur voit-il cet élément?"
QUESTIONS:
├─ Utilisateur voit & clique? → HAUT (Visible)
├─ Utilisateur ne voit pas mais sent l'impact? → MILIEU (Semi)
├─ Utilisateur jamais conscient? → BAS (Invisible)
│
└─ Direct user interaction? → Haut
Backend support? → Milieu
Infrastructure only? → Bas
4.2: Positionnement Pratique
Template pour chaque élément:
Élément: App UI (Homepage)
├─ Visibilité? "Utilisateur voit et clique"
├─ Position: HAUT (Visible)
└─ Raison: Interface directe
Élément: Recommendation Engine
├─ Visibilité? "Utilisateur voit résultats, pas algo"
├─ Position: HAUT/MILIEU (Semi-Visible)
└─ Raison: Impact visible, mais backend
Élément: Database
├─ Visibilité? "Utilisateur jamais conscient"
├─ Position: BAS (Invisible)
└─ Raison: Infrastructure pure
Élément: Payment API
├─ Visibilité? "Utilisateur sait qu'il paye"
├─ Position: MILIEU (Semi-Visible)
└─ Raison: Impact visible mais backend
4.3: Placer sur Axe Y
Sur votre feuille/Miro, créer axe vertical:
HAUT (VISIBLE)
│
├─ App UI
├─ Homepage
├─ Search
├─ Checkout
│
MILIEU (SEMI-VISIBLE)
│
├─ Recommendation engine
├─ Payment verification
├─ User auth
│
BAS (INVISIBLE)
│
├─ Database
├─ AWS servers
├─ Cache
├─ Électricité
4.4: Combiner X et Y
Maintenant créer la 2D matrix (le plus important!):
GAUCHE CENTRE DROITE
(Innovant) (Produit) (Commodité)
HAUT ★ App UI ◆ Search ■ Checkout UI
(VISIBLE) ★ Homepage ◆ Browsing
★ Personalization
MILIEU ★ ML Engine ◆ Auth ◆ Payment API
(SEMI) ★ Recommendations ◆ Analytics ◆ Email Service
BAS ◆ Monitoring ◆ Database ♦ AWS
(INVISIBLE) ◆ Custom Logging ◆ Cache ♦ CDN
◆ API Gateway ♦ Internet
Résultat Étape 4
Carte complète avec positions X & Y:
Vous voyez maintenant la structure complète
Quoi est innovation vs commodité
Quoi est visible vs invisible
🎯 ÉTAPE 5: ASSIGNER MOUVEMENTS (BUILD/BUY/PARTNER)
5.1: Par Chaque Position, Assigner Mouvement
Utiliser la matrice de l’Article 4:
POSITION → MOUVEMENT
★ GAUCHE + HAUT → BUILD (innovation + visible = core)
★ GAUCHE + MILIEU → BUILD ou PARTNER
★ GAUCHE + BAS → PARTNER ou BUY
◆ CENTRE + HAUT → BUILD ou PARTNER
◆ CENTRE + MILIEU → PARTNER ou BUY
◆ CENTRE + BAS → BUY ou OUTSOURCE
■ DROITE + HAUT → BUY
■ DROITE + MILIEU → BUY ou OUTSOURCE
♦ DROITE + BAS → BUY ou OUTSOURCE (must buy)
5.2: Positionnement Pratique
Pour chaque élément, ajouter étiquette:
★ App UI (Gauche + Haut)
└─ Mouvement: BUILD
★ ML Recommendations (Gauche + Milieu)
└─ Mouvement: BUILD
◆ Auth Service (Centre + Milieu)
└─ Mouvement: BUILD ou BUY (considérer Auth0)
■ Checkout UI (Droite + Haut)
└─ Mouvement: BUY (SaaS)
◆ Payment Verification (Centre + Milieu)
└─ Mouvement: PARTNER ou BUY (Stripe/Adyen)
♦ Database (Droite + Bas)
└─ Mouvement: BUY (AWS RDS)
♦ AWS Infrastructure (Droite + Bas)
└─ Mouvement: BUY ou PARTNER (AWS partnership)
♦ Électricité (Droite + Bas)
└─ Mouvement: BUY (power company)
5.3: Valider Portfolio
Vérifier distribution:
Questions:
├─ Avez-vous 15-20% BUILD? (innovation protection)
├─ Avez-vous 40-50% PARTNER/BUY? (support functions)
├─ Avez-vous 30-40% BUY commodité? (cost efficiency)
│
└─ Trop de BUILD? → Trop cher, pas scalable
Trop de BUY? → Générique, pas différencié
Pas d'innovation? → Mort dans 5 ans
Résultat Étape 5
Vous savez maintenant:
- Quoi construire in-house (BUILD)
- Quoi acheter/SaaS (BUY)
- Quoi faire en partenariat (PARTNER)
- Si portfolio est sain
📊 ÉTAPE 6: INTERPRÉTATION & ACTION
6.1: Analyser la Carte
Questions stratégiques:
❓ INNOVATION:
└─ Êtes-vous nombreux à gauche? Suffisant?
❓ STABILITÉ:
└─ Avez-vous couverture à droite pour stabilité?
❓ DÉPENDANCES:
└─ Y-a-t-il single points of failure?
❓ PORTFOLIO:
└─ Est-il équilibré BUILD/BUY/PARTNER?
❓ FUTURES:
└─ Prédisez quoi se déplace gauche→droite soon
6.2: Identifier Mouvements Futurs
L’évolution est prévisible:
Exemple Amazon (année par année):
2000: AWS n'existe pas
2005: AWS = INNOVATION (gauche)
2010: AWS = PIONNIER (centre-gauche)
2015: AWS = PRODUIT (centre)
2020: AWS = COMMODITÉ (droite)
Implication: Votre stratégie AWS aujourd'hui ≠ stratégie 2020
6.3: Créer Roadmap
Basé sur la carte, créer plan:
Q1 2024:
├─ BUILD: Continuer innovation AI
├─ OPTIMIZE: Réduire coûts infrastructure 30%
└─ PARTNER: Discuter AWS partnership
Q2 2024:
├─ BUILD: Lancer nouvelle feature
├─ BUY: Migrer auth à Auth0
└─ OUTSOURCE: Notifications à SendGrid
Q3-Q4 2024:
├─ ANTICIPATE: ML engine devenant produit?
├─ ADJUST: Si oui, passer à PARTNER mode
└─ EXPLORE: Nouvelles innovations (gauche)
6.4: Documenter Risques
Points critiques:
RISQUES IDENTIFIÉS:
1 AWS is single point of failure
→ Action: Multi-region failover
2 ML team is small (5 devs)
→ Action: Hire 2 more engineers
3 Payment API is only vendor (Stripe)
→ Action: Plan secondary provider
4 No innovation in pipeline (2025)
→ Action: Dedicate 20% R&D
6.5: Créer Énoncé de Vision
Basé sur la carte:
VISION 2025:
"Nous continuons innover en ML (gauche) pour rester unique.
Nous commoditisons l'infrastructure (droite) pour coûts.
Nous partenaire pour services établis (centre).
Dans 3 ans, ML doit supporter 10x users.
Notre avantage: Recommendations unique, pas infra."
Résultat Étape 6
Vous avez:
✓ Compréhension complète du système
✓ Stratégie BUILD/BUY/PARTNER claire
✓ Roadmap 2024-2025
✓ Risques documentés
✓ Vision future articulée
📋 Template: Votre Première Carte
Format Papier-Crayon
GAUCHE CENTRE DROITE
(INNOV) (PRODUIT) (COMMOD)
HAUT
(VISIBLE) ┌──────────┐ ┌──────────┐ ┌──────────┐
│ App UI │ BUILD │ │ │ │
│ Personal │ │ │ │ │
│ │ │ │ │ │
└──────────┘ └──────────┘ └──────────┘
MILIEU ┌──────────┐ ┌──────────┐ ┌──────────┐
(SEMI) │ ML Algo │ BUILD │ Auth │ BUILD │ Payments │BUY
│ Recom │ │ Analyt │ │ Email │
│ │ │ │ │ │
└──────────┘ └──────────┘ └──────────┘
BAS ┌──────────┐ ┌──────────┐ ┌──────────┐
(INVISIBLE) │ Monitor │ BUILD │ Database │ BUY │ AWS │BUY
│ Logging │ │ Cache │ │ CDN │
│ │ │ API GW │ │ Internet │
└──────────┘ └──────────┘ └──────────┘
Dépendances clés:
App UI → ML Algo
ML Algo → Database
Database → AWS
Risques:
- AWS single point of failure
- ML team small
Portfolio: 30% BUILD, 30% PARTNER, 40% BUY ✓ Équilibré
Format Digital (Miro)
[Créer quadrants via shapes]
GAUCHE-HAUT (Build Innovant):
├─ Post-it: "App UI"
├─ Post-it: "ML Engine"
└─ Étiquette: "BUILD" (couleur rouge)
DROITE-BAS (Buy Commodité):
├─ Post-it: "AWS"
├─ Post-it: "CDN"
└─ Étiquette: "BUY" (couleur verte)
[Ajouter flèches pour dépendances]
[Ajouter notes pour risques]
🚀 Conseils Pratiques
Comment Faciliter Atelier Groupe
Durée: 2-3 heures (idéal)
30 min: Explainer concepts (axes, mouvements)
45 min: Brainstorm éléments (équipe)
45 min: Dépendances & positions (discussion)
30 min: Mouvements & stratégie (débat)
30 min: Questions & documenter risques
Pièges Courants
❌ Trop de granularité
"Frontend components X, Y, Z"
→ Consolider en "Frontend"
❌ Éléments trop abstraits
"Strategy", "Culture", "Innovation"
→ Utiliser seul éléments tangibles
❌ Oublier dépendances
→ Toujours mapper qui dépend de qui
❌ Mauvaise visibilité Y
→ Rappeler: "Client conscient?"
❌ No consensus
→ Débat sain, prendre décision finale
Itérations Futures
Révisez votre carte:
Tous les 6 mois:
├─ Éléments changé position?
├─ Nouvelles innovations?
├─ Mouvements stratégiques ajustés?
└─ Risques nouveaux?
Annuellement:
├─ Refaire complète analysis
├─ Adapter stratégie
└─ Valider roadmap
📊 Résumé: 6 Étapes
| Étape | Activité | Output | Temps |
|---|---|---|---|
| 1 | Lister éléments | Liste 15-25 items | 15 min |
| 2 | Dépendances | Graphique chaînes | 20 min |
| 3 | Axe X | Positions horizontales | 15 min |
| 4 | Axe Y | Positions verticales | 15 min |
| 5 | Mouvements | BUILD/BUY/PARTNER | 15 min |
| 6 | Interprétation | Stratégie & roadmap | 30 min |
| TOTAL | Carte complète | 110 min |
🏆 Points à Retenir
✅ ÉTAPE 1: Lister
- Exhaustif mais pas trop granulaire
- Éléments tangibles seulement
- Valider périmètre
✅ ÉTAPE 2: Dépendances
- Cartographier qui dépend de qui
- Identifier points critiques
- Visualiser chaînes
✅ ÉTAPE 3: Axe X
- Innovation gauche, commodité droite
- Validé avec team
- Clair différenciation?
✅ ÉTAPE 4: Axe Y
- Visible haut, invisible bas
- Utilisateur conscient?
- Dépendances verticales?
✅ ÉTAPE 5: Mouvements
- BUILD innovation + core
- BUY commodité
- PARTNER en transition
✅ ÉTAPE 6: Action
- Analyser carte
- Identifier risques
- Créer roadmap
- Articulate vision
📚 Prochaines Étapes
Vous pouvez maintenant construire votre carte! 🎉
Cas pratiques complets:
➡️ Cas Amazon (30 ans) →
➡️ Cas Netflix →
➡️ Cas E-commerce →
Guide facilitation:
Créé: 2025-11-17
Carte: 5/5 (Construction)
Niveau: Pratique
Durée: 30-40 minutes