Reprendre un projet existant avec Claude Code sans tout casser

Sur un projet existant, le premier risque n’est pas de coder trop lentement. C’est de modifier quelque chose dont on n’a pas compris le rôle. Claude Code peut aider à explorer une application, mais cette exploration doit précéder les changements.

Reprendre un projet commence par établir ce qui fonctionne, ce qui est fragile et ce qu’il ne faut pas toucher. L’IA intervient dans cette méthode ; elle ne la remplace pas.

Établir un état de départ

Vérifiez la version du projet, les modifications non enregistrées, les environnements disponibles et la procédure de lancement. Conservez les changements des autres intervenants. Un nettoyage automatique du dossier peut détruire précisément le travail qu’il fallait préserver.

Identifiez ensuite les points d’entrée, le stockage des données, les services externes et les principaux parcours utilisateurs. Notez séparément les faits observés et les hypothèses.

Si les tests échouent déjà avant votre intervention, consignez-le. Sinon, il sera difficile de distinguer une régression d’un problème antérieur.

Demander une lecture avant une solution

Un premier brief utile peut être :

Analyse le parcours de création d’un dossier sans modifier les fichiers. Identifie les composants concernés, les validations et les dépendances. Signale ce qui reste incertain et propose les vérifications nécessaires.

Commencez par un plan avant d’autoriser les modifications. Utilisez les permissions adaptées et vérifiez ce que l’outil est autorisé à exécuter. Une consigne écrite seule ne remplace pas la limitation des accès.

Évitez de fournir des secrets ou des données clients réelles lorsque des exemples anonymisés suffisent. Les actions sur une base de production doivent rester hors du périmètre d’exploration.

Choisir une première modification limitée

Dans un exemple fictif, le problème est un champ obligatoire qui n’est pas contrôlé avant l’enregistrement. Le premier changement porte sur cette validation et ses tests, pas sur une refonte de toute l’architecture.

Demandez un plan qui précise les fichiers touchés, les comportements conservés et la méthode de vérification. Les propositions « nettoyer tout le module » méritent une justification distincte du correctif demandé.

Une petite livraison permet de comprendre le projet et de tester la qualité du travail sans multiplier les inconnues.

Vérifier ce qui a réellement changé

Relisez les différences, pas seulement le résumé de l’assistant. Vérifiez les suppressions, les changements de configuration et les dépendances ajoutées.

Testez le cas attendu, le cas refusé et un parcours voisin qui doit rester identique. Pour une interface, ajoutez un contrôle visuel sur mobile. Pour une API, vérifiez les réponses et les effets sur les données.

Définissez ce qu’une réussite signifie pour votre activité : aucun doublon, une permission respectée ou une commande préservée, par exemple. Ces critères doivent pouvoir être vérifiés après chaque modification.

Préparer la transmission

Un correctif utile doit pouvoir être compris après la session. Conservez sa raison, ses limites, les tests exécutés et les points non vérifiés. Une phrase « tout fonctionne » n’est pas une preuve de livraison.

Cette approche évite d’utiliser l’IA comme un accélérateur de dette technique. Pour aller plus loin, consultez le passage du besoin au prototype, le guide existant Claude Code et Linux et l’accompagnement en développement.