Les objectifs de l'Event Storming
L'Event Storming permet de collecter les informations d'un processus et de comprendre ce qu'il faut implémenter. Cette méthode est particulièrement utile quand les connaissances sont fragmentées entre différentes équipes ou départements et qu'il est très difficile d'avoir une vue d'ensemble. J'ai trouvé que rassembler tout le monde quelques heures permet d'éclaircir une situation bien plus rapidement. C'est un vrai gain de temps par rapport aux réunions dispersées ou au "ping-pong" d'emails interminables. Une fois les processus clarifiés, il est plus simple de rationnaliser et simplifier les flux de travail et de l'analyser en vue de l'implémentation : c'est très efficace !
Pourquoi faire un atelier Event Storming ?
Parce qu'à un moment donné, c'est tellement compliqué qu'on ne s'y retrouve plus, ou parce que c'est tellement vieux qu'on ne sait plus pourquoi ça a été fait comme ça, ou finalement ce n'est qu'en ayant cinq personnes d'équipes ou de personnes différentes que l'on peut comprendre un processus. Et ça : c'est le mal !
L'Event Storming permet d'explorer et de comprendre un domaine métier complexe en réunissant différents profils autour d'une activité collaborative. L'objectif principal est de d'extraire une vision partagée et complète du processus métier, depuis une vue d'ensemble jusqu'aux détails d'implémentation.
Une approche progressive en trois niveaux
La méthode se déroule en plusieurs étapes itératives, chacune avec ses propres objectifs :
1. Big Picture Event Storming : Comprendre le domaine dans son ensemble
- Identifier les événements métier majeurs
- Repérer les acteurs impliqués
À cette étape, les profils métier apportent vraiment de la valeur. C'est leur connaissance de la logique métier qui fait émerger les vrais processus, pas ceux qu'on croit qui existent. À ce stade, les questions techniques peuvent attendre, on cherche surtout à comprendre "quoi" et "pourquoi" avec des gens qui vivent le métier au quotidien.
2. Process Modeling : Affiner les processus critiques
- Visualiser les enchaînements d'événements
- Identifier les commandes (actions) qui déclenchent les événements
- Clarifier les interactions entre acteurs et systèmes
C'est ici que la vision transversale des architectes est importante. Leurs questions font ressortir les dépendances entre domaines et les contraintes d'intégration que le métier seul ne verrait pas. On reste néanmoins focalisé sur le métier, mais on commence à intégrer les aspects techniques pour préparer la suite.
3. Design Level : Définir les périmètres techniques
- Identifier les agrégats et modèles de données
- Définir les bounded contexts (périmètres fonctionnels)
- Préciser les responsabilités de chaque système
À cette étape, les profils techniques deviennent essentiels. Ils posent les questions précises qui font ressortir les détails cachés auxquels le métier doit répondre. Le métier peut rester pour valider, mais ce sont les décisions techniques qui dominent.
J'ai pu remarquer qu'à ce stade, il est essentiel d'avoir un interlocuteur métier ayant des dispositions techniques pour bien comprendre les questions et y répondre. Si vous n'avez pas ce type de profil dans l'équipe métier, essayez d'ajouter un analyste fonctionnel.
Les bénéfices concrets
Au-delà de la modélisation, l'Event Storming apporte :
- Un langage commun : tous les participants s'accordent sur les termes métier (ubiquitous language)
- Une meilleure collaboration : les silos entre équipes se brisent naturellement
- Une vision systémique : les dépendances et interactions deviennent visibles
- Des décisions éclairées : les problèmes cachés et opportunités émergent rapidement
Et surtout, c'est un gain de temps énorme comparé aux approches traditionnelles. En quelques heures, on peut obtenir une compréhension qui aurait pris des jours ou semaines en réunions classiques.
On peut alors utiliser le résultat de l'atelier pour commencer à formaliser une analyse, créer un backlog produit, ou même directement démarrer la conception technique.
Ce que l'Event Storming n'est pas
L'Event Storming n'est pas une méthode de modélisation de processus métier classique telle que le BPMN. La méthodologie offre une approche visuelle et collaborative, sans viser un standard formel.
Le livrable n'est pas une analyse prête à l'emploi : le résultat d'un atelier (mur de Post-its, photos, notes) ne peut pas être directement intégré dans un document d'analyse ou une spécification technique. Il nécessite une phase de consolidation et de formalisation pour transformer les insights collectifs en documentation exploitable. L'atelier produit avant tout une compréhension partagée qui doit ensuite être structurée dans une analyse ou dans un backlog selon les besoins du projet.
Produire une analyse formelle à partir d'un atelier Event Storming demande beaucoup de temps et d'efforts. En outre, il faut attendre la fin de l'écriture du document complet avant de pouvoir commencer l'implémentation. Une manière de pouvoir réduire ce temps est d'ajouter les informations dans un backlog, puis de les détailler progressivement en fonction des priorités du projet. De cette manière, on évite une perte de temps due au formalisme excessif et l'attente d'une documentation parfaite avant de commencer le travail de développement.