Pendant trente ans, nous avons construit le web pour des humains qui cliquent et lisent. Puis nous l'avons adapté aux moteurs de recherche. Une troisième catégorie d'utilisateur arrive, et elle ne veut pas visiter votre site : elle veut s'en servir. C'est ce qu'on appelle le web agentique.
Un moteur de recherche lit. Un agent essaie d'accomplir quelque chose
Pendant longtemps, un site avait un visiteur assez prévisible : un humain, arrivé par un lien ou une recherche, qui regardait une page, naviguait, remplissait éventuellement un formulaire et repartait. Puis les moteurs ont imposé une deuxième lecture du web, et nous avons appris à parler deux langues en même temps, une pour les gens et une pour les machines.
Une troisième étape commence, et la différence est plus grande qu'elle n'en a l'air. Un moteur de recherche cherche à répondre à une question : quelles pages semblent pertinentes ? Un agent, lui, reçoit une mission. Trouve-moi un hôtel à Dijon mardi, avec parking, sous 130 €. Compare ces trois produits et commande le moins cher s'il arrive avant vendredi. Réserve un créneau chez ce professionnel.
Dans ces situations, afficher dix liens n'est plus le résultat final. Il faut chercher, comparer, comprendre des contraintes, puis agir.
Avant, une machine venait lire votre site pour décider s'il méritait d'apparaître dans une liste. Maintenant elle vient pour faire quelque chose : réserver, commander, comparer. Ce n'est plus le même visiteur, et il n'attend pas la même chose de vous.
Deux serveurs dans la même pièce, obligés de se parler en photos
Prenons une réservation. Un humain voit un champ « date d'arrivée » et comprend immédiatement qu'il faut cliquer, choisir, continuer. Une IA qui pilote un navigateur fait la même chose : elle prend une capture, analyse l'image, cherche le champ, clique, observe ce qui s'est passé, recommence.
C'est impressionnant, et c'est aussi une manière assez absurde de faire communiquer deux logiciels. Imaginez deux serveurs installés dans la même pièce et contraints de se parler en prenant des photos de leurs écrans. Ça fonctionne, mais on sent qu'on peut faire mieux.
C'est le problème auquel s'attaquent les interfaces destinées aux agents. Cloudflare documente WebMCP, une API expérimentale qui permet à un site d'exposer directement des outils structurés : au lieu de chercher visuellement où cliquer, l'agent découvre une fonction et l'appelle. La différence technique est petite, la différence conceptuelle est énorme. Le site a désormais deux interfaces : celle que voit l'humain, et celle qu'une machine peut utiliser.
Sources : la documentation WebMCP de Cloudflare, mise à jour en avril 2026, et OpenAI, sur les outils de construction d'agents.
Aujourd'hui, une IA qui réserve pour vous regarde l'écran et clique, comme le ferait quelqu'un de très maladroit. Demain, le site pourra lui dire directement « voilà mes fonctions, appelle-les ». C'est plus rapide et ça casse beaucoup moins.
Un site pourrait bientôt avoir des boutons que personne ne voit
Prenons une boutique. Pour un humain il faut une fiche produit, des images, un prix, un bouton, un panier, une interface de paiement. Pour un agent, une bonne partie de cette présentation n'a aucun intérêt : il veut savoir quels produits existent, combien ils coûtent, s'ils sont disponibles, s'il peut commander, ce que coûte la livraison et comment payer.
L'humain voit « Ajouter au panier ». L'agent voit quelque chose comme addToCart(product_id, quantity). L'humain consulte quatre pages, l'agent fait quatre appels. Même service, deux façons complètement différentes de s'en servir.
Cloudflare emploie une expression assez parlante pour décrire ce web-là, autour de quatre propriétés : lisible, découvrable, appelable, payable. Les deux premières ressemblent au web que nous connaissons. Les deux suivantes changent l'équation.
Source : Cloudflare, « Building an open Agentic Internet », 6 août 2026.
Le web actuel sait déjà se faire lire et se faire trouver. Ce qu'il ne sait pas encore faire, c'est dire ce qu'on peut faire avec lui.
Nous avons déjà vécu cette transition, avec Google
Tout cela peut sembler nouveau. Le principe l'est beaucoup moins. Quand les moteurs sont devenus essentiels, les propriétaires de sites ont dû accepter une réalité simple : ce qu'un humain comprend d'un coup d'œil n'est pas toujours évident pour une machine.
Nous avons donc structuré le web. Titres, métadonnées, sitemaps, adresses propres, données structurées, descriptions, textes alternatifs. Cette couche n'existe pas pour rendre la page plus jolie, elle existe pour l'expliquer à une machine.
Avec les agents, nous allons probablement refaire quelque chose de comparable. Mais cette fois il ne suffira pas de dire « voici un produit ». Il faudra parfois ajouter : voilà ce que vous pouvez faire avec.
Source : Google, sur les données structurées.
Attention : « optimiser pour les IA » devient déjà un marché à sigles
Dès qu'une technologie devient importante, une industrie apparaît pour vous expliquer que votre entreprise disparaîtra mardi prochain si vous n'achetez pas son nouveau sigle. Nous avons eu SEO, puis AEO, puis GEO, puis LLMO. Il reste quelques lettres disponibles.
Google a lui-même publié en 2026 un guide qui calme une partie de l'agitation : pour apparaître dans ses fonctionnalités génératives, les fondamentaux du référencement restent pertinents, et aucun fichier spécial ni balisage magique dédié à l'IA n'est nécessaire. Du contenu utile, des pages accessibles, l'information importante disponible en texte, des données structurées cohérentes avec ce qui est affiché.
La nuance est importante. Être compris par une IA et être utilisable par un agent sont deux problèmes différents. Pour être cité dans une réponse générative, un site techniquement propre fonctionne déjà très bien. Pour permettre à un agent de réserver une chambre ou de créer une commande, il faut autre chose : des actions.
Source : Google Search Central, « Fonctionnalités d'IA et votre site ».
On va vous vendre des prestations « d'optimisation pour l'IA ». Google dit lui-même qu'il n'y a pas de balise magique : un site propre et clair est déjà bien placé. Ce qui manque vraiment, ce n'est pas du balisage, c'est la possibilité d'agir.
La vraie rupture commence avec les actions
Un site peut être parfaitement lisible par une IA et complètement inutilisable par elle. Prenons un restaurant. L'IA comprend le nom, l'adresse, la carte, les horaires, les prix. Très bien. Mais si l'utilisateur demande une table pour quatre samedi à 20 h, il faut répondre à d'autres questions : existe-t-il une disponibilité, pour quelle durée, quels créneaux sont réellement réservables, faut-il un téléphone, une carte, peut-on annuler, qui a le droit de confirmer ?
Nous quittons la lecture, nous entrons dans un système transactionnel. Et à partir de là, tout ce que les développeurs connaissent déjà redevient central : interfaces programmatiques, authentification, permissions, validation, journalisation, gestion des erreurs, confirmation, sécurité.
Le web agentique n'abolit donc pas le développement web. Il rend plusieurs bonnes pratiques beaucoup plus importantes.
Le problème des permissions va devenir énorme
Laisser une IA lire votre catalogue est peu risqué. Lui permettre de publier un article l'est davantage. Lui permettre de rembourser une commande encore plus. Et lui donner accès à un compte bancaire devrait normalement provoquer une légère envie de réfléchir deux minutes supplémentaires.
Le monde agentique va donc devoir devenir très précis sur une question : qui a le droit de faire quoi, au nom de qui ? Un agent peut posséder un outil sans devoir l'utiliser librement.
On imagine facilement plusieurs niveaux : consulter une information ; préparer une action sans l'exécuter ; demander l'accord de l'utilisateur ; exécuter réellement ; et pour les actions sensibles, imposer une authentification supplémentaire. Les développeurs connaissent tout cela. Ce qui change, c'est que l'utilisateur ne sera plus forcément devant l'écran au moment où chaque étape se produit.
Donner une clé à un assistant n'est pas la même chose selon la porte. Lire un catalogue, préparer une commande, la valider, rembourser un client : ce sont quatre autorisations différentes, et il faudra les distinguer.
Et si l'agent n'avait plus besoin de la façade ?
C'est la question la plus intéressante. Pour un humain, le site public reste indispensable : nous avons besoin d'une expérience visuelle, d'une marque, d'une ambiance, d'une hiérarchie, et d'une manière de découvrir ce que nous ne cherchions pas.
Mais pour un agent ? Pas nécessairement. S'il peut récupérer les informations structurées puis appeler les actions, la façade devient secondaire pour cette interaction. Et ça oblige à reconsidérer quelque chose qu'on tenait pour évident : un site web est-il forcément une interface ?
Peut-être qu'un site sera plutôt un service à plusieurs interfaces. Une graphique pour l'humain, une structurée pour les moteurs, une fonctionnelle pour les agents. Le même système derrière.
C'est pour ça que la séparation entre le front et le back nous intéresse
Le sujet nous concerne directement. Sillon a été construit en séparant volontairement le back-office et la façade : le moteur connaît les produits, les articles, les clients et les commandes ; la façade décide de leur apparence.
Aujourd'hui cette séparation sert surtout à laisser le développeur libre. Mais elle ouvre une question plus intéressante : si les données existent indépendamment de leur présentation, pourrait-on demain les exposer autrement à un agent ? Conceptuellement, oui. Un produit n'a pas besoin de devenir une carte HTML pour qu'une machine comprenne que c'est un produit. Une disponibilité n'a pas besoin d'être dessinée dans un calendrier. Une action n'a pas besoin d'un bouton pour être une action.
Mais il ne faut pas prétendre que Sillon fait déjà tout cela. Il y a une différence entre avoir une architecture qui s'y prête et exposer un protocole complet permettant à n'importe quel agent externe d'utiliser chaque site. Ce ne sont pas les mêmes choses.
Sillon a plusieurs choix qui vont dans cette direction : la séparation des données et de la façade, des structures prévisibles, un contexte destiné aux IA qui travaillent sur le projet. Rendre un site vraiment utilisable par un agent demanderait d'aller plus loin : exposer explicitement les capacités disponibles, fournir des schémas compréhensibles, gérer finement les permissions, proposer des actions sûres, documenter leurs paramètres, normaliser les réponses et les erreurs, et éventuellement suivre des standards comme MCP ou WebMCP quand ils seront mûrs. C'est une question produit que nous suivons de près.
Faut-il reconstruire tous les sites pour les IA ? Non
Et surtout pas maintenant. Nous sommes au début. WebMCP est expérimental, les acteurs testent encore leurs protocoles et leurs modèles de sécurité, et le standard qui dominera dans cinq ans n'existe peut-être pas encore. Bâtir toute son architecture sur un protocole expérimental serait courageux, ou légèrement prématuré, selon votre affection pour les week-ends passés à refaire ce qui marchait très bien six mois plus tôt.
En revanche, quelques décisions sont déjà raisonnables, et elles ont l'avantage d'être utiles même si rien de tout cela n'arrive :
Garder ses données structurées. Un produit devrait exister comme un produit, pas comme quinze morceaux de texte disposés dans une page. Même chose pour un événement, une réservation, une adresse ou un article.
Produire un HTML réellement lisible, avec les contenus importants accessibles en texte. Google le rappelle encore en 2026.
Utiliser les données structurées quand elles ont du sens, pas pour remplir Schema.org jusqu'à obtenir un sapin de Noël, et en veillant à ce qu'elles correspondent à ce qui est réellement affiché.
Séparer les données de leur présentation. Une information enfermée dans un composant graphique est difficile à réutiliser ; structurée, elle peut alimenter une page, une application, un flux, une interface programmatique, un agent.
Concevoir les actions comme de vraies actions. « Réserver » ne devrait pas seulement signifier « l'utilisateur clique ici », mais correspondre à une opération métier définie, qu'une interface humaine ou un agent peut ensuite déclencher.
Il n'y a rien à refaire dans l'urgence. Les décisions qui préparent le web agentique sont exactement celles qui rendent déjà un site plus solide aujourd'hui : des données propres, du HTML lisible, et des actions qui existent ailleurs que dans un bouton.
La façade ne va pas disparaître
C'est le point à ne pas oublier. On pourrait facilement transformer tout cela en « les IA vont tuer les sites web ». Non. Les humains continueront d'avoir besoin d'interfaces : nous aimons regarder, comparer, explorer, découvrir, et nous faisons confiance à une marque aussi pour la manière dont elle se présente. Le design ne devient pas inutile parce qu'un agent peut réserver un hôtel.
En revanche, il risque de perdre quelque chose qu'il détenait presque exclusivement : le monopole de l'accès au service. Pendant longtemps, pour utiliser un site, il fallait passer par son interface. Demain, ce ne sera peut-être plus toujours vrai.
Nous avons longtemps construit des sites pour les humains. Puis des sites compréhensibles par les moteurs. Nous commençons à devoir imaginer des services utilisables par des agents. Et ce qui est amusant, c'est qu'aucune des idées que ça demande n'est vraiment nouvelle. Ce qui change, c'est qui va commencer à s'en servir.
Pendant trente ans, nous nous sommes demandé ce que verrait le visiteur. La prochaine question pourrait être : qu'est-ce que son agent pourra faire à sa place ?
Les sources
- Cloudflare, « Building an open Agentic Internet » : la vision d'un Internet agentique et ses quatre propriétés, lisible, découvrable, appelable, payable. Publié le 6 août 2026.
- la documentation WebMCP de Cloudflare : l'API permettant à un site d'exposer des outils structurés directement utilisables par un agent. Mise à jour le 23 avril 2026.
- OpenAI, sur les outils de construction d'agents : les environnements permettant à un agent d'exécuter des tâches, d'appeler des interfaces programmatiques et d'utiliser des services.
- Google Search Central, « Fonctionnalités d'IA et votre site » : Google confirme que les fondamentaux du référencement s'appliquent à ses fonctionnalités d'IA et qu'aucun balisage spécifique n'est requis.
- Google, sur les données structurées : l'usage des données structurées pour expliciter le sens d'un contenu.
Les liens pointent vers la page de publication de chaque source plutôt que vers l'article daté lui-même : mieux vaut un lien qui fonctionne dans deux ans qu'une adresse précise qui renvoie une page introuvable.