Une part croissante des lecteurs de votre documentation ne sont pas des humains. Les assistants de code vont chercher la documentation pour répondre à « comment intégrer X » ; les agents de support lisent les articles d’aide pour répondre aux questions des utilisateurs ; les agents de recherche résument les journaux des modifications pour évaluer des fournisseurs. Les hébergeurs de documentation indiquent désormais qu’une grande partie du trafic vient d’agents IA, et non de navigateurs. Si votre contenu n’est lisible que par un humain qui fait défiler une page affichée, vous êtes invisible pour un canal qui décide de plus en plus si votre produit sera recommandé, intégré ou écarté.
Préparer son contenu pour les agents tient en trois couches : un index facile à trouver, un protocole qu’une machine sait utiliser, et un contenu assez bien structuré pour mériter d’être lu.
Couche 1 : llms.txt, l’index que cherchent les agents
llms.txt est une convention calquée sur robots.txt : un fichier Markdown à la racine de votre site (yourapp.com/llms.txt) qui dit aux agents fondés sur des modèles de langage ce qu’est votre site et où se trouve son contenu important. Là où robots.txt dit aux robots d’indexation ce qu’ils n’ont pas le droit de faire, llms.txt dit ce qui mérite d’être lu : une courte description du produit, puis une liste choisie de liens vers les pages clés — sections de la documentation, référence de l’API, journal des modifications, tarifs.
Un bon fichier a deux qualités :
Une sélection, pas une concaténation. Le fichier est une carte, pas un fourre-tout. Pointez vers les pages canoniques de votre documentation : les agents suivent les liens et lisent les pages eux-mêmes. (Une convention voisine,
llms-full.txt, est la variante qui contient tout le texte, pour les agents qui veulent tout récupérer en une seule requête. Elle a son utilité, mais c’est l’index qu’il faut réussir en premier.)Généré, pas maintenu à la main. Comme un sitemap, un llms.txt modifié à la main se périme. Générez-le depuis la même API de contenu que celle qui alimente vos pages : un article publié apparaît alors tout seul dans l’index. Si votre contenu vit dans un backend de contenu, c’est une petite route côté serveur : récupérer les listes, écrire des liens Markdown.
Coût : un après-midi. Gain : les assistants des IDE et les agents de recherche qui récupèrent /llms.txt (et ils le font déjà) reçoivent votre présentation du produit, pas une supposition.
Couche 2 : MCP, du lisible à l’exploitable
Le Model Context Protocol (MCP) est le standard qui s’impose pour connecter des agents IA à des systèmes externes sous forme d’outils. Là où llms.txt rend votre contenu trouvable, un serveur MCP le rend exploitable : un agent appelle search_entries avec la question d’un utilisateur, get_entry pour récupérer un article entier, ou liste votre journal des modifications. Ce sont des opérations structurées qui renvoient des données structurées, sans avoir à extraire le contenu du HTML.
Concrètement, cela change qui peut travailler avec votre contenu :
L’agent de code d’un développeur interroge votre centre d’aide et votre journal des modifications depuis l’éditeur, pendant qu’il intègre votre API.
L’agent de rédaction d’une équipe rédige une entrée du journal des modifications, l’enregistre en brouillon et laisse un humain la publier. Si le serveur expose des outils d’édition, le travail sur le contenu devient quelque chose que l’on peut déléguer.
Vos propres agents internes trient les retours ou répondent aux questions de support en s’appuyant sur ce même contenu, sans intégration sur mesure.
Les CMS ont vite pris ce virage : plusieurs grandes plateformes de contenu ont sorti un serveur MCP au cours de l’année écoulée, et c’est en train de devenir une case à cocher quand on compare des plateformes. Kookee en fournit un : un serveur MCP sur le contenu d’un projet, que chaque membre de l’équipe connecte avec un jeton personnel, en lecture seule sauf s’il en décide autrement. Il propose des outils de lecture (lister, chercher, récupérer) et des outils d’édition (créer, modifier, publier, classer, trier les retours) : les deux moitiés de la boucle, des agents qui lisent votre contenu et des agents qui aident à le produire, fonctionnent dès le départ. Quelle que soit votre plateforme, la question à se poser est la même : un agent peut-il atteindre mon contenu sous forme d’outils, avec une authentification limitée à la personne pour qui il agit ?
Couche 3 : un contenu qui vaut les tokens qu’il coûte
Les index et les protocoles apportent votre contenu aux agents ; la structure décide de ce qu’ils peuvent en faire. Il se trouve que les habitudes qui aident les agents sont celles qui aidaient déjà les humains et les moteurs de recherche :
Une question par article, la réponse d’abord. Les agents récupèrent des fragments. Un article qui commence par sa réponse donne un fragment utilisable ; un article qui l’enterre sous un préambule donne du bruit.
De vrais intertitres et des URL stables. La recherche de passages comme la citation reposent sur des sections qui ont chacune leur adresse. Un agent qui peut citer
yourapp.com/help/billing/refunds#timelinedonne une réponse que l’utilisateur peut vérifier.Des champs structurés plutôt que des conventions de rédaction. Une entrée du journal des modifications avec une catégorie typée (« Correctif ») et un champ de version, ce sont des données filtrables ; la même information noyée dans un paragraphe devient un exercice d’analyse.
Du texte, pas des captures d’écran de texte. Pour la plupart des systèmes de recherche documentaire, une image est opaque. Une capture sert d’illustration, jamais de seul support d’une étape.
Une fraîcheur honnête. Une documentation périmée trompe les agents (et leurs utilisateurs) exactement comme elle trompe les humains, mais à grande échelle. Des dates sur les entrées et un journal des modifications tenu à jour donnent aux agents le signal de récence qui leur fait préférer le contenu actuel.
Une pratique propre à l’ère des agents : les articles de contexte interne. Certaines connaissances (limites connues, détails de contournement, subtilités de migration) doivent servir à votre support IA sans être publiées dans le centre d’aide que voient vos prospects. Avec un backend de contenu qui propose une visibilité réservée à l’IA pour les articles, vos réponses vont plus loin que votre documentation publique. Ces articles n’apparaissent pas dans le centre d’aide public, mais ils ne sont pas secrets : l’assistant peut les citer à n’importe qui.
Ce que cela vous apporte, concrètement
Préparer son contenu pour les agents paraît abstrait tant qu’on n’a pas suivi un parcours. Un développeur demande à son assistant de code : « Comment paginer les résultats dans {votre produit} ? » L’assistant récupère /llms.txt, suit le lien vers la documentation de l’API, lit la section sur la pagination et produit du code qui fonctionne, avec sa source. Cet échange s’est appuyé soit sur votre contenu, soit sur une réponse Stack Overflow vieille de deux ans. Multipliez par chaque décision d’intégration, chaque comparaison de fournisseurs et chaque question de support qui passe désormais par un agent, et l’enjeu est clair.
Dans quel ordre s’y prendre
Corrigez d’abord la structure : la réponse en tête des articles, des intertitres, des champs typés. La documentation s’améliore dès aujourd’hui pour les humains, et tout le reste repose là-dessus.
Mettez en ligne
/llms.txt, généré depuis votre API de contenu.Ajoutez un serveur MCP ou adoptez-en un, celui de votre plateforme de contenu si elle en propose un.
Cherchez dans vos logs les user-agents d’agents et les requêtes vers llms.txt ; laissez le trafic réel vous dire quoi approfondir.
Aucune de ces étapes n’est lourde, et leurs effets s’additionnent : le même contenu structuré, servi par une API, qui affiche vos pages et alimente votre recherche, vous rend lisible pour le public de votre documentation qui grandit le plus vite.