La compatibilité Web pour les agents passe d'une fonctionnalité complémentaire à une exigence par défaut

Un élément de contenu normal apparaît dans le navigateur, mais ne peut souvent pas être lu complètement lorsqu’il est transmis au programme agent. Ce n’est pas parce que la page peut être ouverte qu’elle peut réellement être consommée ; ce n’est pas parce qu’il peut être vu par des personnes qu’il peut être lu, vérifié et suivi de manière stable par des machines.

Cette question était autrefois considérée comme une question secondaire, comme « remplir le plan du site » ou « ajouter des données structurées à la page de l’article ». Ce n’est plus un coin. Une fois qu’un site public est confronté à des robots d’exploration IA, à une récupération automatisée et à des flux de travail basés sur des agents, les objets compatibles ne sont plus seulement des navigateurs et des moteurs de recherche, mais également un type de client capable de diviser les pages en fonction de la sémantique, de sauter en fonction des liens et de poursuivre l’exécution en fonction du statut. Si une page n’est conviviale que pour les lecteurs humains mais pleine de pièges pour ces clients, elle commencera à ressembler à un site Web avec une compatibilité incomplète.

Ce n’est pas parce que la page peut être ouverte qu’elle peut être lue.

Le premier problème n’est généralement pas la qualité du contenu, mais la manière dont le contenu est généré.

Si une page intègre le corps du texte dans le rendu côté client, masque les champs clés dans les panneaux en accordéon, effectue la pagination dans un flux de défilement sans URL explicites et restitue les tableaux en images, le programme agent ne peut s’appuyer que sur des conjectures. Pour les humains, une mauvaise supposition peut signifier qu’un paragraphe est manqué ; pour une machine, une mauvaise supposition peut entraîner une erreur des actions ultérieures, et quelques étapes supplémentaires dans le futur ne feront que continuer selon une mauvaise compréhension.

Ce type de problème est particulièrement évident sur les sites de documents et les sites de contenu. Les lecteurs humains suivent la couche visuelle et complètent eux-mêmes le contexte ; les agents ne le font pas. Ce que l’agent voit, c’est le DOM, la hiérarchie des en-têtes, les relations de liens, les contrôles de formulaire, les codes d’état et le texte explorable. Si le texte principal est déconnecté de ces signaux de base, la page apparaîtra dans un état gênant : elle semble moderne mais est en réalité instable.

Dans le passé, lors de la migration d’applications monopage, cette couche était souvent la première à être exposée. Le premier écran apparaît et l’interaction est possible, mais la machine capture le shell et le texte réel n’apparaît qu’une fois le script terminé. Couplée au chargement paresseux, au défilement infini et à diverses conceptions « développer et afficher », la page de contenu deviendra une série d’événements accidentels. Pour les utilisateurs de navigateurs, il ne s’agit que d’un léger ralentissement ; pour les agents, c’est une chaîne d’entrées peu fiables.

Ce que veut la machine, c’est une entrée stable, pas un contenu visuel.

Rendre le site « prêt pour les agents » consiste essentiellement à ajouter une couche de compatibilité, plutôt qu’à ajouter une nouvelle astuce.

L’aspect le plus précieux de cette couche de compatibilité n’est pas de donner à la page “l’impression qu’elle est destinée aux machines”, mais d’énoncer clairement les faits les plus élémentaires : de quelle page il s’agit, où se trouve le texte, quel est son état actuel, si elle peut continuer à sauter et ce qui doit être renvoyé en cas d’échec. Tant que ces faits restent instables, les agents testeront les limites à plusieurs reprises.

Les éléments les plus intéressants à traiter en premier dans les sites de contenu sont généralement les éléments suivants :

• Le texte doit être directement accessible depuis le HTML, sans recourir à des scripts pour le deviner
• La hiérarchie des titres doit être stable et ne pas laisser le style visuel remplacer la structure sémantique.
• La pagination, le filtrage et les résultats de recherche doivent avoir des URL partageables, plutôt que d’exister uniquement dans l’état frontal
• Les images, tableaux et blocs de code doivent avoir un texte alternatif lisible ou un texte original
• Les exportations de base des fichiers canoniques, du plan du site et du flux doivent être propres et non mélangées à un tas de paramètres temporaires.

