Aller au contenu

Les LLM - Retours d'expérimentations

Cette page reprend les enseignements de quelques expérimentations réalisées en 2024 et 2025 sur l'utilisation des LLM avec les données et services géographiques de l'IGN (dépôt archivé mborne/llm-experimentations).

⚠️ Mise en garde : Certains constats datent principalement de 2024 et ont été faits avec ChatGPT (GPT-4o). Les modèles progressent et la recherche web est désormais souvent activée par défaut : les phénomènes observés sont à revérifier avec les modèles actuels.

Points clés

  • Un LLM n'est pas un géocodeur : il faut lui donner accès à un véritable service de géocodage.
  • Il faut s'appuyer sur des données de référence plutôt que sur la mémoire du modèle.
  • L'intégration des API est passée des actions ChatGPT aux serveurs MCP.
  • Les services conçus pour les besoins cartographiques (ex : WFS, APICARTO...) ne sont pas forcément adaptés à une utilisation par des LLM (d'où le serveur MCP ignfab/geocontext).
  • Une fois l'accès aux données fourni, il est possible de générer des cartes web (ex : montmorillon, spec-driven-maps).

Historique

graph LR
  A["<b>Actions ChatGPT</b><br />(OpenAPI, licence payante)<br />2024"]
  B["<b>mcp-server-gpf</b><br />(premier serveur MCP)<br />2025"]
  C["<b>ignfab/geocontext</b><br />(serveur MCP Géoplateforme)"]
  D["<b>montmorillon</b><br />(génération de cartes web)<br />2026"]
  E["<b>spec-driven-maps</b><br />(cartes web par SDD)<br />2026"]

  A --> B
  B --> C
  C --> D
  D --> E
  C --> E

Besoin d'un véritable service de géocodage

Sans service dédié, la précision du géocodage réalisé par ChatGPT est variable (voir ChatGPT - les limites des capacités de géocodage par défaut (2024-08-12)) :

Cas testé Constat
Monument (tour Eiffel), ville (Besançon) Position précise
Village (Loray) Plusieurs kilomètres d'écart
Adresse (site IGN de Saint-Mandé) Plus de 100 m d'écart

La recherche web ne remplace pas un géocodeur :

  • Le modèle agrège des coordonnées trouvées sur différentes sources web (il n'appelle pas un service de géocodage).
  • Pour l'adresse de l'IGN, les sources sont cohérentes entre elles mais présentent un biais d'environ 500 m.
  • Demander explicitement une recherche web dégrade encore la précision.

L'appel au service d'autocomplétion de la Géoplateforme corrige ces cas (adresse IGN, village de Loray, mairie de Vincennes).

Voir ChatGPT - intégration du service de géocodage de la Géoplateforme (2024-08-12).

S'appuyer sur des données de référence

Les réponses produites à partir de la seule mémoire du modèle sont imprécises voire incohérentes :

Pour obtenir une réponse fiable, il convient d'enrichir le contexte avec des données de référence avant la production de la réponse (ex : appel au module codes-postaux d'APICARTO par tool calling).

Des services conçus pour la cartographie

Les services existants ont été conçus pour les besoins cartographiques (ex : WFS, APICARTO...) et ne sont pas forcément adaptés à une utilisation par des LLM :

  • Les réponses sont volumineuses (géométries complètes) et coûteuses en tokens.
  • Les paramètres sont techniques (filtres CQL, noms de couches, systèmes de coordonnées...).
  • Une question simple nécessite souvent de combiner plusieurs appels (ex : géocodage puis recherche spatiale).

D'où l'intérêt d'une surcouche dédiée sous forme de serveur MCP proposant des outils de plus haut niveau (voir ignfab/geocontext).

Génération de cartes web

Avec un assistant de codage disposant d'un accès aux données (ex : ignfab/geocontext), il est possible de produire des cartes web sous forme de sites statiques (ex : MapLibre GL JS, hébergement GitHub Pages).

Génération à partir d'un prompt

Les cartes de montmorillon (2026-05-29) ont été générées rapidement pour le Printemps des Cartes 2026 (carte d'accès, carte touristique, bâtiments en 3D). La non conservation des prompts a motivé la bascule sur une approche Spec-Driven Development (SDD) traçant mieux les demandes.

Génération avec une approche SDD

spec-driven-maps (2026-09-29) reprend ces cartes et en produit de nouvelles avec une approche Specification-Driven Development (SDD). Chaque carte est un dossier contenant :

  • specs/spec.md : quoi et pourquoi (demande, objectif, public, critères d'acceptation, décisions) ;
  • specs/plan.md : comment (sources de données, traitements, symbologie, rendu) ;
  • specs/tasks.md : les tâches de réalisation ;
  • README.md : la carte, la méthode et un prompt équivalent permettant de commander directement une carte similaire.

Les points notables de cette approche sont les suivants :

  • Les données sont contrôlées avec le MCP avant de choisir la symbologie (ex : répartition des hauteurs des bâtiments de la BD TOPO pour définir des classes adaptées).
  • Les données sont traçables : chaque lieu est décrit par une référence à sa source (identifiant BD TOPO, notice Mérimée ou adresse géocodée) et un script produit un GeoJSON versionné (ou la page lit directement les tuiles vectorielles de la Géoplateforme).
  • Les critères d'acceptation permettent de vérifier le résultat (ex : la légende correspond exactement à la coloration affichée).
Carte Description
commune-doubs Densité de population des communes du Doubs
montmorillon-acces Carte d'accès au Printemps des Cartes 2026
montmorillon-tourisme Carte touristique de Montmorillon
montmorillon-bdtopo-3d Bâtiments de Montmorillon en 3D
vignobles Densité de vignoble par commune et vignes de la BD TOPO (en construction)