Fusionner le renseignement issu du SIGINT, de l'IMINT, du HUMINT et de l'OSINT en une image unique et cohérente semble simple en théorie. Dans la pratique, c'est l'un des problèmes d'ingénierie les plus difficiles de l'infrastructure de données de défense. Chaque discipline produit des données à une vitesse différente, dans un format différent, avec un modèle de confiance différent — et un système qui se contente d'agréger ces flux sans vraiment les corréler produit une image plus bruyante qu'un flux mono-INT bien géré, et non une meilleure image. Une intégration de données pour le renseignement de défense sérieuse exige une architecture conçue dès les premiers principes autour des propriétés de chaque type de source, et non un entrepôt de données générique auquel on aurait ajouté des adaptateurs INT.

Cet article parcourt l'architecture complète d'un système de fusion multi-sources en temps réel — de la couche d'ingestion de flux qui absorbe les apports hétérogènes, en passant par la résolution d'entités et le moteur de corrélation, jusqu'au calcul de la confiance et à la publication d'une image du renseignement enrichie vers les systèmes C2. Chaque section traite des choix de conception spécifiques qui séparent une fusion de qualité industrielle des systèmes prototypes qui semblent corrects en démonstration mais échouent à l'échelle opérationnelle.

Le problème de la fusion multi-sources du renseignement — pourquoi fusionner SIGINT/IMINT/HUMINT/OSINT est plus difficile qu'il n'y paraît

Trois problèmes structurels rendent la fusion multi-sources qualitativement plus difficile que le traitement d'une INT individuelle à grande échelle. Les ignorer — traiter la fusion comme un simple problème de pipeline de données — est l'erreur d'architecture la plus courante, et cela produit un système qui ne peut plus être corrigé une fois les données en production.

L'hétérogénéité des formats est le problème le plus visible. Un enregistrement d'interception ELINT porte la fréquence de l'émetteur, l'intervalle de répétition des impulsions, le type de balayage, le relèvement et les données de différence de temps d'arrivée. Une détection IMINT porte une boîte englobante, un score de confiance en espace pixel, une distance d'échantillonnage au sol et une coordonnée UTM avec le CEP associé. Un extrait narratif HUMINT porte du texte libre, une note de source d'analyste, un lieu nommé et une fenêtre temporelle mesurée en heures ou en jours. Ces trois enregistrements peuvent tous désigner le même objet du monde réel — un véhicule radar — mais ils n'ont aucun champ commun, aucune convention de système de coordonnées commune et aucun identifiant commun. Les normaliser en un schéma canonique unique exige des adaptateurs dédiés à chaque type de source et un modèle d'entité canonique capable de tous les accueillir sans en réduire la sémantique. La conception du modèle de données de fusion de capteurs multi-INT militaire couvre cette couche canonique en détail.

L'inadéquation des confiances est plus subtile mais provoque davantage d'erreurs d'analyse. Chaque INT applique son propre modèle de confiance. La géolocalisation SIGINT porte un CEP (Circular Error Probable, erreur circulaire probable) en mètres — une estimation de précision géométrique. La détection IMINT porte une probabilité de classifieur — le logit de sortie du réseau de neurones pour la classe d'objet. Le HUMINT porte une note de fiabilité admiralty — une échelle de jugement humain à six points. Ces trois nombres ont des sens fondamentalement différents. Un système de fusion naïf qui les moyenne produit un nombre mathématiquement valide mais analytiquement dépourvu de sens. Un modèle de confiance correct doit d'abord traduire chaque confiance native de la source dans un cadre probabiliste commun, puis agréger les sources selon un schéma bayésien ou de combinaison de preuves (comme Dempster-Shafer) qui traite correctement les preuves dépendantes et indépendantes.

