Modèle — Issue de documentation

Modèle à utiliser pour créer une issue de documentation couvrant l'existant d'un projet. Copier le contenu de la section Modèle et l'adapter au contexte.

---

Modèle

## Contexte

Le projet dispose de [décrire l'état actuel : infrastructure, fonctionnalités, etc.],
mais la documentation est [décrire l'état de la doc : absente, partielle, obsolète].

L'objectif est de **documenter ce qui existe aujourd'hui** dans le projet, en suivant
le [guide de rédaction documentaire](lien vers la norme).

## Périmètre

Documenter les composants **Done** ou **In Review** du sprint en cours :

| Composant | Source (code) | Source (issue/PR) |
|-----------|--------------|-------------------|
| [Nom composant 1] | `chemin/vers/fichiers` | #XX, #YY |
| [Nom composant 2] | `chemin/vers/fichiers` | #ZZ |
| [Nom composant 3] | `chemin/vers/fichiers` | commit `abc1234` |

## À faire

### Structure MkDocs

- [ ] Mettre à jour `mkdocs.yml` : ajouter les sections manquantes dans la `nav`
- [ ] Compléter `docs/index.md` avec une grille de navigation vers les sections

### Pages à rédiger

#### Démarrage (type : Tutoriel)
- [ ] `docs/demarrage/[nom].md` — [Description : quoi, pour qui]

#### Learning (type : Explication)
- [ ] `docs/learning/[nom].md` — [Description : concept expliqué, angle choisi]

#### Référence
- [ ] `docs/reference/[nom].md` — [Description : quoi, niveau de détail]

#### Exploitation (type : Guide pratique)
- [ ] `docs/exploitation/[nom].md` — [Description : procédure, prérequis]

### Compléments

- [ ] Créer `Docs/Includes/glossary.md` avec les termes récurrents
- [ ] Vérifier avec `mkdocs serve` que toutes les pages rendent correctement

## Méthode

Pour chaque page :
1. **Croiser** le code source (réalité terrain) avec les issues/PRs GitHub (intention et contexte)
2. **Respecter** la norme de rédaction : H1 + blockquote intro + séparateurs `---` entre H2, max 300 lignes
3. **Utiliser** les fonctionnalités MkDocs Material (admonitions, tabs, Mermaid, blocs de code avec titre+langage)

## Critères d'acceptance

- [ ] Toutes les pages ci-dessus existent et sont navigables dans MkDocs
- [ ] Chaque page respecte le guide de rédaction documentaire
- [ ] `mkdocs serve` affiche la documentation sans erreur ni warning
- [ ] Un nouveau développeur peut [objectif concret : cloner et builder / configurer / déployer] en suivant uniquement la doc

---

Notes d'utilisation

Adapter le périmètre

Le tableau de périmètre est la pièce maîtresse. Pour le remplir correctement :

1. Lister les composants identifiés par l'exploration codebase
2. Pour chaque composant, trouver l'issue ou PR correspondante
3. Ne retenir que ce qui est Done ou In Review — pas le Backlog

Adapter les types de pages

Tous les types ne sont pas toujours nécessaires. Supprimer les sections vides :

Situation	Types à privilégier
Projet en phase infrastructure	Démarrage + Référence
Projet avec concepts complexes	Learning + Référence
Projet en production	Exploitation + Référence
Projet complet	Les 4 types

Nommer les fichiers

Suivre les conventions du projet :

• Minuscules, tirets, pas d'accents : build-system.md
• Nom descriptif et court : installation.md, pas guide-complet-installation-nix.md
• L'ordre est défini dans mkdocs.yml, pas par le nom du fichier