L’event sourcing est utile quand l’historique métier vaut autant que l’état actuel. Au lieu d’écraser les données, on garde chaque événement. Ça change l’audit, la traçabilité, l’IA, mais aussi la complexité technique. Je vous explique où ça brille, et où ça coûte.
C’est quoi l’event sourcing ?
L’event sourcing, je le résume comme ça : au lieu de garder uniquement la photo actuelle d’une donnée, je garde le film complet de ce qui lui est arrivé.
Dans une approche CRUD classique, CRUD veut dire Create, Read, Update, Delete, donc créer, lire, modifier, supprimer. On stocke surtout l’état courant. Prenez un compte bancaire. En CRUD, la base contient souvent une ligne avec le solde actuel, par exemple 1 250 €. Quand un dépôt arrive, on met à jour ce solde. Quand un retrait arrive, on le met encore à jour.
Avec l’event sourcing, je ne considère pas le solde comme la source de vérité. Je stocke les événements métier dans l’ordre : dépôt de 500 €, retrait de 100 €, dépôt de 850 €. Le solde devient une conséquence de cet historique. Je peux le recalculer à partir des événements.
| Approche CRUD | Event sourcing |
| Je stocke le solde actuel du compte. | Je stocke les dépôts, retraits et ajustements. |
| La donnée principale est l’état courant. | La donnée principale est l’historique des événements. |
| Une modification remplace souvent l’ancienne valeur. | Un nouvel événement est ajouté à la suite. |
Le point clé, c’est le côté append-only. Ça veut dire qu’on ajoute des événements, on ne modifie pas les anciens. Si une erreur arrive, je n’efface pas discrètement l’événement. J’ajoute un événement de correction. Ça change pas mal la manière de penser.
Ce modèle crée une trace complète. Je peux comprendre ce qui s’est passé, reconstruire l’état d’un compte à une date précise, auditer une décision, ou alimenter des analyses. Dans certains projets, c’est précieux. J’ai déjà vu des équipes passer des jours à deviner pourquoi un statut avait changé. Avec un bon historique d’événements, la réponse est souvent là, dans la chronologie.
Mais je préfère être clair : ce pattern n’est pas magique. Il ajoute de la complexité. Il faut gérer l’ordre des événements, leur version, leur lecture, parfois des projections pour afficher les données simplement. Pour une application simple, avec peu d’historique métier et aucun besoin fort d’audit, un bon modèle CRUD reste largement suffisant.
Quels sont les composants clés ?
Dans un système en event sourcing, je ne pense pas d’abord en “état actuel”. Je pense en “ce qui s’est passé”. C’est un petit changement mental, mais il change presque tout dans la manière de stocker, relire et exploiter la donnée métier.
Le cycle commence avec les event objects. Ce sont des objets qui décrivent une action passée, jamais une intention vague. Par exemple SubscriptionCreated, PlanUpgraded ou SubscriptionCanceled. Un événement dit “ça a eu lieu”. Il est immuable, donc on ne le modifie pas après coup. Il contient les données nécessaires pour comprendre l’action : l’identifiant de l’abonnement, le plan choisi, la date, parfois l’utilisateur ou la raison de l’annulation. Chez un client SaaS, ce détail a évité pas mal de débats, parce qu’on pouvait retrouver exactement pourquoi un abonnement avait changé de formule.
Ces événements sont ensuite écrits dans l’event store. C’est le journal officiel du système. Il conserve les événements dans des flux ordonnés, souvent par entité ou par agrégat. Un agrégat, c’est juste un groupe cohérent de données métier, comme un abonnement, une commande ou un compte client. Ici, on ajoute des enregistrements au lieu de modifier des lignes existantes. L’event store peut aussi alimenter des consommateurs downstream, c’est-à-dire d’autres systèmes qui réagissent aux événements, via des brokers ou des streams comme Kafka, RabbitMQ ou des services cloud équivalents.
Quand on veut retrouver un état, on fait de la state reconstruction. On rejoue les événements dans l’ordre. On peut reconstruire l’état présent, ou même l’état à une date passée. C’est très fort pour l’audit, les litiges, l’analyse historique. Mais il faut rester lucide : rejouer trop souvent une longue suite d’événements peut coûter cher en temps de calcul.
Pour lire vite, on crée des projections. Ce sont des vues matérialisées adaptées aux requêtes métier : commandes en attente, abonnements actifs, produits en rupture. On peut avoir plusieurs modèles de lecture sans changer le modèle d’écriture. On est souvent proche d’une logique CQRS, où l’écriture et la lecture sont séparées pour mieux servir chaque usage.
Les snapshots viennent alléger tout ça. Ils capturent l’état d’un agrégat à un moment donné, pour éviter de rejouer toute l’histoire à chaque reconstruction. Le principe suffit déjà à comprendre leur intérêt : on repart d’un point connu, puis on rejoue seulement les événements suivants.
| Composant | Rôle | Point d’attention |
| Event objects | Décrivent les actions passées de façon immuable. | Ils doivent contenir assez de contexte pour être compris plus tard. |
| Event store | Stocke les événements dans des flux ordonnés. | On ajoute des événements, on ne modifie pas l’historique. |
| State reconstruction | Rejoue les événements pour retrouver un état. | Le coût augmente si les flux deviennent très longs. |
| Projections | Préparent des vues optimisées pour les lectures métier. | Elles doivent rester synchronisées avec les événements. |
| Snapshots | Capturent un état intermédiaire pour accélérer la reconstruction. | Ils simplifient la lecture, sans remplacer l’historique. |
Pourquoi ce pattern est puissant ?
L’event sourcing est puissant parce qu’il garde le film complet, pas seulement la photo finale. Au lieu d’avoir uniquement “le compte est à 120 €” ou “l’abonnement est suspendu”, on garde chaque événement métier qui a mené à cette situation.
Le premier bénéfice, c’est l’audit complet. Chaque action importante laisse une trace : paiement reçu, remise appliquée, adresse modifiée, compte bloqué, validation manuelle, annulation, relance envoyée. Quand il y a une erreur, un litige ou une décision bizarre à expliquer, on ne fouille pas dans trois exports Excel en espérant retrouver un indice. On relit l’historique.
Ça change beaucoup de choses côté métier :
- Comprendre une erreur : On voit l’action exacte qui a déclenché le mauvais état.
- Gérer un litige : On peut prouver ce qui s’est passé, dans quel ordre, et à quel moment.
- Expliquer une décision : On retrouve les événements qui ont amené le système ou un utilisateur à choisir une option.
- Suivre un changement d’état : On sait pourquoi un client est passé de “actif” à “suspendu”, puis à “résilié”.
Le deuxième bénéfice, c’est la reconstruction d’états passés. On peut rejouer l’historique jusqu’à une date ou jusqu’à un événement précis. Prenons un compte bancaire. Si le solde actuel est de 120 €, je peux rejouer tous les dépôts, retraits, frais et remboursements pour savoir pourquoi ce solde existe. Je peux aussi demander : “Quel était le solde le 12 mars à 14h ?” Et là, je ne devine pas. Je reconstruis.
Même logique avec un abonnement. Si un client se plaint d’avoir été coupé à tort, on peut voir qu’il y a eu un échec de paiement, puis deux relances, puis une suspension automatique, puis une réactivation manuelle. On comprend la trajectoire, pas juste l’état final.
Pour l’IA et l’analyse, c’est intéressant aussi, mais il faut rester sobre. L’event sourcing ne rend pas une IA magique. Par contre, des historiques détaillés donnent une matière plus riche pour analyser des comportements, détecter des patterns, expliquer une trajectoire client ou comprendre pourquoi certains cas dérivent.
Je le vois souvent dans les projets data et automatisation. Le problème, ce n’est pas toujours le manque de données. C’est l’absence de contexte sur la manière dont elles ont changé. Quand le métier doit comprendre le film, pas seulement la photo, l’event sourcing répond très bien à ce besoin.
Quels compromis faut-il accepter ?
L’event sourcing, je le vois comme un échange assez clair : on accepte plus de complexité pour gagner un historique fiable, rejouable et exploitable. Ce n’est pas un pattern magique. Si votre problème métier n’a pas besoin de comprendre précisément ce qui s’est passé, vous risquez surtout d’ajouter du poids à votre système.
Le premier coût, c’est le stockage. Garder tous les événements prend plus de place que stocker uniquement l’état courant. Une commande avec son statut actuel, c’est léger. Une commande avec tous ses changements, ses validations, ses erreurs, ses corrections et ses annulations, ça grossit vite. Mais ce coût peut être très acceptable si l’historique a une vraie valeur métier : audit, conformité, diagnostic, analyse comportementale, litiges client. Chez un client dans l’assurance, garder l’historique complet des décisions valait largement quelques gigas de plus. Ça évitait surtout des semaines de débats quand il fallait expliquer une décision passée.
Le deuxième coût, c’est la lecture des données. Les événements sont très bons pour écrire l’histoire. Ils le sont beaucoup moins pour répondre vite à des questions simples du quotidien : “Quel est le solde actuel ?”, “Combien de dossiers sont en attente ?”, “Quel est le statut de cette demande ?”. Pour ça, on construit des projections, c’est-à-dire des vues de lecture calculées à partir des événements. Elles doivent être pensées, versionnées et maintenues sérieusement.
Il faut aussi accepter un modèle de cohérence différent. Selon l’architecture, les vues de lecture peuvent être mises à jour avec un léger délai. L’événement est bien enregistré, mais la projection n’est pas encore alignée. On parle souvent de cohérence éventuelle : le système converge vers le bon état, mais pas forcément à la milliseconde. L’équipe doit comprendre ça, sinon les bugs imaginaires vont pleuvoir.
Dernier point souvent sous-estimé : le replay. Rejouer trop d’événements à chaque lecture peut coûter cher. On optimise avec du pré-calcul de valeurs, un cache court terme, ou des snapshots, c’est-à-dire des états intermédiaires sauvegardés pour éviter de repartir de zéro à chaque fois.
| Avantage | Contrepartie | Bonne pratique |
| Historique complet et fiable | Stockage plus important | Garder cet historique seulement s’il a une vraie valeur métier |
| Traçabilité forte | Requêtes métier plus complexes | Construire des projections adaptées aux usages de lecture |
| Reconstruction possible des vues | Cohérence pas toujours instantanée | Former l’équipe au modèle de cohérence éventuelle |
| Analyse fine du passé | Replay potentiellement coûteux | Utiliser pré-calcul, cache court terme et snapshots |
Quand faut-il vraiment l’utiliser ?
J’utilise l’event sourcing quand l’historique métier vaut vraiment quelque chose. Pas juste “on garde des logs au cas où”. Je parle d’un historique qui aide à auditer, expliquer, reconstruire, rejouer, comprendre pourquoi un état existe aujourd’hui.
| Situation | Décision |
| Vous devez prouver chaque changement, qui a fait quoi, quand, et pourquoi. | L’event sourcing devient pertinent. |
| Vous gérez de la finance, des paiements, des abonnements, des commandes ou des workflows métier sensibles. | Le pattern peut apporter une vraie valeur. |
| Vous avez juste besoin d’un écran admin avec création, modification, suppression. | Je resterais sur du CRUD classique. |
| L’équipe n’est pas à l’aise avec les projections, les replays et la cohérence éventuelle. | Je l’éviterais, au moins au départ. |
Le bon signal, c’est quand les événements métier ont une valeur durable. “Commande validée”, “Paiement refusé”, “Abonnement suspendu”, “Contrat signé”, “Dossier approuvé”. Ce ne sont pas juste des changements techniques en base. Ce sont des faits métier. Et ces faits peuvent servir plus tard pour reconstruire l’état, alimenter un audit, corriger une projection, ou comprendre une décision.
À l’inverse, je l’éviterais sur un back-office classique avec des données peu critiques. Si l’historique ne sert presque jamais, si personne ne va relire les transitions, si le métier veut juste l’état actuel, l’event sourcing ajoute une charge inutile. Il faut maintenir un event store, c’est-à-dire une base qui stocke les événements. Il faut gérer les projections, donc des vues de lecture reconstruites à partir de ces événements. Il faut penser au replay, quand on rejoue l’historique pour recalculer un état. Ce n’est pas gratuit.
J’ai vu des équipes choisir ce pattern trop tôt, souvent parce que ça sonnait “architecture moderne”. Le problème, c’est que ça change tout. Le modèle métier devient centré sur les transitions. Les lectures sont souvent séparées des écritures. Les intégrations downstream, comme le CRM, la facturation ou les notifications, consomment parfois ces événements. Même l’organisation de l’équipe peut bouger, parce qu’il faut des gens capables de raisonner en flux, pas seulement en tables SQL.
Ma règle est simple. Si vous avez besoin de la photo, le CRUD suffit souvent. Si vous avez besoin du film complet, l’event sourcing devient intéressant.
Alors, vous avez besoin de la photo ou du film ?
L’event sourcing change la manière de penser la donnée. On ne stocke plus seulement l’état final, on garde l’histoire complète des changements. C’est très puissant pour l’audit, la traçabilité, la reconstruction d’états passés, les projections métier et certains usages data ou IA. Mais ça se paie : stockage, replay, cohérence, projections, exploitation. Je ne le choisirais pas par goût de l’architecture élégante. Je le choisirais quand l’historique a une vraie valeur business. Le bénéfice pour vous, c’est une donnée plus explicable, plus traçable, et souvent plus utile pour décider.
FAQ
- Quelle est la différence entre CRUD et event sourcing ?
CRUD stocke surtout l’état courant d’une donnée, par exemple le solde actuel d’un compte. L’event sourcing stocke les événements qui ont produit cet état, comme les dépôts et les retraits. L’état devient le résultat de l’historique. - Pourquoi l’event sourcing aide pour l’audit ?
Parce que chaque changement métier est conservé sous forme d’événement immuable. On peut donc retrouver ce qui s’est passé, dans quel ordre, et reconstruire un état passé. C’est beaucoup plus explicite qu’une donnée écrasée au fil du temps. - Les projections sont-elles obligatoires en event sourcing ?
Elles deviennent vite nécessaires. Les événements sont très bons pour écrire l’historique, mais pas toujours pratiques pour répondre aux requêtes métier courantes. Les projections créent des vues de lecture adaptées, par exemple les abonnements actifs ou les commandes en attente. - À quoi servent les snapshots ?
Les snapshots servent à capturer l’état d’un agrégat à un instant donné. Ils évitent de rejouer toute la suite d’événements à chaque reconstruction. C’est une optimisation utile quand un historique devient long et que le replay coûte trop cher. - Quand éviter l’event sourcing ?
Je l’éviterais quand l’historique n’a pas de vraie valeur métier, quand les requêtes sont simples, ou quand l’équipe n’a pas besoin d’audit détaillé. Pour un back-office classique ou une application CRUD basique, ce pattern peut ajouter plus de complexité que de valeur.
A propos de l’auteur
Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. J’accompagne des équipes qui veulent fiabiliser leurs données, mieux comprendre leurs parcours et automatiser sans bricoler. J’ai travaillé avec des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. Si vous voulez structurer vos données, vos événements ou vos automatisations proprement, contactez-moi.
⭐ Data Analyst, Analytics Engineer et expert dans l’automatisation IA ⭐
Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…
Mon terrain de jeu :
Data Analyst & Analytics engineering : tracking propre RGPD, entrepôt de données (GTM server, BigQuery…), modèles (dbt/Dataform), dashboards décisionnels (Looker, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, Make, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.