Architecture de plateforme GEOINT : ingestion, traitement et diffusion du renseignement géospatial à grande échelle

Le renseignement géospatial est la discipline qui répond à la question : que se passe-t-il, où et quand ? Une plateforme GEOINT est l'infrastructure logicielle qui permet de répondre à cette question à grande échelle — en ingérant des images satellitaires provenant de multiples capteurs et fenêtres de revisite, en les fusionnant avec des vidéos de drones, des données d'altitude et des couches vectorielles, en traitant les pixels bruts en produits exploitables et en livrant ces produits aux analystes à leur poste de travail ainsi qu'aux soldats équipés de tablettes Android sur le terrain. Le défi technique est que chaque étape de cette chaîne opère sur des volumes de données, des contraintes de latence et des conventions de format différents qui n'ont jamais été conçus pour interopérer.

Cet article décrit une architecture de plateforme GEOINT de niveau production, de l'ingestion à la consommation. Il couvre les types de données alimentant le système, le pipeline de conversion de formats et de tuilage, l'architecture de stockage pour les images brutes et traitées, le pipeline de traitement pour la détection de changements et la reconnaissance d'objets, la couche de service pour les analystes et les appareils TAK, le modèle de distribution hors ligne pour les environnements à bande passante limitée, l'intégration des postes de travail des analystes, ainsi que les contrôles de classification et de diffusabilité qui régissent le flux de données entre les enclaves.

Types de données GEOINT : ce que la plateforme doit ingérer

Une plateforme GEOINT complète ingère des données provenant de cinq catégories de sources, chacune avec des conventions de format et des caractéristiques opérationnelles distinctes.

Imagerie satellitaire — électro-optique (EO) et SAR. L'imagerie électro-optique est la plus familière : images en spectre visible et proche infrarouge produites par des capteurs tels que WorldView, Sentinel-2 et Planet SkySat. L'imagerie EO fournit les détails visuels riches nécessaires à la reconnaissance d'objets et à la détection de changements, mais se dégrade par couverture nuageuse et est limitée aux acquisitions diurnes pour les capteurs panchromatiques. L'imagerie Synthetic Aperture Radar (SAR) est produite par des capteurs dont Sentinel-1, ICEYE et Capella Space ; elle pénètre la couverture nuageuse et opère de jour comme de nuit, au prix d'un modèle d'interprétation plus complexe — les images SAR représentent la rétrodiffusion radar, non l'apparence visuelle. Les produits EO et SAR sont couramment livrés en NITF (National Imagery Transmission Format) ou en GeoTIFF, avec des métadonnées géométriques RPC (Rational Polynomial Coefficient) associées pour l'orthorectification.

Vidéo plein mouvement (FMV) de drone. Les drones tactiques produisent des flux vidéo continus — typiquement encodés H.264 ou H.265 — annotés avec des métadonnées MISB (Motion Imagery Standards Board) KLV intégrant la position du capteur, l'attitude de la plateforme, la portée oblique et le champ de vision du capteur. Le flux KLV permet à la plateforme de géolocaliser chaque image vidéo comme une empreinte quadrilatérale sur le sol. Les images à haute valeur peuvent être extraites en images fixes et ingérées dans le pipeline d'imagerie pour exploitation. Les archives FMV sont stockées séparément de l'imagerie en raison de leur volume ; la plateforme maintient un index spatial et temporel pour que les analystes puissent interroger les segments vidéo couvrant une zone et une fenêtre temporelle données.

Modèles d'élévation. Les Modèles Numériques de Terrain (MNT) et les Modèles Numériques d'Élévation (MNE) fournissent la troisième dimension qui manque à l'imagerie. DTED (Digital Terrain Elevation Data) est le format standard de l'OTAN aux niveaux 0 (espacement 900 m), 1 (90 m) et 2 (30 m). SRTM (Shuttle Radar Topography Mission) offre une couverture quasi mondiale à 30 m. Des dérivés à plus haute résolution sont produits à partir de paires stéréoscopiques d'imagerie EO ou d'interférométrie SAR. Les données d'élévation sont essentielles pour l'orthorectification de l'imagerie, l'analyse de visibilité 3D, le masquage du terrain pour la planification des capteurs et la géolocalisation des observations de capteurs depuis des drones et des aéronefs.

