Guide complet de la fusion de données de défense et des logiciels de renseignement

La fusion de données est la discipline d'ingénierie qui transforme le bruit de dizaines de flux de capteurs et de rapports de renseignement incompatibles en une image unique sur laquelle un analyste peut agir. Faites-la mal et les opérateurs voient des pistes dupliquées, des positions contradictoires et des données obsolètes — et cessent de faire confiance au système dans la semaine qui suit le déploiement. Faites-la bien et la plateforme devient une infrastructure invisible : le COP fonctionne, les alertes sont crédibles, et la revue après action dispose des preuves dont elle a besoin.

Ce guide pilier rassemble l'architecture, les algorithmes et les compromis d'ingénierie qui déterminent si une plateforme de renseignement de défense atteint le seuil d'infrastructure de confiance. Il s'adresse à l'ingénieur ou au chef de programme concevant une pile de fusion multi-sources — que ce soit pour un centre national de renseignement, un backend de COP de niveau brigade, ou un pipeline de tri ISR qui alimente une plateforme C2 plus large. Chaque section renvoie à des articles plus approfondis sur le blog de Corvus.

Ce qu'est la fusion de données, et pourquoi elle existe

Les capteurs et les analystes produisent des rapports. Chaque rapport est une observation partielle, bruitée et retardée de la réalité. Un radar peint un retour aux coordonnées X avec une vitesse V. Un message AIS dit que le navire Foxtrot est aux coordonnées Y. Un opérateur FMV signale un véhicule aux coordonnées Z. Une source humaine signale un mouvement aux coordonnées W avec un retard de six heures. Chacun de ces rapports peut faire référence au même objet physique ou à quatre objets différents. Le rôle de la fusion de données est de décider lequel.

L'alternative naïve — afficher chaque rapport sur une carte comme un symbole indépendant — produit ce que les analystes chevronnés appellent la « soupe de pistes ». Une image maritime chargée pourrait contenir 5 000 objets distincts représentés par 20 000 symboles, chacun criant pour attirer l'attention. Le travail de l'opérateur devient de la reconnaissance de motifs face à l'affichage plutôt que face à la réalité. La fusion est ce qui ramène le nombre de symboles à la vérité.

Pour un traitement focalisé des principes et des décisions d'ingénierie, voir Fusion de données militaires expliquée : du multi-sources à une image unique. Le reste de ce guide s'appuie sur cette fondation.

Le modèle JDL : une carte de l'espace problème

Le modèle des Joint Directors of Laboratories donne au domaine son vocabulaire. Cinq niveaux de fusion sont reconnus ; les frontières sont imparfaites mais les niveaux restent utiles comme outil de planification.

Niveau 0 — Prétraitement du signal. Des signaux bruts des capteurs à la détection. Retours radar vers plots, pixels FMV vers boîtes de détection, spectre SIGINT brut vers rapports de gisement. C'est un travail interne au capteur, de plus en plus pris en charge par le traitement embarqué propre au capteur plutôt que par la plateforme de fusion.

Niveau 1 — Raffinement d'objet. Corrélation piste-à-piste, estimation d'identité, raffinement de classification. C'est le cœur de la fusion opérationnelle : associer les nouvelles observations aux pistes existantes, mettre à jour la cinématique, raffiner la confiance d'identité. Chaque plateforme de fusion de défense implémente pleinement le niveau 1 — sans lui, il n'y a pas de pistes utilisables.

Niveau 2 — Évaluation de la situation. Relations entre objets : convois, formations d'escorte, réseaux de contacts, appariements menace-cible. L'image agrégée qui transforme une liste de pistes en un récit tactique. Le niveau 2 est l'endroit où les plateformes de fusion modernes se différencient — et où la plupart sur-promettent.

Niveau 3 — Évaluation d'impact. Prédire les situations futures, l'intention et l'impact des menaces. En pratique, c'est principalement piloté par l'humain avec assistance logicielle : analyse de cours d'action, alerte de menace, routage prédictif. La fusion de niveau 3 entièrement automatisée est rare ; le seuil de confiance est élevé et les conséquences d'une erreur sont opérationnelles.

Niveau 4 — Raffinement du processus. Gestion et taskage des capteurs selon les besoins de fusion — pointer l'UAV vers la zone où les pistes sont les plus ambiguës, retasquer le collecteur SIGINT pour clarifier l'identité. Important et sous-valorisé dans le logiciel ; mérite son propre traitement architectural.

