Le problème du « café le plus proche » : pourquoi les agents IA ont besoin d'une carte

Demandez à un agent IA le café le plus proche et il répond dans une phrase complète, nom de rue compris : 300 mètres devant vous, rue Saint-Jean. Certaines de ces phrases sont fausses, et une fausse se confond avec une vraie au moment précis où vous avez besoin de la réponse. L'erreur est invisible des deux côtés. L'utilisateur entend une phrase assurée, et le modèle ne lève aucun drapeau, parce que rien dans ses poids ne lui a jamais dit qu'il devinait.

Un agent qui invente un lieu est pire qu'une boîte de recherche, pour une raison précise : une boîte de recherche montre au moins des candidats qu'une personne peut se garder de croire. La solution n'est pas de rendre le modèle meilleur en géographie. La solution, c'est de cesser de demander la géographie au modèle, tout court. Donnez-lui des outils qui renvoient de la géométrie vérifiée : une phrase de lieu résolue en une coordonnée qu'il peut contrôler, un polygone qui signifie ce que la question signifie, une réponse d'appartenance calculée contre la vraie limite, et un unsupported bruyant quand la couche en dessous n'a rien. Mapbox, HERE et Overture ont passé une bonne partie de 2026 à publier sur exactement ce manque, ce qui prouve au minimum que l'industrie a admis qu'il portait un nom.

Une boîte de recherche montre ses candidats, un agent affirme

La fluidité est un danger d'interface en géographie d'une manière qu'elle n'est pas ailleurs. Une mauvaise réponse à « résume ce document » se dégrade en prose. Une mauvaise réponse à « où est le café le plus proche » envoie un inconnu marcher dans la mauvaise direction, et la phrase qui porte l'erreur sonne exactement comme la phrase qui porte la vérité. Une erreur 404, elle, se lit. Un nom de rue plausible avec une distance en mètres, non.

La partie étrange, c'est que les questions de géographie sont presque toujours vérifiables en principe. Il existe une bonne réponse, posée dans un jeu de données que la plateforme licence déjà, et le modèle a refusé de la consulter. Cela rend la réponse non fondée moins pardonnable, pas plus : l'agent devine avec une porte ouverte sur la bonne réponse, à deux appels d'outil.

Même une coordonnée correcte peut répondre à la mauvaise question. « Le plus proche », mesuré comment ? À vol d'oiseau depuis un pixel, à pied le long du réseau, ou en voiture ? Un café à 300 m de l'autre côté de la rivière est plus loin qu'un café à 600 m en passant par le pont, et un agent non ancré a confondu les trois sans remarquer qu'il y avait eu un choix à faire.

Ancrage, étape un : ne jamais faire confiance à une coordonnée écrite par le modèle

Le premier outil dont la boucle a besoin transforme une phrase de lieu en un point résolu et vérifié. resolve_place prend la phrase en texte libre plus le contexte que la conversation offre, et renvoie une liste de candidats avec identifiants, noms, coordonnées et source, plutôt qu'un verdict unique. Le modèle peut nommer un lieu, seul un outil peut nommer un point.

Nous avons appris cette inversion à nos dépens. Notre premier harnais d'agent laissait le modèle répondre avec des coordonnées et les validait ensuite. Le validateur se déclenchait sans arrêt. Lire les quasi-ratés pendant une semaine a enseigné la leçon à graver sur une tasse de café : un modèle auquel on demande de produire des coordonnées produit des coordonnées assurées, des nombres plausibles près de la bonne ville, faux de centaines de mètres, assez faux pour compter et assez bien formatés pour convaincre. La validation après coup continuait d'attraper des navires déjà partis. Le correctif fut d'inverser le flux pour que le navire ne quitte jamais le port.

L'ambiguïté survit à la résolution, et c'est bien ainsi, tant qu'elle est portée à la surface. Quand deux candidats sont éloignés l'un de l'autre au nom proche (le problème de la « Station Road », dont nous avons écrit en avril, dans notre billet sur le géocodage d'un recensement), la bonne conduite est de choisir l'un en énonçant la raison, ou de restituer le choix à l'utilisateur, jamais de trancher en silence et d'avancer.

Parfois, la bonne réponse est un polygone

Une grande part des questions que les gens posent à un agent cartographique ont une géométrie pour réponse, et la prose est le mauvais type pour elle. « Où puis-je marcher à moins de 15 minutes de l'hôtel » est un isochrone : un polygone calculé sur le vrai réseau de marche, pour un mode précis et un budget de temps précis. Il change avec l'heure et avec la saison. Une marche de 15 minutes au rythme du dimanche matin n'est pas le même polygone qu'une marche de 15 minutes un après-midi de semaine sur le même réseau. Si l'agent répond à cette question par une phrase, il a répondu à une question de géométrie au ressenti, et le ressenti embarque un mode, un sens de marche et une horloge dont la phrase ne dit rien.

