Graphes de connaissance pour le renseignement militaire : résolution d'entités et analyse de liens

Par Équipe d'ingénierie Corvus Intelligence · À propos de l'équipe →

24 juin 2026 12 min de lecture

Le renseignement militaire a toujours été une question de connexion : quel commandant contrôle quelle unité, quel financier finance quelle cellule, quel nœud d'infrastructure permet quelle chaîne logistique. Ce sont des problèmes de graphe. Les données qui y répondent — communications interceptées, rapports d'agents, métadonnées d'imagerie satellite, enregistrements open source — arrivent d'une douzaine de systèmes de collecte distincts, chacun nommant différemment la même entité réelle et stockant les relations dans des formats incompatibles. Les graphes de connaissance fournissent la couche structurelle qui relie ces fragments en une image cohérente et interrogeable. Cet article examine comment les bases de données en graphe et les graphes de connaissance sont appliqués dans les flux de travail du renseignement militaire — des insuffisances fondamentales des approches relationnelles, à travers la conception d'ontologies alignées sur PMESII, la résolution d'entités à travers des sources multi-INT, la représentation des objets STIX, la sélection de bases de données en graphe pour les environnements classifiés, les patterns de requêtes Cypher pour l'analyse de liens, et l'intégration avec les pipelines C2 et OSINT.

Pourquoi les bases de données relationnelles échouent pour l'analyse de liens de renseignement

La question canonique du renseignement n'est pas « trouvez tous les enregistrements où la colonne X est égale à la valeur Y ». C'est « à partir de cette entité, parcourez son réseau jusqu'à une profondeur de cinq, en filtrant par type de relation et niveau de confiance, et dites-moi à quelles communautés ces entités appartiennent ». Les bases de données relationnelles répondent bien à la première question. Elles répondent à la seconde en enchaînant des opérations JOIN dont le coût de calcul se compose à chaque saut.

Un JOIN à deux sauts sur une table d'entités de dix millions de lignes est généralement faisable — quelques secondes avec de bons index. Un auto-jointure à cinq sauts sur la même table nécessite quatre opérations JOIN séquentielles, chacune multipliant l'ensemble de travail par le facteur moyen de ramification. Avec des données de renseignement réalistes — où un nœud de personne peut avoir cinquante contacts de communication, chacun ayant les leurs — l'ensemble de résultats intermédiaire à la profondeur cinq peut dépasser la mémoire de n'importe quel serveur avant même que le filtrage ne soit appliqué. L'optimiseur de requêtes ne peut pas éviter cela car la relation elle-même n'existe pas dans la base de données en tant qu'objet stocké : elle est recalculée par correspondance de colonnes clés au moment de la requête. Chaque saut est un recalcul complet.

Le problème de désambiguïsation des entités aggrave encore la situation. Une personne apparaît dans un interception SIGINT comme « Ahmed M. » et dans un rapport HUMINT comme « Ahmad Mansour » et dans un enregistrement financier comme « A. Mansouri ». Dans un schéma relationnel, ce sont trois lignes séparées dans trois tables séparées, à moins qu'un analyste humain (ou un pipeline de déduplication) ne les ait explicitement liées. Sans ce lien, un JOIN qui commence par l'enregistrement SIGINT ne traverse jamais vers l'enregistrement financier, et le réseau que voit l'analyste est systématiquement incomplet. Les bases de données relationnelles n'ont aucun mécanisme natif pour exprimer « ces deux lignes sont probablement la même entité, avec un niveau de confiance de 0,85 ». Cette probabilité doit vivre en dehors du schéma, dans la logique applicative qui est généralement manuelle et rarement cohérente.

L'explosion des JOIN et le problème de désambiguïsation des entités expliquent ensemble pourquoi l'analyse de liens dans les systèmes de renseignement de défense traditionnels — construits sur des bases de données relationnelles — nécessitait un travail d'analyste dédié qu'une base de données en graphe pour l'analyse de renseignement peut automatiser. Le graphe stocke les relations comme des arêtes natives avec des pointeurs directs entre les nœuds, de sorte que le coût de traversée est proportionnel au voisinage local, non à la taille globale de la table. La résolution d'entités est de première classe : une opération de fusion collapse plusieurs enregistrements en un nœud canonique, et toutes les arêtes qui référençaient l'un ou l'autre enregistrement référencent désormais le nœud canonique. Le graphe est le modèle de données conçu pour le domaine du problème.

