Toute personne qui travaille avec des données a déjà reçu cet appel. Un chiffre d’un rapport est faux, et quelqu’un doit comprendre pourquoi avant le début de la réunion. L’enquête qui suit est presque toujours la même : quel flux, quel chargement, quelle colonne, jusqu’où l’erreur s’est-elle propagée, et que faisons-nous maintenant ?

Depuis vingt ans, les outils progressent régulièrement sur une partie de ce travail : la détection. Les règles repèrent ce que quelqu’un avait anticipé. L’observabilité repère ce qui a bougé. Mais entre l’alerte et la correction, il reste une personne, une file d’attente et, très souvent, un lundi matin.

Cet article pose la question de savoir si cela doit rester ainsi. Les données peuvent-elles se corriger elles-mêmes ? La réponse honnête : en partie, sous des conditions que l’on peut formaliser par écrit. Et ces conditions s’avèrent plus intéressantes que l’automatisation elle-même.

Qualité des données et observabilité des données : deux disciplines, aucune ne suffit seule

La qualité des données est la mesure dans laquelle les données sont adaptées à l’usage qui en est fait, évaluée par rapport à une attente que quelqu’un a dû formuler par écrit. C’est une propriété des données elles-mêmes : valeurs, clés, relations. Elle est relative à un usage, car une heure de départ suffisamment précise pour un rapport mensuel ne l’est pas pour déposer une demande de créneau aéroportuaire. Et elle est déclarative. Une règle ne trouve jamais que ce à quoi quelqu’un avait déjà pensé.

L’observabilité des données est la capacité à comprendre l’état de santé et le comportement de vos données à partir des signaux qu’elles émettent, sans savoir à l’avance ce qui va mal tourner. Fraîcheur, volume, schéma, distribution et lignage sont appris à partir de l’historique plutôt que spécifiés par les métiers, ce qui permet à l’observabilité de couvrir chaque table. C’est aussi sa limite : l’observabilité peut vous dire que quelque chose a changé, jamais que quelque chose est faux.

Aucune des deux disciplines ne contient l’autre. Prenons un temps bloc de 92 minutes sur une ligne qui en demande normalement 148. Le nombre de lignes est normal, la table est à jour, le schéma n’a pas changé et la valeur se situe confortablement dans n’importe quelle plage globale. Elle passe tous les contrôles et elle est pourtant fausse. C’est l’écart décrit dans notre article sur les données qui semblent fausses mais passent vos règles, et la comparaison complète des deux disciplines se trouve dans Observabilité des données vs qualité des données.

Qu’est-ce que la qualité des données autonome ?

La qualité des données autonome est la capacité continue, en grande partie pilotée par l’IA, à détecter, analyser, évaluer et corriger les problèmes de qualité des données avec un minimum d’intervention humaine. Quatre verbes, et ce sont les trois derniers qui la distinguent des outils dont la plupart des équipes disposent déjà :

• Détecter : quelque chose a suffisamment bougé pour mériter l’attention.

• Analyser : quel flux, quel chargement, quelle colonne.

• Évaluer : la gravité du problème et ce qui en dépend.

• Corriger : mettre en quarantaine, suspendre ou relancer, et consigner précisément ce qui a été fait.

Presque tous les produits du marché s’arrêtent aujourd’hui après le premier verbe. Comme l’observabilité, la qualité des données autonome s’adapte : les seuils et les priorités suivent les données au lieu de rester figés au jour où quelqu’un les a définis. Concrètement, il s’agit d’utiliser les signaux produits par l’observabilité pour générer le travail de qualité qui exigeait auparavant des règles.

Pourquoi cela devient possible maintenant

Deux choses changent en même temps. La première est la forme de la plateforme de données. L’entrepôt central, détenu par une seule équipe qui s’était mise d’accord sur ce qu’était un client ou un passager, laisse la place à des produits de données dotés de leurs propres responsables, contrats et cycles de publication. La qualité doit désormais tenir à chaque frontière que les données franchissent, pas seulement à leur point d’arrivée, et plus personne ne possède la chaîne dans son ensemble.

