ODP comme fondation pour les charges de travail IA

Ce qu'ODP est et n'est pas

Soyons directs : ODP n'inclut pas de modèles d'IA, de grands modèles de langage ni de frameworks d'apprentissage automatique au-delà de Spark MLlib (traité dans la section suivante). ODP est une plateforme de données, non un moteur d'IA.

Ce qu'ODP fournit, c'est la fondation de données gouvernée dont les charges de travail IA ont besoin pour être dignes de confiance, reproductibles et conformes. La qualité, la gouvernance et l'accessibilité des données d'entraînement importent autant que l'architecture du modèle. C'est là qu'ODP intervient.

Vous apportez votre framework ML — PyTorch, TensorFlow, scikit-learn, Hugging Face ou tout autre outil. ODP garantit que les données consommées par ces frameworks sont gouvernées, auditées, versionnées et souveraines.

Ce que signifie « prêt pour l'IA » pour ODP

Une plateforme de données prête pour l'IA doit répondre de façon fiable aux questions suivantes :

• D'où proviennent ces données d'entraînement ? (lignage)
• Qui peut y accéder ? (contrôle d'accès)
• À quoi ressemblaient-elles au moment de l'entraînement d'un modèle ? (versionnement / voyage dans le temps)
• Des données sensibles se sont-elles infiltrées dans les jeux d'entraînement ? (gouvernance)
• Où les données sont-elles physiquement stockées ? (souveraineté)

ODP répond aux cinq questions à travers ses composants intégrés :

Capacité ODP	Pertinence pour l'IA
Apache Iceberg	Format de table ouvert et versionné pour les jeux de données d'entraînement ; voyage dans le temps pour la reproductibilité ML
Apache Atlas	Lignage des données pour la traçabilité des modèles ; savoir exactement quelles données ont entraîné votre modèle
Apache Ranger	Contrôle d'accès fin pour les données d'entraînement ; politiques basées sur les tags pour les colonnes sensibles
Spark MLlib	Algorithmes ML classiques s'exécutant nativement sur YARN, lisant des données Iceberg
Serveur MCP Polaris	Accès LLM aux métadonnées du catalogue sans exposer les données brutes
Déploiement sur site	Infrastructure souveraine ; les données d'entraînement ne quittent jamais votre datacenter

L'architecture lakehouse gouverné pour l'IA

ODP implémente ce que l'on appelle souvent un lakehouse gouverné : la combinaison d'un stockage de lac de données ouvert et évolutif (HDFS/Ozone + Iceberg) avec une gouvernance d'entreprise (Ranger, Atlas, Kerberos). Cette architecture est bien adaptée en tant que couche de données pour les charges de travail IA.

┌─────────────────────────────────────────────────────┐
│              Vos charges de travail IA/ML            │
│  (PyTorch, TensorFlow, scikit-learn, APIs LLM, …)   │
└───────────────────────┬─────────────────────────────┘
                        │  lit des données gouvernées
┌───────────────────────▼─────────────────────────────┐
│              Fondation de données ODP                 │
│                                                      │
│  ┌──────────┐  ┌──────────┐  ┌──────────────────┐  │
│  │ Iceberg  │  │  Atlas   │  │     Ranger       │  │
│  │ (jeux de │  │(lignage, │  │(contrôle d'accès,│  │
│  │  données │  │ catalogue)│  │ pistes d'audit)  │  │
│  │ versionnés)│ └────┬─────┘  └────────┬─────────┘  │
│  └────┬─────┘        │                  │             │
│       │              │                  │             │
│  ┌────▼──────────────▼──────────────────▼──────────┐│
│  │         HDFS / Ozone (stockage souverain)        ││
│  └─────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────┘

Comment ODP complète vos outils IA

Ingestion et préparation des données

Votre pipeline ML commence typiquement par l'ingestion de données brutes, le nettoyage et l'ingénierie des caractéristiques. ODP fournit :

• NiFi : pour l'ingestion de données depuis diverses sources (APIs, bases de données, flux IoT) avec une gouvernance intégrée
• Spark : pour la transformation des données à grande échelle et l'ingénierie des caractéristiques
• Hive / Iceberg : comme couche de stockage pour les jeux de données nettoyés et les tables de caractéristiques

Une fois les données ingérées et préparées, elles sont stockées dans des tables Iceberg — un format ouvert lisible par tout framework ML prenant en charge Parquet (ce qui est le cas de tous).

Accès aux données d'entraînement

Vos scripts d'entraînement (Python, R, Scala) lisent les données d'entraînement depuis le stockage ODP. Pour les données Iceberg :

# PySpark lisant un jeu de données d'entraînement Iceberg
from pyspark.sql import SparkSession

spark = SparkSession.builder \
    .appName("model-training") \
    .config("spark.sql.catalog.hive_catalog", "org.apache.iceberg.spark.SparkCatalog") \
    .config("spark.sql.catalog.hive_catalog.type", "hive") \
    .getOrCreate()

# Lire le jeu de données tel qu'il existait au moment de l'entraînement (voyage dans le temps)
df = spark.read \
    .option("as-of-timestamp", "2025-10-01T00:00:00Z") \
    .table("hive_catalog.ml_datasets.customer_features")

# Entraîner votre modèle
# (en utilisant PySpark MLlib, ou en convertissant en pandas/numpy pour scikit-learn, etc.)

Le contrôle d'accès Ranger s'applique au moment de la lecture : si le principal de service d'un job Spark n'a pas la permission SELECT sur la table, la lecture échoue avec une erreur d'autorisation — avant tout entraînement. Cela empêche l'utilisation accidentelle de données non autorisées.

Artefacts de modèles

ODP ne gère pas nativement les artefacts de modèles ML (fichiers de poids, modèles ONNX, etc.). Cependant, HDFS est un backend de stockage naturel pour les gros fichiers binaires, et le format Iceberg peut être étendu pour stocker des métadonnées de modèles en tant que propriétés de table. Les équipes stockent souvent les artefacts de modèles dans HDFS aux côtés de leurs données d'entraînement, avec des entités Atlas créées pour lier le modèle à son jeu de données d'entraînement.

L'IA Act européen et ODP

L'IA Act européen (en vigueur depuis août 2024) impose des exigences aux systèmes d'IA à haut risque qui concernent directement la gouvernance des données :

Exigence de l'IA Act EU	Capacité ODP
Les données d'entraînement doivent être documentées (Art. 10)	Le lignage Atlas capture l'origine des données et leurs transformations
Qualité et représentativité des données (Art. 10)	Application du schéma Iceberg, statistiques Hive, profilage Impala
L'accès aux données doit être contrôlé (Art. 10)	Les politiques Ranger gouvernent qui peut lire/écrire les jeux d'entraînement
Des pistes d'audit doivent être maintenues (Art. 9)	Journal d'audit Ranger + journal d'audit HDFS + métadonnées opérationnelles Atlas
Droit à l'explication (Art. 13)	Le lignage Atlas montre quelles données ont contribué aux entrées du modèle

ODP ne rend pas automatiquement votre système d'IA conforme à l'IA Act européen — la conformité nécessite des processus organisationnels et de la documentation. Mais ODP fournit l'infrastructure technique qui rend les preuves de conformité disponibles et les pistes d'audit lisibles par les machines.

L'avantage souverain

Pour les organisations dans la santé, la finance, le secteur public et la défense, la question ne concerne pas seulement la gouvernance — elle concerne l'emplacement physique des données.

Les services IA cloud (APIs d'entraînement, fine-tuning de modèles fondationnels, services d'embedding) nécessitent l'envoi de données vers une infrastructure externe. Pour les organisations soumises à des réglementations ou obligations contractuelles qui interdisent aux données de quitter leurs locaux ou leur juridiction, c'est un blocage absolu.

ODP résout cela en fonctionnant entièrement sur site (ou dans un cloud privé souverain). Vos données d'entraînement restent dans votre datacenter. Vos modèles sont entraînés sur votre infrastructure. Aucune donnée n'est transmise à des services externes.

Cela s'aligne avec :

• Les exigences de qualification SecNumCloud (ANSSI française)
• Les exigences de résidence des données du RGPD
• Les exigences NIS2 pour les opérateurs d'infrastructures critiques
• Les réglementations sur les données de santé (HDS en France, gouvernance des données NHS au Royaume-Uni)

La capacité à exécuter des analyses avancées et des charges de travail ML sur une infrastructure entièrement sur site et gouvernée — sans dépendre de services cloud externes — est l'avantage souverain fondamental d'ODP.

Ce qui arrive

L'équipe Clemlab travaille activement sur des fonctionnalités liées à l'IA pour les futures versions d'ODP. Bien que nous ne divulguions pas ici les délais spécifiques, les domaines en développement actif incluent une intégration plus profonde entre la pile de gouvernance d'ODP et les outils d'orchestration de workflows IA/ML.

Pour le statut actuel, suivez les notes de version ODP et le dépôt GitHub Clemlab.