La version texte uniquement de votre site Web supprime la mauvaise couche

En février 2026, j’ai écrit que le fait de proposer des démarques aux agents IA résout le problème de lecture et non le problème d’exécution. Sept mois plus tard, une plateforme, Shopify, a abordé le problème de l’action, mais pas les miroirs de démarques, les scores de préparation et GEO, la discipline permettant d’être cité dans les réponses de l’IA.

Les versions textuelles actuellement proposées à l’IA ne se contentent pas de contenir des actions ; ils les dépouillent. Un miroir de démarque d’une page Web est de la prose. Tout ce qu’un visiteur aurait pu appuyer a disparu au moment où la machine le reçoit.

Un site Web qu’aucun humain n’ouvrira jamais n’a besoin d’aucun JavaScript lourd ni d’aucune couche visuelle

Un JavaScript lourd est absolument inutile pour un site Web qui n’est pas une sorte d’application Web, et la couche visuelle n’est pas non plus essentielle pour les machines, surtout si la couche structurelle est saine. Créez donc un site Web que vous savez avec certitude que personne n’ouvrira jamais, à titre d’exercice, et les deux partiront. La mise en page, la navigation, le système de conception, les traitements d’image et la hiérarchie qui indique à l’œil où atterrir vont avec, et rien n’est perdu.

Les données structurées sont les sites Web de surface réservés aux machines dont disposent déjà

Les données structurées sont des contenus écrits pour les machines et invisibles pour les personnes. JSON-LD figure à lui seul sur 55,6 % des sites Web mesurés par W3Tech, en septembre 2026. Les données structurées survivent à l’exercice car une personne n’a jamais été son public.

Les miroirs de démarque et les scores de préparation publiés depuis février sont des membres plus récents de la même famille. Les deux répondent à la même question, à savoir ce qu’est cette page. Les miroirs ne répondent en rien à ce qu’on peut en faire. Le scanner de préparation vérifie si les outils WebMCP sont enregistrés sur la page et ne dit rien quant à leur fonctionnement.

Le HTML sémantique est le sol pour exposer les actions et une surface d’outil déclarée est le plafond

Un site Web dispose de deux voies pour exposer structurellement ses actions à une machine, du HTML sémantique et une surface d’outil déclarée, et les deux fonctionnent. De retour dans l’exercice, le site Web que personne n’ouvrira jamais ; la machine apparaît pour faire quelque chose plutôt que pour lire quelque chose. Il veut annuler un abonnement ou acheter la chose, et il n’y a ni écran ni personne sur qui cliquer.

Le sol est constitué de HTML sémantique et de fonctionnalités d’accessibilité. Les éléments autochtones disent ce qu’est une chose et ce qu’elle fait. UN


Le plafond est une surface d’outil déclarée. WebMCP est la proposition actuelle : la page enregistre les fonctions qu’un agent peut appeler, et l’agent les appelle sans rien déduire du balisage.


