Un modèle incriminé lors d'un contrôle AI Act doit pouvoir être rejoué à l'identique, données comprises. Comparatif méthodique de DVC, LakeFS et Delta Lake, avec coûts de stockage réels, pour construire une chaîne de preuve exploitable en cas d'audit ou d'incident.
Une équipe data qui ne sait pas reconstituer exactement le jeu de données ayant servi à entraîner un modèle en production s'expose à deux risques distincts : l'incapacité technique à diagnostiquer une dérive de performance, et l'incapacité réglementaire à répondre à un contrôle. Le second risque s'est considérablement renforcé depuis l'entrée en application progressive de l'AI Act. Pour les systèmes à haut risque, les exigences sur la qualité des données imposent que les données d'entraînement soient pertinentes, représentatives et auditées pour les biais, et l'article 10 impose des données d'entraînement pertinentes, représentatives, documentées et contrôlées pour les biais ; sans catalogue, lineage et responsables de données nommés, une IA à haut risque ne peut pas démontrer sa conformité.
La documentation technique exigée par l'article 11 et l'annexe IV n'est pas un livrable ponctuel. Il faut tenir à jour un dossier décrivant le fonctionnement du système, les données d'entraînement, les mesures de performance et les limites connues, et cette obligation est continue : traiter la conformité comme un projet ponctuel est une erreur fréquente, la documentation, la traçabilité et la surveillance humaine sont des obligations continues. Concrètement, cela signifie que chaque réentraînement, chaque correction de dataset, chaque filtrage doit laisser une trace exploitable des mois ou des années plus tard. C'est exactement le problème que le data versioning est censé résoudre — à condition de choisir le bon outil pour le bon niveau de granularité.
Le marché a connu une consolidation majeure fin 2025. lakeFS a acquis DVC en novembre 2025, fusionnant les deux outils de versioning de données les plus utilisés en un produit unifié, confirmé également par l'annonce par lakeFS de cette acquisition en novembre 2025. Les deux outils restent cependant distincts dans leur usage : ils demeurent open source, mais la gouvernance et la feuille de route sont désormais unifiées. Pour une équipe qui doit choisir aujourd'hui, la question n'est donc plus « lequel acheter » mais « à quel niveau de la pile chaque outil intervient ».
DVC étend Git pour fournir du contrôle de version sur les données et les modèles de machine learning, permettant la reproductibilité des projets ML. Son fonctionnement reste simple à adopter pour une équipe qui versionne déjà son code sur Git : DVC versionne les fichiers, en conservant des métadonnées légères dans Git et les données dans un stockage de type S3, ce qui convient aux équipes ML de petite à moyenne taille travaillant sur des fichiers. La limite technique est connue : DVC est un outil léger, compatible Git, pour versionner des fichiers et modèles individuels, nécessitant souvent de copier les données en local pour les consommer. Sur un dataset de quelques centaines de gigaoctets réparti en quelques milliers de fichiers, c'est un non-sujet. Sur un data lake de plusieurs téraoctets partagé par dix équipes, cela devient un goulot d'étranglement opérationnel.
LakeFS fournit des opérations de type Git directement sur des data lakes à l'échelle du pétaoctet, dans un stockage objet, avec du branchement à copie zéro. Cette architecture change la donne pour l'industrialisation : le pipeline peut écrire les données modifiées dans une branche sans affecter la production ; après validation, on fusionne les changements dans la branche principale ; si quelque chose se passe mal, on revient à un état précédemment validé. Pour une équipe qui gère un pipeline de réentraînement automatisé, c'est la seule approche qui permette de tester une nouvelle version du dataset en conditions réelles sans dupliquer physiquement les données. Le framework de policies et de hooks permet d'exécuter des validations avant fusion, en plus du time travel sur les commits — un point critique pour la sécurité en production.
Delta Lake, Apache Iceberg et Apache Hudi résolvent un problème différent : Delta Lake ajoute des transactions ACID et le time travel aux data lakes construits sur Parquet ; contrairement à DVC qui versionne des fichiers et LakeFS qui versionne des chemins de stockage objet, Delta Lake versionne des tables individuelles avec une granularité au niveau ligne, ce qui le rend adapté aux scénarios où les données d'entraînement sont stockées dans un entrepôt de données et où il faut interroger des instantanés historiques précis. Les éditeurs de plateformes l'ont bien compris : Snowflake Time Travel, Databricks Unity Catalog et les tables Delta de Microsoft Fabric supportent tous nativement le time travel. Pour une équipe qui alimente ses modèles à partir de features issues d'un entrepôt Spark ou Databricks, Delta Lake est souvent déjà en place — la question devient alors de l'exploiter correctement plutôt que d'en déployer un nouveau.
L'erreur la plus fréquente consiste à chercher un outil unique pour tout versionner. En réalité, la plupart des équipes d'entreprise ont besoin de plusieurs couches en parallèle : une équipe qui fait tourner des modèles ML sur un lakehouse Databricks peut utiliser DVC pour les datasets d'entraînement, Delta Lake pour les données de pipeline, et Unity Catalog pour la gouvernance, les trois fonctionnant simultanément. Cette observation structure la méthode à mettre en place :
Cette architecture en couches n'est pas un confort technique : c'est la condition pour répondre à une demande d'audit sans reconstituer à la main, des semaines après les faits, quelle version de quelle table a nourri quel modèle. Nos équipes accompagnent ce type de mise en place dans le cadre de missions de conseil en industrialisation IA, en partant toujours de l'état existant du système d'information plutôt que d'un outil imposé a priori.
En cas de contrôle, l'enjeu n'est pas de prouver que le modèle fonctionne bien aujourd'hui, mais de reconstituer la chaîne de décision qui a conduit à sa mise en production. Le cadre réglementaire est précis sur ce que doit contenir le dossier : description du système et de ses finalités, niveau d'exactitude, robustesse et cybersécurité, données d'entraînement utilisées (caractéristiques, pas les données brutes), capacités et limitations identifiées, risques connus et mesures d'atténuation. Pour que cette documentation reste exploitable après coup, la méthode doit produire, à minima, les éléments suivants pour chaque version de modèle déployée :
Cette rigueur a un coût opérationnel que beaucoup d'équipes sous-estiment au moment du choix d'outil. En pratique, il faut s'attendre à un surcoût de stockage de 20 à 50 % pour DVC et LakeFS, et de 50 à 100 % pour Delta Lake selon la fréquence de mise à jour ; ce coût reste minime comparé aux risques réglementaires et opérationnels d'une donnée non versionnée. Ce chiffre s'explique techniquement : Delta Lake fonctionne en copy-on-write, créant de nouveaux fichiers Parquet à chaque version tout en conservant les fichiers inchangés, ce qui multiplie le volume stocké à chaque mise à jour fréquente de table, alors que DVC et LakeFS, en versionnant au niveau fichier ou objet, ne dupliquent que les fichiers réellement modifiés.
Les ordres de grandeur du stockage objet restent le point de départ de tout calcul de coût. En 2026, S3 Standard coûte 0,023 $ par Go et par mois stocké en région US East, avec un tarif qui descend légèrement au-delà de 50 To ; en Europe, la région Irlande (eu-west-1) facture environ 0,024 $ par Go, un ordre de grandeur comparable au Frankfurt relevé à 0,0245 $. Ramené à des volumes concrets : pour une organisation stockant 500 To de données, tout conserver en S3 Standard coûte 11 500 $ par mois, soit 138 000 $ par an — un chiffre qui donne la mesure de ce que représente un surcoût de versioning de 20 à 100 % selon l'outil retenu.
Pour un dataset d'entraînement de taille plus réaliste pour une PME ou un ETI — disons 2 à 5 To de données structurées et non structurées confondues — le calcul se simplifie : le stockage brut coûte entre 46 et 115 $ par mois sur S3 Standard. Un surcoût de versioning de 30 % (DVC ou LakeFS, hypothèse basse) ajoute 14 à 35 $ mensuels ; un surcoût de 75 % avec Delta Lake en cas de mises à jour fréquentes ajoute 35 à 86 $ mensuels. Ces montants restent marginaux face au coût d'un audit raté ou d'un incident de production impossible à diagnostiquer faute de traçabilité.
Le coût logiciel, lui, dépend du périmètre organisationnel. Les grilles observées sur le marché distinguent nettement les profils : pour une petite équipe travaillant sur des notebooks, LakeFS open source combiné à DVC pour les expérimentations ne coûte rien en licence, seulement l'infrastructure ; pour une équipe produit de taille moyenne, une installation LakeFS en production devient indispensable, pour une enveloppe de 0 à 40 000 $ par an plus l'infrastructure ; pour une entreprise soumise à des exigences de conformité, une offre LakeFS managée avec outils d'audit se situe à partir de 40 000 $ de socle annuel. Ces montants doivent être mis en regard du risque réglementaire : un modèle incapable de produire sa documentation technique peut, selon les textes en vigueur, exposer l'entreprise à une requalification en « codéveloppeur » et donc à une responsabilité conjointe lorsque la fiche technique du modèle n'est pas disponible.
La mise en place ne doit pas démarrer par le choix d'un outil, mais par un inventaire des modèles en production et de leur niveau de risque au sens de l'AI Act. Un registre des IA, une classification par niveau de risque, une gouvernance des données traçable et des logs constituent le socle minimal avant toute discussion d'architecture technique. Une fois ce socle posé, la méthode se décline en trois étapes :
Cette dernière étape est souvent négligée faute de temps, alors qu'elle est la seule preuve réelle que le dispositif fonctionne. Un exercice de restitution documenté, mené une à deux fois par an, vaut largement plus qu'une procédure écrite jamais testée. Pour les organisations qui opèrent dans des secteurs à forte exigence réglementaire — santé, finance, assurance — cette discipline devient un prérequis d'exploitation, pas un confort ; nos retours d'expérience sectoriels sont détaillés sur notre page secteurs.
Il n'existe pas de réponse universelle à « DVC, LakeFS ou Delta Lake » : le bon choix dépend de la granularité des données à versionner, pas d'une préférence d'outil. Ce qui compte, en revanche, c'est de documenter la décision d'architecture elle-même, de chiffrer le surcoût de stockage associé, et de tester régulièrement la capacité à reconstituer un entraînement passé. C'est cette combinaison — méthode, coût maîtrisé, preuve opérationnelle — qui transforme le data versioning d'une ligne de budget technique en un actif de conformité. Pour évaluer le niveau de maturité actuel de votre organisation sur ce sujet, une prise de contact permet de cadrer un diagnostic rapide avant tout engagement d'outillage.
Nous utilisons des cookies de mesure d'audience et de suivi publicitaire pour comprendre la fréquentation du site et l'efficacité de nos annonces. Rien n'est déposé sans votre accord. En savoir plus