Toute plateforme sérieuse de renseignement militaire finit par se heurter au même problème structurel : cinq disciplines de renseignement ou plus produisent chacune leurs données dans leur propre format, à leur propre cadence, avec leurs propres sémantiques — et les analystes ont besoin d'une image unifiée qui raisonne sur l'ensemble simultanément. Le guide complet de la fusion de données de défense couvre le pipeline de traitement dans ses grandes lignes. Cet article va plus loin sur la couche schéma — le modèle de données canonique qui se trouve sous le moteur de fusion et lui fournit une base cohérente sur laquelle travailler.
Bien concevoir le modèle de données n'est pas un détail. Un schéma mal conçu force la logique spécifique à chaque INT dans la couche applicative, rend les requêtes inter-sources fragiles et transforme les migrations de schéma en gels de plateforme de plusieurs semaines. Un modèle bien conçu absorbe de nouveaux types d'INT, prend en charge les requêtes bi-temporelles et maintient la traçabilité intacte à chaque étape de la fusion. Cet article couvre l'ensemble des décisions qui déterminent dans quelle catégorie se situera votre plateforme.
Pourquoi chaque INT nécessite une adaptation de schéma différente
Les cinq principales disciplines du renseignement diffèrent non seulement par ce qu'elles collectent, mais aussi par la structure de leurs données, la cadence à laquelle elles arrivent et les métadonnées intrinsèquement disponibles. Ces différences ne sont pas superficielles. Elles déterminent quelle logique d'adaptateur est nécessaire avant qu'un modèle unifié puisse ingérer une source, et elles contraignent les requêtes inter-INT réalisables.
HUMINT (renseignement humain) est essentiellement textuel. Un rapport HUMINT est un document narratif décrivant ce qu'une source a observé, entendu ou ce qu'on lui a dit. Les horodatages sont souvent imprécis — le rapport peut décrire un événement survenu sur une plage de plusieurs jours, avec incertitude à la fois sur l'heure et sur le lieu. La métadonnée la plus importante est l'évaluation de la source : dans quelle mesure cette source particulière est-elle fiable, et dans quelle mesure cette information spécifique est-elle crédible ? La cadence des données HUMINT est faible — quelques dizaines à quelques centaines de rapports par jour sur un point de collecte actif, pas des milliers par seconde.
SIGINT (renseignement d'origine électromagnétique) — couvrant à la fois le COMINT (communications) et l'ELINT (renseignement électronique) — est à haute cadence, très structuré et horodaté à la milliseconde près. Une intercept SIGINT ou la détection d'un émetteur comporte des paramètres de fréquence, des angles de gisement, des fixes TDOA (différence de temps d'arrivée) et des caractéristiques de modulation. Le contenu sémantique (ce qui a été dit) est souvent classifié séparément des paramètres du signal. La cadence des données SIGINT peut atteindre des millions d'enregistrements par heure pour un système de collecte moderne couvrant un environnement électromagnétique contesté.
IMINT (renseignement par imagerie) produit des enregistrements d'observation structurés issus de l'analyse d'images : boîtes englobantes avec étiquettes de classe d'entités et scores de confiance, coordonnées de géolocalisation, résolution au sol et horodatage de collecte. Un seul passage de satellite ou un vol de drone peut générer des milliers d'enregistrements de détection d'objets. La difficulté est que les détections IMINT sont des instantanés spatiaux — elles indiquent où quelque chose se trouvait à un moment précis, non où cela se déplace.
OSINT (renseignement de sources ouvertes) est structurellement le plus hétérogène. Il comprend des publications sur les réseaux sociaux, des articles de presse, des analyses d'imagerie satellitaire commerciale, des données de suivi de vols et des flux AIS maritimes. Chaque type de source a son propre schéma. L'OSINT est également le moins contrôlé — la qualité des sources va des publications gouvernementales officielles aux déclarations anonymes non vérifiées sur les réseaux sociaux.
MASINT (renseignement par mesure et signature) couvre la mesure de phénomènes physiques : signatures sismiques, acoustiques, rayonnements nucléaires, biologiques ou chimiques et profils de section radar. Les observations MASINT sont souvent indirectes — elles détectent un phénomène (explosion, mouvement de véhicule, émission RF) sans identifier directement une entité. La chaîne reliant une observation MASINT à l'identification d'une entité nécessite des étapes d'inférence explicites qui doivent être modélisées dans le schéma.
L'implication pour un modèle unifié est que le schéma doit accommoder cette diversité sans l'effacer. La réponse est une enveloppe de base typée avec des charges utiles d'extension propres à chaque discipline — un design pattern couvert en détail dans la série construction d'un pipeline de fusion de défense, partie 1.
Types d'entités canoniques pour un modèle unifié
Le point de départ de la conception du schéma est la définition de la taxonomie des types d'entités — la liste exhaustive des objets du monde réel que la plateforme doit suivre et sur lesquels elle doit raisonner. Pour la plupart des plateformes de renseignement militaire, six types d'entités couvrent la grande majorité des objets de renseignement :
- Personne — sujets humains individuels : combattants, commandants, facilitateurs, civils d'intérêt
- Organisation — groupes, unités, réseaux, structures de commandement
- Lieu — sites géographiques fixes : installations, infrastructures, points de repère, zones d'intérêt nommées
- Équipement — véhicules, systèmes d'armes, capteurs, appareils de communication
- Événement — occurrences discrètes : engagements, explosions, réunions, transmissions
- Document — matériaux saisis, publications, rapports de renseignement comme objets d'analyse
Chaque type d'entité possède un ensemble de champs de base indépendants de l'INT — des champs qui doivent être renseignés quelle que soit la discipline du renseignement ayant fourni l'information :
EntityCore {
entity_id: UUID // unique mondial, immuable
entity_type: Enum // Person | Organization | Location |
// Equipment | Event | Document
classification: ClassMarkings // voir section provenance
valid_time: TimeInterval // [début, fin) quand le fait était vrai
transaction_time:TimeInterval // [début, fin) quand la ligne était courante
confidence: Float[0..1] // confiance fusionnée entre les sources
source_obs_ids: UUID[] // IDs des enregistrements d'observation contributeurs
schema_version: SemVer // pour la compatibilité d'évolution
created_at: Timestamp
updated_at: Timestamp
}
Au-delà du noyau, chaque type d'entité dispose d'extensions d'attributs typées. Une entité Personne porte des identifiants biométriques, des alias, une nationalité et des liens vers des organisations associées. Une entité Équipement porte le type de plateforme, des identifiants de série si connus et un lien vers l'unité associée. Une entité Événement porte la classe d'événement, des références aux entités impliquées et l'empreinte spatiale. Ces extensions sont stockées sous forme de charges utiles typées attachées à l'enveloppe de base — non pas comme des colonnes de la table de base. C'est cette séparation qui permet au schéma d'absorber de nouveaux attributs pour un type d'entité sans affecter les autres.
Le même principe de séparation s'applique aux contributions des INT. Lorsqu'une intercept SIGINT est liée à une entité Personne (parce qu'un IMSI a été résolu en un individu connu), ce lien est stocké comme un enregistrement d'observation avec une charge utile de type SIGINT pointant vers l'UUID de l'entité Personne. L'entité Personne elle-même ne porte pas de colonnes spécifiques au SIGINT — ce couplage rendrait le schéma fragile à tout changement dans la collecte SIGINT.
Provenance et traçabilité des sources
La provenance est l'exigence non fonctionnelle la plus critique de tout modèle de données de renseignement. Chaque information du tableau fusionné doit être traçable jusqu'à son observation source, le système de collecte qui l'a produite et les évaluations humaines appliquées à sa fiabilité. Sans cette chaîne, les analystes ne peuvent pas évaluer la qualité du tableau sur lequel ils travaillent, et la plateforme ne peut pas effectuer de restauration lorsqu'une source s'avère non fiable.
Un bloc de provenance attaché à chaque enregistrement d'observation doit contenir au minimum :
ProvenanceBlock {
int_type: Enum // HUMINT | SIGINT | IMINT | OSINT | MASINT
source_id: UUID // référence au registre de sources interne
source_reliability: Char // A–F (échelle amirauté OTAN)
info_credibility: Integer // 1–6 (échelle amirauté OTAN)
collection_time: Timestamp
report_time: Timestamp // quand le rapport est entré dans le système
originator: String // unité ou système ayant produit le rapport
classification: ClassMarkings
handling_caveats: String[] // NOFORN, ORCON, REL TO, etc.
dissemination_ctrl: String[]
}
L'échelle d'amirauté de l'OTAN encode deux évaluations humaines indépendantes pour chaque élément de renseignement. La fiabilité de la source (A à F) note le bilan historique et la fiabilité de la source — une source notée A a été constamment exacte et fiable ; une source notée F a un bilan inconnu ou médiocre. La crédibilité de l'information (1 à 6) note la plausibilité de l'information spécifique indépendamment de l'historique de la source — un élément noté 1 est confirmé par d'autres sources indépendantes ; un élément noté 6 est improbable au vu de ce qui est connu par ailleurs.
Ces deux notes sont des évaluations humaines effectuées par des officiers de renseignement formés. Elles sont distinctes du score de confiance de fusion calculé par machine sur l'entité, et ne doivent pas être confondues avec lui. La confiance de fusion reflète l'accord statistique entre les sources corroborantes ; les notes d'amirauté reflètent le jugement humain sur la qualité de la source. Les deux doivent être préservées et présentées séparément aux analystes.
Les marquages de classification exigent une représentation structurée, non du texte libre. Un type ClassMarkings doit encoder : le niveau de classification (NON CLASSIFIÉ à TRÈS SECRET), les compartiments et les mots de code, et les restrictions de diffusion sous forme de liste énumérée. Cette structure permet l'application programmatique du contrôle d'accès — la plateforme peut évaluer au moment de la requête si l'habilitation d'un utilisateur donné satisfait la classification de chaque champ, et peut sélectivement expurger ou retenir les champs dépassant le niveau d'habilitation de l'utilisateur plutôt que de refuser de renvoyer l'entité entière.
Résolution d'entités inter-INT
La résolution d'entités — déterminer que des enregistrements provenant de différentes sources font référence à la même entité du monde réel — est le problème central de la fusion, et il est le plus difficile précisément à la frontière inter-INT. Au sein d'un seul INT, les schémas d'identification sont cohérents : deux enregistrements SIGINT partageant un IMSI font référence au même appareil. Entre les INT, aucun identifiant partagé n'existe par défaut. Une détection IMINT d'un véhicule, un fix de gisement SIGINT sur un émetteur collocalisé avec ce véhicule, et un rapport HUMINT nommant une personne vue dans ce véhicule doivent être reliés par inférence probabiliste, non par une clé partagée.
Le pipeline de résolution d'entités pour un modèle unifié doit gérer trois scénarios de liaison :
Liens durs — identifiants partagés qui relient définitivement des enregistrements à la même entité. Un IMSI connu, une plaque d'immatriculation lue par deux passages IMINT, une correspondance biométrique. Les liens durs doivent être propagés automatiquement sans dégradation de confiance.
Liens souples — associations probabilistes basées sur la similarité d'attributs dans les limites d'incertitude. Deux observations rapportant un véhicule de même classe à des emplacements se chevauchant dans une fenêtre temporelle cohérente avec un déplacement entre elles. Les liens souples portent un score de confiance de correspondance calculé par le moteur de résolution.
Liens inférés — associations dérivées de connaissances du domaine : si un gisement d'émetteur SIGINT se déplace constamment avec une piste de véhicule IMINT, ils appartiennent probablement à la même plateforme. Ces liens nécessitent des définitions de règles explicites et portent une confiance inférieure aux liens souples basés sur un chevauchement direct d'attributs.
Le pipeline de résolution produit des hypothèses de correspondance. Les hypothèses dépassant un seuil de haute confiance sont automatiquement fusionnées dans l'enregistrement golden. Les hypothèses dans la plage intermédiaire sont signalées pour examen par un analyste. Les hypothèses en dessous du seuil bas sont conservées comme entités séparées. Les valeurs de seuil sont configurables et doivent être réglables par type d'entité — les fusions d'entités Personne justifient des seuils de confiance plus élevés que les fusions d'Équipement, car les fusions de personnes erronées produisent des conséquences analytiques plus graves que les fusions d'équipements erronées.
La gestion des enregistrements golden nécessite une politique de fusion définie pour les conflits d'attributs. Lorsque deux sources sont en désaccord sur un attribut — un rapport HUMINT indique qu'une personne se trouvait à l'emplacement A, une détection IMINT la place à l'emplacement B une heure plus tard — la politique de fusion doit préciser comment réconcilier l'attribut dans l'enregistrement golden. Les politiques courantes comprennent : la plus récente en temps de validité l'emporte, la source la plus fiable l'emporte, combinaison pondérée pour les attributs numériques. La politique choisie doit être stockée sur l'enregistrement golden sous forme de métadonnée afin que les analystes puissent comprendre pourquoi l'enregistrement golden affiche une valeur d'attribut particulière.
Le modèle de fusion de données JDL cadre la résolution d'entités comme un problème de niveau 1 (raffinement d'objet) et de niveau 2 (raffinement de situation). La conception du schéma décrite ici est ce qui rend ces niveaux JDL implémentables en pratique.
Modélisation temporelle : temps de validité vs temps de transaction
La modélisation bi-temporelle n'est pas optionnelle pour une plateforme de renseignement militaire. C'est la structure temporelle minimale nécessaire pour prendre en charge les deux types de requêtes les plus critiques : « qu'était-il vrai dans le monde au temps T ? » (requête sur le temps de validité) et « que savait le système sur X au temps T ? » (requête sur le temps de transaction). Ce sont des questions différentes qui nécessitent des réponses différentes, et un schéma qui les confond — en utilisant un seul horodatage par enregistrement — ne peut répondre correctement à aucune des deux.
Le temps de validité représente quand un fait était vrai dans le monde réel. Pour une détection IMINT d'un véhicule à une coordonnée de grille, le temps de validité est l'horodatage d'imagerie. Pour un rapport HUMINT décrivant une réunion, le temps de validité est la meilleure estimation de l'analyste quant au moment où la réunion a eu lieu — ce qui peut être une plage de jours, non un horodatage précis. Le temps de validité est une propriété du monde, non de la base de données.
Le temps de transaction représente quand un enregistrement était courant dans la base de données. Pour la même détection IMINT, le temps de transaction commence à l'insertion de l'enregistrement de détection et se termine si l'enregistrement est jamais remplacé (par exemple, si la géolocalisation est retraitée et corrigée). Le temps de transaction est une propriété de la base de données, gérée automatiquement par le système.
La combinaison permet deux opérations critiques. Premièrement, les requêtes au temps t : « reconstruire le tableau de renseignement complet tel que le système le détenait à 14h00 le jour D. » Cela nécessite d'interroger sur le temps de transaction — en renvoyant uniquement les enregistrements qui étaient courants dans la base de données à 14h00 le jour D, quel que soit le moment où tombe leur temps de validité. C'est essentiel pour l'analyse post-incident et pour l'audit des décisions basées sur le renseignement. Deuxièmement, les requêtes sur les faits historiques : « quels événements se sont produits au lieu X entre le jour D-7 et le jour D ? » Cela interroge sur le temps de validité — en renvoyant les enregistrements dont l'intervalle de temps de validité chevauche la fenêtre de requête, quel que soit le moment de leur insertion.
L'implémentation dans PostgreSQL utilise des colonnes de période. La dimension de temps de validité est représentée comme une colonne tstzrange (plage d'horodatage avec fuseau horaire). La dimension de temps de transaction utilise soit une table temporelle à période système (supportée nativement dans certaines extensions PostgreSQL), soit une paire explicite de colonnes transaction_start et transaction_end, avec transaction_end fixée à l'infini pour les lignes courantes et horodatée à la mise à jour pour indiquer quand la ligne a été remplacée. Toutes les mises à jour doivent être implémentées comme des opérations d'insertion d'une nouvelle ligne / horodatage de l'ancienne ligne, jamais comme des écrasements en place.
Contrôle de version et lignage des objets fusionnés
Les entités de renseignement ne sont pas statiques. Une entité Personne peut débuter comme une identification provisoire à partir d'un seul rapport HUMINT, recevoir une confirmation spatiale d'une détection IMINT trois jours plus tard, et obtenir une confirmation biométrique d'un événement de collecte distinct une semaine après. Chacune de ces mises à jour modifie l'enregistrement golden — mais les états précédents doivent être récupérables, non écrasés.
L'implémentation standard est un journal d'événements en ajout seul par entité. Chaque changement d'état d'un enregistrement golden génère un événement de mise à jour. Chaque événement est immuable une fois écrit et contient :
- L'UUID de l'entité
- Le type d'événement (Créé / Mis à jour / Fusionné / Divisé / Rétracté)
- L'instantané de l'état précédent (copie complète de l'enregistrement golden avant le changement)
- Le nouvel instantané d'état
- Les IDs des enregistrements d'observation qui ont déclenché la mise à jour
- Le nom et la version de la politique de fusion appliquée
- L'horodatage de transaction
- L'ID de l'opérateur (analyste humain ou processus système)
L'enregistrement golden courant est le résultat de l'application de tous les événements en séquence depuis le début du journal. Il s'agit du pattern d'event sourcing appliqué aux données de renseignement. Il fournit une piste d'audit complète pour chaque état d'entité à chaque instant, ce qui est requis pour la responsabilité du renseignement dans la plupart des cadres militaires.
La restauration est une opération de premier ordre : étant donné un UUID d'entité et un horodatage de transaction cible, la plateforme rematérialise l'enregistrement golden tel qu'il existait à cet horodatage en rejouant le journal d'événements jusqu'à cet horodatage sans inclure les événements postérieurs. La restauration est déclenchée lorsqu'une source est évaluée comme trompeuse ou erronée — tous les enregistrements golden ayant incorporé des observations de cette source doivent être réévalués avec les observations contaminées exclues.
Un événement de rétractation est le mécanisme permettant de gérer ce scénario à grande échelle. Lorsque la source S est invalidée, le système génère un événement de rétractation pour chaque observation attribuée à S, puis relance la fusion pour chaque entité ayant référencé l'une de ces observations. Les entités soutenues uniquement par la source rétractée reviennent à un état de confiance inférieure ou sont marquées comme non confirmées. Les entités ayant des sources corroborantes d'autres INT absorbent la rétractation avec une pénalité de confiance mais restent dans le tableau.
Le modèle de lignage permet également les événements de division — l'inverse de la résolution d'entités. Si deux entités ont été incorrectement fusionnées (une fausse fusion positive), un événement de division les sépare : l'enregistrement golden erroné est rétracté, et deux nouveaux enregistrements d'entités sont créés, héritant chacun des observations sources qui leur appartiennent. L'événement de division préserve l'historique complet de l'état fusionné et de la décision de division, permettant aux analystes ultérieurs de comprendre pourquoi la division a eu lieu.
Évolution du schéma en production
Une plateforme de renseignement militaire n'est pas un produit statique. De nouveaux systèmes de collecte se mettent en ligne, de nouvelles disciplines INT sont ajoutées au périmètre, et les schémas existants nécessitent des ajouts d'attributs à mesure que de nouvelles exigences analytiques émergent. L'évolution du schéma dans une plateforme de production ne pouvant tolérer de temps d'arrêt exige des choix de conception délibérés dès le premier jour.
Le principe fondamental est la compatibilité ascendante comme contrat. L'enveloppe d'entité de base — les champs EntityCore — doit être strictement versionnée à l'aide d'un champ schema_version. Tout changement à l'enveloppe de base supprimant un champ ou modifiant le type d'un champ est un changement majeur nécessitant une montée de version majeure avec un chemin de migration défini. L'ajout de champs optionnels au noyau constitue un changement mineur de version. Le champ de version permet aux consommateurs de déclarer quelles versions de schéma ils prennent en charge et permet à la plateforme de servir différentes versions à différents consommateurs pendant une période de migration.
Les charges utiles d'extension sont le bon vecteur pour ajouter de nouveaux types INT ou de nouveaux attributs. Lorsqu'un nouveau système d'analyse d'imagerie se met en ligne et produit des types d'attributs supplémentaires (par exemple, des scores d'évaluation de dommages structurels dérivés d'imagerie SAR), ces attributs vont dans une version nouvelle ou mise à jour de la charge utile d'extension IMINT — non dans le schéma d'entité de base. Les consommateurs existants qui n'ont pas besoin d'attributs spécifiques au SAR ne sont pas affectés.
La taxonomie de provenance doit être étendue lors de l'ajout d'un nouveau type INT. L'énumération des types INT gagne une nouvelle valeur, et les définitions des notes de fiabilité et de crédibilité de la source doivent être révisées pour leur applicabilité au nouveau type de source. Certains nouveaux types de sources peuvent nécessiter de nouveaux critères de crédibilité qui ne correspondent pas proprement à l'échelle d'amirauté à six points existante — dans ces cas, le bloc de provenance doit porter les métadonnées de fiabilité brutes propres à la source en plus de la note d'amirauté traduite, préservant la fidélité.
Les règles de résolution d'entités constituent le chemin d'évolution le plus exigeant en travail. Lorsqu'un nouveau type INT rejoint le modèle unifié, les ingénieurs de résolution doivent spécifier comment les observations du nouveau type de source peuvent être liées aux types d'entités existants. Cela nécessite à la fois une analyse des données (quels attributs sont disponibles pour la correspondance ?) et des connaissances du domaine (quels seuils de proximité d'attributs sont opérationnellement significatifs ?). Ces règles doivent être examinées par des analystes de renseignement expérimentés, pas uniquement par des ingénieurs logiciels — des règles de résolution incorrectes produisent de fausses fusions qui corrompent silencieusement le tableau de renseignement.
La migration de schéma dans un modèle bi-temporel comporte une considération supplémentaire : les lignes historiques doivent être migrées sans altérer leur historique de temps de transaction. Une migration qui réécrit des lignes existantes et met à jour leurs horodatages de transaction brise la sémantique des requêtes historiques. Les migrations doivent être additives : ajouter de nouvelles colonnes avec des valeurs par défaut pour les lignes historiques, sans jamais mettre à jour les valeurs de colonnes existantes dans les enregistrements historiques.
Tester l'évolution du schéma nécessite une stratégie multicouche : tests unitaires pour la sérialisation et la désérialisation de chaque version de schéma ; tests d'intégration pour la compatibilité des consommateurs entre versions ; et tests de régression utilisant des échantillons de données de renseignement historiques pour confirmer que les requêtes existantes renvoient des résultats identiques après une migration. Les tests sur données historiques sont ceux qui sont le plus souvent ignorés et ceux qui détectent le plus de régressions cassant la production.
Le modèle de données décrit dans cet article représente un objectif de conception, non un point de départ pour une implémentation en un seul sprint. La plupart des plateformes progressent vers cette architecture de manière incrémentale — en commençant par un schéma plus simple pour deux ou trois types d'INT, puis en ajoutant le modèle bi-temporel, les blocs de provenance complets et le lignage basé sur l'event sourcing au fur et à mesure que les exigences opérationnelles se solidifient. L'essentiel est que les décisions de conception fondamentales — charges utiles d'extension typées, enveloppes d'entités indépendantes des INT, temps de validité et de transaction séparés — soient prises tôt, car les rétrofitter sur un schéma monolithique est bien plus coûteux que de les intégrer dès le départ.