Claude Desktop Web Search obtient des réponses à jour, mais AWS contrôle le parcours

La recherche web de Claude Desktop a bénéficié d’un parcours contrôlé par AWS le 2 octobre, comblant une lacune de connaissances sans faire transiter les requêtes par une API de recherche distincte. AWS a publié une architecture de référence qui relie Claude Desktop sur Amazon Bedrock à l’outil Web Search géré dans Amazon Bedrock AgentCore. Le modèle peut récupérer des informations actuelles tout en permettant à une entreprise de conserver l’authentification, l’autorisation et l’infrastructure de recherche dans son environnement AWS existant.

Cette combinaison est importante, car Claude Desktop sur Bedrock n’hérite pas automatiquement de toutes les fonctionnalités proposées par les services grand public d’Anthropic. Sans outil de recherche associé, ses réponses restent limitées par la date d’arrêt de l’entraînement du modèle sous-jacent et par le contexte fourni par les utilisateurs. Les questions portant sur une documentation récente, des détails de produits évolutifs ou l’actualité peuvent donc produire des réponses obsolètes.

L’enjeu de fond n’oppose pas Claude à un autre chatbot. Il met en concurrence un parcours de recherche géré par AWS et lié à l’identité avec la pratique courante consistant à connecter une API de recherche externe ou un service de récupération personnalisé. AWS élimine plusieurs tâches d’intégration, mais introduit aussi une chaîne d’identité à plusieurs étapes ainsi que des questions importantes sur les frontières réseau, les autorisations, la journalisation et la responsabilité opérationnelle.

Claude Desktop Web Search dispose désormais d’un parcours géré par AWS

AWS a transformé l’accès au web, d’un module externe, en une cible AgentCore gérée que Claude Desktop peut découvrir via MCP.

AWS a publié l’architecture de référence sous la forme d’un guide technique plutôt que d’une nouvelle version du modèle Claude. Son changement central est architectural. Claude Desktop peut se connecter à une AgentCore Gateway qui expose AWS Web Search comme outil Model Context Protocol.

MCP est un protocole ouvert qui permet aux applications d’IA de découvrir et d’invoquer des outils externes via une interface standard. Dans cette configuration, la gateway présente une liste d’outils à Claude Desktop. Claude peut ensuite demander une recherche lorsqu’un prompt dépend d’informations que le modèle ne possède pas déjà.

Le service de recherche n’est pas une simple surcouche d’une API tierce gérée par l’utilisateur. Selon AWS, il s’appuie sur un index exploité par Amazon qui couvre des dizaines de milliards de documents. Le service géré renvoie des titres, des URL, des extraits et des dates de publication, tout en extrayant des passages adaptés à la fenêtre de contexte d’un modèle.

AWS indique également que l’index est continuellement mis à jour, les contenus nouveaux ou modifiés étant reflétés en quelques minutes. Cette affirmation est importante pour les questions sensibles au temps, même si la fraîcheur des résultats variera toujours selon la page, l’accessibilité au crawl et le comportement de l’éditeur. Un document public fréquemment actualisé pose un défi de récupération différent de celui d’une page obscure dissimulée derrière des scripts complexes.

La documentation Web Search plus générale décrit des contrôles de domaine et des filtres de date en complément de l’index géré. Les administrateurs de cibles peuvent exclure certains domaines. Les versions plus récentes du connecteur prennent également en charge des règles d’inclusion de domaines et des bornes de dates de publication au niveau de la requête.

Ces contrôles créent une surface de politique autour de la recherche, et pas seulement un accès au web ouvert. Une organisation pourrait limiter un assistant à des domaines de documentation approuvés ou exclure des sources qui ne répondent pas aux exigences internes de confiance. Elle pourrait également restreindre une requête aux contenus publiés durant une période définie.

Le guide identifie trois régions AWS prises en charge pour cette intégration particulière : US East en Virginie du Nord, Europe en Irlande et Asie-Pacifique à Tokyo. Les entreprises devraient vérifier la disponibilité actuelle avant de considérer ces emplacements comme des limites permanentes. La couverture des services AWS peut s’étendre indépendamment d’un ancien tutoriel.

