La couche protocolaire du Web agent se divise en deux paris, et la plupart des sites Web ont déjà placé l’un d’entre eux sans le savoir. Le premier pari concerne l’identité : un fichier appelé llms.txt qui indique aux modèles d’IA qui vous êtes et ce que couvre votre contenu. La seconde concerne la capacité : un standard de navigateur appelé WebMCP qui indique à un agent ce qu’il peut réellement faire sur votre site Web une fois celui-ci arrivé. Cela ressemble à la même idée. Ils répondent à des questions opposées. Et la différence décide où doivent aller vos efforts au cours de l’année suivante, car l’un de ces paris est activé par défaut pour vous, tandis que l’autre, celui qui permet réellement à un agent de terminer une tâche, nécessite un travail délibéré.
2 dossiers, 2 questions
Un agent qui atterrit sur votre site Web a peut-être deux choses à savoir. La première est de savoir ce qu’est cet endroit et ce qu’il couvre. La seconde est, maintenant qu’il est ici, comment il accomplit la tâche pour laquelle son utilisateur lui a demandé d’accomplir. Identité, puis capacité. Le Web agent construit une réponse distincte pour chacun, et les deux réponses proviennent de deux fichiers différents soutenus par deux camps différents.
La réponse d’identité est llms.txt, un fichier en texte brut que vous publiez à la racine de votre domaine. C’est une carte organisée : voici qui je suis, voici mes pages les plus importantes, voici de quoi parle chacune d’elles. La réponse en matière de capacité est WebMCP, une norme de navigateur qui permet à votre site Web d’exposer des outils appelables à un agent, afin que l’agent puisse rechercher, filtrer, tarifer ou réserver en appelant une fonction au lieu de deviner votre interface.
Llms.txt et WebMCP sont regroupés comme deux versions de la même chose, la préparation des agents. Ils répondent à deux questions différentes. L’identité est une brochure. La capacité est la caisse enregistreuse. Et à l’heure actuelle, l’industrie pousse chaque site Web vers la brochure, le pari avec les preuves les plus faibles, tandis que la caisse enregistreuse, le pari qui fait réellement avancer une transaction, est laissée aux quelques équipes disposées à la construire.
Le pari identitaire : LLMs.txt
Llms.txt est un fichier de démarque qui se trouve à yourdomain.com/llms.txt. Il a été proposé par Jeremy Howard, co-fondateur d’Answer.AI, le 3 septembre 2024, comme moyen de fournir aux modèles de langage un index propre et organisé par l’homme de votre contenu au lieu de les obliger à l’explorer et à le reconstruire à partir d’un code HTML encombré de navigation, de publicités et de scripts. Le terrain est raisonnable à première vue. Les modèles fonctionnent mieux avec une structure, alors donnez-leur une structure.
Le problème est que les preuves de son efficacité sont minces. Répondant à des personnes sur Reddit en juin 2026, John Mueller de Google a qualifié llms.txt de « purement spéculatif pour l’instant (le fichier existe depuis des années, mais aucun des systèmes d’IA ne l’utilise) » (rapporté par Search Engine Journal). C’est un défenseur de la recherche Google qui dit à voix haute la partie silencieuse. Un dossier qui traîne depuis plus d’un an. Un fichier qu’aucun système d’IA majeur n’a confirmé avoir lu. Un fichier qui vous demande de synchroniser une deuxième copie de votre propre contenu.
Même avec des preuves aussi minces, llms.txt est activé par défaut pour les sites Web. AIOSEO, plugin utilisé sur plus de 3 millions de sites WordPress, génère par défaut un llms.txt. Un très grand nombre de propriétaires de sites Web publient désormais un llms.txt qu’ils n’avaient jamais décidé de publier, décrivant leur site Web dans un fichier qu’ils n’ont jamais lu.
Pour être clair, je ne suis pas contre le dossier. Un llms.txt bien entretenu est un excellent index de contenu. Le problème est la valeur par défaut. Le pari identitaire est gagnant sur l’adoption, non pas parce que cela fonctionne, mais parce qu’une case à cocher du plugin livré est activée. Un fichier que vous n’avez pas écrit, qu’aucun système d’IA n’a confirmé lire, qui se désynchronise du site Web qu’il prétend décrire au moment où vous oubliez son existence, est une chose étrange à avoir au centre d’une stratégie d’agent. Mais c’est là que se trouvent désormais de nombreux sites Web, par défaut plutôt que par choix.
Le pari de capacité : WebMCP
WebMCP, abréviation de Web Model Context Protocol, est une norme de navigateur qui permet à votre site Web d’enregistrer des outils appelables qu’un agent peut invoquer via un navigator.modelContext API. Cela part d’une question différente de celle du fichier d’identité : non pas qui vous êtes, mais, étant donné qu’un agent est déjà sur votre site Web, comment il accomplit correctement la tâche qu’il est venu accomplir. C’est proche de la façon dont Mueller a formulé sa propre préférence dans la même conversation. Il a déclaré qu’il appréciait l’approche WebMCP et les intégrations commerciales car « elles ont des objectifs et des processus clairs ».
Au lieu qu’un agent capture votre page et devine où cliquer, votre site Web le lui dit directement : voici les actions que je soutiens, voici les entrées dont chacun a besoin, voici ce que vous obtenez en retour. Le contrôle s’inverse. Le site Web déclare ses capacités plutôt que de forcer l’agent à les effectuer par ingénierie inverse.
La norme est en cours d’écriture par le W3C Web Machine Learning Community Group par des ingénieurs de Google et Microsoft, et elle a été publiée sous forme de projet le 10 février 2026. Elle fait maintenant l’objet d’un essai d’origine public qui s’étend de Chrome 149 à Chrome 156. Un essai d’origine montre comment Chrome permet à un site Web d’activer une fonctionnalité expérimentale pour ses vrais visiteurs pendant une fenêtre limitée, en s’inscrivant pour un jeton, au lieu de le cacher derrière un indicateur réservé aux développeurs. Vous pouvez donc désormais exécuter les outils WebMCP sur le trafic en direct, et pas seulement sur votre propre ordinateur. L’agent qui utilise ces outils dans Chrome aujourd’hui est Gemini.
WebMCP est le pari le plus fort car il a un travail clair. Un fichier d’identité vous décrit et espère que quelqu’un le lira. Un outil de capacité est invoqué, renvoie des données structurées et rapproche une tâche de sa réalisation. La brochure attend d’être lue. La caisse sonne.
Pourquoi les deux paris ne sont pas interchangeables
La manière la plus simple de faire la différence consiste à utiliser les deux contraintes de conception auxquelles je reviens sans cesse dans l’architecture Machine-First : l’identité et l’interaction. L’identité, c’est rendre votre marque et votre contenu lisibles sans ambiguïté par une machine. L’interaction consiste à permettre à un agent d’accomplir une action avec un résultat prévisible. Llms.txt est un jeu au niveau de la couche identité. WebMCP est un jeu au niveau de la couche d’interaction. Ce sont des outils pour deux tâches différentes, et un site Web peut avoir besoin des deux, d’un seul ou d’aucun, selon ce qu’il souhaite que les agents fassent.
Cela est d’autant plus important maintenant que les agents ne constituent plus une erreur d’arrondi dans votre trafic. Le directeur général de Cloudflare, Matthew Prince, a déclaré en juin 2026 que le trafic automatisé avait dépassé le trafic humain pour la première fois, avec 57,3 % des requêtes vers des pages Web contre 42,7 % émanant de personnes. Un croisement qu’il avait prévu au SXSW n’arriverait pas avant 2027. Lorsque la plupart des requêtes arrivant sur votre site Web sont des machines agissant pour le compte des personnes, la question de savoir si l’agent savait qui vous êtes cesse d’être intéressante. Que l’agent puisse réellement faire ce que votre client a demandé devient tout le jeu. L’identité sans capacité est une machine qui lit votre panneau et se tient ensuite devant une porte qu’elle ne peut pas ouvrir.
C’est l’inversion que l’adoption par défaut fait reculer. Le fichier activé pour tout le monde répond à la question qui compte le moins une fois l’agent arrivé. La norme qui répond à la question la plus importante est celle que presque personne n’a activée.
J’ai placé les deux paris sur mon propre site Web, délibérément
J’utilise les deux sur No Hacks, et le contraste entre le coût de placement de chacun est tout l’argument en miniature.
Pour mon identité, je garde un llms.txt et je le génère à partir du propre contenu du site chaque fois que je mets à jour le site, plutôt que de laisser un plugin pour en écrire un que je ne lis jamais. C’est la partie délibérée. Parce que je le reconstruis chaque fois que le site change, il reste en phase avec ce qui est réellement ici, et si un système d’IA commence à lire llms.txt, le mien sera prêt le jour venu. Je ne parie pas là-dessus. Je le garde à jour et bon marché et je ne le prends pas pour une stratégie.
Pour plus de fonctionnalités, j’ai implémenté WebMCP. Lorsqu’un navigateur compatible WebMCP charge le site Web, il enregistre quatre outils appelables via navigator.modelContext. Deux couvrent le glossaire : l’un répertorie chaque terme afin qu’un agent puisse découvrir ce qui est défini, et l’autre renvoie la définition canonique d’un terme avec son lien source. Deux couvrent mon paysage actuel de navigateurs agents et de produits agents : l’un énumère chaque produit suivi par catégorie et l’autre renvoie tous les détails sur un seul produit par son nom. Un agent n’a pas besoin de parcourir mes pages pour répondre à ce que j’entends par pari de capacité ou quels navigateurs agents je suis. Il appelle un outil et obtient une réponse claire et structurée.
Le détail qui compte le plus est l’endroit d’où les outils lisent. Chacun tire des mêmes données qui alimentent la page destinée aux humains. Les outils de glossaire lisent le glossaire. Les outils produits lisent la liste des produits. Ainsi, la réponse de l’agent et la réponse humaine ne peuvent jamais être en désaccord, car une seule source alimente les deux. C’est la différence entre exposer une capacité et conserver une description distincte de vous-même, et c’est pourquoi le pari de capacité, construit de cette manière, n’a pas de copie distincte à conserver synchronisée.
Je détiens donc les deux fichiers. On a pris un après-midi et on fait du vrai travail. L’autre, je le régénère à partir de mon propre contenu et le traite comme une haie, pas comme un plan.
Ce que cela signifie pour votre site Web
Tout d’abord, découvrez ce que vous avez déjà publié. Ouvrir yourdomain.com/llms.txt dans un navigateur. Si quelque chose se charge, votre pile le place là, peut-être un plugin par défaut que vous n’avez jamais défini. Lisez-le. Demandez s’il décrit réellement votre site Web, car si un système d’IA commence à lire llms.txt, un système inexact est pire que rien du tout. Cela coûte cinq minutes et la plupart des propriétaires de sites Web ne l’ont jamais fait. Si vous souhaitez en conserver un, générez-le à partir de votre propre contenu afin qu’il ne puisse pas dériver.
Deuxièmement, décidez si la couche de capacités vaut la peine d’être placée pour vous. Si les agents ont une raison d’effectuer une tâche sur votre site Web, de rechercher un inventaire, de vérifier un prix, de démarrer une réservation, de commencer un retour, alors WebMCP est le pari qui paie, et l’essai d’origine signifie que vous pouvez l’exécuter sur de vrais visiteurs maintenant plutôt que d’attendre qu’il soit expédié. Si votre site Web est simplement quelque chose que les agents lisent plutôt que sur quoi ils agissent, la couche de capacités peut attendre et vos efforts appartiennent à un contenu propre, rendu par le serveur, que n’importe quel agent peut extraire.
Ce que vous ne devriez pas faire, c’est supposer que le fichier activé par votre plugin est votre stratégie d’agent. Il s’agit d’une revendication d’identité qu’aucun système d’IA n’est en mesure de lire, et elle ne dit rien sur ce qu’un agent peut faire une fois arrivé.
Ce qui n’est toujours pas réglé
L’incertitude honnête : le pari identitaire n’est pas mort ; ce n’est pas prouvé. Si un système d’IA majeur annonce demain qu’il lit llms.txt et le pondère, le calcul change et le fichier dans lequel tout le monde a choisi par défaut gagne soudainement sa place. J’attends exactement ce signal et je ne l’ai pas encore vu.
WebMCP a ses propres questions ouvertes. Il s’agit d’un projet de groupe communautaire et non d’une norme ratifiée. Gemini dans Chrome est le principal agent qui le consomme jusqu’à présent. Et la prise en charge entre navigateurs est plus mince que ne le suggère la couverture secondaire. Microsoft a co-écrit la norme, mais je n’ai pas trouvé WebMCP dans les notes de version officielles de Microsoft Edge à partir de la version 147, je considérerais donc toute affirmation selon laquelle Edge le livre de manière native comme non confirmée pour le moment.
En attendant que ce signal arrive, mon pari est clair : d’ici fin 2026, la capacité sera le pari qui compte, et l’identité se transformera en couverture. Le fichier qui espère être lu perd face à l’outil qui est invoqué, car les agents sont mesurés selon s’ils ont terminé la tâche, et non s’ils ont lu votre signe en premier. Placez le pari de capacité délibérément. Générez le fichier d’identité à partir de votre propre contenu, si vous le conservez. Et lisez celui que votre plugin a déjà écrit avant qu’il ne parle pour vous.
Plus de ressources :
Cet article a été initialement publié sur No Hacks.