Pour la vision ingénierie de chaque niveau — quoi construire, quoi écarter — voir Le modèle de fusion de données JDL : une référence d'ingénierie pratique.

Multi-sources vs multi-INT : la distinction qui détermine la difficulté

Les ingénieurs confondent souvent fusion « multi-sources » et « multi-INT ». Ce ne sont pas les mêmes problèmes.

La fusion multi-sources combine des rapports de type compatible — trois radars voyant le même aéronef, deux récepteurs AIS entendant le même navire. La sémantique s'aligne entre les sources : position vaut position, identité vaut identité, confiance vaut confiance. Les parties difficiles sont l'association cinématique et l'affectation probabiliste de données sous pression de densité de pistes.

La fusion multi-INT est plus difficile. Chaque discipline de renseignement porte une sémantique différente :

SIGINT — renseignement d'origine électromagnétique — donne du gisement et de l'identité, souvent sans position précise. Un rapport SIGINT dit « l'émetteur X est quelque part le long de cette ligne de gisement ». La couche de fusion doit combiner les rapports en gisement seul entre stations pour localiser.

IMINT — renseignement d'origine image — donne position et identité avec haute confiance mais au rythme auquel le collecteur revisite. Un rapport IMINT est une estimation ponctuelle avec une fraîcheur effective de plusieurs heures.

ELINT — renseignement électronique — recouvre le SIGINT mais se concentre sur la caractérisation des radars et autres émetteurs, alimentant l'ordre de bataille électronique.

OSINT — renseignement de sources ouvertes — puise dans les réseaux sociaux, sites de pistage de navires, actualités, fournisseurs d'imagerie satellite. La confiance varie énormément et l'attribution de source compte autant que le contenu. Le modèle de plateforme pour l'OSINT dans les opérations cyber de défense est couvert dans Surveillance des menaces OSINT pour la défense.

GEOINT — renseignement géospatial — combine imagerie avec analyse de terrain, prédiction d'itinéraires et pattern-of-life sur un substrat géographique.

HUMINT — renseignement d'origine humaine — est à haute latence, à forte classification, sensible à la protection des sources. Un rapport HUMINT ne peut être propagé aux partenaires de coalition sans nettoyage de releasability.

Le moteur de fusion doit préserver les différences sémantiques entre ces disciplines, pas les écraser en un seul nombre de confiance. Une piste confirmée par IMINT et SIGINT est qualitativement différente d'une piste confirmée par deux gisements SIGINT. Le modèle de logiciel de renseignement de défense dans Les logiciels de renseignement de défense expliqués décrit comment le multi-INT façonne la plateforme plus large.

Corrélation de pistes : l'algorithme central

La décision d'ingénierie la plus lourde de conséquences dans une plateforme de fusion est la manière dont fonctionne la corrélation piste-à-piste. Deux modèles dominent, et la plupart des systèmes réels les combinent.

Association probabiliste de données. JPDA (Joint Probabilistic Data Association), MHT (Multiple Hypothesis Tracking) et leurs variantes calculent la vraisemblance qu'un rapport entrant appartienne à chaque piste candidate, étant donné les prédictions cinématiques et l'identité a priori. Elles gèrent les scénarios denses et ambigus — beaucoup de pistes proches, occlusions fréquentes, rapports intermittents — bien mieux que les méthodes basées sur des règles. Le coût est computationnel : MHT en particulier fait croître les hypothèses de manière exponentielle sans élagage, et le réglage des paramètres est un art.

Corrélation basée sur des règles. Heuristiques appliquées par ordre de priorité : correspondance d'identité l'emporte ; correspondance du gate cinématique dans la tolérance ; correspondance de compatibilité de source. Bon marché, explicable, facile à déboguer. Fragile à haute densité — une scène à 1 000 pistes avec des trajectoires croisées fréquentes produira de fausses corrélations ou des pistes fragmentées.

Le modèle hybride : la corrélation basée sur des règles gère les 90 % de cas non ambigus, l'association probabiliste est invoquée pour les 10 % contestés. La couche de règles agit également comme un filtre grossier qui maintient tractable l'espace d'hypothèses du moteur probabiliste.

Un problème plus subtil : quand deux pistes doivent fusionner, et quand une piste doit se scinder. Un navire qui a disparu du radar il y a une heure et qui réapparaît approximativement au bon endroit — est-ce la même piste reprise, ou une nouvelle piste ? Des réponses différentes ont des implications opérationnelles différentes. La réponse exige des seuils configurables liés au concept opérationnel, pas codés en dur.

