La Partie 1 a choisi un périmètre, fixé l'architecture en quatre couches et conçu le schéma de piste canonique. La Partie 2 construit le moteur (fusion engine) qui transforme les rapports de capteurs en pistes fiables : les adaptateurs qui font entrer les sources, les algorithmes de corrélation qui décident quels rapports se rapportent au même objet physique, la gestion du cycle de vie qui indique au COP qu'une piste est devenue obsolète, et le magasin de pistes (track store) qui ancre l'ensemble. À la fin de la Partie 2, la plateforme produit des pistes opérationnellement utiles ; elle n'a simplement aucun endroit où les afficher.

La référence conceptuelle pour tout ce qui est traité dans la Partie 2 est Le guide complet de la fusion de données de défense, qui couvre la discipline. Ici, nous prenons des décisions spécifiques pour la plateforme exemple suivie tout au long de la série.

Étape 1 : Le motif d'adaptateur, appliqué strictement

Chaque capteur produit des données dans son propre format. Les radars parlent ASTERIX ; les drones parlent STANAG 4586 ; les récepteurs AIS émettent du NMEA 0183 ; les clients ATAK parlent CoT ; les flux ADS-B civils émettent un protocole binaire différent ; les observations rapportées manuellement arrivent via un formulaire web. Le rôle de la couche d'adaptateur est de traduire l'ensemble vers le schéma de piste canonique défini en Partie 1.

La règle est brutale et mérite d'être mémorisée : aucun concept spécifique à un capteur ne doit fuir au-delà de l'adaptateur. Si le code de votre moteur de fusion référence des catégories ASTERIX, votre architecture fuit. Si votre magasin de pistes a une colonne pour les types de messages AIS, votre architecture fuit. Les adaptateurs sont des convertisseurs de données unidirectionnels avec une isolation stricte ; ils n'exposent en amont que des pistes canoniques.

La structure pragmatique d'un adaptateur pour chaque source :

  • Transport — le connecteur vers la source (socket UDP, abonnement MQTT, webhook HTTP, surveillance de fichier). Résilient aux défaillances côté source : reconnexions, backoff, comptabilité des messages perdus.
  • Parseur — traduit le format filaire en une structure typée fortement en processus. Valide contre la spécification du format. Rejette bruyamment les entrées malformées plutôt que silencieusement.
  • Normalisateur — mappe les champs spécifiques à la source vers les champs canoniques. Conversion de système de coordonnées (typiquement vers WGS84). Normalisation des horodatages (UTC, avec la discipline des trois horodatages de la Partie 1).
  • Émetteur — publie la mise à jour de piste canonique sur le bus de messages. Étiquette avec l'identifiant de source, la classification de source, la diffusion autorisée (releasability).

Chaque adaptateur est un service ou processus distinct. Ils partagent une bibliothèque cliente générée par code pour le schéma canonique, mais aucun autre chemin de code. Ajouter un nouveau type de capteur signifie écrire un nouvel adaptateur, sans toucher à aucun autre composant. Les motifs d'intégration détaillés pour les sources courantes sont dans Intégrer AIS et ADS-B dans une image militaire et le côté CoT dans Cursor on Target (CoT) : le standard XML derrière les applications tactiques de conscience situationnelle.

Étape 2 : Câbler le bus de messages

Les adaptateurs publient sur un journal durable, ordonné et partitionné. Les services de fusion y consomment. Le service d'audit aussi, ainsi que le service de rejeu historique et toute analytique en aval. Le bus de messages est la moelle épinière de la plateforme.

Pour la plateforme exemple, nous utilisons Kafka avec un topic par type de source et des topics supplémentaires pour les sorties de fusion. Les adaptateurs publient sur raw.source-type ; le moteur de fusion les consomme et publie sur tracks.updates et tracks.lifecycle. L'audit s'abonne à tout. Le motif du bus, y compris les compromis entre débit et durabilité, est traité dans Files de messages pour pipelines de données de défense.

La décision architecturale à mettre en évidence : n'appelez pas en HTTP entre les composants de fusion. Le couplage synchrone requête-réponse rend un pipeline de fusion fragile. Une surcharge de capteurs qui bloque un consommateur ne doit pas bloquer chaque producteur en amont. Le bus avec backpressure est la solution structurelle ; HTTP entre composants de fusion est une source récurrente de pannes.

