digna Data Reconciliation : vos tables cibles correspondent-elles encore à leurs sources ?

Toute plateforme de données regorge de tables construites à partir d'autres tables : des agrégats quotidiens calculés à partir de lignes de transactions, des data marts assemblés à partir d'une dizaine de systèmes sources. Chacun de ces chargements peut se terminer sans erreur et produire malgré tout une cible qui ne concorde plus avec les données dont elle provient, parce qu'un filtre a changé, qu'un fichier arrivé en retard a été ignoré ou qu'une jointure a discrètement perdu des lignes. Savoir si les chiffres tombent toujours juste, c'est la vraie question, et on y répond généralement à la main, quand on y répond.

digna est une plateforme de Data Quality & Observability, et digna Data Reconciliation, nouveauté de la Release 2026.11, pose cette question pour vous chaque jour. Il compare une source de données cible aux sources à partir desquelles elle a été construite et vous alerte dès qu'elles ne concordent plus. Cette courte vidéo présente les deux types de règles dans les projets de démonstration de digna, avec des données fictives et le vrai produit.

Configuré sur la cible

Le rapprochement part de la table dont l'exactitude vous importe. Vous ouvrez la source de données cible, allez dans son Data Reconciliation tab et y définissez les règles, en utilisant comme sources toutes les sources de données du projet pour lesquelles la réconciliation est activée.

Il existe deux types de règles, car certaines relations sont simples et exactes, tandis que d'autres impliquent de nombreuses sources et transformations que personne ne souhaite réécrire sous forme de contrôle.

Des règles exactes pour les rapprochements que vous connaissez déjà

Une règle exacte fonctionne comme une règle de qualité des données pour une source et une cible. Vous associez des contrôles par statistique et par attribut, par exemple un nombre de lignes dans la cible face à un nombre de lignes dans la source, ou une somme de montants face à la même somme un niveau plus bas, et vous fixez une tolérance absolue ou relative. La frise chronologique montre ensuite l'écart de chaque jour par rapport à cette tolérance, ce qui vous permet de voir si un écart est ponctuel ou s'il se creuse depuis des semaines.

Dans la démo retail, l'agrégat quotidien des ventes pos_sales_daily est comparé aux lignes de vente dont il est issu, pos_sales_lines, en associant le chiffre d'affaires brut au chiffre d'affaires calculé à partir des lignes, avec une tolérance de ± 0,01 %. Le 26 août, l'agrégat affichait 51 747 € alors que ses propres lignes totalisaient 66 205 €, soit une cible inférieure de 21,8 % et très au-delà de la tolérance.

Les équipes finance, risques et contrôle de gestion effectuent déjà ce type de contrôle dans le cadre de leurs procédures de rapprochement standard ; sous forme de règles exactes, ils sont définis une seule fois et exécutés à chaque inspection.

Des règles IA pour les cibles construites à partir de nombreuses sources

Les règles exactes cessent d'être pratiques dès qu'une cible est assemblée à partir de nombreuses tables via des jointures, des filtres et des agrégations, car la contrôler ainsi revient à maintenir une seconde copie de la logique du pipeline.

Les règles IA empruntent une autre voie. Vous combinez des contrôles issus de plusieurs sources avec une cible, sans jointures, filtres ni agrégations à définir et sans SQL à écrire. Un modèle apprend de l'historique comment la cible suit ses sources et vous alerte lorsque la cible sort de la bande des erreurs passées de la règle. Chaque règle IA dispose de trois paramètres, Sensitivity, Memory et Model Complexity, pour l'ajuster à cette cible précise.

Dans la démo, un data mart de commandes est construit à partir de dix tables sources. Le 6 octobre, il contenait 1 742 commandes alors que ses sources en prévoyaient environ 2 771, soit un millier de moins, et la règle l'a détecté sans que personne n'ait eu à décrire comment le data mart est assemblé à partir de ces dix tables.

Dans le Dashboard et dans vos notifications

Les contrôles de rapprochement apparaissent dans le Dashboard avec une frise chronologique pour chaque règle. Ils sont pris en compte dans le statut global d'inspection, aux côtés de vos autres contrôles, et déclenchent des notifications, afin que les bonnes personnes soient informées d'un écart le jour même.

À qui cela profite

Les data engineers disposent d'un moyen direct de valider les résultats ETL : non seulement qu'un chargement s'est exécuté, mais que son résultat correspond toujours à ses données d'entrée. Les équipes finance, risques et contrôle de gestion retrouvent leurs rapprochements standard sous forme de règles exactes avec un historique visible. Et comme digna fonctionne on-premises ou dans votre cloud privé, vos données ne quittent jamais votre infrastructure pendant leur contrôle. La documentation de Data Reconciliation explique comment configurer les deux types de règles.

digna Data Reconciliation est arrivé avec la Release 2026.11, en même temps que digna Agentic et le digna Engine, et la présentation de la release montre comment les trois s'articulent.

Faites la visite du produit pour voir digna Data Reconciliation et le reste de la plateforme en action.

Questions fréquentes

Que compare digna Data Reconciliation ?

Il compare une source de données cible aux sources à partir desquelles elle a été construite et vous alerte dès qu'elles ne concordent plus. Les règles se configurent dans le Data Reconciliation tab de la cible, et toute source de données du projet pour laquelle la réconciliation est activée peut servir de source.

Quelle est la différence entre les règles exactes et les règles IA ?

Une règle exacte relie une source et une cible, associe des contrôles par statistique et par attribut, comme des nombres de lignes ou des sommes de montants, et applique une tolérance absolue ou relative. Une règle IA combine des contrôles issus de plusieurs sources avec une cible, apprend de l'historique comment la cible les suit et alerte lorsque la cible sort de la bande des erreurs passées de la règle.

Dois-je écrire du SQL ou définir des jointures pour les règles IA ?

Non. Une règle IA ne nécessite ni jointures, ni filtres, ni agrégations, et il n'y a pas de SQL à écrire. Vous pouvez ajuster chaque règle avec ses paramètres Sensitivity, Memory et Model Complexity.

Comment les résultats du rapprochement sont-ils présentés ?

Chaque règle dispose de sa propre frise chronologique dans le Dashboard. Les contrôles de rapprochement sont pris en compte dans le statut global d'inspection et déclenchent des notifications, comme les autres contrôles de digna.