clement13.net
Photo d’origine : Deux poids en laiton couverts de poinçons de vérification : la conformité attestée avant l'usage
Description
Deux poids en laiton couverts de poinçons de vérification : la conformité attestée avant l'usage
Source
HelgeRieder · page d’origine
Licence
CC0 Domaine public
Photo d’origine, non retouchée. L’arrière-plan en est une version stylisée par le site.

Recette et validation métier

« Le code s'exécute sans erreur » ne dit pas « le chiffre est juste ». En data, la recette est d'une nature particulière : on ne vérifie pas une fonction, on vérifie un nombre contre une…

Guide≈ 8 min de lectureVérifiéContrôle effectuéLes faits, chiffres et références ont été contrôlés au regard des sources citées dans la fiche.Rédaction assistée par IA ; sources citées en bas de page. Une erreur ? Signalez-la via le site clement13.net.Lecture

Niveau : 🟢→🔴 · Code thème : REC

Pourquoi ce thème#

« Le code s'exécute sans erreur » ne dit pas « le chiffre est juste ». En data, la recette est d'une nature particulière : on ne vérifie pas une fonction, on vérifie un nombre contre une référence indépendante (un état comptable, un export de l'application source, un calcul manuel d'un expert). Sans elle, la confiance repose sur l'absence de plainte. Avec elle, on peut dire : « ce chiffre est conforme à la référence à 0,1 % près, voici l'écart expliqué et signé ». C'est la dernière ligne de défense avant la décision. Ce thème se distingue des tests du code (DL — tests), des tests de modèle et de mesures (BI — tests et fiabilité des chiffres) et de la qualité (QUA) : ici, la validation métier sur chiffres, sa preuve et sa signature.

Ce que mesure le thème#

  • Axe : de l'impression de justesse à la réconciliation continue contre des références indépendantes.
  • Indicateur clé : part des indicateurs critiques réconciliés avec une référence indépendante, et écart résiduel expliqué.
  • Unité : % d'indicateurs réconciliés ; écart relatif maximal toléré (ex. 0,1 %) ; nombre de défauts échappés détectés en production.

Les cinq niveaux#

Niveau Nom court Promesse Indicateur type (ordre de grandeur)
1 Impression Le demandeur regarde le rapport et dit si cela lui paraît juste. 0 référence indépendante
2 Échantillon Quelques chiffres clés sont rapprochés d'une source de référence à chaque livraison. ≥ 5 chiffres clés comparés, manuellement
3 Plan Un plan de recette définit indicateurs, références, tolérances et responsable de signature ; il est exécuté et archivé. 100 % des indicateurs critiques au plan ; écarts expliqués
4 Automatisée La réconciliation est automatique et rejouée à chaque version : un changement qui modifie un chiffre est visible avant production. Non-régression sur chiffres à chaque livraison ; défauts échappés < 1 par trimestre
5 Continue La production se réconcilie en continu ; les écarts alertent le propriétaire avant que l'utilisateur ne les voie. Réconciliation quotidienne ; écart détecté < 24 h

Jalons par niveau#