Couches vectorielles. Bases de données d'entités nommées, limites administratives, réseaux routiers, hydrographie et données d'installations sont distribués sous forme de jeux de données vectoriels dans des formats incluant Esri File Geodatabase, GeoPackage, Shapefile et GeoJSON. Les couches vectorielles classifiées telles que les bases de données de cibles et les couches d'ordre de bataille sont gérées dans l'architecture de classification et ne sont jamais mélangées avec des couches non classifiées au niveau de la base de données.

OSINT collaboratif. Les extraits OpenStreetMap, les données de localisation dérivées des réseaux sociaux et les rapports de changements agrégés commercialement fournissent des mises à jour quasi en temps réel que la revisite satellitaire ne peut pas égaler. Les flux OSINT sont ingérés en GeoJSON ou en schémas JSON personnalisés et traités comme des couches à faible confiance, non classifiées, qui informent les décisions de collecte — orientant la collecte satellitaire vers les zones où l'OSINT signale une activité — plutôt que comme des produits de renseignement primaires.

Pipeline d'ingestion : ingestion NITF, conversion COG et pyramides de tuiles

Les images brutes arrivent à la couche d'ingestion dans des formats et projections hétérogènes. Le pipeline d'ingestion les normalise en un format de stockage cohérent avant qu'une étape de traitement ne s'exécute.

