Comprendre DataAuthority
DataAuthority : croiser des données sans leur faire dire ce qu’elles ne disent pas
Fusionner des données est relativement facile. Savoir jusqu’où on peut faire confiance au résultat l’est beaucoup moins.
Imaginez trois fichiers : l’un contient des données démographiques, le deuxième des informations sur des commerces, le troisième des données sur l’accès aux services.
On peut les réunir avec Excel, R, Python, SQL ou un logiciel de BI. Mais très vite, d’autres questions apparaissent : les données parlent-elles de la même période ? Les territoires sont-ils définis de la même manière ? Une case vide signifie-t-elle zéro ou information inconnue ? Pourquoi deux sources donnent-elles des chiffres différents ? D’où vient précisément le nombre affiché à la fin ? Et surtout : les données permettent-elles réellement de répondre à la question posée ?
C’est à ce problème que s’intéresse DataAuthority.
Le but n’est pas seulement de fusionner des données. Le but est de préserver ce qu’il faut savoir pour ne pas leur faire dire plus qu’elles ne disent réellement.
Le problème n’est souvent pas le calcul
Prenons un exemple simple.
Dans une commune de 5 237 habitants, une source indique 804 personnes âgées : 804 est le nombre de personnes âgées, 5 237 la population totale de la commune.
On peut donc calculer :
804 ÷ 5 237 = 15,35 %
et écrire :
« Les personnes âgées représentent 15,35 % de la population de cette commune. »
Mathématiquement, le calcul est correct. Mais avant de considérer ce résultat comme fiable, il faut encore comprendre ce que représentent réellement les deux nombres.
- Les 804 personnes âgées et les 5 237 habitants proviennent-ils de la même source ?
- Concernent-ils la même année ? Le même territoire ?
- Quelle définition de « personne âgée » est utilisée ?
- Le chiffre de population correspond-il bien à la même population de référence ?
- Certaines données étaient-elles absentes ?
- Des transformations ont-elles été effectuées ?
- Une autre source donne-t-elle un résultat différent ?
C’est tout l’enjeu de la provenance des données : un pourcentage peut être mathématiquement exact tout en étant difficile à interpréter si l’histoire de ses données a été perdue.
Après plusieurs traitements, une partie de cette histoire peut disparaître. Il ne reste alors qu’un chiffre exact mathématiquement, mais dont il devient beaucoup plus difficile de vérifier le sens.
DataAuthority est conçu pour conserver autour du résultat les informations disponibles qui permettent de reconstruire son histoire :
Valeur : 15,35 % Numérateur : 804 Dénominateur : 5 237 Formule : 804 / 5 237 Source : ... Période : ... État : ... Limites : ... Désaccords éventuels : ...
Le résultat n’est pas forcément différent. Ce qui change, c’est ce que l’on sait encore de lui.
Ces informations ne sont pas systématiquement complètes : ce que DataAuthority peut rattacher à un fait dépend des contrats disponibles pour le cas traité. Selon les cas, la provenance requise peut être complète, partielle ou encore en cours de durcissement — nous ne présentons pas cette exigence comme une garantie universelle.
Une case vide n’est pas zéro
| Commune | Nombre de commerces |
|---|---|
| Commune A | 12 |
| Commune B | 0 |
| Commune C | — |
Pour la commune B, nous savons que la valeur est zéro. Pour la commune C, nous ne savons peut-être simplement pas.
Pourtant, après plusieurs importations, transformations et jointures, une information absente peut finir par être assimilée à zéro. Alors « nous n’avons pas la donnée » devient « il n’y en a aucun ». Ce n’est plus la même information.
DataAuthority distingue donc plusieurs situations :
- 0 : la valeur est connue et vaut réellement zéro ;
- ABSENT : une information attendue n’est pas présente ;
- UNKNOWN : les données disponibles ne permettent pas de connaître la valeur ;
- CONFLICT : plusieurs informations incompatibles existent pour le même fait.
Cette distinction, détaillée dans Donnée absente ≠ zéro, paraît minuscule. Elle peut pourtant changer une conclusion entière.
Deux sources peuvent ne pas être d’accord
Prenons un autre exemple fictif : deux sources comptent le même type d’établissement, sur le même territoire et pour la même période supposée.
Elles indiquent :
Source A : 47 établissements Source B : 52 établissements
Il existe parfois une excellente raison de retenir l’une des deux : date plus récente, définition différente, meilleure couverture ou règle méthodologique particulière.
Le problème n’est donc pas de choisir. Le problème serait de choisir et de faire ensuite disparaître le fait qu’un désaccord existait.
DataAuthority peut conserver cette situation explicitement :
CONFLICT Source A : 47 Source B : 52
Le désaccord devient lui-même une information. Il peut être traité, expliqué ou bloquer certains usages, mais il ne disparaît pas simplement parce qu’un logiciel attend une seule valeur. C’est le principe développé dans Contradictions entre sources.
La question la plus importante vient avant le résultat
Lorsqu’un logiciel reçoit des données et une question, son fonctionnement naturel consiste généralement à essayer de produire une réponse.
DataAuthority ajoute une étape :
Les données disponibles permettent-elles réellement de soutenir cette réponse ?
Prenons la question : « Quel territoire offre le meilleur accès aux services pour les personnes âgées en 2025 ? »
Nous pouvons posséder beaucoup de données, mais certaines peuvent dater de 2021, d’autres de 2024, certaines communes peuvent ne pas être couvertes, certaines valeurs être inconnues et deux producteurs peuvent être en désaccord.
Il est techniquement possible de calculer quelque chose. Cela ne signifie pas forcément que ce quelque chose est défendable.
Selon les règles et les données de la mission, DataAuthority peut distinguer des situations comme :
Réponse possible Réponse possible avec limites Réponse non suffisamment justifiée
avec les raisons correspondantes.
Le système ne demande donc plus seulement : « Puis-je calculer quelque chose ? » mais aussi : « Puis-je réellement affirmer cela à partir des preuves disponibles ? »
DataAuthority ne remplace pas le statisticien
Un bon statisticien connaît déjà ces problèmes. Il vérifie ses sources, documente ses hypothèses, analyse les valeurs manquantes, contrôle les périodes et explique les limites de son étude.
DataAuthority ne prétend pas avoir inventé cette rigueur.
Son objectif est de faire en sorte qu’une partie de cette rigueur ne repose plus uniquement sur la mémoire de la personne qui a réalisé l’étude.
La difficulté change d’échelle lorsqu’il faut suivre plusieurs dizaines de sources, des centaines de territoires, des milliers ou des millions de faits, plusieurs générations de traitements, puis permettre à des logiciels ou à des IA de réutiliser les résultats.
Un statisticien peut maintenir cette discipline sur une étude. DataAuthority cherche à la rendre systématique et vérifiable par la machine. Cette exigence se retrouve étape par étape dans notre méthode de fusion de données.
Pouvoir répondre à une autre question : « Pourquoi ? »
Un chiffre final est beaucoup plus utile si l’on peut remonter jusqu’à ce qui l’a produit :
Résultat territorial
↓
Indicateur de pauvreté
↓
Ratio 15,35 %
↓
804 / 5 237
↓
Données sources
Chaque flèche répond à la question « d’où vient ce chiffre ? » : le résultat territorial repose sur un indicateur de pauvreté, qui repose sur le ratio 15,35 %, lui-même calculé à partir de 804 et 5 237, eux-mêmes issus des données sources.
Cela permet de demander : « Pourquoi obtenons-nous ce résultat ? »
Et lorsque les dépendances nécessaires ont été correctement matérialisées : « Quels résultats utilisent cette donnée ? »
C’est particulièrement utile lorsqu’une source est corrigée ou mise à jour : on peut alors rechercher les résultats qui en dépendent au lieu de repartir à l’aveugle. Cette chaîne est ce que nous appelons la provenance des données.
Les Atoms : conserver des faits avec leur contexte
DataAuthority utilise le mot Atom pour désigner une petite unité de fait structurée.
Par exemple : « Sur ce territoire, cette valeur a été observée pour cette période, selon cette source. »
Un Atom ne contient donc pas seulement un nombre. Il peut porter son contexte : quoi ? où ? quand ? selon quelle source ? avec quel état ? avec quelles limites ?
L’idée est simple : éviter qu’après plusieurs transformations, il ne reste qu’une cellule dont plus personne ne sait exactement d’où elle vient.
Ces faits peuvent ensuite être rapprochés pour construire des informations plus complexes tout en préservant leur histoire. C’est le vocabulaire utilisé dans le parcours du Moteur DataAuthority.
Pourquoi cela devient particulièrement important avec l’IA
Une intelligence artificielle possède une qualité extraordinaire : elle sait produire une réponse.
Cette qualité devient un défaut lorsque les données ne permettent justement pas de répondre.
Imaginons une étude fictive destinée à repérer les territoires qui cumulent plusieurs fragilités : le vieillissement de la population, la pauvreté et la difficulté d’accès aux services.
Pour cela, l’étude utilise un score fictif de vigilance territoriale, compris entre 0 et 100.
Plus le score est élevé, plus le territoire cumule les fragilités étudiées — vieillissement, pauvreté et difficulté d’accès aux services — et plus il mérite une attention particulière.
Le score ne signifie pas qu’un territoire est « mauvais » ou « dangereux ». Il sert simplement à repérer les endroits où plusieurs difficultés se concentrent.
Exemple fictif simplifié.
Territoire A : 78 / 100 Territoire B : 72 / 100 Territoire C : 68 / 100 Territoire D : 82 / 100
Imaginons maintenant qu’une IA reçoive ces résultats et qu’on lui pose une question naturelle :
« Quel territoire faut-il regarder en priorité ? »
Une IA qui ne voit que les scores pourrait répondre :
« Le territoire D, puisqu’il obtient le score le plus élevé : 82 sur 100. »
Cette réponse est logique si l’IA ne dispose que du score.
DataAuthority cherche à conserver autour du résultat les informations disponibles qui changent la lecture de ce score :
Territoire A Score : 78 / 100 État du résultat : UTILISABLE AVEC LIMITES Pourquoi ? - vieillissement : données compatibles - pauvreté : données de 2022 - accès aux services : données de 2024 - mobilité : couverture incomplète
Territoire D Score : 82 / 100 État du résultat : CONFLICT Pourquoi ? Deux sources nécessaires au calcul donnent des informations contradictoires.
Ces exemples restent fictifs : ce vocabulaire exact ne prétend pas décrire une étude publique déjà publiée.
L’IA ne reçoit plus uniquement :
Territoire D = 82
Elle peut aussi recevoir :
score = 82 état = CONFLICT limites = ... sources = ...
Une réponse plus rigoureuse peut alors devenir :
« Le territoire D obtient le score brut le plus élevé, mais les données nécessaires à ce résultat sont actuellement contradictoires. Je ne peux donc pas utiliser ce score pour affirmer qu’il doit être prioritaire.
Le territoire A obtient 78/100 ; son résultat est mieux étayé, même s’il comporte certaines limites, notamment sur les données de mobilité. »
Le contraste est limpide : « 82 est supérieur à 78 » n’est pas suffisant. La vraie question devient :
« Ai-je suffisamment de preuves pour utiliser ce résultat ? »
L’objectif n’est donc pas simplement de donner davantage de données à l’IA.
Il s’agit de lui transmettre aussi leur état, leurs limites et leurs contradictions, afin qu’elle sache non seulement ce qu’elle peut calculer, mais aussi ce qu’elle peut réellement affirmer.
Quand ces comparaisons s’appuient sur des sources publiques, la démarche est celle de la fusion de données publiques.
Ce que DataAuthority ne fait pas
DataAuthority ne rend pas automatiquement une mauvaise source fiable.
Il ne transforme pas une donnée inconnue en donnée connue.
Il ne décide pas à la place d’un statisticien quelle méthode scientifique est correcte.
Il ne garantit pas que toutes les sources soient compatibles simplement parce qu’elles ont été réunies.
Au contraire, son intérêt est précisément de pouvoir laisser visibles ces problèmes lorsqu’ils existent.
Alors, qu’apporte réellement DataAuthority ?
Pas une nouvelle formule mathématique.
Pas une nouvelle façon de produire une carte.
Pas un remplaçant pour Excel, R, Python, SQL ou les statisticiens.
DataAuthority ajoute une couche entre les données et ce que nous voulons affirmer à partir de ces données.
Cette couche cherche à préserver l’origine, la période, le contexte, les dépendances disponibles, les absences, les informations inconnues, les contradictions et les limites.
Et avant d’accepter une conclusion, elle peut poser une question essentielle :
Avons-nous suffisamment de preuves pour affirmer cela ?
C’est le socle commun des services DataAuthority : le moteur d’abord, les usages ensuite.
Quatre règles suffisent presque à résumer DataAuthority
Une donnée absente ne devient pas zéro.
Une information inconnue ne devient pas fausse.
Une contradiction entre deux sources ne disparaît pas.
Quand les données ne permettent pas de conclure, DataAuthority le dit au lieu d’inventer une certitude.
C’est probablement la définition la plus simple du Moteur DataAuthority :
un moteur conçu non seulement pour rapprocher des données, mais pour préserver les conditions qui permettent de savoir jusqu’où on peut leur faire confiance.
Proposer un jeu de données Découvrir le Moteur DataAuthority Voir les services