Le décalage temporel est le problème qui rompt le plus visiblement les architectures de fusion en temps réel. Les latences entre l'occurrence d'un événement et l'arrivée des données dans le pipeline varient considérablement d'une source à l'autre. Une interception SIGINT peut arriver dans le pipeline dans les secondes suivant la transmission. L'IMINT d'un satellite taské peut exiger 60–90 minutes de traitement d'imagerie avant de produire un enregistrement de détection. Un rapport HUMINT décrivant les événements d'hier peut être ingéré au jour D+2. Un moteur de fusion qui corréle les enregistrements par horodatage d'arrivée dans le pipeline associera systématiquement mal les événements — il ne parviendra pas à lier l'interception SIGINT et la confirmation IMINT parce qu'elles sont arrivées à 90 minutes d'écart, même si elles décrivent le même événement. L'architecture doit séparer le temps d'événement (quand l'événement s'est produit dans le monde) du temps d'ingestion (quand le message est arrivé dans le pipeline) et effectuer toute la corrélation temporelle sur le temps d'événement, en n'utilisant le temps d'ingestion que pour le suivi des performances du pipeline.

Architecture d'ingestion de flux — Kafka face à Pulsar pour les flux de renseignement, registre de schémas pour les types de messages hétérogènes, gestion de la contre-pression

La couche d'ingestion de flux doit traiter des messages arrivant à des cadences allant de quelques rapports HUMINT par heure à des millions d'enregistrements SIGINT par heure provenant d'un seul système de collecte, tous vers le même pipeline de fusion. La conception doit absorber les trafics en rafale des sources à haute vélocité sans appliquer cette contre-pression aux sources à faible vélocité et haute priorité — un rapport HUMINT qui arrive en rafale aux côtés d'un flux massif de SIGINT ne doit pas être retardé parce que le pipeline est saturé.

Le principal choix d'architecture à cette couche se situe entre Apache Kafka et Apache Pulsar. Tous deux sont distribués, tolérants aux pannes et éprouvés à l'échelle des systèmes de défense. Kafka dispose d'un écosystème plus large et d'une intégration plus étroite avec les frameworks de traitement de flux — Kafka Streams et Apache Flink disposent tous deux de connecteurs sources Kafka de première classe. Pulsar offre une multi-location native, l'isolation des topics par espace de noms et une architecture calcul-stockage séparée. Pour une plateforme de fusion mono-location opérant dans un seul domaine de classification, Kafka est le choix pragmatique. Pour une plateforme qui doit isoler les flux par niveau de classification, prendre en charge des nœuds déployés en avant, déconnectés, qui se synchronisent de manière asynchrone vers un cluster de l'échelon arrière, ou servir plusieurs organisations locataires, l'architecture de Pulsar fournit des primitives d'isolation plus propres sans contournements ad hoc.

Quel que soit le choix du broker, la structure des topics doit imposer un topic par type de source, et non un topic par discipline INT :

# Convention de nommage des topics : {classification}.{int-type}.{source-id}.raw ts.sigint.comint-system-alpha.raw ts.sigint.elint-collection-bravo.raw ts.imint.uav-sensor-charlie.raw ts.imint.sat-proc-delta.raw ts.humint.field-reports.raw ts.osint.ais-feed.raw ts.osint.social-monitor.raw # Topics de sortie normalisés (post-adaptateur) ts.fusion.observations.normalized ts.fusion.entities.enriched ts.fusion.correlations.output

Un registre de schémas est obligatoire pour les topics de sortie normalisés. Sans schémas imposés, un seul message malformé issu de n'importe quel adaptateur peut corrompre le contexte de désérialisation d'un consommateur en aval et bloquer tout le pipeline de fusion. Le registre impose des schémas Avro ou Protobuf à chaque écriture sur les topics de fusion et rejette les messages qui échouent à la validation avant qu'ils n'atteignent le broker. Les règles de compatibilité de schéma — BACKWARD, FORWARD ou FULL — doivent être définies par topic en fonction de l'évolution des consommateurs. Pour le schéma d'observation normalisé, la compatibilité BACKWARD est appropriée : les nouvelles versions de schéma peuvent ajouter des champs optionnels, et les anciens consommateurs qui ne comprennent pas les nouveaux champs continuent de fonctionner correctement.

