AWS donne à votre agent une réponse sourcée en un appel. Le lien confirme-t-il la réponse ?

Un client demande si sa version d’un logiciel reçoit encore des mises à jour de sécurité. Un agent d’assistance lui donne une réponse assurée et renvoie à la documentation de l’éditeur. Le lien s’ouvre et mène même au bon domaine. Seulement, la page décrit la dernière version alors que le client utilise la précédente.

Le 5 novembre 2026, AWS a rendu Web Answer généralement disponible sur Amazon Bedrock AgentCore, son infrastructure pour faire fonctionner et relier des agents IA. Ce nouveau connecteur géré peut chercher sur le web public, lire des pages et produire une réponse synthétique avec des citations en un seul appel d’outil. AWS le propose dans la région États-Unis Est (Virginie du Nord), ou us-east-1. Cela peut épargner du travail aux équipes qui construisaient ces étapes séparément. Elles obtiennent aussi un résultat concret à examiner avant de répondre au client. Lancement et guide AWS · Documentation AWS du connecteur

Les versions prises en charge, les dates de publication et les instructions modifiées sont de bons tests pour un tel outil. Chaque question a une réponse utile si la bonne source existe. Chacune permet aussi à la recherche de renvoyer une page pertinente qui appuie une autre affirmation. Voyons comment rendre visible le lien entre une réponse et son élément de preuve.

Bâtiments d’un centre de données AWS à Ashburn, en Virginie, photographiés en 2020. Photo de contexte régional de Vahurzpu, recadrée et redimensionnée, CC BY-SA 4.0. Source de l’image · Licence.

Un appel d’outil enchaîne plusieurs opérations

AWS propose deux connecteurs apparentés. Web Search Tool renvoie des résultats classés et des détails comme le titre, le lien, l’extrait et la date de publication. L’application appelante décide quels résultats examiner et comment en tirer une réponse. Web Answer reçoit une question en langage naturel, prépare ses propres recherches, lit les pages pertinentes et renvoie du texte avec des citations. La différence compte au moment de choisir les étapes que votre équipe veut gérer elle-même. Comparaison AWS entre Web Answer et Web Search

Lorsqu’un assistant doit résoudre une question factuelle au milieu d’un parcours plus long, la synthèse peut éviter une étape de coordination. Au lieu de passer vingt extraits à un modèle pour lui faire choisir les plus utiles, l’application peut demander une affirmation sourcée sur une version ou une politique précise. Si la personne chargée de vérifier doit comparer plusieurs articles, examiner l’étendue des résultats ou expliquer pourquoi une source passe avant une autre, la liste de recherche laisse davantage de décisions visibles. Les deux méthodes peuvent servir à des questions différentes au sein de la même application.

Deux façons d’utiliser la recherche dans un même parcours d’assistance. Avec Web Search, l’appelant prend en charge la lecture et la synthèse. Illustration originale de Telli.sh.

AgentCore Gateway expose le connecteur comme outil du Model Context Protocol. AWS documente un résultat qui contient du texte et une liste structurée de réponses. Chaque bloc peut comporter ses propres citations, avec une URL et, s’il est disponible, un domaine. En cas d’erreur de l’outil, la réponse porte l’indicateur isError. AWS impose aux applications qui utilisent des résultats Web Answer dans les contenus destinés aux utilisateurs finaux de conserver et d’afficher les citations et liens. Conservez le lien entre chaque bloc et sa citation à travers l’interface. Regrouper toutes les citations dans un pied de page sans distinction rend la vérification plus difficile, même si le texte paraît toujours sourcé. Format de réponse et règles d’utilisation AWS

Donnez à l’outil une question bien délimitée

