Guides, marque et plusieurs API, à côté de la référence.
Une référence seule n’est pas une documentation. Les guides s’installent à côté des opérations et pointent dedans, l’ensemble porte votre marque sans étape de build, et une installation suffit à couvrir toutes les API que vous publiez.
Une même page de portail, coupée en deux — trente-cinq thèmes livrés, ou un bloc de variables CSS bien à vous.
Votre Markdown, dans la navigation.
Déclarez un fichier Markdown en une ligne et il devient une page de la navigation — l’ordre du tableau est l’ordre du menu, les groupes s’imbriquent sur un niveau, les liens externes cohabitent. Pointez un fichier que vous avez déjà : un README, un CHANGELOG, un guide existant. Il est récupéré comme le schéma, au moment où on le lit. Rien à construire, rien à redéployer au-delà de vos propres fichiers.
Les pages dialoguent avec la référence plutôt que de la décrire de loin. Un lien apidoc: s’affiche en ligne avec un badge de méthode ; un bloc apidoc:operation affiche une carte d’opération complète. Encarts, onglets de code synchronisés par langage, sommaire et pagination viennent avec le format, et la prose est indexée dans la recherche ⌘K. <Cards>, <Steps> et <Tabs> donnent les composants pour lesquels on fait venir MDX, écrits de la même façon — et rien n’est compilé : un moteur de rendu qui ne les connaît pas montre quand même la prose.
Un guide peut même se lire personnellement : {{var}} dans la prose se résout depuis l’environnement du lecteur, les valeurs sensibles étant masquées plutôt qu’affichées. C’est la documentation personnalisée d’une plateforme hébergée, sans serveur et sans compte derrière.
{
"docsPages": [
{ "title": "Démarrer", "url": "./guides/demarrer.md" },
{ "title": "Architecture", "url": "./guides/architecture.md" }
]
}
Votre marque, sans build.
Trente-cinq thèmes daisyUI sont livrés dans le bundle, plus la paire apiglow / apiglow-dark écrite pour le produit — ce à quoi ressemble une installation neuve. Votre propre thème est un bloc de propriétés CSS déclaré sur la page hôte : pas de configuration Tailwind, pas de recompilation, pas de fork.
Comme les thèmes sont à vous d’écrire, le contraste est à vous de le tenir : le produit conditionne sa propre paire au contraste WCAG, et un thème sur mesure se vérifie comme partout ailleurs — par vous.
Plusieurs API, une installation.
Une seule installation peut porter plusieurs documents OpenAPI. Chacun garde ses environnements, son historique et sa portée de recherche, sans fuite entre eux : un lecteur qui passe de l’API Facturation à l’API Livraison n’hérite pas des identifiants de la première.
Des surcharges par spec permettent à un document de diverger des autres là où c’est nécessaire, et la navigation peut renvoyer les pages de support et les mentions légales sous la référence, en annexe plutôt qu’en seconde section de doc.
L’expérience de lecture, prosaïquement.
Recherche ⌘K avec un filtre de portée qui dit où se trouve un résultat — référence, guides ou scénarios — répondant en moins de 200 ms sur un document de 12 Mo et 1220 opérations, budget que l’application fait respecter par sa propre CI. Une interface entièrement localisée, où ajouter une langue tient dans un fichier JSON et où seule la langue active est téléchargée. WCAG 2.2 AA visé sur tous les parcours interactifs : navigation, console d’essai, recherche.
Un portail entier bâti ainsi — référence, guides bilingues, scénarios enchaînés et un bac à sable qui répond dans la page — se visite sur la vitrine Northwind Rail. Northwind Rail est fictif ; le portail ne l’est pas.
Ce que ce n’est pas.
Les pages de prose sont du Markdown, pas du MDX : il n’y a pas d’endroit où glisser un composant à vous. Les cartes d’opération sont des liens vers la référence, pas des consoles embarquées, et les groupes s’imbriquent sur un seul niveau.
Un thème, ce sont des propriétés CSS. Si votre marque demande une autre mise en page plutôt qu’une autre palette, ce n’est pas le bon levier.