Ingestion NITF et GeoTIFF. Les fichiers NITF sont analysés à l'aide du pilote NITF de GDAL, qui extrait les bandes d'image, les coefficients RPC et les champs d'en-tête de sécurité. Les champs de sécurité renseignent les attributs de classification et de diffusabilité de l'enregistrement de métadonnées du catalogue. Pour les conteneurs NITF multi-segments (grandes images divisées en plusieurs segments d'image), GDAL gère le réassemblage de manière transparente. Les ingestions GeoTIFF sont plus simples : GDAL lit directement les métadonnées GeoTransform ou RPC intégrées et les données d'image.

Orthorectification. Avant toute opération spatiale, les images brutes doivent être orthorectifiées — corrigées pour la géométrie du capteur et le déplacement du terrain — afin de produire un produit cohérent projeté sur le sol. La commande GDAL gdalwarp avec correction RPC et entrée DEM effectue cette étape. La sortie est un GeoTIFF projeté en WGS84 ou dans une zone UTM locale, avec une erreur résiduelle typiquement inférieure à un pixel à la résolution source.

Conversion en Cloud-Optimised GeoTIFF. Chaque image orthorectifiée est immédiatement convertie au format COG à l'aide de gdal_translate avec le pilote -of COG. Le COG organise les données d'image en tuiles entrelacées avec des niveaux de vue d'ensemble (pyramides) intégrés à des résolutions réduites par puissances de deux. Le fichier résultant prend en charge un accès efficace par requêtes HTTP de plage : un serveur de tuiles ou un client à accès direct peut récupérer n'importe quel sous-ensemble spatial à n'importe quel niveau de zoom sans lire l'intégralité du fichier. La conversion COG double généralement l'empreinte de stockage par rapport à l'image source en raison des niveaux de pyramide ; il s'agit d'un compromis acceptable pour l'élimination d'une infrastructure séparée de génération de tuiles.

Génération de pyramides de tuiles. Pour les couches nécessitant un service de cache de tuiles plus rapide que les requêtes HTTP de plage COG ne peuvent fournir — cartes de base à fort trafic, sorties de détection de changements fréquemment interrogées — une étape de tuilage explicite génère une pyramide de tuiles à l'aide de MapTiler ou de gdal2tiles.py de GDAL. La sortie est une structure de répertoires XYZ ou un conteneur MBTiles unique, écrit dans le stockage d'objets et indexé dans le catalogue de cache de tuiles. Le choix entre le service COG à la demande et les pyramides de tuiles pré-générées est dicté par la fréquence de requêtes : un nouveau passage satellite ingéré pour un accès analytique immédiat est servi en COG ; une carte de base utilisée par des milliers d'appareils TAK simultanés est pré-tuilée.

Architecture de stockage : stockage d'objets, PostGIS et conteneurs de tuiles

Une plateforme GEOINT gère trois niveaux de stockage distincts, chacun optimisé pour un modèle d'accès différent.

Stockage d'objets pour les images brutes et traitées. Toutes les données raster — ingestions brutes, COGs orthorectifiés, produits dérivés — sont stockées dans un stockage d'objets : MinIO pour les déploiements sur site air-gapped, des magasins compatibles S3 pour les environnements connectés au cloud. Le stockage d'objets offre une capacité horizontale pratiquement illimitée, une récupération adressée par le contenu via URI et une prise en charge native des requêtes HTTP de plage sur lesquelles COG s'appuie. Les politiques de cycle de vie archivent les images froides (non accédées depuis 90 jours) vers des niveaux moins coûteux ; les images chaudes (dans la fenêtre opérationnelle actuelle) sont conservées sur des stockages SSD à haut débit.

PostGIS pour les entités vectorielles et les métadonnées d'imagerie. Le catalogue d'imagerie, les couches vectorielles, les annotations des analystes et les résultats de détection de changements sont tous stockés dans PostGIS. La table du catalogue d'imagerie stocke une ligne par scène avec des colonnes pour le temps d'acquisition, le capteur, le niveau de classification, la couverture nuageuse et une colonne geometry(POLYGON, 4326) pour l'empreinte de la scène. Un index spatial GiST sur cette colonne rend les requêtes d'intersection de boîtes englobantes — « trouver toutes les scènes couvrant cette zone d'intérêt » — sous-millisécondes même avec des millions d'entrées dans le catalogue. Les tables de couches vectorielles suivent le même modèle : chaque entité possède une colonne géométrie et un ensemble de colonnes d'attributs ; l'indexation spatiale permet des requêtes rapides à l'échelle de tuiles de carte. Pour les compromis d'indexation complets, voir Indexation géospatiale pour la défense.

MBTiles et PMTiles pour la distribution hors ligne. Les conteneurs de tuiles conditionnés pour une utilisation hors ligne sont stockés aux côtés des images traitées dans le stockage d'objets, mais sont également copiés dans un magasin de distribution hors ligne dédié — un partage réseau ou un disque physiquement isolé — à partir duquel les appareils TAK et les ordinateurs portables des analystes récupèrent des packages. Les fichiers MBTiles sont des bases de données SQLite : un schéma simple avec une table tiles à clés de zoom, colonne et ligne les rend trivialement transférables et lisibles par tout appareil compatible SQLite. PMTiles, une alternative émergente, stocke les tuiles dans un fichier binaire plat avec un index basé sur l'en-tête, permettant un accès direct par requêtes HTTP de plage depuis un serveur web statique sans processus proxy de tuiles.

Pipeline de traitement : détection de changements, reconnaissance d'objets, cohérence SAR

Le pipeline de traitement transforme les images brutes en produits prêts pour les analystes. Trois modes de traitement principaux couvrent la majorité des exigences opérationnelles.

Détection de changements par différence de pixels. L'approche de détection de changements la plus simple soustrait une image de référence d'une nouvelle image de la même zone, applique un seuil à la différence absolue et produit un masque de changements binaire. C'est peu coûteux en calcul — une paire de pixels 10 000 × 10 000 se termine en quelques secondes sur un seul cœur CPU — et ne nécessite pas de données d'entraînement. Ses modes de défaillance sont bien compris : changement saisonnier de végétation, différences d'angle d'éclairage et dérive de calibration des capteurs génèrent tous des faux positifs. Pour les applications tactiques où la vitesse importe plus que le taux de faux positifs, la différence de pixels est la valeur par défaut correcte.

Détection de changements basée sur l'apprentissage automatique. Un réseau de neurones convolutif entraîné sur des paires d'images étiquetées avant/après produit une carte de probabilité de changements plutôt qu'un masque binaire. Les modèles entraînés se généralisent à travers les variations d'éclairage et saisonnières car ils apprennent des caractéristiques au niveau de la scène plutôt qu'au niveau des pixels. Le compromis est le coût d'inférence — l'inférence accélérée GPU sur une grande scène prend des dizaines de secondes — et l'exigence de données d'entraînement étiquetées représentatives de l'environnement opérationnel. En production, la différence de pixels sert de filtre rapide initial : seules les régions signalées par la différence de pixels sont soumises à l'inférence ML, réduisant la charge GPU d'un ordre de grandeur pour les scènes à changements rares.

Détection d'objets sur les images. Les modèles de détection d'objets — typiquement des architectures de classe YOLO affinées sur des images aériennes — identifient les véhicules, aéronefs, navires, installations et activités de construction dans les images EO. Le modèle produit des boîtes englobantes avec des étiquettes de classe et des scores de confiance ; les boîtes englobantes sont géolocalisées à l'aide des métadonnées d'orthorectification de la scène et écrites dans PostGIS comme entités ponctuelles ou polygonales avec les métadonnées de détection attachées. Les objets détectés alimentent le pipeline de fusion plus large comme des observations dérivées de GEOINT : un convoi de véhicules militaires détecté dans un produit d'imagerie peut être corrélé avec une piste radar ou un relèvement SIGINT dans la couche de fusion multi-capteurs.

Analyse de cohérence SAR. La cohérence est calculée à partir de deux images SAR Single Look Complex (SLC) co-enregistrées acquises sur la même zone à des moments différents. La valeur de cohérence pixel par pixel — la corrélation croisée normalisée des valeurs de pixels complexes — va de 0 (décorrélation complète, indiquant un changement de surface) à 1 (cohérence parfaite, indiquant aucun changement). Les cartes de perte de cohérence produites à partir de paires d'images Sentinel-1 ou ICEYE mettent en évidence les perturbations du sol avec une sensibilité dépassant la différence de pixels dans les terrains végétalisés ou à faible contraste. Le traitement nécessite l'accès à des données de niveau SLC (non les produits d'intensité détectés au sol couramment distribués aux utilisateurs généraux) et des logiciels de traitement SAR interférométrique spécialisés — SNAP, ISCE ou des implémentations CUDA personnalisées pour les exigences en temps réel.

Couche de service : points de terminaison OGC, tuiles vectorielles et intégration TAK

Les produits de renseignement traités doivent atteindre les analystes et les opérateurs sur le terrain via des interfaces standardisées que les outils existants peuvent consommer sans travaux d'intégration personnalisés.

Points de terminaison OGC WMS et WMTS. La norme OGC Web Map Service définit un protocole de demande d'images cartographiques à un serveur selon une boîte englobante, un système de référence de coordonnées, une taille d'image et un nom de couche. WMS est la norme d'interopérabilité universelle : chaque outil SIG — QGIS, ArcGIS, Global Mapper, ATAK — peut consommer un point de terminaison WMS. Sa faiblesse est la latence : chaque requête déclenche un rendu côté serveur. WMTS résout ce problème avec des caches de tuiles pré-rendus à des niveaux de zoom fixes ; un point de terminaison WMTS peut servir des milliers de requêtes de tuiles simultanées depuis le cache sans toucher au backend d'imagerie. MapServer, GeoServer et le plus léger TiTiler (un serveur de tuiles COG natif cloud) prennent en charge les deux normes.

OGC WFS pour les entités vectorielles. WFS expose les entités vectorielles — résultats de détection de changements, objets détectés, annotations des analystes — sous forme de réponses GeoJSON ou GML aux requêtes de filtres spatiaux et d'attributs. Les clients WFS récupèrent des entités pour l'édition et l'analyse plutôt que pour l'affichage ; les géométries retournées portent des charges utiles d'attributs complètes. Pour l'accès en lecture seule à haut débit, OGC API Features (la norme successeur) fournit une interface REST/JSON plus simple à mettre en cache et mieux adaptée aux applications web.

Tuiles vectorielles Mapbox. MVT est la norme de facto pour le service de tuiles vectorielles à haute performance. Les données vectorielles — réseaux routiers, entités nommées, couches des analystes — sont découpées en tuiles à chaque niveau de zoom et encodées en binaire Protocol Buffer ; les clients effectuent le rendu côté client à l'aide de WebGL, permettant un zoom et un panoramique fluides sans allers-retours vers le serveur. La plateforme GEOINT génère des archives MVT à partir de PostGIS à l'aide de tippecanoe ou de la fonction PostGIS ST_AsMVT, les stocke sous forme de MBTiles ou PMTiles et les sert via un serveur de tuiles que le client ATAK-web et les tableaux de bord d'analystes basés sur navigateur consomment.

Intégration ATAK et CloudTAK. Les appareils ATAK se connectent à un serveur TAK — l'implémentation de référence est TAK Server (Java), avec FreeTAKServer comme alternative plus légère — qui distribue des messages XML CoT (Cursor on Target) portant des positions d'objets en temps réel, des pistes et des alertes. La plateforme GEOINT s'intègre comme producteur CoT : lorsque le pipeline de traitement détecte un nouvel objet ou un changement significatif, il publie un événement CoT sur le serveur TAK, qui le relaie à tous les appareils ATAK abonnés. Les couches cartographiques — images traitées, couches de détection de changements — sont distribuées sous forme de packages MBTiles que le serveur TAK rend disponibles au téléchargement sur les appareils via le réseau local.

Distribution hors ligne : conditionnement MBTiles, synchronisation delta et sneakernet

Les opérateurs sur le terrain travaillent régulièrement dans des environnements où la connectivité au backend de la plateforme GEOINT est intermittente ou absente. La distribution hors ligne n'est pas un cas marginal ; c'est un chemin de livraison primaire.

Conditionnement MBTiles pour les appareils TAK. Le flux de travail de package hors ligne commence par un utilisateur — analyste ou officier du renseignement — définissant une zone d'intérêt et un ensemble de couches (carte de base, imagerie récente, couche de détection de changements, entités vectorielles) et demandant un package. La plateforme interroge PostGIS pour les tuiles pertinentes, les assemble en un fichier MBTiles SQLite unique à l'aide d'un script de tuilage et compresse le fichier pour le transfert. La taille du package est gérée par la plage de niveaux de zoom : une zone d'intérêt de 10 km × 10 km aux niveaux de zoom 0–17 produit typiquement un package de 200–500 Mo, qui tient sur une clé USB ou se transfère en quelques minutes sur un réseau Wi-Fi local.

Synchronisation delta pour les environnements à bande passante limitée. Lorsque des fenêtres de connectivité périodiques sont disponibles — une liaison satellite, un aéronef relais en survol — la plateforme prend en charge la synchronisation delta plutôt que la rélivraison complète du package. Le magasin de tuiles maintient un journal des modifications : chaque écriture de tuile est enregistrée avec un horodatage et une clé de tuile. Lorsqu'un appareil se reconnecte, il signale son dernier horodatage de synchronisation ; la plateforme calcule l'ensemble des tuiles modifiées depuis cet horodatage et transmet uniquement le différentiel. Pour une zone d'intérêt tactique avec des taux de changement modérés, une synchronisation delta couvrant 24 heures de mises à jour pourrait transmettre des dizaines de mégaoctets contre des centaines pour une actualisation complète du package.

Transfert sneakernet par code QR. Pour un refus de bande passante extrême — pas de radio, pas de Wi-Fi, isolation physique — les petits produits de renseignement (un seul résultat de détection de changements, une grille de cible, une couche vectorielle de quelques entités) peuvent être encodés en codes QR et transférés visuellement. La plateforme génère un code QR à partir d'un payload GeoJSON encodé en Base64 et compressé ; un appareil récepteur équipé d'un plugin ATAK ou d'une application personnalisée scanne le code et importe l'entité. Cette approche est limitée par la capacité de données du code QR — environ 3 Ko par code — mais couvre le problème critique du « dernier mètre » consistant à obtenir une grille de cible spécifique ou un signalement de véhicule sur un appareil sans autre connectivité.

Poste de travail de l'analyste : intégration QGIS, annotation et export

Le poste de travail de l'analyste est l'environnement d'exploitation principal. La plupart des analystes d'images de défense travaillent dans QGIS, complété par des outils d'exploitation spécialisés pour des types de produits spécifiques.

Intégration de plugin QGIS. Un plugin QGIS de plateforme GEOINT fournit un panneau ancré qui s'authentifie auprès de l'API de la plateforme, interroge le catalogue d'imagerie par zone d'intérêt et plage temporelle, et charge les scènes sélectionnées comme couches COG WMS directement dans le canevas QGIS. Le plugin gère automatiquement le renouvellement des jetons, les conventions de nommage des couches et l'alignement du système de référence de coordonnées. Les analystes peuvent superposer plusieurs scènes, basculer les couches de détection de changements et inspecter les attributs des objets détectés sans quitter l'environnement QGIS. Pour les intégrations QGIS personnalisées, voir aussi PostGIS pour les données géospatiales de défense pour la couche de base de données qui supporte le catalogue.

Flux de travail d'annotation. Les analystes annotent les entités — identification de cibles, étiquettes d'activité, notes d'exploitation — directement sur les images dans QGIS à l'aide de la barre d'outils de numérisation standard, le plugin écrivant les annotations dans la couche d'annotation PostGIS via l'API de la plateforme. Les annotations portent l'identité de l'analyste, le niveau de classification et une référence à l'UUID de l'image source, créant une chaîne de provenance complète de l'image brute au produit de renseignement fini. Les événements d'annotation sont publiés sur le bus de messagerie afin que les consommateurs en aval — la couche d'intégration TAK, le moteur d'analyse des modes de vie — reçoivent des mises à jour quasi en temps réel.

Export vers NITF, KMZ et GeoJSON. Les produits finis doivent quitter la plateforme dans les formats que les consommateurs de renseignement en aval attendent. L'export NITF enveloppe une image traitée avec les champs d'en-tête de sécurité appropriés renseignés à partir des métadonnées de classification du produit. L'export KMZ conditionne les entités vectorielles sous forme de superpositions Google Earth — le format de livraison standard pour de nombreuses organisations partenaires. L'export GeoJSON satisfait les consommateurs d'applications web modernes. Tous les exports sont enregistrés comme des événements de provenance, et la demande d'export capture l'identité du demandeur et le destinataire prévu — essentiel pour la comptabilité de classification et les exigences de piste d'audit.

Classification et diffusabilité : étiquetage des métadonnées, CDS et partage en coalition

Les contrôles de classification ne sont pas une couche ajoutée par-dessus la plateforme GEOINT — ils sont structurels. Chaque objet de données dans le système porte des métadonnées de classification et de diffusabilité dès le moment de son ingestion, et ces métadonnées gouvernent chaque décision d'accès, de traitement et de distribution.

Étiquetage des métadonnées. Les fichiers NITF portent la classification dans des champs d'en-tête de sécurité standardisés (FSCLAS, FSCLSY, FSREL, FSDCTP et champs connexes). Lors de l'ingestion, la plateforme lit ces champs et les stocke dans la base de données du catalogue sous forme d'attributs structurés, et non de chaînes de texte libre. Chaque produit dérivé hérite du niveau de classification le plus élevé de ses entrées sources, sauf si un flux de travail de déclassification explicite a été appliqué. Le schéma d'étiquetage suit les normes de classification nationales ou d'alliance (OTAN, équivalents nationaux) et est appliqué au niveau du modèle de données — un enregistrement de produit sans valeur de classification valide échoue à la validation de schéma et n'est pas admis dans le catalogue.

Intégration de solution inter-domaines. Les appliances CDS — gardes matériels ou logiciels certifiés pour le transfert de données inter-domaines — siègent entre les enclaves de classification et appliquent une politique basée sur le contenu aux données transitant des environnements de haut niveau vers les environnements de bas niveau. La plateforme GEOINT traite le CDS comme un système externe que la plateforme alimente via une interface d'export dédiée. Les produits de haut niveau destinés à la diffusion doivent passer par le flux de travail d'export CDS, qui valide les métadonnées de classification, applique les rédactions ou dégradations requises et génère un enregistrement d'audit des deux côtés de la frontière de domaine. La plateforme n'implémente pas la logique CDS en interne — c'est la frontière de certification du fournisseur CDS — mais elle fournit les métadonnées structurées que les moteurs de politique CDS requièrent.

Déclassification automatique pour le partage en coalition. Les opérations de coalition nécessitent le partage de produits de renseignement avec des nations partenaires qui peuvent ne pas avoir accès au niveau de classification le plus élevé. Les flux de travail de déclassification automatique opèrent sur deux dimensions : spatiale et spectrale. La déclassification spatiale supprime ou pixelise les entités dans les zones sensibles — emplacements spécifiques d'installations, identifiants de cibles à haute valeur — d'un produit avant qu'il ne franchisse les frontières de classification. La déclassification spectrale dégrade la résolution de l'image à un niveau cohérent avec la mise en garde de diffusabilité. Les opérations de déclassification sont paramétrées par les balises de diffusabilité du produit et le niveau d'habilitation du destinataire prévu ; la plateforme exécute automatiquement la transformation de déclassification appropriée et enregistre les paramètres de transformation dans le cadre de la provenance du produit. Les produits partagés en coalition sont marqués de la mise en garde du destinataire et ne peuvent être partagés plus avant que dans le cadre de l'autorité de distribution de cette mise en garde.

Lectures connexes

L'architecture de plateforme GEOINT se situe à l'intersection de l'ingénierie des données géospatiales, du traitement du renseignement et de la conception de logiciels de défense. Les articles ci-dessous traitent en profondeur de sujets connexes.

Ingénierie des données géospatiales : PostGIS pour les données géospatiales de défense, Indexation géospatiale pour la défense, Analyse des modes de vie pour le renseignement militaire.

Fusion et multi-INT : Architecture de fusion multi-capteurs, Guide complet de la fusion de données de défense, Modèle de fusion de données JDL.

Ingénierie des pipelines de données : Files d'attente de messages pour les pipelines de données de défense, Sourçage d'événements pour les pistes d'audit de défense, Construction d'un pipeline de fusion de défense : sources et schémas.

C2 et COP : Tableau opérationnel commun : comment il est construit, Guide complet des systèmes C2.