Apprentissage

Philonomist propose ce dernier mois un test sur l’engagement. L’occasion pour moi

• d’approfondir cette notion à la mémoire de mes derniers accompagnements en coaching d’organisation,
• de me rappeler de la place accordée à l’engagement dans l’agilité, notamment en lien avec la valeur de courage, et la façon dont on définit et respecte les objectifs)
• de le relier à mes articles précédents
• de safisfaire ma curiosité (et rentabiliser mon abonnement) en revisitant le site Philonomist et (re)découvrant quelques articles toujours intéressants, par leur questionnement sur le monde de l’entreprise.
• enfin d’imaginer un atelier, selon mon inspiration du moment que je puisse sortir si l’occasion se présente.

Ceci écrit, voilà déjà une forme d’engagement que d’établir une liste d’actions et de critères qui font sens pour obtenir un résultat.

Cet article vient à la fois illustrer la démarche de “Continuous Discovery” et se poser comme la finalité de cette série pour un cas d’usage concret et actuel d’une interne en médecine.

PROMPT

un article d’exemple de mise en oeuvre dans une démarche de recherche / thèse sur les opportunités d’usage de l’IA générative pour les internes en médecine, qui doivent à la fois parfaire leur apprentissage savoir/savoir-faire auprès des séniors ou autres agents vivants/institutions ou d’IA, pour le mettre en pratique opérationnelle auprès de leurs patients, et se maintenir eux-mêmes en bonne santé, sans trop subir la pression, la fatigue, etc… L’article doit démontrer comment cadrer/cibler une problématique, et fouiller les opportunités, réaliser des interviews de parties prenantes, se focaliser sur la valeur à produire pour les pp et les intéressés en tant que médecin interne.

Cette section vise à parcourir des concepts, pratiques et réflexions sur l’agilité avec quelques thèmes de classement. Pour préciser ce que j’entends par agilité, vous pouvez éventuellement commencer par un à propos d’agilité

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

Cet article est inspiré par les conversations sur les fondamentaux et principes de l’organisation du travail que nous questionnons dans l’exercice de la fresque de l’agilité.

La question ici est de savoir si le pragmatisme est à la bonne place pour discuter de l’organisation des personnes en permettant de dépasser dans le management traditionnel ou moderne, les principes et les limites de la division du travail.

Nous entendons par management moderne, celui qui a pu incorporer une forme d’agilité avec les mêmes intentions que celles du management traditionnel.

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 :

1. Introduire le concept des Product Bets et leurs bénéfices
2. Identifier collectivement les opportunités métier réelles
3. Construire collaborativement les cartes de chaque pari (hypothèses, risques, ressources, métriques)
4. Confronter les idées à travers des challenges croisés entre équipes
5. Prioriser visuellement les paris selon leur valeur estimée vs. leur risque
6. 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 :

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 :

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.