Event sourcing dans les systèmes de défense : pistes d'audit immuables pour les données militaires

Les systèmes d'information de défense DGA/EMA ont une exigence que les applications commerciales rencontrent rarement : chaque changement d'état dans le système doit être enregistré de manière permanente, inviolable et reproductible. L'analyse post-opérationnelle (compte-rendu d'action), la responsabilité juridique pour les engagements, les évaluations de la valeur renseignement des données collectées — tout cela exige un enregistrement faisant autorité et immuable de ce que le système savait et des décisions prises à chaque instant. L'event sourcing est le patron d'architecture qui fournit cela, et comprendre comment l'implémenter correctement dans les contextes de défense est l'objet de cet article.

Event sourcing vs CRUD : la différence fondamentale

Dans un système CRUD traditionnel (Create, Read, Update, Delete), l'état est stocké comme la valeur actuelle de chaque entité. Lorsqu'une position de piste est mise à jour, la position précédente est écrasée. Lorsqu'un SITREP est révisé, la version précédente peut ou non être conservée selon la conception de l'application. L'état du système à tout moment historique n'est pas intrinsèquement récupérable depuis la base de données — cela nécessite des choix de conception de versionnement explicites.

L'event sourcing inverse ce modèle. L'état n'est jamais stocké directement. Au lieu de cela, chaque changement d'état du système est stocké comme un événement — un enregistrement immuable en ajout seul. Le magasin d'événements contient : TrackPositionUpdated au temps T1 aux coordonnées X1 ; TrackPositionUpdated au temps T2 aux coordonnées X2 ; TrackIdentityAttributed au temps T3 à la désignation d'unité Y. L'état actuel d'une piste est toujours calculable en rejouant le flux d'événements depuis le début. Le magasin d'événements lui-même est un journal en ajout seul — aucun événement n'est jamais modifié ou supprimé.

La conséquence opérationnelle est que chaque version de chaque entité est toujours disponible. «Que savait le système sur cette piste à 14h23:07 ?» est répondable en rejouant les événements jusqu'à ce horodatage. Cette capacité est opérationnellement essentielle pour les systèmes DGA/EMA et essentiellement gratuite à implémenter si l'architecture est conçue pour cela dès le début.

Cas d'usage défense pour l'event sourcing

Historique SITREP : Les rapports de situation sont fréquemment révisés à mesure que de nouveaux renseignements arrivent. Dans un système CRUD, le SITREP actuel reflète la dernière évaluation mais l'historique de l'évolution de cette évaluation est perdu. Dans un système event-sourcé, chaque révision est un événement — SITREPCreated, SITREPRevised, SITREPApproved, SITREPDisseminated — et l'historique complet est toujours interrogeable. Après une opération, les analystes du renseignement peuvent reconstituer exactement ce qui était connu et quand, ce qui est essentiel pour l'évaluation des dommages de combat et l'amélioration des processus de renseignement de la Marine nationale et de l'armée de Terre.

Journal de mise à jour des pistes : L'historique cinématique de chaque piste dans le système — chaque mise à jour de position, chaque attribution d'identité, chaque changement de confiance — est la matière première pour l'analyse des modes de vie, la reconstruction des routes et l'analyse post-opérationnelle. L'event sourcing rend cet historique inhérent à l'architecture plutôt qu'un ajout. Un événement TrackUpdated contient l'état complet de la piste au moment de la mise à jour, la source de la mise à jour, l'analyste ou l'algorithme responsable, et l'état précédent remplacé.

Rejeu des décisions de commandement pour l'AAR : Un engagement impliquait une décision de tir au temps T basée sur l'état du système au temps T. L'AAR doit reconstituer l'état du système au temps T : quelles pistes étaient visibles, quelles évaluations de menaces étaient en cours, quelles règles d'engagement s'appliquaient, quels ordres étaient actifs. L'event sourcing permet cela en rejouant le flux d'événements jusqu'au temps T et en matérialisant l'état du système à ce point.

Technologies de magasins d'événements

