Construire un pipeline de fusion de défense, Partie 1 : sources, schémas et couche d'adaptateurs

Un pipeline de fusion qui fonctionne de manière fiable sous charge ne se conçoit pas ; il s'itère. La première itération échoue presque toujours pour la même raison : une discipline insuffisante à la couche source-et-schéma. Les adaptateurs laissent fuir en amont des concepts spécifiques aux sources, le schéma des pistes n'est pas assez stable pour supporter l'évolution, le modèle canonique confond des concepts qui devraient rester séparés, et six mois plus tard l'équipe réécrit le moteur de fusion pendant que les opérateurs utilisent encore celui qui est cassé. Cette série en quatre parties explique comment éviter ce dénouement. La Partie 1 couvre les fondations : cataloguer les sources, concevoir le schéma canonique des pistes, et la couche d'adaptateurs qui maintient tout le reste propre.

Le cadrage architectural de cette série est dans Le guide complet de la fusion de données de défense. L'équivalent côté C2 — construire la pile C2 complète avec la fusion comme un composant — est la série parallèle qui commence par Construire un système C2 à partir de zéro, Partie 1. Cette série se concentre étroitement sur le sous-système moteur-de-fusion plus couche-de-données.

Étape 1 : cataloguer les sources avant d'écrire du code

L'activité au plus fort effet de levier au début d'un programme de fusion est le catalogue des sources — un document décrivant chaque capteur, flux de renseignement et entrée externe que la plateforme ingérera. Le catalogue est sans intérêt à construire, sans intérêt à lire, et critique à réussir. Il devient le contrat dont dépend chaque composant en aval.

Le catalogue capture, pour chaque source :

• Identité de la source — identifiant stable, nom convivial, organisation propriétaire.
• Format filaire — catégorie et version ASTERIX, version STANAG 4586, AIS NMEA 0183, version de schéma CoT XML, version NITF, etc.
• Transport — multicast UDP, unicast TCP, topic MQTT, webhook HTTP, dépôt de fichiers. Inclut l'adressage, l'authentification, la posture de chiffrement.
• Cadence — débit de messages à charge nominale, débit de crête, intervalles de silence attendus.
• Profil de latence — heure d'observation vs heure de rapport vs heure d'ingestion. Certaines sources sont temps réel ; d'autres ont des délais de batch mesurés en heures.
• Précision et incertitude — ce que la spec affirme, ce que les données opérationnelles montrent, ce à quoi ressemblent les modes de défaillance.
• Posture de classification — à quel niveau de classification la source opère, quels compartiments s'appliquent, quelles règles de releasability gouvernent les données.
• Modes de défaillance connus — coupures de lien, indisponibilités côté source, dégradation graduelle, possibilités de manipulation délibérée.
• Mappings de schéma — comment chaque champ source correspond au schéma canonique des pistes (rempli une fois le schéma existant).

Le catalogue est un artefact versionné, stocké dans le dépôt aux côtés du code source, revu par l'équipe d'ingénierie et (le cas échéant) par la communauté opérationnelle dont les capteurs alimentent la plateforme. Une nouvelle source n'est pas « intégrée » tant qu'elle n'a pas d'entrée dans le catalogue ; cette discipline à elle seule prévient le refactor pluriannuel le plus courant dans les projets de fusion.

Le traitement détaillé des défis d'intégration de sources, en particulier la sémantique multi-INT qui émerge en défense, est dans Défis d'intégration de données de défense.

Étape 2 : concevoir le schéma canonique des pistes

La piste est la structure de données centrale de toute plateforme de fusion. Chaque adaptateur produit des pistes ; chaque décision de fusion met à jour des pistes ; chaque consommateur lit des pistes. Le schéma est le contrat avec lequel la plateforme vit toute sa vie opérationnelle, typiquement 15 à 20 ans. Consacrez un sprint à le bien faire ; consacrez une semaine à le documenter.

Le schéma minimum viable inclut :

ID de piste. Globalement unique, stable sur la durée de vie de la piste, jamais réutilisé. UUIDv7 ou un préfixe typé plus UUID est le défaut sûr. L'ID est opaque — il n'encode pas la source, l'identité, ni aucun autre attribut susceptible de changer.

