Un outil de recherche web pour agents IA qui rapporte le texte des pages

Pourquoi un agent a-t-il besoin du texte des pages et pas seulement des snippets ?

Parce que la réponse se trouve rarement dans le snippet. Une page de résultats donne un titre et une ou deux lignes choisies par le moteur de recherche. Le chiffre, la date ou la règle que votre utilisateur demande se trouve plus bas dans la page.

Un agent qui ne voit que des snippets a deux mauvaises options. Il peut répondre à partir d'un fragment et risquer de se tromper, ou appeler un second outil pour récupérer chaque page. La seconde option double les allers-retours et les définitions d'outils.

Avec LLMWebSearch, les premières pages arrivent déjà lues. La navigation, les publicités et les bannières de cookies sont supprimées, donc le modèle dépense ses tokens sur le contenu. Les autres résultats conservent leurs snippets, ce qui aide le modèle à décider s'il doit relancer une recherche.

Comment définir l'outil de recherche ?

Gardez un schéma minimal : un seul query requis et, au maximum, un ou deux commutateurs. Les modèles appellent plus fiablement des outils simples. L'exemple ci-dessous expose un flag recent qui correspond à time_range=month ; tout le reste est fixé dans votre code.

La fonction renvoie du texte brut, pas du JSON. Chaque source commence par un numéro, un titre et une URL, suivis de son Markdown. Cette disposition rend les citations comme [2] naturelles pour le modèle.

Si votre agent embarque déjà un outil nommé web_search, comme c'est le cas de Claude Code et OpenClaw, donnez au vôtre un autre nom, par exemple search_web. Deux outils portant le même nom perturbent le modèle.

Quand un agent doit-il rechercher, et à quelle fréquence ?

Recherchez lorsque la réponse dépend de faits qui changent ou que le modèle ne peut pas connaître. Les prix, les versions, les lois, les horaires et les événements récents en font partie. Les définitions et les connaissances stables, généralement non.

Écrivez cette règle dans le prompt système, et ajoutez un budget. Trois habitudes aident :

• Planifier avant de rechercher. Demandez au modèle d'écrire d'abord ses requêtes. Deux requêtes précises valent mieux que cinq vagues.
• Plafonner les appels. Autorisez, par exemple, quatre recherches par tour utilisateur. Ne relevez le plafond que pour les tâches de recherche approfondie.
• S'arrêter quand les sources concordent. Si trois pages indépendantes disent la même chose, l'agent peut répondre.

Comment garder la fenêtre de contexte sous contrôle ?

Trois paramètres décident de la quantité de texte qui atteint le modèle. read définit combien de pages sont lues, de 0 à 10. max_chars plafonne chaque page, de 500 à 50 000 caractères. max_results définit combien de résultats sont listés, de 1 à 20.

Pour un agent de chat, read=3 avec max_chars=4000 renvoie environ 12 000 caractères de texte de page par recherche. Cela laisse de la place pour plusieurs recherches dans une même conversation. Pour une tâche de recherche approfondie qui résume au fur et à mesure, des pages plus longues conviennent.

Le champ word_count vous indique la longueur de la page complète avant la coupe. L'agent peut s'en servir pour décider s'il doit récupérer davantage avec l'endpoint extract.

Que se passe-t-il quand une page ne peut pas être lue ?

Le résultat revient quand même, avec son titre, son URL et son snippet, mais sans contenu. Un champ content_status en indique la raison.

• blocked_by_robots : le robots.txt du site n'autorise pas notre lecteur.
• blocked_by_site_policy : Un site qui définit Content-Signal: ai-input=no dans son robots.txt garde ses pages hors du contenu de vos résultats.
• target_refused : le site a répondu par un refus ; son statut est dans target_status.
• fetch_failed ou fetch_timeout : la page ne s'est pas chargée à temps.

Quand un site refuse notre lecteur, le résultat revient sans contenu et avec le statut du site : nous ne résolvons jamais de CAPTCHA, ne nous connectons pas à des comptes et ne contournons ni un blocage ni un paywall. Dites à l'agent d'utiliser le snippet, ou une autre source, quand une page revient vide. La recherche elle-même coûte toujours un crédit, quel que soit le sort de chaque page.

Pourquoi ne pas utiliser l'outil de recherche intégré au modèle ?

Les outils intégrés sont pratiques mais vous laissent moins de contrôle. Au 22 octobre 2026, l'outil web_search d'OpenAI coûte 10 $ pour 1 000 appels, plus le contenu de recherche facturé comme tokens d'entrée. La recherche web de Claude chez Anthropic coûte aussi 10 $ pour 1 000 recherches, plus les coûts de tokens. Le grounding de Gemini 3 inclut 5 000 recherches gratuites par mois sur l'offre payante, puis coûte 14 $ pour 1 000.

Ces outils renvoient le plus souvent une réponse rédigée avec citations, et non les pages brutes. Ils lient aussi votre recherche à un seul fournisseur de modèle. Un outil autonome fonctionne avec n'importe quel modèle et vous laisse fixer la longueur de chaque page. Le comparatif des outils intégrés contient le tableau complet.

Combien coûte l'exploitation d'un agent sur LLMWebSearch ?

Un crédit par recherche quand read vaut 3 ou moins. Un assistant utilisé par une équipe, qui répond à 100 questions par jour avec 4 recherches chacune, effectue environ 12 000 recherches par mois. 25 000 requêtes à 41,25 $US couvre ce mois-ci et la majeure partie du suivant.

Un agent de code utilisé par un développeur peut rechercher 20 fois par jour, soit environ 600 fois par mois. 5 000 requêtes à 9,25 $US dure alors plusieurs mois, car les crédits n'expirent jamais. Le guide des coûts montre le calcul pour des volumes plus importants.