EventStoreDB est une base de données de magasin d'événements conçue spécifiquement pour les architectures event-sourcées. Elle fournit un partitionnement natif des flux (les événements sont organisés par identifiant d'agrégat, de sorte que tous les événements pour la piste ID 12345 sont dans le flux «track-12345»), des flux d'abonnement natifs pour construire des projections, et un support intégré pour le contrôle de concurrence optimiste. EventStoreDB est un premier choix raisonnable pour les nouveaux systèmes de défense DGA avec event sourcing si les contraintes opérationnelles permettent un processus de base de données dédié.

Apache Kafka comme journal d'événements : L'architecture de journal en ajout seul et partitionné de Kafka correspond étroitement aux exigences de l'event sourcing. Les topics Kafka partitionnent les événements par type d'agrégat ; au sein d'un topic, les événements sont ordonnés par partition et décalage. Le mécanisme de groupe de consommateurs permet à plusieurs projections de consommer le même flux d'événements à des décalages indépendants. La conception distribuée de Kafka fournit une tolérance aux pannes qu'EventStoreDB nécessite une configuration supplémentaire pour atteindre. Pour les systèmes DGA/EMA utilisant déjà Kafka pour les pipelines d'ingestion, utiliser Kafka comme magasin d'événements évite d'introduire une deuxième base de données spécialisée.

PostgreSQL avec des tables JSONB en ajout seul : Pour les systèmes où l'introduction d'un magasin d'événements dédié n'est pas faisable, PostgreSQL avec une table en ajout seul et des charges utiles d'événements JSONB est une alternative pratique. Le schéma de table : event_id (UUID), aggregate_type (VARCHAR), aggregate_id (UUID), event_type (VARCHAR), event_data (JSONB), occurred_at (TIMESTAMPTZ), recorded_at (TIMESTAMPTZ), recorded_by (VARCHAR). Un déclencheur ou une contrainte au niveau de l'application empêche les opérations UPDATE et DELETE sur la table. Cela fournit la sémantique d'event sourcing sans technologie dédiée.

Reconstruction de l'état : projections, instantanés et performance de rejeu

Reconstruire l'état actuel d'une entité en rejouant son historique complet d'événements depuis le début est coûteux en calcul pour les entités avec de longs historiques. Une piste ayant reçu 50 000 mises à jour de position sur 30 jours nécessite le rejeu de 50 000 événements pour calculer son état actuel. C'est le défi de performance de l'event sourcing.

La solution standard est le snapshotting : matérialisation périodique de l'état actuel d'une entité et stockage à côté du flux d'événements. Lors de la reconstruction de l'état, le système charge le dernier instantané et rejoue seulement les événements après l'horodatage de l'instantané. Une piste avec 50 000 événements totaux mais un instantané pris après 49 900 événements nécessite seulement de rejouer 100 événements. La fréquence des instantanés est un paramètre réglable : des instantanés plus fréquents améliorent la latence de lecture au coût de plus de stockage.

Les projections sont des vues optimisées pour la lecture dérivées du flux d'événements. Une projection «positions actuelles des pistes» matérialise la dernière position de chaque piste en consommant des événements TrackPositionUpdated. Une projection «historique des pistes par unité» matérialise tout l'historique des positions pour chaque unité. Les projections peuvent être reconstruites depuis zéro en rejouant le flux complet d'événements, ce qui est la façon de récupérer d'une base de données de projection corrompue sans perdre de données.

Dimensions juridiques et de conformité

Les exigences légales pour la conservation des données de défense varient significativement selon la juridiction nationale et le type d'opération. Pour les systèmes DGA/EMA, au minimum la plupart des programmes de défense exigent : des preuves d'intégrité des données (l'enregistrement stocké n'a pas été modifié depuis sa création), des registres de chaîne de garde (qui a accédé et traité chaque élément de données), et la conformité à la période de conservation (les données sont conservées pendant la période requise et supprimées de manière sécurisée après). L'event sourcing fournit des preuves d'intégrité des données intrinsèquement — le magasin en ajout seul est structurellement résistant à la modification. La chaîne de garde est fournie par les métadonnées d'événements (champs recorded_by, processing_system_id). La conformité à la conservation exige une application explicite de la politique au niveau de l'infrastructure.