Reprise de developpement

Cette section explique comment utiliser la documentation pour reprendre le projet.

Principe

Chaque module doit repondre aux questions suivantes :

• A quoi sert le module ?
• Qui l'utilise ?
• Quels fichiers lire en premier ?
• Quelles routes, vues, modeles, services et tables sont impliques ?
• Quels flux metiers sont critiques ?
• Quels bugs ou risques sont connus ?
• Comment verifier qu'une modification n'a rien casse ?

Niveau de detail attendu

Le niveau de detail vise est volontairement operationnel :

• noms de fichiers ;
• noms de classes et methodes importantes ;
• tables et colonnes structurantes ;
• routes et endpoints ;
• commandes ;
• scenarios de test ;
• decisions techniques.

Ce qui est exclu de la documentation publique :

• valeurs de secrets ;
• tokens ou cles API ;
• mots de passe ;
• donnees reelles de clients ;
• captures contenant des donnees personnelles ;
• URLs d'administration non publiques ;
• details d'infrastructure qui faciliteraient une attaque.

Processus de documentation par module

1. Identifier les fichiers structurants du module dans le code actuel et l'historique Git.
2. Regrouper les fichiers par module fonctionnel.
3. Lire le code actuel, pas seulement l'historique.
4. Decrire les flux metiers et techniques.
5. Documenter les risques et bugs connus.
6. Ajouter les tests et commandes de verification.
7. Relire la page avec le filtre "public mais utile".