Accueil / Gestes courants

Prendre en main, documenter et migrer une base de code

Sur un dépôt inconnu, une vue d'ensemble demandée avant toute modification oriente les questions suivantes, et la commande /init lit réellement le contenu du projet pour écrire un premier CLAUDE.md plutôt que de partir d'une page blanche.

Sur un dépôt inconnu, ouvrir le premier fichier venu n'apprend presque rien sur la manière dont les pièces s'assemblent. Une question large, du type donne moi un aperçu de ce dépôt, oriente utilement la suite : Claude Code repère les points d'entrée, les dépendances déclarées et l'organisation des dossiers avant de descendre dans le détail d'une fonction précise.

Cartographier avant de toucher au code

La réponse à cette première question sert de carte pour choisir la question suivante. Demander tout de suite comment fonctionne un module isolé, sans être passé par cette vue d'ensemble, revient à corriger une pièce sans savoir à quoi elle sert dans la machine complète. Sur un projet volumineux, deux ou trois questions successives, chacune plus étroite que la précédente, remplacent une exploration fichier par fichier qui prendrait des heures.

Écrire une première mémoire avec /init

La commande /init lit réellement le contenu du dépôt pour produire un premier CLAUDE.md : commandes de build et de test détectées, conventions visibles dans le code existant, structure des dossiers principaux. Si un CLAUDE.md existe déjà, /init ne l'écrase pas, elle propose des améliorations à partir de ce qui est déjà écrit. Le fichier généré reste un premier jet : il se relit et se coupe pour ne garder que ce qui est court et vérifié, comme le détaille CLAUDE.md, la mémoire du projet.

mkdir -p demo-migration/src && cd demo-migration
git init -q
printf 'def total(a, b):\n    return a + b\n' > src/calcul.py
printf 'lodash==4.17.21\n' > requirements.txt
git add -A && git commit -q -m "première version"
claude
> donne moi un aperçu de ce dépôt, puis génère un CLAUDE.md avec /init

Traiter la documentation comme du code source

Une documentation périmée coûte plus cher qu'une absence de documentation, parce qu'elle induit en erreur au lieu de simplement ne rien dire. Demander une génération en précisant le style attendu, JSDoc ou docstrings selon le langage du projet, évite un format que personne n'utilise ensuite dans l'équipe. Le même principe vaut pour une mise à jour de dépendance : demander la liste des changements incompatibles avant de modifier le fichier de verrouillage donne une base de décision, même si aucune commande dédiée ne produit cette liste automatiquement. C'est une formulation de la demande, pas un outil séparé.

Le geste se conclut toujours par une relecture du diff final produit par la migration ou par la génération de documentation, jamais par une confiance accordée au seul message de succès affiché en fin de tâche.