La gestion de la contre-pression exige des limites de débit par type de source avec une classification de priorité. Les sources à haute priorité — SIGINT et IMINT issus de systèmes de collecte en direct — ne doivent jamais être limitées. Les sources à faible priorité — ingestion OSINT en masse, chargement de HUMINT historique — doivent porter des pondérations de priorité explicites qui permettent au broker de réguler leurs consommateurs lorsque le débit du pipeline est contraint. Dans Kafka, cela s'implémente via des quotas de groupes de consommateurs et des stratégies d'affectation de partitions. Dans Pulsar, les limites de débit par espace de noms et les quotas de distribution fournissent un contrôle équivalent. Les motifs d'architecture de pipeline de données de renseignement militaire couvrent en profondeur la gestion des files et la conception des groupes de consommateurs.

Résolution d'entités et déduplication — stratégies de blocage pour la génération de candidats, scoring de similarité par apprentissage automatique, fusion d'entités fondée sur les graphes

La résolution d'entités est le composant qui transforme un flux d'observations indépendantes — chacune décrivant un objet détecté ou un événement signalé — en un ensemble d'enregistrements d'entités unifiés où toutes les observations concernant le même objet du monde réel ont été fusionnées. C'est le composant le plus difficile à bien faire et celui qui a le plus de chances de se dégrader silencieusement : un système à la résolution d'entités médiocre ne plante pas ; il produit une image avec trop d'entités (pistes fragmentées) ou trop peu (fausses fusions), et ces erreurs s'accumulent au fil du temps car la fusion s'appuie sur un état d'entité corrompu.