Le pipeline de messagerie : épine dorsale de toute plateforme de fusion

Les plateformes de fusion déplacent de nombreux messages par seconde entre de nombreux composants. Le substrat de messagerie est une décision avec laquelle la plateforme vit toute sa vie opérationnelle.

Le modèle dominant : un log durable, ordonné et partitionné — Kafka, Pulsar ou NATS JetStream — transporte chaque observation, événement de fusion et action d'opérateur. Les consommateurs s'abonnent aux topics pertinents et traitent à leur propre rythme. Le rejeu est possible parce que le log est durable. L'audit est automatique parce que chaque événement est persisté en ordre.

Le choix a des compromis durs. Kafka est mature et bien compris opérationnellement, mais comporte un surcoût d'accréditation et des exigences de ressources qui dépassent un petit déploiement. NATS est léger et s'embarque bien dans les plateformes tactiques mais lui manque l'écosystème de Kafka. La comparaison détaillée et les recommandations de pattern sont dans Files de messages pour les pipelines de données de défense.

Une erreur courante : utiliser des requêtes/réponses HTTP entre les composants de fusion au lieu d'un bus de messages. Les appels synchrones couplent la disponibilité — si un composant est lent, chaque appelant cale. Les plateformes de fusion doivent absorber les surcharges de capteurs, les coupures réseau et les redémarrages de composants ; un bus de messages avec gestion de la backpressure est structurellement nécessaire, pas optionnel.

Event sourcing et audit : pourquoi l'append-only gagne

Dans les logiciels commerciaux, les journaux d'audit sont souvent une réflexion après coup. Dans les logiciels de renseignement de défense, ils sont au centre de l'architecture. Chaque observation, décision de fusion, appel de classification et action d'opérateur doit être reconstructible à partir de la piste d'audit — pour la revue après action, l'accréditation, les procédures légales et l'entraînement de la prochaine génération d'analystes et de modèles.

Le modèle : event sourcing. L'état faisant autorité du système est le log append-only des événements ; la base de données est une vue matérialisée par-dessus. Chaque changement est une entrée immuable, signée cryptographiquement. Les requêtes voyageant dans le temps — « que croyions-nous à 14h32 ? » — deviennent triviales. Le rejeu d'événements passés contre un nouvel algorithme de fusion donne des tests A/B propres. Le modèle détaillé est dans Event sourcing pour les pistes d'audit de défense.

L'erreur à éviter : greffer l'audit sur une base de données mutable. Une ligne qui enregistre « dernière mise à jour à 14h32 par l'utilisateur Smith » perd l'état antérieur, le raisonnement et la chaîne des décisions. Vous ne pouvez pas reconstruire ce que la plateforme a montré à un opérateur à 14h30. Les évaluateurs d'accréditation connaissent ce modèle et le rejettent.

Le backend géospatial : PostGIS et au-delà

La plupart des données de renseignement de défense sont géospatiales. Pistes, observations, zones d'opérations, terrain, infrastructures, zones de non-tir, historiques IED — toutes vivent en coordonnées spatiales. La base de données géospatiale est la partie de la plateforme que vous ne pouvez pas vous permettre de rater.

Le standard actuel par défaut est PostGIS sur PostgreSQL — open source, compatible avec l'accréditation, mature, gère des milliards de points avec une indexation appropriée, s'intègre à l'écosystème SQL. Pour la vision ingénierie de PostGIS en défense, incluant les stratégies d'index, le partitionnement et les charges qui le cassent, voir PostGIS pour les données géospatiales de défense.

PostGIS n'est pas approprié pour toute charge. Les flux de capteurs en séries temporelles (historiques de plots radar, télémétrie) appartiennent à TimescaleDB ou InfluxDB, interrogés conjointement avec PostGIS pour l'analyse spatio-temporelle combinée. L'imagerie et la vidéo full-motion vivent dans le stockage objet avec les métadonnées dans PostGIS. Les tuiles cartographiques pré-rendues, surtout pour le déploiement à l'edge tactique, vivent comme MBTiles ou PMTiles statiques — voir Cartes hors ligne avec MBTiles et PMTiles.

Un modèle de plateforme qui échoue de manière prévisible : mettre toute charge dans PostGIS parce que c'est pratique. Les requêtes géospatiales sur une table d'un milliard de lignes entrent en concurrence avec les écritures en séries temporelles ; les deux en souffrent. Séparez les charges, routez les requêtes de manière appropriée, et payez le coût opérationnel de faire tourner deux bases — c'est moins cher que la taxe de latence d'une seule base surchargée.

