Le pattern de résumé matinal automatise la partie routinière du triage quotidien de la qualité des données. Un agent automatisé exécute dbt test, analyse les échecs, les catégorise par sévérité, croise avec la documentation et les annote avec l’historique. Le résultat est un rapport Slack structuré qui attend avant le début de la journée de travail, couvrant l’assemblage du contexte pour que le temps humain soit consacré aux décisions plutôt qu’à la préparation de l’investigation.
La conception à deux cycles
Un système de reporting qualité automatisé efficace fonctionne sur deux cycles aux objectifs distincts.
Le cycle quotidien gère la détection des incidents. À minuit (ou lorsque vos pipelines de production se terminent), l’agent déclenche dbt test sur l’environnement de production. Il analyse chaque échec, recherche le contexte dans la documentation, évalue la sévérité, vérifie l’impact en aval et examine les patterns historiques. À 7h du matin — ou quelle que soit l’heure à laquelle vous souhaitez être informé avant que votre journée commence — il livre un résumé structuré dans Slack.
Le cycle hebdomadaire gère la détection des patterns. Les rapports quotidiens individuels vous montrent ce qui a cassé aujourd’hui. Un digest hebdomadaire vous montre ce qui casse régulièrement, ce qui n’a jamais été testé, et quelles sources accumulent du retard progressivement. La vue hebdomadaire est le moment où les décisions structurelles sont prises : quels tests ajouter, quels problèmes récurrents doivent être escaladés vers les propriétaires des sources, quels modèles ont accumulé de la dette technique dans leur couverture de tests.
Les deux cycles sont des cron jobs séparés, pas un seul job qui agrège. Les garder séparés rend chacun plus simple et plus fiable, et le digest hebdomadaire est qualitativement différent d’un résumé quotidien — il invite à des types de décisions différents.
La structure du résumé quotidien
Un bon résumé matinal suit une structure cohérente. La cohérence importe parce qu’elle conditionne le lecteur : après une semaine à voir le même format, vous traitez la section critique en quelques secondes et passez directement au premier élément nécessitant une action.
Rapport de qualité des données, 2026-03-20 (7h00)
🔴 2 Critiques | 🟠 1 Élevé | 🟡 3 Moyens | 147/153 tests réussis
---
CRITIQUES
1. unique_mrt__sales__customers_customer__id — 3 lignes en double Modèle : mrt__sales__customers (7 dépendants en aval, 2 marts) Impact : Des clients en double signifient un revenu compté en double dans les tableaux de bord des ventes Contexte : Première occurrence → Vérifier la logique de déduplication dans base__shopify__customers
2. Fraîcheur source : raw_shopify.orders — 26 heures de retard Impact : Tous les modèles liés aux commandes sont obsolètes Contexte : Dernière occurrence il y a 2 semaines (fenêtre de maintenance fournisseur) → Vérifier le statut du connecteur Shopify. Si retard fournisseur, aucune action requise.
ÉLEVÉ
3. not_null_int__orders_enriched_order__customer_id — 12 lignes nulles Modèle : int__orders_enriched (4 dépendants en aval) Contexte : Échec intermittent depuis le 14 mars → Probablement lié au problème de fraîcheur source ci-dessus
MOYEN
4-6. [Échecs supplémentaires avec moins de détails]
---
Précédemment investigués (ignorés) :- Fraîcheur raw_ga4.events (noté le 18 mars : attendu le week-end)Quelques éléments de cette structure sont intentionnels :
Le résumé des comptages en haut (🔴 2 Critiques | 🟠 1 Élevé) vous indique l’ampleur avant que vous ne lisiez quoi que ce soit. Un bon jour, vous regardez le comptage vert et passez à autre chose. Un mauvais jour, deux cercles rouges vous indiquent qu’il s’agit d’une matinée de résolution d’incidents avant même d’avoir lu un seul échec.
Les échecs critiques obtiennent tous les détails, y compris l’impact, le contexte et une action suggérée. Les échecs élevés obtiennent des détails modérés. Les échecs moyens et inférieurs obtiennent des entrées tronquées — suffisamment pour savoir qu’ils existent sans encombrer le résumé. Cette hiérarchie signifie que le rapport est rapide à lire quand tout va bien et détaillé là où les détails sont nécessaires.
La section “précédemment investigués” en bas liste les échecs que l’agent connaît des précédentes exécutions et pour lesquels il a des notes contextuelles. Les montrer comme ignorés plutôt que les omettre silencieusement préserve la confiance — vous savez que l’agent en est conscient et n’est pas confus ; il sait simplement que vous avez déjà pris une décision.
Les actions suggérées (les lignes →) sont la partie la plus difficile à bien calibrer. Elles doivent être suffisamment spécifiques pour économiser du temps d’investigation sans être si présomptueuses qu’elles vous envoient sur la mauvaise piste. L’objectif est de nommer la première chose à vérifier, pas de diagnostiquer la cause racine. « Vérifier la logique de déduplication dans base__shopify__customers » est mieux que « Corriger le test unique » (trop vague) et mieux que « Le problème est que Shopify envoie des enregistrements clients en double en raison d’un bug de retry de webhook » (trop présomptueux).
Livraison Slack avec threading
Postez le résumé comme un message unique dans un canal Slack dédié. Utilisez un canal spécifiquement pour les alertes de qualité — séparé des canaux généraux de l’équipe data — pour que le rapport signal/bruit reste élevé.
Pour chaque échec Critique ou Élevé, créez une réponse en thread sous le message principal avec des détails supplémentaires : exemples de lignes en échec, la section pertinente de la documentation de schéma et la liste complète des modèles en aval. Le threading garde le canal principal lisible tout en préservant la profondeur pour les échecs qui nécessitent une investigation.
L’instruction pratique pour un agent :
## Livraison Slack
1. Poster le résumé principal comme un message unique dans #data-quality-alerts2. Pour chaque échec Critique : - Poster une réponse en thread sous le message principal - Inclure : exemples de lignes en échec (jusqu'à 5), liste complète des modèles en aval, description schema.yml pertinente pour la colonne en échec3. Pour chaque échec Élevé : - Poster une réponse en thread avec la liste des modèles en aval et la description de la colonne4. Ne pas threader les échecs Moyens ou FaiblesCette conception signifie que votre canal Slack reste lisible. Le message principal est le briefing. Les threads sont les matériaux d’investigation, disponibles sans ouvrir un terminal.
Suivi dans Slack
L’extension la plus pratiquement utile de ce pattern est de faire de Slack une interface bidirectionnelle. Après la publication du résumé matinal, vous pouvez répondre à un thread d’échec spécifique et poser des questions :
- « Montrez-moi les 3 IDs clients en double »
- « Quand ce test a-t-il réussi pour la dernière fois ? »
- « Est-ce lié au problème de fraîcheur source ? »
L’agent dispose du contexte complet de l’exécution matinale et de la mémoire persistante des exécutions précédentes. Les questions de suivi obtiennent des réponses contextuelles sans repartir d’une nouvelle investigation. Au lieu d’ouvrir un terminal, de se connecter à l’entrepôt et d’exécuter des requêtes manuellement, vous répondez dans le thread depuis votre téléphone et obtenez la réponse dans la même conversation.
Cela nécessite de configurer l’agent pour répondre aux messages Slack en plus de publier selon un calendrier — un mode différent du cron job sortant. La configuration dépend de votre plateforme d’agent, mais le pattern vaut le coût de configuration : il convertit Slack d’une destination de notifications en une interface de conversation.
Le digest hebdomadaire
Le digest hebdomadaire s’exécute sur un cron job le vendredi après-midi, après la dernière exécution dbt du jour ouvrable, et agrège les patterns des sept derniers jours.
Digest hebdomadaire de qualité des données — Semaine du 23-27 mars 2026
ÉCHECS RÉCURRENTS (3+ fois cette semaine)- not_null_int__orders_enriched_order__customer_id : 4/5 jours → Toujours non résolu. Recommande d'escalader vers le propriétaire des données source.
- source_freshness_raw_ga4_events : 2/5 jours (mar, mer) → Le pattern suggère des pics de volume en milieu de semaine qui retardent. Envisager d'ajuster le seuil de fraîcheur.
LACUNES DE COUVERTURE- 14 modèles n'ont aucun test (liste jointe) → Lacunes prioritaires : int__marketing__attribution (alimente 3 marts, aucun test)
MÉTRIQUES DE RÉSOLUTION- Échecs résolus le jour même : 3/5 cette semaine (60%)- Échec non résolu le plus ancien : not_null_int__orders_enriched (14 jours)
TENDANCE- Taux de réussite global : 96,2% cette semaine contre 97,8% la semaine dernière- Fiabilité de la fraîcheur source : en amélioration (2 échecs contre 5 la semaine dernière)La vue hebdomadaire révèle des décisions que les rapports quotidiens ne suscitent pas. Un échec qui se produit deux fois par semaine a une apparence différente dans un agrégat de 7 jours que dans deux rapports quotidiens individuels. Un modèle signalé comme ayant une couverture de tests nulle chaque jour semble évidemment problématique une fois qu’on le voit listé sept fois.
La section des échecs récurrents est particulièrement précieuse pour identifier les problèmes qui ne se résolvent pas. Un rapport quotidien crée de l’urgence. Un digest hebdomadaire crée de la responsabilité — si le même échec apparaît cinq fois dans une semaine, la revue hebdomadaire est le moment de décider de le corriger, de mettre à jour le test, ou d’accepter explicitement qu’il s’agit d’un comportement connu.
Résultats observés
L’application de ce pattern sur deux projets clients suggère environ 20 à 30 minutes de temps de triage matinal économisé par projet et par jour. Le digest hebdomadaire révèle des patterns qui s’accumulent lentement dans les rapports quotidiens : échecs de tests récurrents, lacunes de couverture de tests exprimées sous forme de liste avec les noms de modèles et les comptages d’impact en aval, et données de tendance sur les taux de réussite globaux.