Fondamentaux des graphes de connaissance pour l'usage militaire

Un graphe de connaissance étend un graphe de propriétés avec un vocabulaire partagé — une ontologie — qui donne à chaque type de nœud et type d'arête une signification définie et convenue. Ce vocabulaire partagé est ce qui rend les requêtes composables à travers les sources : deux pipelines d'ingestion distincts qui utilisent tous deux l'étiquette de nœud MilitaryUnit et le type d'arête SUBORDINATE_TO produisent des graphes qui peuvent être traversés ensemble. Sans l'ontologie, chaque pipeline invente ses propres noms, et le graphe accumule dix étiquettes synonymes pour le même concept.

Pour le renseignement militaire, le cadre PMESII fournit un squelette d'ontologie naturel. Chacune des six dimensions — Politique, Militaire, Économique, Social, Infrastructure, Information — devient une famille d'étiquettes de nœuds :

Dimension PMESII	Étiquettes de nœuds	Types d'arêtes clés
Politique	Government, Official, PoliticalParty, Faction	CONTROLS, ALLIED_WITH, OPPOSES
Militaire	Unit, Commander, WeaponsSystem, Base	COMMANDS, SUBORDINATE_TO, EQUIPPED_WITH, DEPLOYS_AT
Économique	Organization, FinancialAccount, SupplyChain, Commodity	FINANCES, TRANSACTS_WITH, SUPPLIES
Social	Person, Group, Community	MEMBER_OF, COMMUNICATES_WITH, RECRUITS
Infrastructure	Facility, TransportLink, PowerGrid, NetworkNode	CONNECTS, DEPENDS_ON, OPERATED_BY
Information	MediaChannel, PsyopActor, NarrativeTheme	AMPLIFIES, TARGETS, DISSEMINATES

Chaque nœud porte un ensemble de propriétés obligatoires : un identifiant canonique, un nom, une étiquette de classification, une référence de source et un horodatage de création. Chaque arête porte : type, source_ref, confidence (un flottant entre 0 et 1), valid_from (le moment le plus ancien où la relation a été observée), valid_until (null si toujours active), et classification. Ces propriétés obligatoires sont ce qui rend le graphe auditable : toute connexion inférée peut être retracée jusqu'aux observations qui la soutiennent, avec leurs métadonnées de collecte et leurs scores de confiance intacts.

Les arêtes inter-PMESII sont souvent les cibles de renseignement de plus grande valeur. Un nœud Économique finançant un nœud Militaire traverse deux dimensions ; un nœud Information diffusant un récit au nom d'un nœud Politique en traverse deux autres. Les requêtes qui cherchent spécifiquement des chemins inter-dimensions — quelles organisations Économiques financent cette unité Militaire ? — sont structurellement simples dans un graphe de propriétés car l'arête existe comme objet natif reliant les deux nœuds.

Résolution d'entités à travers des sources multi-INT

Les données de renseignement sont collectées par des sources qui n'ont jamais été conçues pour partager un identifiant d'entité commun. Un système SIGINT identifie une personne par son numéro de téléphone. Un rapport HUMINT la nomme en prose. Un analyste IMINT balise un véhicule dans une annotation d'imagerie. Une base de données open source enregistre une organisation par son nom légal dans un script étranger. Intégrer tout cela dans un graphe cohérent nécessite la résolution d'entités : décider, pour chaque paire d'enregistrements entrants, s'ils font référence à la même entité du monde réel.

