Data-first or Contract-first?

L'intervenant

Jochen Christ est un ingénieur logiciel passionné de data qui, selon ses propres mots, construit des outils pour faire travailler ensemble les données, les gens et l'IA. Il est co-fondateur et CTO d'Entropy Data, auteur du site Data Mesh Architecture, mainteneur de la Data Contract CLI et membre du TSC du projet Bitol de la Linux Foundation, qui héberge l'Open Data Contract Standard.

Entropy Data est une marketplace de produits de données bâtie sur les Data Contracts et la sémantique, avec un objectif : rendre des données de qualité accessibles aussi bien aux humains qu'aux agents.

Où commence le parcours ?

Une seule question structure toute la conférence : quand vous vous lancez dans la construction d'un produit de données, quel est votre point de départ ?

• Voie A, la traditionnelle : partir des données. Vous extrayez les données de production, vous les explorez, vous construisez un produit, puis vous définissez le contrat correspondant.
• Voie B, l'alternative : partir du contrat. Vous vous mettez d'abord d'accord sur l'interface avec les Data Consumers, vous spécifiez le contrat, puis vous le construisez.

Le second itinéraire est-il un détour, un raccourci, ou simplement un autre chemin vers le même objectif ? C'est ce à quoi la conférence veut répondre.

Utiliser les données que vous avez

C'est ainsi que les Data Engineers ont toujours travaillé. Vous extrayez les données de production vers votre plateforme data, vous les explorez pour découvrir des cas d'usage et des tendances, puis vous construisez un jeu de données, un tableau de bord ou un rapport à livrer. C'est le rythme naturel du data engineering et de l'analytique.

