Construire un pipeline de fusion de défense, partie 3 : fusion multi-INT, classification et releasability

Les parties 1 et 2 ont construit un pipeline de fusion mono-source. Les parties 3 et 4 referment l'écart avec la réalité opérationnelle de la défense. La fusion de défense réelle prend en entrée plusieurs disciplines de renseignement — SIGINT, IMINT, ELINT, OSINT, HUMINT, GEOINT, MASINT — chacune ayant sa propre sémantique, sa propre latence, sa propre classification et ses propres marquages de releasability. Les traiter comme des observations interchangeables est l'échec architectural le plus fréquent dans les programmes de fusion de défense. La partie 3 couvre l'ingénierie de la fusion multi-INT et la machinerie de classification que la défense exige de manière unique.

La fondation conceptuelle se trouve dans Guide complet de la fusion de données de défense ; le cadrage du partage de données en coalition se trouve dans Défis du partage de données en coalition ; les fondations RBAC se trouvent dans Contrôle d'accès basé sur les rôles dans les systèmes C2 de défense.

Étape 1 : les sémantiques multi-INT ne sont pas interchangeables

Chaque discipline de renseignement porte une sémantique différente. Un contact SIGINT en bearing-only vous donne la direction mais pas la distance. Une observation IMINT vous fournit une position précise à un instant unique mais aucune cinématique. Un rapport OSINT a une attribution incertaine mais un contexte potentiellement riche. Un rapport HUMINT a une latence élevée et des exigences de protection des sources. Réduire tout cela à un enregistrement générique d'« observation » fait perdre l'information dont la fusion a besoin pour produire des pistes dignes de confiance.

Les champs qui distinguent les observations multi-INT :

• SIGINT — ligne de relèvement, fréquence, modulation, type d'émetteur, heure d'interception. Position calculée par triangulation si plusieurs stations rapportent le même émetteur ; sinon inconnue.
• IMINT — position précise issue de l'exploitation d'images, identité par classification visuelle ou automatisée, heure de collecte. Taux de revisite mesurés en heures.
• ELINT — caractérisation d'émetteurs (paramètres d'impulsion radar, signature). Recoupe le SIGINT mais se concentre sur l'ordre de bataille électronique.
• OSINT — extrait de sources publiques, avec incertitude d'attribution, confiance dans la source, chaîne de citation. De plus en plus important ; traité dans Surveillance des menaces OSINT pour la défense.
• HUMINT — renseignement de source humaine, latence élevée, sensibilité de classification et de protection des sources. Ne peut être propagé aux partenaires de coalition sans un nettoyage de releasability.
• GEOINT — combine l'imagerie avec l'analyse de terrain, la prédiction d'itinéraires et l'inférence de pattern-of-life.
• MASINT — measurement and signature intelligence ; couvre la détection acoustique, infrarouge, nucléaire et autres capteurs spécialisés. Souvent spécifique à un domaine (lutte anti-sous-marine, défense antimissile).

Le schéma canonique de piste accommode ces particularités en portant des métadonnées de discipline-source en plus des champs standard. Le moteur de fusion référence la discipline lorsqu'il calcule les vraisemblances d'association (une observation SIGINT en bearing-only ne peut pas mettre à jour directement une piste cinématique sans logique de bearing-matching ; un fix ponctuel IMINT doit mettre à jour la position mais pas la vitesse).

Étape 2 : l'architecture de fusion multi-INT

Le pattern architectural pour la fusion multi-INT qui fonctionne en production :

Adaptateurs par discipline. Chaque discipline de renseignement dispose de sa propre famille d'adaptateurs avec une logique spécifique à la discipline. Le travail de l'adaptateur est de produire des observations au schéma canonique étiquetées avec la discipline-source, et non d'interpréter à travers les disciplines.

