Par Andrew Tan
Le Problème de la Surveillance des Schémas
La surveillance des schémas est censée détecter les changements critiques. Elle ne le fait pas.
Un pipeline fonctionne pendant des mois sans problème. Puis un service en amont ajoute un champ revenue_v2. L'ancien champ revenue existe toujours, mais il est désormais obsolète et toujours nul. Le pipeline ingère les valeurs nulles sans problème. Pas d'erreurs. Tout est au vert.
La métrique commerciale est simplement fausse.
Cela se produit parce que la surveillance vérifie les changements structurels, pas sémantiques.
Pourquoi la Surveillance Échoue
La plupart des équipes configurent des alertes pour les nouvelles colonnes. Changements de type. Champs manquants. Un humain examine chaque alerte.
Après la cinquantième notification de "nouveau champ optionnel", vous arrêtez de lire. Votre cerveau approuve automatiquement. INT à BIGINT ? Inoffensif. Approuver. Passer à autre chose.
Les vrais problèmes passent inaperçus. Le problème ci-dessus n'était pas structurel. Il était sémantique. Un nouveau champ est apparu — supposément sûr. L'ancien champ existait. Aucun changement critique détecté.
Le contrat était rompu. Personne ne l'a remarqué.
La surveillance détecte les accidents. Vous avez besoin de quelque chose qui détecte les mensonges.
Contrats vs. Registres
Un registre de schéma vérifie la structure. Noms des champs, types, nullabilité. Important. Pas suffisant.
Un contrat de données vérifie les promesses.
- Avez-vous envoyé un nombre ?
- Cela signifie-t-il ce que vous avez dit ?
- Est-il positif ? Dans la plage ? Référentiellement intact ?
Pensez aux APIs REST. Vous ne vérifiez pas seulement que le JSON est analysé. Vous vérifiez que le point de terminaison fait ce que disent les documents. Rompre cette promesse et c'est un changement critique, même si le JSON est techniquement valide.
Les pipelines de données ont besoin de la même chose. Les systèmes en aval se construisent sur des promesses implicites. Quand elles sont rompues, tout s'effondre.
À Quoi Ressemblent de Bons Contrats
Les équipes qui font cela bien définissent trois choses pour chaque ensemble de données :
Garanties structurelles. Mais avec une nuance : toute déviation est critique. Nouveau champ optionnel ? Augmentation de version. Cela semble douloureux. Élimine entièrement les "changements sémantiques furtifs".
Attentes sémantiques. Règles métier comme validation. Âge du patient 0-120. Les codes de diagnostic doivent exister dans le tableau de référence. Horodatages dans les 24 heures suivant la création du fichier.
Engagements des consommateurs. Les systèmes en aval déclarent leurs dépendances. Changer un champ utilisé par trois pipelines critiques ? Risque élevé. Même si cela semble "sûr" structurellement.
Les changements de schéma passent de jours de coordination à des heures. La dérive sémantique silencieuse tombe à zéro.
La Partie Difficile Est Organisationnelle
Les contrats forcent des conversations que la plupart des gens ne veulent pas avoir.
Les producteurs doivent promettre des choses sur des données qu'ils ne contrôlent pas entièrement. L'équipe CRM ne connaît pas tous les consommateurs en aval. L'équipe mobile ne sait pas comment la science des données utilise leurs événements.
Trois modèles de propriété :
Propriété du producteur. L'équipe qui crée les données définit le contrat. Propre en théorie. Échoue souvent car les producteurs optimisent pour la commodité, pas pour les besoins en aval.
Propriété du consommateur. L'aval définit les exigences. Protège les consommateurs, mais les producteurs ne peuvent pas toujours se conformer. Vous obtenez des contrats sur papier qui sont violés en pratique.
Médiation par la plateforme. Une équipe centrale facilite la conversation. Plus de frais généraux. Fonctionne réellement.
La médiation par la plateforme avec des examens trimestriels est coûteuse en temps de réunion. Bon marché comparé aux incidents.
Commencez Petit
Vous n'avez pas besoin d'une plateforme pour commencer.
Écrivez trois choses pour vos ensembles de données critiques :
Que représente-t-il ? Pas les définitions de champs. Le concept commercial. "Instantané quotidien des abonnements actifs" diffère de "la table contient customer_id, plan_type, renewal_date."
Sur quoi les gens peuvent-ils compter ? Nullabilité, fréquence de mise à jour, rétention. Les choses que tout le monde suppose implicitement.
Que se passe-t-il quand cela casse ? Qui appeler ? À quelle vitesse ? Quel est le retour en arrière ?
Commencez avec vos trois Assets les plus critiques. C'est tout.
Les Contrats Créent Aussi des Problèmes
Ils s'ossifient. Changer un contrat nécessite de la coordination. C'est le but — empêche les changements critiques — mais ralentit aussi les bons changements. Les équipes évitent de proposer des changements à cause du coût de la coordination.
Ils mentent. Un contrat n'est bon que par sa validation. Dire "tous les customer_ids doivent exister" sans vérifier ? Théâtre. Une fausse confiance est pire que pas de confiance du tout.
Ils déplacent la faute. Le consommateur détecte une violation. Réponse : "le producteur a rompu sa promesse." Vrai. Inutile. L'objectif est de corriger les données, pas de blâmer. Vous avez besoin de procédures de récupération, pas de pointage du doigt.
Les Outils
Great Expectations et Soda ont ajouté des fonctionnalités de contrat. Pas des plateformes complètes, mais elles imposent des attentes sémantiques aux frontières.
Data Contract Club et AICP émergent. Contrats de première classe avec versioning et validation.
Les catalogues de données — Collibra, Alation, Atlan — ont maintenant la gestion des contrats. Généralement lourds en flux de travail, légers en validation. Mieux pour les documents que pour l'application.
Chez layline.io, nous intégrons les contrats dans les Workflows. Définir le mouvement des données, définir les promesses. Attentes de schéma, règles de validation, seuils de qualité. Appliqué à l'exécution, pas vérifié après.
Mais vous n'avez pas besoin d'outils sophistiqués. Un fichier JSON Schema avec une étape de validation est un contrat fonctionnel. La pratique organisationnelle surpasse la technologie.
Le Test
Choisissez un data Asset critique. Quelque chose qui ferait mal s'il était faux.
L'amont change son format. Techniquement valide — nouveaux champs, mêmes types. Sémantiquement faux. Combien de temps avant que vous ne le remarquiez ?
Si la réponse est "quand quelqu'un se plaint", vous avez besoin de contrats.
Si c'est "nous le détecterions dans la surveillance", creusez plus profondément. Votre surveillance détecte-t-elle les changements sémantiques ou juste structurels ?
L'objectif n'est pas une qualité de données parfaite. C'est de prévenir les problèmes stupides. Ceux issus d'hypothèses que personne n'a écrites.
Andrew Tan est un entrepreneur en série et fondateur de layline.io, construisant une infrastructure de traitement de données d'entreprise qui gère à la fois les charges de travail par lots et en temps réel à grande échelle.