ID Jalon Preuve vérifiable
PD-REC-1.1 Une recette est faite avant mise à disposition aux utilisateurs. Trace d'une validation par le demandeur.
PD-REC-1.2 Le périmètre de la recette (rapports, périodes, filtres) est noté. Note ou ticket de recette.
PD-REC-1.3 Les anomalies trouvées en recette sont consignées et corrigées avant livraison. Liste d'anomalies avec statut.
PD-REC-1.4 La recette se fait sur les données de l'environnement de test, pas de la production seule. Environnement de recette identifié.
PD-REC-2.1 Au moins cinq chiffres clés sont comparés à une source de référence (application source, état comptable). Tableau « chiffre rapport / chiffre référence / écart ».
PD-REC-2.2 La référence est indépendante du calcul testé (ni la même requête ni le même modèle). Description de l'origine de la référence.
PD-REC-2.3 Les écarts non nuls sont expliqués (arrondi, périmètre, décalage de date). Colonne « explication » renseignée pour chaque écart.
PD-REC-2.4 Le résultat de recette est archivé avec la version testée. Fichier de recette lié à la version livrée.
PD-REC-3.1 Un plan de recette liste indicateurs, références, périodes de test, tolérances et rôles. Plan versionné avec propriétaire.
PD-REC-3.2 Les cas limites sont testés : période vide, rejeu de chargement, changement d'année, valeurs négatives, utilisateur à droits restreints. Cas listés avec résultats (la RLS se teste côté BI — RLS).
PD-REC-3.3 Un décideur métier signe la recette (pas l'équipe technique seule). Signature (ou validation écrite) d'un référent métier.
PD-REC-3.4 La recette couvre la cohérence entre rapports (même chiffre, mêmes filtres, même résultat). Test croisé sur au moins un indicateur partagé.
PD-REC-4.1 Un jeu de chiffres de référence est stocké et rejoué automatiquement à chaque version. Jeu versionné et exécuté dans le pipeline (DOP).
PD-REC-4.2 Un écart dépassant la tolérance bloque la livraison. Un cas où le blocage a effectivement eu lieu.
PD-REC-4.3 Les changements de chiffres entre deux versions sont listés et expliqués avant publication (diff de résultats). Rapport « avant/après » à chaque version.
PD-REC-4.4 Chaque défaut échappé en production donne un nouveau cas de recette. Lien entre incident et cas ajouté.
PD-REC-5.1 Une réconciliation programmée compare la production aux références (comptabilité, application) chaque jour. Historique de réconciliations avec résultats.
PD-REC-5.2 Les écarts déclenchent une alerte à un propriétaire nommé, avec délai d'analyse. Alertes archivées et délais constatés.
PD-REC-5.3 Les références sont elles-mêmes validées et leur évolution tracée. Journal des changements de référence.
PD-REC-5.4 La couverture de recette est mesurée par indicateur critique, pas par nombre de tests. Couverture publiée, revue trimestrielle.

Lecture détaillée par niveau#

🟢 Niveau 1 — Impression#

  • Signes : « ça m'a l'air bon » ; aucune trace de ce qui a été regardé ; le bon chiffre est celui qui ressemble au précédent.
  • Gain : une validation sociale rapide.
  • Ne garantit pas : l'exactitude ; une erreur de 2 % passe inaperçue.
  • Difficulté : 1/5 · Effort : 1/5.

🟢 Niveau 2 — Échantillon#

  • Signes : un tableau comparant cinq chiffres du rapport à ceux de l'application source ; les écarts sont discutés ; le fichier est archivé.
  • Gain : le plus gros des erreurs de périmètre ou de jointure est repéré.
  • Ne garantit pas : la couverture ni la répétabilité.
  • Difficulté : 2/5 · Effort : 2/5.

🟡 Niveau 3 — Plan#

  • Signes : plan versionné ; cas limites listés ; signature du métier ; cohérence entre rapports testée.
  • Gain : une recette reproductible, une responsabilité partagée avec le métier.
  • Ne garantit pas : l'absence de régression à la version suivante (recette manuelle, donc coûteuse à rejouer).
  • Difficulté : 3/5 · Effort : 3/5.
🧪 Exemple

Relevés de linéaire d'une application SFA : le plan fixe trois références (export de l'application pour 10 magasins, total du mois comptabilisé, calcul manuel par un expert sur un produit). Tolérance : 0 sur les comptages, 0,1 % sur les mesures calculées. Cas limites : produit sans relevé, magasin fermé, relevé saisi hors-ligne et synchronisé trois jours plus tard, changement de mois. L'écart de 12 relevés trouvé en recette venait de relevés synchronisés en retard : règle de rattachement à la date de relevé et non de synchronisation, validée par le métier.

