AWS ouvre une API Web Search pour les agents : un seul appel, sans passerelle ni clés

Le modèle ne sait pas ce qui s'est passé la semaine dernière. Pour qu'un agent puisse répondre sur les versions récentes, les prix ou les lois, il lui faut une recherche. AWS en proposait déjà une, mais uniquement via AgentCore Gateway : on crée une passerelle, on ajoute une cible de recherche web et on appelle l'outil depuis un client MCP. Pour une équipe plateforme qui applique des règles communes, c'est acceptable. Pour un développeur qui veut simplement des résultats de recherche, c'est une couche superflue.

AWS vient de publier une API Web Search autonome. Il s'agit de l'opération InvokeWebSearch dans le data plane du service bedrock-agentcore. Rien à créer au préalable : vous prenez vos identifiants IAM, vous appelez, vous obtenez les résultats.

À quoi cela ressemble en pratique

Dans Boto3, il s'agit d'une seule méthode, invoke_web_search. Vous lui passez la chaîne de requête (jusqu'à 200 caractères), le nombre de résultats de 1 à 25 et des filtres. Par exemple, vous pouvez limiter la recherche aux domaines aws.amazon.com et kubernetes.io et demander les pages publiées après le 1er janvier 2026. La réponse est une liste classée. Chaque résultat contient un extrait de texte ; le titre, l'URL et la date de publication sont présents si l'index les connaît. Il faut donc les lire avec get, et non par clé.

L'authentification passe par SigV4, donc sans clé d'API. Si le code tourne dans Lambda, ECS, EC2 ou EKS, il suffit d'ajouter au rôle une seule permission : bedrock-agentcore:InvokeWebSearch sur la ressource managée web-search.v1. C'est la même permission que celle utilisée par le rôle de service de la passerelle : une seule politique couvre donc les deux chemins.

On peut aussi tester sans code : dans CloudShell, une seule commande suffit, aws bedrock-agentcore invoke-web-search. Pour Python, il faut Boto3 version 1.43.127 ou plus récente.

Dans quels cas c'est utile

AWS cite plusieurs scénarios où la passerelle est superflue :

• votre propre boucle d'agent ou des frameworks comme LangChain et LlamaIndex ;
• des tâches non agentiques : tableaux de bord, vérification des faits, enrichissement de contenu, veille ;
• les cas où vous voulez gérer vous-même les nouvelles tentatives, le cache et la gestion des erreurs ;
• les applications qui disposent déjà de leur propre couche d'API.

Pour LangChain, un toolkit prêt à l'emploi existe dans langchain-aws 1.9.3 et versions ultérieures. Il permet de figer des règles que le modèle ne peut pas modifier : domaines exclus, borne inférieure de date et budget de recherche. C'est utile quand on ne veut pas que l'agent élargisse lui-même son périmètre de recherche. Il existe aussi un wrapper WebSearchClient dans l'AgentCore Python SDK 1.26.0.

Sécurité et limites

L'argument principal pour les équipes en entreprise est que les requêtes sont servies par un index géré par Amazon et ne partent pas vers un moteur de recherche tiers. Le même index alimente Alexa+, Kiro et Quick. L'accès se règle via IAM et les SCP, et les appels peuvent passer par PrivateLink sans sortie sur Internet. Avec la condition aws:SourceVpce, on peut n'autoriser la recherche que depuis son propre VPC.

Quelques nuances :

• CloudTrail enregistre les appels comme des data events, mais ils sont désactivés par défaut. Il faut ajouter manuellement un sélecteur pour la ressource AWS::BedrockAgentCore::WebSearch. Le texte de la requête et les filtres n'apparaissent pas dans les logs.
• La limite par défaut est de 10 requêtes par seconde, par région et par compte. Pour les pipelines massifs, il faudra demander une augmentation.
• Les conditions d'utilisation obligent à conserver et à afficher les liens vers les sources avec les résultats. Si votre produit masque les sources, c'est un problème.
• Les endpoints VPC d'interface sont facturés aux tarifs standard de PrivateLink.
• L'index appartient à Amazon : il convient donc de vérifier la couverture et la fraîcheur sur vos propres requêtes avant d'abandonner Brave, Tavily ou Bing.

Que faire

Si vous êtes déjà sur AWS et voulez ajouter du web grounding à un agent, commencez par l'API directe : cinq minutes suffisent, sans déployer de passerelle. Si vous avez beaucoup d'agents et une politique d'outils commune, la passerelle reste pertinente. Pour comparer avec d'autres API de recherche, exécutez le même jeu de requêtes sur les deux, et en production, activez tout de suite les data events CloudTrail et limitez les domaines dans le toolkit.