Cela peut paraître cliché, mais leur sens a désormais changé. Dans le passé, ceux-ci étaient ajoutés pour le bien des moteurs de recherche et de l’accessibilité ; désormais, ceux-ci sont ajoutés pour permettre à l’agent de localiser le contenu de manière stable, de déterminer la relation entre les pages et de passer à l’étape suivante sans invite manuelle. Ils pointent tous vers la même chose : la page doit être traitée comme une entrée définitive par un autre client, plutôt que comme un résultat visuel ponctuel.

C’est pourquoi « ajouter un bouton IA » n’aide pas vraiment. Le bouton lui-même ne rend pas la page plus consommable. Au mieux, cela enveloppe simplement une action dans une nouvelle entrée. Si la couche inférieure s’appuie toujours sur la présentation visuelle et l’état temporaire pour maintenir la compréhension, le programme d’agent perdra toujours son emprise lors de l’actualisation, du saut, de l’annulation et des modifications d’autorisation.

L’interaction doit terminer l’action, pas seulement s’arrêter à l’invite

Si la page est uniquement destinée à l’affichage du contenu, les problèmes de compatibilité sont relativement faciles à résoudre. Lorsqu’il s’agit du niveau d’interaction et de fonctionnement, le problème devient encore plus difficile.

Ce dont un agent a réellement besoin n’est pas « presque suffisant », mais des limites d’action claires. Soumettre, confirmer, révoquer, télécharger, s’abonner, sauter et exporter, ces actions doivent de préférence avoir des conditions préalables claires, des retours d’échec et des résultats traçables. Tant que les actions sont mélangées à un ensemble de fenêtres contextuelles, d’invites et de confirmations secondaires, la machine restera bloquée encore et encore au même endroit.

C’est là que la différence entre les sites publics et les systèmes internes commence à se creuser. Les sites publics sont confrontés à la consommable, tandis que les systèmes internes sont confrontés à des autorisations et à un contrôle des risques. Le premier est plus adapté pour stabiliser la structure de l’information et la sémantique des actions, afin que les clients externes puissent éviter les détours ; ces derniers ne doivent pas assouplir les limites afin d’être “compatibles avec les agents”, en particulier lorsque des changements de fonds, de publication, de suppression et d’autorisation sont impliqués. Nous devons encore être conservateurs là où nous devrions l’être.

Il ne s’agit donc pas de transformer toutes les pages web en interfaces machines. Une approche plus réaliste consiste à transformer les pages initialement destinées à une consommation externe en entrées stables, vérifiables et rejouables. Les pages d’articles, les pages de documentation, les bases de connaissances, les centres d’aide, les API ouvertes et les résultats de recherche publics sont les premiers concernés et les premiers à en constater les avantages.

Ce niveau de compatibilité a des limites claires

La préparation des agents n’est pas un objectif unique.

Le backend d’un intranet complet, le système d’entreprise avec un contrôle strict des autorisations, la page d’activité à cycle de vie court et la station de contenu destinée à la consommation publique ne sont pas au même niveau. Le premier se soucie davantage du contrôle, tandis que le second se soucie davantage de la lisibilité, de l’indexabilité et de la traçabilité. Forcer ces deux types de systèmes dans le même ensemble de normes qui « rendent les machines utilisables » ne fera en fin de compte qu’augmenter les coûts de gestion.

Mais difficile de continuer à prétendre que rien n’a changé sur le site public. Les robots d’exploration IA liront de plus en plus les pages directement et les flux de travail des agents s’appuieront de plus en plus sur un contenu structuré et des actions stables. Si un site s’en tient toujours à l’idée selon laquelle « il suffit que les gens le voient », il y aura tôt ou tard des fissures dans la distribution, la récupération, l’archivage et l’intégration automatisée du contenu.

Ce changement s’apparente donc davantage à une mise à niveau de compatibilité. Dans le passé, le front-end devait prendre en compte différents navigateurs, différents écrans et différents réseaux ; désormais, il doit également prendre en compte un type de client capable de diviser les pages par lui-même, de suivre les liens par lui-même et de vérifier son statut par lui-même. Avec cette couche de compatibilité ajoutée, le site peut véritablement entrer dans une nouvelle exigence par défaut : il doit non seulement être visible, mais également être consommé de manière stable.