Carnets

Data contract et ODCS

7 min de lecture

Data contract et ODCS

Résumé

Un data contract est un accord écrit entre le producteur d’un jeu de données et ses consommateurs : ce qu’il contient (schéma), ce qui est garanti (qualité), et à quel niveau de service (fraîcheur, disponibilité). L’Open Data Contract Standard (ODCS) en fixe le format : un fichier YAML, indépendant de la plateforme, dont les clés sont définies. Le contrat est le complément écrit et vérifiable du Data product : l’un décrit l’engagement, l’autre l’unité qui le porte.

Prérequis

Data product pour le contexte, et dbt — Fondamentaux pour la notion de test. Le YAML ci-dessous suit la version 3.2.0 de la documentation consultée le 24 octobre 2026.

À quoi sert un contrat

Sans contrat, un changement du producteur (renommer une colonne, changer un type) casse les consommateurs sans prévenir, et personne ne sait qui contacter ni quelle fraîcheur attendre. Le contrat rend l’attente explicite et vérifiable : on le versionne, on le teste, et on le fait évoluer avec un processus.

Ce que contient un contrat ODCS

La documentation décrit un fichier YAML organisé en 15 sections :1

SectionContenu
FundamentalsIdentité du contrat : version du standard, nature, identifiant, nom, version, statut, domaine, description
SchemaLes objets (tables, documents) et leurs propriétés (colonnes, champs)
ContextContexte d’utilisation
ReferencesRéférences stables entre éléments
Data QualityRègles de qualité
Support & Communication ChannelsOù poser une question
PricingCoût d’accès
TeamÉquipe responsable
RolesRôles d’accès
Service-Level AgreementEngagements de service
Infrastructures & ServersOù se trouve la donnée
Custom & Other PropertiesExtensions
Authoritative DefinitionsLiens vers les définitions de référence
TagsÉtiquettes
VariablesParamètres

Les clés obligatoires de la section Fundamentals sont apiVersion (version du standard), kind (valeur DataContract), id (identifiant unique, par exemple un UUID) et version (version du contrat). Le statut (status) prend des valeurs comme proposed, draft, active, deprecated, retired.2

Schéma

Le schéma utilise un vocabulaire à trois niveaux : des objets (une table, un document), des propriétés (une colonne, un champ) et des éléments (un objet ou une propriété). Chaque élément a un type logique (logicalType, la nature métier) et un type physique (physicalType, la représentation dans le système). Cela permet de relier la description métier à l’implémentation.3

Qualité

Les règles de qualité existent à quatre niveaux :4

NiveauDescription
textPhrase lisible par un humain, à traduire plus tard en vérification exécutable
libraryMétriques prédéfinies (par exemple rowCount, nullValues, invalidValues), pensées pour être compatibles avec les moteurs de qualité courants
sqlUne requête SQL qui renvoie une valeur à comparer
customRègles propres à un outil (Soda, Great Expectations, tests dbt, Monte Carlo, etc.)

Niveaux de service

La section SLA liste des propriétés comme la latence, la fréquence, la rétention, l’heure de disponibilité, la date de fin de support, chacune avec une valeur, une unité, l’élément concerné et un « pilote » (réglementaire, analytique, opérationnel).5

Un exemple

Contrat pour la table orders du domaine ventes. Il est construit à partir des clés documentées ; à valider contre le schéma JSON officiel avant usage.

apiVersion: v3.2.0
kind: DataContract
id: 7c1f6d52-3a8e-4b6c-9d6a-0e1b2a3c4d5e
name: ventes_orders
version: 1.0.0
status: active
domain: ventes
description:
  purpose: Commandes validées, une ligne par commande.
  limitations: Ne contient pas les commandes annulées avant paiement.
  usage: Analyse du chiffre d'affaires et des délais de livraison.
tags: ['ventes']
 
schema:
  - name: orders
    logicalType: object
    physicalType: table
    description: Une ligne par commande validée.
    properties:
      - name: order_id
        logicalType: string
        physicalType: STRING
        primaryKey: true
        quality:
          - type: library
            metric: nullValues
            mustBe: 0
            description: Aucune commande sans identifiant.
      - name: order_date
        logicalType: date
        physicalType: DATE
        partitioned: true
      - name: amount
        logicalType: number
        physicalType: NUMERIC
        description: Montant TTC en euros.
 
slaProperties:
  - property: frequency
    value: 1
    unit: d
    element: orders.order_date
  - property: timeOfAvailability
    value: 08:00+01:00
    element: orders.order_date
    driver: analytics

Le fichier ne vérifie rien à lui seul

