Exemple de rapport de préparation

Voici le format du rapport du sprint, rempli à partir du projet de démonstration public dbt-revenue-variance-demo (commit 243d6f0, CI verte). Aucun client, aucune donnée client. Ce n’est ni un audit Cortex Analyst ni une exécution dans Snowflake : la démo n’a ni l’un ni l’autre. Les résultats question par question ne sont pas montrés ici. Le deuxième bloc dit ce qu’un vrai projet ajoute.

Client: Aucun (projet de démonstration fictif)
Domaine présenté: Chiffre d’affaires mensuel et écart au budget (modèles dbt et couche sémantique, DuckDB)
Préparé le: 2026-10-07 (exemple)
Préparé par: Simon Sangla, ingénieur analytics et IA indépendant
Verdict: GO SOUS CONDITIONS (simple exemple de format ; aucun système réel n’a été évalué). Chaque condition renvoie à un constat ci-dessous.

1. Synthèse

Contrôles exécutés: 6 preuves rejouables, chacune avec son énoncé, son test et son résultat dans le dépôt ; la CI les rejoue à chaque push
Chiffre de référence: Chiffre d’affaires de 53 546,30 EUR (build propre), recalculé à partir des commandes brutes
Défauts injectés dans les données: 3. Le build d’origine en a détecté 1 sur 3 ; avec deux tests ajoutés pour eux, il en détecte 3 sur 3
Changements qui laissent un dbt build simple au vert: 4 distincts : deux des défauts de données, un changement d’agrégation de la métrique, un changement de filtre dans la requête de dashboard
Résidence des données: Pas une exécution dans Snowflake. Cet exemple a tourné sur DuckDB avec des données fictives.

2. Ce qu’un vrai projet ajoute (non montré dans cet exemple)

Cet exemple couvre la partie confiance des métriques et validation. Le sprint lui-même est une évaluation à périmètre fixe de 5 jours de votre configuration Snowflake Cortex ou text-to-SQL, et le rapport ajoute :

Résultats question par question. Un jeu de vos questions métier est soumis à votre configuration Cortex ou text-to-SQL, et chaque réponse est comparée à une requête de référence : réussite, échec ou avertissement, avec la raison.
Une vue sémantique gouvernée pour le domaine audité, construite dans un sandbox ou un clone.
Un jeu de tests de validation que vous pouvez rejouer, pour que le contrôle survive au sprint.
Une recommandation go/no-go avec les blocages à lever en premier, et une restitution avec votre équipe.
La résidence des données, étape par étape. Lecture seule sur vos données de production ; l’endroit où chaque étape a tourné est écrit dans le rapport, et toute étape hors de votre compte est signalée.

3. Carte de confiance des métriques

Chiffre d’affaires
Définition de référence
Somme de quantité x prix unitaire sur les commandes terminées
Granularité
Mois x produit
Filtre obligatoire
statut = terminée (remboursements exclus)
Responsable (rôle illustratif)
Responsable finance
Statut de confiance
VÉRIFIÉ à la granularité totale : la métrique de la couche sémantique égale le recalcul sur les commandes brutes, 53 546,30 EUR. Une modification de la définition de la métrique passerait encore le build tant que la condition 2 n’est pas en place (constat 2)
Pont d’écart (volume, prix)
Définition de référence
Budget + effet volume + effet prix = chiffre d’affaires réel
Granularité
Mois x produit
Filtre obligatoire
Comme le chiffre d’affaires
Responsable (rôle illustratif)
Responsable finance
Statut de confiance
VÉRIFIÉ : rattaché au chiffre d’affaires recalculé à partir des commandes, donc un filtre modifié fait échouer le build (compter les remboursements le passe au rouge, constat 4)
Couverture du budget
Définition de référence
Chaque mois de budget a des commandes terminées
Granularité
Mois
Filtre obligatoire
Aucun
Responsable (rôle illustratif)
Data engineering
Statut de confiance
VÉRIFIÉ après l’ajout d’un test (constat 1)
Chiffre d’affaires du dashboard
Définition de référence
Somme du chiffre d’affaires réel du modèle mensuel
Granularité
Total
Filtre obligatoire
Doit égaler la métrique de chiffre d’affaires
Responsable (rôle illustratif)
Responsable BI
Statut de confiance
AVERTISSEMENT : une seconde définition du même chiffre, protégée seulement par un contrôle de parité (constat 3)

