Trois façons de piloter une page web avec l'IA
Une extension qui agit pour l'utilisateur. Des outils WebMCP déclarés par une page. Un agent intégré à l'application via un SDK. Les trois résolvent des problèmes différents, coûtent des choses différentes, et la réponse honnête à laquelle choisir commence par une question : à qui appartient la page ?
La réponse courte
- Extension de navigateur. Le bon choix quand l'agent doit travailler sur des sites qui ne sont pas les vôtres, quand l'utilisateur doit porter le coût du modèle, et quand voir l'écran compte plus que la vitesse.
- WebMCP. Le bon choix quand vous voulez que des agents externes agissent sur vos pages de façon fiable, via un standard, et que vous pouvez composer avec un support navigateur encore partiel.
- Agent dans le produit. Le bon choix quand vous voulez de la vitesse, des actions au delà de ce que montre l'écran, la maîtrise de l'interface, et les conversations entre vos mains.
Elles ne s'excluent pas. Les mêmes fonctions sous jacentes peuvent alimenter les trois, et la plupart des équipes en utiliseront plusieurs.
Une même page, une même tâche, trois façons de la piloter
Un client veut un remboursement sur la commande 8412. Même tâche, même page, trois surfaces. Chacune sait faire quelque chose que les deux autres ne savent pas.
L'agent arrive avec l'utilisateur
Une extension ou un navigateur agentique lit la page que vos utilisateurs voient et agit dans leur session. Rien à construire chez vous, l'abonnement au modèle est le leur, et l'agent apporte le contexte de tout ce qu'ils ont ouvert à côté.
- 1L'utilisateur amène son propre agentUne extension ou un navigateur agentique. Vous ne livrez rien, et la facture du modèle est la sienne.
- 2Il voit la page comme l'utilisateurCaptures d'écran et DOM : un bouton grisé ou un bandeau d'erreur compte, même si aucune API ne l'expose.
- 3Il choisit une cible et cliqueDans la session utilisateur, avec ses droits, et avec ce qu'il a appris dans ses autres onglets.
- 4Une modale s'ouvre, il relitChaque changement d'écran coûte une relecture. C'est cette boucle qui rend l'approche lente.
- 5La tâche aboutit, hors de chez vousÇa a marché. Vous n'avez jamais vu la conversation, ni ce que l'utilisateur cherchait vraiment.
Ce que chaque approche sait faire, et où elle s'arrête
Chacune des trois gagne sur un point que les deux autres ne peuvent pas offrir. Voici l'argument de chacune, et le prix qui va avec.
Extension et navigateur agentique
Une extension ou un navigateur agentique tourne à côté de la page, lit ce qui est affiché, et agit dans la session de l'utilisateur. Chrome, Edge, Comet et Atlas en proposent tous une version.
- Marche sur n'importe quel site, y compris tous ceux qui ne sont pas les vôtres
- Rien à construire, rien à changer dans la page
- L'utilisateur amène le modèle et le paie
- Porte le contexte de l'utilisateur, ses préférences et les autres onglets de la tâche en cours
- Les captures d'écran font voir au modèle ce que voit l'utilisateur, y compris des états qu'aucune API n'expose
- Lent, parce que chaque étape demande une nouvelle lecture de l'écran
- Ne touche que les utilisateurs ayant installé une extension ou changé de navigateur
- La conversation ne vous parvient jamais : vous perdez à la fois l'insight et la main sur ce qui est dit de votre produit
- Sensible aux changements d'interface, puisque la cible est un élément affiché
Outils WebMCP déclarés par la page
WebMCP est un standard web en préparation qui permet à une page de déclarer des outils typés qu'un agent peut appeler, au lieu de le faire cliquer. C'est un draft du W3C Web Machine Learning Community Group daté du 28 juillet 2026, en origin trial dans Chrome depuis Chrome 149.
- Bien plus rapide que le pilotage par pixels, un appel typé par action
- Un standard : une seule déclaration sert tous les agents qui le parlent, modèle du navigateur inclus
- Vous choisissez les actions, donc un agent externe ne va pas plus loin que ce que vous autorisez
- Touche des visiteurs qui n'ont ni compte ni session chez vous
- Jeune : un draft et un origin trial, pas encore une fonctionnalité livrée
- En août 2026, cela couvre les navigateurs qui ont activé le test, pas votre audience
- La conversation appartient toujours à l'éditeur du navigateur ou de l'agent, pas à vous
- Borné aux outils que vous avez déclarés et à ce que la page sait faire
Un agent dans votre application JavaScript
Un SDK intègre l'agent dans votre propre application, où il exécute votre code derrière votre authentification. Il ne regarde jamais l'écran : chaque message porte un instantané structuré de la session, la route courante, l'état de page que vous avez déclaré et les dernières actions, et l'agent répond par un appel à une fonction que vous avez décrite. Le SDK AGO en est un, comme tout ce que vous construiriez vous même sur un fournisseur de modèles.
- Rapide, parce qu'il lit un instantané structuré au lieu de capturer puis relire la page
- Les actions ne se limitent pas à l'écran : une page absente du menu, un endpoint sans interface, un traitement sans bouton
- Vous maîtrisez l'interface : l'agent affiche la bonne vue, ou confie un formulaire ou une confirmation à vos propres composants, au lieu de cliquer dans une interface pensée pour des humains
- Chaque appel peut être suspendu jusqu'à l'accord de l'utilisateur, fonction par fonction
- Vous maîtrisez la logique métier, les règles, les permissions et la traçabilité
- Chaque conversation est à vous, avec la connaissance produit qui va avec
- C'est vous qui le construisez et qui le maintenez
- Borné aux outils que vous avez déclarés et à ce que l'application sait faire
- Le coût du modèle est pour vous, pas pour l'utilisateur
- Rien ne se passe sur les sites qui ne sont pas les vôtres
Les neuf questions qui les séparent vraiment
Vitesse, coût, portée et contrôle sur la même ligne, pour que le compromis soit visible avant de vous engager.
| Extension | WebMCP | Agent dans le produit | |
|---|---|---|---|
| Changements nécessaires sur votre site | Aucun | Des déclarations d'outils dans la page | Un SDK et les fonctions que vous exposez |
| Ce que le modèle perçoit | Des captures d'écran et le DOM | Les outils déclarés par la page | Vos données, votre état, vos fonctions |
| Vitesse d'une action | 🐢 Lent, lire puis agir à chaque étape | ⚡ Rapide, un appel typé | ⚡ Rapide, un appel direct à votre code |
| Qui paie le modèle | L'utilisateur | L'utilisateur, via son agent | Vous, à la conversation |
| Qui voit la conversation | L'éditeur de l'extension | L'éditeur du navigateur ou de l'agent | Vous |
| Actions possibles | Ce qui est à l'écran | Ce que vous avez déclaré | Tout ce que votre code sait faire, affiché ou non |
| Contrôle de ce qui est affiché | Aucun, il clique dans votre interface | Aucun, l'agent affiche la réponse | Total, c'est vous qui rendez la vue |
| Marche sur les sites qui ne sont pas les vôtres | Oui | Non | Non |
| Portée en août 2026 | Ceux qui en ont installé une | Origin trial Chrome depuis Chrome 149 | Tous vos utilisateurs, tous navigateurs |
Partez de la question : à qui appartient la page ?
Les trois approches ne se disputent pas le même travail. Le propriétaire de la page, et l'utilisateur que vous cherchez à aider, tranchent plus vite que n'importe quelle liste de fonctionnalités.
La page appartient à quelqu'un d'autre
Recherche, remplissage de formulaires, transfert de données entre deux outils qui ne vous exposeront jamais d'API. Personne ne va livrer des outils WebMCP ou un SDK pour vous arranger, et une extension n'en a pas besoin.
Vous voulez que des agents externes utilisent vos pages
Pages publiques où l'assistant de quelqu'un d'autre achète, réserve ou compare. Déclarer des outils est ce qui rend cela fiable, et ce qui vous laisse la main sur ce que ces agents peuvent déclencher.
Vous voulez aider vos utilisateurs connectés
Des gens bloqués dans votre produit, sur vos données, avec vos règles métier. C'est là que la vitesse, les actions au delà de l'écran et le fait de savoir ce que les utilisateurs demandent valent le développement.
Où AGO se situe, et où il ne sert à rien
Nous construisons la troisième approche : autant l'annoncer clairement plutôt que de la cacher dans la comparaison ci dessus.
Le SDK est la surface, pas le produit. Mettre un agent dans votre page est la moitié facile. Dès que ça marche, vous avez des milliers de conversations par semaine à garder justes, sûres et en progression, et c'est cette moitié là que les équipes sous estiment. Garder la conversation, la ligne du tableau ci dessus, n'est un avantage que si vous avez un endroit où la mettre et quelque chose à en faire.
AGO est le système autour de cette conversation :
- Des agents connectés à votre documentation, vos bases et vos API, pour que la réponse vienne de votre propre vérité
- Un agent lab pour rejouer de vraies conversations et tester un changement avant qu'un client le voie
- Un contrôle d'accès sur qui peut parler à quel agent, et sur les systèmes que chaque agent peut toucher
- Une notation qualité automatique sur chaque conversation et non sur un échantillon, avec les lacunes de doc qu'elle révèle
- Un passage de relais vers Zendesk, Intercom ou votre propre outil quand un humain est vraiment nécessaire, contexte inclus
- Des forward deployed engineers qui construisent et affinent les agents avec votre équipe
C'est la raison pour laquelle nous construisons sur la troisième surface : c'est la seule où la conversation arrive dans un endroit que vous pouvez exploiter. L'agent dans la page est ce que vos utilisateurs touchent, le reste est ce qui fait qu'il vaut encore la peine d'être touché un an plus tard.
C'est le mauvais outil pour le reste. Si votre agent doit réserver un vol sur un site qui ne vous appartient pas, une extension ou un navigateur agentique est la réponse, et nous vous le dirons. Si vous voulez que des assistants externes agissent sur vos pages publiques, déclarez des outils WebMCP. La bonne nouvelle : ce sont les mêmes fonctions. Ce que vous exposez à votre propre agent est ce que vous enregistrerez comme outil le jour où les navigateurs seront prêts, et la partie difficile, décider quelles actions un agent peut exécuter, ne se fait qu'une fois.
Testez un agent dans votre propre application
Toute la documentation du SDK est publiée dans un seul fichier écrit pour les agents de code. Collez ce prompt dans Claude Code, Codex ou Cursor et laissez le brancher l'agent dans votre codebase. Vous obtenez d'abord un panneau de chat qui fonctionne, ensuite vous décidez lesquelles de vos fonctions il peut appeler.
Read https://raw.githubusercontent.com/useago/ago-sdk/refs/heads/main/llms-full.txt
and integrate the AGO chat SDK into this app.Questions sur l'IA qui pilote une page web
Extensions, WebMCP et agents dans le produit, et ce que chacun sait vraiment faire en août 2026.
Quelles sont les façons de piloter une page web avec l'IA ?+
Trois, en août 2026. Une extension ou un navigateur agentique lit la page rendue et agit dans la session de l'utilisateur. WebMCP permet à la page de déclarer des outils typés qu'un navigateur compatible appelle directement. Un SDK place l'agent dans le produit, où il utilise vos routes, votre état et les fonctions que vous exposez. Les trois coexistent, et une même page peut être atteignable par toutes.
Quelle approche est la plus rapide ?+
WebMCP et l'agent dans le produit sont tous deux rapides, parce qu'un appel de fonction typé remplace la boucle capture, raisonnement, clic, relecture. Les extensions et navigateurs agentiques sont les plus lents des trois, pour la même raison : chaque changement d'écran coûte une nouvelle lecture.
WebMCP est il disponible dans les navigateurs aujourd'hui ?+
En partie. WebMCP est un draft publié par le W3C Web Machine Learning Community Group, daté du 28 juillet 2026, et Chrome a ouvert un origin trial depuis Chrome 149, avec un flag de test local sur chrome://flags/#enable-webmcp-testing. À considérer comme un pari sur les prochaines années plutôt que comme un moyen de toucher tous vos utilisateurs ce trimestre.
Quand une extension est elle le meilleur choix ?+
Quand l'agent doit travailler sur un site que vous ne contrôlez pas, quand vous voulez que l'utilisateur amène et paie son propre modèle, ou quand la tâche dépend d'un état visuel qu'aucune API n'expose, comme un bouton grisé ou un bandeau. C'est aussi la seule approche qui porte le contexte de l'utilisateur à travers plusieurs sites dans une même tâche.
Quelle approche me laisse les données de conversation ?+
Seulement l'agent intégré au produit. Avec une extension ou avec WebMCP, l'échange a lieu dans un produit qui ne vous appartient pas : vous voyez l'action qui en résulte, jamais la question, la formulation ni l'hésitation derrière. Si comprendre ce que demandent vos utilisateurs fait partie de l'objectif, c'est ce point qui tranche.
Pourquoi les agents à base d'extension cassent sur les vraies applications ?+
Ils reconstruisent leur compréhension de la page à chaque tour. Une modale, une liste chargée à la volée ou un bouton renommé change ce qu'ils lisent, donc l'agent doit relire et peut se tromper d'élément. Le modèle n'est pas en cause, c'est la cible qui a bougé.
Puis je livrer des outils WebMCP et un agent dans le produit en même temps ?+
Oui, et les deux partagent l'essentiel du travail. L'agent dans le produit sert les utilisateurs que vous avez aujourd'hui, dans n'importe quel navigateur. Les outils WebMCP serviront les navigateurs agentiques qui arriveront ensuite. Les deux peuvent s'appuyer sur les mêmes fonctions, donc la partie coûteuse, décider quelles actions un agent peut exécuter, ne se fait qu'une fois. Voir comment le SDK AGO expose des fonctions
Comment contrôler ce qu'un agent a le droit de faire ?+
Vous exposez les actions une par une. Avec WebMCP vous enregistrez un outil par action, avec un SDK vous décrivez une fonction et son schéma, et dans les deux cas l'agent ne peut appeler que ce que vous avez déclaré. Le SDK va un cran plus loin : un appel marqué comme nécessitant une approbation reste en attente jusqu'à ce que l'utilisateur accepte ou refuse. L'extension est l'exception, puisqu'elle atteint tout ce que l'utilisateur peut atteindre à l'écran et que ce n'est pas vous qui décidez.
Prêt à réinventer votre expérience client ?
Déployez des agents IA qui comprennent vraiment vos clients et votre business. Réservez une démo avec notre équipe pour voir Ago en action.