Architecture de data lake militaire : modèles de conception pour l'analytique multidomaine classifiée

Un data lake militaire et un data lake commercial partagent la même idée de base — un stockage objet peu coûteux et évolutif comme fondation de l'analytique — mais ils divergent fortement sur chacune des contraintes qui comptent sur le plan opérationnel. L'application de la classification, l'accès tenant compte des compartiments, le fonctionnement en air-gap et les SLA de requêtes critiques pour la mission ne sont pas des fonctionnalités optionnelles pour un déploiement de défense ; ce sont des exigences structurantes qui façonnent chaque couche de l'architecture, du nommage des buckets de stockage à la configuration du moteur de requêtes. Une architecture qui les traite après coup — en ajoutant une étiquette de classification aux modèles de data lake commerciaux existants — échouera aux audits de sécurité dans le meilleur des cas et produira des violations de conformité dans le pire.

Cet article présente la conception complète d'un data lake militaire de production : la couche de stockage, le pipeline d'ingestion à partir des sources C2, ISR et logistiques, la gestion des métadonnées du catalogue de données militaires, le contrôle d'accès compartimenté et les schémas de charges de travail analytiques. Chaque section traite des décisions de conception qui distinguent un système déployable en opérations d'une architecture de référence qui paraît correcte dans un livre blanc mais qui cède au contact de données classifiées réelles.

Ce qu'un data lake militaire doit faire et qu'un data lake commercial ne fait pas — application de la classification, accès tenant compte des compartiments, fonctionnement en air-gap, SLA critiques pour la mission

La différence la plus fondamentale entre un data lake commercial et un data lake militaire n'est pas un choix technologique : c'est un modèle de menace. Un data lake commercial protège contre les attaquants externes et contre l'exfiltration de données par des initiés. Un data lake militaire doit également se prémunir contre une défaillance plus subtile : un utilisateur autorisé qui accède à des données pour lesquelles il est habilité, mais qu'il n'est pas autorisé à consulter dans le contexte courant. Un analyste des signaux titulaire d'une habilitation Très secret ne doit pas pouvoir interroger un jeu de données HUMINT compartimenté s'il ne détient pas le code de compartiment spécifique. Un officier logistique habilité au niveau Secret ne doit pas pouvoir consulter du renseignement ISR, même si celui-ci est lui aussi classifié Secret. Le niveau de classification et l'appartenance à un compartiment sont des dimensions d'accès orthogonales, et toutes deux doivent être appliquées à chaque couche du système.

Le fonctionnement en air-gap élimine toute dépendance à un service géré dans le cloud. Pas de Kafka managé, pas de catalogue hébergé dans le cloud, pas de service de gestion de clés exploité par un fournisseur. Chaque composant — stockage objet, broker de streaming, moteur de requêtes, catalogue de métadonnées, matériel de gestion de clés — doit pouvoir être déployé sur site à partir de paquets transférables vers l'environnement en air-gap via des supports approuvés. Cette contrainte écarte les architectures qui supposent des points de mise à jour accessibles depuis Internet, des serveurs de validation de licences ou des services de collecte de télémétrie. Elle implique également que l'équipe d'exploitation assume l'ensemble du cycle de mise à niveau et de correctifs de chaque composant, sans voie gérée par le fournisseur.

Les SLA critiques pour la mission portent à la fois sur la fraîcheur des données et sur la latence des requêtes. Un analyste de fusion ISR qui interroge les dernières données ingérées des capteurs ne peut pas accepter une fenêtre de traitement par lots Spark de plusieurs heures. Un officier logistique qui construit un modèle de réapprovisionnement a besoin de résultats de requêtes en quelques minutes, pas en plusieurs jours. Ces exigences imposent des choix d'architecture que les data lakes commerciaux reportent souvent : des moteurs de requêtes toujours actifs, dont les plans de requêtes ont déjà été compilés à partir de statistiques de catalogue à jour, un stockage de niveau chaud pour les données récentes et une ingestion en streaming qui rend les nouvelles données interrogeables quelques secondes après leur réception — et non à la prochaine fenêtre de traitement par lots. Pour approfondir les modèles fondamentaux utilisés dans les couches décrites ici, consultez notre guide sur les modèles d'intégration des données de défense.

