OUTILS IA — L'AGENT QUI AGIT · RECONNAÎTRE UN AGENT À SA PORTE
Sources relevées au 25 juillet 2026, sur la documentation officielle des éditeurs de robots et d'infrastructure citée, et sur les brouillons de normalisation référencés. Aucune configuration n'a été déployée pour cet article.
Pendant trente ans, la question posée à l'entrée d'un site tenait en un mot : humain ou robot ? Le fichier robots.txt réglait le second cas, l'analyse d'audience comptait le premier, et cette partition suffisait. Elle ne suffit plus, parce qu'un troisième visiteur est apparu : le logiciel qui agit pour le compte d'une personne, en direct, pendant qu'elle attend la réponse.
Ce visiteur n'est pas un robot d'indexation. Il n'est pas non plus un navigateur. Et le plus gênant est qu'il n'est pas soumis aux mêmes règles — ce n'est pas une supposition, c'est écrit dans la documentation des éditeurs.
Cet article regarde depuis le comptoir la scène que notre article sur le contrôle de ce que les robots d'IA prennent sur votre site observait depuis la porte de service. Il ne s'agit plus de savoir ce que l'on vous copie, mais de décider ce que vous ouvrez à un logiciel qui vient consulter, comparer, parfois acheter.
Trois trafics que l'on confond, trois décisions distinctes
La documentation d'un opérateur d'infrastructure classe aujourd'hui les robots selon le comportement observé, et non selon leur éditeur. Trois catégories intéressent directement un exploitant de site.
La catégorie Search couvre le parcours destiné à « construire des index de recherche ou des bases de récupération augmentée ». La catégorie Training couvre le parcours destiné à « entraîner ou spécialiser des modèles ». La catégorie Agent, la plus récente, désigne les « agents dirigés par l'utilisateur qui visitent une page pour le compte d'un humain ». Neuf autres catégories complètent la liste, dont une consacrée aux robots qui transigent.
Cette taxonomie n'est pas cosmétique : elle sépare trois décisions commerciales qui n'ont rien à voir entre elles. Refuser l'entraînement n'implique pas de refuser d'être trouvé — c'est même généralement l'inverse de ce que l'on veut, comme nous l'écrivions à propos de la citation par les moteurs de réponse. Et refuser l'agent d'un client qui cherche votre catalogue revient à fermer une caisse.
Or ces trois trafics arrivent par le même port, en HTTPS, avec des en-têtes que rien n'oblige à dire la vérité. D'où la question technique qui commande tout le reste : sur quoi fonder la reconnaissance ?
Un mot sur la déclaration elle-même, puisqu'elle est le point d'appui de toute la chaîne. Un agent utilisateur est une chaîne de caractères librement choisie par celui qui émet la requête. Elle n'est ni attribuée, ni contrôlée, ni opposable. Toute l'architecture décrite plus bas existe pour une raison unique : transformer une déclaration en preuve. Tant que la déclaration reste une déclaration, un exploitant qui filtre sur le nom de l'agent filtre les robots honnêtes et laisse passer les autres — et il faut mesurer ce que ce constat implique avant d'écrire la moindre règle. La question que l'on croit se poser est « qui vient ? » ; la question réellement posée est « qui accepte de me le dire, et sur quelle preuve ? »
Cette exigence de preuve se retrouve, un cran plus loin, dans la manière dont on décide de la confiance que l'on peut placer dans un agent auquel on délègue une action. Le raisonnement est le même des deux côtés du comptoir : ce qui n'est pas prouvé n'est pas une identité, c'est une affirmation.
La signature remplace l'adresse IP
La réponse qui s'impose n'est pas venue du monde bancaire. Elle est venue du besoin, pour un robot légitime, de cesser de dépendre d'une liste d'adresses.
La méthode d'authentification par signature de message HTTP, dont la page de documentation a été mise à jour le 1er juillet 2026, tient en trois couches. Le robot génère une paire de clés Ed25519. Il publie ses clés publiques sur son propre domaine, à un emplacement conventionnel accessible uniquement en HTTPS, au format de jeu de clés JSON. Il signe ses requêtes et joint trois en-têtes : Signature, Signature-Input et Signature-Agent. Le destinataire vérifie la signature contre la clé publiée.
Ce qui disparaît est plus intéressant que ce qui apparaît. Disparaissent la détection par plage d'adresses IP et la résolution de nom inversée, deux méthodes qui ont servi vingt ans et qui supposaient toutes deux que le robot tourne sur l'infrastructure de son éditeur. Cette hypothèse ne tient plus dès qu'un agent s'exécute chez le client, sur un poste de travail ou dans un environnement d'exécution loué à l'heure.
La confiance transitive : le vrai problème
Vient alors la difficulté que la signature ne résout pas, et que la documentation de l'opérateur nomme sans détour.
Les robots se répartissent en deux régimes d'exploitation. Le régime direct : une entité unique exploite son robot sur sa propre infrastructure. Le régime intermédiaire : « un service agentique qu'un large éventail d'utilisateurs finaux peut piloter ». Et la conséquence est écrite telle quelle : cela introduit une confiance transitive — « vous pouvez faire confiance à l'opérateur intermédiaire, mais pas nécessairement à chaque utilisateur final qui le pilote ».
C'est le déplacement de fond. La signature d'un agent intermédiaire atteste de l'éditeur de l'agent, pas de la personne derrière. Un même agent, parfaitement vérifié, transporte indifféremment un client qui compare des prix et un concurrent qui aspire votre catalogue. La réponse envisagée par l'opérateur est expérimentale : transmettre une information sur l'utilisateur final au moyen d'un en-tête dédié, afin que l'exploitant du site puisse appliquer ses préférences. Elle est présentée comme une expérimentation ; il faut la lire comme telle.
Fig. 1 — La chaîne de reconnaissance et son point de rupture. La signature établit l'identité de l'agent, jamais celle de la personne qui le pilote : dès qu'un agent est exploité en régime intermédiaire, la confiance se transmet d'un maillon à l'autre sans jamais atteindre l'utilisateur final. C'est à cet endroit précis, et non au niveau du fichier robots.txt, que se joue une politique d'accès.
Quand l'agent ne vient plus lire, mais acheter
Un cran plus loin, l'agent ne consulte plus : il transige. Les défenses habituelles du commerce en ligne se retournent alors contre le marchand, puisqu'elles ont été construites précisément pour arrêter l'automatisation.
C'est le problème que traite le Trusted Agent Protocol, développé par Visa en collaboration avec un opérateur d'infrastructure. Sa spécification repose sur des signatures cryptographiques propres à l'agent et transporte trois familles d'informations : une intention d'agent, signalant que l'agent souhaite consulter ou acheter un produit déterminé ; une reconnaissance du consommateur, indiquant si celui-ci possède déjà un compte ou a déjà interagi avec le marchand ; et, en option, les données de paiement. Les programmes pilotes sont annoncés pour l'Europe et l'Asie-Pacifique au début de 2026.
Notez ce que la deuxième famille d'informations vous rend : le lien entre un trafic automatisé et un client existant. C'est exactement ce que la détection de robots classique détruit, en traitant l'automatisation comme un signal de fraude. Le sujet rejoint alors celui du paiement lui-même, traité dans notre article sur ce que garantissent les protocoles de paiement agentique — et il s'en distingue nettement : ici, rien n'est encore payé, on décide seulement d'ouvrir la porte.
Votre page devient une surface d'attaque — dans les deux sens
Un aspect passe presque toujours à la trappe dans les discussions sur l'accueil des agents, et il n'est pas mineur : quand un agent lit votre page, votre page lui parle.
Tout ce qui figure dans le contenu servi — texte visible, texte masqué, attributs, commentaires, valeurs de champs — entre dans le contexte du modèle qui pilote l'agent. Il n'existe aucune séparation matérielle entre ce que l'agent doit traiter comme donnée et ce qu'il pourrait traiter comme instruction. C'est le mécanisme décrit dans notre article sur l'injection de prompt, cette faille sans correctif, et l'accueil d'agents en fait un sujet d'exploitant de site, plus seulement de concepteur d'agent.
La conséquence est symétrique, et les deux versants méritent d'être posés. Côté défensif : un contenu déposé par un tiers sur vos pages — un avis client, une description de produit importée d'un catalogue fournisseur, un message dans un fil public — peut viser l'agent d'un visiteur plutôt que le visiteur. Vous hébergez alors, sans le savoir, une instruction adressée au logiciel de quelqu'un d'autre. Côté offensif : rien n'empêche techniquement un exploitant de glisser dans ses propres pages des consignes destinées aux agents qui les parcourent. Cette pratique existe, et la question de savoir ce qu'elle vaut juridiquement n'est tranchée par aucune source relevée ici.
Il en découle une règle d'hygiène simple, et rarement appliquée : le contenu que des tiers déposent chez vous doit être traité comme du contenu non fiable pour les agents comme il l'est déjà pour les navigateurs. La modération d'un avis client ne se pose plus seulement en termes de politesse ou de véracité — elle se pose aussi en termes d'instructions embarquées.
Une politique tient en quatre décisions
Toute cette matière se réduit, pour un exploitant, à quatre questions indépendantes. Les traiter séparément évite la posture par défaut — tout bloquer, ou tout laisser passer — qui est presque toujours mauvaise dans les deux sens.
Laissez-vous entraîner un modèle sur vos contenus ? C'est la seule des quatre que le fichier robots.txt traite correctement, à condition que le robot concerné le respecte, ce qui est le cas des robots d'entraînement documentés.
Voulez-vous être trouvé et cité ? Répondre non à cette question revient à sortir des surfaces de réponse qui remplacent progressivement les pages de résultats. La décision est de nature commerciale et se prend rarement à bon escient dans une console technique.
Laissez-vous un agent consulter pour le compte d'un client ? C'est le cas où le fichier d'exclusion peut ne pas s'appliquer et où votre seule prise réelle est la vérification de signature — donc une politique explicite, écrite, appliquée à l'entrée.
Laissez-vous un agent transiger ? Question à part entière, qui engage vos conditions de vente, votre dispositif anti-fraude et votre service après-vente. Elle ne se déduit d'aucune des trois précédentes.
Un dernier point mérite d'être posé, parce qu'il est souvent découvert trop tard : ces quatre décisions concernent aussi l'assistant conversationnel que vous exposez vous-même sur votre site. Un exploitant qui bloque les agents des autres tout en publiant le sien tient une position difficile à défendre, et pas seulement sur le plan de la cohérence.
🔬 Comment le vérifier vous-même
Rien de ce qui précède n'a été déployé ni mesuré pour cet article. Tout se contrôle en revanche sur votre propre domaine, avec vos propres journaux, en moins d'une demi-journée.
Il reste une question qui n'appartient pas à l'exploitation technique. Un site qui se ferme aux agents ne devient pas invisible : il devient absent des réponses que ces agents rendent à leurs utilisateurs. Un site qui s'ouvre sans politique écrite finance, lui, le catalogue de ses concurrents. Entre les deux, il n'existe pas de réglage par défaut — seulement quatre décisions à prendre, à écrire, et à revoir quand les brouillons de normalisation en cours deviendront des normes.
Cet article est le deuxième de la série Outils IA — l'agent qui agit. Le suivant quitte la porte d'entrée pour l'atelier : ce que devient une tâche de développement confiée à un agent qui travaille pendant votre absence. Sur ce que ces agents savent faire d'un écran, notre article consacré aux agents à usage ordinateur pose le socle.
Une question, un projet IA ?
Vous voulez décider ce que votre site ouvre aux agents, sans vous couper des clients qui les utilisent ? Échangeons sur votre contexte.
Prendre contact →