L'IA sur des données souveraines

ODP 1.3.2.0 — Pas encore disponible

Cette fonctionnalité fait partie de la prochaine version ODP 1.3.2.0, actuellement en phase de qualification. La documentation est fournie à titre d'aperçu. Ne pas utiliser en production avant la sortie officielle.

Le problème avec l'IA cloud

Le développement moderne de l'IA a largement convergé vers un modèle centré sur le cloud : vous envoyez vos données vers l'infrastructure d'un fournisseur cloud, utilisez leurs APIs d'entraînement ou services de fine-tuning de modèles fondationnels, et récupérez le modèle résultant. Ce modèle est opérationnellement pratique, mais il a une implication fondamentale : vos données quittent votre infrastructure.

Pour de nombreuses organisations, c'est un risque inacceptable :

• Santé : les données des patients sont soumises à des exigences strictes de résidence des données. Envoyer des dossiers cliniques ou des imageries médicales vers un service IA cloud peut violer le RGPD, l'HDS (France) ou les règles de gouvernance des données du NHS (Royaume-Uni), indépendamment des accords contractuels.
• Finance : les stratégies de trading, les profils financiers des clients et les modèles de risque sont commercialement sensibles. Les exposer à une infrastructure cloud crée un risque à la fois réglementaire et concurrentiel.
• Secteur public et défense : les données de sécurité nationale, les cartographies d'infrastructures publiques et les données administratives sensibles ne peuvent pas être traitées sur une infrastructure hors contrôle national.
• Juridique : le secret professionnel, les documents sous scellés et les données de stratégie contentieuse ont des exigences strictes de confidentialité qu'une infrastructure cloud ne peut garantir.

La réponse à ce défi n'est pas d'éviter l'IA — c'est d'exécuter les charges de travail IA sur une infrastructure souveraine, où vous contrôlez le matériel, le réseau et les données.

Comment ODP résout le problème

ODP est conçu pour fonctionner entièrement sur site ou dans un cloud privé souverain. Il ne nécessite aucune connexion à des services externes lors de l'exécution. Vos données circulent :

Vos sources de données → NiFi (ingestion) → HDFS/Ozone (stockage)
                                                    ↓
                                  Spark (traitement & entraînement ML)
                                                    ↓
                                  HDFS (stockage des artefacts de modèles)
                                                    ↓
                                  Votre infrastructure d'inférence

Chaque étape de ce pipeline s'exécute sur votre matériel, dans votre réseau, sous votre contrôle.

Compatibilité SecNumCloud

L'architecture d'ODP est compatible avec SecNumCloud — la qualification de sécurité de l'ANSSI française pour les services cloud, requise pour traiter des données gouvernementales sensibles et réglementées. SecNumCloud exige, entre autres :

• Les données doivent rester sur le territoire français
• Le fournisseur cloud doit être juridiquement et opérationnellement indépendant des juridictions hors UE
• L'infrastructure doit répondre à des exigences de sécurité strictes (chiffrement au repos et en transit, contrôle d'accès, journaux d'audit, gestion des vulnérabilités)

ODP fonctionnant sur un cloud privé qualifié SecNumCloud ou sur une infrastructure sur site satisfait à ces exigences. ODP lui-même fournit les couches de chiffrement (chiffrement transparent HDFS avec KMS, TLS pour toutes les communications), de contrôle d'accès (Ranger + Kerberos) et de journalisation d'audit (audit Ranger).

Conformité RGPD pour l'IA

Le RGPD crée des défis spécifiques pour les systèmes d'IA :

Droit à l'effacement (Art. 17) : une personne concernée demande la suppression de ses données personnelles. Pour un lac de données conventionnel, cela signifie trouver et supprimer des enregistrements. Pour un modèle ML, la question est plus difficile : si l'enregistrement supprimé faisait partie du jeu d'entraînement, le modèle s'en « souvient »-il ? C'est le problème du droit à l'oubli dans l'IA.

ODP aide à résoudre ce problème au niveau des données :

• Capacité de suppression RGPD d'Iceberg : utilisez des instructions DELETE sur les tables Iceberg pour supprimer les enregistrements d'une personne concernée. L'audit Ranger capture l'événement de suppression.
• Suivi de version des données d'entraînement : si vous enregistrez l'ID de snapshot Iceberg utilisé pour chaque exécution d'entraînement de modèle, vous pouvez déterminer si un enregistrement spécifique faisait partie du jeu d'entraînement pour une version donnée du modèle.
• Lignage des données via Atlas : les chaînes de lignage Atlas montrent quels jeux de données ont contribué à quels jeux de données dérivés et modèles.

ODP n'effectue pas automatiquement le désapprentissage de modèles (retirer l'influence d'un point de données d'un modèle déjà entraîné). Cela reste un problème de recherche. Mais ODP garantit que vous disposez de la piste de preuves pour comprendre la provenance des données du modèle et prendre des décisions éclairées sur le retrait des modèles.

Droit à l'explication (Art. 22) : les personnes soumises à des décisions automatisées doivent pouvoir recevoir une explication. Le graphe de lignage Atlas montrant la provenance des données d'entraînement soutient l'exigence de documentation — vous pouvez montrer quelles données ont été utilisées pour entraîner le modèle prenant une décision.