Le pipeline de résolution comporte trois étapes. La première est la normalisation : avant toute comparaison, les identifiants doivent être ramenés à une forme canonique. Les numéros de téléphone se normalisent au format international E.164. Les noms se translittèrent dans un script commun (généralement latin) en utilisant une norme de translittération définie (BGN/PCGN pour les langues slaves, ALA-LC pour l'arabe) et sont ensuite normalisés vers une forme de base qui supprime les honorifiques et les variations d'ordre de nom. Les coordonnées se convertissent en WGS84. Un enregistrement dont le numéro de téléphone est stocké comme « 0044-20-7946-0123 » et un autre dont le numéro est « +44 20 7946 0123 » doivent tous deux produire la même clé normalisée avant toute étape de blocage ou de comparaison.

La deuxième étape est le blocage : un mécanisme qui limite les paires d'enregistrements comparées. Comparer chaque enregistrement entrant à chaque nœud de graphe existant est quadratique en complexité et opérationnellement impossible à l'échelle. Les stratégies de blocage comprennent le voisinage trié (enregistrements triés par une clé de blocage, comparés uniquement dans une fenêtre glissante), le blocage par index inversé (les enregistrements partageant au moins un jeton dans un encodage phonétique de nom sont candidats), et le hachage sensible à la localité MinHash pour les attributs à valeurs ensemblistes comme les alias connus. Chaque stratégie échange le rappel contre les performances : un candidat de blocage manqué est une correspondance d'entité manquée, donc les clés de blocage doivent être ajustées sur un ensemble de test de référence de doublons connus.

La troisième étape est la notation et la décision. Les paires candidates reçoivent un vecteur de similarité sur plusieurs attributs : similarité de nom (Jaro-Winkler ou Jaccard sur les tokens de nom), chevauchement d'identifiants (téléphone partagé, IMEI, adresse), proximité géographique et co-occurrence temporelle. Une régression logistique ou un classificateur à gradient boosté produit un score de confiance de fusion. Les paires au-dessus d'un seuil élevé (généralement 0,90) sont fusionnées automatiquement ; les paires dans la bande d'incertitude (0,65–0,90) sont mises en file d'attente pour révision par un analyste ; les paires sous le seuil inférieur sont laissées comme nœuds séparés.

Discipline critique : chaque fusion doit être enregistrée avec le vecteur de preuves et le niveau de confiance qui la justifient. Les fusions doivent être réversibles. Une fusion incorrecte — deux personnes différentes réduites à un seul nœud — fabrique des connexions réseau qui n'existent pas, orientant potentiellement la collecte et l'analyse vers la mauvaise cible. Le journal de fusion n'est pas un artefact d'audit facultatif ; c'est une condition préalable pour que tout produit de renseignement que le graphe soutient survive à un examen analytique.

L'architecture de fusion multi-capteurs qui gère la corrélation de pistes au niveau du capteur utilise bon nombre des mêmes principes probabilistes — portes sur la position, la vitesse et les attributs d'identité — mais fonctionne à une latence de milliseconde sur des messages de capteurs structurés. La résolution d'entités pour les graphes de connaissance fonctionne à un volume bien inférieur (millions d'enregistrements plutôt que millions par seconde) mais sur des données bien plus désordonnées et moins structurées. Les deux domaines nécessitent la même discipline : confiance explicite, décisions réversibles et auditabilité.

Représentation des objets STIX dans un magasin de graphes

STIX (Structured Threat Information eXpression) est la norme de l'OTAN et des Five Eyes pour le partage du renseignement sur les cybermenaces. Un bundle STIX se compose d'objets de domaine STIX (SDOs) — les entités : acteurs de menace, campagnes, indicateurs, logiciels malveillants, vulnérabilités, patterns d'attaque, infrastructure — et d'objets de relation STIX (SROs) qui expriment des relations dirigées entre eux : « L'acteur de menace X utilise le logiciel malveillant Y », « La campagne A cible le secteur B ». C'est un graphe de propriétés natif. Chaque SDO devient un nœud ; chaque SRO devient une arête dirigée.

Le mappage est simple :

// STIX SDO → Neo4j Node
MERGE (n:StixObject {stix_id: $bundle.id})
SET n.type        = $sdo.type,
    n.name        = $sdo.name,
    n.confidence  = $sdo.confidence,
    n.modified    = datetime($sdo.modified),
    n.revoked     = coalesce($sdo.revoked, false),
    n.labels      = $sdo.labels,
    n.classification = $sdo.object_marking_refs[0]

// STIX SRO → Neo4j Edge
MATCH (src:StixObject {stix_id: $sro.source_ref})
MATCH (tgt:StixObject {stix_id: $sro.target_ref})
MERGE (src)-[r:STIX_REL {stix_id: $sro.id}]->(tgt)
SET r.relationship_type = $sro.relationship_type,
    r.confidence        = $sro.confidence,
    r.valid_from        = datetime($sro.start_time),
    r.valid_until       = datetime($sro.stop_time),
    r.modified          = datetime($sro.modified),
    r.revoked           = coalesce($sro.revoked, false)

