Un run dbt corrompt la table du chiffre d'affaires : qui répond du désastre data ?

La table de référence du chiffre d'affaires est souvent la plus regardée de tout l'entrepôt : direction, finance, comités de pilotage en dépendent. C'est aussi celle dont la corruption fait le plus de bruit.

Les scénarios de destruction sont d'une banalité déroutante :

• un dbt run --full-refresh lancé par mégarde sur la production au lieu de l'environnement de test : le modèle incrémental est recréé de zéro, l'historique disparaît ;
• un merge mal écrit dont la clé de jointure n'est pas unique : chaque ligne se duplique, le CA est artificiellement multiplié ;
• un Snowpipe qui rejoue un fichier source déjà ingéré et double les transactions ;
• un changement de logique métier (taux de change, périmètre) déployé sans recalcul de l'historique, qui rend deux périodes incomparables.

Le piège, c'est le silence. Le job se termine en succès technique. Aucune erreur. La corruption ne se révèle que lorsqu'un contrôleur de gestion constate que le CA du trimestre a doublé, parfois plusieurs jours plus tard.

Restaurer une table prend parfois quelques minutes. Le préjudice du client, lui, se mesure en aval :

• Décisions faussées. Un comité a arbitré un budget ou une prime commerciale sur un CA erroné.
• Clôture comptable retardée. Si la corruption tombe en période de clôture, elle bloque la production des états financiers.
• Reporting réglementaire ou investisseur transmis avec des chiffres faux, avec un coût de rectification et d'image.
• Perte de confiance. Une fois la donnée prise en défaut, chaque chiffre est suspecté ; le coût de reconquête de la confiance est diffus mais réel.

C'est un dommage immatériel par excellence : aucune machine cassée, mais une perte financière et opérationnelle parfois lourde.

C'est ce préjudice-là, et non le coût de la restauration technique, qu'un client chiffrera dans une réclamation. D'où l'importance d'une RC Pro couvrant explicitement les dommages immatériels non consécutifs.

Snowflake fournit des mécanismes de récupération puissants. Les connaître et les avoir activés fait partie des règles de l'art de votre métier — leur absence peut vous être reprochée.

• Time Travel. Toute table peut être interrogée ou restaurée à un instant passé (AT / BEFORE), dans la limite de la rétention configurée (jusqu'à 90 jours en édition Enterprise). Une table corrompue se restaure souvent avec un simple CREATE OR REPLACE ... CLONE ... AT(...).
• Zero-copy clone. Avant tout déploiement risqué, cloner la table cible coûte zéro stockage et offre un point de retour instantané.
• Fail-safe. Filet ultime de 7 jours géré par Snowflake après expiration du Time Travel.

Si vous avez réglé la rétention Time Travel à 0 sur une table critique « pour économiser », ou déployé sans clone de sécurité, vous avez supprimé le filet qui aurait évité le sinistre. À l'inverse, un processus de déploiement intégrant clone systématique et rétention suffisante démontre votre diligence.

Comme tout prestataire intellectuel, vous êtes tenu à une obligation de moyens. On ne vous reproche pas qu'un incident survienne — ils sont inévitables — mais de ne pas avoir mis en place les moyens qu'un professionnel diligent aurait déployés. Concrètement, votre responsabilité se durcit ou s'allège selon que vous pouvez démontrer :

• une séparation stricte des environnements (dev / staging / prod) avec des rôles distincts, pour qu'un full-refresh ne puisse pas frapper la prod par accident ;
• des tests dbt (unique, not_null, tests de fraîcheur et de volumétrie) qui auraient détecté la duplication avant publication ;
• un déploiement par CI/CD avec revue, plutôt qu'une exécution manuelle depuis votre poste ;
• une idempotence des pipelines d'ingestion pour éviter les doubles chargements.

Un incident survenu malgré ce dispositif relève de l'aléa couvert par l'assurance. Un incident survenu en son absence ressemble à une négligence. La frontière entre les deux décide souvent de l'issue du litige — et c'est précisément là que les frais de défense pris en charge par votre RC Pro pèsent dans la balance.

Pour transformer le risque en incident maîtrisé, intégrez ces réflexes à chaque livraison sur une table critique :

1. Cloner avant de modifier. Un zero-copy clone de la cible juste avant le déploiement donne un retour arrière immédiat et gratuit.
2. Tester avant de publier. Les tests dbt bloquants empêchent une table en échec de remplacer la version saine.
3. Verrouiller la prod. Aucun --full-refresh manuel possible ; la production ne se déploie que par pipeline validé.
4. Surveiller la volumétrie. Une alerte sur une variation anormale du nombre de lignes ou de la somme du CA détecte la corruption en heures, pas en jours.
5. Documenter la procédure de restauration Time Travel pour chaque table critique : en cas d'incident, la remédiation est rapide et tracée.

Ce dispositif, couplé à une RC Pro adaptée au conseil data, vous place dans la meilleure position : peu de sinistres, des dégâts limités, et une défense solide quand un litige survient malgré tout. Pour le détail des garanties propres à votre activité, voir la page consultant Snowflake.