Une donnée fausse en production n'est pas juste un bug technique. C'est une décision business fausse. Un chiffre d'affaires surestimé qui crée une fausse impression de croissance. Un client classé actif qui ne l'est pas, entraînant du marketing inefficace.
IBM (2025) estime le coût d'une donnée mauvaise à 40 000$ en moyenne. Ça peut aller jusqu'à 500 000$ selon le contexte. Le coût de la prévention - tests, contracts, monitoring - est négligeable en comparaison. Pourtant beaucoup d'organisations ne testent rien. Pourquoi? Parce que les conséquences sont invisibles, diffuses.
Un dashboard affiche un chiffre faux, personne ne s'en rend compte pendant 3 mois. C'est l'urgence cachée du data engineering : implémenter les garde-fous avant que le désastre arrive.
Data Contracts: formaliser le contrat
Un Data Contract est un accord écrit entre le producteur d'une donnée et ses consommateurs. Il spécifie précisément : le schéma exact (colonnes, types, nullabilité), les SLA de fraîcheur (données mises à jour tous les jours avant 8h), les SLA de disponibilité (99.5% du temps), les garanties de cardinalité (pas moins de 1M de lignes/jour), les règles métier (pas de valeurs négatives pour les montants).
Le producteur s'engage à respecter le contrat. Le consommateur s'engage à utiliser la donnée correctement. Si le producteur viole le contrat - livraison 1h en retard, schéma changé sans notice - le consommateur a le droit de refuser. Les Data Contracts réduisent de 75% les anomalies de schéma en production.
C'est la responsabilité explicite. C'est de l'ingénierie.
Schémas stricts et versioning
Un schéma strict signifie : pas de colonnes supplémentaires non-validées, pas de changements de type sans migration, pas de renommage silencieux. BigQuery, Snowflake, Redshift supportent tous les schémas stricts. Chaque colonne a un type, une nullabilité, une description.
Les breaking changes sont interdits : renommer une colonne ne se fait qu'avec migration planifiée. Ajouter une colonne non-nullable casse les contrats. Les schémas mal versionnés causent 30% des anomalies de données.
Fixer le schéma une fois, le tester rigidement, puis l'évoluer avec un processus clair - dépréciation > notification > migration > suppression sur 6 mois. C'est de la discipline.
Great Expectations et automated testing
Great Expectations est l'outil standard pour les tests de qualité de données. Définir des expectations (assertions) et les exécuter automatiquement.
Exemples concrets : « la colonne purchase_date ne doit pas avoir de nulls », « le montant doit être >= 0 », « l'email doit matcher le pattern », « le nombre de lignes ne doit pas chuter de >10% jour sur jour ».
Ces tests s'exécutent après chaque chargement. Si une expectation échoue, alerte ou blocage du pipeline. Great Expectations réduit 80% de la détection des anomalies. Quand une colonne devient soudainement nullable, l'alerte remonte immédiatement. C'est la détection précoce avant la cascade en analyses fausses.
SLA données et Observabilité
Un SLA (Service Level Agreement) données est un contrat entre producteur et consommateur - disponibilité garantie (99.5%), latence maximale (données < 24h old), qualité garantie (>95% de validité).
Si le producteur viole le SLA, il doit compenser ou justifier. Ça crée de l'accountability. Les SLA bien définis réduisent de 90% les disputes entre équipes : tout est noir et blanc.
L'observabilité associée au SLA mesure en continu - latence réelle, taux de validité, erreurs par type. Des dashboards montrent l'état de santé de chaque donnée en temps réel. Si une courbe monte, alerte. L'équipe peut intervenir avant que l'utilisateur ne découvre le problème en prod.
Change Management: les trois types
Un contrat données rigoureux impose un process discipliné pour les changements. Trois types : additive (nouvelle colonne nullable) - pas besoin de notification.
Dépreciations (colonne supprimée dans 6 mois) - notification à tous les consommateurs 3 mois avant.
Breaking changes (supprimer une colonne, changer un type) - discussion avec tous les consommateurs, migration planifiée. Tout changement passe par une PR dbt, revue par les stakeholders, testé rigoureusement, puis déployé avec changelog.
Sans ce process, les changements cassent silencieusement des dépendances. Avec, c'est du software engineering appliqué aux données.
En production
Chez Bomzai, on parle d'industrialiser. Industrialiser la donnée, c'est avoir de la confiance dans ce qui circule. Et la confiance vient de la rigueur.
Schémas stricts, SLA, tests automatisés, change management discipliné. C'est pas du luxe, c'est le minimum pour produire en production. Une mauvaise donnée en production devient exceptionnelle, pas la norme.
Les Data Contracts transforment les données d'un chaos non-gouverné en chaîne d'approvisionnement fiable. Producteur et consommateur responsables ensemble. Fournisseur et client d'un contrat. Et ça change complètement la donne.