Le résultat pratique est simple. Claude Desktop peut aller au-delà des connaissances statiques du modèle sans obliger les développeurs à construire un crawler, normaliser les résultats de recherche ou gérer les identifiants d’un autre fournisseur de recherche. Cela ne rend pas chaque fait renvoyé exact. Cela donne au modèle un mécanisme gouverné pour trouver des éléments de preuve plus récents.

La date d’arrêt des connaissances était en réalité un problème de gouvernance

La capacité manquante n’était pas simplement la recherche. Les entreprises avaient besoin d’informations actuelles sans créer un nouveau parcours de données non géré.

La date d’arrêt des connaissances d’un modèle devient visible lorsque les utilisateurs interrogent les récentes versions logicielles, la documentation cloud mise à jour, de nouvelles réglementations ou des conditions opérationnelles changeantes. Le modèle peut raisonner à partir des éléments fournis, mais il ne peut pas récupérer des faits manquants à moins que l’application ne lui fournisse un outil approprié.

Les produits d’IA grand public masquent souvent cette distinction derrière un bouton de recherche. Les déploiements d’entreprise ne le peuvent pas. Les équipes de sécurité doivent savoir quel service reçoit une requête, où résident les identifiants, quel utilisateur a initié la demande et quelles autorisations régissent l’action.

Cela fait de la recherche web de Claude Desktop une décision d’identité et d’infrastructure. Une équipe peut connecter un service de recherche externe, exploiter sa propre couche de récupération ou utiliser un service géré dans son environnement cloud. Chaque choix modifie le nombre de fournisseurs, d’identifiants, de journaux et de points de défaillance impliqués.

AWS positionne AgentCore Gateway comme point de contrôle. Une gateway est un intermédiaire qui présente des outils à un client d’IA tout en appliquant des règles d’authentification et d’accès aux cibles. Elle permet à Claude Desktop d’invoquer la recherche sans placer une clé d’API de recherche dans la configuration du bureau.

La gateway sépare également le flux d’identité côté client de l’autorisation utilisée pour appeler la cible gérée. Claude Desktop présente à la gateway un jeton associé à l’utilisateur. La gateway invoque ensuite Web Search via un rôle de service AWS disposant de l’autorisation requise.

Cette distinction limite l’exposition directe des identifiants de backend. Elle donne également aux administrateurs un point d’inspection des accès et d’application des politiques. Toutefois, elle ne détermine pas automatiquement si chaque requête est appropriée ou si chaque utilisateur devrait disposer de capacités de recherche identiques.

Cette conception convient aux organisations qui s’appuient déjà sur AWS IAM Identity Center pour l’accès de leurs collaborateurs. Elles peuvent attribuer l’application à des utilisateurs ou groupes approuvés plutôt que de créer un répertoire d’identité distinct. Les processus existants de départ des employés et de revue des accès peuvent alors couvrir la connexion de recherche.

C’est la principale pression créée par l’architecture. Les équipes qui utilisent des API de recherche externes doivent justifier un nouveau magasin d’identifiants et un nouveau processeur pour les requêtes utilisateurs. Les équipes qui exploitent des piles de récupération personnalisées doivent justifier leur charge d’ingénierie et de supervision. AWS propose un parcours qui consolide ces préoccupations, mais seulement aux organisations prêtes à accepter sa frontière cloud et son modèle de configuration.

Cette évolution affecte également les flux de travail liés aux connaissances. La recherche fournit des informations publiques actuelles, tandis que des systèmes tels que le knowledge blending peuvent relier les résultats publics au contexte interne conservé par un utilisateur. La distinction utile consiste à séparer la récupération de ce qui a changé hors de l’organisation du rappel de ce que l’organisation sait déjà.

AgentCore remplace une clé d’API par une chaîne d’identité

Le mécanisme central remplace un identifiant partagé peu contraint par une séquence traçable d’authentification utilisateur, d’émission de jetons, de validation par la gateway et de recherche autorisée par AWS.

Le flux commence avec AWS IAM Identity Center, qui authentifie l’employé via le processus d’authentification unique de l’organisation. Dans la conception publiée, Identity Center agit comme fournisseur d’identité SAML. SAML est une norme de transfert d’assertions d’authentification entre un fournisseur d’identité et une application.