L'approche naïve — comparer chaque observation entrante à chaque entité existante — est computationnellement infaisable à toute échelle réaliste. Un système de collecte ELINT produisant 10 000 enregistrements d'interception par minute face à un corpus de 50 000 pistes d'entités actives exigerait 500 millions de comparaisons par minute avant tout scoring de similarité. Les stratégies de blocage réduisent cela à un ensemble de candidats traitable en exploitant la structure des données de renseignement :

  • Blocage par cellule géographique — indexez chaque entité selon sa position estimée à l'aide d'une grille hexagonale H3 au niveau de résolution 9 (cellules d'environ 0,1 km²). Une observation entrante ne génère de paires candidates que face aux entités de la même cellule et de ses six voisines immédiates. Cette seule clé de blocage élimine plus de 99,9 % des paires candidates pour les données spatiales tout en atteignant un rappel élevé pour les observations réellement colocalisées.
  • Blocage temporel — restreignez les candidats aux entités dont l'intervalle de temps de validité chevauche une fenêtre configurable autour du temps d'événement de l'observation. Pour un véhicule en mouvement, la fenêtre doit tenir compte de la vitesse maximale plausible entre la dernière observation et la position de l'observation actuelle — un char ne peut pas parcourir 50 km en 5 minutes. Un blocage temporel sans blocage par cellule géographique produit des ensembles de candidats énormes pour toute entité active à l'échelle mondiale ; les deux fonctionnent ensemble comme une clé composée.
  • Blocage par identifiant fort — regroupez tous les enregistrements partageant un identifiant déterministe (IMSI, sortie OCR de plaque d'immatriculation, empreinte biométrique, code de transpondeur Mode-S d'aéronef) en un seul grappe de candidates, quelle que soit la position ou le moment. Les identifiants forts contournent tout autre blocage et sont traités comme des signaux de fusion définitifs, sous réserve d'une vérification de déduplication sur l'identifiant lui-même.
  • Blocage par affinité de type INT — certaines paires inter-INT sont structurellement peu susceptibles de correspondre et ne doivent pas être notées. Une observation d'émission SIGINT maritime ne doit pas être notée face à une piste IMINT de véhicule terrestre. Les règles d'affinité, définies par type d'entité, éliminent les paires candidates structurellement implausibles avant le scoring.

Le scoring de similarité des paires candidates utilise un modèle de gradient boosting (XGBoost ou LightGBM) entraîné sur des paires appariées/non appariées étiquetées issues de données de renseignement historiques. Les vecteurs de caractéristiques incluent : la distance spatiale normalisée par l'incertitude de position, la distance temporelle normalisée par l'enveloppe de vitesse du type d'entité, le score de recouvrement d'attributs pour les attributs typés (classe d'entité, appartenance, type d'équipement) et la pondération de compatibilité de type INT. Le modèle produit une probabilité d'appariement dans [0, 1]. Les paires au-dessus d'un seuil élevé (généralement 0,85–0,92) sont fusionnées automatiquement ; les paires dans une bande intermédiaire sont routées vers une revue d'analyste ; les paires en dessous d'un seuil bas sont traitées comme des entités distinctes.

La fusion d'entités fondée sur les graphes traite le cas multi-voies — où trois observations ou plus doivent toutes être résolues vers la même entité. Un graphe est maintenu où les nœuds sont des enregistrements d'observation et les arêtes des décisions de fusion avec les scores de confiance associés. Les composantes connexes du graphe représentent les grappes d'entités candidates. L'enregistrement de référence de chaque grappe est calculé en appliquant la politique de fusion définie à toutes les observations contributrices. Lorsqu'une nouvelle arête à haute confiance est ajoutée et relie deux composantes auparavant disjointes, les composantes sont fusionnées et leurs enregistrements de référence combinés. La représentation en graphe permet aussi les opérations de scission : retirer une arête à haute confiance et recalculer les composantes connexes est le mécanisme de correction d'une fausse fusion.

Référence d'architecture
Pipeline de résolution d'entités — enchaînement des étapes
1
Blocage — Générez des paires candidates via les clés géographique, temporelle et d'identifiant fort. Objectif de rappel : >99,5 % des vrais appariements dans l'ensemble de candidats.
2
Extraction de caractéristiques — Calculez la distance spatiale, le delta temporel, le recouvrement d'attributs et la compatibilité de type INT pour chaque paire candidate.
3
Scoring par apprentissage automatique — Le modèle de gradient boosting produit la probabilité d'appariement par paire. Les paires à identifiant fort contournent le scoring et vont directement à la fusion.
4
Routage par seuil — Score ≥ 0,88 : fusion automatique. 0,55–0,87 : file de revue d'analyste. < 0,55 : rejet (entités distinctes).
5
Fusion par graphe — Mettez à jour le graphe d'entités avec de nouvelles arêtes ; recalculez les enregistrements de référence des composantes connexes ; émettez les entités mises à jour vers le flux d'entités enrichies.
Pipeline de résolution d'entités en cinq étapes, de la génération de candidats jusqu'à la publication de l'enregistrement de référence.

Conception du moteur de corrélation — corrélation par fenêtres (proximité temporelle), corrélation spatiale (partitionnement par cellule géographique), corrélation sémantique (appariement d'attributs d'entité)

Là où la résolution d'entités demande « ces observations concernent-elles le même objet ? », le moteur de corrélation demande « ces événements impliquant des objets différents forment-ils un motif significatif ? ». Un véhicule détecté près d'un dépôt logistique, suivi 20 minutes plus tard du même véhicule à un point de carburant, suivi d'une interception SIGINT d'un appel radio cohérent avec un rapport de position d'unité depuis le point de carburant — ces trois événements impliquent le même véhicule mais décrivent aussi un motif situationnel (activité de ravitaillement) analytiquement plus significatif que toute observation isolée. Le moteur de corrélation produit cet objet de renseignement d'ordre supérieur.

La corrélation opère simultanément sur trois plans :

La corrélation temporelle regroupe les événements en fenêtres selon leur horodatage d'événement et recherche des motifs de cooccurrence dans chaque fenêtre. La définition de la fenêtre est configurable par règle : une règle détectant un début de brouillage simultané et une rupture des communications amies peut utiliser une fenêtre de 30 secondes ; une règle détectant un véhicule à un point de passage suivi d'un autre véhicule au même point de passage peut utiliser une fenêtre de 2 heures. Les fenêtres glissantes (qui se chevauchent de la moitié de la durée de la fenêtre) garantissent que les événements aux limites de fenêtre ne sont pas manqués. La fenêtrage en temps d'événement d'Apache Flink avec watermarks est le choix d'implémentation standard car il traite correctement l'arrivée désordonnée des événements — critique pour un pipeline où l'IMINT et le HUMINT ont des latences d'ingestion très différentes.

La corrélation spatiale regroupe les entités selon leur position estimée à l'aide d'un partitionnement par cellule géographique à une résolution calibrée sur l'échelle spatiale de la règle de corrélation. La résolution H3 au niveau 8 (environ 0,7 km²) convient pour détecter des véhicules opérant dans la même zone ; la résolution H3 au niveau 6 (environ 36 km²) pour détecter des motifs d'activité à l'échelle d'une région. Contrairement au blocage par cellule géographique de la résolution d'entités (qui a besoin d'un rappel élevé), le partitionnement spatial de la corrélation a besoin d'une précision définie par la règle : une règle de corrélation détectant la colocalisation d'un véhicule de commandement et d'un véhicule logistique doit utiliser une cellule plus fine qu'une règle détectant une activité de ravitaillement à l'échelle d'une zone. Les règles encodent leur propre paramètre de résolution spatiale plutôt que d'hériter d'un réglage global.

