Publié le 23 septembre 2026 à 13:00 · Publication originale
Cette information paraît suffisante.
Elle efface pourtant presque toute son histoire.
La commande a été créée à 9h12. Le paiement a été accepté. Le stock réservé. Un entrepôt l'a préparée. Le transporteur l'a prise en charge. Une première livraison a échoué. La seconde a réussi.
Une base traditionnelle peut conserver l'état actuel.
Une architecture événementielle conserve également les événements qui ont conduit à cet état.
Chaque événement décrit quelque chose qui s'est produit: "paiement accepté", "colis expédié", "client remboursé".
Des systèmes comme Apache Kafka organisent ces événements dans des journaux appelés topics.
Ils sont eux-mêmes divisés en partitions.
À l'intérieur d'une partition, chaque événement reçoit une position, appelée offset. Un consommateur peut lire jusqu'à l'offset 18.742, s'arrêter puis reprendre ensuite à 18.743.
Plusieurs applications peuvent ainsi observer le même flux indépendamment.
La comptabilité consomme l'événement de paiement. La logistique réagit à la réservation du stock. Un système de fraude analyse la transaction. Un agent d'IA peut recevoir l'événement et décider s'il doit intervenir.
L'émetteur n'a pas besoin de connaître tous ces consommateurs.
Cette séparation produit une propriété importante: ajouter demain un nouveau système ne nécessite pas forcément de modifier celui qui a créé l'événement.
Et puisque les événements restent conservés pendant une durée définie, un nouveau consommateur peut parfois rejouer le passé.
Une application déployée aujourd'hui peut donc reconstruire ce qui s'est produit hier.
L'entreprise ne possède plus uniquement des tables décrivant son état présent.
Elle possède progressivement une chronologie exploitable de son activité.
ULTRA®
Une partition Kafka ne garantit l'ordre qu'à l'intérieur de cette partition.
Ce détail décide de l'architecture.
Si tous les événements d'une même commande utilisent son identifiant comme clé, ils sont dirigés vers la même partition et conservent leur ordre relatif. Mais augmenter le nombre de partitions modifie la distribution et peut compliquer cette propriété.
Autre piège: un consommateur peut traiter un événement puis tomber avant d'enregistrer son nouvel offset. Au redémarrage, il peut recevoir le même événement une seconde fois.
L'événement "envoyer un courriel" crée alors deux courriels. "Débiter le compte" peut devenir beaucoup plus grave.
Conseil: concevoir les consommateurs comme idempotents et donner aux événements un identifiant stable permettant de reconnaître un traitement déjà effectué.
Dans une architecture événementielle, "au moins une fois" signifie qu'un système robuste doit considérer la répétition comme un comportement normal, pas comme une anomalie.