Corrélation consciente de la discipline. La logique de corrélation du moteur de fusion référence les métadonnées de discipline-source. Le gating basé sur des règles inclut des règles de compatibilité de discipline (« un rapport HUMINT sur un navire ne peut mettre à jour une piste de navire confirmée par IMINT que si l'identité correspond avec une confiance élevée »). L'association probabiliste utilise des a priori spécifiques à la discipline.

Enrichissement par la fusion, pas remplacement. Lorsque les observations multi-INT concordent, elles renforcent la confiance. Lorsqu'elles divergent, le moteur de fusion expose le désaccord à l'opérateur plutôt que d'en choisir une. Une piste avec deux rapports d'identité confiants mais contradictoires n'est pas « erronée » — elle est réellement ambiguë, et l'opérateur a besoin de le savoir.

Analytique inter-disciplines en services séparés. Les analyses d'ordre supérieur qui traversent les disciplines — détection de pattern-of-life (Analyse pattern-of-life), détection d'anomalies comportementales, analyse de réseau — s'exécutent comme des services séparés qui consomment le flux de pistes fusionnées. Elles produisent des annotations enrichies sur les pistes existantes, et non de nouvelles pistes en concurrence avec le moteur de fusion.

Étape 3 : marquage de classification selon STANAG 4774/4778

Chaque objet de données produit par la plateforme porte un label de confidentialité. STANAG 4774 définit le format de marquage ; STANAG 4778 définit la liaison cryptographique qui empêche de détacher les labels des données qu'ils étiquettent. Ensemble, ils constituent la fondation de tout partage de données en coalition dans les contextes OTAN.

L'intégration d'ingénierie :

La classification source est portée par chaque adaptateur. Chaque adaptateur connaît la classification de sa source (configurée dans le catalogue des sources de la partie 1) et étiquette chaque observation avec celle-ci. L'adaptateur est la source de vérité pour la classification de ses observations.

Les labels sont structurés, pas des chaînes. Un label de classification n'est pas « SECRET » ; c'est un objet structuré comportant un niveau de classification, des compartiments, des marquages releasability et une signature de liaison. La bibliothèque de labels implémente la sérialisation STANAG 4774 et la liaison STANAG 4778 ; chaque observation y passe.

Les labels sont propagés, pas régénérés. Lorsque le moteur de fusion met à jour une piste, la classification effective de la piste est calculée à partir de l'ensemble des sources, pas attribuée indépendamment. Une piste dérivée d'un retour radar SECRET et d'un message AIS NON CLASSIFIÉ est SECRET. La discipline de propagation est mécanique ; s'y tromper est une cause d'échec d'accréditation.

La liaison survit à la sérialisation. Lorsque les pistes sont sérialisées sur disque, sur le bus de messages, ou à travers le réseau, la liaison STANAG 4778 reste attachée. Retirer la liaison pour « la commodité » est précisément le genre de raccourci que les évaluateurs d'accréditation cherchent à débusquer.

Étape 4 : propagation de classification à travers la fusion

Le moteur de fusion crée des données dérivées. Une piste est une dérivation à partir de multiples observations sources ; sa classification doit être calculée à partir des leurs. Les règles de propagation :

Le niveau de classification est le maximum sur l'ensemble des sources. Une piste dérivée de sources SECRET et NON CLASSIFIÉES est SECRET. La règle du high-water-mark est implacable mais bien comprise.

Les compartiments sont l'union sur l'ensemble des sources. Une piste dérivée d'une source compartiment HIGH-VALUE-TARGET et d'une source compartiment HUMAN-INTELLIGENCE porte les deux compartiments. L'accès exige une habilitation dans les deux.

La releasability est l'intersection sur l'ensemble des sources. Une piste dérivée de sources FVEY-only et NATO-only n'est releasable qu'à l'intersection (FVEY-et-OTAN, ce qui en pratique signifie les quatre nations FVEY qui sont aussi membres de l'OTAN). La règle d'intersection est la plus lourde de conséquences opérationnelles, et celle que les implémentations ad-hoc se trompent le plus souvent.

Classification par attribut là où cela compte. La position d'une piste peut être largement releasable tandis que son identité est plus restreinte. Le schéma supporte la classification par attribut ; le moteur de politiques évalue l'accès par attribut au moment de la requête.

Étape 5 : le moteur de politiques de releasability

Les labels de classification sur les données sont nécessaires mais pas suffisants. Les décisions d'accès exigent un moteur de politiques qui connaît l'habilitation, la citoyenneté, le rôle de l'utilisateur, et la classification, les compartiments et la releasability des données demandées. Chaque requête contre le magasin de pistes passe par ce moteur.

Le pattern d'ingénierie :

Politique en tant que code. Règles de releasability exprimées dans un langage de politique versionné — le Rego d'Open Policy Agent (OPA) est la valeur par défaut défendable. Les changements de politique passent par revue de code, pas par changements de configuration. L'historique des décisions de politique est auditable depuis le contrôle de version.

Évaluation de décision à la frontière de requête. Lorsqu'un consommateur interroge le magasin de pistes, le moteur de politiques évalue quelles pistes sont visibles et quels attributs sont visibles par piste. Le résultat est une vue filtrée, pas l'intégralité des données avec un masque UI. Le filtrage uniquement UI est une violation des Critères Communs et un point bloquant à l'accréditation.

Journal d'audit par décision. Chaque décision d'accès — quel utilisateur, quelles données, quelle classification, quel résultat — est journalisée de manière immuable. Le journal d'audit est la base de preuves pour la revue d'accréditation et l'analyse forensique opérationnelle.

Budgets de performance. Le moteur de politiques se trouve sur le chemin critique du COP ; sa latence d'évaluation doit être sub-milliseconde par décision. Les stratégies de cache, les bundles de politiques pré-compilés, et les empreintes de politique par utilisateur comptent toutes. Un moteur de politiques naïf est la cause la plus fréquente de lenteur du COP dans les déploiements classifiés.