Idéalement, vous construisez le plafond. Le plafond est toujours une norme proposée, donc le plancher est ce qui compte, et le plancher est brisé pour la plupart des sites Web.
Réparer le sol est un travail, et il est mesuré chaque année
L’évaluation 2026 de WebAIM sur le million de pages d’accueil les plus importantes a révélé que 95,9 % d’entre elles échouaient aux WCAG 2, contre 94,8 % en 2025, annulant six années de petites améliorations. Les erreurs étaient en moyenne de 56,1 par page, en hausse de 10,1 % en un an. Les pages utilisant ARIA, les attributs permettant d’ajouter une sémantique d’accessibilité au balisage, comportaient en moyenne 59,1 erreurs contre 42 pour les pages sans celui-ci. WebAIM prend soin de préciser que ces pages étaient également plus complexes. Le balisage qui recherche une sémantique supplémentaire est toujours le balisage contenant plus d’erreurs.
Trois des six échecs les plus courants sont des actions manquantes. Les entrées de formulaire sans étiquette se trouvaient sur 51 % des pages d’accueil, les liens vides sur 46,3 % et les boutons vides sur 30,6 %. Un bouton sans nom est un bouton qu’un agent ne peut pas distinguer de celui qui se trouve à côté. Chacun d’entre eux est un correctif sur la page que chaque visiteur utilise déjà. Une version texte uniquement les laisse tous là où ils se trouvent et ajoute un fichier.
Sur ces pages, le HTML n’est pas sémantique, donc l’arborescence d’accessibilité à travers laquelle un agent travaille (la façon dont les agents IA voient votre site Web couvre le mécanisme) manque les mêmes éléments qu’un lecteur d’écran. Une entrée sans étiquette a disparu des deux. Une étude acceptée au CHI 2026 a utilisé Claude Sonnet 4.5 d’Anthropic en tant qu’agent d’utilisation informatique sur 60 tâches quotidiennes et a mesuré son succès passant de 78,3 % dans des conditions par défaut à 41,7 % avec le clavier uniquement et 28,3 % avec la fenêtre d’affichage agrandie à 150 %. Il n’a pas testé un balisage brisé, il a testé l’agent fonctionnant de la même manière que travaillent les personnes qui s’appuient sur une technologie d’assistance.
Un agent qui ne peut pas dire si cela a fonctionné le fera deux fois
Sur un projet sur lequel j’ai travaillé, un agent d’IA était configuré pour soumettre des formulaires Web, et deux choses l’ont cassé : un HTML invalide (évidemment) et l’absence de succès programmatique ou de retour d’erreur. L’agent essayait de soumettre à nouveau, car il ne savait pas qu’il avait réussi.
Le formulaire a fonctionné. Une personne aurait vu la confirmation et s’arrêterait. L’agent n’a pas pu, parce que la confirmation avait été donnée à vue, donc il a réitéré la demande. Chaque commande en double, ticket en double et inscription en double provenant de ce modèle est le retour manquant du site Web, et non l’erreur de l’agent. Le code HTML invalide est un problème de fond. Le feedback manquant est celui qu’un formulaire peut avoir sur une page parfaitement valide.
Lorsqu’une machine fait quelque chose, il faut lui dire ce qui s’est passé, sous une forme qu’elle peut lire. Rien dans une version textuelle ne dit quoi que ce soit à ce sujet, et le score de préparation non plus. C’est la liste que produit l’exercice : exposer ce qui peut être fait, le rendre appelable, rapporter ce qui s’est passé.
Les actions que les machines peuvent appeler aujourd’hui ont été installées par une plate-forme
Shopify a activé les outils WebMCP pour chaque vitrine construite sur Liquid, son propre langage de thème, le 5 août 2026 : recherche de catalogue, panier, paiement et recherche de politique, en direct par défaut, rien à installer. En août, c’était le seul endroit que je connaissais avec une surface d’outils déclarée en direct à grande échelle, et les marchands ne l’ont pas construit. J’ai vérifié trois vitrines le lendemain et toutes les trois ont chargé le même script d’adaptateur depuis le CDN de Shopify, car la plateforme l’a écrit une fois et le sert partout. Les descriptions et les résultats des outils sont des instructions destinées à l’appelant de la machine, l’outil de paiement a déplacé le navigateur vers la page de paiement et lui a dit de ne plus naviguer, et un résultat de recherche lui a indiqué quel outil atteindre ensuite, et aucun commerçant n’a eu à en lire un mot.
Les outils lisent le même catalogue, le même panier et effectuent le même paiement que la vitrine humaine, ils ne peuvent donc pas dériver et ne coûtent rien au commerçant. Le 6 août, le chemin de lecture a fonctionné ; une recherche dans le catalogue a renvoyé des produits et des prix, et le parcours d’achat est mort à cause d’une erreur interne. Je ne l’ai pas réexécuté depuis. Shopify a déclaré lors de son appel aux résultats le 5 août que le trafic et les commandes générés par l’IA avaient triplé d’année en année, et que cette affirmation décrit les humains arrivant de réponses de l’IA et achetant comme les humains l’ont toujours fait, donc la question de savoir si une machine a appelé ces outils est toujours une question ouverte. Des parties de cette liste, exposées, rendues appelables, rapportées, sont satisfaites selon le calendrier de quelqu’un d’autre, pour des personnes à qui on n’a pas demandé.
GEO optimise la moitié qui ne peut pas agir
Nous devons parler de ce qu’est GEO et de ce qu’il n’est pas.
GEO, optimisation générative des moteurs, se concentre sur la citation ou la recommandation dans cette réponse LLM, et il est tout à fait exact que la citation est ce qui paie aujourd’hui, il n’est donc pas nécessaire de le contester. C’est ainsi que les gens arrivent ; il est suffisamment mesurable pour être vendu, et dire à une entreprise de l’ignorer serait une erreur.
GEO n’a absolument rien à voir avec l’action. Ce que cela touche, la manière dont une page est descriptible, c’est ce que le référencement a déjà touché.
GEO est vendu comme SEO pour des systèmes plus puissants. Ce qui rend ces systèmes plus puissants, c’est qu’ils peuvent agir. Ainsi, la discipline nommée pour les nouveaux systèmes est celle qui ne s’attaque pas à ce qui les rend nouveaux.
La défense est que l’action est un pari sur un avenir qui n’est pas encore arrivé. Mais chaque entreprise qui peut vous citer aujourd’hui travaille sur une version d’elle-même qui en fait également plus (le paysage des navigateurs agents les répertorie), tout en travaillant avec les autres fournisseurs de l’espace sur les protocoles pour le faire. C’est une erreur de s’arrêter là.
La couche visuelle peut attendre que la structure et les actions fonctionnent
Un site Web comporte trois couches : la visuelle, la structure et le contenu. Les actions vivent dans la structure. Supprimez la couche visuelle et conservez les deux autres, et une machine peut utiliser ce qui reste. Supprimez également la structure et ne conservez que le contenu, ce que fait une version texte uniquement, et la machine ne peut que lire à ce sujet. L’architecture Machine-First, la façon dont j’ai soutenu que les sites Web devraient être construits, signifie que la structure et les actions doivent fonctionner de manière autonome, avec ou sans la couche visuelle au-dessus. La couche visuelle reste pour les gens, et c’est la dernière chose dont il faut s’inquiéter.

