Formats de contenu
Choisis parmi 10 templates (tutoriel, guide, reference, cours, API) et remplis le squelette.
Chaque contenu a un format optimal. Si tu choisis le mauvais format, tu ecris deux fois. Ce systeme utilise le framework Diataxis (4 types fondamentaux : Tutoriel, Guide pratique, Explication, Reference) + 6 formats complementaires (Cours, Troubleshooting, Comparaison, Fiche, Changelog, Reference API (Application Programming Interface)).
Arbre de decision
Tu dois ecrire quelque chose. C'est quoi ?
├─ Le lecteur doit APPRENDRE en faisant ?
│ └─ TUTORIEL (pas a pas guide, resultat visible)
│
├─ Le lecteur doit FAIRE une tache precise ?
│ └─ GUIDE PRATIQUE (etapes, pas d'explication)
│
├─ Le lecteur doit COMPRENDRE un concept ?
│ └─ EXPLICATION (pourquoi, pas comment)
│
├─ Le lecteur doit CONSULTER des faits ?
│ └─ REFERENCE (tableau, exhaustif, scannable)
│
├─ Le lecteur doit SUIVRE un cours complet ?
│ └─ COURS (modules, progression, exercices)
│
├─ Le lecteur doit DIAGNOSTIQUER un probleme ?
│ └─ TROUBLESHOOTING (symptome → cause → fix)
│
├─ Le lecteur doit DECIDER entre options ?
│ └─ COMPARAISON (tableau, criteres, verdict)
│
├─ Le lecteur doit CONSULTER un composant / une entite ?
│ └─ FICHE (1 page, 1 sujet, format standardise)
│
├─ Le lecteur doit SAVOIR ce qui a change ?
│ └─ CHANGELOG (version, date, categories)
│
├─ Le lecteur doit INTEGRER une API ?
│ └─ REFERENCE API (endpoints, params, exemples request/response)
│
└─ Pas sur ?
└─ Commence par une EXPLICATION, puis ajoute les autres1. Tutoriel
Le lecteur apprend en faisant. Il part de zero et arrive a un resultat visible.
Quand l'utiliser
- Premier contact avec un outil ou concept
- Le lecteur n'a aucune experience prealable
- Le resultat doit etre visible en moins de 15 minutes
Squelette
---
title: Creer [resultat] avec [outil]
description: "De zero a [resultat] en [temps]."
human_check: false
---
## Ce que tu vas construire
[1-2 phrases + screenshot/schema du resultat final]
## Prerequis
- [Outil] installe (version X+)
- [Autre prerequis]
## 01 — [Premiere action]
[1 phrase de contexte]
\`\`\`bash
commande ici
\`\`\`
[1-2 phrases expliquant ce qui s'est passe]
## 02 — [Deuxieme action]
[Meme pattern : contexte → code → explication]
## 03 — [Troisieme action]
[...]
## Resultat
[Screenshot ou sortie terminal du resultat]
Tu as maintenant [ce que le lecteur a accompli].
## Lecture liee
- [Guide pratique avance](/lien)
- [Reference complete](/lien)Regles specifiques au tutoriel
| Regle | Detail |
|---|---|
| Resultat visible en 5-15 min | Si plus long, decouper en plusieurs tutoriels |
| Etapes numerotees | 01, 02, 03 — pas de bullets |
| Zero choix pour le lecteur | Un seul chemin. Pas de "tu peux aussi" |
| Montrer le resultat d'abord | Le lecteur sait ou il va AVANT de commencer |
| Pas d'explication de fond | "Pourquoi" va dans une page Explication separee |
| Output attendu a chaque etape | Montrer la sortie terminal ou le screenshot attendu. "Tu dois voir..." |
| Anticiper les erreurs courantes | Si une etape echoue souvent, ajouter : "Si tu vois [erreur], verifie [cause]" |
| "Nous" accepte | La 1ere personne pluriel cree la relation tuteur-apprenant |
2. Guide pratique (How-to)
Le lecteur sait ce qu'il veut faire. Il a besoin des etapes, pas de la theorie.
Quand l'utiliser
- Le lecteur connait deja l'outil
- Il a un objectif precis ("configurer SSL", "ajouter un agent")
- Il ne veut pas apprendre, il veut finir
Squelette
---
title: [Verbe] [objet]
description: "[Verbe] [objet] en [nombre] etapes."
human_check: false
---
[1 phrase : ce que tu vas faire et pourquoi.]
## Prerequis
- [Prerequis 1]
## [Verbe] [objet]
\`\`\`bash
commande
\`\`\`
[1 phrase de contexte si necessaire]
## Verifier
[Comment confirmer que ca a marche]
## Troubleshooting
| Symptome | Cause | Fix |
|----------|-------|-----|
| [Erreur] | [Raison] | [Solution] |Regles specifiques au guide pratique
| Regle | Detail |
|---|---|
| Titre = verbe d'action | "Configurer", "Ajouter", "Deployer" |
| Pas de theorie | Si le lecteur veut comprendre, lier vers une Explication |
| Troubleshooting en fin | Les problemes courants, pas un cours sur les erreurs |
| 1 objectif = 1 guide | Pas de "et aussi tu peux..." |
| Adaptable au reel | Le guide doit couvrir les variantes courantes (ex: "Si tu es sur macOS, remplace par...") |
3. Explication
Le lecteur veut comprendre POURQUOI. Pas faire, comprendre.
Quand l'utiliser
- Concept complexe a demystifier
- Architecture ou philosophie a expliquer
- Le lecteur pose la question "pourquoi ?"
Squelette
---
title: [Concept] — pourquoi et comment ca marche
description: "[Concept] explique. Pourquoi [choix], comment [mecanisme], quand [utiliser]."
human_check: false
---
## Le probleme
[Quel probleme ce concept resout]
## La solution
[Comment ca marche, en termes simples]
## Pourquoi ce choix
[Alternatives considerees, tradeoffs, decision]
| Approche | Avantage | Inconvenient |
|----------|----------|--------------|
| Option A | ... | ... |
| Option B | ... | ... |
## En pratique
[Exemple concret qui illustre le concept]
## Ce qu'il faut retenir
[3-5 bullet points]Regles specifiques a l'explication
| Regle | Detail |
|---|---|
| Pas d'etapes a suivre | C'est un guide pratique, pas ici |
| Probleme → Solution → Justification | Structure en 3 actes |
| Exemples concrets obligatoires | Pas de concept sans illustration |
| Comparaison de tradeoffs | Montrer les alternatives et pourquoi ce choix |
4. Reference
Le lecteur cherche un fait precis. Il ne lit pas, il scanne.
Quand l'utiliser
- Lister des options, parametres, commandes
- Catalogue exhaustif (agents, APIs, configs)
- Le lecteur sait ce qu'il cherche
Squelette
---
title: Reference [sujet]
description: "Liste complete des [elements]. [Nombre] entrees."
human_check: false
---
[1 phrase d'intro + nombre total d'elements]
## [Categorie 1]
| Nom | Description | Valeur par defaut |
|-----|-------------|-------------------|
| ... | ... | ... |
## [Categorie 2]
| ... | ... | ... |Regles specifiques a la reference
| Regle | Detail |
|---|---|
| Tables, pas prose | Le lecteur scanne, il ne lit pas |
| Exhaustif | Si un element manque, la reference est inutile |
| Ordre logique ou alphabetique | Pas d'ordre "comme ca vient" |
| Chaque entree a un exemple | Meme court |
| Miroir de l'architecture | La structure de la page reference doit reflecter la structure du produit/code qu'elle documente |
5. Cours (multi-pages)
Le lecteur veut maitriser un sujet. Progression logique, exercices, evaluation.
Quand l'utiliser
- Sujet complexe qui necessite plusieurs heures
- Le lecteur part de debutant et vise intermediaire/expert
- Besoin de progression structuree
Squelette
cours-[sujet]/
├── index.mdx # Vue d'ensemble + prerequis + plan par module
├── 01-[fondation].mdx # Concepts de base
├── 02-[pratique].mdx # Premiere mise en pratique
├── 03-[avance].mdx # Concepts avances
├── 04-[projet].mdx # Projet complet
└── 05-cheatsheet.mdx # Aide-memoire (fichier supplementaire, pas un module)La page index.mdx liste chaque module avec son temps estime et ses prerequis :
## Plan du cours
| Module | Titre | Temps | Prerequis |
|--------|-------|-------|-----------|
| 01 | [Fondation] | 15 min | Aucun |
| 02 | [Pratique] | 20 min | Module 01 |
| 03 | [Avance] | 25 min | Module 02 |
| 04 | [Projet] | 30 min | Modules 01-03 |Format exercice
Chaque module contient au minimum 1 exercice. La solution est toujours cachee dans un Accordion. Le resultat attendu est verifiable.
### Exercice : [titre]
**Consigne :** [ce que le lecteur doit faire]
**Resultat attendu :** [ce qu'il doit obtenir]
<Accordion title="Solution">
[code ou explication de la solution]
</Accordion>Regles specifiques au cours
| Regle | Detail |
|---|---|
| 1 module = 1 concept | Pas de module fourre-tout |
| Chaque module a un exercice | Apprendre en faisant, pas en lisant. Solution cachee (Accordion). Resultat verifiable |
| Progression lineaire | Le module 3 depend du module 2 |
| Index avec estimation de temps et prerequis | "Module 1 — 15 min — Aucun prerequis" |
| Cheatsheet = fichier supplementaire | Toujours un fichier XX-cheatsheet.mdx separe, pas le dernier module lui-meme |
| 3 a 8 modules par cours | Au-dela de 8 modules, decouper en 2 cours |
6. Troubleshooting
Le lecteur a un probleme. Il veut le fix, pas la theorie.
Squelette
---
title: Resoudre [categorie de problemes]
description: "Diagnostic et solutions pour les problemes courants de [sujet]."
human_check: false
---
## [Symptome 1]
**Cause :** [Explication en 1 phrase]
**Fix :**
\`\`\`bash
commande de fix
\`\`\`
## [Symptome 2]
[Meme pattern]Regles specifiques
| Regle | Detail |
|---|---|
| Titre = le symptome, pas la cause | Le lecteur cherche par symptome |
| Fix avant explication | Il veut la solution, pas le cours |
| 1 symptome = 1 section | Pas de melange |
7. Comparaison
Le lecteur doit choisir entre options.
Squelette
---
title: "[Option A] vs [Option B]"
description: "Comparaison de [A] et [B]. Criteres, forces, faiblesses, verdict."
human_check: false
---
## Resume
| Critere | [A] | [B] |
|---------|-----|-----|
| [Critere 1] | ... | ... |
| [Critere 2] | ... | ... |
## [Option A] en detail
[Forces, faiblesses, cas d'usage ideal]
## [Option B] en detail
[Forces, faiblesses, cas d'usage ideal]
## Verdict
Utilise [A] si [condition]. Utilise [B] si [condition].8. Fiche (reference courte)
1 page, 1 sujet, format standardise. Tu retrouves ce format dans les fiches agents d'Agent OS.
Squelette
---
title: [Nom de l'element]
description: "[Role en 1 phrase]."
human_check: false
---
**Role :** [1 phrase]
**Categorie :** [Couche/domaine]
## Declenchement
| Trigger | Frequence |
|---------|-----------|
| ... | ... |
## Sources
| Source | Donnees |
|--------|---------|
| ... | ... |
## Actions
[Liste des actions]
## Outputs
| Output | Destination | Format |
|--------|-------------|--------|
| ... | ... | ... |9. Changelog / Release Notes
Tu documentes ce qui a change. Le lecteur veut savoir quoi, pas pourquoi.
Squelette
---
title: Changelog
description: "Historique des modifications du systeme."
human_check: false
---
## [version] — YYYY-MM-DD
### Ajoute
- [Description courte]
### Modifie
- [Description courte]
### Supprime
- [Description courte]
### Corrige
- [Description courte]Regles specifiques
| Regle | Detail |
|---|---|
| Date au format ISO 8601 | YYYY-MM-DD, pas "mardi dernier" |
| 4 categories max | Ajoute, Modifie, Supprime, Corrige |
| 1 ligne par changement | Pas de paragraphes |
| Lien vers la page impactee | Chaque changement pointe vers la doc modifiee |
| Plus recent en haut | Ordre chronologique inverse |
10. Reference API
Le lecteur doit integrer une API. Il a besoin des endpoints, des parametres et des exemples request/response.
Quand l'utiliser
- Documentation d'une API REST ou GraphQL
- Le lecteur est un developpeur qui integre l'API
- Il a besoin d'exemples copiables pour chaque endpoint
Squelette
---
title: API [nom du service]
description: "Reference complete de l'API [nom]. [Nombre] endpoints."
human_check: false
---
## Base URL
\`\`\`text
https://api.example.com/v1
\`\`\`
## Authentification
\`\`\`bash
curl -H "Authorization: Bearer YOUR_TOKEN" https://api.example.com/v1/resource
\`\`\`
## [Domaine 1]
### [Methode] /endpoint
[1 phrase de description]
**Parametres :**
| Nom | Type | Requis | Description | Defaut |
|-----|------|--------|-------------|--------|
| id | string | Oui | Identifiant unique | — |
| limit | integer | Non | Nombre de resultats | 20 |
**Exemple request :**
\`\`\`bash
curl -X GET "https://api.example.com/v1/endpoint?limit=10" \
-H "Authorization: Bearer YOUR_TOKEN"
\`\`\`
**Exemple response :**
\`\`\`json
{
"data": [],
"meta": { "total": 0 }
}
\`\`\`
**Codes erreur :**
| Code | Description |
|------|-------------|
| 200 | Succes |
| 401 | Token invalide ou manquant |
| 404 | Ressource introuvable |
| 429 | Rate limit depasse |Regles specifiques a la reference API
| Regle | Detail |
|---|---|
| Ordre CRUD | Lister (GET all), Lire (GET one), Creer (POST), Modifier (PUT/PATCH), Supprimer (DELETE) |
| Max 10 endpoints par page | Au-dela, split par domaine fonctionnel |
| Chaque endpoint a un exemple request + response | Pas d'endpoint sans exemple |
| Parametres en table | Toujours les 5 colonnes : Nom, Type, Requis, Description, Defaut |
| Codes erreur par endpoint | Pas de table d'erreurs globale uniquement |
Matrice format x situation
| Situation | Format | Exemple |
|---|---|---|
| Premier contact avec un outil | Tutoriel | "Creer ton premier agent" |
| Faire une tache precise | Guide pratique | "Deployer sur Cloudflare" |
| Comprendre une decision | Explication | "Pourquoi un CEO unique" |
| Chercher un parametre | Reference | "Liste des MCPs" |
| Apprendre un domaine complet | Cours | "Maitriser le trading auto" |
| Resoudre un bug | Troubleshooting | "Le CEO ne repond pas" |
| Choisir entre options | Comparaison | "Haiku vs Sonnet vs Opus" |
| Documenter un composant | Fiche | "AG-38 Analytics" |
| Documenter un changement | Changelog | "v1.2 — 2026-04-03" |
| Documenter une API | Reference API | "API Agents — 12 endpoints" |
Lecture liee
- Regles de redaction — les 38 regles de style
- Structurer un contenu — decouper, ordonner, versionner, deprecier
- Review et iteration — checklist, scoring, boucle qualite