Gouvernance des données d'entraînement IA avec Ranger

Apache Ranger fournit un contrôle d'accès fin pour toutes les données stockées dans ODP. Pour les données d'entraînement IA, Ranger permet :

Contrôle d'accès au niveau du jeu de données

Accordez à des utilisateurs ou comptes de service spécifiques (jobs d'entraînement ML) un accès en lecture aux jeux de données d'entraînement, tout en bloquant l'accès aux données brutes contenant des informations personnelles sensibles :

Politique : "Entraînement ML - Caractéristiques clients"
Ressource : hive / ml_datasets / customer_features (table)
Autoriser : GROUPE ml-engineers (SELECT)
Autoriser : UTILISATEUR spark-ml-svc (SELECT)
Refuser : * (par défaut)

La table customers brute — avec les champs PII comme nom, email et numéro de téléphone — reste inaccessible au job d'entraînement, qui ne lit que la table de caractéristiques prétraitée.

Masquage au niveau des colonnes pour les données d'entraînement

Lorsque les données d'entraînement doivent conserver une certaine structure mais ne peuvent pas exposer des colonnes spécifiques, utilisez les politiques de masquage de colonnes de Ranger :

Politique : "Données ML - Masquer PII dans les données d'entraînement"
Ressource : hive / ml_datasets / raw_customer_data / colonnes : [email, phone, ssn]
Masquage : HASH (appliquer un hachage SHA-256)
Appliquer à : GROUPE data-scientists

Les data scientists peuvent travailler avec les données pour l'ingénierie des caractéristiques, mais ne peuvent pas lire les valeurs PII brutes. Les valeurs hachées conservent toujours des informations relationnelles (même email → même hachage) utiles pour joindre des jeux de données.

Politiques basées sur les tags pour les données d'entraînement sensibles

L'approche la plus puissante consiste à utiliser les tags Atlas + les politiques basées sur les tags Ranger. Appliquez un tag SENSITIVE_TRAINING_DATA dans Atlas à toute table ou colonne contenant des données qui ne devraient être accessibles qu'aux jobs d'entraînement ML approuvés :

1. Dans Atlas, taguez la table raw_patient_records avec RESTRICTED_AI_TRAINING.
2. Dans Ranger, créez une politique basée sur les tags :
   • Tag : RESTRICTED_AI_TRAINING
   • Autoriser : SERVICE ml-training-approved-jobs
   • Refuser : tous les autres
3. La politique s'applique automatiquement à toute table ou colonne taguée RESTRICTED_AI_TRAINING, quelle que soit la base de données ou table dans laquelle elle se trouve.

Au fur et à mesure que votre patrimoine de données s'agrandit, les nouvelles tables sont automatiquement gouvernées par cette politique lorsque le tag est appliqué — aucune mise à jour manuelle des politiques Ranger n'est requise.

Lignage Atlas pour la provenance des données d'entraînement

Apache Atlas enregistre le lignage des transformations de données à travers la pile ODP. Pour les workflows IA, cela crée une chaîne de provenance des données brutes au modèle entraîné.

Ce qu'Atlas capture automatiquement

Avec l'intégration Atlas d'ODP, le lignage suivant est capturé automatiquement :

• Requêtes Hive : opérations CREATE TABLE ... AS SELECT (CTAS), INSERT INTO, INSERT OVERWRITE — Atlas enregistre quelles tables sources ont contribué à quelle table cible.
• Spark SQL : les jobs Spark utilisant le Hive Metastore créent un lignage Atlas pour les opérations SQL.
• Opérations Iceberg : la création de tables Iceberg et la manipulation de données via Hive et Spark sont capturées par le hook Atlas.

Chaîne de lignage pour un jeu de données ML typique

[NiFi : ingestion de données brutes]
        ↓ (hook NiFi Atlas)
[HDFS : raw_data/customers_raw.parquet]  (entité Atlas : hdfs_path)
        ↓ (Hive CTAS, capturé par le hook Hive Atlas)
[Hive : raw.customers]  (entité Atlas : hive_table)
        ↓ (Spark SQL, capturé par le hook Spark Atlas)
[Hive/Iceberg : ml_datasets.customer_features]  (entité Atlas : hive_table)
        ↓ (enregistré manuellement ou via une entité Atlas personnalisée)
[Modèle : churn-rf-pipeline-v2]  (entité Atlas : ml_model — type personnalisé)

Les trois étapes intermédiaires sont capturées automatiquement. La dernière étape (lier le modèle au jeu de données d'entraînement) nécessite soit une création manuelle d'entité Atlas, soit une intégration avec un registre de modèles qui publie des entités Atlas.

Interrogation du lignage via l'API REST Atlas

# Trouver tous les jeux de données qui ont contribué (directement ou indirectement) à une table donnée
curl -s -u admin:admin123 \
  "https://atlas.example.com/api/atlas/v2/lineage/<table-guid>?direction=INPUT&depth=5" \
  | jq '.relations[] | {fromEntityId, toEntityId, relationshipType}'

Le paramètre de profondeur de lignage contrôle le nombre de sauts en amont à tracer. Pour les pipelines d'ingénierie de caractéristiques complexes avec de nombreuses étapes de transformation, définissez la profondeur à 10 ou plus.

Voyage dans le temps Iceberg pour la reproductibilité ML

L'un des aspects les plus difficiles du développement ML est la reproductibilité : garantir qu'un modèle peut être ré-entraîné sur exactement les mêmes données que celles utilisées initialement. Sans données versionnées, c'est impossible — les données sont mutables, et la relecture d'une table un mois plus tard donne des résultats différents.

Iceberg résout cela avec le voyage dans le temps : chaque écriture dans une table Iceberg crée un nouveau snapshot, et les anciens snapshots sont conservés (pendant une période de rétention configurable). Vous pouvez toujours lire la table telle qu'elle existait à n'importe quel moment.

Workflow d'entraînement reproductible

Étape 1 : avant l'entraînement, enregistrez l'ID de snapshot courant de chaque jeu de données d'entraînement :

snapshot_df = spark.sql("""
    SELECT snapshot_id, committed_at, operation
    FROM hive_catalog.ml_datasets."customer_features$snapshots"
    ORDER BY committed_at DESC
    LIMIT 1
""")
snapshot_id = snapshot_df.first()["snapshot_id"]
committed_at = snapshot_df.first()["committed_at"]

print(f"Entraînement sur le snapshot : {snapshot_id} (commité à {committed_at})")
# Stockez ceci dans votre système de suivi d'expériences / métadonnées du modèle

Étape 2 : entraînez le modèle.

Étape 3 : sauvegardez le modèle dans HDFS avec un fichier de métadonnées :

{
  "model_name": "customer-churn-rf",
  "model_version": "2025-10-15-001",
  "model_path": "hdfs:///models/churn-rf-20251015",
  "training_datasets": [
    {
      "table": "hive_catalog.ml_datasets.customer_features",
      "iceberg_snapshot_id": "5931985158436469021",
      "snapshot_timestamp": "2025-10-14T22:00:00Z"
    }
  ],
  "training_timestamp": "2025-10-15T08:30:00Z",
  "spark_version": "3.5.6",
  "algorithm": "RandomForestClassifier",
  "hyperparameters": {"numTrees": 100, "maxDepth": 10}
}

Étape 4 : pour ré-entraîner sur exactement les mêmes données, utilisez l'ID de snapshot stocké :

df = spark.read \
    .option("snapshot-id", "5931985158436469021") \
    .format("iceberg") \
    .load("hive_catalog.ml_datasets.customer_features")

Cela garantit que le modèle ré-entraîné voit exactement les mêmes enregistrements, même si la table a été mise à jour de nombreuses fois depuis l'entraînement original.

Politique de rétention des snapshots

Configurez la rétention des snapshots Iceberg pour équilibrer reproductibilité et coûts de stockage :

ALTER TABLE hive_catalog.ml_datasets.customer_features
SET TBLPROPERTIES (
  'history.expire.min-snapshots-to-keep' = '10',
  'history.expire.max-snapshot-age-ms' = '2592000000'  -- 30 jours
);

Pour les jeux de données utilisés dans des modèles en production, conservez les snapshots au moins aussi longtemps que le modèle est en production. Cela garantit que vous pouvez toujours reproduire les données d'entraînement si le modèle doit être audité ou ré-entraîné.

Serveur MCP Polaris : accès LLM aux métadonnées du catalogue

ODP inclut un catalogue REST Polaris (déployé sur master03:8181 dans le cluster de référence). Le serveur Model Context Protocol (MCP) construit sur Polaris permet aux LLMs et agents IA d'interroger le catalogue de données sans accéder aux données brutes.

Il s'agit d'un pattern architectural clé pour l'intégration sécurisée de l'IA avec les données ODP :

LLM / Agent IA
     ↓ (protocole MCP)
Serveur MCP Polaris
     ↓ (API catalogue REST Iceberg)
Catalogue Polaris (métadonnées uniquement)
     ↓ (requêtes de métadonnées — pas de transfert de données)
Métadonnées de tables Iceberg (schémas, partitions, statistiques)
     ↑
Données réelles (HDFS/Ozone) — NON accessibles au LLM

Un LLM peut répondre à des questions comme :

• « Quelles tables existent dans le schéma ml_datasets ? »
• « Quels sont les colonnes et types de données de customer_features ? »
• « Combien de partitions sensor_readings a-t-il ? »
• « Quand transaction_history a-t-il été mis à jour pour la dernière fois ? »

Le LLM ne voit jamais les données de ligne réelles. Les politiques Ranger sur le catalogue Polaris contrôlent quelles tables le serveur MCP peut exposer des métadonnées, garantissant que les schémas de tables sensibles sont également protégés.

Ce pattern permet la découverte de données en langage naturel — les utilisateurs peuvent demander à un LLM de les aider à trouver le bon jeu de données pour leur projet ML — sans compromettre la souveraineté des données ni les contrôles d'accès Ranger.