La corrélation sémantique apparie les entités sur la base des valeurs d'attributs plutôt que de la proximité spatiale ou temporelle. Une entité classée comme radar de défense aérienne qui commence à émettre, corrélée à une entité classée comme aéronef de combat entrant dans la zone de couverture du radar — la corrélation est pilotée par la sémantique des attributs (type de radar face au type d'aéronef et à la trajectoire), et non par leur colocalisation. Les règles sémantiques encodent des prédicats d'attributs sur les types d'entités : entity.type == EQUIPMENT AND entity.attributes.role == AIR_DEFENSE AND entity.activity_state == EMITTING. Ces expressions de prédicats sont évaluées par le processeur de flux sur chaque événement de mise à jour d'entité ; lorsque tous les prédicats d'une règle se déclenchent dans la fenêtre, la corrélation se déclenche.

Les règles de corrélation sont stockées sous forme de définitions déclaratives dans un registre de règles, et non comme une logique codée en dur. Cela permet aux analystes du renseignement de rédiger de nouvelles règles sans intervention de l'ingénierie, et autorise l'application des changements de règles sans redéployer le moteur de corrélation :

# Exemple de définition de règle de corrélation (YAML) rule_id: RESUPPLY-PATTERN-001 name: "Détection de séquence de ravitaillement de véhicule" description: "Détecte un véhicule visitant un nœud logistique suivi d'un point de carburant dans la fenêtre" confidence_weight: 0.72 spatial_resolution: H3_LEVEL_8 temporal_window_minutes: 90 events: - alias: VEH entity_type: EQUIPMENT attribute_predicates: - "attributes.platform_class IN [APC, IFV, TRUCK, LOGISTICS_VEHICLE]" - alias: NODE_VISIT entity_type: EVENT attribute_predicates: - "attributes.event_class == LOCATION_VISIT" - "attributes.location_type IN [LOGISTICS_NODE, DEPOT, FUEL_POINT]" linked_entity: VEH temporal_order: AFTER VEH.last_seen output: entity_type: SITUATION situation_class: RESUPPLY_ACTIVITY contributing_entity_refs: [VEH.entity_id, NODE_VISIT.entity_id]

Chaque corrélation déclenchée produit une entité Situation — un nouvel objet de renseignement de la couche JDL Level 2 qui référence les UUID des entités contributrices, porte l'identifiant de la règle et sa pondération de confiance, et est publiée dans le flux d'entités enrichies aux côtés des mises à jour d'entités standard.

Calcul de la confiance et provenance — matrice fiabilité de la source × crédibilité de l'information (système d'amirauté de l'OTAN), propagation de la confiance entre les entités fusionnées

Chaque entité de l'image fusionnée porte un score de confiance, mais la confiance dans un système de fusion multi-sources n'est pas un nombre unique — c'est un composite qui doit être décomposé selon plusieurs dimensions pour être analytiquement utile. Un score de 0,73 produit par trois enregistrements SIGINT corroborants signifie quelque chose de très différent d'un score de 0,73 provenant d'un seul rapport HUMINT non fiable et de rien d'autre. L'architecture doit préserver la décomposition, pas seulement l'agrégat.