Amazon Cognito se place entre cette connexion SAML et AgentCore Gateway. Cognito fédère l’utilisateur Identity Center, exécute un flux OAuth 2.0 d’autorisation par code et émet un JSON Web Token. Un JWT est un jeton signé contenant des revendications qu’un service destinataire peut valider.

Claude Desktop lance le flux d’autorisation via un ID client et un secret client configurés. Le rappel revient vers une adresse localhost sur le port 53280. Après la connexion de l’utilisateur, Claude Desktop reçoit le jeton nécessaire pour atteindre la gateway.

AgentCore Gateway valide ce jeton à chaque requête. Elle vérifie les informations de découverte OpenID Connect configurées et l’identifiant client autorisé avant d’accepter l’appel. Le guide d’autorisation entrante d’AWS prend également en charge les audiences, les scopes et les revendications personnalisées obligatoires pour une validation plus fine.

Cette granularité est importante. Une identité organisationnelle valide n’implique pas nécessairement l’autorisation d’utiliser chaque outil d’IA. Les administrateurs peuvent restreindre l’accès par les groupes attribués, les restrictions de client, les scopes ou les revendications, selon la conception d’identité.

Après l’authentification, la gateway expose le connecteur Web Search géré via MCP. Claude Desktop utilise l’opération tools/list du protocole pour découvrir l’outil disponible. Lorsque Claude détermine qu’un prompt exige des informations actuelles, il appelle l’outil via la gateway.

Le guide configure le rôle d’exécution de la gateway avec l’autorisation d’invoquer la ressource AWS Web Search. Il s’agit d’une autorisation sortante : la gateway s’authentifie auprès de la cible après avoir validé la requête utilisateur entrante. Les utilisateurs ne reçoivent pas les identifiants du rôle AWS sous-jacent.

AWS documente plusieurs autres modèles d’autorisation dans ses concepts de gateway, notamment l’accès entrant basé sur IAM et l’autorisation déléguée. Le modèle Claude Desktop utilise une autorisation JWT personnalisée, car le client de bureau nécessite un flux utilisateur compatible avec OAuth plutôt qu’une signature directe des requêtes AWS.

Le résultat est plus structuré que l’ajout d’une clé de recherche partagée dans un fichier de configuration. Chaque requête entre via un client authentifié et atteint une cible autorisée par un rôle AWS. L’organisation peut modifier l’un ou l’autre côté sans reconcevoir l’interface entière.

Cette structure crée également davantage de composants. Identity Center doit contenir les bons utilisateurs et groupes. Son application SAML doit mapper correctement les attributs. Cognito nécessite un user pool, un fournisseur d’identité, un client d’application, un domaine, une adresse de rappel et une configuration OAuth. AgentCore nécessite une gateway, un autorisateur, un rôle, une politique et une cible de connecteur.

Une erreur de configuration à n’importe quel endroit de cette chaîne peut apparaître à l’utilisateur comme un échec générique de recherche. Un jeton expiré, une audience incorrecte, un rappel non concordant, un client non valide, une autorisation de gateway manquante ou une cible indisponible peuvent tous interrompre la même action visible.

C’est pourquoi la recherche web Claude sécurisée n’est pas une fonctionnalité à cocher en une seule case dans le modèle AWS. La valeur provient d’un contrôle explicite, et ce contrôle explicite implique du travail opérationnel. Les entreprises bénéficient de frontières plus claires au prix de la gestion des relations d’identité entre ces frontières.

La recherche gérée met sous pression les piles de récupération sur mesure

L’argument le plus fort d’AgentCore n’est pas qu’Amazon a inventé la recherche web, mais qu’un endpoint MCP géré peut éliminer plusieurs couches d’intégration à la fois.

Une mise en œuvre classique commence souvent par une API de recherche externe. Les développeurs provisionnent des identifiants, créent un wrapper, définissent un schéma d’outil, analysent les réponses, sélectionnent les passages utiles et exposent le résultat à un client d’IA. Ils doivent également gérer les quotas, les erreurs, la télémétrie et les formats de réponse propres à chaque fournisseur.

Un index personnalisé ajoute encore davantage de responsabilités. Les équipes doivent assurer l’exploration, le stockage, le classement, les contrôles de fraîcheur, l’extraction de contenu et les défenses contre les pages hostiles. Elles doivent décider comment respecter les restrictions des sites et comment retirer les documents obsolètes ou de faible qualité.