Analyse pattern-of-life : où l'IA aide véritablement

L'analyse pattern-of-life (PoL), ou analyse de comportements, est la pratique consistant à construire une référence comportementale pour une entité — navire, véhicule, personne, unité — et à signaler les déviations. Un navire marchand qui fait toujours escale dans les trois mêmes ports dévie soudain vers un quatrième : anomalie. Une unité militaire qui mène des exercices chaque mardi à 08h00 devient soudain silencieuse un mardi matin : anomalie. La technique passe à l'échelle, des navires individuels à des flottes entières, et des routes locales aux infrastructures nationales.

Le modèle d'ingénierie : ingérer des données longitudinales de pistes, segmenter le comportement en activités routinières, ajuster un modèle comportemental par entité, scorer les nouvelles observations contre le modèle. Le cœur algorithmique est une statistique peu glamour avec du ML sélectif — mélanges gaussiens, HMM, classifieurs gradient-boosted — augmenté de plus en plus par des modèles de deep learning sur des séquences brutes de trajectoires. La partie difficile n'est pas l'algorithme. C'est la curation des données, la définition opérationnelle d'« anomalie », et la gestion de la classification et de la revue éthique autour du profilage comportemental.

Le modèle détaillé, incluant les pipelines de données, le cycle de vie des modèles et l'intégration opérationnelle, est dans L'analyse pattern-of-life dans le renseignement militaire. Pour le pipeline IA/ML plus largement — déploiement de modèles, inférence à l'edge, tri ISR — voir L'IA pour le tri des données ISR, La vision par ordinateur dans les systèmes de défense, et Optimisation de modèles ONNX et TensorRT.

Sources de pistes ouvertes : AIS, ADS-B et la frontière civilo-militaire

Une plateforme de renseignement moderne ingère couramment des données de pistage civiles. AIS pour les navires, ADS-B pour les aéronefs — toutes deux sont des diffusions ouvertes destinées à la sécurité et à la gestion du trafic, mais toutes deux révèlent aussi des schémas d'activité militaire et de zone grise. Navires avec AIS éteint dans des zones suspectes, aéronefs émettant des codes transpondeur civils tout en volant selon des profils militaires — ce sont des signaux opérationnels.

Intégrer AIS et ADS-B dans une image de défense comporte des pièges d'ingénierie spécifiques. Les volumes de données sont importants — l'AIS mondial représente des centaines de millions de messages par jour. Le spoofing est courant et de plus en plus sophistiqué, en particulier dans les zones maritimes contestées. Corréler les trous d'AIS avec les pistes radar est à haute valeur mais algorithmiquement subtil. Le modèle complet est dans Intégrer AIS et ADS-B dans une image militaire.

Les défis d'intégration que la plupart des plateformes sous-estiment

Au-delà du cœur algorithmique, chaque plateforme de fusion de défense rencontre le même ensemble de défis d'intégration. Ils paraissent faciles sur un slide deck et sont responsables de la plupart des retards de programme.

Zoo des systèmes de coordonnées. WGS84 latitude/longitude, MGRS, UTM, références grille nationales, réalisations ITRF, grilles opérationnelles définies localement. Chaque source utilise quelque chose de légèrement différent. La plateforme doit convertir et arrondir de manière cohérente. Une erreur d'arrondi de 1 mètre à un endroit devient une erreur de 1 kilomètre après trois transformations.

Sémantique du temps. Les horodatages des capteurs peuvent être UTC, locaux, ou être l'heure de génération du message plutôt que l'heure d'observation. Le délai réseau entre observation et ingestion peut être de secondes, minutes ou heures. Le moteur de fusion doit raisonner sur les temps « as-of » et « as-known » séparément — les décisions opérationnelles dépendent des deux.

Propagation de la classification. Une piste dérivée d'une source SECRET et d'une source NON CLASSIFIÉ est SECRET. Une piste dérivée de sources FVEY uniquement et OTAN uniquement ne peut pas être pleinement libérée à l'une ou l'autre alliance. Le moteur de classification doit calculer correctement l'enveloppe fermée, à chaque requête, sans casser la latence du COP. Voir Défis du partage de données en coalition pour le côté politique.

Réconciliation d'identité. Un navire connu sous le nom de « MV Foxtrot » dans un flux peut être « Foxtrot-25 » dans un autre et « FOXTROT 25 » dans un troisième. Même numéro de coque, catalogues de capteurs différents. La normalisation d'identité est une part non triviale de la couche d'adaptateurs et une source fréquente de pistes en double.

