Open data et IA : pourquoi un MCP ne remplace pas une donnée territoriale fiabilisée

Depuis février 2026, data.gouv.fr expose ses jeux de données aux assistants d’IA via un serveur MCP. Interroger l’open data en langage naturel devient possible. Obtenir une réponse juste sur un territoire reste un autre problème. Cet article explique pourquoi, et ce qui sépare un accès brut aux données d’une donnée exploitable pour une décision immobilière ou une politique publique.

Ce que change le MCP de data.gouv

Le Model Context Protocol (MCP) est un standard ouvert qui permet à un modèle de langage (LLM) d’appeler des outils externes : rechercher un jeu de données, lire ses métadonnées, interroger un fichier tabulaire. Le 25 février 2026, data.gouv.fr a ouvert un serveur MCP expérimental, en lecture seule. Concrètement, un utilisateur peut demander à son assistant d’IA « quel est le prix moyen des appartements vendus à Aix-en-Provence en 2024 ? » et l’IA va chercher elle-même les fichiers correspondants.

L’avancée est réelle. Elle supprime une partie du travail de recherche : savoir quel jeu de données existe, où il se trouve, sous quel format. Pour une question exploratoire, c’est un gain de temps.

La question posée par les professionnels de l’immobilier et les collectivités est différente : ce canal peut-il remplacer un service spécialisé d’analyse territoriale ? La réponse courte : non. Pas pour des raisons de confort d’interface, mais pour des raisons de qualité de la donnée.

Accéder à la donnée n’est pas la fiabiliser

L’open data publique française est abondante. Elle n’est pas prête à l’emploi. Chaque base est produite par une administration différente, selon sa propre logique, son propre calendrier et sa propre géographie. Les fichiers contiennent des doublons, des valeurs aberrantes, des ruptures de série et des zones non couvertes.

Un MCP transmet ces fichiers tels qu’ils sont publiés. Il ne corrige rien. Le LLM qui les reçoit n’a ni le temps, ni le contexte, ni la méthode pour les corriger à la volée. Il produit une réponse plausible à partir d’une matière première brute. La forme est fluide ; le fond peut être faux sans que rien ne le signale.

data.gouv.fr le reconnaît elle-même : ce type de dispositif est difficile à auditer. Elle signale aussi l’existence de nombreux serveurs MCP non officiels qui se présentent comme liés à la plateforme. La provenance de la donnée, premier critère de qualité, devient elle-même incertaine.

Les pièges concrets de l’open data immobilier et territorial

Quatre exemples montrent l’écart entre la donnée publiée et la donnée exploitable.

1. Les valeurs foncières (DVF)

La base Demandes de valeurs foncières recense les mutations immobilières. Une seule vente peut y apparaître sur plusieurs lignes : une par lot, par local ou par parcelle, avec le prix total répété sur chacune. Calculer un prix moyen sans regrouper les mutations revient à compter plusieurs fois la même vente et à attribuer à un studio le prix d’un immeuble entier.

S’ajoutent les ventes en bloc, les cessions entre apparentés, les biens mixtes, les surfaces absentes ou incohérentes. Un prix au m² calculé sans filtrage peut s’écarter fortement de la réalité du marché. Enfin, DVF ne couvre ni l’Alsace-Moselle ni Mayotte : une réponse sur Strasbourg ou Metz construite à partir de ce fichier est vide ou fausse.

2. Le recensement de la population

L’INSEE produit des résultats annuels à partir de cycles de collecte de cinq ans. Comparer deux millésimes trop rapprochés mesure en partie des effets de méthode, pas des évolutions réelles. Un LLM qui compare 2021 et 2022 pour conclure à une baisse de population commet une erreur d’interprétation que rien dans le fichier ne l’empêche de faire.

3. La géographie qui bouge

Les communes fusionnent, les intercommunalités se recomposent, les codes changent chaque année. Une série sur dix ans n’a de sens que si toutes les années sont ramenées à un même découpage. Sans cette harmonisation, une commune nouvelle semble « gagner » des milliers d’habitants en un an, et ses communes déléguées disparaissent des statistiques.

4. Le secret statistique

Pour les petites communes et les quartiers peu peuplés, certaines données, notamment de revenus, ne sont pas diffusées. Le fichier contient alors des cellules vides ou masquées. Un modèle de langage, conçu pour produire une réponse, a tendance à combler ce vide : par extrapolation, par approximation, voire par invention. La réponse correcte est souvent « cette donnée n’existe pas à cette échelle ».