Cette approche a de vraies qualités : la créativité (vous repérez des tendances et des erreurs que vous n'auriez jamais pensé à demander), la rapidité (une requête SQL vous donne un prototype en quelques minutes) et un ancrage dans le réel, puisque vous travaillez sur les données qui existent vraiment.

Mais l'exploration seule ne fait pas un produit

Le hic avec le data-first, c'est que ce que vous obtenez n'est pas encore un produit. Quatre problèmes reviennent sans cesse :

• Propriété non définie, le problème central du Data Mesh : qui possède ce jeu de données sur la durée ?
• Aucune documentation : une colonne nommée TX021 contient un horodatage, mais est-ce la date de commande, l'heure du paiement, ou tout autre chose ?
• Pas encore prêt pour la production : aucune règle de qualité, aucun contrôle, aucune attente exprimée.
• Jeux de données techniques massifs : copier la production vous donne des tables larges et brutes dans lesquelles personne ne sait naviguer.

Le premier remède, c'est de mettre les données sous contrat, ce qui ajoute une quatrième étape au parcours : tester.

Qu'est-ce qu'un Data Contract ?

Un Data Contract est un document YAML qui consigne qui possède les données, leurs conditions d'utilisation, une description, ainsi que leur schéma, leur sémantique, leur qualité et leurs SLA.

Voyez-le comme une spécification d'API, mais pour les données. Les API REST ont OpenAPI, les messages et les topics Kafka ont AsyncAPI, et les jeux de données partagés ont l'Open Data Contract Standard. Même idée, interface différente.

Le standard : ODCS

Le standard du marché pour les Data Contracts, c'est ODCS, l'Open Data Contract Standard, gouverné par le projet Bitol de la Linux Foundation. Un seul fichier YAML contient tout ce dont un consommateur a besoin :

• Les fondamentaux : nom, version, statut.
• Le schéma : tables et colonnes, avec exemples, classifications et tags, donc bien plus qu'un simple schéma SQL.
• La qualité as code : des règles prédéfinies comme « le nombre de valeurs invalides doit être nul », ou des contrôles SQL libres qui s'exécutent réellement.
• L'équipe : le propriétaire du produit de données et ses coordonnées.
• Les conditions d'utilisation : la finalité prévue et les limites, par exemple « ces données de commande ne peuvent pas servir au marketing ».
• Les SLA et les serveurs : les garanties, et l'endroit où vivent réellement les données.

Les conditions d'utilisation sont sans doute la partie la plus importante : elles disent à quoi sert le produit et à quoi il ne doit jamais servir.

Transformer le contrat en test

Un contrat n'a de valeur que si vous pouvez le faire respecter. La Data Contract CLI open source lit le YAML, se connecte à votre produit de données sur Snowflake, Databricks, BigQuery, Postgres ou ailleurs, et convertit le schéma, les règles de qualité et les SLA en requêtes SQL qu'elle exécute sur les vraies données.

Lancez datacontract test et vous obtenez un code de sortie : zéro, tout va bien ; autre chose, quelque chose a cassé. Intégrez-le à un pipeline de déploiement, à un DAG Airflow ou à un job Databricks pour vérifier, à chaque changement, que le produit en production honore encore toutes les garanties du YAML.

Dans l'exécution CI de la diapositive, 27 contrôles passent et un échoue : il attrape une incohérence de type, une colonne que le contrat attend en nombre alors qu'elle contient du texte.

Ce n'est pas fini : publiez-le

Le Data Mesh consiste à partager des produits de données par-delà les frontières des équipes : le parcours gagne donc une cinquième étape, publier. Le même YAML peut être poussé dans un outil de métadonnées, un catalogue ou une marketplace comme Entropy Data, ce qui rend le produit découvrable, lisible et abordable, au lieu d'un simple fichier YAML brut.

Et comme ce sont des métadonnées sur un standard ouvert, les agents peuvent les lire aussi. Ils peuvent chercher dans la marketplace, puis dialoguer avec les données ou les interroger de façon autonome, tout en respectant les conditions d'utilisation définies dans le contrat, la finalité et les limites : l'accès reste ainsi sécurisé.

Trois problèmes sur quatre, réglés

Mettre les données sous contrat règle trois des quatre problèmes : vous avez désormais un propriétaire nommé, une interface convenue et documentée, et des tests de qualité exécutables.

Ce que cela ne règle pas, c'est le jeu de données technique massif. Le data-first a tendance à publier tout ce qui sort du système source : vous vous retrouvez toujours avec de larges tables de colonnes qui se ressemblent, sans que personne sache lesquelles intéressent vraiment le métier. Pour résoudre ça, il faut changer de point de départ.

Commencer par une conversation

Le contract-first ne part pas des données. Il part d'une conversation. Avant même de regarder une seule colonne, vous rencontrez vos Data Consumers et vous comprenez ce qu'ils veulent vraiment faire : un modèle d'IA, un tableau de bord pour le CFO, un cas d'usage opérationnel. Ensuite, vous spécifiez ces besoins sous forme de contrat, vous construisez le produit et vous le testez.

Écrire le contrat en amont vous donne aussi la meilleure documentation que vous aurez jamais, parce que vous avez encore l'énergie de l'écrire. Personne n'écrit de bonne doc une fois le produit livré.

Les bénéfices s'accumulent : la collaboration et l'empathie (vous savez que quelqu'un en a réellement besoin), le langage métier (vous employez les termes du consommateur, pas des noms de colonnes bruts), des attentes réelles (des règles de qualité qui veulent dire quelque chose) et un produit de données à la bonne taille, avec uniquement les champs vraiment nécessaires, ce qui règle précisément le problème des jeux de données trop larges.

Se laisser piloter par le cas d'usage métier

Vous commencez par un atelier, idéalement sur site, avec les parties prenantes et le futur Data Product Owner. Un data product canvas le structure : vous le remplissez en partant de la droite, du cas d'usage métier, et vous laissez celui-ci piloter l'interface et les sources dont vous aurez besoin.

L'exemple fil rouge : Maxi, category manager dans une entreprise de e-commerce, veut l'inventaire des produits qui ne se sont pas vendus depuis six mois, ces fameux shelf warmers qui prennent la poussière en entrepôt. « Shelf warmer » est le terme métier, et c'est bien là tout l'intérêt.

John, Product Owner dans l'équipe ventes, pousse les questions qui affûtent le contrat : qu'est-ce qui compte comme une vente ? Les retours comptent-ils ? Et les mises au rebut ou les vols ? Ces réponses deviennent la sémantique du contrat.

Le recueillir là où le métier sait le faire

Le YAML brut n'est pas accessible aux utilisateurs métier. Après avoir vu trois clients saisir leurs contrats dans Excel de leur propre initiative, l'équipe a publié un modèle Excel ODCS officiel, accompagné d'un convertisseur CLI entre Excel et YAML dans les deux sens. Les Product Owners remplissent la feuille, la font circuler et la convertissent quand elle leur convient.

Pour les Engineers, le Data Contract Editor open source transforme un contrat en expérience visuelle, avec des vues diagramme et entité-relation. Il est désormais intégré à la CLI : datacontract edit <name> ouvre l'éditeur directement.

Un contrat à la bonne taille

Une fois le besoin compris, il est minuscule. Maxi n'a besoin ni de toute la table des commandes ni de toute la table des stocks. Il lui faut une seule table, shelf_warmers, avec quatre colonnes : un SKU (le numéro d'article), un nom d'article, un horodatage de dernière vente et, par convention interne, un horodatage de traitement.

Le vrai travail ici, c'est la sémantique : expliciter ce que « dernière vente » veut dire exactement. La description précise qu'il s'agit de l'horodatage du dernier mouvement de stock négatif, que cela peut inclure des événements qui ne sont pas des ventes comme les mises au rebut, et que la valeur est nulle si l'article n'a jamais enregistré de vente. Cette phrase fait toute la différence entre un produit utilisable et un jeu de devinettes.

Le construire avec un agent de code

Une fois le contrat spécifié, vous construisez, et aujourd'hui cela veut dire avec un agent de code (Claude Code, Codex, Copilot CLI). L'agent a besoin de deux entrées. La première, c'est le YAML du contrat : quoi construire. La seconde, c'est comment votre organisation construit ses produits de données, parce que l'agent ignore si vous utilisez Snowflake, dbt ou vos propres conventions de nommage.

Ce « comment » est fourni sous forme de skills : des instructions pour l'agent de code, conservées dans un dépôt git.

Les skills : apprendre votre stack à l'agent

Le dbt Data Product Builder open source est un dépôt modèle que vous clonez et adaptez à vos conventions. Chaque skill n'est qu'un document markdown listant les étapes à suivre : une skill bootstrap pour un produit tout neuf, une skill implement pour les évolutions, plus des skills pour les métadonnées et les tests.

Une skill peut par exemple définir comment un champ ODCS se traduit en modèle dbt, ou embarquer un template décrivant à quoi ressemble un projet dbt chez vous, que l'agent respectera ensuite. Vous l'installez via la marketplace de plugins de votre agent et vous la reliez à vos métadonnées et à votre projet dbt.

« Tester ne coûte pas cher, vous pouvez donc ajouter de plus en plus de skills, et les skills peuvent se référencer entre elles. »

La construction

Toute l'instruction tient en une ligne : implémente le produit de données correspondant au contrat. L'agent lit le contrat, reconnaît qu'il s'agit d'un nouveau produit, charge la skill bootstrap avec son template dbt et se met au travail en mode YOLO, en mettant en place les modèles dbt et le câblage OpenLineage que prescrivent les skills. Montré dans la conférence sous forme d'enregistrement d'écran ; la construction en direct prend environ onze minutes.

Point crucial : il utilise aussi la marketplace pour trouver ses sources en amont. Pour satisfaire le contrat, il cherche les événements de mise à jour de stock et les données de référence des articles, trouve les produits de données existants correspondants et demande les accès dans le code généré.

Le résultat

Environ onze minutes plus tard, le produit est construit : un projet dbt complet avec ses Input Ports et Output Ports, la table SHELF_WARMERS alimentée dans Snowflake, et le produit de données publié dans la marketplace en mode privé, prêt à être rendu public par son propriétaire.

Les tests de contrat, eux aussi fournis par les skills, s'exécutent comme une étape de votre CI ou de votre pipeline de données. Quand le contrat est au vert, vous livrez. L'implémentation est faite par un agent de code, mais les besoins, la sémantique et les garanties restent les vôtres.

Livrer quand les tests sont au vert

Le contract-first se déroule ainsi : comprendre, spécifier, construire, tester. Vous investissez du temps en amont pour comprendre et spécifier les besoins sous forme de contrat, l'agent de code l'implémente, les tests de contrat tournent dans votre pipeline, et quand ils sont au vert, vous livrez.

Il n'y a pas de mauvais chemin

Les deux itinéraires arrivent à la même destination : un produit en production qui délivre de la valeur. Alors, quelle est la réponse ? Trois enseignements :

• C'est le contrat qui rend les données fiables. Il consigne les besoins et la sémantique et automatise les tests : dès que quelque chose romprait les attentes d'un consommateur, ça passe au rouge et vous êtes averti.
• Parlez avec vos parties prenantes data. Il n'y a pas de raccourci. Si vous ne comprenez pas la valeur métier d'un produit de données, il ne vaut probablement pas la peine d'être construit. Prenez le product ownership au sérieux.
• Les agents de code implémentent ce que vous spécifiez. Meilleures sont vos spécifications et vos descriptions, mieux l'agent construit, et mieux il sait signaler ce qui manque ou ce qui cloche.

« Ce sont les Data Contracts qui font la différence. Ce sont eux qui rendent votre produit de données digne de confiance. »