Une quatrième exigence, elle aussi mal couverte par les data lakes commerciaux, est l'intégration de données multi-domaines : joindre, dans une seule requête et à travers les frontières de classification (avec les contrôles appropriés), les données de pistes C2, les données de capteurs ISR, les enregistrements logistiques et les couches de référence géospatiales. Dans un data lake commercial, les jointures inter-domaines sont une commodité d'ingénierie des données. Dans un data lake militaire, elles constituent le principal cas d'usage analytique — et elles doivent être possibles sans relâcher l'application de la classification. Le moteur de requêtes doit être capable de joindre des tables issues de différents domaines de données tout en appliquant de manière transparente, de chaque côté de la jointure, des filtres de classification propres à chaque table.

Conception de la couche de stockage — stockage objet (MinIO/Ceph sur site), stockage hiérarchisé (chaud/tiède/froid), nommage et partitionnement des objets pour les domaines de données militaires

Le stockage objet est le socle de toute architecture de data lake moderne et, pour les déploiements militaires en air-gap, le choix se resserre sur deux plateformes éprouvées en production : MinIO et Ceph. MinIO implémente l'intégralité de l'API AWS S3, avec chiffrement AES-256 au repos, politiques IAM par bucket, ainsi que versionnage et verrouillage au niveau de l'objet — le tout sans aucune dépendance au cloud. Ses performances sur du matériel NVMe moderne dépassent celles du stockage objet des clouds commerciaux pour les charges d'écriture séquentielle, qui constituent le schéma dominant de l'ingestion de données de capteurs. Ceph fournit du stockage objet, bloc et fichier à partir d'un seul cluster via sa passerelle RADOS Gateway, ce qui le rend adapté aux environnements où une même infrastructure de stockage physique doit servir à la fois la charge objet du data lake et les volumes bloc des machines virtuelles. Pour un déploiement dédié au data lake, MinIO est plus simple à exploiter ; Ceph est le bon choix lorsque le cluster de stockage doit aussi fournir des interfaces bloc et fichier.

L'isolation par classification est mise en œuvre au niveau du bucket, et non au niveau de l'objet. Chaque palier de classification dispose de son propre espace de noms de buckets :

La structure en zones — brute (raw), structurée (structured), consolidée (curated) — répartit les données par étape de traitement au sein de chaque palier de classification. La zone brute contient les données exactement telles qu'elles ont été reçues des systèmes sources, dans leur format natif (CoT XML, NIEM XML, flux binaires de capteurs, exports logistiques CSV). Rien n'est modifié dans la zone brute après l'écriture ; elle constitue un enregistrement d'audit immuable de ce qui a été reçu. La zone structurée contient les données après normalisation en Parquet avec le format de table Delta Lake — schéma imposé, champs mappés vers des noms canoniques, métadonnées de provenance ajoutées. La zone consolidée contient des agrégats prêts pour les analystes, des vues multi-domaines pré-jointes et des tables de synthèse qui permettent des requêtes interactives rapides sans obliger chaque analyste à réaliser indépendamment la même logique de jointure.

La conception des clés d'objets de la zone structurée encode toutes les dimensions de partition nécessaires à un pushdown de requêtes efficace :

Le stockage hiérarchisé est géré par les politiques de cycle de vie de MinIO. Le niveau chaud repose sur des nœuds à base de NVMe et contient les données des 30 derniers jours — suffisamment récentes pour que les analystes les interrogent fréquemment dans le cadre de l'analyse opérationnelle en cours. Après 30 jours, les objets passent au niveau tiède, sur disques rotatifs haute densité, où ils restent interrogeables mais avec une latence plus élevée. Après 180 jours, les objets passent au niveau froid, sur un stockage d'archivage haute densité dont la latence de récupération est configurable. Les seuils de chaque niveau sont configurables par domaine et par niveau de classification — les données de capteurs ISR issues de zones d'opérations actives peuvent avoir un délai de transition du niveau tiède au niveau froid plus court que les données d'archives logistiques.

