La fusion de données militaires est le processus de calcul qui combine le renseignement provenant de sources multiples et hétérogènes en une représentation cohérente, consistante et précise de l'environnement opérationnel. Quand ça fonctionne, un commandant voit une seule piste étiquetée « char T-80, confiance 87 %, dernière mise à jour il y a 14 secondes ». Quand ça ne fonctionne pas, il voit trois pistes contradictoires, chacune d'un capteur différent, chacune avec une position différente — et aucun moyen de savoir laquelle est correcte.

Réussir la fusion de données est l'un des problèmes les plus techniquement exigeants dans les logiciels de défense. Les entrées sont bruitées, retardées et souvent contradictoires. La sortie doit être suffisamment fiable pour agir dessus.

Le modèle JDL : un cadre pour les niveaux de fusion

Le modèle DFIG (Data Fusion Information Group) — communément appelé modèle JDL d'après ses origines aux Joint Directors of Laboratories — définit la fusion de données comme une série de niveaux de traitement, chacun s'appuyant sur le précédent.

Niveau 0 — Association et estimation de données sous-objet. Les signaux bruts des capteurs sont traités et nettoyés. Les images au niveau des pixels sont prétraitées ; les données acoustiques sont numérisées ; les signaux RF sont démodulés. La sortie est un flux d'observations, pas encore corrélé avec un objet.

Niveau 1 — Raffinement d'objet. Les observations individuelles sont combinées pour produire des pistes. Plusieurs retours radar du même objet physique sont associés et fusionnés en une seule piste cinématique. Ce niveau traite le problème central de la fusion de pistes : étant donné cinq détections radar sur 30 secondes, estimer la position, la vitesse et le cap de l'objet, avec une ellipse d'incertitude associée. Les algorithmes ici incluent le filtrage de Kalman, le suivi à hypothèses multiples (MHT) et l'association probabiliste de données conjointes (JPDA).

Niveau 2 — Raffinement de la situation. Les pistes individuelles sont placées dans leur contexte. Ce niveau répond à « que signifie cette formation ? » — reconnaissant que les trois chars se déplaçant en formation en coin avec de l'artillerie derrière constituent une tentative de brèche, pas une patrouille. La fusion de niveau 2 nécessite de corréler les pistes avec la doctrine, les bases de données d'ordre de bataille et les schémas historiques.

Niveau 3 — Raffinement des menaces. La situation actuelle est projetée en avant : si cette formation continue sur son cours et sa vitesse actuels, que va-t-elle menacer dans 20 minutes ? Ce niveau produit des évaluations de menaces, pas seulement des données de piste.

Sources de données et leurs défis logiciels

Les flux SIGINT arrivent sous forme d'interceptions structurées ou de captures RF brutes. Ils portent une incertitude temporelle (le temps d'interception vs le temps de transmission peuvent différer) et une ambiguïté de position quand les données de géolocalisation sont absentes. Les entrées SIGINT nécessitent souvent une normalisation de format à partir des sorties des systèmes de collecte propriétaires avant de pouvoir entrer dans le pipeline de fusion.

Les produits IMINT sont la sortie de l'exploitation d'imagerie — soit automatisée (détections par vision par ordinateur depuis des flux UAV) soit manuelle (annotations des analystes en imagerie). Le défi est la précision des horodatages : une image acquise à 09h47 montrant un véhicule aux coordonnées X n'est utile que si le moteur de fusion sait qu'elle a été acquise à 09h47, pas traitée et soumise à 11h15.

Les rapports HUMINT sont des rapports de renseignement structurés provenant de sources humaines. Ils sont typiquement peu fréquents, très fiables, et portent une incertitude de position significative. Ils sont rarement directement fusionnables avec les données de piste cinématiques mais sont essentiels pour construire le contexte d'ordre de bataille que la fusion de niveau 2 nécessite.

