Notre voyage vers l'Event Sourcing
Comment nous avons migré une partie critique de notre infrastructure de comptabilité vers l'Event Sourcing pour gagner en auditabilité et en résilience.
Pourquoi changer ?
La comptabilité est un domaine où l'immuabilité des données est primordiale. Modifier une transaction a posteriori sans trace d'audit crée des risques légaux et techniques.
Notre modèle initial — une table SQL avec des enregistrements mutables — atteignait ses limites face aux exigences de nos experts-comptables partenaires.
Qu'est-ce que l'Event Sourcing ?
Au lieu de stocker l'état courant d'un objet, on stocke la liste des événements qui l'ont amené à cet état.
# Avant : mutation directe
transaction.update!(amount: 150.0, category: :expense)
# Après : événement immuable
EventStore.append(
stream: "transaction-#{id}",
event: TransactionCategorized.new(amount: 150.0, category: :expense)
)
L'état courant se reconstruit en rejouant les événements.
Ce qu'on a gagné
- Auditabilité totale : chaque modification est tracée avec timestamp et acteur
- Time travel : on peut reconstituer l'état à n'importe quel instant
- Debugging facilité : le stream d'événements raconte l'histoire complète
- RGPD : suppression logique sans impact sur l'intégrité comptable
Les difficultés rencontrées
Performance
Reconstruire l'état en rejouant 5000 événements à chaque lecture est prohibitif. On a implémenté des snapshots périodiques pour garder les performances.
Complexité opérationnelle
La migration progressive (CQRS + double écriture) a nécessité 6 semaines de travail et de nombreux tests de régression.
Formation de l'équipe
Penser en événements plutôt qu'en état est un changement de paradigme non trivial.
Bilan après 6 mois
L'Event Sourcing est aujourd'hui en production sur notre module de transactions. Le retour des équipes produit et support est unanime : la traçabilité a considérablement réduit le temps de résolution des anomalies comptables.
Le prochain chantier : étendre le modèle aux déclarations fiscales.