Prenons un éditeur fictif, ExampleSync. Le client dit utiliser ExampleSync Server 4.2 en Allemagne avec l’offre d’assistance standard. Une bonne question demande si cette version et cette offre donnent encore droit aux mises à jour de sécurité à la date de la demande. Elle réclame la déclaration applicable sur le cycle de vie, l’URL de la source, sa date d’effet et un avertissement si les pages concernent un autre produit ou une autre édition. Le nom du client, son numéro de compte, sa clé de licence et ses échanges privés sont superflus.

Cette formulation sépare la décision d’assistance de la recherche de preuves. Une question comme « Puis-je dire à ce client qu’il bénéficie encore d’une assistance ? » peut amener le système à raisonner sur toute la relation commerciale. Une question sur le cycle de vie publié d’une version précise donne un point concret à vérifier. Si le calendrier public ne dit rien d’un contrat de maintenance privé, la réponse peut orienter la personne chargée du dossier vers le service qui gère ce contrat.

La documentation actuelle décrit des règles par domaine, des filtres de date de publication et une indication de pays à partir de la version 1.1.0. Un agent peut notamment inclure les domaines de documentation et d’assistance de l’éditeur. AWS décrit aussi des restrictions de domaine configurées sur la cible. La passerelle peut ainsi fixer ses limites sans dépendre de toutes les indications de la demande utilisateur. Le pays affine les résultats. Lorsque la géographie détermine la réponse, le résultat doit encore identifier le bon territoire ou contrat. Configuration des filtres et schéma d’entrée AWS

Une liste étroite de domaines peut éviter les republications et laisser des lacunes si l’éditeur répartit ses contenus entre plusieurs sites. Un filtre de publication trop strict peut écarter un document de cycle de vie vieux de deux ans qui fait toujours autorité. À l’inverse, une page récente peut annoncer une date encore à venir. Distinguez la date de publication, la date d’effet indiquée et la date de votre consultation. Si les résultats se contredisent, gardez les sources en désaccord et donnez à une personne le moyen de décider laquelle s’applique.

Suivez la citation jusqu’à la phrase qui compte

Dans un dossier d’assistance, la citation indique où chercher la preuve. Commencez par ouvrir la page liée à l’affirmation déterminante. Vérifiez que le titre et la langue conviennent, puis repérez le passage. Vérifiez le produit, la version, l’édition et la région. Si la réponse cite une date, lisez la ligne ou la cellule du tableau qui la donne. Une explication générale correcte d’une politique de fin d’assistance ne suffit pas à dater la fin d’assistance d’une version précise.

Avant de décider comment utiliser la réponse, la personne chargée de la vérifier examine le passage et son périmètre. Illustration originale de Telli.sh.

Supposons que le résultat affirme que la version 4.2 reçoit des mises à jour de sécurité jusqu’en décembre. La source est une page du cycle de vie de l’éditeur dont le tableau distingue l’assistance standard et l’assistance étendue. La première prend fin en septembre et la seconde en décembre. La vérification doit faire ressortir l’écart même si le lien fonctionne et que la date citée figure bien sur la page. Une interface robuste laisse la citation attachée à l’affirmation contestée et permet de signaler l’offre incorrecte.

Parfois, la question omet une distinction. Si l’utilisateur n’a pas indiqué l’édition, le meilleur pas suivant peut être une demande de précision. Parfois, les preuves sont incomplètes. Une présentation générale du produit peut omettre la version à laquelle s’applique une fonction, ou une note peut évoquer un déploiement de préproduction sans indiquer de disponibilité générale. Une interface utile indique ce qu’elle a trouvé et les points encore ouverts sans demander à l’utilisateur d’interpréter une série de liens inexpliqués.

Refaites l’exercice sur une question dont la bonne réponse consiste à exprimer l’incertitude. Demandez par exemple le statut d’une version absente du calendrier public. Le résultat attendu explique clairement que la documentation publique ne permet pas d’établir un statut et propose une prochaine étape utile. Ce test mesure la capacité de répondre et celle de reconnaître les cas où il vaut mieux retenir une réponse.

Rendez la première intégration facile à évaluer

