Lorsque je parle aux gens des agents qui interagissent avec des sites Web, la conversation commence presque toujours par la perception : comment un agent « voit » une page ? S’agit-il de captures d’écran, du DOM ou de l’arborescence d’accessibilité ? Dans mon précédent article d’InfoWorld, « L’accessibilité est l’interface de premier ordre pour les agents IA », j’ai soutenu que l’arborescence d’accessibilité devient une interface de plus en plus importante entre les sites Web et les agents IA. À partir de là, la conversation se tourne vers l’actionnement et vers les moyens de le rendre moins fragile, ce qui permet à un site d’exposer ses propres actions en tant qu’outils appelables au lieu de forcer un agent à deviner les boutons et les formulaires.
Cette conversation compte. Mais cela laisse de côté une question architecturale plus conséquente, celle qui détermine qui est responsable lorsqu’un agent commet quelque chose de mal : où vit l’agent ?
Il existe trois emplacements plausibles pour un agent qui interagit avec votre entreprise : sur site, dans le navigateur et hors navigateur. Chacun échange différemment le contrôle contre la portée. À l’heure actuelle, une grande partie de l’attention de l’industrie se concentre sur les deux foyers les plus éloignés de l’entreprise : les extensions de navigateur qui naviguent conjointement avec un utilisateur et les agents autonomes exécutés dans le cloud qui communiquent avec vos API ou pilotent eux-mêmes un navigateur.
Je pense que ce n’est pas le bon point de départ pour la plupart des entreprises.
Si vous dirigez une entreprise avec une réelle exposition à la conformité, ou une marque que vous ne pouvez pas vous permettre de dénaturer, la solution pragmatique consiste à créer d’abord l’agent qui vit sur votre propre site et à traiter la portée comme un problème que vous résolvez plus tard, selon vos propres conditions.
Atteindre sans gouvernance est un handicap
L’attrait des agents intégrés et hors navigateur est évident. Ils promettent une découverte, une évolutivité et une automatisation que vous n’avez pas besoin de créer ou de maintenir vous-même. Un agent hors navigateur peut comparer vos prix à ceux de tous vos concurrents et continuer à travailler une fois que votre équipe d’assistance est rentrée chez elle. Une extension de co-navigation peut agir au sein de la session déjà authentifiée d’un utilisateur sans nécessiter aucune intégration particulière de votre part.
Mais un agent que vous ne contrôlez pas parle toujours au nom de votre entreprise.
Un agent hors navigateur parlant à vos API ou grattant vos exécutions DOM sur un modèle que vous n’avez pas choisi, suit des garde-fous que vous n’avez pas écrits et représente votre marque dans une conversation que vous ne pouvez pas voir. S’il donne un prix erroné, énonce une politique de manière erronée ou initie une transaction créant un litige client, le fait que l’agent appartenait à quelqu’un d’autre ne fera peut-être pas disparaître le problème qui en résulte.
Il existe également un problème de sécurité plus profond. Les agents informatiques interagissent dès leur conception avec du contenu non fiable. Les conseils d’Anthropic destinés aux agents utilisant des navigateurs et des ordinateurs indiquent que les pages Web et les interfaces d’application peuvent contenir des instructions contradictoires et recommandent des autorisations limitées, une confirmation humaine pour les actions à enjeux élevés et une surveillance du comportement des agents. L’IA Agent Security Cheat Sheet de l’OWASP va plus loin, identifiant les risques spécifiques aux agents, notamment l’injection rapide, l’abus d’outils et l’élévation de privilèges, l’exfiltration de données et l’empoisonnement de la mémoire.
Les agents intégrés au navigateur sont une meilleure affaire, car un humain regarde le même écran et peut détecter une erreur avant qu’elle n’atterrisse. Mais le modèle, le ton et la logique décisionnelle échappent encore à votre contrôle. Pour tout autre secteur réglementé, ce n’est pas un risque à prendre à la légère simplement pour atteindre un objectif que vous n’avez pas encore appris à gouverner.
Ce que vous gagnez réellement en construisant chez vous
Un agent sur site est moins glamour que l’idée que votre produit soit découvert par des agents itinérants sur le Web ouvert. Mais c’est le seul siège où l’entreprise conserve une pleine gouvernance.
Vous choisissez le modèle. Vous définissez les garde-corps. Vous décidez du ton, des voies d’escalade et de ce que l’agent est et n’est pas autorisé à promettre exactement à un client. Étant donné que l’agent a un accès direct à vos systèmes, il n’a pas besoin de procéder à une rétro-ingénierie de votre flux de paiement comme le ferait un agent externe. Il peut être donné votre connaissance réelle du domaine et vos API réelles.
C’est important parce que les entreprises ont déjà résolu ce problème. Ils n’ont pas exposé les bases de données directement sur Internet ; ils ont introduit les API. Les API ne concernaient pas seulement l’intégration. Ils ont créé des contrats, l’authentification, l’audit et l’application des politiques. Les agents sur site représentent une évolution similaire. Plutôt que de forcer un agent externe à déduire un comportement à partir d’une interface utilisateur, une entreprise peut exposer des fonctionnalités gouvernées via des outils avec des contrats explicites.
WebMCP est une étape prometteuse dans cette direction. Cela permet à un site de publier plus facilement les actions qu’un agent peut invoquer, au lieu de forcer l’agent à deviner la page. Le changement important n’est pas que l’agent puisse cliquer sur un bouton. Le but est que chaque action devienne observable, régie par des politiques et rejouable.
La démo WebMCP Sports de l’équipe Chrome est un bon aperçu de ce à quoi cela peut ressembler : un assistant sur site appelant les propres outils WebMCP du site, chaque appel étant visible dans le journal de discussion. Ce n’est pas une boîte noire dont vous espérez qu’elle se comporte. Il s’agit d’une interaction auditable, avec des outils nommés et des contrats définis.
Les trois maisons
La façon la plus claire d’y penser est de considérer un spectre.
- Sur place. L’agent vit sur votre site Web. Vous l’expédiez. Vous possédez le modèle, les outils, le ton, les politiques et la télémétrie. Il dispose d’un accès de première partie à vos systèmes et à vos flux de travail. Le compromis est la portée : elle est couplée à votre site et n’est pas destinée à accompagner le parcours de l’utilisateur sur le Web.
- Dans le navigateur. L’agent réside dans la session du navigateur de l’utilisateur, généralement en tant qu’extension de co-navigation ou assistant intégré au navigateur. Il bénéficie de l’état de connexion de l’utilisateur et peut agir en présence de l’utilisateur. Cela lui donne une réelle portée et un solide filet de sécurité humaine. Mais l’entreprise ne contrôle ni le modèle ni les garde-corps, et l’agent peut toujours donner une fausse image de la marque.
- Hors navigateur. L’agent s’exécute ailleurs : dans le cloud, sur un serveur ou sur la machine locale d’un utilisateur et atteint votre entreprise en parlant aux API ou en pilotant un navigateur à distance. Il s’agit du modèle le plus étendu, mais aussi le moins gouverné du point de vue de l’entreprise. Il peut comparer des concurrents, croiser les flux de travail et agir à grande échelle, mais vous ne contrôlez pas l’expérience.
Aucune de ces maisons n’est intrinsèquement mauvaise. Ils résolvent différents problèmes. Mais si votre première priorité est la gouvernance, la responsabilité et l’intégrité de la marque, le terrain est le bon point de départ.
Commencez par l’interface gouvernée
Pour les équipes qui décident où placer leur premier investissement, trois étapes font la différence entre une vraie interface et un chatbot collé à une page d’accueil.
Tout d’abord, envoyez l’agent sur site comme interface faisant autorité, et non comme solution de secours. Il doit avoir un accès de premier ordre à vos propres API et connaissances de domaine – les mêmes systèmes que votre équipe d’assistance et votre flux de paiement utilisent déjà – plutôt que de recevoir une version récupérée de votre propre page.
Deuxièmement, instrumentez chaque appel d’outil qu’il effectue. Si votre agent appelle un outil WebMCP pour vérifier l’inventaire ou appliquer une remise, enregistrez-le de la même manière que vous enregistreriez un appel API provenant de n’importe quel autre client. Ce journal constitue votre piste d’audit, votre outil de débogage et éventuellement votre preuve lorsqu’un régulateur ou un client vous demande ce qui s’est passé.
Troisièmement, concevoir une escalade humaine dès le premier jour. Même un agent bien gouverné ne devrait pas prendre toutes ses décisions de manière autonome. Créez des chemins de transfert explicites vers les opérateurs humains pour les situations ambiguës ou à haut risque.
Pris ensemble, ces choix transforment un agent sur site en une interface gouvernée plutôt qu’en une fonctionnalité de nouveauté. Cette distinction est importante. Le premier est quelque chose qu’une entreprise peut exploiter en toute sécurité ; la seconde est quelque chose qu’elle devra éventuellement défendre.
Quand les agents commencent à parler aux agents
Il existe une autre raison de construire d’abord l’agent sur site : il est peu probable que les trois maisons restent isolées.
Imaginez que l’agent de navigation d’un utilisateur arrive sur le site Web d’une compagnie aérienne. Il connaît déjà les préférences du voyageur, ses contraintes de calendrier, ses programmes de fidélité et peut-être son budget. L’agent sur place de la compagnie aérienne connaît quelque chose de complètement différent : les itinéraires, la disponibilité des sièges, les règles tarifaires, l’éligibilité au surclassement et les politiques opérationnelles de la compagnie aérienne.
Pourquoi l’agent en visite devrait-il procéder à une ingénierie inverse de tout cela à partir d’un site Web ?
Une architecture plus naturelle pourrait consister à permettre aux deux agents de communiquer.
Ce n’est plus purement hypothétique. Le protocole Agent2Agent (A2A) est explicitement conçu pour permettre aux agents indépendants créés par différents fournisseurs et frameworks de découvrir des fonctionnalités, d’échanger des informations, de déléguer du travail et de coordonner des tâches.
Dans ce monde, l’agent de l’utilisateur apporte l’intention et le contexte de l’utilisateur. L’agent du site apporte une connaissance du domaine et une exécution gouvernée.
Et du coup, la portée limitée de l’agent sur place ne semble plus aussi limitée. Il n’est pas nécessaire qu’il voyage sur le Web si d’autres agents peuvent y accéder.
Le problème des incitations que personne n’a encore pris en compte
Derrière la question technique se cache une question plus difficile : pour qui travaille réellement l’agent sur site ?
Un agent visiteur, co-navigateur ou non, agit au nom de l’utilisateur. Un agent sur place, aussi bien bâti soit-il, est l’employé de l’entreprise. Et dès que les deux négocient une remise, une mise à niveau ou une substitution, cet échange cesse de ressembler à un transfert neutre et commence à ressembler à une conversation commerciale avec une IA de chaque côté de la table.
Cette tension va compter.
Les entreprises qui construisent des agents sur site devraient désormais concevoir leurs garde-fous en tenant compte de cet examen minutieux, plutôt que de considérer « l’agent a décidé » comme un bouclier. Le contrôle en vaut la peine. C’est aussi une responsabilité. Et construire l’agent qui vous répond est le seul moyen de l’exercer.
Le premier agent devrait être celui que vous pouvez gouverner
L’histoire des logiciels d’entreprise suggère un modèle familier. Les organisations adoptent de nouveaux modèles d’interaction en les plaçant d’abord sous leur propre gouvernance. Les systèmes internes deviennent des API. Les API deviennent des plateformes. Les plateformes deviennent des écosystèmes.
Les agents IA suivront probablement le même chemin.
C’est pourquoi je pense que le premier agent que votre entreprise construit ne devrait pas être celui qui peut atteindre l’ensemble du Web. Ce devrait être celui dont vous pouvez comprendre, mesurer et améliorer le comportement. Une fois cette fondation établie, l’expansion vers l’extérieur devient un choix architectural plutôt qu’un acte de foi.
La portée est tentante. Mais pour les entreprises réglementées et sensibles à la marque, le contrôle doit primer.