Deux complications spécifiques à STIX nécessitent une gestion explicite. Premièrement, le versionnage : STIX met à jour un objet en réémettant le même identifiant avec un nouvel horodatage modified. Le pattern MERGE-on-stix_id ci-dessus gère cela correctement en écrasant les propriétés sur place. Pour les flux de travail qui doivent reconstruire l'image du renseignement à un moment spécifique — comme une révision post-incident — un pattern de versionnage temporel est nécessaire : au lieu d'écraser, créer une nouvelle version de nœud et chaîner les versions avec des arêtes HAS_VERSION, en stockant l'horodatage effectif sur chaque nœud de version.

Deuxièmement, la révocation : un objet STIX avec revoked: true doit être exclu des traversées mais non supprimé, pour préserver la piste d'audit. La convention est de définir revoked: true sur le nœud et d'ajouter un filtre WHERE NOT n.revoked à chaque requête de traversée par défaut. Une arête révoquée qui affirmait une relation entre deux acteurs de menace doit rester dans la base de données afin qu'un analyste puisse voir que l'affirmation a été faite puis rétractée — la rétractation est elle-même un renseignement.

STIX définit également des objets Sighting, qui enregistrent qu'un SDO a été observé dans un contexte spécifique. Les Sightings se mappent sur des arêtes reliant l'objet observé à une identité observatrice, avec les propriétés sighting_count et first/last_seen. C'est le mécanisme qui relie le renseignement sur les menaces abstrait — « cette famille de logiciels malveillants » — à une observation opérationnelle spécifique : « ce logiciel malveillant a été vu sur ce réseau à ce moment. »

Sélection de base de données en graphe pour les environnements militaires

Choisir une base de données en graphe pour un déploiement militaire classifié n'est pas principalement une décision de performance. Plusieurs contraintes non fonctionnelles dominent :

Moteur	Air-gap	Langage de requête	Algorithmes GDS natifs	Notes
Neo4j Enterprise	Oui (licence hors ligne)	Cypher / openCypher	Bibliothèque GDS : PageRank, Louvain, Dijkstra, WCC	La plupart des outils d'analyse ciblent Cypher ; solide historique d'accréditation dans les déploiements Five Eyes
TigerGraph	Oui (bundle sur site)	GSQL	Intégré : centralité, communauté, chemin	Débit plus élevé pour l'analytique par lots ; courbe d'apprentissage GSQL plus raide pour les analystes
Amazon Neptune	Non (service cloud)	openCypher / Gremlin / SPARQL	Neptune ML pour les réseaux neuronaux de graphes	Adapté uniquement aux locataires cloud TS/SCI ; pas pour un vrai air-gap
JanusGraph	Oui (open source)	Gremlin	Via backend Spark/Hadoop	Entièrement open source ; fonctionne sur HBase, Cassandra ou RocksDB ; idéal pour les nœuds déployés en périphérie avec stockage embarqué

Pour les nœuds de renseignement déployés en avant ou en périphérie de réseau — une équipe d'exploitation avec un ordinateur portable et un réseau tactique — les magasins de graphes embarqués soutenus par RocksDB (JanusGraph + EmbeddedGraph) ou le mode embarqué de Neo4j offrent la plus faible empreinte. Pour les réseaux analytiques en garnison avec accès concurrent multi-analyste, le déploiement en cluster de Neo4j Enterprise ou l'architecture distribuée de TigerGraph fournissent le débit nécessaire pour des sessions d'analyse de liens simultanées. Amazon Neptune n'est approprié que lorsque l'enclave de classification est déjà hébergée dans une location cloud souveraine au niveau de classification requis.

Une considération opérationnelle critique est la couche d'application du contrôle d'accès multi-niveau (MLS). La base de données en graphe elle-même est rarement compatible MLS : elle stocke des données et exécute des requêtes sans comprendre intrinsèquement les étiquettes de classification. La couche d'application se situe dans la passerelle de requêtes — un composant middleware qui réécrit chaque requête Cypher entrante pour ajouter une clause WHERE filtrant sur l'ensemble de classification autorisé de l'utilisateur demandeur. Cela doit être mis en œuvre soigneusement : un utilisateur accrédité SECRET ne doit pas pouvoir déduire l'existence d'arêtes TOP SECRET par des différences de timing ou des messages d'erreur, même s'il ne peut pas voir le contenu de l'arête.

Patterns de requêtes pour l'analyse de liens

