Agents IA : ⚡ fiabilité web ? Ils ne vérifient pas
Découvrez pourquoi les agents IA en recherche web IA peuvent halluciner, comment repérer l’info non vérifiée et instaurer des règles pour des réponses fiables.
Pourquoi votre agent IA répond sans vérifier le web
Demandez à un assistant IA le prix d'un hôtel à Lisbonne pour le week-end prochain, et vous obtiendrez probablement un chiffre donné avec aplomb. Mais si vous lui demandez ensuite d'où il sort, la réponse peut devenir floue. L'agent a peut-être consulté un site de réservation quelques secondes plus tôt. Ou il a tout simplement extrapolé à partir d'une information apprise pendant son entraînement, qui n'est plus forcément vraie aujourd'hui.
On parle souvent d'« hallucination ». Pourtant, le problème n'est pas toujours que l'IA invente. Parfois, un prix ancien était exact à un moment donné, puis il a changé. Le système n'a juste pas vérifié si c'était encore le cas. Et cette nuance compte dès qu'une entreprise confie à l'IA des réponses sur ses tarifs, ses stocks, la concurrence ou des sujets réglementaires.
Au fond, la vraie question n'est pas seulement « l'agent peut-il naviguer sur le web ? », mais plutôt « quand choisit-il de le faire ? » et « que se passe-t-il quand la vérification échoue ? ». Voici comment analyser ces décisions, repérer les réponses non vérifiées et construire un agent plus fiable, sans transformer chaque demande en recherche coûteuse.
Pourquoi un agent répond de mémoire
Quand un agent reçoit une question, il doit choisir entre deux options. Soit il génère une réponse à partir de ce qu'il a appris pendant son entraînement, soit il utilise un outil pour chercher une information récente et lire une page. Dans les équipes qui construisent des agents, cette décision s'appelle parfois fetch decision : le moment où le système décide de récupérer (ou non) des données externes.
Pour l'utilisateur, ce choix est souvent invisible. Le modèle peut répondre avec le même ton confiant, qu'il ait consulté une source ou non. Le problème, c'est qu'il n'a pas une horloge fiable associée à chaque morceau de « mémoire ». Une ancienne grille tarifaire peut y coexister avec une connaissance stable (par exemple, l'eau bout à une température bien définie) sans signal clair indiquant que l'une doit être actualisée.
Une réponse plausible n'est pas forcément actuelle
Les modèles de langage sont conçus pour produire un texte cohérent à partir du contexte et de leurs paramètres. Ils ne consultent pas une base de données en temps réel à chaque phrase. Si l'information demandée ressemble à un fait déjà connu, répondre « de mémoire » est souvent le chemin le plus simple - même si, entre-temps, les prix ou les conditions ont changé.
Le risque est particulièrement fort quand on demande des choses sensibles au temps :
- un tarif d'hôtel, d'abonnement ou de billet de train ;
- des stocks et des délais de livraison ;
- des horaires d'ouverture ou des conditions d'accès ;
- le prix d'un concurrent ou des caractéristiques de son offre ;
- une règle juridique, fiscale ou administrative qui peut évoluer.
Dans ces cas, l'erreur peut induire en erreur sans que l'agent ait « inventé ». Et pour une entreprise, les conséquences sont très concrètes : un client reçoit un prix faux, un commercial compare sur une base dépassée, ou un salarié applique une règle qui n'est plus en vigueur.
La recherche implique plus qu'un clic
Chercher sur le web n'est pas une action unique. L'agent doit souvent :
- formuler une requête ;
- trouver une page pertinente ;
- y accéder ;
- récupérer le contenu ;
- puis extraire ce qui répond à la question.
À chaque étape, quelque chose peut rater. Un site peut limiter les accès automatisés ; une page peut n'afficher l'information qu'après l'exécution de JavaScript ; une bannière de consentement peut masquer le contenu ; ou la page trouvée peut simplement ne pas répondre exactement à la demande.
Ensuite, il faut nettoyer et structurer ce contenu avant de le transmettre au modèle. Les pages web contiennent menus, publicités, éléments de navigation et parfois de longs blocs sans rapport direct. Tout cela prend du temps et des jetons. À l'inverse, répondre à partir de la mémoire du modèle est généralement plus rapide et moins coûteux.
Conclusion : la recherche n'est pas une garantie de justesse. Elle fournit une possibilité de vérification, à condition que la source soit pertinente, accessible et comprise correctement. Bref : c'est un mécanisme à concevoir, pas un bouton « magique » activé par le simple mot navigation.
Pourquoi la recherche web est souvent ignorée
Dans beaucoup de systèmes, l'accès au web est présenté au modèle comme un outil qu'il peut utiliser. Le modèle décide donc, au moment de répondre, si la question justifie une recherche. C'est pratique : ça évite des appels inutiles. Mais ça transfère aussi une décision produit à un système qui ne connaît pas toujours vos exigences métier.
Le modèle peut estimer qu'une question est assez « simple » pour être traitée de mémoire. Une demande sur le prix actuel d'un concurrent peut ainsi déclencher une réponse plausible, surtout si la formulation ne contient pas de mots comme « aujourd'hui », « à jour » ou « dernière version ». Autrement dit, la nécessité de vérifier dépend parfois trop de la façon dont l'utilisateur pose sa question.
Les critères de réussite peuvent créer de mauvais réflexes
Souvent, les équipes évaluent l'assistant sur sa rapidité, sa fluidité et sa capacité à ne pas interrompre l'utilisateur. En démo, un agent qui affiche « impossible de charger cette page » peut donner l'impression d'être en panne. À l'inverse, celui qui fournit immédiatement un chiffre net paraît plus performant - même si ce chiffre est obsolète.
Au fil des versions, les choix de conception finissent parfois par pousser vers des réponses « immédiates » : des prompts qui découragent les recherches longues, des seuils trop prudents, des outils de navigation instables, ou une gestion d'erreur qui fait disparaître les échecs. La recherche devient alors l'exception. Et comme l'utilisateur ne voit pas ce qui s'est passé en coulisses, l'équipe peut ne pas remarquer que l'agent vérifie rarement.
Le problème n'est pas uniquement « la qualité » du modèle. Même en changeant pour un modèle plus récent, vous améliorez parfois certains comportements... sans résoudre le fait que la recherche reste facultative. Un modèle capable d'utiliser le web peut choisir de ne pas le faire. Si votre produit exige une donnée actuelle, la règle doit être portée par le système - via ses outils et son orchestration - pas laissée à une consigne « au conditionnel ».
Le coût doit être mesuré au bon endroit
La recherche a un coût : latence, jetons, appels à des services externes, maintenance de l'intégration. Mais il faut comparer ce coût au coût d'une réponse erronée.
- Pour une question générale, sans enjeu fort, une réponse de mémoire peut suffire.
- Pour un prix contractuel, une info de conformité, ou une disponibilité annoncée à un client, le coût d'une erreur peut être bien plus élevé que celui d'une vérification.
L'idéal est de mesurer aussi la fréquence des recherches par sujet, leur taux de réussite et les conséquences réelles des erreurs. Sans ça, l'arbitrage entre rapidité et fiabilité repose sur l'intuition - et finit souvent au détriment de la vérification, parce que son bénéfice est moins visible qu'un temps de réponse plus court.
Comment concevoir un agent plus fiable
Pour rendre un agent plus prévisible, il faut traiter la recherche comme une fonction du produit. L'objectif n'est pas d'imposer une consultation web pour chaque question : ce serait lent, coûteux, et parfois inutile. L'enjeu est plutôt de définir quand l'information doit être récente, puis de rendre cette règle observable et appliquée automatiquement.
1. Mesurer les recherches réellement effectuées
Suivez la proportion de réponses fondées sur une page effectivement récupérée, en distinguant les catégories de demandes. Une moyenne globale peut masquer un problème majeur : par exemple, l'agent peut vérifier les définitions générales de manière systématique, mais presque jamais les prix.
Mesurez aussi le taux de recherche réussie, les pages inaccessibles, les délais et les cas où l'agent retombe sur une réponse de repli. Ces mesures doivent être utiles aux équipes produit et opérationnelles : elles servent à détecter l'écart entre le niveau de vérification attendu et celui observé.
2. Imposer la vérification là où l'actualité est nécessaire
Définissez des règles explicites pour les prix, les niveaux de stock, les horaires, les conditions d'éligibilité et les informations juridiques ou financières. Une classification simple peut associer chaque type de question à une politique : mémoire autorisée, recherche recommandée, ou recherche obligatoire.
Par exemple, l'assistant peut répondre de mémoire à une question conceptuelle sur le fonctionnement d'un abonnement. En revanche, si on lui demande le tarif actuel à un client, il doit consulter une source à jour (ou dire clairement qu'il ne peut pas confirmer). Cette logique doit être inscrite dans le code applicatif : routeur de requêtes, règles d'orchestration, garde-fous. L'idée est d'empêcher le modèle d'ignorer la contrainte « juste parce qu'il pense que la réponse est évidente ».
3. Rendre les échecs visibles
Quand une page ne peut pas être chargée, l'agent doit le dire clairement. Par exemple : « Je n'ai pas pu confirmer ce tarif sur la source officielle. » Plutôt que de combler le trou avec un chiffre issu de sa mémoire.
L'interface peut ensuite proposer une action concrète : réessayer, ouvrir la page, ou demander un document à l'utilisateur. Et surtout : ces échecs doivent être analysables par l'équipe. Si les échecs se produisent souvent sur des sites importants, c'est un problème d'intégration ou de couverture. Les masquer peut rendre la démo « plus jolie », mais ça abîme la confiance dès qu'un utilisateur tombe sur une erreur.
4. Réduire les étapes sans supprimer les contrôles
Certaines architectures assemblent plusieurs services : rechercher, ouvrir les pages, nettoyer le contenu. Chaque passage ajoute de la latence et multiplie les points de panne. Simplifier le parcours peut améliorer la fiabilité, tant que vous conservez les contrôles essentiels : provenance, date, qualité de la page, statut de récupération.
Par exemple, une API de données web peut permettre à un agent de rechercher des pages et d'en extraire le contenu sous une forme exploitable. Des fournisseurs comme Decodo présentent ce modèle comme un moyen de réduire les obstacles techniques liés aux pages et aux accès automatisés. Mais il faut évaluer chaque solution selon les sites visés, les conditions d'utilisation, la qualité des résultats et les exigences de conformité. Un accès « plus facile » ne remplace pas le fait de vérifier que la collecte est autorisée et appropriée.
5. Évaluer le résultat de bout en bout
Ne testez pas seulement si l'outil de recherche répond. Vérifiez que l'agent :
- trouve la bonne page ;
- extrait la bonne donnée ;
- la restitue sans la déformer ;
- et fournit une source compréhensible.
Un test utile inclut aussi les cas d'échec : contenu inaccessible, informations contradictoires, page périmée, absence de résultat.
Pour un déploiement sérieux, conservez une trace proportionnée des sources utilisées et des décisions importantes. Cette traçabilité aide à diagnostiquer les erreurs et à répondre aux besoins internes de contrôle. Attention quand même au cadre légal : notamment le RGPD si des données personnelles passent dans les requêtes ou les journaux. La recherche web ne donne pas tous les droits pour transmettre n'importe quelle donnée à n'importe quel service.
Conclusion : choisir le niveau de vérification selon le risque
Un agent utile n'est pas celui qui recherche tout, ni celui qui répond toujours instantanément. C'est celui qui sait distinguer une connaissance stable d'une information qui vieillit vite, et qui rend son niveau de certitude visible.
Pour les sujets à faible enjeu, la mémoire peut suffire. Pour ce qui change et engage l'entreprise, la vérification doit faire partie du parcours - avec une réponse honnête quand elle échoue.
Avant votre prochain déploiement, prenez quelques questions fréquentes - prix, disponibilité, réglementation, délais - et vérifiez concrètement si l'agent consulte une source, laquelle, et comment il répond quand il ne peut pas y accéder. Cette petite revue dit souvent plus que le simple fait de savoir si l'outil « sait naviguer ».
Comment repérer une réponse non vérifiée
Les interfaces ne montrent pas toujours comment l'agent a travaillé. Il existe pourtant des indices. Dans un produit bien conçu, une réponse issue d'une page consultée devrait afficher au moins la source utilisée, et idéalement le moment de la vérification. Si aucune référence n'apparaît, ce n'est pas forcément de la « fabrication » : ça peut venir de la mémoire du modèle, d'un document déjà indexé, ou d'une recherche qui n'a finalement rien donné. L'absence de lien ne permet donc pas, à elle seule, d'identifier la cause.
Pour un usage courant, demandez explicitement à l'assistant de vérifier l'information et de fournir la source. Par exemple : « Consulte la page officielle des tarifs, puis indique le lien et la date de consultation. » Cela peut pousser l'agent à utiliser un outil, mais ce n'est pas une validation humaine si l'enjeu est important.
Lire les sources, pas seulement les citations
Une citation à l'écran est utile, mais ce n'est pas une preuve que l'agent a correctement compris la page. Vérifiez :
Une page ancienne, une annonce promotionnelle expirée ou un résumé tiers peut donner une impression de traçabilité sans confirmer ce que vous cherchez.
Pour les informations commerciales, commencez par la page officielle de l'entreprise concernée. Pour une démarche française, référez-vous d'abord au site de l'administration compétente ou à une source réglementaire officielle. Pour les sujets européens, EUR-Lex est plus adapté qu'un résumé non daté. Le niveau de vérification doit coller à l'enjeu : une idée de voyage et une obligation légale ne demandent pas le même contrôle.
Les questions à poser à un fournisseur
Avant d'adopter un outil d'IA en entreprise, demandez au fournisseur :
La réponse du type « notre agent sait naviguer sur le web » ne suffit pas. Elle décrit une capacité, pas la fréquence d'utilisation, ni le comportement exact quand cette capacité ne fonctionne pas.