🟡 Niveau 4 — Automatisée#

  • Signes : un jeu de chiffres de référence s'exécute dans le pipeline ; un diff de résultats « avant/après » est produit à chaque version ; chaque incident ajoute un cas.
  • Gain : une recette qui coûte presque zéro à rejouer ; les régressions deviennent visibles.
  • Ne garantit pas : que la référence soit juste (une référence erronée fige l'erreur).
  • Difficulté : 4/5 · Effort : 4/5.
-- Réconciliation : total du datamart contre la référence source (T-SQL), tolérance 0,1 %
WITH Dm  AS (SELECT SUM(REL_QTE) AS Tot FROM [fact].[Releve] WITH (NOLOCK) WHERE [date] >= '2026-09-01' AND [date] < '2026-10-01'),
     Ref AS (SELECT SUM(QTE)     AS Tot FROM [ref].[ExportApplication] WITH (NOLOCK) WHERE MOIS = '2026-09')
SELECT Dm.Tot AS Datamart, Ref.Tot AS Reference,
       ABS(Dm.Tot - Ref.Tot) * 1.0 / NULLIF(Ref.Tot, 0) AS EcartRelatif,
       CASE WHEN ABS(Dm.Tot - Ref.Tot) * 1.0 / NULLIF(Ref.Tot, 0) <= 0.001 THEN 'OK' ELSE 'ECHEC' END AS Verdict
FROM Dm CROSS JOIN Ref;

🔴 Niveau 5 — Continue#

  • Signes : la réconciliation tourne chaque jour ; un écart alerte un propriétaire ; la couverture est mesurée par indicateur.
  • Gain : la confiance se construit en continu, pas à la livraison.
  • Ne garantit pas : le sens (une réconciliation parfaite d'un indicateur mal défini ne le rend pas utile ; voir VAL).
  • Difficulté : 5/5 · Effort : 4/5.

Atteinte partielle et notation#

Évaluez sur les cinq indicateurs les plus utilisés. Un jalon vaut 1 si les cinq sont couverts, 0,5 si deux à quatre, 0 sinon. Sans trace archivée, un jalon de recette vaut 0 : une recette sans preuve n'a pas eu lieu.

Un « 5 partiel » : une réconciliation quotidienne couvre le chiffre d'affaires et les volumes principaux (5.1 à 0,5), les alertes arrivent au propriétaire (5.2 à 1), les références sont stables mais non tracées (5.3 à 0,5), la couverture n'est pas mesurée (5.4 à 0).

⚠️ Piège

La référence qui n'en est pas une : comparer le datamart à une requête sur… le datamart. Symptôme : écart nul, utilisateurs en désaccord. Remède : la référence vient d'un autre chemin (source, comptabilité, calcul indépendant).

⚠️ Piège

La recette sur le seul cas nominal : tout est juste sauf le dernier jour du mois, l'utilisateur au périmètre restreint ou le rejeu. Remède : une liste fixe de cas limites data (période vide, rejeu, changement d'année, valeurs négatives).

Passer au niveau suivant#

Moyens possibles (facultatifs)

Passage Leviers possibles
1 → 2 Choisir cinq chiffres que le métier connaît par cœur ; les comparer à la source à chaque livraison.
2 → 3 Écrire le plan avec le référent métier ; ajouter les cas limites ; faire signer.
3 → 4 Stocker les chiffres de référence ; les rejouer dans le pipeline ; produire le diff avant/après.
4 → 5 Planifier la réconciliation en production ; brancher l'alerte sur le propriétaire (EXP).

Pièges transverses : (1) Faux positif — un 100 % de réussite sur un jeu de test non représentatif. (2) Goodhart — viser « zéro écart » conduit à ajuster la référence ou à élargir la tolérance ; tracez toute modification de tolérance. (3) Effet tunnel — une recette uniquement technique, sans décideur métier, laisse passer les erreurs de définition (GOV).

🤖 IA

Elle propose des cas limites, génère des requêtes de réconciliation, commente un diff de résultats. Elle ne signe pas une recette, ne connaît pas la tolérance acceptable et peut produire un test qui passe toujours. La référence indépendante et la signature restent humaines.

Voir aussi#

✻ Rédigé par Claude Sonnet 5.5