Let's Talk About Data Contracts: Standards, Tooling & Best Practices

Introduction

Bonjour, je m’appelle Simon. Je suis développeur dans l’âme, et j’ai atterri dans le monde de la data il y a environ quatre ans. Je viens de l’écosystème Java : j’ai co-écrit un livre sur le clean code en Java, « Java by Comparison ». Anecdote amusante : ce livre a été écrit avant l’IA, et il fait aujourd’hui l’objet d’un procès parce que les modèles d’Anthropic l’ont utilisé illégalement pour leur entraînement.

J’ai longtemps travaillé comme consultant chez INNOQ, et en 2025 nous en avons essaimé une startup. Je suis Co-Founder et CEO chez Entropy Data, où nous construisons une marketplace de produits de données fondée sur les Data Contracts.

Avec des collègues, j’ai co-traduit en allemand le livre « Data Mesh », lancé datamesh-architecture.com et datacontract.com, je co-maintiens des outils open source comme la Data Contract CLI et le Data Contract Editor, et je siège au Technical Steering Committee du projet BITOL de la Linux Foundation, qui porte les standards de Data Contracts. Je pense donc pouvoir vous parler des Data Contracts en connaissance de cause.

Pourquoi suis-je ici aujourd’hui ?

Une petite anecdote. Il y a environ un an et demi, j’ai donné une conférence à l’événement BARC « Heart of Data Mesh & Fabric », et Peter Baumann, d’INFOMOTION, l’a partagée sur LinkedIn. Le post a dépassé les 1 000 likes, il est devenu carrément viral, avec pour titre « A Data Contract Is Not a Contract ». Un peu provocateur, bien sûr, mais les gens ont cliqué.

Alors parlons des Data Contracts. Et quand on parle de données, on parle en réalité de confiance. De la confiance dans les données. C’est là l’essentiel.

Qu’est-ce qu’un Data Contract ?

Un Data Contract est un document qui définit la propriété, la structure, la sémantique, la qualité des données et les conditions d’utilisation pour l’échange de données entre un Data Producer et ses consommateurs. En gros, une spécification d’API, mais pour le monde de la data.

Sur le schéma, vous voyez que le Data Consumer veut utiliser les données, mais qu’il veut surtout pouvoir leur faire confiance. Le Data Contract joue ici un rôle décisif : le Data Producer propose des données et inscrit ses promesses dans le contrat. Si ces promesses correspondent aux données réelles, le Data Consumer peut utiliser les données et se fier au contrat.

Un Data Contract comporte de nombreux éléments. Nous allons les parcourir en détail, mais je veux d’abord vous raconter comment nous en sommes arrivés aux standards.

Le manque : aucune spécification pour les API de données

Il y a quelques années, dans le monde du logiciel et de la data, la réponse était très claire pour les API REST : OpenAPI, le successeur de Swagger. Pour les interfaces asynchrones comme Kafka, il y avait AsyncAPI. Mais pour les données, quand je voulais partager un gros jeu de données, il n’y avait pas de bonne réponse. Quelques solutions isolées, oui, mais rien de standardisé.

Et pourtant, des API de données, nous en avions plein : du CSV sur SFTP (oui, je vois les premiers sourires), du JSON sur S3, des tables SQL sur BigQuery, des fichiers Iceberg, des vues Snowflake, des Delta Live Tables. Ce sont toutes des interfaces. Quelqu’un a construit quelque chose de critique par-dessus, et si cette interface casse, tout ce qui se trouve en aval casse aussi.

Il nous fallait un moyen d’être sûr que le CSV que je consomme sur un serveur SFTP reste stable et que les données aient bien la qualité convenue.

Chacun a créé son propre format

À mesure que les données se sont décentralisées, de plus en plus d’équipes se sont mises à partager des données avec de plus en plus de consommateurs. Ce n’était plus une seule équipe data avec un serveur Oracle et un data warehouse.