1. Utilisez une passerelle de test dans la région documentée. Suivez le guide AWS pour rattacher Web Answer et accorder au rôle de service de la passerelle la permission d’appeler le connecteur. Accordez à l’appelant la permission distincte d’invoquer la passerelle, selon les besoins du test. Utilisez un compte de test ou un environnement isolé déjà autorisé à émettre des requêtes facturables. Guide de configuration AWS
2. Préparez quelques questions avant d’affiner les consignes. Incluez une réponse actuelle, un document pertinent mais ancien, un cas lié à une offre, des sources concurrentes et un cas avec trop peu de preuves publiques. Notez ce qu’une bonne réponse doit faire dans chaque cas.
3. Commencez par des questions de test et des documents publics. Appliquez des limites de domaine et de date lorsqu’elles ont un objectif précis. Inspectez les blocs structurés, conservez leurs liens dans l’affichage et permettez de comparer le texte à la page originale.
4. Comparez avec le parcours manuel ou avec le connecteur de résultats classés. Relevez les affirmations correctement étayées, les réponses retenues à juste titre et les dossiers qu’il a fallu rouvrir. Si possible, mesurez depuis la demande jusqu’à la validation finale pour inclure la vérification humaine.
5. Prévoyez un recours en cas d’erreur de l’outil, d’absence de source ou de délai dépassé. Laissez l’équipe d’assistance ouvrir la documentation officielle ou transmettre le dossier à un collègue. Enregistrez un motif précis pour le diagnostic et respectez les règles d’accès et de conservation du dossier d’origine.

Le guide AWS du 5 novembre affiche 10 dollars américains pour 1 000 appels Web Answer. À ce tarif indicatif, 100 appels représentent un poste de 1 dollar et 250 appels de 2,50 dollars pour Web Answer. L’usage de la passerelle, le modèle de l’agent appelant et les appels répétés se considèrent séparément. Dans l’assistance, l’unité de comparaison utile est la réponse vérifiée et exploitable. Une réponse courte qui demande trois révisions et plusieurs minutes de vérification peut coûter plus cher qu’une réponse plus lente validée du premier coup. Tarifs indiqués dans le guide AWS

Suivez ce délai et le motif d’échec le plus courant avant d’élargir l’usage. Si la plupart des erreurs viennent de mauvaises éditions, ajoutez un champ distinct au formulaire. Si le problème tient à des pages anciennes, repérez la politique de référence de l’éditeur et le mode de publication des mises à jour. Si les sources utiles se trouvent souvent hors de la liste autorisée, révisez la politique de la passerelle avec la personne responsable de l’assistance. Chaque changement répond à une cause différente.

Comparez séparément les questions simples et les cas litigieux. Si dix-neuf demandes courantes sont validées immédiatement et que la vingtième combine deux politiques régionales contradictoires, une seule moyenne masquera le travail de vérification restant. Notez le motif et la durée de chaque examen. Rejouez les mêmes cas après avoir modifié le connecteur. Vous pourrez voir si la nouvelle politique rend davantage de réponses exploitables tout en transmettant les cas incertains à la bonne personne.

Le gain concret se situe entre une question bien posée et un ensemble de preuves qu’une personne peut examiner. AWS fournit la recherche et la synthèse en une requête. L’équipe d’assistance y gagne en précisant quels éléments font preuve et en donnant aux collègues le moyen de les ouvrir.

Sources

• Annonce AWS de disponibilité générale le 5 novembre 2026
• Guide et démonstration publique AWS Web Answer du 5 novembre 2026
• AWS Web Answer, connecteur, filtres, schéma de réponse et règles d’utilisation
• Connecteur AWS Web Search Tool
• Photo de contexte de Vahurzpu, CC BY-SA 4.0

---

Pour retrouver les questions, les vérifications de sources et les décisions prises au cours des échanges d’assistance, créez un compte Telli.sh.