Architecture data mesh pour les organisations du renseignement de défense

Les organisations du renseignement de défense accumulent des données depuis des décennies — interceptions SIGINT, produits GEOINT, rapports HUMINT, agrégats OSINT — et n'ont jamais réussi à transformer cette accumulation en quelque chose que les analystes peuvent réellement utiliser. Le problème tient rarement à la collecte. Il réside dans l'intégration. Et la cause organisationnelle du problème d'intégration est presque toujours la même : personne n'est propriétaire des données. L'équipe centrale d'ingénierie des données, propriétaire des pipelines, ne possède pas la connaissance du domaine pour les maintenir corrects. La cellule SIGINT, qui possède cette connaissance, n'a pas l'infrastructure pour publier ses données sous une forme que d'autres équipes peuvent consommer.

Le data mesh est un modèle architectural et organisationnel qui s'attaque directement à cette cause fondamentale. Développé par Zhamak Dehghani et décrit pour la première fois en 2019, il recadre le problème des données non pas comme un défi technologique mais comme un défi de propriété. La réponse n'est pas une meilleure plateforme de données centralisée — c'est un modèle fédéré dans lequel les équipes qui produisent des données sont également responsables de leur publication en tant que produit consommable.

Ce qu'est le data mesh — et ce qu'il n'est pas

Le data mesh repose sur quatre principes. Le premier est la propriété de domaine : l'équipe qui produit les données est responsable de les rendre disponibles aux consommateurs. Le deuxième est les données en tant que produit : les données sont traitées avec la même rigueur qu'un logiciel — elles ont un propriétaire, un schéma versionné, un SLA, une documentation et une interface consommateur définie. Le troisième est l'infrastructure libre-service : une équipe centrale de plateforme fournit les outils dont les équipes de domaine ont besoin pour publier et consommer des produits de données sans soumettre de tickets. Le quatrième est la gouvernance fédérée : les standards d'interopérabilité sont fixés par un organe de gouvernance inter-domaines, mais leur application est automatisée par la plateforme.

Le contraste avec un data lake est instructif. Un data lake centralise à la fois le stockage et la responsabilité. Quand le système de collecte SIGINT modifie son schéma de sortie, le pipeline de l'équipe centrale se brise, et personne ne s'en aperçoit avant que l'analyste ne signale des données obsolètes trois semaines plus tard. Dans un data mesh, l'équipe de domaine SIGINT est propriétaire du pipeline et du contrat de schéma.

Pourquoi les architectures centralisées échouent dans le renseignement de défense

Les problèmes que résout le data mesh sont aigus dans le renseignement de défense, car ces organisations présentent des caractéristiques qui rendent les architectures de données centralisées particulièrement fragiles. Premièrement, les barrières de classification. Deuxièmement, les silos organisationnels : HUMINT, SIGINT, GEOINT, OSINT — chacun avec sa propre culture. Troisièmement, la fragilité des pipelines ETL monolithiques. Quatrièmement, les litiges de propriété que le data mesh résout par une attribution explicite et contractuelle.

Propriété de domaine dans le contexte du renseignement

Dans un data mesh de défense, les domaines correspondent naturellement aux disciplines INT : HUMINT, SIGINT, GEOINT, MASINT et OSINT constituent chacun un domaine distinct. Chaque équipe de domaine est responsable des produits de données qu'elle publie dans le mesh : définition des contrats de schéma, maintenance des pipelines d'ingestion, respect des SLA (fraîcheur, disponibilité, complétude), réponse aux problèmes de qualité et gestion des versions de schéma.

Dans un environnement classifié, la propriété de domaine signifie également gérer les métadonnées de classification. L'équipe de domaine SIGINT détermine le niveau de classification de chaque produit, les mentions de diffusabilité et les règles d'héritage pour les produits dérivés.

Produits de données pour le renseignement

Le concept de produit de données est l'unité d'échange dans un data mesh. Un produit de données est découvrable, adressable, fiable (soutenu par un SLA avec monitoring), auto-descriptif et interopérable. Exemples concrets : une équipe de domaine SIGINT peut publier un produit "tableau de pistes actuel de l'adversaire" — une collection de fonctionnalités GeoJSON de pistes actives, mise à jour toutes les 15 minutes, conforme au schéma de pistes MIP4, classifié SECRET. Une cellule d'analyse ELINT peut publier une "base de données des émetteurs" mise à jour dans les quatre heures suivant une nouvelle collecte. Une cellule GEOINT peut publier une "couche d'annotation d'imagerie" — des objets de relation STIX2 mis à jour dans les huit heures suivant la livraison des images.

Gouvernance fédérée

Un conseil de gouvernance des données — avec des représentants de chaque domaine, de l'équipe plateforme et de la fonction juridique/conformité — fixe les standards de gouvernance : exigences d'interopérabilité des schémas, conventions de métadonnées de classification, exigences des métadonnées du catalogue et définitions des métriques de qualité. Dans le contexte de la défense, les marquages de classification fonctionnent comme un attribut de gouvernance de premier ordre. Chaque événement d'accès aux données doit être enregistré dans un journal d'audit immuable.

Infrastructure libre-service pour les environnements classifiés

La plateforme libre-service est ce qui distingue un data mesh d'un cadre conceptuel. Dans un environnement classifié, la plateforme doit être déployable dans des réseaux air-gap, fonctionner sans dépendances vis-à-vis des API cloud publiques et satisfaire aux exigences d'accréditation de sécurité. La pile de plateforme typique comprend : stockage objet (MinIO ou Ceph), registre de schémas, service de catalogue de données (Apache Atlas), couche de contrôle d'accès intégrée au fournisseur d'identité et service de monitoring SLA — tous installables depuis des miroirs de packages locaux.

Défis d'implémentation et chemin de migration

L'approche correcte est incrémentielle : commencer avec un domaine, construire les capacités de la plateforme en parallèle avec le premier produit de domaine, et étendre à partir de là. Le domaine GEOINT est souvent un bon point de départ. Le data lake central ne disparaît pas pendant cette migration — il devient une plateforme de transition qui rétrécit à mesure que les produits de domaine mûrissent. Une période parallèle où les deux coexistent est le chemin de migration attendu.

Pour une présentation détaillée de l'architecture de stockage sous-jacente, voir Architecture data lake pour la défense : conception et opérations. Les modèles de fusion qui consomment des produits de données entre domaines INT sont décrits dans Fusion des données militaires : architectures et méthodes. Les pipelines d'ingestion sont présentés dans Construction d'un pipeline de fusion de données de défense, partie 1 : sources et schémas.