Beaucoup d’entreprises ont vu le besoin de Data Contracts, et chacune a construit son propre format. Toutes avaient le même problème, toutes ont bricolé leur propre solution. Leur seul point commun ? Presque tout le monde a choisi YAML. Bon, certains ont pris JSON, et quelques-uns même Word et Excel. Puis un standard a fini par émerger.

L’Open Data Contract Standard (ODCS)

Ce standard, c’est l’Open Data Contract Standard. Il vient de PayPal, l’une de ces entreprises qui avaient développé leur propre format de Data Contract. Ils l’ont publié en open source sous licence Apache, puis en ont fait don à la Linux Foundation.

J’ai rejoint le comité de standardisation. Nous avons retiré les éléments propres à PayPal et élargi le standard pour que d’autres entreprises puissent l’utiliser. Depuis 2025, il est en version 3 (aujourd’hui 3.1) et il est vraiment exploitable. L’adoption s’accélère nettement cette année : Collibra s’est engagé, OpenMetadata aussi et a déjà livré des fonctionnalités dédiées.

Il couvre les fondamentaux, le schéma, la qualité des données, la tarification, l’équipe, la sécurité, les SLA, l’infrastructure, le support, les règles métier et les propriétés personnalisées.

Fondamentaux

Dans le bloc des fondamentaux, on définit l’identifiant, le nom, la version et un statut qui sert à introduire ou retirer progressivement un contrat. Comment versionner un Data Contract ? J’y reviens plus loin, dans la partie bonnes pratiques. Tous ces détails sont détaillés sur datacontract.com.

Schéma

La description du schéma est essentielle : elle définit la structure des données. Vous décrivez les tables et leurs colonnes. Ce qui est intéressant, c’est qu’on a à la fois des types physiques et des types logiques. On y met aussi des exemples, la classification des données et les noms métier : on va déjà vers la sémantique. Vous pouvez décrire le schéma très finement.

Qualité des données

La qualité des données fait partie du contrat, parce qu’elle fait partie des promesses que je fais à mes consommateurs en tant que fournisseur. On voit ici un contrôle de qualité sur les valeurs invalides, avec une bibliothèque comme Soda ou Great Expectations, et des contrôles en SQL, directement exécutables. Avec le bon outillage, vous pouvez vérifier automatiquement si les données réelles respectent le contrat.

Équipe

La section équipe indique qui fournit ces données et comment les contacter. Quel est le canal Slack ? Quel est le canal de support privilégié ? Est-ce qu’on vous répond vraiment ? C’est déterminant : quand quelque chose déraille côté données, il faut savoir à qui s’adresser.

Conditions d’utilisation

Les conditions d’utilisation définissent ce que j’ai le droit de faire avec les données en tant que consommateur, et ce que je n’ai pas le droit de faire. Y a-t-il des conditions de licence ? Le RGPD s’applique-t-il ? Existe-t-il des politiques internes de protection des données que l’on s’est imposées ? Qu’ai-je le droit d’en faire, et quoi ? Là encore, cela crée de la confiance.

Service Level Agreements

Les Service Level Agreements, c’est du classique : rétention des données, fraîcheur, latence. Ce sont des éléments essentiels, et là encore vérifiables automatiquement. Ici, je les ai garantis par écrit par le fournisseur, noir sur blanc.

Serveurs et infrastructure

Et enfin : où se trouvent réellement les données ? J’ai ici un exemple avec Postgres sur Supabase. Mais cela peut être n’importe quoi : Databricks, Snowflake, un CSV sur S3 ou toute autre plateforme de données.

Tout automatiser

Dès que j’ai un contrat qui contient toutes ces informations, je peux en faire mille choses :

• Tester : mettre les données et le contrat côte à côte et vérifier qu’ils correspondent. Sinon, lever une alerte et escalader.
• Générer du code : produire du DDL SQL, un modèle dbt, voire faire construire tout le projet dbt par l’IA. Quand l’entrée et la sortie sont claires, l’IA sait combler le trou.
• Surveiller en continu : vérifier en permanence que le contrat correspond toujours aux données, qui ne cessent d’être enrichies.
• Diffuser les métadonnées : pousser le contrat, qui est la source de vérité, vers les catalogues et les metastores, et s’en servir comme documentation.
• Provisionner l’infrastructure : créer des buckets S3, mettre en place des rôles IAM pour une marketplace de données, afin que d’autres accèdent facilement aux données protégées par le contrat.

