2/4+150 XP

Construire une open data que citoyens et journalistes utilisent vraiment

# Construire une open data que citoyens et journalistes utilisent vraiment

En 2013, un journaliste dépose une demande d'accès aux documents auprès d'une ville américaine de taille moyenne : tous les scores d'inspection sanitaire des restaurants sur les cinq dernières années. La ville répond huit mois plus tard avec un PDF verrouillé : 4 000 pages, scannées de travers, impossibles à chercher ou à trier. Techniquement, elle s'est conformée. En pratique, elle a enterré le sujet.

Cet écart entre « nous avons publié » et « quelqu'un peut s'en servir » est tout l'objet de cette leçon.

De la demande FOIA au jeu de données ouvert

Le FOIA (Freedom of Information Act, la loi fédérale américaine qui donne au public un droit d'accès aux documents administratifs ; la plupart des États ont leur équivalent, souvent appelé sunshine law ou public records law) est réactif. Il faut que quelqu'un demande. L'open data inverse le modèle : on publie de façon proactive pour que personne n'ait à demander.

Les administrations avisées surveillent leurs logs FOIA comme un signal de demande. Si le service de santé reçoit douze fois par an la même demande sur les données d'inspection, ce jeu de données doit vivre sur un portail, rafraîchi automatiquement, pour que le douzième demandeur (et le millième citoyen) n'ait qu'à le télécharger.

Voici le pipeline que construit une bonne administration :

1. Système source : la base d'inspection que les agents sanitaires utilisent déjà sur le terrain.

2. Extraction : un pull planifié (chaque nuit ou chaque semaine) vers une zone de staging.

3. Nettoyage et standardisation : corriger les adresses, normaliser les catégories, retirer tout ce qui est légalement exempté (numéros de téléphone personnels, identités d'informateurs).

4. Publication : pousser vers un portail public sous forme de fichier machine-readable et d'une API (Application Programming Interface, un moyen pour un logiciel de récupérer directement les données).

5. Documentation : attacher des métadonnées pour qu'un inconnu comprenne ce que signifie chaque champ.

Le PDF scanné a échoué aux étapes 3, 4 et 5. Reprenons chacune.

Le machine-readable est le minimum

Un dump de conformité est au mieux lisible par un humain. L'open data est machine-readable : un logiciel peut le parser sans qu'une personne retape quoi que ce soit.

La hiérarchie pratique, grossièrement du pire au meilleur :

PDF ou image : inutilisable pour l'analyse. À éviter.
Excel avec cellules fusionnées et couleurs : mieux, mais le formatage casse les scripts.
CSV (comma-separated values, un tableau en texte brut) : la valeur sûre. S'ouvre partout.
JSON via API : idéal pour les développeurs qui construisent des applications nécessitant des mises à jour en direct.

Le modèle open data à 5 étoiles de Tim Berners-Lee est la référence classique : une étoile pour toute licence ouverte, trois étoiles pour un format non propriétaire comme le CSV, cinq étoiles pour des linked data connectées à d'autres jeux de données. Visez au moins trois étoiles. C'est là que l'essentiel de la valeur civique se libère.

Un champ qui pèse plus lourd que sa taille : un identifiant unique stable pour chaque enregistrement. Si chaque restaurant a un ID permanent, un journaliste peut suivre un même établissement à travers les années, même quand il change de propriétaire ou de nom. Sans cela, il devine.

Les métadonnées : la partie que tout le monde saute

Les métadonnées sont les données sur les données. C'est fastidieux à écrire et c'est ce qui sépare un jeu de données que les gens utilisent avec confiance d'un jeu de données qu'ils abandonnent.

Chaque jeu de données a besoin d'un dictionnaire de données : une définition en langage clair de chaque colonne. Voici un extrait d'un fichier d'inspection bien documenté :

field_name       description                                  example
------------------------------------------------------------------------
facility_id      permanent unique ID for the location         REST-004821
inspection_date  date of inspection (YYYY-MM-DD)              2026-03-14
score            0-100, higher is better                      92
result           PASS, CONDITIONAL, or CLOSED                 CONDITIONAL
violation_codes  semicolon-separated codes; see codebook      3-501; 4-602

Regardez ce que cela évite. Sans la mention « higher is better », un journaliste pourrait publier qu'un diner apprécié a obtenu 92 comme s'il avait échoué. Sans la référence au codebook, les codes d'infraction ne sont que des chaînes de caractères vides de sens.

Documentez aussi la provenance et la cadence : d'où viennent les données, à quelle fréquence elles sont mises à jour, et quand a eu lieu le dernier rafraîchissement. Un portail affichant « dernière mise à jour : 2021 » indique aux utilisateurs que les données sont mortes. Un « mise à jour hebdomadaire, dernier run lundi 6h » visible signale que le pipeline est vivant.

La norme fédérale ici est le schéma de métadonnées DCAT-US, qui structure des champs comme l'éditeur, l'email de contact, la fréquence de mise à jour et la licence. Suivez un schéma établi plutôt que d'inventer le vôtre, afin que les agrégateurs et les moteurs de recherche puissent indexer votre catalogue automatiquement.

La cadence est une promesse

Publier une fois, c'est un communiqué de presse. Publier selon un calendrier fiable, c'est une infrastructure.

Les journalistes et les développeurs d'applications ne construiront que sur des données sur lesquelles ils peuvent compter. Une agence de transport qui publie la position de ses véhicules toutes les 30 secondes rend possibles les applications de prédiction d'arrivée que des millions de voyageurs utilisent. Si ce flux s'éteint par intermittence, les développeurs l'abandonnent.

Fixez une cadence que vous pouvez réellement tenir : temps réel, quotidienne, hebdomadaire, mensuelle ou trimestrielle. Puis automatisez-la pour qu'elle survive au turnover. Le mode d'échec le plus courant est l'analyste héroïque qui met à jour un jeu de données à la main jusqu'à ce qu'il change de poste, après quoi tout pourrit en silence.

Vie privée et dommages d'une publication naïve

Publier de façon proactive ne veut pas dire tout publier. L'obligation de caviarder est réelle, et se tromper cause des dégâts durables.

Le danger, c'est la ré-identification : même sans noms, une combinaison de champs (code postal, date de naissance, sexe) peut désigner une personne précise. Une démonstration célèbre a montré que ces trois champs seuls peuvent identifier de façon unique une large part de la population américaine (une estimation largement citée tourne autour de 87 %, issue de travaux sur le recensement de 1990, et le chiffre exact est discuté).

Garde-fous pratiques avant publication :

Retirez les identifiants directs (noms, numéros de sécurité sociale, adresses de domicile exactes des personnes).
Agrégez les petits groupes. Si une catégorie ne compte que deux personnes, un effectif de « 2 » associé à un lieu peut les exposer.
Grossissez la granularité des champs fins. Publiez des tranches d'âge plutôt que des dates de naissance, des îlots de recensement plutôt que des points GPS, dès que des individus sont concernés.
Faites une revue avec le juridique et un délégué à la protection des données pour tout jeu de données touchant à des personnes.

L'objectif est un équilibre défendable : maximum de données de redevabilité (comment l'administration performe), minimum d'exposition personnelle.

Vérification des acquis

1. La leçon décrit une ville qui a répondu à une demande de documents par un PDF verrouillé, scanné de travers. Quelle distinction fondamentale cet exemple illustre-t-il ?

2. En quoi le modèle open data diffère-t-il fondamentalement du modèle FOIA ?

3. Pourquoi la leçon suggère-t-elle que les administrations surveillent leurs logs FOIA comme un « signal de demande » ?

CHOIX MULTIPLES

4. Sélectionnez TOUTES les bonnes réponses. Dans le pipeline décrit, que doit-il se passer pendant l'étape « nettoyage et standardisation » ?

Sélectionnez toutes les réponses correctes.

CHOIX MULTIPLES

5. Sélectionnez TOUTES les bonnes réponses. Le PDF scanné a échoué aux étapes nettoyage, publication et documentation du pipeline. Quelles conséquences découlent de ces échecs précis ?

Sélectionnez toutes les réponses correctes.

Concevoir pour les deux utilisateurs clés

Citoyens et journalistes attendent des choses différentes du même portail. Servez les deux.

Les journalistes et analystes veulent un téléchargement en masse. Donnez-leur un seul CSV avec le jeu de données complet, une licence claire (Creative Commons Zero ou une dédicace au domaine public lève tout doute sur la réutilisation) et un changelog pour qu'ils voient ce qui a bougé entre les versions. Ne les forcez pas à cliquer à travers 400 pages d'un visualiseur web.

Les développeurs civiques veulent une API documentée avec des noms de champs stables. Si vous renommez score en inspection_score sans prévenir, toutes les applications bâties sur vos données cassent du jour au lendemain. Versionnez votre API et annoncez les changements.

Le grand public veut une recherche simple et une page lisible : je tape le nom d'un restaurant, je vois ses scores récents. La plupart ne toucheront jamais au fichier brut, mais c'est ce fichier brut qui alimente les outils qu'ils finiront par utiliser.

Un test utile : un extérieur compétent, sans passer un appel à votre bureau, peut-il télécharger vos données, comprendre chaque champ et reproduire un constat de base ? Si oui, vous avez construit de l'open data. S'il doit vous écrire pour décoder une colonne, vous avez construit un dump de conformité à peine plus présentable.

À quoi ressemble « utilisé »

Vous saurez que le portail fonctionne quand les résultats apparaissent dans le monde réel :

Un média local construit une carte interrogeable des scores d'inspection et cite votre jeu de données.
Un collectif de quartier récupère les données de plaintes au 311 (la ligne municipale de services non urgents) pour réclamer plus de budget de réfection de voirie.
Un développeur sort une application qui alerte les voyageurs des retards de bus à partir de votre flux.

Suivez la réutilisation comme une équipe produit suit l'adoption : nombre de téléchargements, volume d'appels API, et une galerie publique des projets bâtis sur vos données. Des villes comme New York avec son portail Open Data publient l'usage et mettent en avant des projets civiques, ce qui crée un cercle vertueux : une réutilisation visible justifie le budget qui maintient le pipeline en marche.

Points clés

Traitez les logs FOIA comme un signal de demande. Des demandes répétées sur les mêmes documents signifient que ce jeu de données a sa place sur un portail, rafraîchi automatiquement, plutôt que livré à la main chaque fois.
Machine-readable plus métadonnées, c'est le plancher. Un CSV avec un dictionnaire de données en langage clair, des identifiants uniques et une cadence de mise à jour documentée bat à chaque fois un PDF de 4 000 pages.
La cadence est une promesse que vous devez automatiser. Des mises à jour fiables et planifiées permettent aux journalistes et développeurs de bâtir sur vos données ; les mises à jour manuelles meurent avec le départ de l'analyste.
Caviardez délibérément pour empêcher la ré-identification. Agrégez les petits groupes et grossissez la granularité des champs fins avant publication, et faites relire tout ce qui concerne des individus par les équipes privacy et juridique.
Mesurez la réutilisation, pas seulement la publication. Suivez les téléchargements, les appels API et les projets réels ; c'est l'usage civique visible qui maintient le pipeline financé et vivant.

Lire les métriques de service comme un opérateur d'agence publique

Mesurer les résultats quand les services ne paient qu'après des années