Versionnement et évolution de schéma. Une plateforme pluriannuelle révisera le schéma canonique des pistes plusieurs fois. Le faire sans casser les adaptateurs, les consommateurs en aval ou le rejeu des données historiques exige de la discipline. L'évolution uniquement additive est la seule stratégie stable. L'ensemble plus large des défis est dans Défis d'intégration de données de défense.

Classification, releasability et la couche de contrôle d'accès

Une plateforme de fusion de défense est, structurellement, un système classifié. La plupart des données sont classifiées à l'ingestion ; la fusion peut élever la classification des pistes dérivées ; les marquages de releasability déterminent quels partenaires peuvent voir quels produits. La couche de contrôle d'accès n'est pas un bolt-on — c'est une des fondations.

Le modèle qui passe à l'échelle : contrôle d'accès basé sur des politiques, avec niveau de classification, compartiments, releasability, et attributs utilisateur (habilitation, citoyenneté, rôle) évalués à chaque requête. Application à la frontière de l'API et au niveau de la couche de requête de la base de données, jamais uniquement à l'UI. Chaque piste porte son ensemble de sources ; le moteur de politique calcule la classification effective au moment de la requête plutôt que de la figer dans la ligne.

Le traitement architectural plus profond du RBAC, de la classification et des compartiments pour le C2 est dans Contrôle d'accès basé sur les rôles dans les systèmes C2 de défense. Les mêmes principes s'appliquent à une plateforme de fusion, avec l'ajout que la fusion crée des données dérivées — le moteur doit raisonner sur la dérivation, pas seulement sur la source.

Disciplines adjacentes que l'architecte plateforme ne peut pas se décharger : ligne de base ISO 27001 pour le processus de développement (ISO 27001 dans les logiciels de défense), DevSecOps adapté aux cycles d'accréditation (DevSecOps pour les pipelines de défense), suivi de SBOM pour l'intégrité de la chaîne d'approvisionnement (SBOM dans les achats de défense), et la réalité du personnel habilité (Habilitation de sécurité pour les équipes logicielles).

Fusion de renseignement cyber : une discipline parallèle

De plus en plus, les plateformes de renseignement de défense incluent des données cyber — indicateurs de menace, exploitations observées, anomalies réseau. Les principes d'ingénierie de fusion se transposent, mais la sémantique des données diffère. Les observables cyber ont une durée de vie courte, sont souvent corrélés à travers de nombreuses entités, et bénéficient de l'intégration de flux de threat intelligence d'une manière que les données du domaine physique ne font pas.

Le modèle pour les plateformes Cyber Threat Intelligence (CTI) est dans Plateformes CTI pour la défense. L'intégration SIEM/SOAR pour l'image opérationnelle cyber est dans SIEM et SOAR pour l'intégration militaire. Le modèle plus large de connaissance de la situation cyber est dans Plateformes de connaissance de la situation cyber. ICS/OT — systèmes de contrôle industriel et technologies opérationnelles — est un problème de fusion spécialisé avec ses propres modèles de détection d'intrusion ; voir Détection d'intrusion ICS/OT dans les réseaux militaires.

La décision architecturale : construisez-vous une plateforme unique qui fusionne les domaines physique et cyber, ou deux plateformes avec un pont de partage ? La tendance, accélérée par les mandats de type JADC2, va vers les plateformes unifiées. La réalité d'ingénierie est que la sémantique des données, les latences et les workflows opérateur diffèrent suffisamment pour que même les plateformes unifiées aient souvent des pipelines distincts côté physique et côté cyber en interne.

De la fusion à l'image opérationnelle commune

La fusion est en amont du COP. Le COP est l'artefact face à l'utilisateur ; la fusion est la machinerie de confiance derrière. L'interface entre eux est le schéma canonique des pistes et le flux publish-subscribe des changements d'état de pistes.

Pour le côté COP de l'architecture, voir Image opérationnelle commune : comment elle se construit dans les logiciels de défense modernes et Rendu cartographique en temps réel pour C2 militaire. Le cadrage C2 plus large — la fusion comme partie d'une architecture à quatre couches — est dans Le guide complet des systèmes de commandement et contrôle (C2) et Qu'est-ce qu'un système C2 ?. Pour l'interopérabilité OTAN des produits de données générés par la fusion, voir Standards d'interopérabilité OTAN pour les logiciels et Structures de données ADatP-34.