Les questions d'appartenance sont de la même espèce. « Le site est-il dans la zone de l'école » ou « cette parcelle est-elle dans la couche d'inondation » est un calcul point-dans-polygone contre les vraies données de limite, pas le souvenir de l'apparence d'une limite dans l'entraînement. Le polygone contient le point ou ne le contient pas, et le travail de l'agent est d'exécuter ce calcul et d'attacher à la réponse le nom et la date de la couche.

Cartographier la trace, puis réclamer la route

Chaque fois qu'une position brute apparaît dans le flux, point de téléphone, trace GPS, ping de livreur, le map matching la place quelque part de réel. Le map matching accroche une polyligne bruitée au chemin le plus probable sur le vrai réseau, de sorte que la réponse à « où était l'équipe » référence une route qui existe plutôt qu'une oscillation dans l'échantillon. Les points appariés passent ensuite par le même contrôle inverse que les géocodés : devant quel élément nommé se trouve ce point, à quelle distance, et est-ce que cette distance passe le seuil. Le motif se répète parce qu'il marche.

La boucle, telle que nous la construisons aujourd'hui

L'ensemble tient sur un écran :

GROUNDING_TOOLS = {
    "resolve_place": ...,  # phrase + context -> candidates (id, name, lat, lon, source)
    "reverse_check": ...,  # verified coordinate -> nearest feature + distance_m
    "isoline": ...,        # coordinate + minutes + mode -> polygon
    "contains": ...,       # coordinate + layer id -> inside | outside | unsupported
}

def grounded_reply(turn, user_place):
    if turn.writes_coordinates():
        refuse("coordinates must come from a tool result, never from weights")
    place = choose_candidate(GROUNDING_TOOLS["resolve_place"](user_place, turn.context))
    proof = GROUNDING_TOOLS["reverse_check"](place.lat, place.lon)
    if proof.distance_m > 50:
        return ask_user_to_disambiguate(place.candidates)
    if turn.question == "where_can_i_walk_in_15_minutes":
        polygon = GROUNDING_TOOLS["isoline"](place.lat, place.lon, 15, mode="walk")
        return answer_with_geometry(place, polygon, provenance=[proof])
    return answer_with_prose(place, proof)

Trois propriétés font le travail de fond. Le schéma fait des appels d'outil le seul chemin vers la géométrie, si bien que le modèle ne peut répondre à une question de lieu sans en passer par un. Chaque affirmation géométrique porte sa provenance dans la réponse, si bien que la phrase et sa preuve voyagent ensemble. Et la branche de refus est du vrai code, pas une ligne dans le prompt.

Quand la couche en dessous répond unsupported

Un agent a aussi besoin de savoir quand il ne devrait avoir aucune opinion. Nous avons rendu open source everymap-rs, un client à base de traits qui enveloppe le géocodage, le routage, les isochrones, le map matching, la planification de tournées et le trafic sur HERE, Google, TomTom, Mapbox et Radar : 35 implémentations réelles sur 5 fournisseurs, publié pour la première fois en septembre 2026. La partie instructive pour les agents, c'est son style d'échec. Un domaine qu'un fournisseur n'implémente pas échoue bruyamment, si bien que demander le trafic à Google renvoie une erreur qui dit exactement cela, au lieu d'un succès vide qui glisse en aval pour devenir le bug de quelqu'un. Ce texte d'erreur est ce qu'un agent ancré devrait faire remonter : « Je ne peux pas répondre à cela à partir des données » bat à chaque fois une supposition fluente, parce que seule la première peut être crue deux fois.

Limites honnêtes : la boucle est de la plomberie, et la plomberie fuit

Honnêtes jusqu'au bout, donc. Une coordonnée vérifiée est une affirmation avec une source, pas une vérité terrain. L'ambiguïté entre candidats survit à la boucle, et l'outil choisit faux de temps en temps, à un taux que nous n'avons pas mesuré rigoureusement. Les isochrones varient avec l'heure et le mode, si bien qu'une réponse polygonale n'est valable que pour l'horloge sous laquelle elle fut calculée. Les couches de commerces voisins portent la fraîcheur de leurs flux, si bien qu'un café fermé le mois dernier peut être parfaitement apparié et parfaitement mort. Et les modèles tentent encore de répondre depuis les poids chaque fois que le schéma laisse un trou, si bien que la contrainte doit être stricte et relue. Une ligne de prompt priant le modèle d'utiliser les outils n'a jamais empêché un modèle de sauter un outil.

Si votre agent énonce un jour une distance en mètres, un nom de rue ou une paire de coordonnées, remontez à la source de ces nombres. Si la réponse est « les poids », la phrase est une fiction, si fluente soit-elle.

La fluidité n'est pas un système de coordonnées.