Granularité : le niveau que représente une ligne. Test à réponse connue : recalcule un chiffre indépendamment à partir des données brutes et le compare à celui du modèle.

4. Constats

Les constats ci-dessous viennent d’une injection volontaire de défauts sur une démo publique, pas d’une découverte sur un système réel.

Constat 1 (gravité élevée) : une classe de défauts qu’un pipeline au vert peut laisser passer.

Trois défauts ont été injectés dans le seed des commandes d’une copie du projet. Le chiffre d’affaires propre est de 53 546,30 EUR.

Cinq lignes de commande terminées chargées deux fois
Chiffre d’affaires (EUR)
53 776,60 (+230,30)
Build d’origine
Détecté (unique_stg_orders_order_id)
Après deux tests ajoutés pour eux
Détecté
Lignes remboursées requalifiées en terminées
Chiffre d’affaires (EUR)
61 606,60 (+8 060,30, +15 %)
Build d’origine
Non détecté : PASS=27, ERROR=0
Après deux tests ajoutés pour eux
Détecté (assert_refunds_present_each_month)
Commandes de mars 2026 manquantes
Chiffre d’affaires (EUR)
35 950,20 (-17 596,10, -33 %)
Build d’origine
Non détecté : PASS=27, ERROR=0
Après deux tests ajoutés pour eux
Détecté (assert_orders_cover_budget_months)

Les tests à réponse connue n’ont pas aidé : ils recalculent le chiffre d’affaires à partir du même seed, donc quand le seed est faux, les deux côtés concordent. Le mois manquant n’apparaissait que comme un écart de 100 % au budget, ce qui ressemble à un résultat métier, pas à un défaut de données. Tests ajoutés : deux. Build propre PASS=29, ERROR=0 ; les trois builds modifiés échouent avec ERROR=1, 1 et 2.

Constat 2 (gravité élevée) : un changement dans la couche sémantique est invisible pour le build.

Un mot changé dans la définition de la métrique (agg: sum devient agg: max) : la métrique renvoie 9 550,90 EUR contre 53 546,30 EUR depuis les commandes brutes. dbt build reste vert parce qu’aucun test de table ne lit la couche sémantique. Seul un contrôle à réponse connue, interrogé via la couche sémantique elle-même, le détecte.

Constat 3 (gravité moyenne) : deux définitions d’un même chiffre.

Une requête de type dashboard et la métrique revenue concordent à 53 546,30 EUR. Si la requête abandonne le filtre de statut, elle renvoie 61 606,60 EUR, et dbt build reste vert (PASS=27, ERROR=0). Un contrôle qui exécute la requête et la métrique côte à côte le détecte.

Constat 4 (résolu) : un changement de définition doit être visible.

Compter les commandes remboursées comme chiffre d’affaires fait passer celui-ci à 61 606,60 EUR (+8 060,30, +15 %) et met le build au rouge sur deux tests à réponse connue (ERROR=2). Le changement ne peut pas atteindre le pont d’écart en silence : quelqu’un doit l’approuver.

5. Décision go / no-go avant production

Conditions avant déploiement général

Garder les deux tests de données ajoutés (couverture des mois de budget, remboursements présents chaque mois) dans le build. Constat 1.
Exécuter en CI le contrôle à réponse connue de la métrique via la couche sémantique. Constat 2.
Exécuter en CI le contrôle de parité dashboard / métrique, ou supprimer la seconde définition. Constat 3.

Sources : proofs/2026-10-07-*/CLAIM.md dans le dépôt de démonstration, commit 243d6f0. Données fictives, seed 42.

Télécharger le PDF (en anglais, 3 pages)Dépôt de démonstration sur GitHub

Réserver un appel de cadrage de 20 min