Construire un pipeline de fusion de défense, partie 2 : corrélation de pistes et gestion du cycle de vie

La partie 1 a laissé le pipeline avec un flux d'observations de pistes canoniques arrivant sur le bus de messages. Chaque observation est un atome isolé — « la source X rapporte un objet à la position Y avec la vitesse Z à l'instant T ». Le travail du moteur de fusion est de décider quelles observations se réfèrent au même objet physique, de les accumuler en pistes stables dont la confiance d'identité croît, de gérer le cycle de vie quand les observations cessent ou que de nouvelles arrivent, et d'exposer une vue interrogeable du monde au COP et aux consommateurs en aval. La partie 2 traite de la construction de ce moteur.

La référence conceptuelle est La fusion de données militaire expliquée pour l'aperçu de la discipline, le modèle de fusion de données JDL pour le mapping des niveaux, et l'article pilier Guide complet de la fusion de données de défense pour le cadrage architectural plus large.

Étape 1 : le filtre de corrélation à deux étages

La décision centrale du moteur de fusion — savoir si une observation entrante est une mise à jour d'une piste existante ou la naissance d'une nouvelle — n'a pas besoin de reposer sur un seul algorithme. Le motif qui passe à l'échelle en production utilise deux étages : un filtre basé sur des règles, peu coûteux, qui traite les cas faciles, et un moteur d'association probabiliste invoqué uniquement quand la couche à règles est ambiguë.

L'étage basé sur des règles traite les 90 % d'observations qui ne sont pas ambiguës. Pour chaque observation entrante, il calcule l'ensemble des pistes existantes candidates à portée cinématique — une porte position-temps. Les a priori d'identité filtrent davantage : une observation étiquetée « navire » ne peut pas correspondre à une piste « aéronef ». La compatibilité de source filtre aussi : une observation provenant d'un radar terrestre ne peut pas correspondre à une piste aérienne d'une plateforme sous-marine. Quand la porte produit exactement un candidat qui passe les règles d'identité et de source, l'observation met à jour ce candidat directement. Quand la porte ne produit aucun candidat, l'observation initie une nouvelle piste tentative. Peu coûteux, rapide, explicable.

L'étage probabiliste est invoqué quand la couche à règles renvoie plusieurs candidats ou quand la densité de pistes est suffisamment élevée pour qu'un gating confiant soit impossible. L'association probabiliste conjointe (JPDA) calcule la vraisemblance qu'une observation appartienne à chaque piste candidate et met à jour chacune pondérée par la vraisemblance. Le suivi par hypothèses multiples (MHT) maintient plusieurs hypothèses de pistes à travers les observations, différant les décisions d'association jusqu'à ce que suffisamment de preuves s'accumulent. Les deux sont plus lourds en calcul et plus difficiles à régler ; les deux ne sont corrects que pour les cas où la couche à règles aurait eu tort de trancher.

Un piège spécifique à souligner : MHT génère un nombre exponentiel d'hypothèses sans élagage. La politique d'élagage — combien d'hypothèses retenir, quand fusionner, quand supprimer — est plus importante que l'algorithme cœur. Par défaut, élaguez agressivement ; détendez seulement quand les preuves opérationnelles l'exigent.

Étape 2 : régler la couche à règles

La couche à règles est l'endroit où atterrit la majeure partie de l'effort d'ingénierie de fusion. L'algorithme est simple ; le réglage est un artisanat.

Les paramètres de porte qui comptent :

• Taille de la porte cinématique — à quelle distance une observation peut se trouver de la position prédite de la piste pour encore correspondre. Trop petite, on rate de vraies mises à jour après bruit capteur ; trop grande, on produit de fausses corrélations dans des scènes denses.
• Porte d'identité — quels attributs d'identité doivent correspondre (toujours : taxonomie de type ; parfois : sous-type, numéro de coque, indicatif).
• Règles d'ensemble de sources — quelles sources peuvent mettre à jour quels types de pistes. Spécifiques au domaine (un radar maritime ne devrait pas mettre à jour une piste sous-marine) et à la plateforme (un contact SIGINT en goniométrie seule peut ne pas s'associer à une piste cinématique sans correspondance d'azimut).
• Tolérance de temps écoulé depuis la dernière mise à jour — les observations face à des pistes silencieuses depuis trop longtemps produisent une nouvelle piste tentative plutôt qu'une réassociation à l'ancienne.

Les valeurs par défaut proviennent des profils de précision et de latence du catalogue des sources. Le réglage opérationnel vient du rejeu sur données capturées, avec des métriques sur le taux de fausse corrélation et le taux d'erreur d'association. Les moteurs de fusion de niveau commercial exposent ces molettes de réglage pour que l'équipe opérationnelle les ajuste par déploiement ; les programmes sur mesure codent souvent les valeurs en dur et le regrettent quand le contexte de déploiement change.