La seconde est l’arrivée d’agents au-dessus de cette plateforme. Un agent n’a pas besoin qu’on lui dise comment. Il a besoin qu’on lui dise quoi, et jusqu’où il peut aller. Prenons un rechargement de routine. Aujourd’hui, un ingénieur retrouve la procédure stockée et ses paramètres, l’API source avec son authentification et sa pagination, écrit la logique de nouvelle tentative et de gestion des erreurs, puis réécrit le tout lorsqu’un partenaire modifie son export. Avec un agent, l’instruction devient une phrase : recharger les données d’embarquement d’hier pour un vol. L’agent trouve la procédure et l’API dans le catalogue, ordonne les appels, relance si nécessaire et vérifie lui-même le nombre de lignes.

C’est un modèle d’intégration différent de tout ce que nous avons construit jusqu’ici. Nous passerons moins de temps à spécifier comment un rechargement se déroule, et davantage à spécifier ce qui peut être rechargé, par qui, et sans demander.

Un tronçon de vol, cinq réponses différentes

Pour rendre cela concret, prenons Alpenwing Airways, une compagnie européenne fictive de taille moyenne dont les problèmes sont, eux, bien réels. Sept systèmes décrivent le même vol : les réservations, le contrôle des départs, la base de données opérationnelle de l’aéroport, la maintenance, la planification des équipages, la comptabilité des recettes et les flux de onze partenaires en partage de codes. Aucun d’eux n’est faux. Ils ont été conçus pour des tâches différentes à des époques différentes, et c’est dans l’entrepôt que leurs désaccords deviennent visibles. Voici ce que fait un agent face à cinq alertes sur un seul tronçon de vol, le WG 402 de Vienne à Varsovie.

1. Un flux partenaire passe du jour au lendemain des codes aéroport IATA aux codes ICAO

La longueur moyenne de la colonne de l’aéroport de départ passe de 3,00 à 4,00 sur une seule source, et 1 284 lignes échouent au contrôle des valeurs autorisées. Rien d’autre n’a bougé sur ce flux. Un Data Steward a approuvé la correspondance LOWW vers VIE il y a des mois, le registre ICAO publié la confirme et la correction est réversible. C’est le cas le plus simple qui soit, et il est proche de ce qui est possible aujourd’hui.

2. Le vol embarque 36 passagers dans un avion de 180 sièges

Un coefficient de remplissage de 0,20, sur une ligne qui n’est pas descendue sous 0,72 depuis deux ans, alors que tous les autres tronçons de la journée paraissent normaux. Il existe un modèle approuvé exactement pour ce cas : recharger le tronçon, puis le vérifier par rapport à un second comptage indépendant issu du système de réservation. Le lignage montre que trois data marts et le rapport d’exploitation quotidien en dépendent, l’agent les suspend donc jusqu’à ce que le comptage soit confirmé.

3. Le contrôle des départs compte 168 passagers, la base de données aéroportuaire en compte 171

Une réconciliation planifiée échoue pour trois passagers, et l’observabilité ne voit strictement rien : 168 est un nombre normal, 171 aussi. La différence s’avère être une question de définition. Un nourrisson voyageant sur les genoux d’un adulte est-il un passager ? Aucune entrée du catalogue n’y répond et aucun modèle approuvé ne couvre ce cas. L’agent peut mener toute l’analyse. La définition reste une décision humaine.

4. Le flux opérationnel de l’aéroport a trois heures de retard

Le flux arrive normalement avant 02h30. À 05h40, il n’est toujours pas là, et le rapport d’exploitation est attendu à 06h00. Aucune règle de qualité des données ne se déclenche, car les données ne sont pas fausses : elles sont simplement absentes. Différer les chargements dépendants en cas d’arrivée tardive est un modèle approuvé ; l’agent s’appuie donc sur le lignage et le journal de chargement pour suspendre exactement les rapports qui, sinon, tourneraient sur les chiffres de la veille, et rien d’autre.

5. La ville de destination arrive en texte libre

Wiedeń, Viena et Wien désignent toutes Vienne. Le nombre de valeurs distinctes passe de 41 à 63 en une journée, et 2 140 lignes ne correspondent à aucune liste de référence. L’internet ouvert est utile pour apprendre que Wiedeń est le nom polonais de Vienne, mais il ne suffit jamais à lui seul. Une correspondance n’est sûre que par rapport à un domaine déclaré : les 94 aéroports qu’Alpenwing dessert réellement. C’est la direction que prend la technologie, plutôt que son état actuel.

