Open Standards for Data Products

L'orateur

Simon Harrer se présente comme un ingénieur logiciel dans l'âme, passé à la data il y a environ cinq ans. Il a co-écrit « Java by Comparison » (qui fait aujourd'hui partie des données d'entraînement de plusieurs grands modèles de langage, note-t-il avec un sourire), et il a traduit « Data Mesh » de Zhamak Dehghani en allemand. L'édition papier allemande est tout en couleurs, ce qu'aucun original anglais n'est.

Il est aujourd'hui co-fondateur et CEO d'Entropy Data, une petite startup qui construit une marketplace de produits de données et une couche de métadonnées, avec des clients dans le monde entier, six personnes et beaucoup d'agents qui font le travail. Il siège au Technical Steering Committee de Bitol à la Linux Foundation, contribue à Open Semantic Interchange (l'initiative de standardisation lancée par Snowflake) et développe de l'outillage open source autour de tout cela.

Il maintient aussi data-landscape.com, un panorama ouvert des standards ouverts du monde de la data. Ça vaut le coup d'œil, dit-il : tout est ouvert et gratuit.

Le programme

Trois choses. D'abord, un aperçu du futur pour la motivation : à quoi cela pourrait-il ressembler ? Ensuite, découvrir les standards, les ouverts : pourquoi ils existent et ce qu'ils permettent de faire.

Et pour finir, écrire l'histoire ensemble. Gardez vos téléphones à portée de main et connectez-vous à GitHub, lance Simon à la salle, on va en avoir besoin avant la fin.

Un aperçu du futur (juste un teaser)

La question de départ : et si nous utilisions déjà les standards ouverts pour les produits de données, et que nous les vivions vraiment ? Pour y répondre, Simon lance une démo live (avec un enregistrement de secours prêt, au cas où). Dans un même répertoire, deux fichiers : un Data Contract conforme au standard, qui décrit les données qu'il veut proposer, et un fichier produit de données ODPS, qui décrit la boîte du schéma d'architecture, avec son objectif, son domaine, ses Output Ports et ses liens vers la couche sémantique.

Puis il déclenche l'agent de code : claude --dangerously-skip-permissions, « fais de ce produit de données une réalité ». Il n'a écrit que ce qu'il voulait. L'agent trouve le reste tout seul, et la construction prend environ 15 minutes.

Il le laisse donc tourner en arrière-plan, les tokens travaillant dur pour nous, et passe au vrai sujet de la conférence. Gardez cette image en tête. Le dénouement arrive à la fin.

D'abord, qu'est-ce qu'un produit de données ?

Dans une conférence data, le public connaît, alors Simon va vite. Un produit de données, c'est la pensée produit appliquée aux données : on optimise pour ses consommateurs, on assume la propriété, une équipe se tient derrière et on construit des interfaces dont on répond. C'est le deuxième des quatre principes du Data Mesh.

Le Data Product Canvas, gratuit et open source, sert à le concevoir sur le papier, en atelier avec des personnes, en partant du cas d'usage. Simon appelle le canvas terminé l'« acte de naissance » du produit.

Architecte logiciel dans l'âme, il voit aussi le produit de données comme une unité d'architecture : il reçoit des choses par ses Input Ports, en fait beaucoup à l'intérieur et expose des résultats par ses Output Ports. Dans la démo d'ouverture, il n'avait spécifié que l'Output Port et la boîte, avant de lâcher l'agent de code dessus.

Et qu'est-ce qu'un standard ?

Le xkcd obligatoire résume tout. On a besoin de standards pour se mettre d'accord et réduire la complexité : le seul format de date correct, c'est le standard ISO, et tout le reste est faux. Pareil pour le décompte avant un départ, « 3, 2, 1, partez », pour que personne ne se demande si l'action commence sur le « un » ou après.

Et le risque obligatoire : il existe 14 standards, un gros acteur veut sa part, et en voilà 15. Cela arrive partout, y compris dans le monde de la data. Utile quand cela réduit la complexité, pénible quand cela ne fait qu'ajouter un prétendant de plus.

Ce qui fait un bon standard

Simon expose quatre dimensions, et il veut à chaque fois le côté gauche :

• De facto ou de jure (usage) : si tout le monde l'utilise, c'est un standard dans les faits, même si aucun organisme ne l'a décrété.
• Initiative ou éditeur (propriétaire) : mieux vaut une initiative derrière le standard, pour que le pouvoir ne soit pas entre les mains d'une seule entreprise qui le contrôle entièrement.
• Plusieurs ou un seul (contrôle) : le pouvoir est-il réparti entre les contributeurs, ou détenu par une seule partie ?
• Ouvert ou payant (coût) : tout le monde peut-il le lire et l'adopter, ou faut-il payer un organisme rien que pour lire la spec ?