AgentCore concentre une grande partie de ce travail dans une cible gérée. AWS exploite le service d’indexation et de récupération. Gateway présente la cible via MCP, tandis que le rôle de service gère les accès sortants. Claude Desktop fournit l’expérience client et invoque l’outil lorsque nécessaire.

Cette configuration met sous pression trois alternatives.

Premièrement, les API de recherche tierces doivent rivaliser sur la couverture, la qualité du classement, les contenus spécialisés et la portabilité. Leur configuration plus simple peut rester attrayante, en particulier pour les équipes hors de l’écosystème AWS. Toutefois, un fournisseur supplémentaire crée une relation additionnelle de traitement des données et une nouvelle frontière d’identifiants.

Deuxièmement, les systèmes de recherche auto-hébergés doivent démontrer que leur personnalisation justifie leur maintenance. Un corpus spécialisé, une source de données privée ou un modèle de classement propre à un domaine peuvent rendre la récupération personnalisée pertinente. Les requêtes générales sur le Web public constituent un argument moins convaincant pour reconstruire une infrastructure devenue standard.

Troisièmement, les fonctions de recherche natives des applications d’IA doivent satisfaire aux exigences de gouvernance d’entreprise. Un simple commutateur de recherche pratique destiné aux consommateurs ne répond pas aux questions d’identité organisationnelle, de sélection de région, d’attribution des accès ou d’auditabilité au niveau du cloud.

Les conseils d’Anthropic sur les connecteurs ajoutent un détail réseau important. Les connexions MCP distantes proviennent de l’infrastructure cloud d’Anthropic, et non directement de l’ordinateur de l’utilisateur. Un serveur distant doit donc accepter le trafic provenant des plages réseau Anthropic concernées.

Ce détail complique les affirmations simplistes selon lesquelles l’intégralité de l’interaction resterait dans un réseau privé unique. La cible de recherche AWS et l’index peuvent demeurer au sein de l’infrastructure AWS, tandis que la connexion entre le client et la passerelle traverse toujours le service d’Anthropic vers un point de terminaison AWS. Les entreprises doivent définir précisément quel segment elles désignent lorsqu’elles évoquent une frontière AWS.

Les serveurs MCP locaux fonctionnent différemment, car Claude Desktop les atteint depuis la machine locale. Toutefois, un processus local ne fournirait pas la même passerelle distante gérée de manière centralisée que celle décrite par AWS. Le choix porte sur la portée du déploiement, le contrôle centralisé et l’exposition réseau, plutôt que sur un classement universel de la sécurité.

L’avantage d’AgentCore est le plus fort pour les organisations déjà engagées dans les opérations et la gestion des identités AWS. Elles peuvent réutiliser leurs structures de comptes, leurs rôles, leurs pratiques de supervision et leur gouvernance administrative. Une entreprise disposant d’une autre plateforme d’identité peut tout de même appliquer ce modèle, car AWS indique que Cognito peut se fédérer avec des fournisseurs compatibles SAML ou OIDC.

Pour une équipe plus petite, cette même architecture peut sembler excessive. Un pool d’utilisateurs, un pont de fédération, un client d’application, un rôle de passerelle et une politique réseau créent une surcharge avant même que la première recherche ne réussisse. Le service de recherche géré supprime l’infrastructure de récupération, mais il ne supprime pas l’architecture d’identité d’entreprise.

C’est là que se situe la ligne de partage concurrentielle. AgentCore favorise les organisations qui accordent plus de valeur à la cohérence des politiques qu’au temps minimal de configuration. Les API externes et les connecteurs plus simples conservent une place lorsque la portabilité et le déploiement rapide comptent davantage qu’un plan de contrôle AWS unifié.

La recherche Web sécurisée dans Claude nécessite toujours un modèle de menaces

La validation des JWT et la récupération gérée par AWS réduisent certains risques, mais elles ne rendent pas le contenu Web digne de confiance et n’éliminent pas les modes de défaillance administratifs.

La première incertitude concerne l’expression « toutes les requêtes restent dans votre frontière AWS ». AWS indique que le trafic de recherche reste sur son infrastructure et ne nécessite pas de clés de recherche tierces. Il s’agit d’une réduction significative de l’exposition aux fournisseurs au niveau de la couche de recherche.

