+Comparaison / Plateformes data

APRÈS TRANSFORMATION, LE RÉSULTAT VEUT-IL ENCORE DIRE LA MÊME CHOSE ?

Une donnée peut être exacte au départ et devenir trompeuse après plusieurs traitements. DataAuthority travaille sur cette étape précise : vérifier que le résultat veut encore dire la même chose que ce que la source permettait d’affirmer.

01 / L’exemple

UNE ABSENCE N’EST PAS UN ZÉRO.

Une source ne donne aucune valeur pour les pharmacies d’une commune.

Est-ce que cela veut dire 0 pharmacie ? Pas forcément. Cela peut simplement vouloir dire information absente.

Dans un tableau, ces deux réponses se ressemblent. Elles ne veulent pas dire la même chose. Une valeur calculée à partir d’un zéro supposé n’a pas la même portée qu’une valeur calculée à partir d’un vide.

Le point de départ : un même chiffre peut être exact et pourtant conduire à une conclusion trop forte, simplement parce que ce qui manquait a disparu en chemin.

02 / La question

APRÈS TOUTES LES TRANSFORMATIONS, LE RÉSULTAT VEUT-IL ENCORE DIRE LA MÊME CHOSE ?

Croiser deux fichiers, retirer des lignes, regrouper des catégories ou calculer une moyenne peut changer la portée d’un résultat. La donnée reste exacte ; c’est le sens du résultat qui se déplace.

C’est cette question que DataAuthority met au premier plan. Elle est simple à énoncer et exigeante à tenir, parce qu’il faut la vérifier après chaque étape, pas seulement à l’arrivée.

03 / Ce que nous gardons visible

SIX CHOSES QUI RESTENT VISIBLES JUSQU’AU RÉSULTAT.

Pour répondre à cette question, DataAuthority conserve les éléments qui permettent d’interpréter un résultat — et d’en refuser un usage excessif.

  • La source : d’où vient l’information et quelle version a été utilisée.
  • Les transformations : filtres, jointures, regroupements et calculs appliqués.
  • Les absences : ce qui manque reste signalé comme manquant.
  • Les contradictions : un désaccord entre deux sources reste visible.
  • La période et le contexte : la date et les conditions de production restent attachées.
  • La couverture et les limites : ce que la source observe réellement, et ce qu’elle ne permet pas de conclure.

DataAuthority est spécialisé sur ce point précis : garder ces distinctions jusqu’au résultat final, plutôt que de les laisser se dissoudre dans la sortie.

04 / IA

UNE IA PEUT UTILISER LES DONNÉES. ELLE NE DOIT PAS DEVINER CE QUI MANQUE.

Une IA peut très bien connaître la source d’une donnée et malgré tout tirer une conclusion trop forte. Si elle ne sait pas qu’une information manque, qu’une couverture est partielle ou que deux sources se contredisent, elle peut produire une réponse convaincante et trompeuse.

DataAuthority transmet donc aux systèmes d’IA non seulement les données, mais aussi les limites qui les accompagnent : ce qui est observé, ce qui est absent, ce qui est incertain.

05 / Le paysage

QUATRE FAMILLES D’OUTILS QUI TRAITENT DES QUESTIONS DIFFÉRENTES.

Le sujet de la donnée est déjà couvert par des familles d’outils bien distinctes. Les citer aide à situer la question ; cela ne dispense pas de la tester.

01

TRAÇABILITÉ / DATA LINEAGE

Suivre le chemin d’une donnée, de ses sources à ses usages, parfois jusqu’au niveau de la colonne. On y trouve Palantir Foundry, Informatica, Collibra, Databricks (Unity Catalog), Alation et OpenMetadata.

02

CATALOGUE ET GOUVERNANCE

Recenser les jeux de données, les définitions, les responsables et les règles d’usage. On y trouve Collibra, Informatica, Alation, Atlan et OpenMetadata.

03

CONTEXTE, QUALITÉ ET IA

Rapprocher les données de leur contexte métier, de la qualité et des usages liés à l’IA. On y trouve Atlan et Alation.

04

PROVENANCE STANDARDISÉE

Décrire formellement l’origine et l’histoire d’une information : entités, activités et acteurs. Le W3C PROV en donne le modèle de référence.

Ces familles répondent au comment : comment la donnée circule, qui la gouverne, où elle est cataloguée. Le travail présenté ici porte sur une étape complémentaire et précise : vérifier ce que le résultat permet d’affirmer — et ce qu’il ne permet pas.

Sources officielles : les capacités citées ci-dessus peuvent être vérifiées sur la documentation de chaque acteur — Palantir Foundry, Collibra, Informatica, Databricks, Atlan, Alation, OpenMetadata et W3C PROV. Une capacité non documentée n’est pas présentée ici comme absente.

06 / Le test

UN BENCHMARK UTILE PART DU RÉSULTAT, PAS DU DÉBIT.

Un benchmark classique compare la vitesse, le prix, le nombre de connecteurs ou le volume traité. C’est utile, mais cela ne répond pas à la question du sens.

Le test qui aurait du sens serait de donner à plusieurs systèmes le même jeu de données imparfait — une vraie valeur zéro, une valeur manquante, un doublon, deux sources contradictoires, deux années différentes, une couverture partielle — puis de poser les mêmes questions à chacun :

  • Une absence reste-t-elle une absence ?
  • Une contradiction reste-t-elle visible ?
  • Peut-on retrouver la source du résultat ?
  • La période reste-t-elle visible ?
  • La couverture partielle reste-t-elle visible ?
  • Le système sait-il refuser une conclusion trop forte ?

Cette comparaison reste à tester. C’est le type de protocole que nous proposons lorsque nous travaillons sur un jeu de données.

07 / Vocabulaire

UN ATOM : UN FAIT, SA SOURCE, SON CONTEXTE, SES LIMITES.

DataAuthority utilise le mot atom. Un atom, c’est simplement un petit fait auquel on garde attachés son origine, son contexte et ses limites.

Par exemple, au lieu de conserver seulement « 12 commerces », on garde aussi, autant que possible : la source, la période, la catégorie, les transformations, les absences éventuelles et les contradictions éventuelles.

Précision : « atom » n’est pas un standard officiel. C’est le vocabulaire de travail de DataAuthority.

08 / En une phrase

LA DIFFÉRENCE EN UNE PHRASE.

DataAuthority protège le sens des données quand elles sont transformées.

Et la question à retenir reste simple : après toutes les transformations, le résultat veut-il encore dire la même chose ?