Build, buy, configure : considérations spécifiques à la fusion

Le build-vs-buy en fusion a des arêtes plus tranchantes que dans le logiciel C2 général. Le moteur de fusion central est mathématiquement dense, difficile à tester et dangereux à rater — et le marché commercial compte un petit nombre d'offres matures avec des algorithmes éprouvés opérationnellement. La coquille COP, l'ingestion de données et l'outillage analyste autour du moteur sont bien plus propices à un build interne.

Le modèle courant : licencier un moteur de fusion, construire tout le reste autour. Cela évite le risque d'ingénierie le plus coûteux (les algorithmes de corrélation) tout en préservant le contrôle souverain du modèle de données, de l'UX et de l'intégration. Les critères de sélection de fournisseur sont couverts dans Comment choisir un fournisseur de logiciels de défense ; la réalité plus large des achats dans Achats de défense : de l'AO au contrat.

Le cas du build pur s'applique lorsque le concept opérationnel nécessite une sémantique de fusion qu'aucun produit commercial ne supporte — par exemple, une image de guerre irrégulière où les entités ne sont pas les navires-aéronefs-véhicules que les moteurs de fusion commerciaux modélisent. Les leçons d'Ukraine dans Transformation numérique de la défense : leçons d'Ukraine sont particulièrement instructives sur la construction d'une fusion souveraine à partir de zéro lorsque les options commerciales ne correspondent pas à la réalité opérationnelle.

Directions futures : fusion ML-native, federated learning et inférence à l'edge

Le domaine est en transition. La fusion probabiliste traditionnelle reste la ligne de base opérationnelle, mais les approches ML-natives progressent : trackers neuronaux end-to-end qui apprennent le problème d'association à partir des données, résolution d'identité basée sur transformers à travers les modalités, résumés par grands modèles d'images fusionnées pour les briefings analystes.

L'évaluation honnête : la fusion ML-native n'est pas encore opérationnellement de confiance aux niveaux où le sont les méthodes probabilistes. Les modes de défaillance sont différents — silencieusement faux plutôt que bruyamment manquants — et plus difficiles à repérer pour un opérateur. Les systèmes hybrides, avec le ML fournissant des associations candidates à un vérificateur probabiliste, sont la voie réaliste à court terme.

Le federated learning est plus mature. Entraîner des modèles pertinents pour la fusion à travers des données distribuées et partiellement classifiées sans centraliser les données est une capacité réelle. Le modèle est dans Federated learning pour les capteurs militaires. Les données synthétiques, utiles pour l'entraînement là où les données réelles sont rares ou sensibles, sont couvertes dans Données synthétiques pour l'IA de défense. L'IA embarquée — exécuter l'inférence au capteur ou à la plateforme plutôt que centralement — remodèle la topologie de fusion, en particulier pour les plateformes tactiques ; voir Cas d'usage militaires de l'IA embarquée et Comparaison du matériel d'IA embarquée.

L'intégration des LLM dans les workflows de renseignement est à la frontière expérimentale. Prometteur pour la synthèse face aux analystes et l'interrogation en langage naturel des magasins de renseignement ; moins prometteur pour les décisions de fusion autonomes où des pistes hallucinées seraient catastrophiques. Voir LLM dans le tri du renseignement pour l'application réaliste et les garde-fous.

Lectures recommandées : la carte complète de la fusion

Ce guide reste au niveau architectural. Les articles focalisés ci-dessous traitent en profondeur des sections individuelles.

Fondations de la fusion : Fusion de données militaires expliquée, Modèle de fusion de données JDL, Défis d'intégration de données de défense.

Ingénierie des données : Files de messages, Event sourcing, PostGIS pour la défense.

Sources de pistes et analyse : Intégration AIS et ADS-B, Analyse pattern-of-life.

Contexte plus large des logiciels de renseignement : Les logiciels de renseignement de défense expliqués, Architecture mission-critique, Dette technique.

Fusion cyber et OSINT : Plateformes CTI, Surveillance des menaces OSINT, SIEM/SOAR, Connaissance de la situation cyber, Détection d'intrusion ICS/OT, Forensique numérique.

IA/ML pour la fusion : Tri des données ISR, Vision par ordinateur, Federated learning, Tri du renseignement par LLM, Données synthétiques.

Connecter la fusion au C2 et à l'interopérabilité : Guide complet des systèmes C2, COP, Plateforme C4ISR, Partage de données en coalition.