Les flux de capteurs EW fournissent des données d'émissions électroniques — ensembles de paramètres radar, fréquences de communication, signatures de formes d'onde. Lorsqu'ils sont corrélés avec des données de piste, ils permettent l'identification de plateforme : la piste se déplaçant à 60 km/h correspondant à la signature d'émission d'un radar BMP-2 devient une identification BMP-2 haute confiance.

Les flux vidéo UAV produisent un flux continu de données de position et visuelles. Le défi logiciel est d'extraire des pistes structurées depuis la vidéo — ce qui nécessite une inférence de vision par ordinateur en temps réel — et de corréler ces pistes avec les données existantes, en tenant compte du fait que le même véhicule observé par un UAV et détecté par un radar peut générer deux pistes séparées dans le moteur de fusion.

Défis de normalisation : la complexité cachée

Avant qu'un algorithme de fusion s'exécute, toutes les données entrantes doivent être normalisées. C'est un travail peu glamour qui consomme une part disproportionnée du temps de développement dans les vrais systèmes de fusion.

Normalisation du système de coordonnées : les capteurs rapportent les positions en WGS84, MGRS, grille locale, ou systèmes de coordonnées dépendant de l'altitude. Tout doit être transformé en une représentation canonique avant que la corrélation soit possible. Une erreur de 10 mètres introduite par une transformation de coordonnées est opérationnellement significative.

Normalisation des horodatages : différents capteurs utilisent le temps GPS, UTC, l'heure locale ou des numéros de séquence. Le moteur de fusion a besoin d'horodatages faisant autorité dans un seul référentiel. Un horodatage synchronisé GPS est le standard, mais tous les capteurs hérités ne le supportent pas.

Gestion de la classification et des caveats : les données de fusion traversent les frontières de classification. Une piste construite à partir de SIGINT à un niveau de classification et de données radar à un niveau inférieur a une classification composite. Le moteur de fusion doit propager la classification correctement et appliquer le besoin d'en connaître au moment de la requête, pas au moment de l'ingestion.

Corrélation et déconfliction

Le problème technique central dans la fusion de niveau 1 est de décider si deux observations, de deux capteurs différents, représentent le même objet physique. C'est le problème d'association de données. L'approche standard est une fonction de gating (éliminer les candidats en dehors d'un seuil de distance maximum) suivie d'un scoreur probabiliste (par ex. plus proche voisin ou MHT) qui assigne une probabilité de correspondance.

La déconfliction — résoudre le cas où deux pistes existantes sont en réalité le même objet — est plus difficile. Elle nécessite de détecter les doublons de pistes persistants, de fusionner leurs historiques et de réconcilier les conflits d'attributs. Une mauvaise déconfliction conduit à des pistes « fantômes » : des objets qui apparaissent sur le COP mais n'existent pas, ou des objets qui existent mais apparaissent deux fois.

Point clé : Dans la plupart des systèmes de fusion opérationnels, la plus grande source d'erreur n'est pas l'algorithme de fusion lui-même — c'est l'imprécision des horodatages et les erreurs de normalisation de coordonnées introduites au niveau de la couche d'ingestion de données. Corrigez la plomberie avant d'affiner les algorithmes.

Comment la fusion de données alimente le COP

Le moteur de fusion produit le magasin de pistes faisant autorité que le tableau opérationnel commun (COP) restitue. La couche COP interroge le magasin de pistes via API, s'abonne aux événements de mise à jour via WebSocket et restitue les changements de façon incrémentielle. La qualité du COP dépend entièrement de la qualité de la couche de fusion en dessous.

Un pipeline de fusion vers COP bien conçu publie des événements de mise à jour de pistes (nouvelle piste, piste mise à jour, piste supprimée) comme un flux. Le COP s'abonne et applique des deltas — pas des instantanés d'état complet — pour maintenir un affichage réactif même quand la base de données de pistes contient des dizaines de milliers d'objets. La latence entre l'observation capteur et l'affichage COP doit être mesurable en secondes à un chiffre pour les systèmes tactiques.