MCP data.gouv.fr : interroger l open data français depuis Claude Code

L'open data français, en théorie c'est génial

data.gouv.fr. La plateforme nationale d'open data. Des milliers de jeux de données : élus, budgets, géographie, transports, santé, éducation. Sur le papier, un trésor. En pratique ? Tu passes 20 minutes à naviguer dans l'interface, tu télécharges un CSV, tu l'ouvres dans un tableur, tu te rends compte que c'est pas le bon fichier - ou que le format a changé depuis la dernière mise à jour, parce que bien sûr personne prévient quand ça change. Tu recommences. Galère.

Et puis j'ai découvert que data.gouv.fr avait sorti un serveur MCP officiel. MCP, c'est le Model Context Protocol - un standard ouvert qui branche des sources de données externes directement dans ton assistant IA. En gros : tu poses ta question en français dans ton terminal, et l'IA va fouiller dans les datasets à ta place. J'étais sceptique. J'ai testé quand même. Ça marche vachement bien.

Mise en place : franchement, c'est rapide

Pas de repo à cloner. Pas de Docker. Pas d'API key (ça, ça m'a surpris). Le serveur tourne sur une instance publique, gratuite, sans inscription. Une commande :

claude mcp add --transport http datagouv https://mcp.data.gouv.fr/mcp

Ça plante ça dans ~/.claude.json. Tu relances Claude Code, c'est prêt.

Petit check pour être sûr :

claude mcp list

Si datagouv apparaît avec le transport http, t'es bon. Si ça apparaît pas, relance Claude Code - j'ai eu le coup la première fois, il faut un restart complet, pas juste un /mcp reset.

Pour Claude Desktop (ou Cursor, Windsurf, VS Code)

Là, il faut passer par npx mcp-remote comme wrapper dans le fichier de config JSON :

{
  "mcpServers": {
    "datagouv": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://mcp.data.gouv.fr/mcp"]
    }
  }
}

Même principe pour les autres éditeurs.

La boîte à outils

Trois catégories. Je vais pas faire un roman sur chaque outil, le tableau parle de lui-même.

Datasets (les fichiers)

Outil	Ça fait quoi
`search_datasets`	Recherche par mots-clés
`get_dataset_info`	Métadonnées d'un dataset (titre, licence, dates...)
`list_dataset_resources`	Liste des fichiers dispo (CSV, JSON, XLS...)
`query_resource_data`	Requête directe sur un CSV/XLSX via l'API Tabular
`get_resource_info`	Infos techniques (format, taille, URL)
`download_and_parse_resource`	Télécharge et parse un JSON/JSONL

query_resource_data c'est le plus intéressant, et de loin. Tu interroges un CSV de 50 000 lignes sans le télécharger, avec des filtres (exact, contains, less, greater), du tri, de la pagination. Ça évite le cycle infernal télécharger-ouvrir-filtrer-refermer.

Dataservices (APIs tierces)

Outil	Ça fait quoi
`search_dataservices`	Recherche d'APIs enregistrées
`get_dataservice_info`	Métadonnées d'une API (URL de base, doc)
`get_dataservice_openapi_spec`	Spec OpenAPI pour voir les endpoints

Tu peux par exemple tomber sur l'API Adresse, l'API Sirene, et directement lire leur spec OpenAPI pour comprendre comment les appeler. Pas besoin d'aller lire une doc sur un site tiers.

Métriques

Un seul outil : get_metrics. Stats de visites et téléchargements. Anecdotique, mais ça peut servir pour savoir si un dataset est activement maintenu ou si c'est un truc abandonné depuis 2019.

En vrai, ça donne quoi ? Valider des données d'élus

Un cas que j'ai eu cette semaine. J'avais un fichier JSON avec des données de députés - noms, départements, groupes politiques. 580 entrées. Le truc, c'est que je savais pas si mes données étaient encore à jour. Des députés qui ont démissionné, des suppléants qui ont pris le relais, des noms de famille qui changent après un mariage... ça bouge tout le temps à l'Assemblée.

