La « préparation des agents » WebMCP émerge comme un moyen pratique d’aider les agents d’IA à découvrir et à interagir avec des sites web via des capacités explicites plutôt que par du scraping fragile de l’interface utilisateur. Elle est présentée comme une norme web et annoncée comme « disponible dans Chrome 146 » dans les communications de février 2026, ce qui indique que des interfaces adaptées aux agents pourraient bientôt être une attente par défaut plutôt qu’une expérimentation.
Préparer votre site pour des agents d’IA pilotés par WebMCP signifie penser au‑delà des pages et en termes d’actions : ce qu’un agent peut faire, ce qu’il est autorisé à faire, et comment il doit le faire de manière sûre et fiable. Il s’agit aussi de répondre à un écosystème croissant de clients, alors que des efforts de normalisation autour de MCP sont discutés dans l’industrie au sens large (y compris des rapports d’interopérabilité liés à la Linux Foundation) et que les plateformes signalent un soutien croissant pour MCP.
1) Du scraping à la « préparation des agents » : ce que WebMCP cherche à standardiser
L’automatisation traditionnelle repose souvent sur le scraping de l’interface : cliquer sur des boutons, lire des libellés et espérer que la structure du DOM reste stable. L’argument de WebMCP est de remplacer cette fragilité par une façon standardisée pour les agents de découvrir et d’invoquer directement les capacités du site, réduisant ainsi les ruptures quand l’interface change et améliorant la vitesse d’exécution et la déterminisme.
Le marketing de WebMCP présente ce changement comme analogue au SEO, mais pour les actions : « SEO disait à Google de quoi parlait votre page… WebMCP dit aux agents d’IA ce que votre site peut faire. » Cette analogie importe car elle suggère une nouvelle discipline : décrire les actions, les entrées, les contraintes et les résultats comme des artefacts de première classe, indexables pour les agents.
Le message « disponible dans Chrome 146 » (février 2026) suggère aussi une voie native au navigateur pour l’interaction des agents. Si les navigateurs supportent nativement la découverte d’agents et l’invocation d’outils, la base concurrentielle passe de « fonctionne dans mon UI » à « fonctionne comme une surface d’outil explicite ».
2) Mise en œuvre rapide, modèles, et le vrai travail caché derrière “under an hour”
WebMCP annonce « From zero to agent-ready in under an hour » via une CLI (`npx webmcp-cli`) et plus de 37 modèles industriels. Ce type de passerelle est utile pour installer le squelette : points de terminaison, manifests, et outils/ressources d’exemple qui ressemblent à des flux métiers courants.
Mais le vrai travail commence après le modèle : décider quelles capacités exposer comme outils, définir leurs permissions, et s’assurer que les sorties sont stables et consommables par machine. Un modèle peut créer un point de départ ; il ne peut pas encoder automatiquement vos règles métier, vos contraintes de conformité ou vos cas limites propres au produit.
Considérez la promesse « under an hour » comme un objectif de démarrage : obtenir rapidement quelque chose d’invocable par un agent, puis itérer avec des contrôles de qualité production, des limites de débit, des journaux d’audit, des frontières explicites et une gestion robuste des erreurs, car ce sont ces fonctionnalités qui rendent les agents fiables (et vos systèmes sûrs) à l’échelle.
3) Concevez la couche d’outils autour du noyau JSON-RPC 2.0 de MCP
Sous le capot, MCP utilise une structure de messages JSON-RPC 2.0 pour les requêtes, notifications et réponses. Lorsque vous concevez des points de terminaison ou des serveurs WebMCP, vous vous engagez en pratique sur des noms de méthodes prévisibles, des schémas de paramètres et un modèle d’erreur cohérent sur lequel les agents clients peuvent compter.
Dans une architecture type d’exécution d’outils MCP, l’application d’IA intercepte les appels d’outils, les achemine vers un serveur MCP, puis injecte le contenu structuré retourné dans le contexte du modèle. Cela signifie que les réponses de vos outils ne sont pas « seulement des réponses d’API », elles deviennent des entrées pour l’étape de raisonnement suivante de l’agent ; la cohérence et la clarté affectent donc directement le comportement en aval.
Pragmatique : il vaut la peine de standardiser un style interne pour les sorties d’outils : clés stables, types explicites, payloads distincts réussite/échec et ambiguïté minimale. Si votre outil renvoie de la prose humaine difficile à analyser, vous réintroduisez la même fragilité que WebMCP cherche à éliminer.
4) Faites des paginations et des listings des natives agents (et conformes à la spec)
Les listings, outils, ressources, prompts, catalogues et résultats de recherche destinés aux agents nécessitent souvent la pagination. L’utilitaire de pagination du draft MCP définit une pagination basée sur des curseurs et précise explicitement que les clients MUST traiter les curseurs comme opaques, ce qui signifie que votre implémentation ne doit pas exiger que les clients déduisent du sens à partir des chaînes de curseurs.
L’opacité des curseurs a des conséquences opérationnelles : vous avez besoin d’une validation côté serveur des curseurs, de tailles de page prévisibles et d’un comportement d’expiration sûr. Si les curseurs intègrent un état interne, traitez‑les comme des identifiants : signez‑les, limitez leur durée de vie et évitez de divulguer des identifiants internes sensibles.
La gestion des erreurs compte aussi. La spécification note que des curseurs invalides SHOULD renvoyer le code d’erreur JSON-RPC -32602 (Invalid params). Quand les agents rencontrent des erreurs standardisées, ils peuvent se rétablir (par ex. redémarrer le listing) au lieu de boucler ou de basculer vers un fallback UI.
5) Les descriptions d’outils ne sont pas de la documentation, ce sont des leviers de performance
La qualité des descriptions d’outils est une mesure de la « préparation des agents ». Une grande étude empirique (16 février 2026) a constaté que 97,1 % des descriptions d’outils MCP contenaient au moins une « odeur » et que 56 % n’indiquaient pas clairement l’objectif. Autrement dit : la plupart des surfaces d’outils sont techniquement appelables mais sémantiquement confuses pour les agents.
La même étude a mesuré l’impact sur la performance : l’amélioration des descriptions a augmenté la réussite médiane des tâches de 5,85 points de pourcentage et la complétion partielle des objectifs de 15,12 %. Cependant, cela a aussi augmenté le nombre d’étapes d’exécution de 67,46 % et a régressé les performances dans 16,67 % des cas, donc « plus de mots » n’est pas automatiquement mieux.
Une approche pratique consiste à rendre les descriptions précises plutôt que verbeuses : indiquer l’objectif, les entrées, les contraintes, les effets secondaires et des exemples d’utilisation correcte. Puis tester avec des tâches réelles d’agents et surveiller l’inflation d’étapes non voulue (les agents « réfléchissant trop » parce que la description invite à des vérifications supplémentaires).
6) Permissions, journaux d’audit et limites de débit : la readiness production, c’est le produit
Le modèle « préparation du site » de WebMCP commercialise explicitement l’exposition d’outils avec des limites de permissions, des limites de débit et des journaux d’audit comme faisant partie de la readiness en production. Cela correspond au comportement réel des agents : ils enchaînent des appels d’outils multi‑étapes, retentent, bifurquent et explorent, parfois plus agressivement qu’un utilisateur humain.
La limitation de débit mérite une attention particulière. Un article du secteur affirme que « la gestion inadéquate des limites de débit est la cause n°1 des échecs d’agents en production », et les chaînes d’outils multi‑étapes amplifient le risque de quota. Si un agent a besoin de 20 appels pour compléter un flux, une limite modeste par minute peut devenir une défaillance garantie à moins que vous ne fournissiez du batching, de l’idempotence et des signaux clairs de backoff.
Les journaux d’audit sont tout aussi importants pour la réponse aux incidents et la conformité : enregistrez qui (ou quelle identité d’agent) a appelé quel outil, avec quels paramètres, quand, et ce qui a été retourné. Lorsqu’un utilisateur conteste une action (« pourquoi cette commande a‑t‑elle été annulée ? »), vous avez besoin d’une traçabilité à travers la chaîne d’outils de l’agent, pas seulement l’appel API final.
7) Sécurité pour les écosystèmes d’agents : l’injection de prompt est une réalité opérationnelle
OWASP décrit l’injection de prompt comme un risque où du contenu non fiable inclut des instructions cachées susceptibles d’influencer le comportement d’un agent. Pour les agents web, le danger n’est pas théorique : un agent peut ingérer du contenu de pages, d’e-mails, de PDF, de tickets ou d’intégrations tierces et le traiter comme une instruction exécutable.
Le Top 10 MCP d’OWASP inclut « MCP06:2025 Prompt Injection via Contextual Payloads », cadrant le problème comme une injection classique : l’interpréteur est le modèle et la charge utile est du texte. Ce cadrage aide les équipes d’ingénierie à appliquer des contrôles familiers : validation, moindre privilège, compartimentation et frontières strictes entre données et instructions.
Des recherches récentes soulignent l’ampleur et la créativité des attaques. MUZZLE (9 février 2026) rapporte 37 nouvelles attaques à travers quatre applications web, y compris une injection de prompt inter‑application découverte via du red‑teaming adaptatif agentique. SkillJect (15 février 2026) met en avant « skill‑based prompt injection » pour les agents de programmation, où des skills ou scripts auxiliaires empoisonnés guident le comportement assisté par outils, ce qui est pertinent si votre site publie des « skills », des scripts ou des exemples réutilisables en aval.
8) Couches MCP natives au navigateur, contrôles de crawling et la réalité désordonnée de l’accès
« Préparer votre site pour des agents pilotés par WebMCP » peut aussi signifier offrir une couche MCP native au navigateur qui évite le scraping. MCP‑B commercialise « Direct API calls in milliseconds vs 10, 20 seconds for screen scraping automation », ce qui capture le gain business : des interactions plus rapides, moins coûteuses et moins fragiles lorsque les agents peuvent appeler les outils directement.
MCP‑B affirme aussi que « Authentication just works » en utilisant les sessions de navigateur existantes. C’est attractif car cela réduit la friction : les agents peuvent agir comme l’utilisateur connecté sans réimplémenter OAuth dans un client séparé. Mais cela impose aussi des exigences de conception : vous devez cadrer strictement ce qu’une session authentifiée peut faire via des outils, et veiller à ce que les actions à haut risque nécessitent une ré‑authentification, une vérification renforcée ou une confirmation explicite de l’utilisateur.
Toutefois, tout le trafic d’agents ne sera pas constitué d’appels d’outils, en particulier pendant les périodes de transition. Les contrôles responsables de crawling restent importants. AWS recommande de respecter robots.txt et d’implémenter une limitation du taux de crawl (y compris des délais/délais aléatoires). Les consignes robots.txt de Google notent qu’il prend en charge user-agent, allow, disallow et sitemap, et ne prend explicitement pas en charge crawl-delay. OpenAI documente des user agents distincts (OAI-SearchBot, GPTBot, ChatGPT-User), note que la propagation des règles robots.txt peut prendre ~24 heures, et ajoute une nuance importante : ChatGPT-User « n’est pas utilisé pour crawler le web de façon automatique », et les règles robots.txt « peuvent ne pas s’appliquer » lorsque la navigation est initiée par un utilisateur. Planifiez en conséquence : robots.txt est nécessaire, mais pas suffisant, en tant que plan de contrôle unique.
9) Préparez votre base de code et votre documentation pour des collaborateurs agents, pas seulement des visiteurs
La readiness WebMCP croise souvent l’expérience développeur parce que les agents codeurs et les assistants internes consommeront vos dépôts, SDK et runbooks opérationnels. Les recommandations d’ingénierie d’OpenAI (février 2026) préconisent un fichier AGENTS.md comme une « carte, pas une encyclopédie », maintenu court (~100 lignes) et pointant vers des docs/ plus détaillés comme source de vérité.
Ce modèle complète une surface d’outils WebMCP : l’agent peut découvrir quoi faire via les outils, et comprendre comment le faire en toute sécurité via des instructions concises au niveau du dépôt. Cela aide aussi les humains : les mêmes repères réduisent le temps d’onboarding et facilitent la réponse aux incidents lorsque le comportement des agents doit être débogué.
Enfin, anticipez davantage de clients. Les rapports indiquent une normalisation et une gouvernance croissantes autour des protocoles d’agents (y compris des efforts liés à la Linux Foundation et des revendications de neutralité autour de MCP), et les signaux d’adoption par les plateformes suggèrent que les intégrations de type MCP pourraient devenir plus courantes (avec des discussions publiques sur des préoccupations de sécurité comme l’injection de prompt et le vol de tokens). La leçon pratique : concevez pour l’interopérabilité dès maintenant, avec des schémas clairs, des noms de méthodes stables et des patterns d’auth/permissions portables.
Préparer les sites pour des agents d’IA pilotés par WebMCP consiste moins à ajouter une intégration de plus qu’à redéfinir votre interface publique : des actions en tant qu’outils, gouvernées par des permissions explicites, des limites de débit, une auditabilité et des comportements conformes à la spec comme la pagination par curseur et les codes d’erreur JSON-RPC.
Bien fait, vous réduirez la fragilité du scraping, accélérerez l’exécution des agents et rendrez votre site lisible pour un écosystème croissant de clients agents. Mal fait, vous risquez des automatisations peu fiables, des cascades de quotas et des incidents causés par des injections de prompt ; traitez donc la « préparation des agents » comme une discipline de production, pas comme une case marketing à cocher.