Les standards sur lesquels il vaut la peine de parier penchent à gauche sur les quatre : utilisés sur le terrain, portés par une communauté, gouvernés largement et ouverts.

Une carte des standards ouverts

Les standards sont partout dans un produit de données : pour le décrire, pour lire d'autres produits, pour le traitement, le stockage, l'ordonnancement, la supervision, l'observabilité. Pour voir tout le paysage d'un coup, Simon maintient data-landscape.com, une carte interactive et assumée des standards de données et de métadonnées, qu'il classe en adopter, selon le contexte, évaluer ou prudence.

Pour cette conférence, il se concentre sur trois standards dont il est personnellement proche et dont il peut parler honnêtement : ODCS, ODPS et OSI. Les autres, il ne les connaît que de l'extérieur.

Qu'est-ce qu'un Data Contract ?

Un Data Contract existe pour construire la confiance. Un producteur propose des données, un consommateur veut les utiliser, et le contrat entre les deux porte les promesses et les garanties du producteur sur ce jeu de données (qui peut compter plusieurs tables). Il couvre la structure, la sémantique, la propriété, la qualité et les conditions d'utilisation.

Le besoin de Data Contracts est apparu en parallèle dans beaucoup d'entreprises il y a quelques années. Chacun a construit son propre format en YAML, JSON, Excel, Word ou Confluence, mais le problème de fond était toujours le même : capturer les garanties qu'un fournisseur donne sur une offre de données. (Pour aller plus loin : Qu'est-ce qu'un Data Contract ?)

La grande fusion des formats

Voici l'histoire. PayPal a publié son format de Data Contract en open source, en version 2.2, et l'a donné à la Linux Foundation. L'entreprise de Simon avait elle aussi un format concurrent, comme beaucoup d'autres. Il a rejoint l'effort de standardisation, et le groupe a retravaillé la version de PayPal (calibrée pour une seule plateforme de données, parce que tout le monde n'est pas PayPal et ne tourne pas uniquement sur BigQuery) pour qu'elle convienne à n'importe quelle entreprise.

Avec la version 3.1, ils ont fusionné les deux lignées et abandonné la leur, parce qu'un standard fort vaut mieux que deux standards concurrents. ODCS 3.2 arrive bientôt. La leçon : plutôt que d'en faire 15 standards, les camps se sont réunis en un seul, gouverné chez Bitol.

Dans les entrailles de l'Open Data Contract Standard

ODCS v3 porte les informations de schéma, la qualité des données, la tarification (elle est bien dans le standard, même si Simon n'a jamais vu personne s'en servir, une discussion académique amusante), la propriété et l'équipe, la sécurité, les accords de niveau de service, l'infrastructure et bien plus encore. Tout est lisible sur datacontract.com.

La partie intéressante, c'est le schéma : il stocke la classification des données et les marqueurs PII, des valeurs d'exemple et des contrôles de qualité des données en ligne. Un contrôle peut imposer un ensemble de valeurs valides ; un autre peut être du SQL brut exécuté comme contrôle qualité conforme au standard. Vous pouvez aussi consigner qui possède le produit et comment le contacter, les conditions d'utilisation (ce que vous avez le droit de faire ou non avec les données, avec des liens vers une politique de confidentialité ou une licence pour des données achetées), et des SLA comme la rétention et la fraîcheur.

Et il indique où vivent les données. Dans l'exemple, c'est Postgres sur Supabase, et depuis ODCS 3.2, il existe aussi un emplacement Hana. (Pour le contexte : Open Data Contract Standard.)

Et maintenant ? Tout automatiser

Pourquoi le standard en valait-il la peine ? Parce que vous n'avez pas à inventer le format, et que vous pouvez y accrocher de la logique. Ce sont les meilleures métadonnées que vous puissiez avoir sur un jeu de données, plaide Simon, et on ne fait pas mieux, surtout quand vous les reliez en plus à une ontologie. Dès qu'un contrat est lisible par la machine, il pilote le reste :

• Génération de code : Java, Pydantic, modèles dbt, DDL SQL
• Tests : vérifier les données sur Hana ou n'importe quel autre système par rapport au contrat, à chaque étape du cycle de vie, avec en plus la détection des breaking changes et la supervision
• Diffusion des métadonnées : pousser vers les metastores, les catalogues de données et les marketplaces
• Provisionnement d'infrastructure : Output Ports, Input Ports, anonymisation, contrôle d'accès
• Collaboration et gouvernance : conventions de nommage, évolution de schéma, accords d'utilisation, workflows d'approbation

