Repenser la conception logicielle à l’ère de l’IA avec Event Modeling, Event Sourcing et Slice Architecture
Les pratiques de développement logiciel évoluent. Du moins… elles auraient dû évoluer.
Existe-t-il des alternatives à la traditionnelle spécification remplie de user stories ?
Des approches plus simples, plus efficaces, plus engageantes ?
Et est-ce que certaines pratiques sont plus avantageuses pour mieux exploiter l’efficience que l’IA promet?
Les métiers aiment les histoires — et les systèmes aussi
Les humains aiment les histoires.
Elles captivent, simplifient, rendent les concepts concrets, et surtout, elles déclenchent de bonnes questions.
On s’en souvient, car une histoire a un début, un déroulement, une fin et des détails qui marquent.
Les métiers aussi aiment raconter leurs histoires. Chaque processus métier est une histoire structurée par des faits qui s’enchaînent dans le temps :
“Un client entre dans le magasin, choisit un produit, passe à la caisse, paie, puis quitte le magasin.”
C’est exactement ce que fait l’Event Modeling : représenter visuellement ces histoires, avec les métiers, pour en déduire la structure du système d’information.
Event Modeling : un outil simple pour raconter et visualiser les histoires métiers
L’Event Modeling frappe par sa simplicité :
Cette approche de modélisation permet de parcourir, visualiser, comprendre et explorer les histoires “métier” autour d’un système d’information en s’appuyant sur seulement 5 éléments organisés en 4 patterns:
Illustration : faisons un espresso
Pour comprendre les 5 éléments et les 4 patterns, prenons une histoire simple :
Histoire métier
“Faire un espresso et lever une alerte pour alimenter le réservoir à café.”
3 systèmes:
- Le Système d’Information permettant de commander son espresso,
- La machine mécanique qui fait l’espresso,
- Le réservoir à grain: un troisième système.
La raison de cet exemple est qu’il illustre parfaitement les patterns d’ “Event Modeling”. Ceci devrait vous permettre plus facilement d’appréhender des systèmes d’information plus beaucoup plus riches.
- L’utilisateur sélectionne un espresso
- La machine prépare l’espresso.
- Une alerte indique ensuite que le conteneur à grains est vide.
Mais… il manque des éléments importants :
- Comment la machine sait-elle qu’elle doit préparer un espresso ?
- Comment l’alerte du conteneur passe-t-elle dans le Système d’Information ?
C’est là que l’Event Modeling devient puissant: cette approche permet d’articuler chaque pas* de l^histoire:
*J’utilise le mot « pas » pour illustrer le fait que nous cherchons à articuler l’histoire métier.
Event Modeling - un modèle construit avec les métiers !
L’event modeling raconte le flux d'information, sans aucun place à l'imagination
- L’utilisateur choisit un espresso via un écran. Un événement est publié : “Espresso Commandé”.
- Le système liste les espressos à préparer (projection).
- La machine reçoit cette liste et prépare l’espresso.
Elle publie l’événement : “Espresso Préparé”. - Le système d’information annonce qu’un espresso est prêt.
- Le conteneur à grains émet une alerte “plus de café”. C’est un système externe.
Le SI la traduit en événement interne : “Conteneur Vide” (avec un code d’erreur).
→ Si le fournisseur change, seule la traduction change ; l’événement métier reste stable. - Une interface de maintenance remonte l’alerte.
Nous avons ainsi utilisé l’ensemble des 5 éléments et des 4 patterns d’Event Modeling.
Ci-dessous les patterns sont réalisés via – ce que nous appelons – des slices, 6 au total.
Une histoire est un enchaînement de "pas": les slices
Event Modeling s'appuie sur BDD
Pour chaque slice, des tests BDD – Behaviour Driven Development – sont ajoutés. C’est la spécification par l’exemple !
Un bénéfice d’Event Modeling est que les tests BDD sont par slice et donc le nombre de tests à définir reste limité par slice: moindre charge cognitive que d’écrire des tests BDD pour des user stories qui couvrent plusieurs cas.
Exemples de tests BDD:
Les slices : nouvelle unité de progrès et d’implémentation
La mise en œuvre des 4 patterns se fait via les slices. Chaque slice est l’implémentation d’un des patterns.
Elles ont des caractéristiques clés :
- Ce sont des user stories enrichies (3C* + tests BDD Given/When/Then).
- Elles sont strictement limitées à une seule capabilité métier.
→ “Commander un espresso” ≠ “Commander un cappuccino” → 2 slices. - L’effort est maîtrisé : 1 à 3 jours chacune (si plus… vous avez sans doute plusieurs slices !)
- Si 100 slices sont identifiées, on peut estimer ~200 jours d’effort d’implémentation.
- Les slices sont compréhensibles par les métiers (contrairement aux story points).
- Elles sont indépendantes par design.
*3C: Carte , Conversations, et Confirmation
Quand l’IA entre en scène: contexte plus que prompt
Event Modeling ne donne aucune direction sur les choix d’architecture: Event Modeling est purement métier. C’est ensuite que vous décidez de votre architecture.
Prenons le cas du choix de développement spécifique pour notre solution.
L’IA devient extrêmement efficace lorsqu’elle dispose d’un contexte précis. L’IA n’est pas une machine à prompt, c’est une machine à contexte. Et ce contexte, elle l’a et nous allons contraindre l’IA à penser en slices donc réduire son contexte à la slice.
Grâce à l’Event Modeling, et les slices, l’IA comprend le contexte de chaque slice:
- Event Modeling : raconter, visualiser et structurer les histoires “métier” slice par slice
- Chaque slice est une pas : unité atomique, claire et testable.
- Chaque slice devient un répertoire dans le code, reflétant le modèle.
- Event Sourcing garantit cohérence, audit et évolutivité* et chaque événement donne du contexte
- Les tests BDD confirment la compréhension du contexte de la slice
L’IA travaille dans le contexte d’une slice et devient puissance car contrainte sur un petit périmètre et avec un contexte claire et détaillée
Archictecture logicielle: réduire le contexte de l'IA avec Vertical Base Architecture
Pour chaque slice du modèle :
- Nous créons une slice dans le code (un répertoire autonome) → vertical architecture
Exemples de structure du code:
- slices/
- CommanderEspresso
- ProjectionListeDesEspressosAPréparer
- MarquerEspressoPréparé
- ProjectionListeDesEspressosPréparées
- TraduireAlertePlusDeCafé
- ProjectionListeDesAlertes
- SharedServices/
- EspressoMaker
- SystèmeExterne_A
Idéalement, une slice contient tout le code nécessaire à son indépendance, incluant une partie du code front.
Ainsi, l’IA peut générer, maintenir et faire évoluer le code slice par slice, dans un contexte parfaitement maîtrisé.
→ Une architecture verticale est, par design, évolutive et très adaptée à l’IA.
Enrichir le contexte avec les événements: Event Sourcing
Les événements du modèle (les stickers oranges) et les modèles de lecture (verts) vont devenir respectivement notre base de « données » opérationnelles et analytiques. Nous gardons la notion d’événements utilisée au niveau le modèle dans l’implémentation.
Au lieu des données « Client » et « Nom », event sourcing gère, non pas des états, mais les événements – suite de faits – permettant de reconstituer l’état: { « ClientCréé », « nom »: « Durant »; « id »: « 0x123 »; « date »: 08.12.2025.15.36.57.145 }.
S’ajoutent de nouveaux patterns que nous pouvons utiliser e.g. le “ToDo list” pattern pour les workflows et “Git” pattern pour le versioning si vous utilisez une approche “event sourcing”:
Event Sourcing est une approche différente et, si au abord peut paraître compliquée et faire peur, est relativement simple. Il n’y a plus de modèles de données (!) et il est facile de faire évoluer un système d’information. “Le versioning d’événements est difficile” est une légende urbaine: au pire, recopier des streams reste une option pour avoir des streams avec une seule version (sachant que le versioning n’est pas obligatoire).
En résumé
- Event Modeling : raconter, visualiser et structurer les histoires “métier”.
- Chaque pas devient une slice : unité atomique, claire et testable.
- Chaque slice devient un répertoire dans le code, reflétant le modèle.
- Event Sourcing garantit cohérence, audit et évolutivité*.
- L’IA est restraint au contexte apporter par la slice (slice métier avec les tests BDD, fichiers et événement)
* Évitant tout débat, j’utilise le terme Event Sourcing même si j’inclue l’approche Eventz (functional programming avec des fonctions pures). Il peut se trouver qu’Event Sourcing soit associé avec des bases de données spécifiques de type “EventStore” alors qu’Eventz a juste besoin de bases de données classiques tel que Postgres. Le monde change très vite (à tel point que la notion même d’agrégat est remise en cause).
Les bénéfices
- Diviser par 2 sur les coûts d’implémentation*, plus pour les coûts de maintenance ;
- Forte réduction des risques de dérive budgétaire et planning ;
- Architecture stable, claire, évolutive ;
- Transparence totale pour les métiers (souvent demandée, rarement obtenue).
- Et sans doute le point le plus fort, c’est une première version de votre produit deux semaines après avoir modélisé votre première histoire: simple, choquant, puissant !
* De mon expérience. C’est un chiffre pessimiste quand je discute avec les experts. Au vu des projets qui “échouent”, Event Modeling vous permet de bien mieux réussir vos projets.
A ce jour, je n’ai pas encore trouvé d’exemples de systèmes d’information (solutions “web”) dont la construction n’aurait pas bénéficié d’Event Modeling, ayant travaillé dans plusieurs domaines de l’industrie.
Références
eventmodeling.ch , site en français que je maintiens
Understanding Event Sourcing and Event Modeling , excellent livre par Martin Dilger
Adaptech.com travaille depuis plus de 10 ans avec Event Modeling et Adam Dymitruk – créateur de l’approche – explique amplement les bénéfices d’Event Modeling (Dr. Melvin E. Conway – la fameuse loi de Conway – est advisor à Adaptech).
EventModeling.org: site dédié à l’Event Modeling maintenu par Adam Dymitruk
Vertical Slice Architecture par Jimmy Bogard
Event Sourcing par by Greg Young
Exemple - Event Modeling avec Miro:
