Data Contracts: What They Are, Why They Matter, and How to Use Them

Introduction

Bonjour à toutes et à tous, je suis Jochen, d'Ansbach, près de Nuremberg. Aujourd'hui, nous parlons des Data Contracts, un sujet devenu très populaire. Nous allons voir ce qu'est un Data Contract, dérouler quelques exemples, passer en revue les outils disponibles et comprendre pourquoi le sujet a pris autant d'importance.

Je travaille chez Entropy Data, une spin-off d'INNOQ. Notre cœur de métier, c'est un logiciel de gestion des produits de données avec des Data Contracts, une plateforme de gestion des métadonnées. Nous maintenons aussi deux outils open source : le Data Contract Editor, une interface web pour travailler sur les Data Contracts, et la Data Contract CLI, pour les tester.

Je viens du génie logiciel, Java est ma langue maternelle. Il y a environ cinq ans, nous avons plongé dans le monde de la donnée en nous demandant quelle serait la prochaine grande vague en informatique. Le cloud, c'était fait ; les architectures événementielles aussi ; le Domain-Driven Design était partout. Nous en avons conclu que la donnée et l'IA auraient le plus d'impact. Cela nous a menés au Data Mesh, puis à traduire en allemand, pour O'Reilly, le livre Data Mesh de Zhamak Dehghani.

Où sont vos API ?

En venant du monde logiciel, la première question que nous posions aux gens de la data était toujours : « Où sont vos API ? » Et la réponse était toujours : « Regarde dans le catalogue de données. » Alors nous regardions, et au début nous ne trouvions rien ; et quand nous trouvions quelque chose, nous n'y comprenions rien.

Puis PayPal a publié le premier modèle de Data Contract. L'idée nous a plu, mais nous trouvions qu'elle pouvait se rapprocher davantage d'OpenAPI/Swagger. Nous avons fait une proposition et, finalement, nous avons uni nos forces pour créer le projet BITOL au sein de la Linux Foundation, où nous pilotons et faisons évoluer l'Open Data Contract Standard (ODCS).

Je siège au Technical Steering Committee. Donc s'il manque quelque chose ou si un point n'a pas de sens, dites-le-nous : nous pouvons l'améliorer.

Un document YAML, comme OpenAPI, mais pour les données

Un Data Contract est, surprise, un document YAML. Pourquoi du YAML ? À cause de Kubernetes : dans Kubernetes, tout est en YAML. Et OpenAPI/Swagger est aussi un document YAML. Il décrit ce qui compose un jeu de données que je veux partager avec d'autres.

Dans un contexte Data Mesh, une équipe est responsable d'un jeu de données : celle où la donnée est créée à l'origine, par exemple dans un microservice, un ERP ou un domaine métier. Cette équipe prend l'ownership du produit de données partagé avec les autres équipes. Les autres veulent y accéder pour faire de l'analytique, construire des services, développer des applications IA ou créer des produits de données agrégés.

Le Data Contract définit l'interface vers les consommateurs. Il devient pertinent dès qu'on échange des données entre équipes et entités organisationnelles. Important : il s'agit d'une relation d'usage, pas d'un pipeline ETL. Les autres équipes accèdent à mes données ou les consomment. Conceptuellement, c'est une dépendance d'usage, ce qui est très différent des pipelines de données classiques.

Et pour les développeurs que la vue d'une table de base de données rend nerveux : je ne parle surtout pas d'exposer directement la base Oracle ou Postgres. Il y a toujours une couche anticorruption, une vue, qui découple le modèle de données du système opérationnel.

L'Open Data Contract Standard (ODCS)

ODCS est aujourd'hui, je crois, le standard de l'industrie sur lequel tout le monde a convergé. Collibra, OpenMetadata, IBM : tous les grands éditeurs de solutions de métadonnées l'adoptent. S'il vous plaît, si vous introduisez les Data Contracts, n'inventez pas un format propriétaire. Utilisez ODCS pour profiter de l'écosystème et de l'outillage, et rester interopérables avec les couches de métadonnées et les catalogues de données.

L'an dernier, l'Open Data Product Specification (ODPS) a également vu le jour à la Linux Foundation. Un produit de données, c'est le système ou le module qui produit la donnée, avec des Input Ports, un pipeline, des tests, des métadonnées, de la documentation, et qui expose au bout du compte un jeu de données via un Output Port assorti d'un Data Contract précis. Le produit de données est le système ; le contrat est la spécification d'interface du jeu de données final.

Deux façons de construire un Data Contract

Data first, c'est l'approche la plus répandue. Vous avez déjà une table ou un schéma dans votre data warehouse. Vous voulez maintenant y ajouter un contrat : le documenter, le décrire, préciser les attributs de qualité, pour que vos consommateurs comprennent ce qu'est ce jeu de données. Vous posez un contrat sur des données existantes.

Contract first est moins courant, mais très puissant. Vous partez des besoins de vos utilisateurs métier et de vos consommateurs. De quelles données ont-ils réellement besoin ? À quoi doit ressembler le modèle de données pour couvrir leurs cas d'usage ? Vous concevez ensuite le produit de données en fonction de ces besoins. Résultat : des produits de données plus petits et mieux ciblés, au lieu de tables à 10 000 colonnes parce que personne n'a jamais voulu jeter quoi que ce soit.

Une remarque importante : les utilisateurs ne savent ni lire ni écrire du YAML. Nous allons voir des outils qui rendent tout cela bien plus accessible, y compris des modèles Excel.

Exemple déroulé : un Data Contract sur les commandes

Prenons un exemple concret. Dans une boutique en ligne, une équipe Checkout gère les données de commandes et de clients. Une équipe Recommandations veut construire un modèle de machine learning. Nous organisons donc un atelier contract-first avec Sophia, la data scientist :

« En tant que data scientist, je veux toutes les commandes de la boutique en ligne des cinq dernières années, afin de savoir quels articles ou quelles catégories un client achète ensemble, ce qui nous permettra de construire un modèle de recommandation pour la boutique et les e-mails marketing. »

L'ownership est la partie la plus difficile. Quelle équipe accepte d'être responsable de la fourniture du jeu de données des commandes ? Cette question représente souvent 50 % du travail. Nous avons annulé des ateliers parce que personne ne voulait porter le produit de données. Sans ownership, tout le reste, la sémantique, la qualité, les niveaux de service, n'a plus d'objet.

Schéma, sémantique et exemples

Le cœur d'un Data Contract, c'est le modèle de données. Vous définissez des schémas avec des tables et des colonnes. Mais il n'y a pas que de l'information technique : on y trouve aussi les noms et descriptions métier, ceux qu'emploierait un utilisateur métier. Dit-il « Order ID », « Bestellnummer » ou « numéro de commande » ? Nous notons à la fois le nom technique et le nom métier.

Cette description sémantique, l'IA ne peut pas la produire à votre place. Vous ne l'obtenez qu'en parlant à vos experts métier, en écoutant comment ils échangent entre eux, et en le mettant par écrit. C'est la meilleure source de bonnes métadonnées.

Les exemples sont essentiels. En atelier, nous écrivons volontairement des exemples légèrement faux, parce que les gens adorent corriger. Un expert métier va dire : « Quatre décimales ? Ce n'est pas possible. » Et là, vous découvrez si les montants sont stockés en dollars, en euros, en entiers de centimes ou en doubles. Les questions classiques, celles qui ont toujours fait mal.

Si personne ne corrige vos exemples, c'est que votre auditoire s'est endormi.

Les règles de qualité

Les règles de qualité peuvent d'abord être saisies en texte libre, comme une description de ce qu'attendent les consommateurs. Par exemple : « La date de livraison ne doit pas dépasser 20 jours dans le futur. » Commencez par capturer les attentes métier en langage naturel.

Transformez-les ensuite en requêtes SQL. L'IA peut vous y aider. L'essentiel, c'est de capturer la logique métier. Une fois le SQL écrit, vous pouvez vérifier la qualité de vos produits de données et de vos jeux de données, un peu comme le font des outils tels que Great Expectations.

L'histoire de John et du filtre de consentement

Une heure après le début de l'atelier, John, le product owner de l'équipe Checkout, se souvient tout à coup : « Désolé, nous ne pouvons pas vous donner toutes les commandes. Il y a une restriction liée au consentement : seules 80 % environ des commandes disposent du consentement cookies pour un usage analytique. »

Sophia, la data scientist, répond : « Pas de problème, le machine learning est de toute façon approximatif, 80 % suffisent. » Mais cette information doit figurer dans le Data Contract, dans les limites. Ce jeu de données est validé pour un usage analytique, mais il n'est pas adapté aux KPI financiers, puisqu'il ne représente qu'environ 80 % du chiffre d'affaires.

Voilà typiquement le genre de limites que l'on ne voit pas en regardant simplement la table dans le data warehouse. Il faut des métadonnées dans le contrat pour les consigner.

Les conditions d'utilisation prennent de plus en plus d'importance, en particulier pour l'IA. Pouvoir indiquer à un agent ce qu'il a le droit de faire ou non avec un jeu de données, et pour quels usages celui-ci convient, est déterminant pour la gouvernance. Vous pouvez aussi référencer des politiques standard comme le RGPD, des règles de classification des données ou des règles propres aux données marketing.

Niveaux de service et garanties non fonctionnelles

Un Data Contract peut aussi couvrir des aspects non fonctionnels : disponibilité, latence, heures de support, rétention et garanties de sauvegarde. À chaque session, quelqu'un demande : « Puis-je utiliser ce jeu de données pour mon microservice opérationnel ? » La réponse : définissez les garanties dans le contrat et laissez le consommateur juger si elles suffisent à son cas d'usage.

Personne ne construirait une boutique en ligne dépendant d'un système garanti à 99,8 % de disponibilité. On ajouterait au minimum une couche anticorruption ou un découplage asynchrone. Les informations de SLA du contrat aident les consommateurs à prendre cette décision.

Pourquoi le nom est faux, et pourquoi il est resté

Ce qu'un Data Contract ne contient pas, ce sont les parties, c'est-à-dire les consommateurs. Nous avons l'owner, mais pas ceux qui consomment. En droit commercial, un contrat est une déclaration bilatérale et engageante. Ce caractère bilatéral manque ici. C'est en réalité une spécification d'interface.

Juridiquement, cela ressemble plutôt à une invitatio ad offerendum, une invitation à faire une offre. Alors pourquoi parle-t-on de « contract » ? Parce que PayPal a forgé le terme en premier et qu'il est resté. Il est accrocheur. Il marque les esprits. Il n'est simplement pas exact techniquement.

La relation bilatérale est gérée à part, via les agreements dans l'outillage, avec des dates de début, des dates de fin et une gestion du cycle de vie. C'est là que vit la relation 1:1 entre fournisseur et consommateur.

Produits de données et Data Contracts

Un produit de données a une face privée et une face publique. En interne, il y a des pipelines, du code de transformation, des tables intermédiaires, des tables brutes, des tests. Au bout du compte, vous exposez un jeu de données précis que d'autres équipes vont consommer : c'est la partie publique, l'Output Port.

Le Data Contract décrit exactement cet Output Port. Le produit de données est le système sur la plateforme ; le contrat est l'interface qui décrit à quoi ressemblent les données et quelles garanties les accompagnent. Les deux sont étroitement liés.

Data Contract Editor

Le Data Contract Editor est une application web open source que vous pouvez déployer en local sous forme de conteneur Docker. Vous pouvez écrire le YAML directement, mais aussi passer par des formulaires pour saisir les conditions d'utilisation, les informations serveur et les définitions de schéma. Il propose de la modélisation visuelle, façon modèle entité-association, comme dans Innovator ou d'autres outils dont les gens ont l'habitude.

Au final, il produit du YAML. Vous pouvez prévisualiser en HTML, valider la conformité et lancer des tests pour vérifier que le produit de données derrière le contrat correspond bien à ses définitions.

Le modèle Excel, on n'échappe pas à Excel

Nous avons créé un modèle Excel parce qu'au moins trois clients nous ont dit : « Tout est très bien, mais nous avons mis en place Excel pour travailler avec nos utilisateurs métier. » En tant qu'informaticiens, c'était dur à accepter. Mais pour beaucoup de gens, Excel offre encore la meilleure expérience. On peut l'envoyer par e-mail. Et les données sources sont souvent déjà dans Excel.

Le modèle est conforme au standard et se convertit en YAML dans les deux sens. Vous ne vous débarrasserez pas d'Excel : autant en faire un bon Excel.