Les humains peuvent s'en servir, les systèmes déterministes aussi, et les agents également, ce que fait précisément celui qui construit en arrière-plan en ce moment même.

Un standard ouvert appelle un outillage ouvert

Un standard ouvert permet de construire un outillage ouvert qui travaille main dans la main avec lui : adopter le standard vous donne l'automatisation presque gratuitement. La Data Contract CLI open source (environ 900 étoiles GitHub) lit le YAML, se connecte à tous les fournisseurs de données habituels, exécute les contrôles et vous rend un rapport de test que vous pouvez emporter partout. Elle fait aussi de l'import et de l'export, pour arriver vite à un contrat et continuer à travailler à partir de lui.

Le standard et l'outillage sont étroitement liés. Le graphique d'historique des étoiles montre les deux qui grimpent ensemble vers 1 000 : la CLI a mené la course longtemps, aidée par une réécriture de Go vers Python (le monde de la data vit en Python), tandis que le standard décolle en crosse de hockey à la fin. Un standard sans outillage ne vaut rien au début, puisqu'il faut tout construire soi-même ; donnez l'automatisation gratuitement et le standard s'installe.

Un éditeur, et l'inévitable Excel

Comme tout le monde ne parle pas couramment YAML, il existe aussi un Data Contract Editor open source, avec une vue formulaire, une vue YAML avec aperçu en direct et une vue diagramme qui fonctionne comme un outil de modélisation de données.

Et l'inévitable Excel. Simon espérait y échapper, mais la réalité montrait sans cesse des entreprises qui bricolaient leurs propres tableurs pour saisir des contrats ODCS. L'équipe en a donc construit un, avec conversion automatique d'Excel vers YAML. Il a rencontré un immense succès. Pariez sur le standard et vous obtenez l'éditeur, le modèle Excel et l'automatisation par la CLI dans le même paquet. Si vous voulez que les standards ouverts l'emportent, mettez la main à la pâte sur les outils, car c'est ce qui crée l'adoption, et c'est l'adoption qui pousse les éditeurs à les prendre en charge à leur tour.

L'Open Data Product Standard

Les Data Contracts ne parlent pas de produits de données ; un contrat, c'est vraiment l'interface, le jeu de données que vous partagez. Un produit de données, pour Simon, peut exposer plusieurs contrats sur plusieurs plateformes à la fois, et il existe un standard qui lui va bien : ODPS.