L'analyse de liens en Cypher se réduit à un petit vocabulaire de patterns qui se composent en questions analytiques complexes. Les exemples suivants supposent Neo4j et la bibliothèque GDS, mais les patterns se traduisent en GSQL ou Gremlin avec des modifications syntaxiques mineures.

Chemin le plus court entre deux entités d'intérêt :

// Trouver le chemin le plus court, filtrant les arêtes à haute confiance non révoquées
MATCH (a:Entity {id: $seedA}),
      (b:Entity {id: $seedB}),
      p = shortestPath((a)-[*1..6]-(b))
WHERE ALL(r IN relationships(p)
      WHERE r.confidence >= 0.6
        AND NOT coalesce(r.revoked, false)
        AND (r.valid_until IS NULL OR r.valid_until > datetime()))
RETURN p, length(p) AS hops
ORDER BY hops ASC

Expansion du voisinage à K sauts depuis une graine, avec fenêtre temporelle :

// Voisinage à 3 sauts actif durant une fenêtre opérationnelle de 30 jours
MATCH (seed:Entity {id: $seedId})-[r*1..3]-(neighbor)
WHERE ALL(rel IN r
      WHERE rel.confidence >= 0.5
        AND rel.valid_from <= $windowEnd
        AND (rel.valid_until IS NULL OR rel.valid_until >= $windowStart))
RETURN DISTINCT neighbor, labels(neighbor) AS types
LIMIT 500

Détection de communautés avec Louvain (exécuté sur une projection de graphe en mémoire) :

// Projeter un sous-graphe pondéré par confiance, exécuter Louvain, écrire les IDs de communauté
CALL gds.graph.project(
  'intel-graph',
  ['Entity'],
  {COMMUNICATES_WITH: {properties: ['confidence']}})

CALL gds.louvain.write('intel-graph', {
  writeProperty: 'communityId',
  relationshipWeightProperty: 'confidence'
}) YIELD communityCount, modularity

// Puis afficher les pairs de la communauté de la graine
MATCH (seed:Entity {id: $seedId})
MATCH (peer:Entity {communityId: seed.communityId})
WHERE peer.id <> $seedId
RETURN peer ORDER BY peer.degreeCentrality DESC LIMIT 50

Analyse de liens temporelle — cadence d'activité dans le temps :

// Compter les activations d'arêtes par semaine calendaire pour l'analyse de pattern temporel
MATCH (a:Entity {id: $seedId})-[r:COMMUNICATES_WITH]-()
WHERE r.valid_from >= $rangeStart AND r.valid_from <= $rangeEnd
WITH r,
     date.truncate('week', r.valid_from) AS week
RETURN week,
       count(r) AS contact_count,
       avg(r.confidence) AS avg_confidence
ORDER BY week ASC

L'analyse de liens temporelle est le pont vers le mode opératoire dans l'analyse du renseignement militaire : lorsque la cadence des activations d'arêtes d'un nœud change — la fréquence diminue, les horaires changent, les partenaires de contact tournent — le graphe révèle ce changement comme une anomalie structurelle même avant qu'un modèle comportemental dédié ne soit entraîné sur l'entité. La requête de graphe est le détecteur de premier passage ; le modèle comportemental est la couche de confirmation.

Une note sur les performances : la détection de communautés et les algorithmes de centralité s'exécutent sur le graphe projeté complet, pas seulement sur un sous-graphe. Pour un graphe de dizaines de millions de nœuds, ces algorithmes doivent être planifiés comme des tâches par lots en arrière-plan plutôt que des requêtes interactives. Les résultats — communityId et degreeCentrality écrits comme propriétés de nœud — sont ensuite disponibles pour une recherche instantanée dans les requêtes d'analyste sans réexécuter l'algorithme.

Intégration des graphes de connaissance avec les pipelines C2 et OSINT

Un graphe de connaissance non connecté à des sources de données en direct est un artefact historique plutôt qu'un outil opérationnel. L'architecture d'intégration comporte trois canaux d'ingestion et deux points de consommation.