Le modèle de confiance superpose trois entrées. Premièrement, la pondération de fiabilité de la source dérivée de la note de fiabilité de la source du système d'amirauté de l'OTAN : A=1.0, B=0.8, C=0.6, D=0.4, E=0.2, F=0.1. Cette pondération met à l'échelle la contribution de chaque observation source au calcul de fusion. Deuxièmement, la pondération de crédibilité de l'information dérivée de la note de crédibilité admiralty : 1=1.0, 2=0.8, 3=0.6, 4=0.4, 5=0.2, 6=0.1. Cette pondération est appliquée par observation, indépendamment de la fiabilité de la source, car une source fiable peut rapporter une information incertaine. Troisièmement, le score d'accord inter-sources — la fraction des sources corroborant indépendamment qui s'accordent sur la valeur de l'attribut clé, pondérée par leur fiabilité de source. Une valeur de position corroborée par trois sources notées A avec des notes d'information B2 obtient un score très différent d'une valeur corroborée par deux sources notées E avec des notes D4.

La confiance composite d'un attribut est :

# Formule de confiance par attribut fusionné # Pour chaque observation contributrice i : # w_i = source_reliability_weight(admiralty_grade_A_to_F) # × info_credibility_weight(admiralty_grade_1_to_6) # # Score d'accord pondéré : # agreement = sum(w_i for i in corroborating sources) # / sum(w_i for i in all contributing sources) # # Confiance de fusion : # confidence = agreement × source_coverage_penalty # # où source_coverage_penalty pondère à la baisse la corroboration mono-INT : # 1.0 si ≥ 2 types INT distincts corroborent # 0.75 si exactement 1 type INT avec ≥ 2 sources # 0.5 si exactement 1 source au total

La propagation de la confiance entre les entités dérivées suit une règle de dilution : une entité Situation dérivée par le moteur de corrélation à partir de deux enregistrements de référence d'entités contributrices ne peut pas avoir une confiance supérieure à celle de l'entité contributrice la moins fiable. La confiance ne peut augmenter que lorsque des observations corroborantes indépendantes supplémentaires sont ajoutées aux entités contributrices. Cela empêche le moteur de corrélation d'artificiellement gonfler la confiance en liant des entités de faible qualité.

Les liens de provenance sont stockés sous forme de chaîne : chaque enregistrement de référence référence les UUID des observations qui y ont contribué ; chaque observation référence son identifiant de source, son système de collecte et ses notes admiralty. La chaîne est immuable — elle n'est jamais mise à jour en place. Lorsqu'une source contributrice est ultérieurement jugée non fiable ou trompeuse, la chaîne fournit l'ensemble complet des entités qui doivent être réévaluées en excluant les contributions de cette source. La rétractation d'une source est une opération de premier rang, et non une procédure d'urgence.

Publication de l'image du renseignement — publication d'entités enrichies vers les systèmes C2 via CoT/NIEM, objectifs de latence pour le renseignement sensible au temps

Le flux d'entités enrichies est la représentation interne. La publication convertit cette représentation dans les formats de transmission que les systèmes C2 et les consommateurs en aval comprennent réellement. Pour la plupart des déploiements de défense, cela signifie Cursor on Target (CoT) pour les données de pistes et des formats de messages fondés sur NIEM pour les rapports de renseignement structurés.

La publication CoT associe chaque mise à jour d'entité enrichie à un événement CoT. La correspondance doit traiter trois types de mises à jour : les mises à jour de position (nouvelles coordonnées avec incertitude mise à jour), les mises à jour d'attributs (changement de confiance, changement d'état d'activité, changement d'évaluation d'appartenance) et les événements de cycle de vie de l'entité (création d'entité, retrait, et événements de scission/fusion). Les mises à jour de position sont directes — elles se traduisent par un événement de point CoT avec la position estimée de l'entité et la confiance de position encodée dans le champ d'erreur CoT. Les mises à jour d'attributs se traduisent par des remarques CoT ou des mises à jour d'éléments de détail sur l'entité existante. Les événements de cycle de vie — en particulier la fusion et la scission — exigent un traitement particulier : un événement de fusion retire la piste CoT de l'entité la moins fiable et met à jour le détail CoT de l'entité survivante avec les informations de provenance ; un événement de scission crée une nouvelle piste CoT pour l'entité nouvellement séparée.

