Data Architecture: The New Backbone of Modern Software

Deux intervenants

Gernot Starke est INNOQ Fellow, cofondateur et mainteneur d'arc42, cofondateur d'aim42 et de l'iSAQB. Il fait de l'architecture logicielle depuis très longtemps, et les données en ont toujours fait partie, y compris à l'époque où le reste de la profession avait cessé d'en parler.

Simon Harrer est product engineer dans l'âme, coauteur de « Java by Comparison » et de « Remote Mob Programming », et cotraducteur en allemand du « Data Mesh » de Zhamak Dehghani. Après des années chez INNOQ, il a cofondé Entropy Data en 2025, sous forme de spin-off. Il comaintient le Data Contract CLI et le Data Contract Editor, et siège au TSC de BITOL, le projet Linux Foundation dédié aux standards ouverts de Data Contracts et de produits de données.

Données ou information ?

Tout le monde en informatique connaît la différence, mais elle mérite d'être redite. Les données, c'est le tas de briques Lego en vrac au fond du tiroir : des symboles isolés qui ne veulent rien dire tout seuls. 42 ou 07.05.2026, ce n'est qu'une valeur.

L'information, c'est la donnée remise en contexte, avec de la sémantique. « La température est de 42 °C » ou « conférence le 2026-05-07 », là on peut agir. Toute l'histoire de l'architecture de données consiste à transformer la première en la seconde.

De la mémoire à tores aux disquettes

Côté informatique, tout commence dans les années 1950 avec la mémoire à tores de ferrite : de minuscules anneaux enfilés sur des fils, qu'on aimantait dans un sens ou dans l'autre pour stocker un bit. Rien à voir avec le nucléaire, malgré le nom allemand « Kernspeicher », et quasiment personne dans la salle n'en avait jamais eu une entre les mains.

En 1956, IBM livre le premier disque dur : une pile de plateaux magnétiques, 5 mégaoctets, et près d'une tonne. Dans les années 1970, on réquisitionne la cassette audio comme support de données : 300 à 400 kilooctets par face, soit aujourd'hui à peu près la moitié d'une icône d'application.

Viennent ensuite les disquettes 8, 5,25 et 3,5 pouces : souples, sensibles à la poussière, et pratiquement vides. 80 ko sur les premières, jusqu'à 2880 ko sur les toutes dernières. Des « porteurs de données », au sens le plus littéral du terme.

Du gigaoctet à l'ångström

Dans les années 2000, les disques grand public se comptent en dizaines de gigaoctets ; à partir de 2010, les SSD font passer le même format au téraoctet. Les disques de datacenter d'aujourd'hui affichent 24 To, et ce n'est pas fini. Ironie de l'histoire, ils sont aussi devenus difficiles à acheter : ils partent tous chez les hyperscalers.

Le plus fascinant, c'est ce que l'industrie du stockage est devenue en silence : dans une vidéo Seagate que Gernot a projetée, on voit des têtes de lecture-écriture voler au-dessus du plateau avec des tolérances de l'ordre de l'ångström, c'est-à-dire à l'échelle moléculaire. Les fabricants de disques durs travaillent avec la même précision que les machines de gravure d'ASML. Quatre minutes de vidéo qui valent le détour.

Le commerce, premier cas d'usage des données

Consigner les choses est un besoin fondamental des civilisations depuis toujours. Le commerce en est le bon exemple. Les bâtisseurs de pyramides égyptiens tenaient déjà des listes de transactions. Les marchands du Moyen Âge notaient leurs achats et leurs ventes à la plume dorée.