Identité. Un type structuré avec trois sous-champs : taxonomie de type (navire, aéronef, véhicule, personne, unité, signal, non classifié-autre), sous-type (classification plus fine par domaine), et attributs identifiants (numéro de coque, numéro de queue, indicatif d'appel, MMSI, identifiant transpondeur). L'identité est mise à jour par la fusion au fur et à mesure que les preuves s'accumulent ; l'ID ne l'est pas.

Position et incertitude. Latitude, longitude, altitude en WGS84 par défaut. Incertitude représentée soit par une matrice de covariance (préférée pour la fusion cinématique), soit par un grand axe/petit axe avec gisement (acceptable pour des cas plus simples). Jamais un seul nombre d'incertitude — cela perd l'information géométrique dont la fusion a besoin.

État cinématique. Vecteur vitesse, taux de virage, cap/vitesse dérivés pour l'affichage. Horodaté avec l'instant d'estimation.

Ensemble de sources. Quels adaptateurs ont contribué aux observations de cette piste, avec classification, releasability et confiance par source. L'ensemble de sources est la fondation pour la propagation de la classification et l'audit. Le traitement détaillé est dans Fusion de données militaires expliquée.

Trois horodatages. Heure d'observation (quand le capteur a vu l'objet), heure de rapport (quand le message a quitté le capteur), heure d'ingestion (quand la plateforme l'a reçu). Les confondre est la source de bug la plus courante en ingénierie de fusion. Les opérateurs ont besoin de l'heure d'observation ; l'analyse en rejeu a besoin de l'heure d'ingestion ; la différence entre elles fait remonter la latence des capteurs pour la surveillance.

État du cycle de vie. Tentative, confirmée, mature, en déclin, perdue. Les détails de la machine à états viennent dans la Partie 2.

Enveloppe de classification. Classification effective calculée à partir de l'ensemble de sources. Tags de releasability calculés à partir de l'intersection des releasabilities des sources. Marquages de compartiments le cas échéant.

Confiance et certitude. Confiance au niveau de la piste comme un score calibré unique. Certitude par attribut là où elle diffère matériellement — par exemple, une piste peut avoir une haute certitude de position mais une identité tentative.

Étape 3 : s'engager à une évolution de schéma uniquement additive

Le schéma évoluera. De nouveaux attributs seront nécessaires ; des cas rares émergeront que la conception originale n'avait pas anticipés. La discipline qui maintient la plateforme opérationnelle à travers cette évolution est le versionnage additif uniquement.

Les règles :

• Les nouveaux champs sont optionnels. Les consommateurs existants les ignorent jusqu'à leur mise à niveau. Les producteurs les remplissent quand des données pertinentes sont disponibles.
• Les champs existants ne changent jamais de sémantique. Un champ qui signifie « vitesse en m/s » aujourd'hui doit signifier « vitesse en m/s » pour toujours. Un changement de sens exige un nouveau champ, pas un changement sur place.
• Les suppressions sont des dépréciations. Un champ marqué déprécié est toujours dans le schéma ; les nouveaux producteurs cessent de l'écrire ; les nouveaux consommateurs cessent de le lire ; les anciennes données continuent de fonctionner indéfiniment.
• Les changements cassants sont des bumps de version majeure. Ils arrivent — rarement. Quand ils arrivent, la migration est documentée, testée et coordonnée à travers tous les consommateurs. Un changement cassant ne devrait survenir qu'au plus une fois par durée de vie de plateforme, pas une fois par release.

Enveloppez le schéma dans une bibliothèque cliente générée par code partagée par chaque langage consommateur. Le schéma-as-code prévient la divergence lente qui autrement produit « plateforme de fusion v3.4 dans le service A, v3.6 dans le service B, v4.0 dans le service C » — le cauchemar opérationnel que chaque programme de fusion rencontrera sans cette discipline.

Étape 4 : construire la couche d'adaptateurs avec une isolation stricte

La couche d'adaptateurs traduit le format natif de chaque source vers le schéma canonique des pistes. La règle architecturale est brutale et mérite d'être mémorisée : aucun concept spécifique au capteur ne fuit au-delà de l'adaptateur. Si le code de votre moteur de fusion référence des catégories ASTERIX, vous avez une architecture qui fuit. Si votre magasin de pistes a une colonne pour les types de messages AIS, vous avez une architecture qui fuit. La règle est structurelle — la rompez une fois, et le coût se compose sur des années.

La structure d'un adaptateur bien conçu, en quatre couches :

Transport. Le connecteur à la source. Socket UDP, listener TCP, abonnement MQTT, webhook HTTP, watcher de fichiers. Résilient aux défaillances côté source : reconnexion automatique avec backoff, comptabilité des messages perdus, télémétrie exportée vers la pile de surveillance de la plateforme.

Parser. Traduit le format filaire en une structure en-process fortement typée. Valide contre la spécification du format. Rejette une entrée malformée bruyamment, avec un logging structuré qui fait remonter la malformation, l'identifiant de la source et l'horodatage. L'abandon silencieux des entrées invalides est le mauvais défaut — il masque des problèmes opérationnels qui devraient être remontés.

Normalizer. Mappe les champs spécifiques à la source vers les champs du schéma canonique. Conversion de système de coordonnées (typiquement vers WGS84). Normalisation des horodatages vers UTC avec la discipline des trois horodatages. Normalisation des champs d'identité à travers les diverses façons dont le même numéro de coque ou indicatif d'appel peut être formaté dans différentes sources.