Le champ de délai d'expiration CoT (stale time) est le mécanisme naturel de gestion du TTL côté récepteur C2. Chaque événement CoT publié définit stale_time à entity_publication_time + entity_TTL. Le système C2 récepteur (ATAK, CURSOR ou similaire) retire l'entité de son affichage lorsque stale_time est dépassé sans actualisation. Le système de fusion doit garantir que les entités dotées d'observations actives reçoivent des événements d'actualisation CoT à un intervalle plus court que leur TTL — typiquement à 50 % du TTL — pour éviter que des entités valides ne disparaissent de l'image en fonctionnement normal.

Les objectifs de latence déterminent la manière d'implémenter la couche de publication. Pour les workflows de ciblage sensibles au temps, la latence de bout en bout de l'événement capteur à l'affichage C2 doit être inférieure à 30 secondes. Pour y parvenir : des workers de publication asynchrones et non bloquants ; une sérialisation CoT parallélisée sur les partitions d'entités ; des files de sortie priorisées qui donnent la priorité aux pistes mobiles à haute confiance sur les mises à jour d'entités statiques ; et une livraison TCP multicast directe aux destinataires C2 plutôt qu'un polling d'API REST. Pour la conscience situationnelle générale au niveau opérationnel, une latence de 60–120 secondes est généralement acceptable, ce qui permet des motifs de publication par lots synchrones plus simples.

La publication NIEM sert les consommateurs de rapports de renseignement — les systèmes qui ont besoin d'évaluations du renseignement structurées et lisibles par machine plutôt que de données de pistes. Une entité Situation produite par le moteur de corrélation est publiée sous forme de NIEM Intelligence Message, avec les UUID des entités contributrices comme références, la classe de situation comme sujet, et les données de confiance et de provenance dans le bloc de métadonnées du message NIEM. Les consommateurs NIEM incluent les plateformes de partage de renseignement multi-domaines, les passerelles d'interopérabilité vers les systèmes des nations partenaires et les systèmes d'archivage qui exigent une provenance structurée pour la conformité d'audit.

Gestion de l'incertitude temporelle et du renseignement périmé — gestion du TTL pour les entités de renseignement, courbes de décroissance de la confiance de position/activité, déclencheurs de réévaluation

Le renseignement est périssable. Un rapport de position pour une piste de véhicule qui était exact il y a 20 minutes l'est moins maintenant — le véhicule a pu se déplacer. Une évaluation d'activité fondée sur une seule interception SIGINT il y a 4 heures peut ne plus refléter le comportement actuel. Un système de fusion qui ne modélise pas cette dégradation et ne la propage pas à l'image publiée amènera les analystes à prendre des décisions fondées sur des informations périmées avec des scores de confiance élevés obtenus par des observations plus anciennes.