Étape 3 : Corrélation piste-à-piste (track-to-track)

Le cœur du moteur de fusion est l'algorithme qui décide si un rapport entrant est une mise à jour d'une piste existante ou la naissance d'une nouvelle piste. Mal le faire, et l'opérateur voit de la soupe de pistes (mille symboles là où il devrait y en avoir cent) ou des pistes fantômes (des doublons qui auraient dû fusionner). Bien le faire, et le COP devient digne de confiance.

Le motif pragmatique utilise un filtre en deux étapes.

Étape 1 : portillon (gating) à base de règles. Pour chaque rapport entrant, calculer l'ensemble des pistes candidates existantes dans la portée cinématique — un portillon position-temps qui dit « une piste se déplaçant à au plus V m/s aurait pu parcourir depuis sa dernière position connue jusqu'à la position de ce rapport dans cet intervalle de temps ». Les a priori d'identité filtrent davantage : un rapport étiqueté « vaisseau » ne peut correspondre à une piste « aéronef ». Les filtres de compatibilité de source : un rapport d'un radar terrestre ne peut correspondre à une piste aérienne d'une plateforme sous-marine. L'étape à base de règles traite 90 % des entrées à faible coût et sans ambiguïté.

Étape 2 : association probabiliste. Pour les cas contestés — plusieurs candidats dans le portillon, identité ambiguë, scénarios denses avec trajectoires qui se croisent — invoquer l'association probabiliste de données. Joint Probabilistic Data Association (JPDA) pour une densité modérée ; Multiple Hypothesis Tracking (MHT) pour les cas les plus difficiles. Les deux calculent une vraisemblance qu'un rapport entrant appartienne à chaque piste candidate et mettent à jour les pistes pondérées par cette vraisemblance.

Le modèle théorique complet avec ses implications d'ingénierie est dans Le modèle de fusion de données JDL : une référence d'ingénierie pratique. Les nuances d'ingénierie sur le moment où chaque technique s'applique, et le réglage requis, sont dans La fusion de données militaires expliquée.

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 central. Par défaut, optez pour un élagage agressif ; réglez vers l'extérieur uniquement lorsque la situation de menace l'exige.

Étape 4 : Gestion du cycle de vie de la piste

Une piste n'est pas un enregistrement statique. Elle naît, est confirmée, vieillit, s'estompe et meurt. Le moteur de fusion gère le cycle de vie explicitement ; le COP affiche l'état du cycle de vie pour que les opérateurs sachent à quelles pistes faire confiance.

