Pour présenter les résultats de Great Expectations aux utilisateurs métier, il faut les sortir des outils de l’équipe data et les traduire en informations visibles là où les lecteurs travaillent déjà. Trois approches sont courantes : partager les Data Docs générés par Great Expectations, écrire les résultats dans une table de statuts lue par votre rapport Power BI, ou envoyer des alertes dans le canal utilisé par les équipes métier. Quelle que soit l’approche, ajoutez un message clair, le nom d’un responsable et une explication de ce que l’échec du contrôle implique pour le chiffre affiché.
En bref
- Les Data Docs sont utiles, mais leur organisation convient davantage aux personnes qui ont écrit les tests qu’aux lecteurs du rapport.
- Un utilisateur métier a besoin de trois informations : le chiffre du jour est-il utilisable, quel est le problème en termes simples et qui s’en occupe ?
- Une petite table de statuts lue par vos rapports, avec un responsable identifié pour chaque jeu de données, constitue souvent l’approche la plus directe.
Pourquoi les résultats des tests atteignent rarement les lecteurs du rapport
Beaucoup d’équipes data considèrent que le travail est terminé une fois les tests exécutés. Ce n’est pas le cas. Un contrôle en échec que seule l’équipe data voit ne change rien pour la personne qui consulte le rapport.
Prenons un exemple : le mardi matin, un contrôle sur la table des commandes échoue parce qu’un fichier source est arrivé à moitié vide. L’ingénieur data le voit dans les résultats de validation. À neuf heures, le responsable commercial ouvre le rapport hebdomadaire, constate une baisse des commandes et commence à demander des explications à son équipe.
Le résultat du contrôle existe bien. Il se trouve simplement dans un outil que les équipes métier n’ouvrent jamais, avec un vocabulaire qu’elles n’utilisent pas.
Option 1 : partager les Data Docs de Great Expectations
Great Expectations décrit les Data Docs comme une documentation statique, lisible par des personnes, construite à partir de vos Expectations et des résultats de validation. Vous pouvez les héberger sous forme de site statique : les personnes disposant du lien et des droits d’accès nécessaires peuvent alors consulter les contrôles réussis et ceux en échec.
C’est un bon point de départ pour les analystes. Pour les utilisateurs métier, le niveau de détail est souvent trop élevé. Une page qui énumère les Expectations par nom de colonne n’indique pas à un responsable financier si le chiffre d’affaires du mois est suffisamment fiable pour être présenté. Si vous choisissez cette approche, partagez uniquement les liens vers les pages de synthèse et ajoutez, pour chaque jeu de données, une phrase simple expliquant ce qu’un échec signifie.
Option 2 : écrire les résultats dans une table de statuts lue par votre rapport Power BI
C’est souvent l’approche la plus directe pour atteindre le lecteur du rapport. Après chaque exécution de validation, écrivez un petit enregistrement par jeu de données dans une table de votre entrepôt de données : nom du jeu de données, statut, date et heure de l’exécution, message en langage courant et responsable.
Ajoutez ensuite cette table au modèle sémantique et affichez son contenu dans le rapport : une carte de statut sur la première page, ou une ligne dans l’en-tête indiquant quand les données ont été contrôlées pour la dernière fois et si le contrôle a réussi.
- Restez bref. Un statut par jeu de données, pas un statut par Expectation.
- Écrivez pour le lecteur. « Les commandes de la boutique en ligne sont incomplètes pour la journée d’hier » est plus utile que « expect_column_values_to_not_be_null a échoué ».
- Nommez le responsable. Un lecteur qui voit un avertissement doit savoir à qui s’adresser.
La contrepartie : cette table de statuts est une implémentation que votre équipe construit et maintient, pas un connecteur natif de Great Expectations vers Power BI. Vous devez aussi prévoir son intégration dans chaque rapport qui en a besoin.
Option 3 : envoyer des alertes là où les équipes métier travaillent déjà
Les Checkpoints de Great Expectations peuvent exécuter des Actions après la validation, par exemple mettre à jour les Data Docs ou envoyer une notification dans un canal de discussion ou par e-mail, selon la configuration. Pour les jeux de données critiques pour l’activité, dirigez les alertes vers le canal que les responsables des rapports consultent réellement, et pas uniquement vers celui de l’équipe data.
Les alertes conviennent bien aux anomalies urgentes. Elles sont moins adaptées comme trace durable : un message envoyé le mardi peut déjà être noyé dans les échanges le jeudi, et une personne qui ouvre le rapport plus tard ne le verra pas nécessairement.
Ce que les utilisateurs métier attendent réellement d’un résultat de qualité
Quelle que soit l’approche choisie, vérifiez que le résultat répond aux trois questions du lecteur.
- Puis-je utiliser ce chiffre aujourd’hui ? Donnez un oui, un non ou un « avec prudence » clair, plutôt qu’un pourcentage de contrôles réussis.
- Quel est le problème, dans mon vocabulaire ? Une phrase sur l’impact métier, pas sur le test.
- Qui s’en occupe ? Une personne nommément identifiée, pas « l’équipe data ».
Comparaison des options
| Approche | Qui voit les résultats ? | Où ? | Effort de maintenance | Atteint le lecteur du rapport ? |
|---|---|---|---|---|
| Data Docs | Analystes et ingénieurs data | Un site statique distinct | Faible : documentation générée par Great Expectations | Rarement |
| Table de statuts dans le rapport | Lecteurs du rapport | Dans le rapport Power BI | Moyen : solution construite et maintenue par votre équipe | Oui, si le statut est affiché dans le rapport consulté |
| Alertes dans un canal | Les personnes présentes dans le canal | Messagerie ou e-mail | Faible après la mise en place | Surtout au moment de l’envoi |
| Catalogue regroupant les problèmes de qualité | Utilisateurs métier et responsables | Une vue d’ensemble, à côté des définitions et des responsables | Variable selon l’outil | Via un espace de découverte des données dans l’application, si les utilisateurs métier le consultent |
Une méthode pratique : tester, traduire, orienter, afficher, attribuer
- Tester : continuez à exécuter Great Expectations là où il fonctionne aujourd’hui. Cette démarche ne change rien à ce fonctionnement.
- Traduire : écrivez une phrase simple expliquant ce que chaque échec signifie pour le métier.
- Orienter : décidez, pour chaque jeu de données, où envoyer le résultat : dans une table de statuts, dans un canal de discussion, ou dans les deux.
- Afficher : placez un statut simple là où les lecteurs regardent, avec la date et l’heure du dernier contrôle.
- Attribuer : désignez, pour chaque jeu de données critique pour l’activité, un responsable qui répond aux questions à son sujet.
Commencez par cinq jeux de données
Great Expectations permet à l’équipe data de repérer ce qui a échoué. Ses résultats de validation ne disent toutefois pas, à eux seuls, au responsable commercial s’il peut se fier au rapport du lundi. Cette traduction vous revient : des mots simples, un responsable identifié et un statut là où les lecteurs regardent déjà. Commencez par les cinq jeux de données dont dépendent vos rapports de direction.
Questions fréquentes
Comment afficher les résultats de Great Expectations dans Power BI ?
Écrivez une synthèse de chaque exécution de validation dans une table de votre entrepôt de données, avec une ligne par jeu de données contenant le statut, la date et l’heure, ainsi qu’un message simple. Ajoutez cette table à votre modèle sémantique et affichez le résultat sous forme de carte de statut ou de ligne dans l’en-tête du rapport. Cette intégration est à construire et à maintenir par votre équipe.
Les utilisateurs métier peuvent-ils lire les Data Docs de Great Expectations ?
Ils peuvent les consulter s’ils y ont accès, mais les Data Docs sont organisés autour des Expectations et des colonnes, ce qui convient surtout aux personnes qui ont écrit les tests. La plupart des utilisateurs métier ont besoin d’un statut unique et d’une phrase sur l’impact. Ajoutez donc une synthèse si les Data Docs sont votre seul moyen de partager les résultats.
Comment alerter les utilisateurs métier lorsqu’un contrôle de qualité des données échoue ?
Configurez les Actions d’un Checkpoint pour envoyer une notification après la validation. Pour les jeux de données critiques pour l’activité, envoyez les alertes dans un canal que les responsables des rapports consultent réellement. Formulez le message en termes métier et indiquez qui s’occupe du problème.
Faut-il afficher les résultats de qualité des données dans chaque rapport ?
Non. Commencez par les rapports qui alimentent les décisions : rapports de direction, rapports financiers et rapports destinés au conseil d’administration. Afficher un statut dans chaque rapport risque rapidement de créer du bruit que plus personne ne lit.
Qui doit être responsable d’un problème de qualité des données visible par les utilisateurs métier ?
Une personne nommément identifiée par jeu de données, généralement le responsable métier plutôt que l’ingénieur qui a écrit le test. L’ingénieur corrige le pipeline de données. Le responsable indique aux lecteurs si le chiffre peut être utilisé.