Un produit de données pointe vers un contrat pour chaque Output Port (ce qu'il partage) et pour chaque Input Port (ce dont il dépend). Dans l'exemple, un produit Orders a quatre Output Ports : les commandes en version 1 et en version 2, plus leurs variantes sans PII, parce que des données sans information personnelle sont bien plus faciles à consommer, tandis que les ports sensibles passent par un processus d'approbation manuel qui peut prendre des semaines. Un Input Port référence un topic Kafka qu'un pipeline transforme en offre.

Comme les ports pointent vers des contrats, vous obtenez un data lineage au niveau des produits : un service de commandes alimente le produit Orders, qui alimente d'autres consommateurs. (À lire : Qu'est-ce qu'un produit de données ?)

Ce qui arrive chez Bitol

Un rapide vote à main levée : environ 10 % de la salle utilise déjà ODCS. ODCS 3.2 sort bientôt, ODPS 1.1 arrive, et le groupe de travail rédige d'autres standards autour de l'observabilité, des domaines de données, des accords d'accès et de l'orchestration.

Cela prend du temps, remarque Simon. Le comité ne se réunit pas souvent, et chacun fait cela en plus du travail qui paie réellement les factures.

Attention : deux choses s'appellent ODPS

Attention à la confusion : il existe deux standards nommés ODPS, tous deux à la Linux Foundation. L'un fait partie de la famille Bitol, fonctionne bien avec ODCS grâce aux Input Ports et peut référencer plusieurs contrats. L'autre est indépendant, n'a pas de notion d'Input Port et ne se rattache qu'à un seul ODCS.

Ils incarnent des visions réellement différentes de ce qu'est un produit de données. Celui de Bitol est plus faible sur la tarification et l'internationalisation ; l'autre est solide sur les plans tarifaires et l'i18n. L'un s'appelle le Standard, l'autre la Specification. C'est, reconnaît Simon, vraiment désolant.

Open Semantic Interchange

Les produits de données atterrissent dans une marketplace, c'est là que les agents vont demander ce qui existe ; cette couche a donc besoin de standards elle aussi, sinon on retombe dans les formats de métadonnées propriétaires. Le troisième standard porte sur la sémantique : que veulent dire les données ? Open Semantic Interchange (OSI), fortement poussé par Snowflake, est parti du modèle sémantique classique : jeux de données, relations et, surtout, métriques. Vos données sont déjà dans Snowflake, Databricks, Oracle ou SAP, et vous posez une couche sémantique par-dessus.

Ce qui frappe, c'est à quel point le format est pensé pour l'IA d'abord. Il porte des instructions, des synonymes et des exemples : les remplir améliore nettement le travail des agents. Donnez des instructions à vos métadonnées, et les agents en feront plus. Pour le reste, cela ressemble beaucoup à un contrat : vous décrivez des jeux de données, des relations et désormais des métriques, par exemple total_revenue comme la somme des montants de commande, ou full_name comme le prénom, un espace, puis le nom.

Et, comme partout, il existe de l'outillage open source, dont un éditeur pour le modéliser. (Pour aller plus loin : Sémantique.)

Les standards apprennent les uns des autres

ODCS et OSI sont en fait assez proches. La comparaison montre où chacun a de l'avance : OSI mène sur les métriques, les champs dynamiques et le contexte IA, tandis qu'ODCS couvre les conditions d'utilisation, la qualité et les SLA.

Les écarts se comblent au fil des comités. Le contexte IA arrive dans ODCS 3.2, avec les champs dynamiques et les métriques comme l'exemple full_name. Les standards se rapprochent et apprennent les uns des autres, ce qui est plutôt agréable à observer.

Ontologies, et un renommage en Apache Ossie

OSI compte de nombreux groupes de travail, dont un particulièrement actif sur les ontologies, que Simon apprécie beaucoup. Tout cela est encore très jeune (version 0.2.0.dev), mais fortement soutenu par Snowflake. Vous pouvez modéliser une ontologie de concepts et de relations, avec internationalisation, et relier une colonne de contrat à un concept.

Un clin d'œil aux informaticiens : baptiser son initiative « OSI » alors qu'un célèbre modèle réseau porte déjà ce nom, c'est gonflé. Ils semblent d'accord, puisque pas plus tard qu'hier, ils ont apporté l'initiative à la Fondation Apache et l'ont renommée Apache Ossie. Beaucoup d'éditeurs sont derrière, Entropy Data compris : le format arrive.

Le futur, c'est maintenant

Retour à l'agent qui tournait en arrière-plan. Il lui a fallu 17 minutes et 57 secondes, et c'est terminé. Le prompt lancé disait simplement « implémente le produit de données », et Simon n'avait écrit que ce qu'il voulait.

Le résultat est un projet dbt complet, avec des modèles d'entrée, de sortie et intermédiaires. Tout seul, l'agent a découvert qu'il avait besoin de données provenant de trois autres produits de données (que Simon n'avait jamais indiqués), a récupéré leurs descriptions ODPS et leurs contrats ODCS, a évalué ceux dont il avait besoin, a demandé les accès, puis a construit et exécuté le pipeline. La marketplace montre désormais le nouveau produit relié à ces trois sources amont, avec des traces OpenLineage et un data lineage au niveau des colonnes.

Pourquoi ça marche ? Grâce aux standards ouverts. Le contrat et le produit sont décrits dans des formats standards, l'agent dialogue avec la marketplace et les outils via MCP, il utilise la Data Contract CLI en interne pour vérifier sa sortie par rapport au contrat, et un dépôt de skills encode la façon dont cette entreprise construit ses produits de données (Snowflake, dbt, OpenLineage). Chaque boîte du slide d'ouverture est aujourd'hui un vrai standard ouvert, et c'est l'agent qui a tapé le code.

Écrivons l'histoire

Voilà la partie que la salle peut faire ensemble. Juste avant la conférence, l'Open Data Contract Standard en était à 978 étoiles GitHub. À 1 000, il atteint le niveau suivant et peut passer en graduation au sein de la Linux Foundation. C'est donc votre chance : 22 étoiles, on peut sûrement y arriver.

Et la salle l'a fait. Les téléphones sont sortis, le compteur est monté en direct, 998, puis la barre a été franchie.

Nous l'avons vraiment fait. En moins de cinq minutes, la communauté Bitol a fait passer l'Open Data Contract Standard de 978 à plus de 1 000 étoiles GitHub, en direct dans la salle. Le seuil est franchi pour qu'ODCS passe en graduation au sein de la Linux Foundation. Merci à toutes les personnes qui ont scanné le QR code et donné une étoile. Ensemble, nous pouvons déplacer des montagnes.

Si ces standards vous sont utiles, donnez une étoile au dépôt ODCS et aidez-le à continuer de grandir.