Claude Code en pratique : les 10 usages qui changent le quotidien

Je développe seul mon SaaS crmcoaching (CRM pour coachs professionnels) depuis le premier jour avec Claude Code. Stack : NestJS 11, Prisma 7, PostgreSQL, Zod 4, hexagonale ; front Next.js 16, React 19, shadcn/ui. Environ 47 use cases, une dizaine de bounded contexts. Claude n'est pas un compagnon d'auto-complétion dans ce projet : c'est un vrai partenaire de développement.

La réaction initiale de beaucoup de développeurs quand ils découvrent Claude Code est prévisible : "C'est bien pour générer du boilerplate." Deux mois plus tard, après avoir vraiment exploré les usages avancés, les chiffres de productivité personnelle changent radicalement.

La plupart des développeurs exploitent 20% de Claude. Voici les 10 usages qui changent vraiment la vitesse et la qualité du dev au quotidien.

Les études sur les assistants IA montrent que les développeurs complètent les tâches de codage 40 à 55% plus vite en moyenne. Ce chiffre cache une grande variance : ceux qui utilisent l'outil uniquement pour l'auto-complétion gagnent 10 à 15%. Ceux qui maîtrisent les usages décrits ici atteignent le haut de la fourchette.

Avant de commencer : la configuration qui fait la différence

Avant les usages, quelques minutes de configuration qui changent la qualité des réponses.

Le fichier CLAUDE.md : c'est le point de départ. Dans ce fichier, je documente les conventions du projet, l'architecture hexagonale, les bounded contexts, les patterns préférés, et ce que Claude ne doit pas faire. Claude lit ce fichier comme contexte pour chaque session dans le dépôt. C'est l'équivalent d'un onboarding permanent : une fois bien rédigé, je n'ai plus à ré-expliquer le contexte à chaque session.

# CLAUDE.md (extrait)
## Architecture
Apps/api : NestJS 11, Prisma 7, hexagonale (domain / application / infrastructure / interface)
Apps/web : Next.js 16, React 19, shadcn/ui, TanStack Query

## Règles
- Pas de logique métier dans les contrôleurs
- Les use cases retournent des DTOs typés via Zod (packages/shared)
- Tests obligatoires : unitaires (Vitest) + intégration pour chaque use case

L'ouverture des fichiers de contexte : Claude utilise les fichiers mentionnés dans la conversation comme contexte. Ouvrir ou citer les interfaces de port, les use cases voisins, les schemas Zod avant de demander une implémentation produit des suggestions significativement plus précises et cohérentes avec l'existant.

Les commentaires comme instructions : un commentaire en tête de fichier ou de fonction qui décrit l'intention (// Ce use case doit...) produit des suggestions bien meilleures que de laisser Claude deviner.

Les 10 usages à adopter

Usage 1 : Générer des tests Vitest

Le meilleur retour sur investissement, de loin. Je décris le scénario, je fournis le use case et les types en contexte, Claude génère le test complet avec les mocks appropriés.

// tests/unit/application/use-cases/create-client.use-case.spec.ts

// Scénarios à couvrir :
// - should create a client and return a ClientDto
// - should throw ConflictException when email already exists
// - should throw NotFoundException when coachId is invalid
// - should emit ClientCreated domain event

Claude génère les 4 tests Vitest avec les mocks de repository et les assertions sur le DTO retourné, en respectant les patterns hexagonaux du projet. Gain estimé : 60 à 70% sur l'écriture des tests.

Ce que j'apprécie surtout : Claude lit le vrai use case et génère les tests en cohérence avec les branches réelles du code, pas avec des scénarios génériques.

Usage 2 : Expliquer du code complexe

Dans Claude Code, je colle un bloc de code et je demande : Explique ce que fait ce use case en 3 phrases, en incluant les cas limites qui pourraient poser problème.

Redoutable sur des migrations Prisma complexes ou des use cases écrits il y a trois mois. Plus rapide que de relire ligne par ligne, surtout quand je reprends un domaine que je n'ai pas touché depuis plusieurs semaines.

Usage 3 : Générer les use cases NestJS

Je décris le comportement attendu, je fournis l'interface de port et le schema Zod, Claude génère le use case complet en respectant l'architecture hexagonale du projet :

// Générer un use case ConvertLeadToClientUseCase qui :
// - reçoit un ConvertLeadToClientDto (leadId: string, coachId: string)
// - vérifie que le lead existe et appartient au coach (LeadRepository)
// - crée un client depuis les données du lead (ClientRepository)
// - émet un événement domaine LeadConverted
// - retourne un ClientDto validé par le schema Zod shared/schemas/client.schema.ts

Le résultat nécessite une relecture et des ajustements, mais 80% du travail mécanique est fait. Ce qui aurait pris une heure s'écrit en 10 minutes.

Usage 4 : Refactoriser par pattern ou par règle d'architecture

Je sélectionne un bloc de code et je demande : Refactorise ce use case pour extraire la logique de validation dans un Value Object. Le use case ne doit plus contenir de logique métier inline.

