DATA QUALITY
Les limites réelles de l'open data tiennent à trois écarts. La qualité du contenu n'est garantie par personne, la fiabilité dépend de la méthode de production du producteur, et la mise à jour n'engage pas celui qui publie. Une donnée ouverte s'utilise donc après vérification de sa couverture, de sa date réelle et de sa stabilité, jamais sur la seule foi du portail.
Les données ouvertes entrent progressivement dans les chaînes de traitement des entreprises. Un référentiel d'adresses pour normaliser une base client, un fichier d'entreprises pour qualifier des prospects, une série statistique pour compléter un tableau de bord. Au fil des mois, ces sources deviennent des dépendances : elles alimentent des analyses présentées en comité et servent de base à des décisions d'implantation, de ciblage ou de tarification.
Leur crédit repose sur une idée rarement discutée : une donnée publiée par une administration serait une donnée sûre. Le producteur est officiel, le portail est institutionnel, le fichier est téléchargé des milliers de fois. Aucun de ces trois éléments ne renseigne sur la qualité du contenu.
Le cadre juridique de l'open data place d'ailleurs la charge de la vérification du côté de celui qui réutilise, et très peu d'organisations ont lu leurs licences sous cet angle. Elles traitent une source gratuite comme une source garantie, alors que la gratuité porte sur l'accès et que la garantie, elle, n'existe pas.
Les limites de l'open data ne disqualifient pas la donnée ouverte. Elles déplacent le travail : un jeu de données téléchargé en quelques secondes reste une source à qualifier, à surveiller et à documenter, avec la même rigueur qu'une donnée achetée à un fournisseur ou produite en interne. Ce travail se prépare en connaissant précisément ce qui peut faire défaut, et à quel moment.
La première limite de l'open data est juridique avant d'être technique. Les licences ouvertes organisent la liberté de réutilisation, pas la qualité de ce qui est réutilisé. Tant que ce point n'est pas compris, le réutilisateur attribue au producteur des engagements que celui-ci n'a jamais pris.
La Licence Ouverte 2.0 d'Etalab, publiée en avril 2017, est la licence de référence des données publiques en France. Son article consacré à la responsabilité est explicite : l'information est mise à disposition telle que produite ou reçue par le producteur, l'absence de défauts ou d'erreurs n'est pas garantie, et la fourniture continue de l'information ne l'est pas davantage. Le réutilisateur y est désigné comme seul responsable de la réutilisation.
Ce texte répartit les rôles de façon nette. Le producteur s'engage sur les conditions d'accès, le réutilisateur porte tout le reste.
La dernière obligation est la plus souvent ignorée. Elle signifie qu'un tableau de bord qui affiche un indicateur construit sur une donnée ouverte, sans en mentionner la date, expose l'organisation qui le diffuse. La responsabilité de la date affichée appartient au réutilisateur, pas au producteur.
La plupart des données publiques ne sont pas collectées pour être publiées. Elles sont le sous-produit d'une procédure administrative : une déclaration fiscale, une formalité d'entreprise, un acte notarié, une inspection. La publication en open data intervient après coup, sur une donnée dont la qualité a été calibrée pour la mission du producteur.
Les demandes de valeurs foncières en donnent un exemple clair. Publiées par la direction générale des finances publiques, elles sont issues des actes notariés et des informations cadastrales. Leur finalité première est fiscale, et leur structure reflète cette finalité : ce qui sert à la procédure est soigneusement renseigné, ce qui ne lui sert pas l'est moins.
Ce décalage explique une grande partie des déceptions. Le réutilisateur attend d'un fichier public qu'il réponde à sa question, alors que le fichier répond d'abord à celle du producteur. Une donnée de bonne qualité pour son usage d'origine peut se révéler insuffisante pour un usage analytique, sans qu'aucune erreur n'ait été commise à la source.
👉 À lire aussi : Open Data : quand l'ouverture des données a du sens (et quand elle n'en a pas)
Les défauts de qualité des données ouvertes se voient rarement sur la page de présentation du jeu de données. Ils apparaissent au premier croisement avec une source interne, ou au premier chiffre qui surprend en comité. Quatre familles de défauts reviennent d'un jeu de données à l'autre, et chacune se détecte avec un test simple, à condition de la chercher.
Un jeu de données présenté comme national n'est pas nécessairement complet. Le titre décrit l'intention de la publication, la notice décrit son périmètre réel, et les deux diffèrent souvent. Les demandes de valeurs foncières couvrent ainsi les transactions des cinq dernières années sur le territoire métropolitain et les départements et régions d'outre-mer, à l'exception de l'Alsace, de la Moselle et de Mayotte.
Les lacunes de couverture prennent trois formes, qu'il faut rechercher séparément sur chaque source.
Un trou de couverture ne se corrige pas, il se compense ou se déclare. L'essentiel est de le connaître avant l'analyse : une moyenne nationale calculée sans les départements exclus n'est pas une moyenne nationale.
Une part importante des données publiques restitue ce qui a été déclaré, pas ce qui a été observé. L'activité principale d'une entreprise correspond au code déclaré lors de ses formalités, qui peut ne plus refléter son activité réelle. La tranche d'effectif d'un établissement se rapporte à une année de référence, qui n'est pas toujours récente.
Ces valeurs sont exactes au sens administratif : elles reproduisent fidèlement la déclaration. Elles ne décrivent pas pour autant la réalité économique que le réutilisateur cherche à mesurer. La distinction change la façon de s'en servir.
Trois usages restent sûrs avec une donnée déclarative, à condition d'en connaître la nature.
Une même information publiée par plusieurs producteurs arrive rarement dans la même structure. Des dizaines de collectivités publient leurs équipements, leurs subventions ou leurs délibérations, chacune avec ses propres noms de colonnes, ses propres formats de date et ses propres listes de valeurs. Des schémas de données communs existent, référencés sur schema.data.gouv.fr, mais leur adoption reste partielle.
L'hétérogénéité a un coût que les réutilisateurs découvrent au moment de consolider. Chaque source demande une table de correspondance, chaque changement de structure chez un producteur casse un traitement, et chaque valeur libre doit être rapprochée d'une nomenclature. Ces écarts produisent exactement les mêmes effets que les causes de mauvaise qualité des données observées en interne : des libellés concurrents, des référentiels divergents, des agrégats qui ne se recoupent pas.
La granularité d'un fichier ouvert ne correspond pas toujours à l'objet que le réutilisateur croit compter. Dans les demandes de valeurs foncières, une même mutation peut s'étendre sur plusieurs lignes, une par lot ou par local, avec la valeur foncière répétée sur chacune. Additionner la colonne sans regrouper les lignes par mutation compte plusieurs fois la même vente.
Ce type de défaut n'est pas une erreur du producteur, mais une structure mal comprise par le réutilisateur. Il se prévient en répondant à une question avant tout calcul : à quel objet correspond une ligne du fichier ? La réponse figure dans la notice, rarement dans les noms de colonnes.
La fiabilité d'une donnée ouverte ne se mesure pas ligne par ligne. Elle tient à la méthode qui a produit le contenu et à la stabilité de ce contenu dans le temps. Deux jeux de données de qualité apparente équivalente peuvent mériter des niveaux de confiance très différents, selon la façon dont ils ont été construits et dont ils évoluent.
Le caractère public du producteur ne dit rien de la méthode employée. Trois modes de production coexistent sur les portails, et chacun appelle un niveau de vigilance différent.
Identifier le mode de production est le premier réflexe à acquérir. Il indique où chercher les faiblesses, avant même d'ouvrir le fichier.
Certains producteurs republient des millésimes anciens après correction. La démarche est saine du point de vue du producteur, puisqu'elle améliore l'exactitude de la donnée. Elle crée un problème pour le réutilisateur : la même requête, lancée à six mois d'intervalle sur le même millésime, ne renvoie plus le même résultat.
Sans conservation du fichier utilisé à l'époque, l'écart devient inexplicable. Un chiffre présenté en comité ne peut plus être justifié, une tendance semble s'inverser sans raison, et la confiance dans l'ensemble de l'analyse se dégrade. Une donnée qui change sans que le réutilisateur le sache n'est pas une donnée fiable, même si chaque version est exacte.
Les nomenclatures sur lesquelles reposent les données publiques évoluent. Le code officiel géographique de l'Insee est mis à jour au 1er janvier de chaque année pour intégrer les fusions et les créations de communes. Une série construite par commune sur plusieurs années compare donc des périmètres qui ne sont pas identiques d'un millésime à l'autre.
Le même phénomène touche les colonnes elles-mêmes. Un champ renommé, un format de date modifié ou une liste de valeurs enrichie suffisent à fausser un traitement qui fonctionnait sans erreur jusque-là. Plusieurs parades existent, et elles se combinent.
La mise à jour est la limite de l'open data la plus sous-estimée, parce qu'elle se lit mal sur les portails. La date mise en avant sur la page d'un jeu de données est une date de publication. Elle ne dit ni de quand datent les faits décrits, ni à quel rythme la donnée sera renouvelée.
Toute donnée ouverte porte trois dates, et seule la deuxième est visible au premier regard. La date des faits correspond au moment où la situation décrite a eu lieu. La date de publication correspond à la mise en ligne du millésime. La date d'usage correspond au moment où le réutilisateur s'en sert pour décider.
L'écart entre la première et la deuxième date peut être considérable. Les populations légales en vigueur au 1er janvier d'une année décrivent la situation observée environ trois ans plus tôt, en raison de la méthode du recensement. Les demandes de valeurs foncières, mises à jour deux fois par an, restituent des transactions intervenues plusieurs mois avant chaque publication.
L'ancienneté d'une donnée s'accumule entre ces trois dates, ce qui explique qu'une date affichée sur un portail ne suffise jamais à juger de sa fraîcheur.
Chaque jeu de données affiche une fréquence de mise à jour : quotidienne, mensuelle, annuelle, ponctuelle. Cette information est déclarative. Le score de qualité des métadonnées de data.gouv.fr distingue d'ailleurs deux critères, le fait que la fréquence soit renseignée et le fait qu'elle soit respectée, ce qui suffit à montrer que les deux ne coïncident pas toujours.
Un jeu de données annoncé comme mensuel peut rester inchangé pendant plusieurs trimestres sans qu'aucun message ne le signale. Le fichier reste téléchargeable, les traitements continuent de tourner, et les résultats continuent d'être produits sur une réalité qui a cessé d'être décrite. Ce retard silencieux est plus dangereux qu'une panne, parce que rien ne s'arrête.
La Licence Ouverte ne garantit pas la fourniture continue de l'information, et les producteurs en font usage. Les arrêts de publication prennent plusieurs formes, qui n'ont pas les mêmes conséquences pour un traitement automatisé.
Chacune de ces situations se détecte par un contrôle automatique, à condition qu'il ait été prévu. Aucune ne se détecte par la simple consultation du portail.
L'évaluation d'un jeu de données ouvert se fait avant son intégration, en trois temps : lire les signaux publics, tester le fichier sur son propre périmètre, puis remonter à la documentation du producteur. Aucun de ces temps ne demande d'outil spécialisé, et l'ensemble tient en quelques heures pour un jeu de données de taille courante.
Les portails publics fournissent des indicateurs utiles, à condition de savoir ce qu'ils mesurent. Data.gouv.fr a mis en place en 2022 un score de qualité des métadonnées, construit pour aider les réutilisateurs à repérer les jeux de données dignes d'intérêt et pour inciter les producteurs à mieux documenter.
Les critères de ce score portent tous sur la description du jeu de données, pas sur son contenu.
D'autres signaux complètent ce score. L'onglet des discussions révèle les anomalies déjà signalées par d'autres réutilisateurs et la réactivité du producteur à y répondre. Les réutilisations référencées indiquent que la donnée a déjà été exploitée, sans garantir que ces exploitations aient été rigoureuses.
Le seul test qui compte porte sur le périmètre réellement utilisé. Une complétude satisfaisante au niveau national peut masquer une couverture médiocre sur les territoires, les secteurs ou les années qui intéressent le réutilisateur. Le profilage applique à la source ouverte les mêmes indicateurs de qualité des données que ceux suivis sur une source interne.
Cinq contrôles couvrent l'essentiel des défauts de qualité, de fiabilité et de mise à jour.
La page d'un jeu de données résume, la documentation du producteur précise. Les notices méthodologiques, les dictionnaires de variables et les conditions d'utilisation décrivent les exclusions, les règles de calcul et les limites connues, que les pages de présentation passent sous silence. Les demandes de valeurs foncières sont par exemple accompagnées d'une notice explicative et de conditions générales d'utilisation qu'il faut lire avant tout calcul.
Cette lecture a un effet secondaire utile : elle permet de rédiger la fiche de la source dans le catalogue interne, avec ses limites déclarées. Les limites de l'open data se résument en une grille : pour chacune, un test à passer avant l'usage et un contrôle à maintenir en production.
| Limite | Ce qui se produit | Test avant usage | Contrôle en production |
|---|---|---|---|
| Couverture incomplète | Des territoires, des années ou des populations manquent sans que le titre du jeu de données le signale. | Lire la notice et mesurer la complétude sur le périmètre réellement utilisé. | Comparer le volume de chaque livraison à celui de la précédente. |
| Valeurs déclaratives | Les valeurs reproduisent une déclaration, parfois ancienne, et non une situation observée. | Identifier les champs déclarés et leur année de référence. | Afficher l'année de référence avec chaque valeur utilisée. |
| Formats hétérogènes | Une même information arrive dans des structures différentes selon le producteur. | Vérifier l'existence d'un schéma commun et son adoption par les producteurs. | Maintenir une table de correspondance par producteur. |
| Granularité mal comprise | Une ligne ne correspond pas à l'objet compté, ce qui produit des doubles comptes. | Identifier dans la notice l'objet représenté par une ligne. | Contrôler l'unicité de la clé avant toute agrégation. |
| Correction rétroactive | Un millésime republié modifie des résultats déjà diffusés. | Comparer deux versions successives du même millésime. | Conserver chaque fichier utilisé, daté et identifié. |
| Changement de nomenclature | Les séries comparent des périmètres différents d'une année à l'autre. | Repérer les nomenclatures utilisées et leur millésime. | Convertir toutes les années dans une nomenclature figée. |
| Retard ou arrêt de mise à jour | Les traitements continuent de tourner sur une réalité qui n'est plus décrite. | Comparer la date la plus récente du fichier à la fréquence annoncée. | Déclencher une alerte dès que l'écart dépasse un seuil défini. |
Une source ouverte qui alimente un traitement récurrent change de statut. Elle devient une dépendance externe, soumise aux mêmes exigences qu'un flux fournisseur, avec une différence de taille : aucun contrat ne lie le réutilisateur au producteur. Les contrôles qui compensent cette absence de contrat relèvent entièrement de l'organisation qui réutilise.
La conservation des versions est la condition de la reproductibilité. Un traitement qui lit directement la dernière version publiée produit des résultats qui changent au gré des republications du producteur, sans trace de ce qui a été lu.
La parade consiste à stocker chaque fichier récupéré, daté et identifié, avant tout traitement. Les calculs s'appuient sur cette copie, et chaque résultat diffusé peut être rattaché au millésime exact qui l'a produit. Le volume de stockage est négligeable au regard de ce qu'il permet : expliquer un écart, rejouer une analyse passée, conserver un historique qu'une source glissante ferait disparaître.
Les défauts de mise à jour et de structure ne se voient pas à l'œil nu. Ils se détectent par des règles simples, exécutées à chaque récupération de la source, qui bloquent le traitement ou déclenchent une alerte quand une valeur sort de l'attendu.
Quatre contrôles suffisent à couvrir la plupart des incidents observés sur des sources ouvertes.
Une source ouverte sans responsable interne n'est surveillée par personne. Le producteur public ne répond pas des usages qui sont faits de sa donnée, et les équipes techniques qui exploitent le flux n'ont pas vocation à juger de sa pertinence métier.
Le rôle revient à un Data Owner, qui répond de la source comme de n'importe quelle donnée de son périmètre, appuyé par un Data Steward qui suit les contrôles et documente les anomalies. Cette désignation s'inscrit dans l'organisation existante de la qualité : savoir qui est responsable de la qualité des données dans l'organisation revient ici à étendre ce périmètre aux données qui viennent de l'extérieur.
La Licence Ouverte impose de ne pas induire en erreur sur la date de mise à jour de l'information. Cette obligation se traduit concrètement dans chaque tableau de bord, chaque note et chaque présentation qui s'appuie sur une donnée ouverte.
Deux mentions suffisent dans la plupart des cas : la source avec la date de ses données, et les limites connues qui pèsent sur l'interprétation. Ces mentions gagnent à être centralisées dans un Data Catalog, où chaque source ouverte dispose d'une fiche avec son producteur, sa licence, son périmètre réel, ses exclusions et la date de son dernier contrôle.
👉 À lire aussi : Data Owner, Data Steward, Data Custodian : le triptyque pour réussir sa gouvernance des données
Les limites de l'open data ne plaident pas pour renoncer aux données ouvertes. Elles plaident pour les traiter comme ce qu'elles sont : des sources externes, publiées sans garantie de qualité ni de continuité, dont la valeur dépend du travail de qualification fait par le réutilisateur. La gratuité de l'accès ne réduit en rien ce travail.
Ce travail se répartit sur trois moments. Avant l'usage, il consiste à lire la licence, la notice et les signaux du portail, puis à profiler le fichier sur son propre périmètre. Au moment de l'intégration, il consiste à conserver chaque version et à poser les contrôles de fraîcheur, de volume et de structure. Dans la durée, il consiste à désigner un responsable et à dater chaque restitution. La démarche ne diffère pas de celle d'un référentiel de données de référence alimenté par un tiers.
Un dernier point prend de l'importance. Les données ouvertes alimentent désormais des modèles d'IA, internes ou externes, qui les absorbent sans conserver leurs dates ni leurs limites. Une valeur périmée ou un trou de couverture se retrouve alors dans des réponses générées, sans lien vers la source. Plus une donnée ouverte est réutilisée loin de son portail, plus ses limites doivent être documentées dans la donnée elle-même, ce que confirme l'analyse du lien entre mauvaise qualité des données et risque IA.
Une donnée ouverte est aussi fiable que la méthode qui l'a produite, pas davantage. Le statut public du producteur ne garantit ni l'exactitude du contenu ni sa mise à jour, et la Licence Ouverte exclut explicitement toute garantie sur ces deux points. La fiabilité se juge donc source par source, en fonction de son mode de production et de sa stabilité dans le temps.
Le réutilisateur. La Licence Ouverte 2.0 précise que l'information est mise à disposition telle que produite ou reçue, que l'absence d'erreurs n'est pas garantie et que le réutilisateur est seul responsable de la réutilisation. Le producteur s'engage sur les conditions d'accès, pas sur la qualité du contenu.
La fréquence varie d'une source à l'autre, et celle qui est affichée sur le portail est déclarative. Le score de qualité de data.gouv.fr distingue une fréquence renseignée d'une fréquence respectée, ce qui montre que les deux peuvent diverger. La date de mise à jour visible sur un portail est par ailleurs une date de publication, pas la date des faits décrits.
La vérification se fait en trois temps : lire les signaux du portail, profiler le fichier sur son propre périmètre, puis lire la documentation du producteur. Le profilage est l'étape décisive, parce qu'une complétude satisfaisante au niveau national peut masquer une couverture médiocre sur les territoires ou les années utiles.
Le score évalue la documentation d'un jeu de données, pas son contenu. Mis en place en 2022, il aide les réutilisateurs à repérer les jeux de données bien décrits et incite les producteurs à mieux documenter leurs publications. Un score élevé signale une source bien présentée, sans garantir l'absence de trous, de doublons ou de valeurs anciennes.
Trois mécanismes expliquent ces écarts : la correction rétroactive d'un millésime par le producteur, le changement d'une nomenclature entre deux années, et la modification de la structure du fichier. Sans conservation de la version utilisée à l'époque, l'écart ne peut plus être expliqué.
En la traitant comme une dépendance externe, avec des contrôles exécutés à chaque chargement et un responsable interne désigné. Aucun contrat ne lie le réutilisateur au producteur : les garanties que la licence ne donne pas doivent être reconstruites par l'organisation qui réutilise.
.png)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
%20copie.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)