Les quatre contrôles qui décident si un agent peut agir seul

Chacun de ces scénarios passe par la même porte, construite à partir de quatre questions vérifiables. Aucune d’entre elles n’est la confiance du modèle lui-même, qui n’est pas calibrée et ne devrait jamais être la raison pour laquelle un entrepôt est modifié.

• Ce modèle précis a-t-il déjà été approuvé ? Si un Steward l’a approuvé une fois, la dixième occurrence relève de la consultation plutôt que du jugement. C’est le signal le plus fort à lui seul, mais il n’est ni nécessaire ni suffisant.

• L’action est-elle réversible ? Quarantaine, suspension, nouvelle demande et rechargement peuvent tous être annulés. L’écrasement d’une valeur sur place, non. Les actions réversibles méritent beaucoup plus de liberté.

• La source fait-elle autorité et est-elle datée ? Un registre publié avec une date de publication justifie d’agir. Une réponse plausible sans citation, non, aussi assurée qu’elle paraisse.

• Quelle est l’étendue de l’impact ? Une ligne mise en quarantaine n’est pas comparable à une dimension à laquelle chaque data mart est joint, qui elle-même n’est pas comparable à un chiffre déjà déclaré à un régulateur.

L’ordre dans lequel un agent consulte ses sources compte tout autant. Votre propre base de connaissances vient en premier : le catalogue, le lignage, les contrats et la bibliothèque de modèles approuvés. Les registres publiés viennent en second. L’internet ouvert ne sert qu’à s’orienter, et la mémoire propre du modèle est la source la plus faible de toutes, car une réponse que personne n’a vérifiée est impossible à distinguer d’une réponse documentée. Un agent qui ne peut pas citer sa source n’a pas le droit d’agir.

La liberté accordée à l’agent se règle par domaine et par produit de données, jamais une fois pour toute l’entreprise. Une banque réglementée peut n’autoriser que des propositions, chacune attendant un approbateur nommé. Les données opérationnelles d’une compagnie aérienne peuvent laisser les actions réversibles s’exécuter seules, tandis que tout ce qui est irréversible est proposé. Un produit de données marketing peut exécuter la plupart des corrections sans surveillance et être revu chaque semaine de manière agrégée. Et quel que soit le réglage, chaque action porte ses preuves, chaque action peut être annulée individuellement, et les modèles approuvés sont surveillés et expirent, car le monde peut évoluer sous un modèle qui était juste autrefois.

Ce que la qualité des données autonome ne sait toujours pas faire

Les limites se sont déplacées. Elles n’ont pas disparu, et trois d’entre elles sont permanentes.

• Elle ne peut pas inventer une source de vérité. Le fait qu’un passager ait réellement embarqué est enregistré par le scan d’embarquement et nulle part ailleurs. Si les deux copies d’un chiffre sont fausses en même temps, la réconciliation les confirmera sans broncher, car elle compare au lieu de vérifier.

• Elle ne peut pas définir la finalité. Savoir si un nourrisson compte comme passager, quel système fait autorité et si l’historique peut être retraité après qu’un chiffre a été déclaré à un régulateur relève de décisions métier. Quelqu’un doit en être responsable, par écrit.

• Elle ne corrige pas la source amont. Un flux réparé en silence pour toujours est un flux qui n’est jamais réparé à la source, car le fournisseur ne ressent jamais le problème. C’est pourquoi chaque correction automatique doit tout de même être signalée.

Ce que devient le rôle du Data Steward

Chaque équipe data connaît ce lundi matin : quarante et une alertes accumulées pendant le week-end, dont trois sont de vrais problèmes. La qualité des données autonome ne fait pas disparaître cette pile. Elle en supprime la partie répétitive.

Ce qui disparaît : relire la même alerte pour la quarantième fois, relancer un partenaire à propos d’un flux de nouveau cassé, et relancer des chargements à la main à sept heures du matin. Ce qui le remplace : maintenir la bibliothèque de modèles de résolution approuvés, décider de ce que signifie réellement une valeur ambiguë, auditer les décisions de l’agent de manière agrégée et fixer la liberté accordée à chaque produit de données. Le Data Steward cesse de corriger des problèmes un par un et commence à décider de la manière dont les problèmes sont corrigés. C’est un poste plus senior que celui qu’occupent aujourd’hui la plupart des stewards, plus proche de la politique que des opérations. Personne n’est supprimé. C’est le travail qui passait mal à l’échelle qui l’est.