C’est extrêmement puissant en matière d’automatisation.

Data Contract CLI

L’outil incontournable, c’est la Data Contract CLI, un projet open source qui compte environ 800 étoiles sur GitHub. Elle lit un contrat, se connecte à toutes les plateformes de données que vous connaissez et vérifie automatiquement que ce que déclare le contrat correspond aux données réelles. Vous obtenez un rapport.

Vous pouvez l’exécuter dans une pipeline, dans Airflow, et suivre les résultats dans le temps. Elle exporte vers de nombreux formats et importe depuis des sources existantes pour générer rapidement une première version de contrat.

Data Contract Editor

Parce qu’on veut parfois éditer à la main, nous avons construit le Data Contract Editor, un composant web open source qui permet d’éditer vos contrats de manière visuelle. La CLI y est directement intégrée : depuis l’onglet de test, vous lancez vos contrôles en un clic.

Modèle Excel

Et l’expérience montre une chose : tout cela est beau et brillant, mais les gens reviennent toujours à notre bon vieux modèle Excel, qui reprend exactement le standard ODCS. Pour beaucoup de monde, Excel reste tout simplement l’interface la plus simple. On ne le croirait pas, mais dans ce cas précis Excel ne meurt pas. Et bien sûr, la CLI sait lire le fichier Excel pour le tester en CI.

Démo en direct : tester un contrat sur des données réelles

Pendant la démo, j’ai ouvert le Data Contract Editor sur un contrat décrivant deux tables reliées par une clé étrangère. À droite, on voit un aperçu avec les descriptions, les exemples, le partitionnement, les clés primaires, les champs obligatoires, l’équipe responsable, l’endroit où vivent les données (Postgres) et les Service Level Agreements.

Le plus intéressant : je peux lancer un contrôle en direct depuis l’éditeur, qui compare le contrat aux données réelles. Le rapport indique quels contrôles sont passés. En interne, nous nous appuyons sur Soda Core pour cela.

Ce résultat de test peut être publié à côté du contrat dans une marketplace. Et c’est cela qui crée la confiance : je sais qu’il y a quelques secondes, une machine a vérifié que tout était au vert, et je peux construire mon cas d’usage ou mon analyse sur ces données en toute sérénité.

Bonne pratique : la correspondance 1:1:1:1:1

Un Data Contract dans une version majeure correspond à un Output Port d’un produit de données, qui correspond à un schéma de base de données (pouvant contenir plusieurs tables) et à un rôle de lecture que je peux acquérir.

Si vous arrivez à tenir cette correspondance, tout reste simple. Plus vous vous en écartez, plus cela se complique : un contrat par table et vous voilà avec bien trop de contrats ; plusieurs rôles par contrat et cela devient trop complexe. S’en écarter coûte cher.

Bonne pratique : l’habitat naturel

Les Data Contracts vivent dans le dépôt git du produit de données. Vous avez un fichier YAML pour la description du produit de données et un répertoire datacontracts/ où se trouvent les contrats, sous forme de fichiers YAML.

Vous pouvez définir des contrats pour les Output Ports (ce que j’offre) et, en option, pour les Input Ports (ce que je consomme). Par exemple : « je n’utilise que les trois premières colonnes de votre table, j’ignore tout le reste. » Vous pouvez même ajouter vos propres contrôles de qualité par-dessus ceux du fournisseur.

Bonne pratique : cycle de vie et évolution

De la gestion du changement classique, fondée sur les versions majeures. Un changement cassant impose une nouvelle version majeure. Les changements non cassants, comme l’ajout d’une colonne, passent en versions mineures ou correctives, si bien que la V1 reste active longtemps.

