Pipeline d'ingestion d'imagerie satellitaire pour la défense : de la scène brute à l'analyse commandée

Une scène satellitaire n'est pas du renseignement. C'est une donnée brute : un raster compressé de valeurs de pixel encodées dans un format propriétaire, étiqueté avec un système de référence de coordonnées, accompagné d'un fichier de télémétrie capteur et enveloppé dans un conteneur de classification qui détermine qui peut y toucher. Entre cette livraison brute et un analyste de ciblage recevant sur son poste de travail une image orthorectifiée exploitable se trouve un pipeline d'ingestion : une série d'étapes de traitement automatisées que la plupart des programmes GEOINT sous-estiment jusqu'à ce qu'elles cèdent à 02h00 sur un besoin de collecte urgent. Cet article dissèque chaque étape d'un pipeline d'ingestion d'imagerie satellitaire de défense : comment la commande de scènes s'interface avec les API des opérateurs satellitaires et les systèmes de requête de moyens techniques nationaux (NTM), ce que fait la chaîne de prétraitement à l'imagerie brute avant qu'elle n'entre au catalogue, pourquoi les choix de format importent sur le plan opérationnel, comment les catalogues spatiaux permettent une récupération rapide des scènes parmi des millions de scènes archivées, et comment la logique de routage relie l'imagerie nouvellement ingérée aux outils d'exploitation et aux files des analystes qui en ont besoin.

Le pipeline d'imagerie satellitaire : périmètre et exigences opérationnelles

Un pipeline d'ingestion d'imagerie de défense couvre trois domaines fonctionnels : l'acquisition (faire entrer la scène du satellite ou du fournisseur dans le pipeline), le traitement (convertir la scène brute en un produit calibré, géoréférencé et catalogué) et le routage d'exploitation (livrer la bonne scène au bon outil ou au bon analyste au bon moment). Chaque domaine a des exigences distinctes de latence, de débit et de fiabilité qui façonnent les choix d'architecture. Pour la collecte de routine soutenant la production de renseignement à cycle long, une latence de bout en bout de plusieurs heures entre l'acquisition de la scène et sa disponibilité au catalogue est acceptable. Pour les besoins de renseignement à délai critique (TSI) (évaluation des dommages de combat, suivi des forces ou ciblage dynamique), le même pipeline doit comprimer cette latence à moins de 30 minutes, et dans certaines architectures à moins de 10.

Les exigences opérationnelles imposent des contraintes que les pipelines d'imagerie commerciaux ne rencontrent pas. La gestion de la classification signifie que des scènes de niveaux de sécurité différents ne peuvent pas partager une infrastructure de traitement sans accréditation, ou doivent être traitées dans des enclaves isolées avec des contrôles stricts de transfert de données entre niveaux. La journalisation de la chaîne de traçabilité (enregistrer qui a commandé une collecte, quels algorithmes de traitement ont été appliqués, quel analyste a reçu le produit et quelles actions d'exploitation ont été menées) est obligatoire pour le renseignement fini engageant la responsabilité juridique et opérationnelle. Les exigences de disponibilité pour les pipelines d'imagerie soutenant des opérations actives sont généralement plus élevées que pour les systèmes de production en temps de paix, nécessitant des nœuds de traitement redondants, un basculement automatique et des plans d'exploitation en mode dégradé pour le cas où le chemin principal de liaison descendante commerciale ou l'environnement de traitement cloud serait indisponible.

Le pipeline doit également être multi-source par conception. Un théâtre de défense ne repose pas sur une seule constellation satellitaire. Les fournisseurs commerciaux (Maxar WorldView Legion, Planet SuperDoves, Airbus Pleiades Neo, Satellogic), les fournisseurs de radar à synthèse d'ouverture (SAR) (Capella Space, ICEYE, Umbra) et l'imagerie de coalition ou NTM arrivent tous par des mécanismes de livraison différents, avec des conventions de format, des schémas de métadonnées et des contraintes de licence différents. Le pipeline d'ingestion abstrait ces différences derrière un schéma interne commun afin que les outils en aval de traitement, de catalogage et d'exploitation opèrent sur une représentation normalisée quelle que soit la source.

Commande et tâche de scènes : intégration avec les API des opérateurs satellitaires et les systèmes de requête NTM

