Modes de contrat de schéma des outils EL

Les outils EL constituent le premier point d’application des contrats de schéma. Ils se situent avant toute couche de transformation et peuvent rejeter les données non conformes avant qu’elles n’atteignent l’entrepôt. Leurs capacités en matière de contrats varient significativement.

dlt : contrats de schéma granulaires

dlt (data load tool) dispose du support natif de contrats le plus capable de tous les outils EL. Il est possible de définir un comportement par type d’entité — tables, colonnes et types de données — avec quatre modes indépendants :

evolve — accepte tous les changements. Les nouvelles tables, nouvelles colonnes et changements de type transitent sans intervention.
freeze — rejette les changements et lève des exceptions. Le pipeline échoue si le schéma source dévie de ce qui est attendu.
discard_rows — supprime silencieusement les lignes non conformes. Le pipeline réussit mais charge uniquement les données correspondant au contrat.
discard_columns — supprime les nouvelles colonnes sans échouer. Les colonnes existantes sont appliquées ; les ajouts inattendus sont ignorés.

La puissance réside dans la combinaison de ces modes par type d’entité. Une configuration de production courante :

import dlt

SCHEMA_CONTRACT = {
    "tables": "evolve",
    "columns": "freeze",
    "data_type": "freeze"
}

@dlt.resource(
    write_disposition="merge",
    table_name="orders",
    primary_key="order_id",
    schema_contract=SCHEMA_CONTRACT
)
def orders_resource():
    yield [{"order_id": 1, "customer_id": 42, "amount": 99.50}]

Cette configuration laisse apparaître de nouvelles tables (utile pendant le développement ou lorsqu’une API ajoute de nouveaux endpoints) mais rejette tout changement de colonne ou de type sur les tables existantes. Si une API commence à retourner un nouveau champ ou modifie le type d’un champ, le pipeline échoue avant que quoi que ce soit n’atteigne l’entrepôt.

La combinaison evolve + freeze pour les tables vs. les colonnes est particulièrement pratique. En développement, on veut découvrir ce que la source fournit. En production, on veut de la stabilité. En autorisant l’évolution des tables mais en figeant les schémas de colonnes, on obtient les deux : les nouvelles catégories de données sont capturées, mais les schémas existants sont protégés.

dlt supporte également la validation par modèles Pydantic pour une application de schéma encore plus stricte :

from pydantic import BaseModel
import dlt

class Order(BaseModel):
    order_id: int
    customer_id: int
    amount: float
    status: str

@dlt.resource(columns=Order)
def orders():
    yield [{"order_id": 1, "customer_id": 42, "amount": 99.50, "status": "pending"}]

Avec les modèles Pydantic, la validation de type se produit en Python avant même que les données n’atteignent l’étape de chargement. Un champ arrivant comme chaîne alors que le modèle attend un entier lève immédiatement une erreur de validation.

Fivetran : paramètres peu granulaires

Fivetran adopte une approche fondamentalement différente. Il détecte automatiquement les changements de schéma — nouvelles colonnes, colonnes supprimées, changements de type, nouvelles tables — et propose trois paramètres :

« Allow all new data » — tout transite, avec des notifications par e-mail sur les changements.
« Allow new columns » — autorise les ajouts de colonnes mais bloque les autres changements.
« Block all new data » — arrête complètement les synchronisations à tout changement de schéma.

Il n’y a pas de granularité par colonne ou par type. Il n’est pas possible de dire « figer les colonnes mais faire évoluer les tables » comme avec dlt. Les changements se propagent avec des notifications par e-mail, ce qui signifie qu’on est informé après coup, sauf avec le paramètre de blocage le plus strict.

Le problème avec « Block all new data » est qu’il est trop agressif pour la plupart des équipes. Il arrête complètement les synchronisations à tout changement, y compris les changements bénins comme l’ajout d’une nouvelle colonne à la source. Si votre synchronisation s’exécute à 3h du matin et qu’un changement de schéma la bloque, personne ne le sait jusqu’à ce que les tableaux de bord soient vides le matin. L’option existe, mais elle n’est pas pratique pour les équipes ayant besoin d’un flux de données continu.

Pour les utilisateurs de Fivetran, la posture réaliste est « Allow all new data » avec notifications par e-mail, combiné à une application en aval dans dbt ou Soda. On accepte que les changements de schéma atterrissent dans l’entrepôt et on les détecte lors de la transformation.

Airbyte : mode d’approbation manuelle

Airbyte se situe entre dlt et Fivetran en termes de granularité. Son mode « Detect and manually approve » met les connexions en pause pour révision lors de changements considérés comme cassants. Lorsqu’un schéma source change d’une manière qu’Airbyte considère comme cassante, la synchronisation s’arrête et attend qu’une personne approuve le changement dans l’interface avant que les données ne reprennent.

C’est plus proche de ce qu’un contrat devrait faire — bloquer les changements cassants jusqu’à leur révision. Mais l’étape manuelle crée ses propres problèmes :

Les synchronisations sensibles au temps sont retardées. Si un changement de schéma se produit pendant les heures de bureau et que quelqu’un l’approuve rapidement, aucun problème. S’il se produit un vendredi soir, la synchronisation est bloquée jusqu’au lundi.
Fatigue d’approbation. Si les changements de schéma sont fréquents, l’équipe commence à approuver sans examen attentif juste pour maintenir le flux de données. Le mécanisme s’érode quand il se déclenche trop souvent.
Pas de dérogation programmatique. Il n’est pas possible de construire une logique disant « approuver automatiquement si le seul changement est une nouvelle colonne » — chaque changement signalé nécessite une intervention humaine.

La gestion des changements non cassants d’Airbyte est automatique. Les nouvelles colonnes sont ajoutées à la destination, et les promotions de type (élargissement d’un type) se poursuivent sans intervention. Seuls les changements qu’Airbyte considère comme cassants — suppressions de colonnes, rétrécissement de type — déclenchent le workflow d’approbation.

Implications pratiques

La réalité pratique est que la plupart des équipes analytics utilisent Fivetran ou Airbyte et vivent avec un contrôle en amont limité. L’application du schéma se produit à la couche suivante — dans dbt via les tests de source et les modèles de base avec contrats, ou dans un outil post-chargement comme Soda.

Si vous construisez de nouveaux pipelines ou avez des sources avec des changements de schéma fréquents, les modes de contrat de dlt constituent un véritable différenciateur. La capacité de dire « figer les colonnes, faire évoluer les tables, figer les types de données » et que le pipeline l’applique automatiquement — avant que les données n’atteignent l’entrepôt — est quelque chose que ni Fivetran ni Airbyte ne peuvent reproduire.

Pour les pipelines Fivetran ou Airbyte existants, l’application doit se produire en aval. Ce n’est pas un échec — c’est le modèle de défense en couches. Votre outil EL est un point d’application, et s’il ne peut pas gérer des contrats granulaires, vous compensez à la couche suivante.

La décision sur quel outil EL utiliser implique de nombreux facteurs au-delà des contrats de schéma — voir Choosing Between Fivetran, Airbyte, and dlt pour une vue d’ensemble. Mais pour les équipes où l’instabilité du schéma en amont est un vrai problème, le support de contrats de dlt mérite d’être pris en compte aux côtés du coût, de la couverture des connecteurs et de la charge opérationnelle.