Tutoriel Claude Code série 4 : Quels sont les cas d'utilisation de Claude Code ?

Cas d'utilisation typiques

Je classe les cas d'utilisation en quatre catégories, par ordre de fréquence décroissante.

Première catégorie : Comprendre le code

C'est probablement la plus utilisée. Lorsque vous reprenez le projet de quelqu'un d'autre, examinez un module ancien ou ouvrez un référentiel sans documentation, posez-lui directement la question.

Concrètement :

claude "À quoi sert ce projet ? Où est le point d'entrée ?" — Il lit package.json, la structure des répertoires, les fichiers clés et fournit un résumé.
Ouvrez une fonction, demandez-lui d'expliquer la logique, de décrire le flux (avec du texte).
Demandez-lui de retracer le chemin complet d'une requête API, du front-end à la base de données.

Ici, ce qu'il fait, c'est essentiellement faire le travail ingrat de la lecture du code. Vous n'avez pas besoin de chercher vous-même longuement avec grep puis de reconstituer le puzzle mentalement. Il clarifie le chemin, et vous prenez la décision.

Ce que cette catégorie remplace : la recherche manuelle, la prise de notes, le traçage manuel des appels dans la base de code.

Deuxième catégorie : Écrire et modifier du code

C'est la catégorie la plus discutée, mais pas la plus utilisée. Les scénarios d'écriture de code sont généralement les suivants :

Ajouter une nouvelle fonctionnalité : "Ajoute une interface pour modifier l'e-mail dans le module user, avec validation du format de l'e-mail et des tests unitaires."
Refactorisation interfichiers : "Remplace tous les moment() par dayjs() dans ces trois fichiers, sans modifier aucune autre logique."
Migration et mise à niveau : "Transforme ce composant Vue 2 en écriture Composition API Vue 3."

Le code généré n'est pas forcément correct du premier coup, mais il peut effectuer toutes les modifications interfichiers en une seule fois, et vous pouvez comparer fichier par fichier (diff) et accepter ou rejeter individuellement.

Ce que cette catégorie remplace : l'écriture manuelle de code répétitif, la recherche et le remplacement manuels de références interfichiers.

Troisième catégorie : Débogage et correction

Quand un bug apparaît, le flux de travail habituel est : regarder l'erreur, localiser le fichier, deviner la cause, essayer une correction, si ça ne marche pas, revenir en arrière. Claude Code peut directement recevoir toute la stack d'erreur et la localiser en combinant avec le code du projet.

Exemples typiques :

Donnez-lui la sortie d'un test échoué, il lira le code concerné, proposera une modification, puis relancera le test pour vérifier.
En cas d'erreur CI, collez le journal, laissez-le corriger, puis exécutez git diff pour confirmer les changements.

Ici, son rôle est plutôt celui d'un « premier inspecteur ». C'est vous qui passez du temps à réfléchir, mais c'est lui qui parcourt les fichiers, compare les différences et exécute les commandes de vérification.

Ce que cette catégorie remplace : l'exécution répétée de tests, la lecture des journaux d'erreurs, la comparaison manuelle des différences de code.

Quatrième catégorie : Automatisation diverse

Cette catégorie est la moins visible, mais cumulée, elle fait gagner le plus de temps.

Exemples :

Rédiger des messages de commit Git : claude "Écris un message de commit au format Conventional Commits basé sur le diff Git actuel"
Générer une description de PR : Demandez-lui de comparer la branche actuelle avec main et de générer un résumé des modifications et des explications de test.
Rédiger des notes de version : Faites lire à Claude Code l'historique des commits de la semaine dernière pour générer un CHANGELOG.
Répondre aux problèmes d'environnement : "J'ai une erreur lors de l'installation de cette dépendance, aide-moi à analyser la sortie du terminal et à trouver la cause."

Le point commun de ces tâches : elles ne sont pas complexes, mais sont fastidieuses. Les faire soi-même nécessite de changer de fenêtre, de taper beaucoup de texte. En les confiant à Claude Code, c'est réglé en quelques secondes.

Ce que cette catégorie remplace : l'édition manuelle de texte, la rédaction de documentation standardisée, la recherche manuelle de problèmes de configuration d'environnement.

Une « carte »

En intégrant ces quatre catégories dans le flux de travail quotidien, voici à quoi cela ressemble :

Obtenir un projet inconnu
    │
    ▼
[Comprendre le code] ─── Comprendre la structure, le point d'entrée, la logique clé
    │
    ▼
Commencer à écrire une nouvelle fonctionnalité ou modifier un module
    │
    ▼
[Écrire/Modifier le code] ─── Générer l'implémentation, refactorisation interfichiers
    │
    ▼
Exécuter les tests, un bug apparaît
    │
    ▼
[Déboguer et corriger] ─── Analyser l'erreur, localiser, corriger, relancer
    │
    ▼
Préparer le commit
    │
    ▼
[Automatisation diverse] ─── Écrire le commit, la description de PR, les notes de version
    │
    ▼
Committer, terminer

Vous n'êtes pas obligé de l'utiliser dans les quatre domaines. Certaines équipes ne l'utilisent que pour comprendre le code, d'autres seulement pour écrire des tests et envoyer des PR. Choisissez le domaine qui vous pose le plus de problèmes et commencez par là.

Deux critères utiles

Si vous n'êtes pas sûr de devoir confier une tâche à Claude Code, posez-vous deux questions :

1. Cette tâche est-elle plus « mécanique » que « créative » ?

Modifier cent références, formater une sortie, générer du code passe-partout — ces choses faites à la main sont chronophages, mais vous avez déjà l'idée. Convient de les lui confier.

2. Le « coût de vérification » de cette tâche est-il élevé ?

Si une modification nécessite de naviguer, exécuter des tests, consulter des journaux à plusieurs reprises pour être confirmée, le tâtonnement manuel est lent. Claude Code peut réaliser lui-même le cycle « modifier-exécuter-vérifier-modifier à nouveau », ce qui vous soulage considérablement.