Quand un changement cassant devient vraiment nécessaire, j’introduis la V2 à côté de la V1. Il y a une période de grâce où les deux versions tournent en parallèle, la V1 étant dépréciée et la V2 active, ce qui laisse aux consommateurs le temps de migrer. Cela demande un peu d’effort, mais cela reste propre.

Data-first ou contract-first ?

Le data-first est l’approche la plus naturelle : vous avez déjà des données sur Snowflake ou Databricks et vous les placez « sous contrat ». L’import de la CLI vous génère rapidement une première version de contrat.

Mais à partir du moment où vous activez un contrat, celui-ci devient la source de vérité. Si les données s’en écartent, ce sont les données qui ont tort : par définition, le contrat a toujours raison. Vous basculez donc naturellement en contract-first : tout changement passe d’abord par le contrat, puis par l’implémentation.

Nous avons maintenant notre premier client américain, et il est totalement contract-first. Il crée toujours le contrat d’abord, puis construit le produit de données. L’avantage : on peut discuter précisément de la tête qu’aura l’interface, et ensuite c’est facile à construire. Avec l’IA, les transformations s’écrivent pratiquement toutes seules dès lors que l’interface est clairement définie.

Bonne pratique : l’automatisation

Vous pouvez automatiser à trois moments :

• Chaque jour, côté plateforme de données : lancer datacontract test pour vérifier en continu les contrats face aux données de production.
• À chaque commit dans les PR : lancer datacontract lint (avec les règles maison) et datacontract test --server=staging pour repérer les problèmes avant la fusion. Une entreprise peut imposer des règles du type « chaque champ doit porter une classification de données », faute de quoi la PR ne passe pas.
• À chaque commit sur main : lancer datacontract publish pour pousser le contrat vers votre marketplace de données, là où les gens voient les données et leur font confiance.

Pourquoi les agents IA ont besoin des Data Contracts

Un Data Contract est, par définition, la source de vérité des métadonnées d’un jeu de données proposé. Quoi de mieux pour une IA agentique que de consulter le contrat, de vérifier s’il est utile pour la tâche en cours, de comparer plusieurs contrats, puis d’utiliser les données protégées par le contrat le plus adapté ?

Pendant la démo, j’ai demandé à l’agent IA : « Qui sont mes meilleurs clients ? » En arrière-plan, il a cherché des produits de données dotés de contrats, trouvé le bon, examiné le contrat pour vérifier qu’il pouvait répondre à la tâche, généré une requête SQL, l’a exécutée et a renvoyé la réponse.

C’est cela, l’avenir. Quel que soit le client IA que vous utilisez, des agents affamés de données arrivent. Ils veulent accéder à Snowflake, à Databricks, partout où vivent les données. Le Data Contract et la couche de gouvernance placée entre les agents et les données font office de ligne de défense.

L’architecture : le serveur MCP de produits de données

Côté architecture : le client IA est en haut, la plateforme où vivent les données est en bas, et une marketplace porte les métadonnées. L’agent IA dialogue avec un serveur MCP de produits de données capable de rechercher, de récupérer les métadonnées avec le contrat et d’exécuter des requêtes.

La couche décisive au milieu, c’est la gouvernance : gestion des droits, vérification des conditions d’utilisation, politiques globales, quotas et contrôles de sécurité. Cela arrivera, tout simplement parce que c’est bien trop naturel pour ne pas arriver.

ODCS sera partout

Swagger 1.0 est sorti en 2011, et aujourd’hui OpenAPI est partout.

ODCS 3.0 est sorti en 2025. Je suis convaincu que dans cinq ans, les Data Contracts seront aussi omniprésents que l’est aujourd’hui OpenAPI dans le monde des API.

Merci

Merci de votre attention. Si vous voulez poursuivre la discussion, vous me trouvez sur LinkedIn, vous pouvez m’écrire à simon.harrer@entropy-data.com ou passer sur www.entropy-data.com. Et si vous aimez l’open source, mettez une étoile à datacontract-cli sur GitHub.