La tâche satellitaire commence par un besoin : une zone géographique d'intérêt (AOI), une fenêtre de collecte, une exigence de résolution et une priorité de renseignement. Dans une organisation de défense, les besoins sont formalisés sous forme de besoins permanents (STANREQ) ou d'ordres de tâche ad hoc gérés dans un système de suivi des besoins. Le module de tâche du pipeline d'ingestion lit les besoins actifs et les traduit en ordres de collecte soumis à chaque opérateur satellitaire ou courtier NTM pertinent. Pour les fournisseurs commerciaux, cela signifie appeler une API REST de tâche : soumettre un polygone d'AOI, une fenêtre de collecte, une spécification de niveau de produit et des identifiants d'authentification. L'API Maxar SecureWatch, l'API Planet Orders et l'API Airbus Intelligence Access suivent toutes des schémas globalement similaires : POST d'une commande, interrogation du statut, et téléchargement du paquet de scène depuis une URL signée lorsque la collecte est confirmée.

L'intégration NTM suit un schéma différent régi par des protocoles de requête classifiés. Plutôt qu'une API REST commerciale, les requêtes NTM transitent par des systèmes de diffusion contrôlés utilisant des formats de message tels que STANAG 4559 (norme OTAN pour la requête et la livraison d'imagerie) ou des protocoles propres à la communauté du renseignement américaine. Le module d'interface NTM du pipeline d'ingestion gère l'authentification auprès du système de courtage pertinent, soumet les requêtes dans le schéma requis, surveille les notifications de livraison et récupère les paquets de scènes par le chemin de transfert autorisé. Le principe architectural clé est que la tâche NTM et la tâche commerciale doivent être gérées par des modules d'interface distincts avec des magasins d'identifiants isolés, même s'ils alimentent la même file de traitement en aval, car leurs exigences de classification, de gestion et d'audit diffèrent.

La gestion des commandes nécessite une machine à états locale pour suivre le cycle de vie de chaque requête de collecte : soumise, accusée réception par le fournisseur, collectée (passage satellite effectué), descendue par liaison, traitée par le fournisseur et livrée au point de terminaison d'ingestion du pipeline. Les échecs de traitement côté fournisseur, la couverture nuageuse au moment de la collecte et les conflits de tâche satellitaire nécessitent tous une logique de gestion : reprogrammation, escalade vers un fournisseur alternatif de priorité supérieure ou marquage du besoin comme non satisfait pour examen manuel. Le module de tâche doit conserver un historique de toutes les requêtes et de leurs résultats pour soutenir le reporting d'efficacité de la collecte et l'analyse de performance des fournisseurs.

Prétraitement de l'image brute : orthorectification, correction atmosphérique et masquage des nuages

Une scène livrée par un fournisseur commercial au Niveau 1B (corrigée radiométriquement, géométrie capteur) n'est pas prête pour l'exploitation ou le catalogage dans un système d'imagerie de défense. Avant d'entrer au catalogue spatial, elle doit être orthorectifiée (corrigée géométriquement pour supprimer les erreurs d'attitude du capteur et le déplacement dû au relief) et normalisée radiométriquement vers une échelle de réflectance de surface cohérente. Ces étapes ne sont pas des raffinements optionnels ; ce sont des prérequis pour superposer l'imagerie à des cartes vectorielles, effectuer la détection de changement par rapport à des collectes antérieures et mesurer des objets avec une précision suffisante à des fins de renseignement militaire.

L'orthorectification utilise les coefficients polynomiaux rationnels (RPC) fournis avec la scène et un modèle numérique d'élévation (MNE) pour projeter chaque pixel de la géométrie capteur vers une projection cartographique. Le SRTM 1 seconde d'arc (environ 30 m de résolution horizontale) est le MNE de référence pour la plupart des pipelines au niveau du théâtre ; pour les collectes haute résolution (0,3 à 0,5 m de distance d'échantillonnage au sol) où la précision de géolocalisation submétrique importe, un MNE haute résolution propre au théâtre dérivé de collectes satellitaires stéréoscopiques ou de lidar aéroporté est requis. Le modèle basé sur les RPC atteint une erreur circulaire probable (CEP) de 3 à 8 m sans contrôle au sol ; l'ajout d'un ensemble clairsemé de points de contrôle au sol (GCP) levés par GPS pour affiner la solution RPC améliore la précision à 1 à 2 m de CEP pour les produits post-traités. Pour les missions où la précision de géolocalisation absolue est critique (la mensuration de coordonnées de cible, par exemple), le pipeline doit intégrer une base de données de GCP et appliquer automatiquement l'étape d'affinage des RPC.

La correction atmosphérique convertit la radiance au sommet de l'atmosphère (TOA) en réflectance de surface, supprimant les effets de la diffusion moléculaire, de l'absorption par les aérosols et de la géométrie d'éclairement solaire. Cette étape est essentielle pour la détection de changement multispectrale : deux scènes collectées sous des conditions atmosphériques différentes présenteront des différences radiométriques apparentes dans chaque bande même si la surface au sol n'a pas changé, produisant de fausses alarmes. Les modèles de transfert radiatif tels que MODTRAN ou 6S calculent les coefficients de correction à partir de paramètres atmosphériques (épaisseur optique des aérosols, vapeur d'eau, colonne d'ozone) obtenus à partir de récupérations MODIS coïncidentes ou de champs d'analyse de modèle. Le masquage des nuages et de leurs ombres utilise un algorithme d'évaluation de qualité (FMask, S2cloudless ou un CNN entraîné) pour étiqueter chaque pixel comme clair, nuage, ombre ou neige/glace. Le masque de nuages est stocké comme bande compagne aux côtés de la scène traitée et se propage à travers tout le traitement en aval : les algorithmes de détection de changement, par exemple, doivent exclure les pixels masqués par les nuages de leurs statistiques.

Paysage des formats : NITF, GeoTIFF, JPEG 2000 et leurs cas d'usage de défense

Les pipelines d'imagerie de défense doivent gérer plusieurs formats coexistants car aucun format unique ne satisfait tous les cas d'usage au sein d'une organisation de défense. Le NITF 2.1 (National Imagery Transmission Format) est le conteneur de référence pour l'imagerie de renseignement dans les systèmes américains et alliés. Il transporte les données image aux côtés de champs de métadonnées structurés qu'aucun autre format ne prend nativement en charge : marquages de classification et de gestion de sécurité dans l'en-tête de fichier, enregistrements d'extension technique PIAIMC (Profile for Imagery Access) décrivant les paramètres du capteur et la géométrie de collecte, SENSRB (Sensor Data Records) pour la télémétrie précise du capteur, et coordonnées de coin IGEOLO et informations de projection cartographique. La structure du NITF permet aussi plusieurs segments image au sein d'un même fichier, autorisant une bande panchromatique, une pile multispectrale et un produit pansharpened à coexister dans un seul conteneur avec un en-tête de métadonnées partagé.

Le GeoTIFF (et plus précisément le Cloud-Optimized GeoTIFF, COG) est le format de travail pour la visualisation web, les couches de visualisation des plateformes GEOINT et les workflows de traitement IA/ML. Les fichiers COG organisent la structure interne de tuiles et d'aperçus de sorte que les requêtes HTTP par plage ne récupèrent que la portion de l'image visible au niveau de zoom actuel de la carte, permettant à un service de carte web de diffuser l'imagerie depuis le stockage objet sans pré-générer de pyramides de tuiles. Pour l'inférence des modèles IA (détection de changement, détection d'objets, extraction de caractéristiques), le GeoTIFF avec métadonnées lisibles par GDAL est le format d'entrée standard pour les frameworks ML géospatiaux basés sur Python. Le pipeline génère les dérivés COG à partir du maître NITF comme étape de sortie parallèle, en les écrivant vers la couche de stockage objet accessible aux services web et aux nœuds d'inférence ML.

Le JPEG 2000 occupe une niche spécifique dans l'imagerie de défense : c'est le format de compression intégré au sein des fichiers NITF pour les produits haute résolution où une compression sans perte ou visuellement sans perte à des ratios de 4:1 à 8:1 est requise, et c'est le format utilisé dans de nombreuses normes héritées d'échange d'imagerie entre alliés. La compression par ondelettes du JPEG 2000 surpasse le JPEG aux forts taux de compression tout en préservant les détails fins critiques pour l'exploitation (identification de véhicules, analyse d'installations, reconnaissance de schémas d'activité). Le pipeline doit être capable de lire et d'écrire des flux JPEG 2000 à la fois comme fichiers autonomes et comme données de segment image au sein de conteneurs NITF, en utilisant une bibliothèque conforme telle qu'OpenJPEG ou Kakadu. Pour les pipelines de fusion de données de défense traitant l'imagerie multi-source, la normalisation de toutes les sources vers un format interne cohérent avant l'indexation au catalogue élimine la gestion spécifique aux formats dans les outils en aval.

Indexation au catalogue : indexation spatiale et temporelle pour une récupération rapide des scènes

Le catalogue spatial est la mémoire opérationnelle du pipeline d'imagerie. Chaque scène traitée doit être indexée avant d'être utile : un NITF orthorectifié reposant dans le stockage objet qu'aucun catalogue ne connaît est effectivement invisible pour les analystes et les outils d'exploitation. La spécification SpatioTemporal Asset Catalog (STAC) est devenue le schéma standard pour les catalogues d'imagerie de défense et commerciaux, car elle définit une structure JSON commune pour les métadonnées de scène (géométrie d'empreinte, date et heure d'acquisition, identifiants de capteur et de plateforme, descriptions de bandes, liens d'actifs) lisible par un écosystème croissant de clients de catalogue, d'API de recherche et d'outils de visualisation sans travail d'intégration personnalisé.

Sous l'API STAC, une base de données PostgreSQL adossée à PostGIS stocke les enregistrements Item et leurs géométries d'empreinte GeoJSON. Les requêtes spatiales (« toutes les scènes intersectant ce polygone, collectées dans les 14 derniers jours, avec moins de 15 % de couverture nuageuse, à une résolution de 0,5 m ou mieux ») s'exécutent comme des requêtes d'intersection spatiale PostGIS avec des index composites sur la colonne de géométrie d'empreinte, la colonne de date et d'heure d'acquisition et les champs numériques de couverture nuageuse et de résolution. Pour un catalogue contenant 10 millions d'enregistrements de scènes, cette structure de requête renvoie les résultats en moins de 500 ms si les index sont maintenus et les plans de requête optimisés. L'étape d'indexation du pipeline insère chaque nouvel enregistrement STAC Item immédiatement après l'écriture du NITF et la validation de ses métadonnées, de sorte que la scène est interrogeable en quelques secondes après l'achèvement du traitement.

L'indexation temporelle importe autant que l'indexation spatiale pour les workflows de détection de changement. Les analystes et les services automatisés interrogent fréquemment « toutes les collectes antérieures de cette AOI » pour établir une imagerie de référence pour la détection de changement ou l'analyse de schémas d'activité. Un index sur la colonne de date et d'heure d'acquisition avec une structure B-tree prend en charge efficacement les requêtes de plage (toutes les collectes entre la date A et la date B), mais le schéma d'accès temporel le plus utile (« toutes les scènes intersectant l'empreinte X, ordonnées par date d'acquisition ») nécessite une requête spatio-temporelle conjointe qui bénéficie d'un index couvrant combinant les colonnes de géométrie et de date-heure. Les mêmes principes d'indexation spatiale utilisés dans les pipelines de normalisation des données de capteurs s'appliquent ici : le schéma doit être conçu pour les schémas de requête que les outils d'exploitation émettent réellement, et non pour la seule normalisation du schéma.

Routage vers l'exploitation : mise en file de l'imagerie vers les outils analytiques appropriés et les postes de travail des analystes

Une scène nouvellement cataloguée est candidate à une livraison vers plusieurs consommateurs en aval simultanément : un service automatisé de détection de changement, un modèle de détection d'objets basé sur l'IA, un analyste d'imagerie humain et un système de génération de rapports. Le moteur de routage est le composant qui confronte chaque nouvelle scène aux besoins enregistrés et détermine quels consommateurs la reçoivent, dans quel ordre de priorité et via quel mécanisme de livraison. Le modèle de routage utilisé dans la plupart des systèmes d'imagerie de défense repose sur des abonnements de zone d'intérêt nommée (NAI) combinés à des besoins permanents (STANREQ) qui spécifient des critères de filtrage (résolution minimale, couverture nuageuse maximale, fenêtre de date de collecte, type de capteur) et un système de destination ou une file d'analyste.

Lorsque l'étape d'indexation écrit un nouvel STAC Item, le moteur de routage l'évalue par rapport à tous les abonnements actifs. Les abonnements sont implémentés comme des requêtes spatiales sur la bibliothèque de polygones NAI : si l'empreinte de la scène intersecte une NAI enregistrée, le moteur applique les critères de filtrage de l'abonnement. Une scène qui satisfait tous les critères génère une notification de livraison vers le système de destination désigné. Pour les services d'exploitation IA, la notification transporte l'URI de stockage NITF de la scène et est publiée vers une file de travail (RabbitMQ, AWS SQS ou un courtier de messages équivalent) consommée par les processus travailleurs du service. Pour les postes de travail des analystes, la notification met à jour la file de tâches de l'analyste dans le système d'exploitation d'imagerie (SOCET GXP, RemoteView ou FADE/MIST) avec un nouvel enregistrement de tâche pointant vers la scène. Pour les besoins de renseignement à délai critique, le moteur de routage applique un rehaussement de priorité qui prend le pas sur les éléments de moindre priorité déjà présents dans la file d'exploitation.

Le routage inter-classification exige un soin particulier. Une scène collectée à un niveau de classification supérieur à l'accréditation de base de l'analyste ne peut pas être routée vers sa file de poste de travail standard ; elle doit être routée vers un poste de travail dans l'enclave correctement accréditée. Le moteur de routage doit interroger l'habilitation et l'enregistrement d'accréditation de l'analyste dans le système de gestion des identités avant d'expédier toute notification de livraison. Les services IA automatisés qui traitent l'imagerie à plusieurs niveaux de classification doivent être accrédités au plus haut niveau de données qu'ils traitent, et leurs produits de sortie doivent porter les marquages de classification source de l'imagerie qu'ils ont consommée. Les concepteurs de pipelines qui reportent ces contrôles « à plus tard » découvrent invariablement que rétro-adapter un routage tenant compte de la classification dans une architecture existante de transmission de messages est plus coûteux et plus perturbateur que de l'intégrer dès le départ.

Performance du pipeline : débit, latence et exigences de stockage à l'échelle opérationnelle

Un pipeline d'imagerie de défense de taille moyenne soutenant un seul théâtre d'opérations traite généralement 50 à 150 scènes satellitaires par jour provenant de multiples sources commerciales et gouvernementales. À une résolution de 0,5 m, une fauchée de collecte commerciale standard couvre 15 à 30 km de large et 100 à 200 km de long, produisant des scènes orthorectifiées de 1 à 4 Go chacune en GeoTIFF et de 2 à 8 Go en NITF non compressé. Le volume d'ingestion quotidien à cette échelle se situe entre 150 et 600 Go de nouvelles données de scènes, plus les intermédiaires de prétraitement qui peuvent doubler ou tripler le besoin de stockage de travail pendant le traitement actif. Un pic de couverture théâtre complet en haute résolution (couverture exhaustive sur une vaste zone disputée) peut porter les volumes d'ingestion quotidiens à plusieurs téraoctets, nécessitant des clusters de prétraitement qui passent à l'échelle horizontalement pour respecter les SLA de latence.

La latence de traitement est la contrainte de performance qui affecte le plus directement l'utilité opérationnelle. Pour les workflows TSI, la cible est inférieure à 30 minutes entre la livraison de la scène et sa disponibilité au catalogue ; pour la production de routine, moins de 4 heures est acceptable. L'étape d'orthorectification est l'étape la plus intensive en calcul : une scène panchromatique de 0,3 m à pleine résolution avec affinage des RPC et projection sur MNE prend 5 à 20 minutes sur un seul nœud de calcul moderne. La parallélisation sur les tuiles de scène et l'exécution simultanée de plusieurs scènes sur un cluster de 8 à 16 nœuds atteint les cibles de latence TSI pour des volumes de scènes typiques. La correction atmosphérique est plus légère en calcul (1 à 3 minutes par scène) mais nécessite l'accès à des données de paramètres atmosphériques coïncidentes provenant de l'analyse de modèle NWP ou de produits d'aérosols dérivés par satellite, ce qui introduit une dépendance de données pouvant retarder le traitement si le pipeline de données auxiliaires n'est pas pré-alimenté.

L'architecture de stockage suit un modèle d'accès hiérarchisé aligné sur les schémas d'exploitation. Le stockage de travail actif (bloc adossé à NVMe ou stockage objet haute performance) contient les 30 à 60 derniers jours de scènes orthorectifiées à pleine résolution, prenant en charge des requêtes de catalogue en moins d'une seconde et une récupération rapide des scènes pour l'exploitation active. Le palier d'archive active de 6 à 18 mois utilise le stockage objet (compatible S3) avec une latence de récupération de quelques secondes à quelques minutes, adéquate pour l'analyse historique et les références de détection de changement. La rétention à long terme au-delà de 18 mois passe vers le stockage objet froid ou la bande, avec une latence de récupération de plusieurs heures, acceptable pour les obligations d'archivage historique mais pas pour l'exploitation active. La base de données du catalogue STAC contient toujours les métadonnées complètes pour tous les paliers ; l'URI de stockage dans chaque enregistrement de catalogue pointe vers le palier approprié, et la couche de récupération gère un accès transparent au palier afin que les outils d'exploitation n'aient pas besoin de savoir dans quel palier de stockage réside une scène demandée.