Le savoir invisible de votre organisation

Posez cette question à votre équipe : "comment se passe exactement le processus de validation d'un devis chez nous ?". Vous obtiendrez probablement autant de réponses que de personnes interrogées. Le commercial vous parlera de sa hiérarchie d'approbation, l'économiste de la validation métré, le responsable administratif du contrôle RIB, la comptabilité du plafond de crédit.

Chacun dit vrai. Chacun ne voit qu'un morceau. Les processus réels sont dans les têtes des gens, pas dans les procédures écrites. Ils ont été construits par sédimentation au fil des années, des exceptions, des clients particuliers, des bugs contournés. Aucun document ne les décrit entièrement. Et pourtant, c'est exactement cette réalité-là qu'il faut modéliser pour construire une application qui marche.

L'Event Storming, c'est quoi exactement

L'Event Storming est une méthode d'atelier collaboratif inventée par Alberto Brandolini en 2013. Le principe est d'une simplicité radicale : on colle des post-its sur un très long mur (ou un outil numérique type Miro/Mural). Chaque post-it orange représente un événement métier qui s'est produit au passé ("devis envoyé", "paiement reçu", "lot attribué"). On remplit le mur, collectivement, jusqu'à reconstituer le processus complet.

Les règles sont simples : pas de hiérarchie dans la salle, tout le monde peut coller un post-it, on ne juge pas, on ne débat pas tout de suite. L'important est d'abord d'obtenir une carte exhaustive. Ensuite on ajoute des post-its roses (les commandes qui déclenchent les événements), bleus (les acteurs), jaunes (les règles métier), rouges (les points de douleur).

Pour le décideur : L'Event Storming, c'est 2 à 4 heures d'atelier qui remplacent des semaines de cahier des charges. Et surtout, qui révèlent ce que le cahier des charges aurait oublié.

Pourquoi c'est différent d'un cahier des charges

Un cahier des charges décrit ce que l'application devrait faire, en langage normatif. Il oublie systématiquement les exceptions, les hacks, les "oui mais", les cas limites que l'équipe gère depuis des années sans y penser. L'Event Storming cartographie ce qui se passe vraiment, au quotidien, y compris les zones grises.

Exemple BTP concret
En réunion classique : "Le client valide le devis, puis on lance le chantier."

En Event Storming : "Le client valide le devis, MAIS parfois il demande une modification mineure, ET parfois le commercial accorde une remise sans validation, OR il arrive que le chef de projet ajoute un lot oublié avant signature, ET dans 15% des cas il faut refaire un devis rectificatif après démarrage..."

Le second scénario est le vrai. Le premier, c'est une fiction utile pour les slides, mais une catastrophe pour qui code l'application.

Les 3 niveaux d'Event Storming

Big Picture

Une vue d'ensemble du parcours client ou de la chaîne de valeur. 2 à 3 heures, 15-20 participants, tous métiers confondus. L'objectif : avoir une compréhension partagée de bout en bout.

Process Modeling

Un zoom sur un sous-processus précis (par exemple "la validation d'un DPGF" ou "le décompte général définitif"). 3 à 4 heures, équipe plus restreinte, focus sur les règles métier et les règles de gestion.

Software Design

Le dernier niveau, celui qui prépare le code. On identifie les agrégats (au sens DDD), les bounded contexts, les services. 4 à 6 heures, équipe mixte métier/tech. C'est ici que la carte devient architecture.

Les outils nécessaires

  • Un mur long (6-10 mètres) ou un tableau Miro/Mural en distanciel
  • Des post-its orange, rose, bleu, jaune, rouge (ou leurs équivalents numériques)
  • Un facilitateur formé (crucial : un mauvais facilitateur peut transformer l'atelier en réunion stérile)
  • 2 à 4 heures de calendrier bloqué sans interruptions

Ce que vous en retirez concrètement

Une vision partagée

Toute votre équipe voit le même processus de la même façon. Les non-dits deviennent explicites. Les désaccords entre services émergent au grand jour et se résolvent dans la salle, pas 6 mois plus tard en prod.

Les vrais besoins

On découvre des besoins dont personne n'avait parlé parce que "tout le monde sait". Ce sont typiquement ces besoins oubliés qui font échouer les projets applicatifs classiques.

Un socle solide

La carte devient la fondation de l'architecture applicative. On peut directement identifier les bounded contexts, les services, les événements métier à implémenter. Le passage du métier au code est fluide.

Une documentation vivante

Le résultat de l'atelier (photo du mur, export Miro) devient une documentation de référence du métier. Utile pour l'onboarding, les évolutions, les audits.

Retour d'expérience sur un projet BTP

Sur un projet d'application pour un bureau d'études structure, nous avons animé 6 sessions d'Event Storming en 3 semaines. Résultat : 12 bounded contexts identifiés, 80 événements métier formalisés, 5 règles métier critiques découvertes que personne n'avait pensé à documenter. Temps gagné sur la phase de conception : estimé à 4 mois. Bug de spécification en production : zéro sur les 12 premiers mois.

En résumé : L'Event Storming est l'outil le plus rentable pour démarrer un projet applicatif métier. Il transforme le savoir tacite en modèle explicite, réduit drastiquement les risques projet, et produit une carte directement exploitable par l'équipe tech.