Decodo explique pourquoi les agents IA préfèrent deviner plutôt que vérifier

Un arbitrage invisible entre mémoire et recherche

Demandez à un assistant d'intelligence artificielle le tarif d'un hôtel de gamme moyenne à Lisbonne pour le week-end suivant. Vous obtiendrez un chiffre, énoncé avec assurance. Si vous demandez ensuite d'où il vient, l'explication devient floue.

Parfois l'agent a réellement consulté un site de réservation quelques secondes plus tôt. Parfois il n'a rien vérifié et a livré un montant issu de ses données d'entraînement, qui peut dater de deux étés. Le ton employé est identique dans les deux cas. On parle souvent d'hallucination, mais il s'agit plutôt d'un prix qui a existé à un moment donné, sans que le système ait eu pour consigne de confirmer qu'il était toujours valable, rapporte The Next Web.

La décision de recherche, un choix rarement tracé

Avant de répondre, un agent doit trancher entre puiser dans sa mémoire et aller lire une page. Les développeurs appellent cela la décision de fetch. L'utilisateur ne la voit jamais. Presque aucune des équipes avec lesquelles travaille Decodo ne l'enregistre, alors que leurs tableaux de bord affichent le coût de chaque requête à une fraction de centime près.

Dans la plupart des frameworks d'agents, l'ingénieur ne prend même pas cette décision : la recherche web est exposée au modèle comme un outil qu'il peut mobiliser, et c'est lui qui juge sur le moment si la question l'exige. Ce jugement est plus fragile qu'il n'y paraît. Un modèle n'a aucune notion de l'ancienneté des faits stockés dans sa mémoire : un tarif hôtelier de 2024 y côtoie la température d'ébullition de l'eau avec la même certitude non datée.

Une recherche web plus coûteuse que la mémoire

La consultation du web suppose davantage d'étapes qu'on ne l'imagine : un appel de recherche pour trouver la bonne page, puis un fetch. C'est là que le processus casse le plus souvent : le site bloque les visites automatisées, ou le prix n'apparaît qu'après exécution du JavaScript, et l'agent reçoit une bannière de consentement aux cookies.

Ce qui revient doit ensuite être nettoyé avant lecture par le modèle. Chaque paragraphe se paie en tokens et en secondes, alors que la remémoration ne coûte presque rien. Les équipes produit, elles, évaluent les agents sur la vitesse et la fluidité. En revue, un agent qui répond « je n'ai pas pu charger cette page » paraît défaillant, tandis que celui qui cite un prix périmé passe pour fiable. Au fil des cycles de version, chaque prompt ajusté et chaque paramètre par défaut choisi dans l'urgence rendent la vérification un peu plus facile à contourner, jusqu'à ce que répondre de mémoire devienne la norme.

Distinguer une réponse vérifiée d'une réponse devinée

La décision de fetch échappe à l'utilisateur, mais son résultat est souvent repérable. Une réponse construite sur une page consultée en direct indique généralement sa provenance, avec un lien et souvent la date de vérification. Une réponse issue de la mémoire se lit aussi couramment, mais sans lien. Pour tout ce qui évolue vite, comme un prix ou un horaire de vol, mieux vaut considérer une réponse sans source comme une supposition. Demandez à l'assistant de vérifier et de montrer sa source : cette requête supplémentaire change souvent la réponse.

Les entreprises qui achètent des outils d'IA peuvent poser la même question avant de signer. Interrogez le fournisseur sur la fréquence à laquelle son agent consulte le web avant de répondre sur un prix ou une disponibilité, et sur ce que voit l'utilisateur quand cette vérification échoue.

Ce que les acheteurs et les développeurs peuvent exiger

La navigation web devient une fonction standard, et la plupart des agents savent déjà l'utiliser, mais pas tous. Pour ceux qui en sont incapables, il est possible de brancher un service tiers de données web via un plugin ou une API, afin que l'agent cherche et lise des pages en direct.

Changer de modèle est le premier réflexe des développeurs, et il produit moins d'effet qu'espéré. Les modèles les plus récents savent naviguer, mais décident délibérément de s'en passer. Si le modèle juge une recherche inutile, il répond à partir de son entraînement, ce qui, pour un prix, peut être très daté. La formulation pèse souvent : une question contenant « aujourd'hui » ou « dernier » envoie généralement l'agent sur le web. « Combien notre principal concurrent facture-t-il son offre d'entrée ? » peut encore recevoir une réponse de mémoire, même si ce tarif a changé deux fois depuis l'entraînement.

La solution réside dans la façon dont le produit est construit autour du modèle. Quatre exigences se dégagent : mesurer la part de réponses fondées sur une page réellement lue, par thème ; rendre la vérification obligatoire pour les prix, les niveaux de stock et tout sujet juridique ou financier, en l'inscrivant dans le code pour que le modèle ne puisse pas l'éviter ; signaler à l'utilisateur les échecs de vérification et permettre à l'équipe d'en suivre la fréquence ; simplifier la consultation, car empiler plusieurs services ajoute des délais et des points de défaillance.

C'est ce dernier point que Decodo travaille le plus, et qui a motivé la création de sa Web Data API. Avec une seule clé, un agent peut chercher sur le web, examiner l'organisation d'un site, collecter des pages ou extraire le contenu d'une page unique. Le service s'appuie sur un pool d'adresses IP sourcées éthiquement, ce qui lui permet de lire des sites qui bloquent les visiteurs automatisés. La page revient en texte propre, directement exploitable, plutôt qu'en code brut.

Reprenons la question du concurrent : avec un accès web en direct, l'agent ouvre la page tarifaire actualisée et y lit le prix du jour. La réponse vient de la page, pas de la mémoire du modèle. La plupart des outils d'IA savent déjà chercher sur le web et beaucoup affichent leurs sources. Ce qui manque encore, c'est la constance. Un agent qui vérifie un prix sur une question et répond de mémoire à la suivante, sans moyen de distinguer les deux, inspire difficilement confiance dès qu'il s'agit d'argent.