Toutefois, Claude Desktop reste le client initiateur. Pour les connecteurs MCP distants, Anthropic indique que son infrastructure cloud se connecte au serveur distant. Les évaluateurs de sécurité devraient cartographier l’intégralité du parcours de la requête, y compris le service Claude, le point de terminaison public de la passerelle, la Région AWS, la cible Web Search, les systèmes de journalisation et le contenu renvoyé.

La deuxième incertitude concerne la conception des jetons. AgentCore valide les JWT, mais la protection dépend des revendications configurées. Un enregistrement client trop étendu ou une attribution de groupes insuffisamment rigoureuse peut accorder davantage d’accès que prévu. Un jeton valide prouve qu’une identité et un ensemble de revendications sont acceptés, et non que chaque requête est judicieuse.

La documentation AWS indique que certaines revendications JWT peuvent apparaître dans les enregistrements CloudTrail. Elle recommande d’éviter les informations permettant d’identifier une personne dans le champ sujet et suggère des identifiants opaques. Cet avertissement mérite attention, car l’auditabilité peut devenir un problème de confidentialité lorsque les revendications d’identité contiennent des données personnelles inutiles.

La troisième incertitude porte sur la profondeur de l’autorisation. Le guide attribue des utilisateurs ou des groupes à l’application Identity Center et limite la passerelle à un client autorisé. Les entreprises peuvent nécessiter des contrôles supplémentaires pour les services, les classifications de données, les domaines approuvés ou les catégories de requêtes sensibles.

Une liste d’autorisation de domaines peut réduire l’exposition aux sources non fiables, mais elle ne peut garantir l’exactitude factuelle. Des sites Web approuvés peuvent publier des informations obsolètes, compromises ou incorrectes. Les résultats de recherche doivent rester des éléments de preuve pour le raisonnement du modèle, et non une vérité incontestée.

L’injection de prompt constitue une autre préoccupation. Une page récupérée peut contenir du texte destiné à influencer un agent d’IA, y compris des instructions en conflit avec l’objectif de l’utilisateur. L’extraction sémantique élimine certains éléments de page non pertinents, mais elle n’établit pas que chaque passage extrait est sûr.

Le risque dépend de ce que Claude peut faire après une recherche. Un assistant de recherche en lecture seule a un impact plus limité qu’un agent capable d’envoyer des messages, de modifier des enregistrements ou d’invoquer des outils administratifs. Les organisations devraient évaluer les autorisations combinées des outils plutôt que d’approuver Web Search de manière isolée.

Les boîtes de dialogue d’approbation des outils offrent une protection au niveau de l’utilisateur. Le guide AWS montre Claude présentant la requête proposée avec des options pour la refuser, l’autoriser une fois ou l’autoriser pour la tâche en cours. Cette visibilité peut aider les utilisateurs à repérer des recherches inattendues.

L’approbation n’est pas un système de politique complet. Les utilisateurs peuvent approuver des requêtes nuisibles sans en reconnaître le risque, et des sollicitations fréquentes peuvent entraîner une acceptation habituelle. Des restrictions centralisées, des périmètres limités et une composition soigneuse des outils restent nécessaires.

La quatrième incertitude concerne l’observabilité. Les équipes doivent savoir si elles peuvent reconstituer quel utilisateur a lancé une recherche, quelle requête a atteint la cible, quels résultats ont été renvoyés et quelle réponse les a intégrés. Elles ont également besoin de politiques de rétention qui évitent de collecter davantage de données sensibles que nécessaire.

La cinquième incertitude est la disponibilité. L’expérience utilisateur dépend d’Identity Center, Cognito, AgentCore Gateway, Web Search, du service de connecteurs de Claude et de la connectivité régionale. Une défaillance de l’un de ces composants peut supprimer l’accès aux informations actuelles tandis que le modèle de base continue de répondre à partir de connaissances plus anciennes.

Cela crée un risque produit subtil. Les utilisateurs ne distinguent pas toujours une réponse récente, étayée par une recherche, d’une réponse produite sans recherche réussie. Les interfaces et la supervision opérationnelle devraient rendre les défaillances des outils visibles au lieu de se dégrader silencieusement vers des réponses obsolètes.

