# Une documentation qu'un agent peut lire.

> Ouvrez votre doc d'API aux agents : llms.txt et llms-full.txt générés dans le navigateur, une config MCP, un menu Copier pour l'IA sur chaque page.
>
> Source: https://apiglow.dev/fr/docs/ai/index.md


Le lecteur d'ApiGlow peut être une personne, un agent, ou une personne qui travaille avec un agent. L'app produit dans le navigateur tout ce que ce lecteur emporte : cette documentation ne fait tourner aucun serveur, et aucun modèle n'est jamais appelé.

Chaque chose s'attrape là où on la veut — les fichiers de l'API entière depuis le menu **« Copier pour l'IA »** de l'en-tête, sur chaque page, et ceux d'une page depuis son menu « Copier la page ». La version courte vit sur la page [Surface IA](/fr/features/agents/) ; ce guide est le mode d'emploi.

## Générer les deux fichiers texte

**`llms-full.txt`** est la documentation entière en un seul document Markdown : infos du schéma, pages de prose, chaque opération. C'est le format que les assistants ingèrent d'un bloc. Copiez-le ou téléchargez-le depuis le menu « Copier pour l'IA » de l'en-tête, sur n'importe quelle page.

**`llms.txt`** est l'index du même contenu, selon la convention [llmstxt.org](https://llmstxt.org/). Il porte :

- les pages de doc sous le titre de leur groupe de nav — celles de la zone du haut en `## Guides`, celles de la [zone du bas](/fr/docs/docs-pages/) en `## Resources`
- une section `## Workflows` qui liste chaque [scénario](/fr/docs/scenarios/) déclaré en config avec ses nombres d'étapes et d'entrées, et sa recette Arazzo quand elle est publiée
- un lien par opération, groupé par tag, et un par webhook
- où trouver le texte complet et le fichier OpenAPI

L'en-tête énonce l'URL de base et une ligne d'orientation sur les schemes d'auth. Le lien Reference est qualifié : quand la documentation rend le schéma à travers des overlays, ou cache des opérations que le fichier publié déclare toujours, le lien le dit, pour qu'un agent lisant le fichier brut sache qu'il diffère de ce que voient les humains.

Dans l'app, les deux fichiers vivent dans le menu « Copier pour l'IA » de l'en-tête, chacun copié ou téléchargé, plutôt que dans la navigation : ils se génèrent sur place, il n'y a donc aucune page vers laquelle naviguer.

Chaque URL qu'ils donnent porte les `{{variables}}` de votre environnement déjà remplies, puisque rien hors de la page ne les connaît. Une URL de base qui demanderait une valeur sensible, ou une variable que personne n'a renseignée, cède la place au serveur du document lui-même — jamais un fichier qui porte un secret ou un `{{nom}}` littéral.

## Les héberger à côté de la page

La doc est une application routée par hash, donc un crawler ou un LLM ne peut pas parcourir des URL `#/op/…`. C'est ce que ces deux fichiers corrigent, à condition d'être atteignables. Déposez-les à côté de la page hôte et servez-les statiquement à la racine du site :

```text
docs.example.com/
├── index.html      ← la page qui porte la balise script ApiGlow
├── llms.txt
└── llms-full.txt
```

## Ou laisser le bake les servir

Télécharger et copier à la main fonctionne. [`apiglow bake`](/fr/docs/seo/) l'automatise : le CLI écrit `llms.txt` et `llms-full.txt` en fichiers servis, dans le même passage qui écrit les miroirs HTML et Markdown.

Les versions servies portent davantage que les téléchargements. `llms.txt` pointe vers le miroir `.md` servi de chaque page au lieu de routes à fragment qu'un agent ne peut pas récupérer, et chaque section de `llms-full.txt` porte une ligne `Source:` vers sa page. La génération dans le navigateur garde les liens à fragment, puisque sans bake il n'y a rien d'autre à pointer.

Les deux fichiers sont des instantanés du document chargé. L'app ne peut pas venir mettre à jour des fichiers sur votre serveur : quand le schéma change, relancez le bake — ou régénérez à la main — et redéployez avec la page.

## La carte de config MCP

Pour les agents qui parlent MCP, la page d'accueil génère une config de serveur prête à coller. Elle relie un pont OpenAPI→MCP du commerce, qui tourne sur la machine du lecteur et se choisit depuis la carte, à l'URL OpenAPI de cette API.