Au lieu de passer une après-midi à croiser ça à la main avec le site de l'Assemblée nationale (spoiler : leur interface de recherche est... perfectible), j'ai tenté le MCP.

"Répertoire National des Élus" dans search_datasets. Bam. Dataset du Ministère de l'Intérieur, ID 5c34c4d1634f4173183a64f1. La source officielle, celle qui fait foi.

list_dataset_resources me sort la liste : un fichier pour les députés, un pour les sénateurs, un pour les maires, les conseillers régionaux... Chaque fichier avec son ID, son format, sa taille. Jusque-là, classique.

Et là, le moment où ça devient intéressant. query_resource_data sur le fichier députés. 575 lignes. Mon fichier local : 581. Six de trop. Problème identifié en 30 secondes, sans avoir ouvert quoi que ce soit.

À partir de là, j'ai fait comparer les noms un par un. Le bilan était pas joli : 4 entrées qui n'étaient pas des députés du tout (des anciens ministres qui traînaient dans le fichier - allez savoir comment ils sont arrivés là), 13 députés qui n'étaient plus en exercice, 21 qui manquaient complètement. Et une soixantaine de noms avec des accents ou des tirets différents de la source officielle. Ah, et 5 départements écrits "Reunion" au lieu de "La Réunion". Le genre de détail qui passe inaperçu pendant des mois.

Le genre de nettoyage qui prend une bonne demi-journée à la main, entre les allers-retours sur le site de l'AN et les copier-coller dans un tableur. Là, 20 minutes en conversation.

Le workflow classique

Le pattern revient toujours :

search_datasets -> get_dataset_info -> list_dataset_resources -> query_resource_data

Chercher avec des mots-clés courts et précis (l'API fait un AND logique, donc "données élus France" retourne rien - "Répertoire élus" retourne ce qu'il faut). Identifier le bon dataset en lisant les métadonnées. Lister les fichiers pour trouver le bon. Requêter directement avec filtres et pagination. C'est tout.

Pour les APIs tierces, même logique mais en trois étapes :

search_dataservices -> get_dataservice_info -> get_dataservice_openapi_spec

Tu découvres l'API, tu récupères sa spec, tu l'appelles.

Les trucs à savoir (j'ai appris à mes dépens)

Les mots-clés, c'est tout un art. "Assemblée nationale députés" marche. "liste des députés français données ouvertes" retourne zéro résultat. L'API est assez stricte sur le matching, faut aller droit au but. J'ai perdu un bon quart d'heure à reformuler des requêtes avant de comprendre que moins de mots = plus de résultats.

Commence petit. page_size=20 pour voir la structure des données. Ensuite tu augmentes. J'ai fait l'erreur de demander 500 lignes d'entrée de jeu sur un dataset que je connaissais pas - c'était des codes postaux, 36 000 lignes, j'avais évidemment pas besoin de tout ça.

Les gros fichiers, c'est pas son fort. Au-delà de 1000 lignes, mieux vaut utiliser download_and_parse_resource plutôt que de paginer 50 fois. Limite dure à 50 Mo par fichier.

Pas d'auth. L'instance publique demande rien. Zéro clé, zéro compte. Faut juste que ton client MCP gère le transport HTTP streamable (Claude Code le gère nativement, pour les autres vérifier la doc).

Les métriques marchent pas en démo. Uniquement sur l'environnement de production. Pas grave, mais bon, à savoir si tu te demandes pourquoi get_metrics te renvoie des erreurs.

Mon avis après quelques jours

Pour bosser avec des données publiques françaises, c'est un vrai raccourci. Je me vois mal retourner à l'ancienne méthode - naviguer sur data.gouv.fr, cliquer sur "télécharger", ouvrir LibreOffice Calc, loucher sur des colonnes. Non merci.

C'est un serveur MCP standard, donc ça marche avec Claude Code, Claude Desktop, Cursor, VS Code, Gemini CLI. Si t'as déjà un setup MCP, ça s'intègre en 30 secondes. Si t'en as pas, c'est une bonne excuse pour commencer.

Lien du projet : datagouv/datagouv-mcp sur GitHub

Instance publique : https://mcp.data.gouv.fr/mcp