Open Data Contract Standard

Deux spécifications dominent l’espace des data contracts : l’Open Data Contract Standard (ODCS) et le Data Contract Specification (datacontract.com). ODCS, maintenant à la version v3.1.0 sous le projet Bitol de la Linux Foundation, s’est imposé comme le standard de facto. Les deux sont ouverts, les deux utilisent YAML, et les équipes derrière eux travaillent activement à l’harmonisation.

Origines d’ODCS

ODCS a débuté comme le Data Contract Template interne de PayPal. PayPal utilisait des contracts basés sur YAML intégrés à leur implémentation Data Mesh pour gérer les accords de partage de données entre équipes. La spécification a été open-sourcée et donnée au projet Bitol de la Linux Foundation, où elle continue d’évoluer sous une gouvernance communautaire.

La progression d’un outil interne d’une seule entreprise vers un standard de la Linux Foundation reflète des patterns observés dans d’autres infrastructures de données (Apache Spark depuis AMPLab, Kubernetes depuis Google). Cela signale la maturité : la spécification ne dépend plus des priorités d’une seule organisation.

Ce que couvre ODCS

Un contract ODCS complet définit bien plus que des noms de colonnes et des types. La spécification couvre plusieurs dimensions :

Définition de schéma

La couche fondationnelle — quels champs existent, leurs types et contraintes structurelles :

schema:
  - name: payment_id
    logicalType: string
    physicalType: VARCHAR(36)
    isNullable: false
    isPrimaryKey: true
    description: "Unique payment identifier (UUID format)"
  - name: amount
    logicalType: decimal
    physicalType: NUMERIC(12,2)
    isNullable: false
    description: "Payment amount in the currency specified"
  - name: currency
    logicalType: string
    physicalType: VARCHAR(3)
    isNullable: false
    description: "ISO 4217 currency code"

La distinction dual logicalType / physicalType importe. Les types logiques sont agnostiques à la plateforme (string, decimal, timestamp). Les types physiques sont spécifiques à l’entrepôt (VARCHAR, NUMERIC, INT64). Cette séparation signifie qu’un seul contract peut décrire des données qui atterrissent dans BigQuery, Snowflake ou Redshift avec le mapping de types approprié.

Règles de qualité des données

Les contracts peuvent intégrer des attentes de qualité directement :

quality:
  - name: amount_is_positive
    type: custom
    dimension: accuracy
    rule: "amount > 0"
    severity: error
  - name: currency_is_valid
    type: custom
    dimension: validity
    rule: "currency IN ('USD', 'EUR', 'GBP', 'CAD', 'AUD')"
    severity: warning
  - name: null_rate_below_threshold
    type: custom
    dimension: completeness
    rule: "COUNT(CASE WHEN email IS NULL THEN 1 END) / COUNT(*) < 0.05"
    severity: warning

Ces règles sont déclaratives — elles décrivent ce qui doit être vrai, pas comment le vérifier. Les outils comme Soda ou Data Contract CLI les traduisent en vérifications exécutables contre les données réelles.

SLAs et garanties de livraison

slaProperties:
  - property: latency
    value: "4h"
    description: "Data available within 4 hours of event occurrence"
  - property: availability
    value: "99.9%"
    description: "Target uptime for the data product"
  - property: freshness
    value: "1h"
    description: "Maximum age of most recent record"

Les SLAs sont là où les contracts vont au-delà de ce que dbt gère. Un contract dbt peut faire respecter qu’un modèle a les bonnes colonnes et types. Il ne peut pas promettre que les données seront disponibles dans les quatre heures ou que le pipeline aura une disponibilité de 99,9%. Ces engagements nécessitent un soutien organisationnel, une infrastructure de monitoring et des processus de réponse aux incidents.

Propriété et gouvernance

team:
  - name: seller-platform
    role: producer
    contact: seller-platform@company.com
  - name: analytics-engineering
    role: consumer
    contact: analytics@company.com

contractCreatedTs: "2025-09-15T10:00:00Z"
contractStatus: active

Les métadonnées de propriété répondent à la question qui est sinon résolue par l’archéologie Slack : « à qui parler quand ces données sont cassées ? » Rendre la propriété explicite dans un format lisible par machine permet le routage automatisé des alertes de qualité des données vers la bonne équipe.

Propriétés personnalisées

ODCS supporte des propriétés personnalisées arbitraires pour les besoins spécifiques à l’organisation :

customProperties:
  - property: costCenter
    value: "SELLER-001"
  - property: gdprClassification
    value: "contains_pii"
  - property: retentionPeriod
    value: "7 years"

Cette extensibilité évite le problème du « nous avons besoin d’un champ que la spécification ne supporte pas » qui tue l’adoption des standards rigides.

Le Data Contract Specification (datacontract.com)

La spécification alternative, développée par l’équipe derrière Data Contract CLI (d’Entropy Data), suit des conventions similaires. Elle utilise aussi YAML, couvre le schéma, la qualité et les métadonnées, et cible les mêmes cas d’usage.

La différence clé est la provenance et la gouvernance : ODCS est sous la Linux Foundation avec une gouvernance formelle, tandis que le Data Contract Specification est maintenu par la communauté par l’équipe Entropy Data.

En pratique, les différences diminuent. Data Contract CLI est passé à ODCS comme format par défaut. L’équipe Entropy Data est explicite sur la direction : « Il n’y a pas de différences fondamentales ou conceptuelles entre ces deux formats majeurs. Les deux sont des standards ouverts, utilisent YAML et spécifient des jeux de données de façon similaire. Nous visons l’harmonisation. »

Ce n’est pas le problème des standards concurrents XKCD. L’écosystème converge vers ODCS, avec le Data Contract Specification agissant plus comme une syntaxe alternative qu’une philosophie concurrente.

ODCS vs contrats de modèles dbt

Les contrats de modèles natifs de dbt (disponibles depuis Core v1.5) et ODCS opèrent à des portées différentes :

Dimension	Contrats de modèles dbt	ODCS
Portée	Schéma d’un seul modèle dbt	Cycle de vie complet du produit de données
Enforcement du schéma	Noms de colonnes, types, contraintes	Noms de colonnes, types, typage logique/physique
Règles de qualité	Non inclus (utiliser les tests dbt séparément)	Intégré dans le contract
SLAs	Non inclus	Latence, disponibilité, fraîcheur
Propriété	Non inclus (utiliser `meta` comme contournement)	Section `team` de première classe
Métadonnées personnalisées	Via bloc `meta`	Via `customProperties`
Point d’enforcement	Moment du dbt build	Varie selon l’outillage
Gouvernance	Config par modèle en YAML	Document versionné autonome

Les contrats dbt sont des contrats de schéma pour la couche de transformation. ODCS est un accord complet sur le produit de données. Ils se complètent : utiliser les contrats dbt pour faire respecter le schéma dans le DAG, et ODCS pour définir l’accord plus large (SLAs, propriété, règles de qualité) qui couvre le pipeline complet.

Pour les équipes utilisant déjà dbt, le chemin pratique est : commencer avec les contrats de modèles natifs de dbt sur les modèles mart, puis adopter ODCS quand il faut formaliser des accords avec des équipes extérieures au projet dbt — équipes d’ingénierie logicielle produisant des données sources, équipes ML consommant les sorties, ou partenaires externes recevant des produits de données.