L’architecture d’AWS constitue donc un point de départ en matière de sécurité, et non un modèle de menaces achevé. Elle réduit la prolifération des identifiants et place la cible de recherche sous les contrôles AWS. Les organisations doivent encore définir les frontières de données, les règles d’accès, les pratiques de journalisation, le comportement en cas de défaillance et les protections contre les contenus récupérés hostiles.

Trois signaux montreront si l’architecture tient ses promesses

Le prochain test est l’adoption opérationnelle, et non la capacité de la démonstration à renvoyer une réponse actuelle.

Le premier signal sera la manière dont les entreprises restreignent les autorisations au-delà de la simple attribution à une application. Les déploiements robustes utiliseront des clients à périmètre limité, des revendications restreintes, des groupes attribués avec soin et des autorisations de passerelle limitées. Les déploiements faibles considéreront tout employé authentifié comme également autorisé à utiliser la même capacité de recherche.

Si AWS publie davantage de modèles de production autour des revendications de groupe, des rôles de moindre privilège et des politiques au niveau des requêtes, la voie gérée deviendra plus facile à défendre. Si les clients doivent inventer ces contrôles de manière indépendante, le travail de sécurité sur mesure restera une part importante de l’adoption.

Le deuxième signal sera la manière dont AWS et Anthropic clarifient la frontière réseau de bout en bout. L’index de recherche, le traitement des résultats et l’invocation de la cible peuvent rester au sein d’AWS, mais la requête MCP distante commence dans le cloud d’Anthropic. Les acheteurs d’entreprise voudront une documentation précise sur les points de terminaison, les plages réseau autorisées, le comportement régional, la télémétrie et le traitement du contenu.

Une documentation plus claire sur les frontières renforcerait l’affirmation d’AWS selon laquelle ce modèle évite une exposition inutile aux recherches tierces. Une formulation ambiguë l’affaiblirait, surtout pour les acheteurs réglementés qui doivent documenter chaque sous-traitant et chaque saut réseau.

Le troisième signal sera la qualité de la récupération dans des charges de travail réelles. Un index couvrant des dizaines de milliards de documents paraît vaste, mais les utilisateurs jugeront la fraîcheur, la pertinence, la qualité des citations, la latence et la cohérence. Les filtres de domaine et les contrôles de date de publication doivent fonctionner de manière prévisible lorsque les équipes recherchent de la documentation, des réglementations, des mises à jour de produits ou des actualités évoluant rapidement.

Ce signal déterminera si la recherche gérée remplace les fournisseurs externes ou les rejoint simplement. Les entreprises conservent souvent plusieurs voies de récupération lorsqu’un service fonctionne bien pour les requêtes générales, mais mal pour les sources spécialisées.

L’architecture sera également soumise à un test d’utilisabilité. Les administrateurs doivent finaliser la fédération ainsi que la configuration des jetons, de la passerelle, des rôles et des connecteurs. Les utilisateurs doivent s’authentifier et comprendre les approbations d’outils. Les équipes de support doivent diagnostiquer les défaillances sur plusieurs services sans transformer chaque incident en enquête sur l’identité cloud.

Pour les développeurs, la valeur immédiate est une interface MCP standard soutenue par un index géré. Pour les acheteurs d’entreprise, la valeur consiste à centraliser les contrôles d’identité et de recherche dans AWS. Pour les travailleurs du savoir, la valeur est un accès plus simple à des informations publiques actuelles depuis la même interface Claude Desktop.

Aucun de ces avantages ne supprime la nécessité de vérifier les réponses importantes. L’ancrage par la recherche améliore l’accès à des éléments de preuve récents, mais il ne transforme pas le Web en base de données fiable. Les utilisateurs devraient examiner les sources citées, comparer les affirmations contradictoires et reconnaître lorsqu’un résultat dépend d’une page susceptible d’évoluer.

La question décisive est de savoir si une organisation a suffisamment besoin de réponses actuelles pour exploiter la chaîne d’identité de manière responsable. Les équipes utilisant déjà Bedrock et IAM Identity Center ont une raison crédible de tester la recherche Web dans Claude Desktop. Elles devraient commencer avec un groupe d’utilisateurs restreint, des autorisations limitées, des domaines explicites, des défaillances observables et des flux de travail en lecture seule avant d’ajouter des outils à plus fort impact.