Claude comprend les patterns hexagonaux, les Value Objects, les domain events. Il peut appliquer des refactorings structurés en respectant les contraintes architecturales que je lui ai décrites dans CLAUDE.md. L'auto-complétion seule ne ferait pas ce travail.

Usage 5 : Générer et valider des schemas Zod / DTOs

Je décris la structure attendue, Claude génère le schema Zod et le DTO correspondant pour packages/shared :

// Schema Zod pour CreateSlotHoldDto
// - clientId: UUID obligatoire
// - offreId: UUID obligatoire
// - startsAt: ISO datetime, doit être dans le futur
// - durationMinutes: entier, entre 30 et 240
// - notes: string optionnel, max 500 caractères

Claude génère le schema avec les messages d'erreur en français, le type inféré, et l'export. Il propose aussi le schema de réponse si je lui précise le contexte.

Usage 6 : Identifier les edge cases

Dans Claude Code : Quels sont les edge cases non gérés dans ce use case ? Propose le code pour les couvrir.

Claude identifie fréquemment des cas limites que j'oublie en première passe : nulls, conflits de concurrence sur les slots, dépassement de quota, états transitoires lors d'un checkout Stripe. Cette étape avant la PR réduit les allers-retours en review de 20 à 30%. Moins de corrections sur des cas non couverts, plus de concentration sur la logique métier.

Usage 7 : Documentation inline et JSDoc

Je positionne le curseur au-dessus d'un use case ou d'un port et je demande à Claude de générer la documentation. Claude génère la JSDoc avec les paramètres, la valeur de retour, les exceptions levées, et une description basée sur le code réel.

/**
 * Converts an existing lead into a client record.
 *
 * @param dto - Lead identifier and coach identifier
 * @returns The newly created ClientDto
 * @throws NotFoundException if the lead does not exist or does not belong to the coach
 * @throws ConflictException if a client with the same email already exists
 */
async execute(dto: ConvertLeadToClientDto): Promise<ClientDto> { ... }

Mon habitude : générer cette documentation systématiquement sur tous les use cases et ports publics, et en faire un point de vérification à la PR.

Usage 8 : Générer des migrations Prisma

Je décris le changement de schéma en langage naturel, Claude génère le bloc Prisma schema correspondant et la commande de migration :

// Ajouter au modèle SlotHold :
// - un champ expiresAt DateTime non-nullable (default: maintenant + 15 minutes)
// - un champ status enum SlotHoldStatus (PENDING, CONFIRMED, EXPIRED, RELEASED)
// - un index sur (clientId, status) pour accélérer les requêtes de nettoyage

Claude génère le bloc model mis à jour, l'enum, l'index, et la commande prisma migrate dev --name add-slot-hold-status. Je relis et teste systématiquement avant exécution, mais la génération initiale est fiable sur les cas courants.

Usage 9 : Revue de sécurité locale

Dans Claude Code : Analyse ce contrôleur pour des vulnérabilités courantes : injection, autorisation manquante, exposition de données sensibles, mauvaise gestion des erreurs.

Claude identifie les patterns problématiques avec une précision acceptable : guard manquant sur une route, champ sensible retourné dans le DTO, validation insuffisante d'un paramètre. Ce n'est pas un outil SAST, mais c'est un premier filtre utile avant la review formelle. Sur crmcoaching, ça m'a permis de détecter deux routes sans guard avant qu'elles ne partent en PR.

Usage 10 : Générer des factories de données de test

// Générer une factory TypeScript pour ClientEntity avec :
// - des noms français réalistes (prénom + nom de famille)
// - des emails valides au format prenom.nom@domaine.fr
// - un coachId UUID aléatoire par défaut, surchargeable
// - un status parmi ClientStatus enum (ACTIVE majoritaire, quelques ARCHIVED)
// - une date createdAt dans les 12 derniers mois
// Pattern : factory function avec overrides partiels (Partial<ClientEntity>)

Claude génère la factory complète avec les overrides partiels. Les données réalistes améliorent la qualité des tests d'intégration Vitest et des démonstrations. La différence avec client1@test.com est visible immédiatement dans la qualité des bugs trouvés.

Comment mesurer l'impact réel sur la productivité

Le ressenti ne suffit pas. Trois métriques à suivre, sur une fenêtre de 4 semaines.

1. Cycle time des stories : temps moyen entre le start et la PR mergée. Objectif : réduction de 15 à 30% sur les stories d'implémentation.

2. Temps de review : nombre de commentaires liés au style, aux edge cases, à la documentation. Objectif : réduction de 20 à 35%.

3. Couverture de tests sur les nouvelles stories : les stories développées avec Claude ont-elles une meilleure couverture ? Objectif : amélioration de 10 à 20%.

Sur crmcoaching, l'introduction structurée de ces 10 usages a produit une accélération mesurable du rythme de livraison, notamment sur les use cases répétitifs (génération de tests, schemas Zod, migrations). Trois domaines qui me prenaient plusieurs heures se gèrent maintenant en moins d'une heure avec Claude comme partenaire. Bien utilisée, l'IA joue le rôle d'un senior disponible en permanence pour les tâches mécaniques, ce qui libère le temps de concentration pour les décisions d'architecture.

FAQ sur Claude Code