Étape 3 : quand et comment invoquer l'association probabiliste

L'association probabiliste est le bon outil quand le gating basé sur des règles ne peut pas produire une seule correspondance confiante. Le signal que le probabiliste est nécessaire : la porte renvoie plus d'un candidat à un taux supérieur à (disons) 5 % dans la scène opérationnelle.

Le motif d'invocation pragmatique :

JPDA pour densité modérée. Quand la porte renvoie 2 à 4 candidats par observation ambiguë, JPDA calcule des vraisemblances d'association en utilisant des a priori cinématiques (distance de Mahalanobis depuis la position prédite) et des a priori d'identité. Les mises à jour de pistes sont pondérées par la vraisemblance ; aucune piste ne reçoit de mise à jour « définitive », mais les candidats les plus probables accumulent les preuves plus vite.

MHT pour les cas les plus durs. Quand la porte renvoie de nombreux candidats et que l'ambiguïté d'association persiste à travers les observations, MHT diffère la décision. Il maintient des hypothèses (interprétations alternatives de quelle observation appartient à quelle piste) et élague par vraisemblance. Après plusieurs observations, l'hypothèse dominante émerge et les autres sont supprimées.

Sortie combinée. Les deux algorithmes produisent des mises à jour qui reviennent dans le même magasin de pistes que les mises à jour basées sur des règles. Du point de vue des consommateurs en aval, toutes les mises à jour se ressemblent ; la différence se trouve dans les métadonnées de confiance et de provenance attachées.

La réalité d'implémentation : il existe des bibliothèques open source bien testées pour JPDA et MHT (Stone Soup, FilterPy et outils adjacents). La plupart des moteurs de fusion opérationnels enveloppent une bibliothèque éprouvée plutôt que d'implémenter à partir de zéro. L'effort d'ingénierie est dans l'intégration, le réglage et le durcissement opérationnel — pas dans l'algorithme.

Étape 4 : la machine à états du cycle de vie des pistes

Les pistes ont des cycles de vie. La machine à états qui les gouverne est l'une des décisions opérationnellement les plus lourdes de conséquences de la plateforme : les opérateurs tolèrent les pistes manquantes mais ne tolèrent pas les pistes périmées affichées avec confiance. Le cycle de vie est la frontière entre affichage fiable et affichage non fiable.

La machine à états pour l'exemple en cours :

• Tentative (tentative). Première observation ; en attente de confirmation. Non affichée dans le COP opérationnel sauf si un opérateur demande explicitement la visibilité basse confiance. Décline vers supprimée si aucun suivi dans une fenêtre configurable.
• Confirmée (confirmed). Deux observations corrélées ou plus dans la fenêtre de cohérence cinématique. Promue depuis tentative. État par défaut des pistes affichées.
• Mature (mature). Confirmée et persistante pendant au moins N minutes avec des mises à jour cohérentes. Utilisée par les analyses en aval qui ont besoin d'une identité stable pour le pattern-of-life ou l'analyse comportementale.
• En déclin (fading). Aucune mise à jour dans l'intervalle de revisite attendu pour cette classe de source. Affichage signalé comme périmé (symbole atténué, indicateur d'âge). Configurable par classe de source — une piste maritime de 30 secondes est correcte ; une piste aérienne de 30 secondes est en déclin.
• Perdue (lost). Aucune mise à jour pendant une période prolongée. Retirée de l'affichage actif mais conservée dans le magasin de pistes pour l'audit et l'analyse historique.

Les transitions sont basées sur le temps et sur les mises à jour, les deux alimentant un arbre de décision unique. Chaque transition est journalisée avec l'événement déclencheur (mise à jour d'observation, expiration de délai, override d'opérateur). Le journal des transitions alimente la piste d'audit event-sourced couverte dans Event Sourcing pour les pistes d'audit de défense.

Un détail pratique : le service de cycle de vie est un processus distinct du moteur de corrélation. Il s'abonne aux événements de mise à jour de pistes depuis la corrélation, calcule les transitions de cycle de vie et les publie comme un flux séparé sur le bus. Le découplage permet à la politique de cycle de vie d'évoluer sans toucher au moteur de corrélation.

Étape 5 : le magasin de pistes comme modèle de lecture event-sourced

La fusion produit en sortie un flux de mises à jour de pistes et de transitions de cycle de vie. Le magasin de pistes est la vue matérialisée : l'état courant de chaque piste active, interrogeable par le COP, par les analyses et par des API externes. La décision architecturale qui vaut d'être prise tôt est que le magasin de pistes est un modèle de lecture, pas une source faisant autorité. La source faisant autorité est le journal d'événements sur le bus de messages. Le magasin de pistes est reconstruit depuis le journal à la demande.

Les bénéfices de ce motif :

Effacer et reconstruire. Le magasin peut être vidé et reconstruit depuis le journal sans perte de données. Migrations de schéma, réglage de performance et récupération de données corrompues deviennent tous routiniers plutôt que risqués.