Puis quelqu'un a inventé la comptabilité en partie double : doubler délibérément le volume de données à tenir, pour réduire les erreurs. C'est au fond un dispositif de qualité de données. (Spoiler : l'idée va revenir.)

Aujourd'hui, dans un groupe de distribution, la donnée est l'or. C'est elle qui permet de négocier de meilleures conditions d'achat, de répartir les stocks entre les magasins, de personnaliser les offres. Vous pouvez avoir des algorithmes brillants, des tableaux de bord soignés et les meilleurs modèles de ML du monde : si les données qui les alimentent sont médiocres, ce que le manager récupère à l'autre bout l'est tout autant.

Défi n° 1 : le génie logiciel a oublié les données

La thèse est volontairement provocatrice : entre 1995 et 2020, le génie logiciel a largement oublié les données. On avait la tête ailleurs.

Vers 1995, C++ se généralise, Java débarque, et tout le monde apprend l'objet : héritage, méthodes, couplage et cohésion. Le versant fonctionnel du logiciel. Dans les années 1980, on parlait encore couramment de « modèle de données » ; à la fin des années 1990, le terme était presque devenu un gros mot. Puis la SOA. Puis l'agilité et Scrum (le mot « données » n'apparaît nulle part dans le Scrum Guide). Puis les microservices. Tout cela centré sur le comportement, jamais sur la forme des données qui circulaient.

Gernot reconnaît volontiers qu'il était en plein dedans. Complice, dit-il. Il ne s'agit pas de s'excuser, mais de prendre la mesure du trou dont nous sommes en train de remonter.

Défi n° 2 : les données, seul actif sans propriétaire

Dans une entreprise, tous les autres actifs ont un propriétaire. Les données, traditionnellement, non. Ou plutôt : tout le monde s'estime propriétaire, ce qui revient au même problème sous une autre forme.

L'exemple préféré de Gernot vient d'un assureur chez qui il travaillait au moment de la mise en place du RGPD. La maison avait une joyeuse convention d'« adresse pour tous » : dès que quelqu'un manifestait de l'intérêt pour un produit, son adresse était transmise à tous les destinataires internes susceptibles d'en vouloir. Puis le RGPD arrive, « Sylvia » demande la suppression de ses données, et personne ne peut dire honnêtement où elles ont atterri. Personne n'était propriétaire du fichier d'adresses.

Il appelle l'état qui en résulte, avec son mot allemand, du « Wildwuchs » : une prolifération sauvage. Il y a des données en pagaille, mais personne ne sait quelle copie fait foi, si elle est encore valide, ni si elle a le bon nombre de décimales.

Défi n° 3 : de jolies images posées sur un marécage

Les data warehouses classiques produisent de très beaux rapports. Le problème, c'est qu'ils arrivent souvent trop tard et reposent sur de mauvaises données. Gernot a assisté à quantité de réunions où quelqu'un sortait un fichier Excel d'un autre âge en lâchant : « tiens, moi je n'ai pas les mêmes chiffres ».

C'est du shadow IT, et il apparaît exactement là où la tuyauterie centrale a laissé les gens sur le carreau. Les data lakes ont hérité du même problème, à plus grande échelle : on déverse tout dedans en espérant qu'il en sorte quelque chose de bon. L'espoir est une belle chose, mais une piètre stratégie de données.

La vague de l'IA a rendu la chose impossible à ignorer. Dès qu'une entreprise a voulu affiner son propre modèle et s'est mise en quête de données d'entraînement, la réponse a généralement été : nous avons beaucoup de données, mais aucune idée de celles qui sont justes. Un modèle entraîné sur un marécage n'est pas intelligent. C'est un marécage.

Nous avons déjà résolu ce problème

On a déjà connu ce genre de pagaille. Le « chaos des services » des années 2000 y ressemblait beaucoup : SOAP/WSDL était lourd, REST était léger mais sans contrat, la documentation vivait dans Confluence quand elle existait, et l'ESB faisait goulot d'étranglement. Personne ne savait vraiment quels services l'entreprise possédait.

Ce qui nous en a sortis, c'est Swagger puis OpenAPI. Un format texte, lisible par la machine et neutre vis-à-vis des éditeurs. Dix lignes de YAML suffisent pour démarrer. Swagger UI donne un bénéfice immédiat. Comme le dit Gernot, qui pèse ses mots, ça a vraiment changé la donne dans la façon dont les équipes produisent et consomment des services.

Il faut maintenant faire passer la même idée dans le monde des données.

Toute entreprise a déjà des API de données

REST a OpenAPI. Les messages et les événements ont AsyncAPI. Et les jeux de données partagés ?

Parce qu'en vérité, toute entreprise possède déjà des dizaines d'« API de données ». Simplement, elles n'y ressemblent pas. Elles ressemblent plutôt à ceci :

• des CSV sur un SFTP
• des fichiers JSON sur S3
• des tables SQL sur BigQuery ou Snowflake
• des fichiers Iceberg sur Azure One Lake
• des Delta Live Tables sur Databricks
• des fichiers Excel sur SharePoint

Une équipe produit, d'autres consomment. Tableaux de bord, rapports pour le comité de direction, entraînement de modèles, pipelines en aval : tout repose sur la stabilité et la qualité de ces interfaces. Et le jour où le pipeline producteur change discrètement un en-tête de CSV ou vide une colonne, le tableau de bord affiche simplement un autre chiffre. Aucune erreur, aucune alerte : le pire mode de défaillance possible.

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é et les conditions d'utilisation des données échangées entre un producteur et ses consommateurs. Pensez à une spécification d'API, mais pour les données.

Le producteur est propriétaire du contrat et y déclare ses garanties. Le consommateur le lit et s'y fie. Sans contrat, il ne lui reste qu'à rétro-concevoir le schéma en scrutant quelques lignes d'exemple, en devinant que OID2 est le numéro de commande alors que ce peut être tout autre chose. Ces contresens silencieux sont très difficiles à détecter.

Du bricolage maison au standard

Quand le besoin est apparu, chaque entreprise a inventé son propre format. Du YAML ici, du JSON là, de l'Excel, parfois même des documents Word. Tous cherchaient à encoder la même chose : que signifie chaque champ, quelle est sa qualité, quel est le SLA, quelles sont les conditions d'utilisation.

PayPal a ouvert son template interne et l'a donné à la Linux Foundation sous le nom d'ODCS 2.2. Simon a rejoint le TSC et aidé à en retirer les spécificités PayPal pour que n'importe quelle entreprise puisse l'utiliser. ODCS 3.0, publié en 2025, est la première version réellement neutre.

Le standard vit désormais chez BITOL, le projet Linux Foundation dédié aux standards ouverts de Data Contracts et de produits de données, avec un bon équilibre entre utilisateurs finaux, consultants et éditeurs au sein du comité. C'est ce type de gouvernance qui fait du mot « standard » autre chose qu'un argument marketing.

Ce que contient un contrat ODCS

Un seul fichier YAML rassemble tout ce dont un consommateur a besoin :

• Fondamentaux : id, nom, version, statut (pour le cycle de vie).
• Schéma : tables et colonnes avec types logiques et physiques, clés primaires et étrangères, noms métier (« Customer Identifier »), classifications, étiquettes PII.
• Qualité des données : énumérations (order_status ∈ {pending, shipped, cancelled}) ou SQL libre (« le nombre de lignes doit dépasser 100 000 »). Point crucial, tout s'exprime en pourcentages plutôt qu'en obligatoire/facultatif strict : les données réelles sont imparfaites et un modèle de ML fonctionne très bien avec 99 % de complétude.
• Équipe et support : propriétaires, canaux Slack, outils de ticketing.
• Conditions d'utilisation : ce que les consommateurs ont le droit de faire ou non avec les données (portée géographique, garanties d'absence de PII, limitation de finalité).
• SLA : disponibilité, rétention, fraîcheur, latence. Dans le monde des données, la latence et la fraîcheur comptent bien plus que la disponibilité de la plateforme (Databricks, Snowflake ou BigQuery sont simplement là).
• Servers : l'endroit où les données résident réellement, pour qu'un consommateur autorisé puisse s'y connecter directement.

« Rendre la propriété explicite, voilà le grand pas. Tant que c'était implicite, les producteurs pensaient que la structure et la sémantique devaient évoluer, et les consommateurs supposaient qu'elles resteraient figées pour toujours. C'est ce malentendu qui casse les pipelines. »

Tout automatiser

Dès lors qu'un contrat est du YAML, on peut en faire beaucoup : générer du Java, du Pydantic, des modèles dbt ou du DDL SQL, le confronter aux données réelles, faire échouer une pull request en cas de changement cassant, surveiller en continu en production, pousser les métadonnées vers des catalogues (Colibra), des marketplaces (Entropy Data) et des catalogues applicatifs (LeanIX).

Le Data Contract CLI open source fait le gros du travail : imports depuis SQL DDL, JSON Schema, Iceberg, Protobuf, BigQuery, Unity Catalog, AWS Glue et Excel ; exports vers SQL DDL, HTML, dbt, Entropy Data, Avro, SodaCL, Pydantic et Excel ; tests sur AWS S3, BigQuery, Azure, Databricks, Snowflake et Kafka.

« Avant, les contrôles de qualité étaient des invariants enfouis dans notre code. Maintenant ils vivent à côté des données, dans le contrat, et ils tournent en continu. »

L'outillage compte plus que le standard

Si l'on regarde les étoiles GitHub, le Data Contract CLI est plus populaire que la spécification ODCS elle-même. C'est de nouveau la leçon d'OpenAPI : un standard ouvert a besoin d'un bon outillage open source pour être adopté.

C'est le standard qui vous offre cet outillage gratuitement, qui évite l'enfermement propriétaire dès que plusieurs outils parlent le même format, et qui fait que les équipes s'entraident au lieu de réinventer dix fois le même YAML avec dix variantes.

Des éditeurs pour les humains (et pour le métier)

Écrire du YAML à la main est fastidieux, alors nous avons construit un Data Contract Editor open source. Vue diagramme, vue formulaire, vue YAML brut, avec aperçu et validation. Il est intégré au CLI : pendant que vous éditez, vous pouvez relancer les tests sur les données et vérifier que le contrat tient toujours.

Pour les collègues qui n'ont aucune envie d'apprendre un nouvel outil, il existe aussi un modèle Excel ODCS. Le CLI le convertit en YAML. Ce n'est pas beau, mais c'est pratique, et Excel n'est pas près de disparaître.

Démo live : l'éditeur et le CLI sur une vraie base

L'éditeur, sur editor.datacontract.com, affiche un contrat orders et line_items sous forme de diagramme, avec la clé étrangère qui les relie. Chaque champ a son type logique et son type physique, des exemples (« C-10000001 »), des classifications (internal, PII) et une description compréhensible par le métier (SKU → Stockkeeping Unit).

L'éditeur est branché sur une base Postgres hébergée chez Supabase. Un clic sur Run Test déclenche des sondes SQL via le CLI et renvoie un rapport tout vert : chaque champ du schéma attendu est présent et bien typé, order_status ne contient aucune valeur invalide, et le nombre de lignes dépasse largement le minimum de 100 000 exigé par le contrat.

Tout ce que vous savez exprimer en SQL devient un contrôle de qualité. Tout ce que vous savez exprimer devient un test continu.

Où les Data Contracts s'inscrivent dans le tableau d'ensemble

Les Data Contracts s'accordent naturellement avec le Data Mesh : propriété par domaine, données comme produit, plateforme en self-service, gouvernance fédérée. Les équipes de domaine construisent des produits de données qui consomment les contrats d'autres produits de données et en exposent de nouveaux. C'est la logique d'API que nous appliquons déjà aux services, avec la même pensée produit, la même pensée plateforme et la même gouvernance, transposée aux données.

Vous n'avez pas besoin de mettre en place un Data Mesh pour utiliser des Data Contracts. Le minimum, c'est deux équipes : une qui produit les données, une qui les consomme. Le Mesh se marie très bien avec, mais ce n'est pas un prérequis.

La vraie raison pour laquelle les Data Contracts vont s'imposer : les agents IA

Le codage agentique n'est que la petite partie visible. Le vrai enjeu, ce sont les agents qui dialoguent avec les données de l'entreprise. Or un agent ne sait pas nativement ce que veulent dire vos tables, à quel point les données sont fraîches, s'il a le droit de s'en servir pour du marketing, ni comment demander un accès.

Le contrat lui donne tout cela : sémantique, conditions d'utilisation, accès, qualité, SLA. Souvenez-vous de la diapositive sur données et information : le contrat est précisément la couche qui transforme la donnée brute en information sur laquelle un agent peut raisonner.

Sans contrat, les agents finissent par deviner, et joignent les mauvaises colonnes avec beaucoup d'assurance. Avec des contrats, ils disposent de métadonnées solides sur lesquelles s'appuyer. C'est là tout le pari.

Démo live : un agent posé sur la couche contractuelle

Même montage, un étage au-dessus. Un agent (Claude Opus) est branché au serveur MCP d'Entropy Data, qui expose la marketplace de données : des produits de données consultables, chacun accompagné de son contrat ODCS.

Un utilisateur métier pose sa question en allemand : « Wer sind meine Top-Kunden ? » (« qui sont mes meilleurs clients ? »). L'agent parcourt l'offre de données à partir des métadonnées des contrats, choisit le produit de données capable de répondre, vérifie que l'accès existe (et déposerait automatiquement une demande dans le cas contraire), exécute du SQL et renvoie un top 10 : nom, chiffre d'affaires, catégorie de produits préférée, moyen de paiement. Puis vient une relance, « und für welche Produkte ? » (« et pour quels produits ? »), et il poursuit, en disant franchement ce qu'il a trouvé et ce qu'il n'a pas trouvé.

L'important n'est pas que l'agent soit malin. L'important, c'est ce que le contrat rend possible : des utilisateurs métier qui formulent directement leurs hypothèses, au lieu d'ouvrir un ticket et d'attendre des semaines qu'une équipe data leur construise un cube.

La prédiction

Swagger 1.0 est arrivé en 2011. Au début, il n'avait même pas de schémas, seulement des endpoints. Aujourd'hui, chaque API REST que vous croisez a sa spécification OpenAPI.

ODCS 3.0, la première version réellement neutre, est sorti en 2025. Le pari : dans cinq ans, il occupera la place qu'OpenAPI occupe aujourd'hui. Les choses vont plus vite qu'en 2011.

Le ticket d'entrée est modeste : n'importe quel éditeur de texte, dix lignes de YAML et le CLI open source suffisent à valider la pertinence sur votre propre cas d'usage. Autant être proactif plutôt que réactif.