Emitter. Publie la mise à jour canonique de piste sur le bus de messages de la plateforme, tagguée avec l'identifiant de source, la classification de source, la releasability et un horodatage d'ingestion frais. L'emitter est le seul composant de l'adaptateur qui connaît la plateforme ; tout en amont de lui est du code isolé spécifique à la source.

Chaque adaptateur tourne comme un service ou un processus séparé. Ils partagent une bibliothèque cliente générée par code pour le schéma canonique, mais aucun autre chemin de code. Ajouter une nouvelle source signifie écrire un nouvel adaptateur ; cela ne touche aucun autre composant. Les modèles d'intégration détaillés pour les sources de défense les plus courantes sont dans Intégrer AIS et ADS-B dans une image militaire et le côté CoT dans Cursor on Target (CoT).

Étape 5 : câbler les adaptateurs à un bus de messages durable

Les adaptateurs publient vers un log durable, ordonné et partitionné. Les services de fusion y consomment. L'audit, le rejeu historique et l'analyse en aval aussi. Le bus est la colonne vertébrale de la plateforme de fusion.

Le pattern qui passe à l'échelle : Kafka ou NATS JetStream comme log d'événements durable ; un topic-par-type-de-source du côté entrée ; un topic-par-type-de-sortie du côté fusion. Les adaptateurs publient sur raw.<source-type> ; le moteur de fusion les consomme et publie sur tracks.updates, tracks.lifecycle, tracks.classification. Les consommateurs s'abonnent aux topics dont ils ont besoin.

Les compromis détaillés entre Kafka et NATS, la discipline de modélisation des topics et les considérations opérationnelles sont dans Files de messages pour les pipelines de données de défense.

La règle architecturale qui mérite d'être soulignée : n'appelez pas HTTP entre les composants de fusion. Le couplage synchrone requête-réponse entre adaptateurs, services de fusion et consommateurs rend le pipeline fragile. Une surcharge de capteurs qui cale un consommateur ne doit pas caler le côté producteur. Le bus avec gestion de la backpressure est la solution structurelle ; HTTP entre composants de fusion est une source récurrente d'indisponibilités.

Étape 6 : tester le catalogue des sources contre la réalité

Le catalogue des sources est une hypothèse jusqu'à ce qu'il soit testé. Les disciplines qui le valident avant que le pipeline ne passe en opération :

Rejeu de données capturées. Pour chaque source, capturez des jours ou semaines de trafic réel au format filaire dans un fichier. Rejouez le fichier contre l'adaptateur au débit original et à débit accéléré. L'adaptateur qui gère des données réelles à 10× la vitesse est l'adaptateur qui gérera les surcharges opérationnelles de capteurs ; l'adaptateur qui ne gère que des données synthétiques de catalogue n'est pas encore prêt.

Tests d'entrée adversariale. Injectez des messages malformés, de l'AIS spoofé, des plots radar qui violent la physique (pistes au sol à Mach 5), du CoT XML avec des violations de schéma. L'adaptateur doit les rejeter bruyamment, ne pas planter, ne pas propager silencieusement. La discipline se prolonge jusqu'au moteur de fusion lui-même, traité dans Fusion de données militaires expliquée.

Tests d'aller-retour de schéma. Chaque adaptateur doit pouvoir faire un aller-retour entre son entrée native, le schéma canonique et le retour, en préservant les champs opérationnellement significatifs. Un adaptateur à perte est un échec de conception qui émerge sous test de conformité des mois plus tard.

Audit du catalogue contre des données de production réelles. Une fois le pipeline en déploiement pilote, auditez le catalogue des sources contre les données d'ingestion réelles. Sources qui produisent des attributs que le catalogue n'avait pas anticipés, latences qui dépassent les attentes du catalogue, ou modes de défaillance que le catalogue n'avait pas documentés — ce sont des constatations qui mettent à jour le catalogue, l'adaptateur, ou les deux.

La suite

La Partie 1 a couvert les fondations. Sources cataloguées, schéma canonique des pistes conçu avec évolution additive, adaptateurs construits avec isolation stricte, bus de messages câblé, et les disciplines de test qui valident la couche. Le pipeline ingère désormais les données sources et produit des observations canoniques de pistes sur le bus — mais ces observations ne sont pas encore corrélées en pistes.

Partie 2 : corrélation de pistes et gestion du cycle de vie prend le flux d'observations canoniques et construit le cœur du moteur de fusion. Gating basé sur des règles, association probabiliste de données (JPDA, MHT), machine à états du cycle de vie, et le magasin de pistes comme modèle de lecture event-sourced.