Le mot de la fin : précédent, réversibilité et preuves, pas confiance

Un agent généraliste disposant d’identifiants de base de données n’est pas de la qualité des données autonome. Sans catalogue, il ne sait pas si une colonne contient un code ou un libellé, et il devine avec aplomb. Sans lignage, il ne peut ni délimiter une relance ni évaluer l’étendue de l’impact. Sans bibliothèque de modèles, chaque occurrence est la première, rien ne se capitalise et le Steward ne récupère jamais de temps. Sans ces trois éléments, un modèle de langage ne devrait pas approcher votre entrepôt.

C’est pourquoi la qualité des données autonome a sa place à l’intérieur de la plateforme de qualité des données plutôt qu’à côté. Les fondations doivent déjà être en place : digna Data Anomalies apprend à quoi ressemble la normalité sans seuils manuels, digna Data Validation applique des règles auditables au niveau de l’enregistrement, digna Timeliness apprend les schémas d’arrivée en complément des plannings que vous déclarez, digna Schema Tracker détecte les changements structurels et digna Data Analytics suit l’évolution des métriques elles-mêmes dans le temps. Le tout s’exécute in-database, sans que les données quittent votre environnement. Le gradient de confiance, la porte d’autonomie, la piste de preuves et la bibliothèque de modèles décrits ici sont la direction vers laquelle digna construit.

Les données peuvent-elles se corriger elles-mêmes ? Pas seules. Mais avec le précédent, la réversibilité et les preuves en place, une part croissante d’entre elles peut être corrigée sans attendre le lundi.

Découvrez les fondations sur lesquelles repose la qualité des données autonome.

digna apprend à quoi ressemble la normalité sur chaque table, in-database, dans le cloud ou on-premise, sans seuils manuels à maintenir. C’est la couche de preuves dont un agent a besoin avant qu’on puisse lui faire confiance pour agir.

Réserver une démo personnalisée → Découvrir la plateforme digna

Questions fréquentes

Qu’est-ce que la qualité des données autonome ?

La qualité des données autonome est la capacité continue, en grande partie pilotée par l’IA, à détecter, analyser, évaluer et corriger les problèmes de qualité des données avec un minimum d’intervention humaine. La plupart des outils s’arrêtent à la détection ; la partie autonome, c’est l’analyse, l’évaluation de l’impact et une correction consignée et réversible.

En quoi la qualité des données autonome diffère-t-elle de l’observabilité des données ?

L’observabilité des données apprend des références de fraîcheur, de volume, de schéma et de distribution, et vous signale qu’un élément a changé. La qualité des données autonome utilise ces signaux comme déclencheurs, puis analyse la cause, évalue ce qui dépend des données et prend une action encadrée, comme une quarantaine, une suspension ou un rechargement.

Quand un agent IA peut-il corriger des données seul ?

Quatre contrôles en décident : le modèle précis a-t-il déjà été approuvé, l’action est-elle réversible, la source fait-elle autorité et est-elle datée, et quelle est l’étendue de l’impact. La confiance du modèle lui-même n’en fait jamais partie, car elle n’est pas calibrée.

À quelles sources un agent de qualité des données doit-il se fier ?

D’abord à sa propre base de connaissances : le catalogue, le lignage, les contrats et les modèles approuvés. Les registres publiés, comme les listes de codes IATA ou ICAO, viennent en second. L’internet ouvert ne sert qu’à s’orienter, et la mémoire non sourcée du modèle est la source la plus faible. Un agent incapable de citer sa source ne doit pas agir.

La qualité des données autonome va-t-elle remplacer le Data Steward ?

Non. Elle supprime la partie répétitive du travail, comme relire la même alerte ou relancer des chargements à la main. Le Steward se consacre à la bibliothèque de modèles de résolution approuvés, décide de ce que signifient les valeurs ambiguës et fixe la liberté accordée à chaque produit de données, un rôle plus proche de la politique que des opérations.