DataData dans Secteur public & associatifSecteur public & associatif

Publier des données ouvertes que les citoyens, journalistes et corps de contrôle utilisent vraiment

La plupart des portails open data publics accumulent des fichiers que personne ne télécharge. Ce guide pratique montre comment un CDO du secteur public passe d'une conformité formelle à une publication qui génère un usage réel.

La France compte aujourd'hui plus de 45 000 jeux de données sur data.gouv.fr. Le taux de réutilisation active, mesuré par les téléchargements répétés et les appels API, reste concentré sur moins de 3 % d'entre eux. Le constat vaut pour la plupart des portails municipaux, régionaux et para-publics : on publie pour cocher la case CRPA (Code des relations entre le public et l'administration), pas pour produire de l'impact. Or les attentes changent : depuis 2024, les corps d'inspection et les chambres régionales des comptes intègrent explicitement la qualité des données publiées dans leurs grilles d'audit. Un CDO qui répond "nous avons un portail" sans pouvoir montrer des métriques d'usage s'expose à des recommandations embarrassantes dans les rapports publics.

Le problème n'est pas technique. Les formats CSV et JSON sont maîtrisés. Le problème est de conception : on publie ce qu'il est facile d'extraire du SI, pas ce que les réutilisateurs cherchent. Corriger cela demande une séquence précise, pas une refonte globale.

La séquence pour publier des données réellement utilisées

Étape 1 : cartographier la demande avant de toucher aux données

Avant d'ouvrir un nouveau jeu de données, passez deux semaines à auditer la demande existante. Trois sources concrètes : les demandes CADA (Commission d'accès aux documents administratifs) des douze derniers mois, les sujets de presse locale qui ont cité un manque de données chiffrées, et les questions écrites des élus à l'exécutif. Ces trois corpus révèlent ce que les réutilisateurs cherchent et ne trouvent pas. La Métropole de Lyon a utilisé cette méthode en 2023 pour prioriser l'ouverture de ses données de permis de construire, et le jeu de données correspondant a atteint 1 200 téléchargements distincts dans les six mois suivant sa publication, selon les données publiques du portail.

Étape 2 : structurer pour les outils des journalistes, pas pour votre DBA

Un journaliste de données travaille sous Datawrapper, QGIS ou un simple tableur. Il ne maîtrise pas SQL. Cela impose des règles concrètes : un fichier par unité logique (pas de jointures implicites entre colonnes de codes INSEE et libellés dans des fichiers séparés), des en-têtes de colonnes en français compréhensible (pas "cd_commune" mais "code_commune"), une ligne par observation, et aucune cellule fusionnée. La norme Schema.data.gouv.fr fournit des gabarits validés pour les usages fréquents (délibérations, marchés publics, subventions). Les utiliser réduit les questions de support de 60 à 70 % selon les retours collectés par Etalab auprès des producteurs pilotes.

Étape 3 : documenter comme si le producteur avait quitté l'administration

La documentation standard d'un portail est une description copiée depuis le SI source. Elle ne répond à aucune des vraies questions : quelle est la fréquence réelle de mise à jour, comment traiter les valeurs manquantes, quelles sont les entités juridiques exclues du périmètre et pourquoi. Rédigez un fichier README structuré avec quatre sections : périmètre exact, limites connues, fréquence et déclencheurs de mise à jour, contact technique. Ce fichier accompagne chaque publication et est versionné avec les données. La Direction interministérielle du numérique (DINUM) recommande ce format depuis 2025 dans son guide producteur mis à jour.

Étape 4 : mettre en place une pipeline de transformation traçable

Les données publiables sortent rarement propres des systèmes sources. La tentation est de corriger manuellement dans Excel avant export. C'est la cause principale des incohérences entre millésimes successifs et des impossibilités à répondre aux questions d'audit ("pourquoi ce chiffre a changé entre juin et septembre ?"). Implémentez les transformations dans un outil qui documente chaque étape : dbt (data build tool) s'impose ici pour sa capacité à versionner les transformations SQL, générer automatiquement un catalogue de données et produire des tests de qualité exécutables. dbt Labs, l'éditeur commercial derrière dbt Core, a publié en 2026 la version 1.12 en disponibilité générale, avec des améliorations sur la gestion d'état qui réduisent les temps de recalcul (source : dbt Labs, éditeur de l'outil, données à croiser avec des retours terrain indépendants). La version open-source dbt Core suffit pour la majorité des cas d'usage publics.

Étape 5 : créer une boucle de feedback formalisée

Publier sans écouter reproduit le problème d'origine. Mettez en place un formulaire structuré sur chaque page de jeu de données avec trois champs : ce que l'utilisateur cherchait, ce qu'il a trouvé, ce qui manque. Examinez ces retours en revue mensuelle avec l'équipe data et le référent CADA. Ce circuit remplace l'intuition par des signaux réels et fournit une traçabilité documentable pour les audits.

Les pièges qui font échouer la démarche

Le premier piège est de publier des données agrégées pour "protéger" des informations qui ne sont pas confidentielles. L'agrégation détruit la valeur analytique. Si la CADA ou un tribunal administratif a déjà confirmé que des données granulaires sont communicables, publiez-les directement.

Le deuxième piège concerne l'accessibilité. L'article 106 de la loi du 11 février 2005 et les règles RGAA imposent que les interfaces de téléchargement soient utilisables par les personnes en situation de handicap. Un portail non conforme expose l'administration à des recours et discrédite la démarche lors des audits Section 508 équivalents conduits par les corps d'inspection.

Le troisième piège est de traiter la mise à jour comme facultative. Un jeu de données qui n'est plus mis à jour sans explication devient activement nuisible : les journalistes publient des analyses sur des données périmées. Établissez un contrat de service interne avec une SLA de mise à jour et rendez-le public dans la documentation.

Enfin, méfiez-vous des exports "one-shot" produits par des prestataires à l'occasion d'un projet. Sans pipeline reproductible, la prochaine mise à jour coûte autant que la première. La commande publique (marchés de services informatiques soumis au code de la commande publique) doit inclure une exigence explicite de livraison de la logique de transformation, pas seulement des fichiers.

Pour démarrer cette semaine

  • Tirez la liste des dix dernières demandes CADA reçues et identifiez celles qui pointent vers un jeu de données publiable sans décision politique nouvelle.
  • Téléchargez un jeu de données déjà publié sur votre portail et tentez de reproduire une analyse simple : mesurez le temps nécessaire et notez ch

Le parcours complet sur ce secteur :Data dans Secteur public & associatif.

Pour aller plus loin

Les leçons qui prolongent cet article, en accès libre.

  1. 1Liberté d'information et accès aux documents publics : ce qui devient public, et quandSecteur public & associatif : comment le secteur fonctionne
  2. 2Scorecards de qualité des données pour les jeux de données publicsLa data dans le secteur public
  3. 3Cartographier le paysage des données publiques : registres, données administratives et données d'enquêteLa data dans le secteur public
  4. 4Gouverner la privacy et l'équité sur des systèmes legacyLa data dans le secteur public
  5. 5Gérer les parties prenantes et l'accountability publiqueSecteur public & associatif : comment le secteur fonctionne

Vous avez lu cet article ?

Validez votre lecture pour gagner de l’XP et alimenter votre radar.