Modèles de lecture multiples. Un modèle de lecture optimisé COP (indexé géospatial, cache de pistes chaudes, lectures à faible latence) coexiste avec un modèle optimisé analytique (dénormalisé, friendly aux traitements par lot) et un modèle API externe (filtré, classifié par consommateur). Tous sont des projections du même flux d'événements sous-jacent.

Requêtes de retour dans le temps. « Que croyait la plateforme à 14:32 ? » devient trivial : rejouez le journal jusqu'à 14:32 contre une nouvelle projection. Revue après action, entraînement et audits d'accréditation en bénéficient tous.

L'implémentation : PostgreSQL avec l'extension PostGIS pour les requêtes géospatiales (par défaut pour l'exemple en cours). Une couche Redis en façade pour des lectures de pistes chaudes en moins d'une milliseconde sur le chemin critique du COP. Le magasin relationnel gère les requêtes à plus longue queue et les garanties de persistance. La vue d'ingénierie détaillée, y compris les stratégies d'indexation qui passent à l'échelle de milliards de points, est dans PostGIS pour les données géospatiales de défense.

Étape 6 : résister à la base de données graphe (pour l'instant)

Une tentation prévisible dans la conception de fusion est d'ajouter une base de données graphe « pour les relations ». Détection de convois, reconnaissance de formations, réseaux de contacts — tout cela sonne « graphe ». La tentation est de les modéliser dans Neo4j ou équivalent et de gagner des requêtes de relations « naturelles ».

Le contre pragmatique : les relations entre pistes relèvent de la fusion JDL niveau 2, une préoccupation distincte de la maintenance de pistes niveau 1. Construisez d'abord le niveau 1, faites-le tourner en opérations pendant un an, et revisitez seulement ensuite le niveau 2 avec les preuves opérationnelles en main. Les relations niveau 2 se révèlent souvent nécessiter une forme différente de celle que prédisait l'intuition « base graphe » — temporelle-relationnelle plutôt que purement topologique, consciente de la classification plutôt qu'ouverte, exprimée à un niveau d'abstraction plus élevé que les arêtes par piste.

Les plateformes qui réussissent commencent avec PostGIS + Redis pour le modèle de lecture, prouvent la fusion au niveau 1, et ajoutent les capacités niveau 2 comme services distincts consommant le même flux d'événements. Les plateformes qui échouent ajoutent la base graphe dès la première semaine et passent deux ans à déboguer l'abstraction inappropriée.

Étape 7 : tester le moteur de fusion face à la réalité

Un moteur de fusion testé uniquement avec une charge jouet passe les tests d'intégration et échoue en opérations. Les disciplines qui attrapent les problèmes avant le déploiement :

Harnais de tests de rejeu. Traces capteur capturées d'opérations réelles, rejouées à pleine cadence et à cadence accélérée contre le moteur de fusion. Les traces sont la suite de tests de régression : tout changement d'algorithme ou de schéma doit produire des résultats équivalents ou meilleurs, et pas seulement sur charge synthétique.

Métriques de qualité de pistes en CI. Taux de fausse corrélation, taux d'erreur d'association, taux de fragmentation de pistes, timing des transitions de cycle de vie. Chaque métrique suivie dans le temps ; les régressions bloquent la release. Les métriques sont évaluées contre les traces de rejeu, pas contre une charge synthétique.

Tests de scénarios adverses. Messages AIS spoofés avec cinématique implausible. Plots radar violant la physique. Coupures de sources à des moments critiques. Le moteur de fusion doit se dégrader gracieusement sous mauvaise entrée — ne pas planter, ne pas produire des pistes confiantes mais erronées. Le motif d'ingénierie plus large pour la robustesse adversariale en défense est dans Tester les systèmes C2 critiques pour la mission.

Tests de charge et de pointe. Latence de fusion au 95e percentile sous 500 ms à 10 000 observations/seconde ; 99e percentile sous 1,5 s. Soutenu pour la durée d'une rotation opérationnelle, pas seulement pour le benchmark marketing. La plateforme doit avoir une marge CPU à un seul chiffre de pourcentage pour gérer les pointes.

La suite

La partie 2 a construit le moteur. La corrélation à deux étages gère les cas faciles et difficiles. La machine à états du cycle de vie fait remonter la fraîcheur aux opérateurs. Le magasin de pistes comme modèle de lecture event-sourced supporte les requêtes sans devenir une source faisant autorité. Les disciplines de test valident la couche face à la réalité.

La partie 3 approfondit le cas multi-INT — combiner SIGINT, IMINT, ELINT, OSINT, HUMINT, GEOINT, MASINT dans le même flux de fusion tout en préservant leurs différences sémantiques — et s'attaque à la propagation de classification et de releasability que la fusion de défense exige de manière unique.