La Data Contract CLI et l'intégration dans les pipelines

La Data Contract CLI reprend toutes les informations du YAML, types de champs, formats, règles de qualité (en SQL ou en Great Expectations), se connecte à la base de données et vérifie que les données respectent les garanties du contrat. Elle exécute des requêtes SQL pour chaque aspect et indique ce qui passe et ce qui échoue.

L'intégrer à votre pipeline de déploiement, par exemple dans un workflow GitHub Actions, vous donne bien plus de confiance dans vos données. Vous réagissez vite quand quelque chose passe au rouge. Et les consommateurs peuvent lancer les mêmes vérifications sur leurs Input Ports avant d'exécuter leurs pipelines.

La CLI dialogue avec toutes les grandes plateformes de données (BigQuery, Snowflake, Databricks, Postgres et bien d'autres) et sait importer et exporter depuis divers formats.

Communication, confiance et découvrabilité

Communication : les Data Contracts vous donnent un format structuré pour réunir les gens, producteurs et consommateurs, et discuter des besoins en données, de la connaissance du domaine, de la sémantique. Ils guident la conversation à travers les points importants : conditions d'utilisation, SLA, règles de qualité. Ne sous-estimez pas cet aspect de transformation au sein de l'organisation.

Confiance : les données ne sont utilisées que si les consommateurs les jugent justes et complètes. La confiance se perd vite : après la troisième panne du pipeline, plus personne ne croit aux données. Vous connaissez le grand classique : un KPI, trois valeurs différentes. Laquelle est la bonne ? Les Data Contracts aident grâce à une sémantique claire et à des contrôles de qualité automatisés.

Découvrabilité : en rassemblant vos Data Contracts et vos spécifications de produits de données au même endroit, vous obtenez une vue d'ensemble très puissante de toutes les données disponibles dans l'organisation. Contrairement aux catalogues de données traditionnels qui scannent la moindre table brute ou intermédiaire, une marketplace de données bâtie sur les produits de données ne montre que des jeux de données gérés et curés, destinés à être consommés : beaucoup moins d'artefacts, et une qualité bien supérieure.

Les agents ont besoin des données de l'entreprise, et de gouvernance

Les clients IA, ChatGPT, Claude, les systèmes d'agents autonomes, savent répondre à « Quelle est la distance entre la Terre et la Lune ? » sans données d'entreprise. Mais pour des tâches métier utiles, il leur faut accéder aux données de votre organisation : clients, commandes, finances.

Pour que ce soit possible en toute sécurité, les agents ont besoin de plusieurs outils :

• Rechercher : découvrir quels produits de données existent (données clients, commandes, etc.).
• Évaluer : juger si la sémantique et les modèles de données correspondent à la question posée.
• Interroger : à partir du schéma, une IA peut écrire automatiquement du SQL et interroger les données.
• Gouverner : contrôler quels agents ont accès, vérifier l'identité (contexte utilisateur ou compte de service), faire respecter les conditions d'utilisation, appliquer les politiques globales et exécuter des contrôles de sécurité.

C'est exactement l'architecture que nous mettons en œuvre avec notre serveur MCP Entropy Data. Un agent pose une question métier, le serveur MCP cherche dans la marketplace de données, récupère le Data Contract avec toutes ses métadonnées, évalue le schéma, demande l'accès et génère le SQL. Le Data Contract, avec ses conditions d'utilisation, ses règles de qualité et sa sémantique, devient la couche de gouvernance qui rend tout cela sûr et maîtrisé.

Démo en direct : un agent IA face aux Data Contracts

Dans la démo, je demande à Claude : « Qui sont nos meilleurs clients ? » Le serveur MCP Entropy dispose de trois outils : search, fetch et query. Claude en extrait un terme de recherche, interroge la marketplace de données, trouve les produits de données correspondants et récupère le contrat complet, schéma et métadonnées inclus.

À partir du schéma, avec des champs comme « Total Spend » et « Average Order Value », il génère automatiquement le SQL, interroge les données et renvoie la réponse. Le tout gouverné par le Data Contract : contrôle d'accès, conditions d'utilisation et garanties de qualité sont appliqués de bout en bout.