Ingestion de flux CTI (STIX/TAXII). Un client TAXII interroge les points de terminaison de collection enregistrés — plateformes de partage CTI alliées, flux nationaux de renseignement sur les menaces — et traite les bundles STIX entrants via le pipeline SDO-vers-nœud / SRO-vers-arête décrit ci-dessus. Le traitement des bundles est idempotent : MERGE sur l'identifiant STIX garantit qu'un objet redélivré met à jour les propriétés plutôt que de créer un nœud en double. Les nouveaux objets sont résolus par entités par rapport au graphe existant avant d'être validés ; si un nouveau ThreatActor STIX correspond à un nœud Person non-STIX existant par résolution d'identité probabiliste, les deux sont fusionnés et toutes les arêtes des deux enregistrements sont désormais traversables depuis le nœud canonique.

Ingestion de rapports HUMINT. Les rapports en langage naturel provenant de sources humaines sont traités via un pipeline NLP qui effectue la reconnaissance d'entités nommées, l'extraction de relations et la résolution de coréférences, puis mappe les entités et relations extraites au schéma de graphe. Le pipeline NLP n'est pas le graphe : c'est la couche de transformation de la prose vers les éléments de graphe structurés. Les entités extraites passent par le même pipeline de résolution d'entités que toute autre source, avec une confiance de base généralement inférieure (l'extraction de prose est moins fiable qu'un enregistrement de base de données structuré) qui est propagée aux arêtes que le rapport HUMINT soutient.

Ingestion de pistes SIGINT. Les observations SIGINT — une communication entre deux points de terminaison à un moment spécifique, un appareil apparaissant à un endroit spécifique — arrivent comme un flux continu. Chaque observation crée ou rafraîchit une arête dans le graphe : une arête COMMUNICATES_WITH entre deux nœuds de personne ou d'appareil, ou une arête OBSERVED_AT entre un appareil et un lieu. Le valid_from de l'arête est l'horodatage de l'observation ; valid_until est null à moins que le flux SIGINT ne ferme explicitement l'observation. L'ingestion en flux à volume élevé nécessite un ingesteur soutenu par une file d'attente (Kafka ou équivalent) qui met en tampon les observations et les regroupe en écritures de graphe à un rythme que la base de données peut absorber sans bloquer les requêtes interactives.

Les deux points de consommation sont le poste de travail de l'analyste et l'image opérationnelle commune (COP) du C2.

Le poste de travail de l'analyste expose une interface d'analyse de liens où un analyste spécifie une entité de départ, sélectionne les types de relations et les seuils de confiance, et étend un voisinage délimité. Le résultat est rendu comme une disposition de graphe dirigée par les forces avec la confiance encodée comme opacité des arêtes et l'appartenance à la communauté encodée comme couleur des nœuds. Les scores de centralité déterminent la taille des nœuds. L'analyste ne voit jamais tout le graphe — seulement le sous-graphe délimité, filtré, piloté par requête qui répond à une question spécifique. Une bonne interface fournit le pattern Cypher dans une barre latérale afin que l'analyste comprenne exactement ce qui a été interrogé et puisse l'affiner.

L'intégration COP C2 présente les profils d'entités dérivés du graphe — les subordonnés connus d'une unité, l'appartenance à la communauté d'un individu, les dépendances d'approvisionnement d'une installation — sous forme de popups sur l'image tactique. Lorsque l'opérateur clique sur une entité suivie, le système C2 interroge le graphe de connaissance pour le contexte réseau de cette entité et affiche les cinq entités les plus associées par confiance et centralité. Cela transforme le graphe de connaissance d'un outil analytique autonome en composant actif de l'image opérationnelle : renseignement structurel sur les relations, disponible en contexte, sans nécessiter que l'opérateur ouvre un outil séparé.

Principe d'architecture : le graphe de connaissance n'est pas la visualisation — c'est la couche de données. Investissez dans la qualité d'ingestion, la précision de la résolution d'entités et les performances d'index. La visualisation est le dernier kilomètre. Une interface analyste construite sur un graphe mal résolu avec des arêtes à faible confiance induira en erreur plus rapidement et avec plus de certitude que tout processus manuel qu'elle remplace. Le graphe gagne la confiance opérationnelle par l'auditabilité : chaque connexion affichée doit être développable jusqu'à ses preuves sous-jacentes, avec source, heure de collecte et confiance attachées.

Intégrez le renseignement relationnel dans votre image opérationnelle

Corvus HEAD fusionne des sources de renseignement multiples en un graphe de connaissance interrogeable — résolution d'entités, analyse de liens et visualisation de réseau intégrée au C2, conçue pour les analystes qui ont besoin de réponses auditables et pondérées par confiance, pas de toiles d'araignée.

