Le site devient biface
Pendant vingt ans, un site devait surtout être agréable à parcourir par un humain et suffisamment propre pour qu'un moteur le comprenne. People Inc. ajoute maintenant un troisième convive à table : l'agent IA, qui ne veut ni votre menu déroulant, ni votre carrousel, ni les quatorze scripts chargés pour lui vendre des chaussettes. Il veut le texte, son auteur, sa date, son état. Le contenu change de lecteur, et donc de tuyauterie.
Dans son enquête publiée par Digiday, Jessica Davies raconte comment l'éditeur est passé du crawling à des dépôts Amazon S3, puis à des API sur mesure. Elles livrent l'article en Markdown avec des métadonnées comme l'auteur, la date de publication ou la date de mise à jour. L'objectif est double : réduire le coût de traitement pour les partenaires IA et mieux contrôler ce qui leur est envoyé. Le HTML cesse d'être l'unique porte.
Ce mouvement ne concerne déjà plus seulement la presse. L'article cite The Economist, qui rend certains contenus marketing et B2B plus lisibles pour les agents, Time, qui convertit ses pages en Markdown, et Forbes, qui expérimente des versions Markdown ainsi qu'une couche MCP. En France, des entreprises comme Pignon Digital documentent déjà des pages Markdown, un fichier llms.txt et des API d'action. Le site se dédouble : une façade pour les yeux, une interface pour les machines.
La tentation est immédiate : ajouter un export Markdown, trois champs JSON-LD, un joli llms.txt, puis déclarer le patrimoine éditorial « agent-ready » avec la mine satisfaite du gonze qui vient de mettre une étiquette sur son tiroir à câbles. Sauf que la lisibilité ne crée pas la fiabilité. Elle rend seulement ce qui existe plus facile à prendre, à transporter et, le cas échéant, à répéter de travers.
Le tuyau est propre
Commençons par rendre justice à People Inc. Le crawling d'une page web est une manière assez baroque d'obtenir un article : l'agent aspire navigation, publicité, scripts, recommandations et balisage avant de retrouver le texte au milieu de ce buffet de mariage. Chez People Inc., les dépôts S3 permettaient déjà d'envoyer des mises à jour et des retraits ; l'API vise une livraison plus efficace et plus contrôlée. Le transport devient enfin explicite.
Les métadonnées ont aussi une utilité très concrète. La documentation Article de Google recommande déjà d'indiquer l'auteur, la date de publication et la date de modification pour aider ses systèmes à interpréter une page. People Inc. pousse cette logique plus loin en livrant directement le contenu et ses « signaux de confiance ». La provenance voyage avec le texte, au lieu d'être déduite tant bien que mal.
L'urgence n'est pas entièrement imaginaire. Le rapport 2026 de HUMAN Security indique, sur les interactions observées par sa propre plateforme en 2025, une croissance annuelle de 7 851 % du trafic provenant d'agents et de navigateurs agentiques. Le chiffre est spectaculaire et son périmètre doit rester accroché au mur : il ne décrit pas tout le web. Il confirme néanmoins que les machines ne se contentent plus d'indexer ; elles commencent à naviguer et à agir.
Une couche machine dédiée peut donc devenir raisonnable pour un éditeur, un catalogue très mouvant, une documentation produit ou un service transactionnel. Elle permet d'authentifier, de versionner, de restreindre, d'observer les usages et de retirer une information. Mais ce sont des capacités d'infrastructure, pas la preuve que le contenu livré mérite confiance. Le tuyau propre ne contrôle pas l'eau.
Le bazar, en Markdown
Là où ça se complique, c'est que l'API transporte ce que l'organisation lui donne. Si trois pages décrivent trois périmètres d'offre, si le cas client n'indique pas la taille du client, si une promesse commerciale a changé sans que l'ancien PDF soit retiré, le Markdown ne réconcilie rien. Il industrialise la contradiction. Proprement, rapidement, avec une jolie réponse 200 OK.
Un agent qui répond pour un acheteur B2B n'a pas seulement besoin d'une date et d'un auteur. Il lui faut savoir ce qui est encore vrai, dans quel marché, pour quel segment, avec quelles conditions, quelle preuve et quelle autorité interne. Une statistique sans population ou une fonctionnalité sans statut de disponibilité restent ambiguës, même empaquetées dans le JSON le plus pimpant du canton. La structure syntaxique n'est pas le contexte.
Cette limite rejoint ce que j'écrivais dans « Vos contenus sont clairs, et c'est bien le problème » : comprendre une information ne suffit pas à décider. Pour un agent, la difficulté devient plus rude encore. Il doit non seulement lire, mais savoir si l'information peut être mobilisée dans une comparaison, une recommandation ou une action. Une phrase claire peut rester indécidable.
Le contenu réellement exploitable ressemble donc moins à un article nettoyé qu'à un objet gouverné. Il possède un propriétaire, une portée, un statut, une preuve, une date de révision, une règle d'expiration et, lorsque le sujet l'exige, une procédure de retrait. Ce travail paraît moins sexy qu'un serveur MCP présenté sur une scène baignée de violet. C'est pourtant la couche qui empêche la vérité de pourrir.
Lire n'est pas agir
Reste un piège commode : confondre lecture et action. Rendre un contenu accessible à un agent lui permet de répondre. Lui permettre d'agir exige autre chose : une interface dont les opérations, les paramètres, les permissions et les erreurs sont décrits. La spécification des outils MCP sépare justement les ressources consultables des outils que le modèle peut invoquer. Une ressource informe ; un outil engage.
Cette frontière est capitale pour une entreprise B2B. Une page peut expliquer une offre ; elle ne doit pas pour autant autoriser un agent à créer une opportunité, modifier un contrat ou inscrire quelqu'un à une séquence. Entre la bonne réponse et la bonne action se glissent l'identité, le consentement, le rôle, le périmètre d'autorisation et parfois ce vieux machin charmant : un humain responsable. L'action ajoute une dette de contrôle.
Le risque serait de construire une seconde usine éditoriale pour les agents : pages humaines d'un côté, Markdown de l'autre, fiches commerciales ailleurs, réponses du chatbot dans un coin, puis une stagiaire héroïque chargée de vérifier que tout raconte à peu près la même chose. On connaît la chanson. Dans ma critique du système Animalz, je distinguais déjà la boucle qui produit mieux de celle qui améliore les décisions. Ici aussi, le doublon technique masque un défaut de gouvernance.
La bonne architecture part d'une source maintenue et produit plusieurs présentations : page web, extrait commercial, documentation, flux machine ou outil agentique. Elle ne demande pas à chaque canal de réinventer la vérité. Cela suppose des arbitrages moins flamboyants que « lançons notre MCP » : qui possède la promesse, qui valide la preuve, qui publie la modification, qui peut révoquer l'accès ? L'interface vient après l'autorité.
| Couche | Question à résoudre | Preuve observable |
|---|---|---|
| Contenu | Que peut-on affirmer, pour qui et dans quelles limites ? | Source, périmètre, statut, propriétaire |
| Distribution machine | Comment livrer la bonne version ? | Flux versionné, journal de mise à jour |
| Action | Que peut faire l'agent et avec quelle autorité ? | Permissions, consentement, confirmation, journal |
L'actif avant le format
People Inc. montre une direction crédible : les sites vont devoir servir des lecteurs humains, des moteurs et des agents dont les besoins ne se confondent pas. À mon sens, la leçon utile pour le B2B n'est pas « convertissez tout en Markdown avant mardi ». Elle est plus exigeante : décidez ce qui mérite d'être machine-actionnable, puis rendez cette matière traçable et maintenable.
Commencez par les informations qui déplacent réellement une décision : périmètre d'offre, critères d'éligibilité, prix ou méthode de prix, prérequis, preuves, compatibilités, délais, risques et procédures. Un article d'opinion peut rester une page. Une condition commerciale utilisée par un agent devrait avoir un propriétaire et un cycle de vie. Tout contenu n'a pas la même criticité.
Cette hiérarchie évite aussi de répéter l'erreur des licences de contenus. Dans l'analyse sur les accords de Google avec les éditeurs, la question était de savoir qui garde la relation avec le lecteur. Avec les agents, elle s'élargit : qui garde la capacité de corriger l'information, d'observer son usage et d'arrêter une action ? Le contrôle ne se résume pas à l'accès.
Votre futur patrimoine éditorial aura probablement plusieurs sorties. Très bien. Mais s'il n'a toujours ni source canonique, ni propriétaire, ni règle de révision, vous n'aurez pas bâti une infrastructure pour agents. Vous aurez installé un monte-charge ultrarapide dans un entrepôt où personne ne sait quelles caisses sont périmées. Et le monte-charge fera admirablement son travail.
Ce que j'en retiens pour agir
D'abord, classez vos contenus par criticité décisionnelle. Le content lead réunit produit, sales et juridique pour identifier les informations qu'un acheteur ou un agent pourrait utiliser afin de comparer, qualifier ou engager l'entreprise. Le livrable tient dans un registre : affirmation, périmètre, source, propriétaire, date de révision et conséquence d'une erreur. Ne commencez pas par exporter tout le blog ; commencez par ce qui peut réellement faire prendre une mauvaise décision.
Ensuite, construisez une source canonique avant son flux machine. Pour un petit corpus, un CMS bien tenu avec champs structurés, historique et statut suffit probablement. Pour un catalogue mouvant, une API ou un dépôt versionné devient pertinent. Le critère n'est pas la modernité de l'outil, mais la capacité à propager une correction, retirer une information et savoir quelle version a été servie. Testez ce cycle complet sur dix objets critiques avant de bâtir une cathédrale.
Enfin, séparez lecture, recommandation et action. Le responsable produit et le RSSI définissent ce qu'un agent peut consulter librement, ce qu'il peut utiliser pour formuler une recommandation et ce qui exige permission ou confirmation humaine. Le livrable est une matrice de droits accompagnée de journaux et d'un scénario de retour arrière. Mesurez erreurs évitées, fraîcheur, reprises et décisions correctement routées ; pas seulement le nombre de requêtes servies.