Triez ce que vous servez aux machines en descriptibles et réalisables. Attendez-vous à une première pile pleine et à une seconde vide. Le tri prend quelques heures.
Découvrez qui a installé ce qui se trouve dans la deuxième pile. Si quelque chose s’y trouve, une plate-forme l’a probablement mis là, et les termes se trouvent dans une documentation que vous n’avez peut-être jamais ouverte. Lisez-le.
Vérifiez ce que dit votre formulaire. Soumettez-le et lisez la réponse comme le ferait une machine. Si le seul signe que cela a fonctionné est une boîte verte, une IA aura probablement du mal à la gérer.
Réparez le sol avant d’acheter un plafond. Exécutez WAVE, le vérificateur sur lequel l’évaluation de WebAIM est basée, sur la page contenant votre formulaire le plus important, et comptez les entrées sans étiquette, les liens vides et les boutons vides. Ces trois-là font partie des six échecs les plus courants dans les 95,9 % de WebAIM, et ce sont les trois qui font disparaître les actions. Une surface d’outil déclarée ne corrige pas la page à laquelle elle renvoie l’agent.

Une version de votre site Web conçue pour les machines est tout l’intérêt. Une version texte uniquement avec les actions entreprises est une brochure. Et cela est servi à l’utilisateur le plus désireux d’agir.
On pourrait faire valoir que cela rend la brochure inutile.
Plus de ressources :

Cet article a été initialement publié sur No Hacks.