"Bon, les amis, on va faire un Event Storming !"
Les développeurs lèvent un sourcil : "un quoi ?"
Les managers paniquent : "Ça va encore finir en mur de post-it géant, nooooon !"
Pourtant, derrière son nom un peu ésotérique, l’Event Storming est l’un des ateliers les plus puissants pour comprendre, modéliser et améliorer un système complexe collectivement.
Pas besoin d’être architecte logiciel pour y participer. Il suffit de savoir raconter ce qui se passe dans la vraie vie et d’aimer les murs colorés, bien-sûr.
Cet article vous propose une explication claire et concrète de l’Event Storming.
On y verra d’où vient cette méthode, comment se déroule un atelier, étape par étape, à quoi servent les fameuses couleurs de post-its et surtout, pourquoi ça change profondément la manière de collaborer entre métiers et tech.
Quel est l’intérêt d’un event storming ?
Avant de parler de post-its, il faut comprendre pourquoi l’Event Storming existe.
Pendant des années, les équipes ont tenté de modéliser leurs systèmes via des diagrammes UML, des PowerPoints de 45 slides ou des documents de spécification écrits par des gens qui ne voyaient jamais le produit final.
Avec au final, beaucoup de malentendus, de rework, et de frustration.
Alberto Brandolini, le créateur de la méthode, est parti d’un constat simple :
"Ce n’est pas le code qui est compliqué. C’est ce qu’on croit savoir sur le métier qui l’est."
L’Event Storming est donc né pour rassembler tous les acteurs autour d’une vision partagée, sans outils complexes, sans jargon, juste avec beaucoup de post-its et un peu de cerveaux tout de même.
L’idée clé : raconter les événements du métier
Avant d’être un atelier, l’Event Storming est une façon de penser, car on ne modélise pas un système, mais on raconte une histoire.
Tout commence par la question magique : “Qu’est-ce qui se passe d’important dans votre système ?”
Ces événements racontent le film du système, du point de vue métier.
Le reste du travail consiste à comprendre comment et pourquoi ces événements arrivent.
Le déroulé d’un atelier Event Storming
Maintenant que nous savons quoi observer, voyons comment dérouler un atelier concret.
Étape 1 – Le Big Picture, la « tempête d’évènements »
Avant de réfléchir aux acteurs ou aux règles, il faut comprendre globalement le fonctionnement du domaine.
On réunit tout le monde (métier, tech, PO, QA, ops, support...) et on déroule les événements majeurs sur un grand mur, et ce, de manière chronologique.
Si le parcours arrive à une condition, il faudra partir sur une branche parallèle.
C’est la phase de découverte collective.
Dans ces moments d’échanges, la qualité des interactions humaines devient le véritable moteur de compréhension et de collaboration, bien avant les outils ou les post-its.
On ne cherche pas la perfection, mais la compréhension partagée.
Dans cette première étape, les "choses importantes" sont les événements du domaine, des faits passés, observables et pertinents pour le métier.
Un petit conseil pratique :
Commencez par définir le premier et le dernier évènement de votre domaine afin de poser le cadre. Il ne restera plus qu’à découvrir les événements entre les deux jalons.
En présentiel, des groupes vont se former devant le mur, échanger, partager et générer des événements.
Avec un outil électronique, c’est un peu moins fluide en termes d’échanges, mais quand on veut décaler un gros groupe de post-it, le lasso est juste magique.
Ce que vous verrez apparaître :
- Des zones floues ("ah bon, c’est à ce moment qu’on envoie la facture ?”),
- Des dépendances cachées,
- Des doublons dans les process,
- Du « jargon » non partagé entre les acteurs… Cela me rappelle un échange lors d’un Event Storming avec un post-it KYC qui est entré dans la tempête. Un développeur a alors demandé : "Mais que vient faire Keycloak dans notre domaine ?" Un business analyst a répondu, étonné : "Mais non, il s’agit de Know Your Customer." L’atelier leur a donc permis de s’aligner sur les éléments de langage.
- Et parfois… des non-sens logiques.
Exemples :
- "Commande validée"
- "Facture envoyée"
- "Utilisateur désinscrit"
- "Paiement refusé"
Chaque événement est noté sur un post-it orange.
Étape 2 – Les commandes
Une fois les événements identifiés, on se demande ensuite : "Quelle action l’a provoqué ?"
Cette étape relie les événements aux actions concrètes dans le système.
Chaque action ou intention est représentée par un post-it bleu : une commande.
Elle est définie par un verbe à l’infinitif accompagné de son contexte.
On commence à tracer la logique des interactions : "ce qui déclenche quoi".
Et on obtient une magnifique représentation chronologique du domaine.
Étape 3 – Les systèmes externes et les acteurs
Après avoir défini événements et commandes, il est temps de relier chaque événement à l’acteur ou au système qui le déclenche en se posant les questions :
- "Qui a déclenché cet événement ?"
- "Qu'est-ce qui a déclenché cet événement ?"
C’est le moment d’ajouter les systèmes tiers (en rose) et les acteurs humains (en jaune).
Cela permet de visualiser l’écosystème complet.
C’est là que les conversations les plus intéressantes émergent :
- "Et si le serveur bancaire ne répond pas ?"
- "Et si le client annule avant le paiement ?"
C’est ici que l’on relie l’humain ou le système à ce qu’il produit.
Ces questions deviennent la base de la conception, des tests et du backlog produit.
Un petit conseil pratique :
À ce stade, demandez à un valeureux narrateur de raconter l’histoire du domaine. Si tout le monde est OK, on peut passer à la suite, sinon on peut jouer les prolongations.
Nous pouvons nous arrêter à cette étape, car nous avons déjà réussi à modéliser tous les éléments du domaine et à établir les éléments de langage partagé ou "Ubiquitous Language".
Vous pouvez aussi utiliser le travail effectué pour alimenter un User Story Mapping afin de définir votre MVP et commencer à peupler votre backlog.
Mais comme vous êtes des puristes, nous allons aller au bout de l’exercice.
Pensez à sauvegarder votre travail si vous êtes sur un outil numérique (Miro, …), ou à prendre une photographie si vous travaillez avec des post-it, car nous allons tout chambouler.
Étape 4 – Les agrégats
Après avoir posé les événements, commandes et acteurs, nous cherchons à structurer les données et règles pour maintenir la cohérence du domaine.
Les agrégats sont des entités métiers qui regroupent les données et les règles.
Exemples :
- "Commande"
- "Facture"
- "Stock"
On matérialise un agrégat avec un post-it jaune clair.
Étape 5 – Les politiques ou process managers
Après avoir défini les agrégats, il faut identifier les décisions et règles métier qui influencent les événements.
On matérialise une règle du domaine avec un post-it violet.
On introduit ici les concepts de DDD (Domain-Driven Design) sans en avoir peur.
L’objectif est de repérer où se trouvent les décisions et les invariants du métier.
Étape 6 – Les Read Models
Il s’agit de vues utilisées pour interroger le système sans impacter les agrégats.
Les read models (vert) sont des projections ou rapports issus des événements. Ils permettent de visualiser les futurs écrans ou rapports métier.
C’est à ce moment que les Dev se disent : "Ah ! Mais ça commence à devenir bien concret ! Je commence même à visualiser l’application."
On matérialise un read model avec un post-it vert.
Étape 7 – Les Bounding Contexts
Après avoir défini agrégats, règles et read models, nous allons maintenant regrouper les éléments en sous-domaines cohérents.
Exemples :
- Gestion des commandes : Commande, Paiement, Client
- Gestion du stock : Article, Stock, Gestionnaire
À ce stade, il faut bien déplacer les éléments et les regrouper dans un ensemble visible grâce à un marqueur si vous êtes en physique ou avec un beau cadre dans votre outil numérique :
C’est à ce moment précis que la lumière se fait pour les Dev : "Tiens, mais ça ne serait pas un micro service, cette gestion des commandes ?"
Et effectivement, c’est à ce moment que la bascule du business vers la technique se fait en toute tranquillité.
Nous avons commencé par définir un domaine. Puis, nous l’avons découpé en agrégats, ensuite regroupé en sous-domaines qui contiennent à la fois les données et les traitements.
Ce qui nous donne un système complet, autonome avec ses propres responsabilités.
Or quelle est la définition d’un micro service ?
"L'architecture de micro services désigne un style d'architecture utilisé dans le développement d'applications. Elle permet de décomposer une application volumineuse en composants indépendants, chaque élément ayant ses propres responsabilités."
Et c’est exactement ce que nous avons fait en déroulant notre Event Storming.
Découper un système complexe en systèmes élémentaires ayant chacun leurs propres responsabilités.
Les codes couleurs de l’Event Storming
Pour éviter le mur monochrome illisible, chaque type d’élément a sa couleur.
Voici un rappel synthétique :
Les erreurs fréquentes à éviter
Parce que oui, on a tous un peu raté notre premier Event Storming :
- Beaucoup de monde d’un coup → Commencez petit. Une équipe. Un processus clé.
- Chercher à être exhaustif → Ce n’est pas un audit ISO, c’est une exploration. Partez sur un domaine restreint, voire découpez-le en sous-domaines et faites des Event Storming différents.
- Vouloir "finir" le mur → L’Event Storming est vivant. Il se complète au fil des discussions.
- Un atelier en roue libre → Le coach doit assurer la fluidité avec des transitions souples et un timeboxing rigoureux.
En pratique : l’atelier type
Pour ancrer les idées, voici une trame d’atelier simple et efficace, mais comptez tout de même près de 4 heures.
Étape | Durée indicative | Objectif principal |
|---|---|---|
Icebreaker et contexte | 10 min | Détendre et clarifier le but |
Collecte des événements | 45 min | Poser les faits métier |
Tri et séquençage | 10 min | Donner du sens et de l’ordre |
Ajout des commandes | 30 min | Comprendre le “pourquoi” |
Ajout des acteurs et systèmes | 30 min | Compléter la vue d’ensemble |
Identification des agrégats | 20 min | Structurer les données et règles pour la cohérence métier |
Définition des politiques | 20 min | Repérer les décisions et invariants métier |
Création des read models | 15 min | Préparer la visualisation et les projections métier |
Regroupement en Bounding Contexts | 20 min | Définir les sous-domaines et les limites du système |
Synthèse et apprentissages | 15 min | Identifier les insights et next steps |
Cas pratique : commande e-commerce
Imaginons un site e-commerce :
- Le client passe une commande → Commande passée
- Le système valide le paiement → Paiement validé
- Si le stock est suffisant → Expédier article
- Sinon → Notifier le gestionnaire pour réassort
Chaque action est visualisée par un post-it coloré et regroupée par Bounding Context, c’est-à-dire par sous-domaine métier partageant les mêmes règles et le même vocabulaire.
Cela rend le flux clair et permet de détecter immédiatement les points de friction et les zones critiques.
Voici l’Event Storming complet :
Conclusion
L’Event Storming n’est pas une religion, mais un langage commun visuel.
Il ne remplace pas la modélisation, mais la rend accessible et actionnable.
De l’événement au micro service, chaque étape construit une vision partagée et favorise la collaboration entre métiers et tech.
Alors, la prochaine fois qu’on vous propose un Event Storming, ne fuyez pas devant le mur orange.
Prenez un marqueur, racontez une histoire, et observez la magie de la compréhension partagée.
