Il y a des outils qu'on installe, qu'on teste une semaine et qu'on oublie. Claude Code n'est pas de ceux-là. Après six mois d'utilisation sur des projets clients en Next.js, TypeScript et MDX, mon workflow ressemble à quelque chose que je n'aurais pas reconnu début 2025.
Ce n'est pas un article de hype. Je vais vous montrer exactement comment j'organise mon travail, où Claude Code est vraiment utile, et les endroits où il vaut mieux ne pas lui faire confiance.
Avant de commencer : Claude Code n'est pas un outil qui code à votre place. Si c'est ce que vous cherchez, vous allez être déçu — et votre codebase aussi.
C'est un outil qui amplifie ce que vous savez déjà faire. Si vous ne comprenez pas ce qu'il génère, vous ne pourrez pas le corriger quand il se trompe. Et il se trompe.
Quand j'ouvre un nouveau ticket — que ce soit une feature, un bug ou une refacto — ma première action est d'ouvrir Claude Code dans le terminal et de lui coller le contexte :
J'ai ce ticket à traiter sur un projet Next.js 16 avec App Router :
[contenu du ticket]
Avant qu'on commence à coder, explique-moi :
1. Quels fichiers sont probablement concernés
2. Les risques ou points d'attention
3. L'approche que tu suggères en 3 étapes max
Je ne lui demande pas de coder immédiatement. Je veux d'abord voir s'il a bien compris le problème. Neuf fois sur dix, cette étape me fait gagner du temps en révélant des ambiguïtés que j'aurais découvertes au milieu de l'implémentation.
Claude Code peut lire votre codebase directement. Sur un projet avec lequel il n'est pas encore familier, je commence par :
Lis les fichiers suivants et dis-moi comment ce système fonctionne :
- app/blog/[slug]/page.tsx
- lib/mdx.ts
- content/blog/ (structure)
Ce qui m'a surpris : il fait des connexions que je rate parfois. Sur un bug récent lié à la génération du sitemap, il a remarqué que deux fichiers utilisaient des sources de données différentes pour lister les articles — l'un lisait le système de fichiers, l'autre une constante exportée manuellement. C'était le bug.
C'est là que beaucoup de gens se plantent avec les outils IA : ils demandent trop d'un coup.
Je ne dis jamais "implémente toute la feature". Je découpe :
On va implémenter ça en 3 étapes.
Étape 1 seulement : crée le composant <ArticleCard> avec ces props.
Ne touche à rien d'autre pour l'instant.
Après chaque étape, je lis le diff. Je lis toujours le diff. C'est non-négociable. Les erreurs de Claude Code sont rarement catastrophiques, mais elles sont subtiles : un use client ajouté là où il ne devrait pas être, une dépendance importée depuis le mauvais chemin, un type any glissé pour passer la compilation.
Une fois l'implémentation terminée, j'ai pris l'habitude de faire une passe de revue assistée :
Voici le diff de ce que tu viens d'écrire.
Joue le rôle d'un relecteur senior qui n'a pas écrit ce code.
Qu'est-ce qui te pose question ? Qu'est-ce que tu ferais différemment ?
Les résultats sont souvent plus utiles que ce qu'on imagine. Il a plusieurs fois identifié des cas limites que j'avais oubliés — notamment des comportements sur les Server Components quand les données fetched sont undefined plutôt que null.
Claude Code construit une mémoire de votre projet au fil des sessions. Il retient les conventions que vous lui avez indiquées, les patterns que vous utilisez, les fichiers importants. Après quelques semaines sur un projet, il n'a plus besoin que vous lui réexpliquiez l'architecture à chaque session.
/voice — pour les moments où taper est trop lentLe mode vocal (maintenir espace) est moins gadget que prévu. Quand j'explore un problème à voix haute — ce que je faisais déjà tout seul — avoir quelque chose qui répond aide à structurer la pensée. C'est particulièrement utile pour déboguer des problèmes d'état complexes.
Sur les tâches longues — migrer une vingtaine de composants vers un nouveau pattern, par exemple — Claude Code peut maintenant lancer plusieurs instances en parallèle. Ce qui prenait 40 minutes séquentiellement peut se faire en 12 minutes. Je reste là pour valider chaque lot, mais la mécanique d'exécution est déléguée.
Quelques règles que j'ai établies après des erreurs :
Les décisions d'architecture. Claude Code suggère des structures, mais c'est moi qui décide. Il optimise pour ce qu'il a vu dans son entraînement — pas pour les contraintes spécifiques de votre projet ou de votre client.
Les migrations de base de données. Trop de risque, trop de contexte spécifique. Je rédige ces scripts moi-même, point.
La sécurité. Validation des inputs, gestion des tokens, politiques CORS — je relis ces parties ligne par ligne. Pas parce que Claude Code est mauvais là-dessus, mais parce que c'est mon nom qui est engagé quand ça part en production.
Le CSS fin. Il génère du CSS fonctionnel, mais il n'a pas votre œil. Les micro-ajustements d'espacement, les animations, les détails typographiques — ça reste à la main.
Sur les trois derniers mois, j'ai mesuré le temps passé sur les phases de dev de mes projets. Les tâches répétitives et bien définies (créer des variantes de composants, écrire des tests unitaires, migrer des patterns) sont passées de 40% de mon temps à environ 15%.
Ce temps, je le réinvestis dans ce que les outils IA font mal : comprendre le vrai besoin du client, prendre des décisions d'architecture, et faire du travail de design qui nécessite un jugement humain.
Est-ce que Claude Code me rend meilleur développeur ? Non. Il me rend plus rapide sur les parties que je maîtrise déjà.
La différence est importante. Un outil IA amplifie votre niveau, il ne le remplace pas. Si vous ne savez pas ce qu'est un Server Component, Claude Code va vous en générer un — et vous ne saurez pas pourquoi il pose problème à la première rehydratation.
Apprenez d'abord. Déléguez ensuite.
Vous travaillez sur un projet Next.js et vous cherchez à optimiser votre workflow de développement ? Parlons-en — je consulte aussi des équipes qui veulent intégrer ces outils de manière réaliste.
Besoin d'aide ?