Explorer Corvus HEAD → Réserver un briefing

Cette analyse a été préparée par les ingénieurs de Corvus Intelligence qui construisent des systèmes de renseignement et d'intégration de données critiques pour les organisations de défense et gouvernementales. En savoir plus sur notre équipe →

Questions fréquemment posées

Pourquoi les explosions de JOIN relationnels les rendent-elles inadaptées à l'analyse de liens de renseignement en profondeur ?

Les bases de données relationnelles répondent aux questions de relation par des opérations JOIN qui multiplient l'ensemble de travail à chaque saut. Une requête à deux sauts nécessite une auto-jointure ; une requête à cinq sauts en nécessite quatre, et chacune multiplie le résultat précédent par un facteur de ramification potentiellement important. Sur une table de dix millions d'enregistrements d'entités, une traversée à cinq sauts peut produire des ensembles intermédiaires de trillions de lignes avant le filtrage. L'analyse de liens de renseignement nécessite régulièrement cinq sauts ou plus — d'un téléphone intercepté au réseau de réseaux au-dessus — ce qui rend les requêtes relationnelles en profondeur soit extrêmement lentes soit opérationnellement impossibles dans une session.

Quelle est la différence entre un graphe de propriétés et un graphe de connaissance RDF/OWL dans un contexte militaire ?

Un graphe de propriétés stocke les nœuds et les arêtes avec des étiquettes typées et des propriétés clé-valeur arbitraires sur les deux. Il est flexible en termes de schéma et optimisé pour les requêtes de traversée. Un graphe de connaissance RDF modélise tout comme des triplets sujet-prédicat-objet ; OWL ajoute une couche d'ontologie avec des sémantiques formelles qui supporte l'inférence. Pour le renseignement militaire, les graphes de propriétés sont plus pratiques opérationnellement : ils gèrent naturellement les propriétés de provenance et de confiance et s'intègrent avec les outils Cypher que les analystes utilisent déjà. RDF/OWL est préféré là où l'interopérabilité des normes formelles est importante, comme l'intégration de contenu STIX au niveau sémantique ou la fédération avec des bases de connaissances alliées utilisant des protocoles de données liées.

En quoi la désambiguïsation d'entités diffère-t-elle de la résolution d'entités dans le contexte du renseignement ?

La résolution d'entités décide si deux enregistrements structurés font référence à la même entité du monde réel et les fusionne. La désambiguïsation d'entités mappe une mention textuelle — un nom dans un rapport HUMINT — à un nœud de graphe existant. Les deux doivent être résolus en séquence : le NLP extrait les mentions, la désambiguïsation les relie aux nœuds candidats, et la résolution décide si les candidats sont la même entité. Les erreurs de désambiguïsation créent de fausses arêtes ; les erreurs de résolution fragmentent ou sur-fusionnent des nœuds. Les deux nécessitent des scores de confiance et des décisions réversibles, avec une journalisation complète des preuves qui ont motivé chaque décision.

À quoi ressemble un objet de relation STIX en tant qu'arête de graphe dans neo4j ?

Un SRO STIX devient une arête dirigée dont le type est la chaîne relationship_type (par exemple « uses », « targets »). L'identifiant STIX propre du SRO, la confiance, les champs created et modified sont stockés comme propriétés d'arête. Les champs source_ref et target_ref se résolvent vers des nœuds existants par leur propriété stix_id. Les champs temporels (valid_from, valid_until) sont indexés comme propriétés d'arête afin que les requêtes Cypher à fenêtre temporelle puissent filtrer les relations actives durant une fenêtre opérationnelle spécifique. Les SROs révoqués définissent revoked: true sur l'arête et sont exclus des traversées par un filtre WHERE NOT par défaut, mais conservés pour l'audit.

Comment gérer les objets STIX versionnés dans un magasin de graphes ?

Le versionnage STIX utilise le même identifiant avec un nouvel horodatage modified. Deux stratégies s'appliquent. Le remplacement par instantané ne conserve que la dernière version de chaque nœud — simple mais perd l'historique. Le versionnage temporel de nœud crée un nouveau nœud par horodatage modified et chaîne les versions avec des arêtes HAS_VERSION, permettant des requêtes de voyage dans le temps pour reconstruire toute image de renseignement passée. Pour le renseignement opérationnel, le remplacement par instantané suffit ; pour les flux de travail analytiques qui doivent retracer comment une image de menace a évolué avant une décision, le versionnage temporel est essentiel. Les deux stratégies doivent marquer les objets révoqués avec revoked: true et les supprimer des traversées sans les supprimer, préservant la piste d'audit.