Les credentials en sortent comme des espaces réservés clairement marqués, jamais comme les valeurs stockées dans les environnements de qui que ce soit. Lisez le bloc, collez-le dans la config client de l'agent (Claude Desktop, Claude Code, et compagnie), ou téléchargez-le en `mcp.json`.

Le même enregistrement sort aussi dans les deux autres formes que prend l'outillage d'un lecteur : une **ligne de commande `claude mcp add …`** à coller dans un terminal, et des **liens d'installation pour Cursor et VS Code**. Les trois sont construits depuis une seule config, donc la commande installe exactement ce que dit le bloc sous vos yeux.

Trois comportements à connaître :

- La carte propose deux ponts, qui diffèrent sur la prise en charge des [overlays](/fr/docs/schema-support/). Choisir celui qui ne peut pas appliquer les vôtres est signalé, jamais silencieux.
- Un scheme de sécurité sans forme d'en-tête — un `apiKey` en query ou en cookie, ou `mutualTLS` — est rapporté tel quel plutôt qu'approximé.
- Avec un schéma inline (`openapi.spec`), il n'y a pas de carte du tout : un pont a besoin d'une URL à télécharger, et la page n'en a aucune à lui tendre. Cette règle vaut aussi pour la commande et les liens d'installation.

## Deux menus : cette page, et l'API entière

Les choses à emporter ne sont pas réservées à la page d'accueil. Deux menus répondent à deux questions.

**« Copier la page »** — *donne-moi cette page ailleurs* — se trouve sur chaque endpoint et chaque page de prose.

**Cette page, en Markdown.** Copiez-le dans le presse-papiers, ou ouvrez **« Voir en Markdown »** pour lire la source d'abord : une boîte de dialogue par-dessus la documentation, qui montre exactement la chaîne que produit la copie, telle quelle dans un `<pre>`, avec un bouton pour l'enregistrer en `{operationId}.md`. C'est une vue et non une URL, puisque la doc est routée par hash et qu'il n'existe aucune adresse `?format=md` à donner.

**Cette page, tendue à un assistant.** Deux entrées ouvrent ChatGPT ou Claude dans un nouvel onglet, le Markdown de l'endpoint déjà glissé dans le prompt, sous une phrase qui demande à l'assistant de le lire et d'aider à utiliser l'endpoint. Le Markdown est tronqué au-delà de ~6 000 caractères, parce que les navigateurs plafonnent la longueur d'une URL. La troncature est marquée, donc une longue page arrive visiblement raccourcie plutôt que massacrée en silence.

**« Copier pour l'IA »** — *donne l'API entière à un assistant ou à un agent* — se trouve dans l'en-tête, identique sur chaque page.

**Toute la documentation, pour un assistant.** `llms-full.txt` et `llms.txt`, chacun copié ou téléchargé. Collé dans une conversation, `llms-full.txt` est la documentation elle-même ; `llms.txt` est une liste de liens qu'un assistant ne peut suivre que si le [bake](/fr/docs/seo/) sert les miroirs Markdown.

**L'API entière, branchée sur un agent.** L'enregistrement MCP sous deux de ses formes : la commande `claude mcp add …`, et les liens d'installation pour Cursor et VS Code. Ils sortent de la même config que la carte de la page d'accueil, donc la commande installe exactement ce que la carte montre. L'URL de base suit l'environnement sélectionné : enregistrer depuis un environnement de sandbox produit un enregistrement de sandbox. Avec un schéma inline, la section est tout simplement absente, pour la même raison que la carte.

## Un agent qui corrige le schéma

L'autre sens : un agent qui travaille *sur* votre API plutôt qu'avec elle. L'[audit du schéma](/fr/docs/audit/) note ce qu'un agent obtiendra du document — sa catégorie **prêt pour les agents** couvre les entrées sans type, les unions ambiguës, les valeurs d'enum inexpliquées et les erreurs renvoyées en prose. Et le paquet npm livre une skill d'agent, `skills/apiglow-audit/SKILL.md`, qui lance [`apiglow audit`](/fr/docs/audit-ci/#un-agent-qui-corrige-le-schéma), corrige les constats et audite à nouveau — sans inventer ce que fait votre API, et sans faire taire une règle de lui-même.