Un contrat est une description. Il devient un contrat quand un outil le vérifie à chaque livraison (schéma conforme, règles de qualité respectées, SLA tenus) et que sa violation déclenche une action. Sinon, c’est de la documentation.

Contrat de données, contrat dbt et tests dbt

Ce que dit la documentation dbt

Un contrat de modèle dbt est un ensemble de garanties sur la forme du jeu de résultats d’un modèle (colonnes, types) : dbt vérifie à la construction que le modèle produit bien un jeu de données conforme, sinon la construction échoue. Les fonctions de gouvernance de dbt sont propres aux modèles : elles ne s’appliquent pas aux snapshots, aux seeds ni aux sources, et ajoutent de la maintenance si on les adopte trop tôt. Le contenu des données (valeurs, seuils, fraîcheur) relève des tests et d’autres outils. L’ODCS englobe ces niveaux : il accepte notamment les tests dbt comme règles de qualité de niveau custom.6

En résumé : le contrat ODCS décrit l’engagement de bout en bout ; dbt est l’un des moyens de le faire respecter.

ODCS et ODPS

Deux standards complémentaires du même projet : l’ODCS décrit le contrat d’un jeu de données, l’ODPS (Data product) décrit le produit. Les schémas JSON publiés sont des compagnons des standards : en cas de conflit, c’est le standard qui prévaut.1 Une clé dataProduct existait dans l’ODCS ; elle est dépréciée depuis la version 3.1.0.2

Gouvernance du standard

Bitol, le projet qui porte l’ODCS, a obtenu le statut « Graduated » de la fondation LF AI & Data le 27 juillet 2026, annoncé le 28 (après le bac à sable en septembre 2023 et l’incubation en novembre 2024), d’après l’annonce du projet. Il est sous licence Apache 2.0.7 L’ODCS v3.2.0 et l’ODPS v1.1.0 ont été publiés ensemble le 8 septembre 2026.8

Mettre en place

  1. Commencer par un produit de données important et deux ou trois consommateurs.
  2. Écrire le contrat avec eux : schéma, deux ou trois règles de qualité, une fraîcheur.
  3. Brancher la vérification dans le pipeline (tests dbt, requêtes SQL du contrat, ou outil de qualité).
  4. Définir le processus de changement : qui prévient qui, avec quel préavis, comment on versionne (changement compatible ou non).
  5. Mesurer : combien de ruptures de contrat, combien d’incidents côté consommateurs.

Pratiques qui évitent qu’un contrat devienne obsolète

Un billet d’éditeur d’outils de gouvernance (donc un point de vue intéressé) en retient cinq, de bon sens et cohérentes avec ce qui précède :9

  • Versionner le contrat avec le code : un contrat dans un wiki dérive du pipeline qu’il décrit.
  • Vérifier à la revue de code, pas après le déploiement : bloquer un changement de schéma en revue coûte un commentaire, en production un incident.
  • Un propriétaire par contrat, plutôt que par équipe : l’attribution survit aux réorganisations.
  • Générer un premier brouillon à partir des schémas et de l’historique des requêtes pour les pipelines existants.
  • Traiter une violation comme un échec de build, pas comme une alerte qu’on trie plus tard.

La même source distingue l’application proactive (empêcher la violation, par exemple en analysant les changements de schéma en revue) de l’application réactive (surveiller la production), et conseille de commencer par les jeux de données les plus critiques.9

Un contrat n’est pas un catalogue de données : le catalogue documente les actifs après coup, le contrat est un accord préalable entre producteur et consommateur sur ce que sera la donnée et quand elle arrivera.9

Notes liées

Notes de bas de page

  1. Open Data Contract Standard, page d’accueil de la documentation, consultée le 24 octobre 2026. ↩ ↩2

  2. ODCS, Fundamentals. ↩ ↩2

  3. ODCS, Schema. ↩

  4. ODCS, Data Quality. ↩

  5. ODCS, Service-Level Agreement. ↩

  6. dbt, Model contracts, documentation officielle, consultée le 24 octobre 2026. ↩

  7. Bitol graduates, annonce de Jean-Georges Perrin, 28 juillet 2026 ; Bitol, page d’accueil (licence Apache 2.0), consultée le 24 octobre 2026. La page d’accueil porte encore la mention « projet en incubation ». ↩

  8. Data Contracts & Data Products for AI, Bitol, 8 septembre 2026. ↩

  9. Foundational, Data Contracts: Implementation and Best Practices Guide, billet d’éditeur non daté, consulté le 24 octobre 2026. Source secondaire à visée commerciale. ↩ ↩2 ↩3

Vue Graphique

Liens retour