Le traitement détaillé du pattern du moteur de politiques, des implications de partage de données en coalition, et des anti-patterns opérationnels à éviter, se trouve dans Défis du partage de données en coalition.

Étape 6 : flux de données inter-enclaves

Les réseaux de défense ne sont pas des enclaves uniques. Une plateforme opérant à travers NATO RESTRICTED, NATO SECRET et des réseaux classifiés nationaux doit déplacer les données appropriées entre eux tout en empêchant les flux inappropriés. Le pattern architectural :

Instances de fusion par enclave. Chaque enclave classifiée exécute sa propre instance de fusion avec son propre ensemble de sources, son propre magasin de pistes et son propre moteur de politiques. Les instances sont physiquement séparées ; la plateforme ne suppose pas qu'elles partagent un état.

Ponts inter-domaines (cross-domain bridges). Là où les données se déplacent légitimement entre enclaves — par exemple un flux AIS non classifié remontant vers une enclave SECRET, ou un produit nettoyé pour la releasability descendant vers une enclave de coalition — le mouvement passe par un pont inter-domaines accrédité, et non par une connexion directe. Le pont applique les règles de classification à la frontière.

Diodes unidirectionnelles là où la physique impose la direction. Pour le déplacement de données du haut vers le bas (rare et opérationnellement sensible), les diodes de données unidirectionnelles imposent la direction au niveau de la couche réseau. La plateforme de fusion s'intègre à l'infrastructure de diode plutôt que d'implémenter la sienne.

Release manuelle là où l'automatisation échoue. Certaines décisions de classification ne peuvent être automatisées en toute sécurité. Les décisions de release par produit pour le HUMINT ou les données compartimentées peuvent exiger une approbation humaine. La plateforme doit accommoder le workflow — exposer la release candidate, capturer la décision humaine, propager la release approuvée.

Étape 7 : considérations opérationnelles

La fusion multi-INT en opérations fait émerger des défis invisibles en développement. Les disciplines qui distinguent les plateformes opérationnelles des plateformes de démonstration :

L'attribution de source survit à la propagation. Lorsqu'une piste est interrogée, la réponse inclut l'ensemble des sources qui y ont contribué. Les opérateurs ont besoin de savoir si une position vient du radar (haute confiance cinématique, identité incertaine) ou du HUMINT (faible précision spatiale, contexte d'identité riche). L'attribution de source rend cela transparent.

Le désaccord est préservé, pas écrasé. Lorsque deux disciplines de source divergent sur l'identité d'une piste, le moteur de fusion préserve les deux alternatives avec leurs confiances. L'opérateur décide ; la plateforme expose.

L'expansion des compartiments est bornée. Une piste avec de nombreux compartiments a de nombreuses audiences potentielles distinctes. Le système doit calculer la releasability efficacement même lorsque l'ensemble des compartiments est large.

L'audit couvre chaque décision de release. Chaque transfert inter-domaines, chaque résultat de filtre par requête, chaque escalade de compartiment est journalisé. Le journal d'audit soutient la revue forensique opérationnelle, les preuves d'accréditation, et l'analyse après action. Le pattern détaillé se trouve dans Event sourcing pour les pistes d'audit de défense.

Les observables cyber comme multi-INT

De plus en plus, les observables cyber alimentent le même pipeline de fusion que les observations du domaine physique. Une intrusion réseau confirmée, un ensemble d'identifiants fuités, un lead d'attribution dérivé d'OSINT — chacun peut devenir une observation dans le flux de fusion multi-INT. L'adéquation architecturale est réelle mais demande de la prudence : les données cyber ont une latence, une confiance et une sémantique de classification différentes de celles du domaine physique. Le pattern est traité dans Plateformes CTI pour la défense et la vision plus large du cyber-comme-discipline-de-fusion dans Le guide complet de la cybersécurité de défense.

La décision d'ingénierie : construire des adaptateurs spécifiques au cyber qui produisent des observations au schéma canonique étiquetées avec la discipline « cyber » tout en préservant les métadonnées spécifiques au cyber (indicateurs de compromission, attribution d'acteur de menace, phase de kill-chain). Le moteur de fusion traite les observations cyber comme les autres entrées multi-INT ; l'outillage spécifique au cyber (plateformes CTI, SIEM/SOAR) consomme le même flux de pistes pour ses propres usages.

La suite

La partie 3 a couvert la machinerie multi-INT et de classification. La plateforme corrèle désormais les observations à travers les disciplines de renseignement tout en préservant leurs différences sémantiques, propage correctement la classification à travers la fusion, applique la releasability via un moteur de politiques, et opère à travers les frontières inter-enclaves classifiées.

La partie 4 referme la série avec l'opérationnalisation : surveillance du drift sur les algorithmes de fusion, le pipeline d'audit qui soutient l'accréditation, les patterns de déploiement en production (cloud-vers-air-gapped), et la discipline de maintenance de long terme qui maintient la plateforme opérationnelle sur un cycle de vie de 20 ans.