Génération de doc tech automatisée
Du code au README à la doc API aux diagrammes —— code écrit, doc sort
Le trou noir de la documentation
Le code a changé 20 fois, le README c'est la version d'il y a 3 mois. Une recrue lit la doc, lance et ça explose partout, elle demande « la doc est obsolète c'est ça ? ».
Personne veut écrire de doc. Dev dit « le code c'est la doc », product dit « écris d'abord j'y regarderai après », résultat personne n'écrit rien, c'est qu'entre collègues.
T'écris une doc API bien faite, deux champs changent à la mise en ligne et tu oublies de synchro, le front galère une demi-journée sur l'ancienne doc, vient te chercher des explications.
Laisse OpenClaw faire la doc
OpenClaw lit directo le code source —— signatures, types, returns, comments, who calls who, il saisit tout, puis génère une doc structurée.
C'est pas du trash genre « cette fonction prend un param ». Il détaille chaque route : c'est quoi, params précis, types, returns, codes d'erreur, tout.
Le code change ? Re-lance le Prompt, la doc se met à jour auto. Plus jamais de doc et code qui se battent.
Prompts de génération doc, direct utilisables
README jusqu'à doc API jusqu'à diagrammes, trois Prompts et c'est emballé.
Analyse la structure de code complète du projet, génère un README.md professionnel.
Sections à inclure :
1. Intro du projet : deux phrases max pour expliquer c'est quoi
2. Features : bullet points des fonctionnalités clés
3. Quick start : install, config, run (copie-colle possible)
4. Structure : arbo des répertoires + explications
5. Configuration : variables d'env, fichiers config
6. API specs (si applicable)
7. FAQ
Style : clair et succinct, pas de blabla. Code d'exemple doit être runnable.Lis tous les fichiers de routes/controlleurs du projet.
Génère une doc API standard (Markdown), pour chaque route :
1. Path et méthode (GET/POST/PUT/DELETE)
2. Description : c'est quoi la route
3. Params : nom, type, required?, description, exemple
4. Body example : format JSON
5. Response examples : succès et échec
6. Codes d'erreur expliqués
7. Auth nécessaire (si oui)
Groupe par module, ajoute une TOC de navigation.Analyse la structure de code complète et les relations de dépendances du projet.
Génère ces diagrammes Mermaid :
1. Schéma système (flowchart) :
- Les modules clés et comment ils parlent ensemble
- Sens des flux de data
- Différencie frontend, backend, BD, services tiers
2. Dépendances code (flowchart) :
- Import / dépendances entre modules
- Modules clés vs modules utility
3. Flux données (sequenceDiagram) :
- Un use case métier complet de bout en bout
- De l'action user à la BD au retour
Chaque diagramme a du texte qui explique, outline les décisions de design clés.Génération doc : OpenClaw vs ChatGPT
Les deux peuvent faire de la doc, mais la méthode c'est pas la même.
- Lit directement le code source, la doc vient du code vrai
- Comprend qui appelle qui, doc API sans trou
- Code bouge ? Regénère, la doc suit
- Peut générer des diagrammes Mermaid
- Faut que tu copies-colles le code, contexte limité
- Voit pas la structure du projet, routes can get missed
- Doc une fois, code bouge la doc elle suit pas
- Pour les gros projets token limit peut être un mur