La machine à états pour la plateforme exemple :

  • Tentative (tentative) — première observation ; pas encore affichée dans le COP opérationnel, sauf demande explicite. Décroît vers « supprimée » s'il n'y a pas de suivi dans une fenêtre configurable.
  • Confirmée (confirmed) — deux rapports corrélés ou plus, la cohérence cinématique tient. Promue depuis « tentative ». C'est l'é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 analytiques en aval qui ont besoin d'une identité stable.
  • S'estompant (fading) — pas de mise à jour dans l'intervalle de revisite attendu. Affichage marqué comme obsolète. Configurable par classe de source (une piste maritime de 30 secondes est correcte ; une piste aérienne de 30 secondes est en train de s'estomper).
  • Perdue (lost) — pas de mise à jour pendant une période prolongée. Retirée de l'affichage actif mais conservée dans le magasin de pistes pour audit et analyse historique.

Chaque transition d'état est journalisée. Le service d'audit consomme le flux de transitions et écrit des enregistrements immuables — le sujet de Event sourcing pour les pistes d'audit de défense. Les transitions sont également exposées sur le bus afin que le COP puisse rendre l'état du cycle de vie sans interrogation.

Insight clé : Les opérateurs tolèrent une piste manquante. Ils ne tolèrent pas une piste obsolète affichée avec confiance. La gestion du cycle de vie est la couche qui fait la différence. Construisez-la avant que l'algorithme de fusion soit pleinement réglé — c'est peu coûteux, et ça rapporte chaque fois qu'une liaison de capteur tombe.

Étape 5 : Le magasin de pistes faisant autorité

La fusion produit un flux de mises à jour de pistes et de transitions de cycle de vie. Le magasin de pistes (track store) est la vue matérialisée : l'état courant de chaque piste active, interrogeable par le COP et les analytiques. La décision architecturale à prendre tôt : 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 à partir du journal à la demande.

Ce motif — état event-sourced avec projections en modèle de lecture (event sourcing) — présente trois bénéfices opérationnels. Le magasin peut être effacé et reconstruit sans perte de données. Plusieurs modèles de lecture aux formes différentes peuvent coexister (un pour le COP, un pour les analytiques, un pour une API externe). Les requêtes à voyage dans le temps deviennent triviales : rejouer le journal jusqu'à un instant choisi pour reconstruire ce que la plateforme croyait alors.

Le magasin lui-même est PostgreSQL avec PostGIS pour l'indexation géospatiale. Les pistes chaudes vivent en mémoire ou dans une couche Redis en façade de PostgreSQL pour des lectures sous la milliseconde ; le magasin relationnel gère les requêtes de longue traîne et les garanties de persistance. La vue d'ingénierie détaillée est dans PostGIS pour les données géospatiales de défense.

Résistez à l'envie d'ajouter une base de données graphe « pour les relations ». Les relations entre pistes — détection de convoi, reconnaissance de formation, réseaux de contacts — relèvent de la fusion JDL niveau 2, une préoccupation distincte de la maintenance des pistes de niveau 1. Construisez d'abord le niveau 1, exploitez-le en opérations pendant un an, puis revisitez le niveau 2 avec les preuves opérationnelles en main.

Étape 6 : Tester avec des entrées réalistes

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

Bancs de rejeu (replay test harnesses). Capturer des traces de capteurs réelles en développement et les rejouer à pleine cadence contre le moteur de fusion. Les traces servent de suite de tests de régression : un nouvel algorithme ou un changement de schéma doit produire des résultats équivalents ou meilleurs sur les traces existantes, pas seulement sur une charge synthétique.

Entrées adversariales. Messages AIS usurpés avec une cinématique invraisemblable. XML CoT malformé. Plots radar qui violent la physique (pistes au sol à Mach 5). Le moteur de fusion doit rejeter ou marquer ces entrées, ne pas paniquer, ne pas planter, ne pas produire de pistes confiantes mais erronées. La discipline est la même que la discipline de test plus large dans Tester les systèmes C2 critiques de mission.

Détection de motifs de vie (pattern-of-life). Une fois la fusion de base fonctionnelle, superposer les analytiques PoL — voir Analyse des motifs de vie dans le renseignement militaire. Le service PoL consomme les mêmes topics du bus ; il produit des annotations enrichies d'état de piste plutôt que de concurrencer le moteur de fusion.

Étape 7 : Cibles de performance et marge

La latence de fusion est opérationnellement déterminante. Cibles pour la plateforme exemple : latence de fusion de bout en bout au 95e centile sous 500 ms (de l'ingestion du rapport de capteur au message de mise à jour de piste sur le bus) ; 99e centile sous 1,5 s ; débit soutenu à 10 000 rapports par seconde avec une marge CPU à un seul chiffre en pourcentage.

Ce sont des cibles de niveau brigade tactique. Les plateformes stratégiques ont des tolérances de latence plus lâches et des plafonds de débit plus élevés. Les cibles dictent les décisions architecturales : éviter les appels synchrones inter-services sur le chemin chaud ; pré-allouer l'état des pistes chaudes ; ne batcher que là où le bus le permet ; instrumenter chaque étape du pipeline pour que les régressions de latence émergent en CI plutôt qu'en opérations.

La suite

La Partie 2 a construit le moteur. Les adaptateurs de capteurs convertissent vers des pistes canoniques ; le bus de messages porte les événements ; le moteur de fusion corrèle les rapports en pistes ; la gestion du cycle de vie maintient les opérateurs honnêtes sur la fraîcheur ; le magasin de pistes expose l'état courant. La plateforme produit désormais des données de pistes dignes de confiance. Elle n'a simplement aucune surface destinée aux opérateurs.

La Partie 3 construit l'image opérationnelle commune — le frontend qui transforme les pistes en la carte que l'opérateur utilise réellement. Symbologie, mises à jour en temps réel, filtrage selon le rôle et les décisions d'ingénierie qui déterminent si la plateforme est adoptée sur le terrain.