Contrats de source
Une entente écrite pour chaque source de données — la forme des données à l'arrivée, leur fraîcheur exigée, et qui est appelé quand ça brise — vérifiée automatiquement à la porte.
Comme une entente de livraison avec un fournisseur : les boîtes arrivent à l'heure convenue, emballées de la façon convenue, et si un envoi est fautif, vous savez exactement qui appeler — au lieu de déballer des boîtes mystères en devinant qui les a envoyées. Un contrat de source, c'est cette entente, pour des données, appliquée par une machine.
Le problème, en mots simples
Un pipeline brise pendant la nuit. Au matin, votre tableau de bord est vide, et le travail de détective commence : laquelle des quarante sources a changé ? L'exportation du CRM, le flux des paiements, le chiffrier du partenaire ? Vous fouillez les journaux, trouvez un champ renommé, puis passez l'après-midi à déterminer quelle équipe en amont l'a fait et si elle est seulement au courant. Le temps que ce soit réparé, deux jours d'enregistrements sont perdus ou abîmés — et les équipes en aval sont retournées, sans le dire, à ne plus faire confiance aux données.
Ce que nous mettons en place
Chaque source reçoit un contrat, écrit en code : à quoi ressemblent exactement les données (un schéma typé — chaque champ nommé, avec son type), leur fraîcheur exigée et comment on la mesure, combien d'erreurs sont tolérables avant de déclarer un bris (un budget d'erreurs), et ce qui arrive quand le contrat est violé — réessayer, mettre les mauvais enregistrements de côté, ou arrêter la chaîne. La validation s'exécute dès l'arrivée des données. Le contrat est versionné comme du code, et les équipes en aval s'y abonnent — un changement planifié est annoncé à tous les concernés, au lieu d'être découvert par eux.
Comment ça fonctionne, étape par étape
- Écrire le contrat par source
Forme, fraîcheur, budget d'erreurs et politique de bris — convenus avec l'équipe propriétaire de la source, et rangés sous forme de code.
- Vérifier chaque livraison à la porte
Les données entrantes sont validées contre le contrat à l'arrivée, pas après s'être répandues en aval.
- Traiter les violations selon la politique convenue
Selon le contrat : réessayer, détourner les mauvais enregistrements vers une table de rebut (des objets trouvés), ou arrêter et refuser le chargement.
- Aviser le propriétaire automatiquement
Quand un contrat brise, le propriétaire nommé de la source est avisé, avec les enregistrements fautifs joints — pas besoin d'enquête pour trouver le coupable.
- Versionner les changements et aviser les abonnés
Une source qui doit changer de forme publie une nouvelle version de son contrat ; chaque consommateur abonné l'apprend avant que ça arrive.
Ce qui change pour vous
Avant : un pipeline brisé est un roman policier qui mange la semaine de votre équipe de données. Après : c'est un avis à un propriétaire nommé, avec les preuves jointes et les mauvais enregistrements mis de côté en sécurité. Les tableaux de bord et les agents en aval apprennent à faire confiance à ce qui arrive — et la télémétrie de fraîcheur permet au retrieval de sauter une source devenue discrètement périmée. Ce qu'il ne fera pas : empêcher les sources de briser un jour. Les systèmes changent et les erreurs arrivent ; le contrat rend le bris visible, contenu et attribuable — pas impossible.