Architecture du pipeline d'ingestion — flux des systèmes C2 (CoT/NIEM), ingestion des données de capteurs ISR, ETL des systèmes logistiques, modèles d'ingestion en streaming et par lots

La couche d'ingestion doit gérer simultanément trois profils de vélocité des données fondamentalement différents : des flux en streaming à haute vélocité provenant des systèmes C2 et ISR, qui produisent des milliers d'événements par minute ; des flux structurés à vélocité moyenne provenant des systèmes logistiques et de planification, qui produisent des centaines d'enregistrements par heure ; et des exports par lots à faible vélocité issus de systèmes hérités, qui livrent des extractions de fichiers quotidiennes ou hebdomadaires. Ces profils exigent des modèles d'ingestion différents, qui doivent interopérer proprement à la frontière de la zone d'atterrissage.

Apache Kafka constitue l'épine dorsale de streaming des flux temps réel. La conception des topics suit la même convention, fondée sur la classification, que le stockage — chaque topic est préfixé par son niveau de classification, et les ACL Kafka restreignent l'accès des producteurs et des consommateurs par palier de classification. La convention de nommage des topics encode le type de source et l'identité du système :

Les services adaptateurs CoT/NIEM s'abonnent aux topics C2 bruts, analysent le XML, mappent les champs vers le schéma d'ingestion canonique, joignent les métadonnées de provenance (identifiant du système source, horodatage de collecte, niveau de classification, unité d'origine) et publient vers le topic normalisé. L'analyse CoT doit traiter à la fois les champs CoT standard et les extensions de l'élément Detail utilisées par certains systèmes C2 — l'adaptateur ne doit pas abandonner silencieusement le contenu des extensions ; il doit soit mapper les extensions connues vers des champs canoniques, soit les conserver dans une colonne d'extensions structurée. Les adaptateurs NIEM traitent des schémas nettement plus complexes — la conception modulaire de NIEM implique qu'une instance d'échange NIEM peut référencer des types issus de plusieurs schémas NIEM de base et de domaine, et l'adaptateur doit résoudre toutes les références avant le mappage des champs. L'adaptateur produit une structure aplatie, à raison d'une ligne par rapport, adaptée au stockage Parquet.

L'ingestion des capteurs ISR varie selon le type de capteur. Les flux d'analyse vidéo des UAV produisent des enregistrements d'événements de détection — boîte englobante, classe de détection, score de confiance, horodatage de l'image, position du capteur — à des cadences pouvant dépasser 10 000 enregistrements par minute pour une plateforme multiflux. Ceux-ci doivent être ingérés via Kafka avec une application du schéma Avro ou Protobuf côté producteur, et pas seulement côté consommateur. Les récepteurs SIGINT produisent des enregistrements d'interception d'émetteurs avec la fréquence, la modulation, les paramètres d'impulsion, le relèvement et les données TDOA. Les flux radar produisent des rapports de pistes avec la position, la vitesse et des métriques de qualité de piste. Chaque type de capteur dispose d'un adaptateur dédié qui normalise son format natif vers le schéma canonique d'observation ISR avant que l'enregistrement n'atteigne la zone d'atterrissage. Pour un traitement approfondi de l'architecture de fusion du renseignement en temps réel, consultez notre article complémentaire sur le traitement de flux multisources.

L'ETL logistique fonctionne généralement en mode par lots — la plupart des systèmes ERP logistiques produisent des exports périodiques plutôt que des flux de changements en temps réel. Le pipeline ETL extrait les données de l'interface d'export du système source (dépôt de fichiers SFTP, requête de base de données ou extraction par API REST), valide le schéma, applique le mappage des champs vers le schéma logistique canonique et écrit des fichiers Parquet dans la zone d'atterrissage brute. Un job Spark traite ensuite les fichiers bruts vers la zone structurée selon un calendrier synchronisé avec la cadence d'export du système source. Pour les systèmes logistiques qui prennent en charge la capture des données modifiées (CDC) via le streaming du journal de la base de données, la voie en streaming est privilégiée — elle réduit de plusieurs heures à quelques minutes le délai entre un événement logistique et sa disponibilité pour les requêtes analytiques.

La validation de la qualité des données à l'ingestion n'est pas facultative — c'est le mécanisme qui empêche des données malformées d'atteindre la zone structurée et de corrompre les analyses. Chaque adaptateur d'ingestion doit effectuer au minimum : une validation de la conformité au schéma, des contrôles de complétude de la provenance, des contrôles de cohérence temporelle (horodatages des événements dans des bornes plausibles) et, pour les données géospatiales, une validation de la plage des coordonnées. Les échecs de validation sont acheminés vers une file de lettres mortes avec le corps complet du message d'origine et un enregistrement d'erreur structuré identifiant le contrôle précis qui a échoué.

Catalogue de métadonnées et découverte des données — étiquetage de la classification et des caveats dans les métadonnées, registre de schémas, suivi du lignage des données, expérience de recherche et de découverte pour les analystes

Le catalogue de métadonnées est le composant qui rend le data lake exploitable par des analystes qui ne l'ont pas construit. Sans catalogue, le data lake n'est qu'un ensemble de fichiers Parquet opaques dans le stockage objet, que seuls les ingénieurs ayant écrit les adaptateurs d'ingestion savent interroger. Avec un catalogue bien alimenté, tout analyste disposant de l'habilitation appropriée peut découvrir les jeux de données disponibles, comprendre leurs schémas et leur provenance, et construire des requêtes dessus — sans solliciter le support de l'ingénierie pour chaque nouvelle question analytique. Le guide sur la gestion des métadonnées du catalogue de données militaires décrit en détail la conception du catalogue ; cette section traite de son intégration à l'architecture du data lake.

Apache Atlas est le catalogue open source éprouvé en production pour les environnements qui exigent des types de métadonnées extensibles, un suivi du lignage et une intégration avec les outils de l'écosystème Hadoop. Le système de types d'Atlas permet de définir des types d'entités de métadonnées personnalisés comme des objets de schéma à part entière (et non comme des annotations en texte libre), ce qui est essentiel pour les champs spécifiques à la défense qui doivent être obligatoires lors de l'enregistrement d'un jeu de données :

• ClassificationLevel — type énuméré : UNCLASSIFIED, CONFIDENTIAL, SECRET, TOP_SECRET. Obligatoire sur chaque entité de jeu de données. Pilote le routage vers les buckets de stockage et l'évaluation des politiques de contrôle d'accès.
• CaveatCodes — liste de chaînes à valeurs multiples. Enregistre les caveats applicables, tels que NOFORN, les identifiants de compartiments et les instructions de manipulation. Doit être renseigné à l'ingestion ou laissé sous la forme d'une déclaration vide explicite — la valeur null n'est pas autorisée.
• DataOwnerUnit — référence de type chaîne vers l'unité organisationnelle responsable du jeu de données. Sert à l'acheminement vers les responsables des données (stewardship) et à l'identification d'un point de contact pour les demandes d'accès aux données.
• RetentionPolicy — référence à la règle de conservation applicable, qui définit la durée maximale de conservation, la procédure de suppression sécurisée et l'autorité ayant approuvé la période de conservation.
• OriginatingSystem — identifiant du système source qui a produit les données. Sert au suivi du lignage et au renvoi des problèmes de qualité des données à l'exploitant du système source.

L'intégration d'un registre de schémas avec Apache Kafka garantit que le schéma de chaque topic est enregistré et versionné avant qu'un producteur ne commence à écrire. Le Confluent Schema Registry (déployable sur site sans connectivité cloud) applique les règles de compatibilité des schémas Avro ou Protobuf — la compatibilité BACKWARD pour les topics destinés aux consommateurs signifie que les nouvelles versions de schéma peuvent ajouter des champs optionnels sans casser les consommateurs existants. Chaque version de schéma est liée depuis l'entité du catalogue Atlas correspondant au jeu de données, ce qui fournit un historique complet de l'évolution de la structure du jeu de données au fil du temps.

Le suivi du lignage des données dans Atlas capture la chaîne de transformation depuis l'ingestion brute jusqu'à la table analytique consolidée. Le hook Atlas de Spark émet automatiquement des événements de lignage lorsqu'un job Spark lit un jeu de données enregistré dans Atlas et écrit dans un autre. L'intégration d'Atlas dans Trino nécessite un écouteur d'événements personnalisé qui enregistre les tables sources consultées pour produire un résultat de requête. Le graphe de lignage qu'Atlas construit à partir de ces événements permet à un analyste de remonter de n'importe quelle valeur d'une table analytique consolidée, en traversant chaque étape de transformation, jusqu'à l'enregistrement brut d'origine dans la zone d'atterrissage, puis plus loin encore jusqu'au système source et à l'événement de collecte à l'origine. Cette chaîne est importante sur le plan opérationnel — les analystes ont fréquemment besoin de déterminer si un résultat analytique donné est traçable jusqu'à une source fiable — et constitue une exigence de conformité pour les données classifiées.

La recherche et la découverte destinées aux analystes exigent que le catalogue puisse être interrogé selon les attributs que les analystes utilisent réellement : domaine de données (C2, ISR, logistique, géospatial), période couverte, niveau de classification et caveats (filtrés selon ce que l'utilisateur est autorisé à voir), ainsi qu'une recherche par mots-clés dans les descriptions des jeux de données et les noms de colonnes. L'API de recherche d'Atlas prend en charge toutes ces dimensions, mais la couche de contrôle d'accès doit garantir que les résultats de recherche du catalogue sont eux-mêmes filtrés selon l'habilitation et les appartenances aux compartiments de l'utilisateur — un analyste ne doit pas pouvoir découvrir l'existence d'un jeu de données compartimenté auquel il n'est pas autorisé à accéder, même si l'entrée du catalogue n'expose pas le contenu du jeu de données.

Contrôle d'accès compartimenté — contrôle d'accès basé sur les attributs (ABAC) pour l'application des compartiments, sécurité au niveau des lignes et des colonnes dans les moteurs de requêtes, journalisation d'audit

Le contrôle d'accès dans un data lake militaire n'est pas une politique unique : c'est une pile d'application en couches, où chaque couche rattrape ce que la couche supérieure pourrait laisser passer. Ces couches sont : les politiques de buckets au niveau du stockage (qui peut lire et écrire dans quels buckets), les politiques de visibilité au niveau du catalogue (qui peut découvrir quels jeux de données), la sécurité des lignes et des colonnes au niveau du moteur de requêtes (quelles lignes et quelles colonnes un utilisateur peut voir dans un jeu de données auquel il est autorisé à accéder) et la journalisation d'audit (ce qui a été consulté, par qui, quand, et ce qui a été retourné). Les quatre couches doivent être actives simultanément — une couche isolée n'offre qu'une protection partielle.

Le contrôle d'accès basé sur les attributs (ABAC) est le bon modèle pour les dimensions de classification et de compartiment, car l'explosion du nombre de rôles rend le RBAC ingérable à grande échelle. Une politique ABAC évalue l'accès en calculant une fonction de politique sur les attributs de l'utilisateur et les attributs de la ressource :

OPA est déployé en sidecar du coordinateur Trino. Lorsqu'un analyste soumet une requête SQL, le plugin de contrôle d'accès de Trino appelle OPA pour chaque référence de table de la requête, en lui transmettant les attributs d'identité de l'utilisateur authentifié (issus du fournisseur d'identité) et les attributs de ressource de la table (issus du catalogue). OPA renvoie une décision d'autorisation ou de refus et, pour les tables autorisées, renvoie le prédicat de filtrage de lignes et les définitions de masquage de colonnes à appliquer à cette table dans la session de cet utilisateur. Trino injecte de manière transparente les filtres de lignes et les masques de colonnes — la requête de l'analyste s'exécute telle qu'écrite, mais le jeu de résultats ne contient que les lignes et les colonnes que l'analyste est autorisé à voir.

La sécurité au niveau des lignes dans Trino ajoute un prédicat à la clause WHERE de chaque requête portant sur une table protégée. Pour une table contenant des enregistrements de plusieurs niveaux de classification, le filtre de lignes restreint la requête aux lignes dont le niveau de classification se situe dans la plage autorisée de l'utilisateur. Le masquage au niveau des colonnes remplace les valeurs de colonne par NULL ou par un littéral de chaîne pour les colonnes que l'utilisateur n'est pas autorisé à voir en intégralité — par exemple, un champ contenant un identifiant de compartiment peut être visible pour les utilisateurs disposant de l'autorisation de compartiment appropriée et masqué par NULL pour ceux qui ne l'ont pas.

La journalisation d'audit doit capturer chaque événement de requête avec un niveau de détail suffisant pour reconstituer ce que l'utilisateur a vu. Les champs minimaux d'un enregistrement d'audit sont : l'identité de l'utilisateur authentifié (pas seulement le nom d'utilisateur — l'ensemble des attributs du fournisseur d'identité), l'horodatage de soumission de la requête, le texte de la requête, la liste des tables consultées avec leurs niveaux de classification, le nombre de lignes retournées par table, les éventuelles politiques de filtrage de lignes ou de masquage de colonnes appliquées, et le statut d'achèvement de la requête. Les enregistrements d'audit doivent être écrits sur un stockage objet en ajout seul avec verrouillage d'objet activé, ce qui empêche leur modification ou leur suppression, y compris par les administrateurs du stockage. Le magasin des journaux d'audit doit se situer au plus haut niveau de classification pouvant apparaître dans une requête, afin que les enregistrements d'audit ne constituent pas eux-mêmes un canal de données entre niveaux de classification.

Schémas de charges de travail de requêtes et d'analytique — Trino/Presto pour le SQL ad hoc sur le stockage objet, Spark pour l'analytique par lots, environnements de notebooks pour les analystes

Un data lake militaire répond à deux profils de charges de requêtes distincts, qui exigent des moteurs d'exécution différents, optimisés pour des fonctions de coût différentes. Les requêtes ad hoc des analystes privilégient une faible latence — un analyste qui prépare une évaluation de ciblage a besoin d'une réponse en quelques secondes à quelques minutes, pas en plusieurs heures. Les jobs d'analytique par lots privilégient le débit — un pipeline d'ingénierie des données qui traite l'intégralité du corpus historique d'enregistrements de capteurs pour l'analyse des schémas de vie (pattern-of-life) peut accepter des durées d'exécution plus longues s'il produit des résultats précis et exhaustifs. Déployer à la fois Trino et Spark sur le même stockage objet permet de répondre aux deux profils sans compromis.

Trino est le moteur de requêtes ad hoc de référence pour l'analytique SQL sur data lake. Il lit les fichiers Parquet et Delta Lake directement depuis le stockage objet via son connecteur Hive — sans étape de chargement des données, sans ETL vers une base de données distincte. Le moteur d'exécution de requêtes distribué de Trino découpe la requête en fragments exécutés en parallèle sur les nœuds workers, les résultats intermédiaires étant échangés sur le réseau. Pour les requêtes typiques des analystes — filtrer les enregistrements récents de capteurs, joindre des pistes C2 à des couches de référence géospatiales, agréger la consommation logistique par unité et par période — Trino fournit des résultats en quelques secondes à quelques minutes sur des jeux de données couvrant des centaines de gigaoctets de fichiers Parquet. Les principaux paramètres de réglage pour un déploiement de data lake militaire sont : la configuration de l'élagage des partitions (Trino doit pousser les prédicats de la clause WHERE sur les colonnes de partition jusqu'au listage du stockage objet, afin d'éviter les analyses complètes des buckets), la fréquence de collecte des statistiques (l'optimiseur fondé sur les coûts de Trino a besoin de statistiques de table exactes pour produire des plans de jointure efficaces) et les limites de mémoire des workers (les requêtes à grosses jointures peuvent dépasser la mémoire par worker ; configurer le spill-to-disk évite les erreurs de mémoire insuffisante, au prix d'une latence de requête accrue).

Apache Spark est le moteur d'analytique par lots pour les charges qui exigent un traitement de l'intégralité du corpus ou des calculs itératifs complexes. L'intégration de Delta Lake dans Spark offre une sémantique d'écriture ACID — les jobs par lots peuvent écrire dans des tables Delta Lake avec des garanties de traitement « exactly-once », et les lecteurs Spark et Trino concurrents voient à tout moment un instantané cohérent de la table grâce au protocole MVCC de Delta Lake. Les charges Spark courantes dans un data lake militaire comprennent :

• Jobs ETL nocturnes qui traitent les fichiers de la zone d'atterrissage brute des 24 heures précédentes vers la zone structurée — analyse, validation, normalisation et écriture de Parquet avec les métadonnées de partition
• Analyse des schémas de vie sur des semaines ou des mois de données historiques de pistes — identification des modèles de déplacement réguliers, des événements fréquents de colocalisation et des changements de comportement au fil du temps
• Jobs par lots de résolution d'entités qui fusionnent les enregistrements en double entre les sources pour la table maître d'entités consolidée
• Pipelines de préparation des données d'entraînement pour les modèles d'apprentissage automatique (ML) — extraction de caractéristiques à partir des données brutes de capteurs, jointure des étiquettes, export du jeu de données au format attendu par le framework d'entraînement
• Balayages de qualité des données qui exécutent un profilage statistique sur l'ensemble de la zone structurée afin de détecter la dérive de schéma, les anomalies de distribution des valeurs et les lacunes dans les métadonnées de provenance

JupyterHub fournit l'environnement de notebooks destiné aux analystes. Les notebooks se connectent à Trino pour les requêtes SQL et à Spark pour la manipulation programmatique des données, en combinant la flexibilité exploratoire de Python et les capacités de requêtes structurées des deux moteurs. Dans un déploiement classifié, le serveur JupyterHub doit être isolé dans le segment réseau correspondant au niveau de classification approprié — chaque palier de classification exige sa propre instance JupyterHub connectée aux clusters Trino et Spark de ce palier. Les notebooks créés par les analystes doivent être stockés dans la zone consolidée du data lake (et non sur le disque local du serveur JupyterHub), afin d'être soumis aux mêmes politiques de conservation et d'audit que les autres contenus du data lake. Des modèles de notebooks préconçus pour les schémas courants de jointure multi-domaines — piste C2 jointe aux détections de capteurs ISR, consommation logistique jointe aux rapports opérationnels — réduisent le temps qu'un analyste doit consacrer à la construction de requêtes standardisées avant d'en arriver à sa question analytique.

Qualité et gouvernance des données — contrôles de qualité des données à l'ingestion, gestion des données maîtres pour les références d'entités, politiques de conservation et d'élimination des données classifiées

La gouvernance des données dans un data lake militaire n'est pas un exercice de documentation : c'est une discipline opérationnelle qui détermine si l'on peut se fier, pour la prise de décision, aux analyses produites par le data lake. Un analyste qui découvre qu'une évaluation de ciblage reposait sur des données ayant échoué à leurs contrôles de qualité mais autorisées à se propager vers la zone consolidée a perdu confiance dans l'ensemble de la plateforme d'analytique. Les mécanismes de gouvernance doivent être appliqués automatiquement, sans dépendre de la connaissance qu'ont les analystes de l'état de qualité des données.

Les contrôles de qualité des données à l'ingestion (décrits dans la section sur le pipeline d'ingestion) constituent la première barrière de gouvernance. La seconde est un balayage quotidien de la qualité des données sur l'ensemble de la zone structurée avec Apache Spark. Ce balayage exécute un ensemble configurable de contrôles sur chaque jeu de données enregistré :

• Contrôles de complétude — pourcentage de valeurs non nulles pour les champs obligatoires ; tout jeu de données dont un champ obligatoire tombe sous 95 % de complétude déclenche une alerte auprès du responsable des données (data steward)
• Contrôles de distribution des valeurs — le profilage statistique des colonnes numériques détecte les changements brusques de distribution pouvant indiquer un défaut d'étalonnage des capteurs, un changement de système de coordonnées ou des bogues ETL
• Contrôles d'intégrité référentielle — les relations de clés étrangères entre jeux de données (par exemple, les identifiants d'entités de pistes référencés dans les enregistrements de capteurs doivent exister dans la table maître des entités C2) sont validées chaque jour afin de détecter les références orphelines produites par des problèmes de séquencement de l'ingestion
• Contrôles de fraîcheur — chaque jeu de données a une latence d'ingestion maximale attendue ; les jeux de données qui n'ont pas reçu de nouveaux enregistrements dans cette fenêtre déclenchent une alerte pouvant indiquer une défaillance du système source ou une partition réseau

La gestion des données maîtres (MDM) pour les références d'entités est le mécanisme de gouvernance qui empêche la prolifération d'identifiants d'entités incohérents entre les domaines de données. Dans un contexte militaire, les principales entités qui nécessitent une MDM sont : les unités et formations (avec leurs relations hiérarchiques et leur articulation opérationnelle actuelle), les équipements (avec modèle, variante et unité d'affectation), les éléments géographiques et installations (avec leurs noms classifiés et non classifiés) et le personnel (avec les dossiers d'habilitation et d'affectation). Chacun de ces types d'entités exige un enregistrement de référence (golden record) dans la table maître des entités, qui sert de référence faisant autorité pour les jointures entre domaines de données. Sans table maître des entités tenue à jour, les analystes qui joignent des enregistrements de capteurs ISR à des enregistrements d'unités C2 obtiendront des échecs de jointure ou des résultats incorrects chaque fois que la même unité est identifiée par des identifiants différents dans différents systèmes sources — un problème courant dans les environnements de données militaires multisources.

La conservation et l'élimination des données classifiées reposent sur l'effacement cryptographique comme mécanisme standard. La clé de chiffrement des données (DEK) de chaque palier de classification est stockée dans un module de sécurité matériel (HSM). Lorsqu'une politique de conservation déclenche l'élimination d'un jeu de données, le HSM détruit la DEK des objets concernés au lieu d'écraser objet par objet des données chiffrées pouvant représenter des pétaoctets. Après la destruction de la DEK, les objets chiffrés sont irrécupérables sur le plan calculatoire — l'exigence de suppression sécurisée est satisfaite sans la charge opérationnelle de procédures d'écrasement multi-passes à l'échelle du pétaoctet. Le service de purge qui exécute la destruction des DEK doit consigner chaque événement de purge dans une piste d'audit immuable qui enregistre :

• L'identifiant du jeu de données et le préfixe de chemin d'objet concernés
• Le nombre d'objets dont la clé de chiffrement a été détruite
• La règle de la politique de conservation qui a déclenché l'élimination (par identifiant et version de la règle)
• L'identité du service automatisé ou du principal humain ayant autorisé l'élimination
• Une empreinte cryptographique de la DEK au moment de sa destruction (prouvant que la clé existait avant sa destruction sans conserver la clé elle-même)
• L'horodatage de la destruction de la DEK et l'enregistrement d'attestation du HSM confirmant l'événement de destruction

Le cadre de gouvernance n'est efficace que si ses résultats sont visibles pour les personnes responsables de la qualité des données. Un tableau de bord de gouvernance quotidien — construit à partir des résultats du balayage de qualité des données, des métriques de complétude de l'enregistrement dans le catalogue, de l'état de conformité aux politiques de conservation et des synthèses des journaux d'audit — donne aux data stewards la visibilité nécessaire pour repérer et traiter les problèmes avant qu'ils ne se propagent aux jeux de données consolidés destinés aux analystes. Le tableau de bord lui-même doit être déployé dans le segment réseau correspondant au niveau de classification approprié, et ses données doivent provenir exclusivement de ce segment — un tableau de bord de gouvernance pour des données classifiées Secret ne doit pas tirer ses métriques d'une infrastructure de supervision non classifiée. Traiter la gouvernance comme une préoccupation de second rang pouvant partager l'infrastructure avec des services de classification inférieure est une erreur d'architecture fréquente, qui crée à la fois une exposition en matière de conformité et un angle mort opérationnel sur la qualité des données du contenu le plus sensible du data lake.