Event Storming - l'atelier dynamique²

Event Storming - l'atelier dynamique²

C’est quoi ? Pourquoi faire ?

Event Storming est un atelier collaboratif, rapide et visuel, conçu pour rendre explicite la logique métier d’un domaine complexe. Inventé par Alberto Brandolini, il permet de mettre en commun connaissances, hypothèses et risques, et de transformer ce travail collectif en décisions actionnables.

C’est l’atelier idéal si votre équipe doit :

  • Clarifier un processus métier obscur ou dispersé.
  • Faire émerger un langage commun (Ubiquitous Language).
  • Définir frontières de contexte (Bounded Contexts) et premières pistes d’architecture.
  • Prioriser des chantiers produit ou techniques.

Pour en savoir plus sur les bonnes pratiques et le glossaire Event Storming, voyez le travail de la communauté DDD Crew : https://github.com/ddd-crew et en particulier leur cheat-sheet : https://github.com/ddd-crew/eventstorming-glossary-cheat-sheet. Le livre d’Alberto Brandolini reste la référence pour la méthode et l’esprit de l’atelier.

Ce que propose cet atelier (pitch pour l’équipe candidate)

  • Durée : atelier d’introduction 3 heures (format long possible : demi-journée ou journée pour un Big Picture complet).
  • Participants : 6–12 personnes recommandées — mélange d’experts métier, product, développeurs, facilitateur.
  • Rythme : alternance d’exploration rapide (collecte d’événements) et de synthèse (regroupement, identification de zones de complexité).
  • Matériel : paperboard / mur libre, rouleaux de papier, post-its colorés, feutres, marqueurs, et un facilitateur expérimenté.

Agenda type (3 heures)

  • 0:00–0:15 — Introduction & objectifs (quoi cherchons-nous ?)
  • 0:15–1:00 — Collecte d’événements métier (chaque participant colle des événements sur la timeline)
  • 1:00–1:30 — Regroupements et premières couleurs (hot spots, règles métier, lectures)
  • 1:30–2:00 — Identification des zones à risque / opportunités
  • 2:00–2:30 — Proposition d’artefacts techniques (agrégats, commandes, lectures) et premières idées d’API/séparations
  • 2:30–3:00 — Synthèse : décisions, backlog initial, actions & responsables

Méthode en bref

  • On travaille d’abord par événements (ce qui arrive dans le domaine), pas par écrans ou composants.
  • Les événements sont posés très vite, sans discussion prolongée. Le débat vient ensuite lors du regroupement.
  • On utilise des couleurs pour différencier : événements, commandes, lectures, règles métier, acteurs, problèmes.
  • Le facilitateur garde le tempo, fait émerger divergences, et cadre les décisions.

Sources & références utiles

Vous repartez (concrets)

  • Une carte d’événements (timeline) qui rend explicite le flux métier.
  • Les hotspots : zones de complexité, règles ambiguës, risques identifiés.
  • Un vocabulaire commun (Ubiquitous Language) partagé par l’équipe.
  • Des frontières de contexte proposées (premières idées de Bounded Contexts).
  • Un backlog priorisé de chantiers (clarifications, expérimentations, stories techniques).
  • Responsabilités et prochaines étapes (qui fait quoi, et quand).

Pour qui et quand lancer cet atelier ?

  • Quand vous sentez que les discussions tournent en rond et qu’il manque une vue partagée.
  • Avant une grosse refonte, une intégration ou un chantier impliquant plusieurs équipes.
  • Pour accélérer l’alignement entre produit, métier et engineering.

Intérêt immédiat

Event Storming transforme l’incertitude en cartographie actionnable. En quelques heures votre équipe obtient une vue partagée et des premières actions concrètes. Si vous voulez que j’organise une session pilote ou que je fournisse un template d’invitation, dites-le et je prépare tout.