Ce qu’un LLM fait, et ce qu’il ne fait pas

Un LLM est un outil de langage. Il excelle à reformuler, synthétiser, expliquer. Il n’est pas un moteur de calcul fiable ni un contrôleur de qualité de données.

Trois limites structurelles s’appliquent, quel que soit le modèle :

• Le volume. DVF compte plusieurs millions de lignes par an à l’échelle nationale. Un assistant d’IA travaille sur des extraits, des échantillons ou des requêtes ponctuelles. Il ne voit jamais l’ensemble, donc il ne détecte pas les incohérences qui n’apparaissent qu’à l’échelle de la base entière.
• La reproductibilité. Deux questions identiques peuvent produire deux chemins de calcul différents, donc deux résultats différents. Pour un comité d’engagement, un dossier de permis de construire ou un diagnostic de PLH, un chiffre qui varie selon la formulation de la question n’est pas utilisable.
• L’absence de connaissance métier. Savoir qu’il faut exclure les ventes en bloc, respecter l’écart de cinq ans entre deux recensements ou harmoniser le code officiel géographique relève d’une expertise accumulée. Le LLM ne l’applique que si on la lui impose, à chaque requête, et sans garantie qu’il la suive.

Le risque principal n’est pas l’erreur visible. C’est l’erreur crédible : un chiffre précis, bien présenté, cité avec assurance, et faux. Dans un projet immobilier ou une politique de logement, cette erreur se paie en programmation inadaptée, en prix de sortie mal calibrés ou en équipements mal dimensionnés.

La méthode Terre de Données : robustesse sur plusieurs échelles territoriales

Terre de Données traite l’open data territoriale en amont, une fois, avec une méthode documentée, plutôt qu’à la volée, à chaque question. La différence porte sur quatre points.

Collecte et provenance. Les données sont collectées depuis les sources officielles (INSEE, DGFiP, ministères, opérateurs publics), versionnées et datées. Chaque indicateur affiché correspond à une source identifiée et à un millésime précis.

Nettoyage et contrôle de qualité. Les doublons sont regroupés, les valeurs aberrantes détectées et écartées, les mutations atypiques filtrées. Les ruptures de série sont identifiées avant toute comparaison temporelle.

Harmonisation géographique. Toutes les données sont ramenées à un découpage cohérent, du quartier à la commune, de l’intercommunalité au département. Un indicateur reste comparable d’une année sur l’autre et d’un territoire à l’autre.

Cohérence entre échelles. Un chiffre communal doit être compatible avec la somme de ses quartiers et avec la moyenne de son intercommunalité. Ces contrôles croisés détectent les anomalies qu’aucune requête isolée ne fait apparaître. Lorsque la donnée n’est pas fiable à une échelle donnée, elle n’est pas affichée, ou elle l’est avec son avertissement.

Le résultat : des indicateurs éco-socio-démographiques et immobiliers stables, comparables et vérifiables pour les 35 000 communes de France, restitués sous forme de visualisations lisibles.

Concurrence ou complémentarité ?

Le MCP de data.gouv et les assistants d’IA vont progresser. Ils vont réduire le coût d’accès à l’open data et habituer les utilisateurs à interroger la donnée en langage naturel. Pour une question de culture générale sur un territoire, ils suffiront souvent mais ils ne répondent pas au même besoin qu’un service d’analyse territoriale. La comparaison utile peut se résumer ainsi :

La question pertinente n’est donc pas « IA ou service spécialisé ». Elle est : Quel niveau de fiabilité exige la décision ? Une intuition à vérifier tolère une approximation. Un bilan de promotion, une programmation de logements ou un argumentaire face aux services de l’État ne la tolèrent pas.

À terme, les deux approches convergent : une IA interrogeant des données déjà fiabilisées produit des réponses fiables. Une IA interrogeant des données brutes produit des réponses brutes, mieux rédigées.

Ce qu’il faut retenir

• Le MCP de data.gouv facilite l’accès à l’open data. Il ne garantit ni la qualité, ni la cohérence, ni la justesse des réponses.
• Les bases publiques (DVF, recensement, revenus) contiennent des pièges de méthode qu’un LLM ne corrige pas spontanément.
• Le principal risque est l’erreur crédible : un chiffre précis et faux.
• La valeur d’un service comme Terre de Données réside dans le travail fait en amont : nettoyage, harmonisation géographique, contrôles de cohérence entre échelles territoriales.
• Pour un projet immobilier ou une politique publique, la qualité de la donnée conditionne la qualité de la décision.