La gestion du TTL commence par l'affectation du TTL à la création de l'entité. Les valeurs de TTL sont spécifiques au type d'entité et au niveau de confiance :

  • Piste de véhicule mobile à confiance élevée (confiance ≥ 0,80, classe de mobilité = WHEELED/TRACKED) : TTL 8–15 minutes
  • Piste mobile à confiance moyenne (confiance 0,50–0,79) : TTL 4–8 minutes
  • Piste provisoire à confiance faible (confiance < 0,50) : TTL 2–4 minutes
  • Installation fixe à confiance élevée (confiance ≥ 0,80, classe de mobilité = STATIC) : TTL 24–72 heures
  • Entité de personnel (fondée sur l'activité, non sur la position) : TTL 30–120 minutes selon le type de dernière activité
  • Entité Situation (corrélation dérivée) : TTL égal au TTL le plus court de toute entité contributrice, plafonné à 60 minutes

Les courbes de décroissance de la confiance modélisent la façon dont la confiance de position et d'activité se dégrade entre les observations confirmantes. Plutôt qu'un état binaire actif/périmé, la courbe de décroissance fournit une fonction de confiance continue en fonction du temps écoulé depuis la dernière observation :

# Décroissance de la confiance de position — modèle exponentiel # c(t) = c_0 × exp(-λ × t) # où : # c_0 = confiance au moment de la dernière observation confirmante # t = temps écoulé depuis la dernière observation (secondes) # λ = constante de décroissance, propre au type d'entité # # Constantes de décroissance (illustratives) : # TRACKED_VEHICLE: λ = 0.003 (demi-vie ≈ 3.8 min) # WHEELED_VEHICLE: λ = 0.004 (demi-vie ≈ 2.9 min) # SLOW_MOVER: λ = 0.001 (demi-vie ≈ 11.5 min) # STATIC_SITE: λ = 0.00001 (demi-vie ≈ 19 heures) # MARITIME_SURFACE: λ = 0.002 (demi-vie ≈ 5.8 min) # # L'entité passe à STALE lorsque c(t) < staleness_threshold # (généralement 0.15 pour les pistes mobiles, 0.05 pour les sites statiques)

Les déclencheurs de réévaluation se déclenchent lorsqu'une nouvelle observation arrive, spatialement et temporellement cohérente avec une entité périmée. Plutôt que de créer une nouvelle entité pour la nouvelle observation, le déclencheur la route dans le pipeline de résolution d'entités face à l'entité périmée comme candidate. Si la confiance d'appariement dépasse le seuil de fusion, la nouvelle observation actualise l'entité périmée : l'horloge du TTL est réinitialisée, la confiance est recalculée à partir de la nouvelle observation (éventuellement à la hausse depuis la valeur dégradée, si la nouvelle observation a une confiance forte), et l'entité repasse du statut STALE au statut ACTIVE. L'actualisation est journalisée comme événement de mise à jour dans la piste d'audit de l'entité.

Le modèle de décroissance doit aussi être communiqué aux consommateurs C2, et non seulement appliqué en interne. Publier une position à haute confiance dans CoT sans signaler que la position a 18 minutes amène l'affichage C2 à montrer une icône de piste nette et confiante que l'analyste peut interpréter comme une observation en temps réel. Deux mécanismes répondent à cela : le champ CoT stale_time (déjà évoqué) garantit que l'entité disparaît de l'affichage lorsqu'elle est définitivement périmée ; et un champ d'âge depuis la dernière observation publié dans l'élément de détail CoT donne à l'analyste une visibilité en temps réel sur l'âge de l'observation sous-jacente, même pour les entités qui n'ont pas encore atteint leur délai d'expiration. Certains systèmes C2 utilisent ce champ pour moduler la représentation visuelle de la confiance — faisant varier l'opacité ou la taille de l'icône de piste en fonction de l'âge de l'observation.

Ensemble, les sept composants d'architecture décrits dans cet article — ingestion de flux hétérogènes, normalisation imposée par schéma, résolution d'entités par blocage et apprentissage automatique, moteur de corrélation multi-plans, calcul de confiance par couches, publication CoT/NIEM et gestion de la décroissance du TTL — constituent une plateforme complète de fusion multi-sources du renseignement en temps réel. Aucun de ces composants n'est individuellement novateur. Ce qui rend l'architecture de qualité industrielle, c'est la conception explicite des interfaces entre eux : le schéma canonique d'observation que la normalisation produit et que la résolution d'entités consomme ; le format de graphe d'entités que la résolution d'entités produit et que le moteur de corrélation consomme ; le flux d'entités enrichies que la résolution d'entités et le moteur de corrélation écrivent tous deux et que la couche de publication lit. Un système où ces interfaces sont implicites ou non documentées — où chaque composant suppose un comportement spécifique de son amont — est fragile exactement aux points où les données de renseignement sont les plus variables de caractère.