Quel est le problème des super-nœuds dans les graphes de renseignement militaire ?

Un super-nœud est un nœud avec un degré extrêmement élevé — une ligne téléphonique publique partagée, une IP NAT commune ou un hub logistique majeur. Traverser un super-nœud multiplie l'ensemble de résultats par son degré, rendant les requêtes non terminantes. Dans l'analyse de centralité, le super-nœud apparaît comme l'entité la plus importante même s'il reflète un artefact d'infrastructure, pas une signification opérationnelle. Les atténuations incluent la limitation du degré d'expansion par nœud, la maintenance d'une liste d'exclusion de hubs et l'application d'un filtrage d'arêtes pondéré par degré afin que les arêtes passant par des nœuds à très haut degré contribuent moins aux scores de chemin.

Quelle base de données en graphe convient le mieux aux déploiements militaires de renseignement en air-gap ?

Les déploiements en air-gap nécessitent un moteur de graphe sans rappels de licence réseau. Neo4j Enterprise avec une licence hors ligne est le choix le plus compatible avec les outils d'analyse. TigerGraph supporte une licence groupée sur site. JanusGraph est entièrement open source et fonctionne sur RocksDB embarqué — idéal pour les déploiements en périphérie. Amazon Neptune est un service cloud et inadapté au vrai air-gap. Pour les nœuds de périphérie déployés en avant, JanusGraph avec RocksDB offre la plus petite empreinte. Pour les réseaux analytiques en garnison, le clustering Neo4j Enterprise ou TigerGraph distribué fournit la concurrence multi-analyste nécessaire.

Quel pattern Cypher trouve le chemin de renseignement le plus court entre deux entités ?

Le pattern canonique est : MATCH (a:Entity {id:$seedA}),(b:Entity {id:$seedB}), p=shortestPath((a)-[*1..6]-(b)) WHERE ALL(r IN relationships(p) WHERE r.confidence>=0.6 AND NOT r.revoked AND (r.valid_until IS NULL OR r.valid_until>datetime())) RETURN p, length(p) AS hops. La borne [*1..6] empêche les traversées incontrôlées. Pour les chemins les plus courts pondérés par confiance, la procédure GDS Dijkstra avec propriété de poids (1-confidence) préfère les arêtes à haute confiance en leur assignant un coût plus faible.

Comment la détection de communautés aide-t-elle les analystes à prioriser les cibles ?

Les algorithmes de détection de communautés — Louvain, propagation d'étiquettes, composants faiblement connectés — partitionnent le graphe en clusters d'entités plus densément connectées en interne qu'en externe. Dans le renseignement militaire, une communauté correspond généralement à une cellule fonctionnelle : des individus qui communiquent, un réseau logistique partageant des ressources ou des installations liées par des chaînes d'approvisionnement. L'exécution de Louvain côté serveur et l'écriture de communityId comme propriété de nœud permettent aux analystes de révéler instantanément tous les pairs de communauté d'une entité de départ, d'identifier les nœuds de pont à haute centralité d'intermédiarité reliant des clusters autrement séparés, et de prioriser la collecte vers les leaders de communauté identifiés par la centralité de degré intra-communautaire.

Comment les flux CTI et les pistes SIGINT en temps réel sont-ils réconciliés dans un graphe de connaissance en direct ?

Les flux CTI arrivent comme des bundles STIX traités par lots ; le SIGINT arrive comme un flux continu. Un pipeline en deux étapes réconcilie les deux. L'étape par lots traite les bundles STIX : MERGE sur l'identifiant STIX crée ou met à jour les nœuds, les SROs deviennent des arêtes. L'étape de streaming traite les observations SIGINT via un ingesteur soutenu par Kafka : chaque observation est résolue par entités en quasi-temps réel et crée une arête délimitée dans le temps. Les deux étapes écrivent dans le même graphe de propriétés, de sorte que les requêtes Cypher voient une image unifiée. Les propriétés temporelles d'arête du graphe isolent la fenêtre de streaming la plus récente sans réexécuter l'historique par lots.