Un dev senior a posté ses tips Claude Code après six mois d'usage quotidien. J'ai lu, j'ai souri, et j'ai réalisé : moi aussi je l'utilise tous les jours depuis six mois. Sauf que je n'avais jamais ouvert un terminal avant lui. Je suis entrepreneur, pas codeur. Voici le bilan chiffré, les sept leçons que je retiens, le projet que j'ai bouclé ce week-end, mes trois plus belles boulettes, et à quoi ressemble ma journée type.
Avant de te servir des leçons, je te pose les chiffres. Tout est mesurable, tout est dans mon dossier ~/Projets/ ou sur GitHub. Aucune extrapolation, aucune projection. Juste ce qui est sorti des claviers et qui tourne aujourd'hui.
git log --since="6 months ago" --oneline | wc -l sur chaque repo, puis additionné. Avant Claude Code, je n'avais jamais commit de ma vie. Aujourd'hui c'est devenu un réflexe à chaque session.Pour rendre le truc moins abstrait, voilà le même quotidien chiffré dans les deux configurations.
| Tâche | Avant Claude Code | Aujourd'hui |
|---|---|---|
| Publier un article complet | 3 h écriture + 1 h mise en ligne | 45 min + 5 min |
| Déclinaison LinkedIn / X | 1 h par publication | 5 min (skill dédié) |
| Audit SEO d'une page | 25 min à la main avec Claude.ai | 4 min (skill activé) |
| Sortir un pilote podcast 18 min | Inenvisageable seul | ~22 h de travail actif |
| Coût mensuel total | 0 € (rien ne sortait) | ~340 € outils, 0 € agence |
| Projets vivants en parallèle | 0 | 11 |
Les devs seniors mesurent leur productivité en « lignes de code par jour » ou en « pull requests mergées ». Moi je la mesure en projets vivants qui tournent. Le critère n'est pas le même, donc le ressenti d'efficacité non plus. C'est ce qui rend Claude Code radicalement différent selon d'où tu pars.
Avant les leçons, un détour rapide. Il y a deux chemins pour arriver à Claude Code, et selon ton chemin, tu n'utilises pas du tout le même outil.
Il vient de son éditeur de code habituel · VS Code, Cursor, Zed (les logiciels où les devs écrivent leur code). Il a déjà un workflow qui fonctionne (sa façon d'enchaîner les étapes du travail). Il a quinze ans d'habitudes installées. Il cherche à automatiser ce qu'il fait déjà, gagner en vitesse, industrialiser. Il parle naturellement de tests, linting, refactoring. Il juge la qualité du code que Claude produit.
Claude Code arrive dans sa vie comme un collègue ingénieur. Il l'utilise en pair programming (à deux sur le même clavier, l'un code, l'autre relit). Il corrige ses suggestions, il désactive ce qui ne marche pas chez lui, il cherche à optimiser chaque seconde.
Moi, j'arrive d'ailleurs. Je veux publier un site, envoyer une newsletter, avoir un tableau de bord pour suivre mes idées d'articles. Je ne pars pas d'un éditeur. Je pars d'un besoin.
Je n'ai pas d'avis sur la qualité du code. Je valide le résultat · est-ce que le site est en ligne, est-ce que le formulaire marche, est-ce que l'email arrive. Le reste, je fais confiance à Claude.
Claude Code arrive dans ma vie comme un stagiaire qui sait déjà tout, qui ne demande pas de pause déjeuner et qui ne se plaint jamais.
Les devs seniors produisent du code robuste parce qu'ils savent ce qui casse en production. Moi non. Je livre des projets personnels et des outils pour mon business. Si tu construis un SaaS qui sert mille clients, les tips d'un dev senior sont indispensables. Ce que je dis ici vaut pour l'entrepreneur qui veut livrer pour lui-même.
Pas de théorie, pas de bullet points recopiés du blog d'un dev senior. Chaque leçon a un titre, le piège dans lequel je suis tombé, ce qui marche maintenant, et un chiffre mesuré. Tu peux toutes les utiliser demain matin.
Le piège · sur mes deux premiers projets, je passais 30 min en début de chaque session à re-expliquer à Claude qui j'étais, ce que je voulais, comment j'aimais qu'on s'adresse à moi. Au bout de la quatrième session, j'ai compris : je perdais 2 h par semaine en remise en contexte. Pire, comme je redonnais le contexte un peu différemment à chaque fois, Claude prenait des décisions incohérentes d'une session à l'autre.
Ce qui marche · un fichier CLAUDE.md à la racine de chaque projet, deux pages max. Il dit qui je suis, ce que fait le projet, mes règles de style, mes interdits, le ton de voix attendu, les conventions de nommage, et la stack technique. Claude le lit à chaque démarrage automatiquement. Mon CLAUDE.md global vit dans ~/.claude/CLAUDE.md et porte tout ce qui ne change pas d'un projet à l'autre (ton Leo, langue française, discipline de dev, sécurité). J'ai même publié le mien anonymisé en téléchargement libre sur le site.
Le gain mesuré · temps de mise en contexte passé de 30 min à 0 par session. Sur 5 sessions/semaine × 6 mois = environ 60 h récupérées. Et zéro décision incohérente entre deux sessions.
Le piège · première fois que j'ai monté mon back-office admin, j'ai dit « construis-moi un dashboard avec 9 modules, sidebar dynamique, base de données, authentification ». Claude a livré 1 200 lignes de code en 20 min. Ça ne marchait pas. Trois jours pour trouver pourquoi (un nom de fonction conflictuel entre deux modules, et une auth qui ne lisait pas le bon cookie). Le pire : j'avais perdu le fil de ce que Claude avait fait, donc je ne savais même pas par où commencer pour débugger.
Ce qui marche · je découpe en livrables d'une heure. « Construis-moi le squelette HTML du dashboard sans aucun module. » Je vérifie. « Ajoute-moi un module idées d'articles qui lit un fichier markdown. » Je vérifie. « Ajoute-moi le rendu en cards. » Je vérifie. C'est lent en apparence, c'est trois fois plus rapide en réalité — parce qu'à chaque palier, si quelque chose casse, je sais exactement où chercher.
Le gain mesuré · sur mon back-office, j'ai livré 11 modules en 14 jours, à raison d'un module toutes les 1-2 sessions. Si j'avais essayé en bloc, je serais encore en train de débugger. Règle pratique : si une étape demande plus de 60 min, c'est qu'elle doit être coupée en deux.
Le piège · sur mon premier agent de brainstorm, j'ai laissé Claude partir bille en tête. Il a écrit 800 lignes de code Node.js avec une architecture multi-fichiers complexe. J'ai relu 30 secondes, j'ai dit « OK ». Trois jours plus tard, je voulais ajouter une source · impossible de m'y retrouver, parce que je n'avais aucun modèle mental de la façon dont les fichiers s'enchaînaient.
Ce qui marche · pour tout ce qui touche plus de 3 fichiers, je dis explicitement « présente-moi un plan d'abord, on validera étape par étape ». Claude propose une architecture, je challenge en posant des questions volontairement bêtes (« pourquoi tu sépares en 5 fichiers et pas 2 ? », « où est-ce que la config vit ? »), on tranche ensemble, on code après. Bonus : ce dialogue produit naturellement des notes que je copie-colle dans le CHANGELOG.md du projet.
Le plugin superpowers formalise ce réflexe : il force Claude à passer par une phase « brainstorming → plan → exécution » avant la moindre ligne. Je l'utilise sur tout projet non-trivial.
Le gain mesuré · temps passé à comprendre un projet 1 mois après l'avoir livré · 5 min si j'ai validé un plan, 1 h si j'ai laissé filer. Et environ 50 % de réécritures en moins sur la première semaine d'un projet.
Le piège · au début je voulais que Claude pousse en production tout seul. Vercel, GitHub, push direct. Sauf qu'une fois j'ai laissé partir un changement de CSS qui a cassé l'affichage en dark mode sur 4 pages. Personne pour le voir avant que ça soit live. La home est restée illisible en dark mode pendant 4 h, j'ai eu deux DM pour me prévenir.
Ce qui marche · Claude écrit, je relis dans mon navigateur local en dark + light, je commit moi-même, et seulement après je git push. Vercel redéploie tout seul ensuite. La barrière humaine entre « ça compile » et « ça part en prod », c'est moi. C'est ennuyeux, c'est lent, c'est exactement pour ça que ça marche.
Corollaire : je désactive systématiquement les hooks Claude Code qui voudraient pousser ou déployer sans confirmation. La règle, c'est « Claude écrit, Jérémy publie ».
Le gain mesuré · zéro régression visuelle en prod depuis que j'ai instauré cette règle, mi-février. Avant : ~2 par mois.
Le piège · au bout de deux mois, je revenais sur des projets et je n'avais aucune idée de ce que j'avais fait la session d'avant. Pourquoi cette fonction ? Pourquoi ce nom de fichier ? Aucune trace, juste du code. Et Claude, à chaque démarrage, repartait à zéro lui aussi — donc on tournait en rond ensemble.
Ce qui marche · à la fin de chaque session non-triviale, je demande à Claude de mettre à jour CHANGELOG.md à la racine du projet. Format : date, ce qui a été fait, pourquoi (le problème résolu), fichiers touchés, ce qui reste à faire. Mon CLAUDE.md global le rend obligatoire — Claude refuse maintenant de fermer une session sans cette mise à jour.
Le bonus inattendu : à la session suivante, Claude lit le CHANGELOG en plus du CLAUDE.md et s'auto-contextualise. Plus besoin de raconter « la dernière fois on avait fait X et Y ».
Le gain mesuré · CHANGELOG.md de jerwis.fr · 1 050+ lignes en 4 semaines de vie. C'est ma mémoire, pas du flicage. Et environ 15 min gagnées au démarrage de chaque session de reprise.
Le piège · pour préparer la trilogie podcast « Guerres d'IA », je devais creuser trois angles d'OpenAI vs Anthropic en même temps · timeline business, biographies des fondateurs, analyse technique des modèles. À l'ancienne j'aurais ouvert 30 onglets, perdu deux heures à zapper d'un sujet à l'autre, et fini par ne creuser correctement aucun des trois.
Ce qui marche · j'ouvre Claude Code, je lance trois sous-agents en parallèle (« Lance trois recherches indépendantes sur ces sujets, chacune dans un sous-agent dédié »). 8 minutes plus tard, j'ai trois rapports synthétiques, sources comprises. Même chose pour scraper plusieurs sites concurrents, comparer plusieurs APIs, ou auditer plusieurs pages SEO d'un coup.
La règle d'or que je me suis posée : 2+ tâches indépendantes (pas de dépendance entre elles, pas de données partagées) = 2+ sous-agents simultanément. Si elles se nourrissent l'une l'autre, en revanche, mieux vaut séquentiel.
Le gain mesuré · sur la prep du pilote « Guerres d'IA », documentation ramassée en 12 min vs ~3 h en surfing manuel. Soit un facteur ×15 sur les phases de recherche pure.
Le piège · à chaque audit SEO d'un nouvel article, je redonnais à Claude les mêmes 12 critères, le même format de sortie, le même barème. Par jour ça allait. Par mois c'était lourd, et je perdais en cohérence : la 5e fois je formulais légèrement différemment, donc le résultat variait.
Ce qui marche · je transforme la tâche répétée en skill custom (un mode d'emploi permanent que Claude lit et applique comme un jeu d'instructions à invoquer en une commande). J'en ai 26 actifs aujourd'hui · audit SEO, transcréation Eurofiscalis 7 langues, brainstorm d'idées, écriture style JIM, narrative-podcast-fr, et bien d'autres. Je les ai même packagés en téléchargement gratuit sur le site (pack jeremy-claude-pack.zip).
La règle qui déclenche : si je m'apprête à donner les mêmes consignes à Claude pour la 3e fois, je m'arrête, je lui demande de transformer ces consignes en skill, et je gagne du temps pour la 4e, la 5e et toutes les suivantes.
Le gain mesuré · temps moyen pour un audit SEO complet d'un article passé de 25 min (à la main avec Claude) à 4 min (skill activé). Soit ×6, sur une tâche que je fais 2-3 fois par semaine.
Une leçon n'a de valeur que si elle vient d'un truc que tu as cassé toi-même. Lis les conseils des autres, mais teste-les sur ton terrain avant de les graver. Ce qui marche pour un dev senior peut t'embrouiller, et ce qui te débloque peut faire sourire un dev senior. Les deux sont vrais en même temps.
Pour t'en montrer un en grand · le projet le plus dingue des 6 mois. Une série podcast narrative façon Wondery sur la guerre IA OpenAI vs Anthropic. Trois épisodes, écriture + voix + montage + mise en ligne. Claude Code de bout en bout. Du jamais fait avant.
| Étape | Ce que je fais | Ce que Claude fait | Temps réel |
|---|---|---|---|
| Brief initial | 2 paragraphes de cadrage | Reformule + pose 3 questions | 15 min |
| Recherche sources | Lance 4 sous-agents | Scrape, classe, synthétise | 4 h (machine) |
| Écriture script | Tranche + relit + reformule | Génère + applique le skill | 6 h (actif) |
| Voix + audio | Choisit voix + ambiances | Pilote ElevenLabs + ffmpeg | 4 h (machine) |
| Mise en ligne | Valide + commit + push | Génère cover + RSS + page | 4 h |
« Je veux trois épisodes de 18-22 min chacun. Style Wondery français · narrateur omniscient, scènes dialoguées, ambiances sonores. Sujet · la guerre IA OpenAI vs Anthropic, vue depuis 2026. Pas de bullshit, sources solides. »
Tout est documenté dans le « Making-of Guerres d'IA » à la racine du repo podcast (10 actes, anecdotes, méta-leçons). Si tu veux le récit narratif complet, il est lisible.
Pas de monde rose. Voilà les trois erreurs qui m'ont vraiment coûté quelque chose · un week-end de prod, une rotation de clé en urgence, et un coup de stress mémorable. Tu vas pouvoir les éviter.
Ce qui s'est passé · samedi 12 avril, je travaillais sur la home en dark mode. J'ai dit à Claude « optimise les couleurs ». Il a remplacé background: var(--ink) par background: #0A0A0A sur 6 sections. Sauf que --ink en dark mode = cream, donc certains blocs censés être TOUJOURS noirs sont devenus cream sur cream = illisibles. J'ai poussé sans relire, je suis parti déjeuner.
Ce que ça m'a coûté · la home jerwis.fr a été cassée 4 heures en dark mode. J'ai eu deux DM « il y a un truc bizarre sur ton site ». J'ai passé mon dimanche après-midi à tout reprendre.
Ma règle depuis · obligation absolue de tester en local en light + dark avant tout git push. Et la règle « variables sémantiques vs couleurs fixes » est gravée dans le CLAUDE.md du projet.
Ce qui s'est passé · sur le projet « Importateur de Buzz » (NANAKIA, pour un proche), j'avais une clé API Cloudinary qui traînait dans un fichier de config. J'ai demandé à Claude de « nettoyer le projet ». Il a déplacé la clé dans .env.local, super. Sauf qu'avant le déplacement, le fichier de config avec la clé en clair avait été commit deux fois. La clé a vécu 5 jours dans l'historique Git public.
Ce que ça m'a coûté · une rotation de clé en urgence, et un audit secu de tout le repo. Plus une session d'environ 3 h à comprendre comment retirer un secret de l'historique Git proprement (réponse · git filter-repo).
Ma règle depuis · tout secret va dans .env.local AVANT le premier commit. Un check pre-commit cherche les patterns d'API keys (Resend, Stripe, OpenAI, etc.) dans tout fichier ajouté. Et je relis chaque diff avant push, en cherchant explicitement sk_, re_, pk_.
Ce qui s'est passé · sur le CRM Eurofiscalis (un autre projet), je voulais réorganiser la table bookings. J'ai dit à Claude « tu peux migrer la table pour qu'elle ait la nouvelle structure ? ». Il a fait. Sans me prévenir qu'il fallait un backup. La migration a foiré sur 3 lignes (des données mal formatées). Plus moyen de revenir en arrière.
Ce que ça m'a coûté · un week-end entier à reconstruire les 3 lignes manuellement à partir d'emails Brevo. Et un coup de stress monumental.
Ma règle depuis · toute action destructive (migration, delete, update massif) doit être précédée d'un backup explicite + d'une commande de rollback documentée dans le plan. Cette règle est dans mon CLAUDE.md global, et Claude la rappelle quand je passe à côté.
Mes 3 erreurs ont la même origine · j'ai laissé Claude faire sans contrôle humain. Pas parce que Claude est mauvais, parce que MOI je n'ai pas mis le contrôle. La leçon n'est pas « il faut moins faire confiance à l'IA », c'est « il faut mettre tes propres garde-fous, et les écrire noir sur blanc ».
On me demande souvent comment ça s'organise concrètement quand on bosse avec Claude Code tous les jours. Voilà ma routine actuelle, telle que je l'ai stabilisée fin avril 2026. Trois sessions par jour, jamais plus de 90 min chacune, le reste de la machine qui tourne en arrière-plan pendant que je vis.
localhost:3001), je clique « Cherche-moi des idées ». Le brainstorm parcourt 470+ items, scrore, classe en 6 clusters, me sort 15 idées. Je garde 2-3.Cette routine n'a rien d'optimisé · elle s'est posée toute seule au fil des 6 mois. Elle me permet de produire 2-3 livrables sérieux par semaine sans m'épuiser.
Mes deux newsletters auto · AI Playbook scanne 100+ sources le jeudi soir, drafte le brief, je relis vendredi matin avant envoi à 9 h. Business Radar pareil mais bi-mensuel. Mon brainstorm tourne aussi quand je clique. Le reste · podcasts, pipelines transcréation, scripts d'audit, c'est à la demande.
Je passerais pour un vendeur de tapis si je m'arrêtais aux belles histoires. Voilà ce qui ne marche toujours pas, après 6 mois.
Claude propose régulièrement des syntaxes qui ont disparu il y a un an, ou des packages npm qui n'existent pas. Sur du Next.js récent (App Router, Server Actions), il faut systématiquement croiser avec la doc à jour. Le plugin context7 aide énormément · il va chercher la doc officielle au moment de répondre, plutôt que de se reposer sur sa mémoire d'entraînement. Sans ça, je reproduis le bug.
Au-delà de ~90 min, Claude commence à perdre le fil. Il oublie une décision prise au début, ou il « invente » une fonction qu'il pense avoir écrite. La parade : redémarrer une session avec un prompt récap de 5 lignes (« voilà où on en est, voilà ce qu'on doit faire, voilà les contraintes »), et fermer la précédente.
Claude est très mauvais pour estimer combien de temps une tâche va prendre. Il dit « 5 minutes » et ça en prend 45. Il dit « ça va coûter 2 € en API » et tu finis à 18 €. Je ne lui demande plus d'estimer · je mesure moi-même après coup, et je note dans le CHANGELOG.
Les modèles Claude ont une coupure de connaissances. Sur tout ce qui s'est passé après leur date d'entraînement, ils sont à côté ou inventent. Pour une recherche d'actualité réelle, je passe par un sous-agent qui a accès au web (dev-browser, ou un MCP web). Jamais Claude tout seul.
Si Claude affirme quelque chose de précis (un chiffre, une syntaxe, une fonction d'API), je vérifie avant de l'utiliser. Pas par méfiance, par expérience. Le coût d'une vérification de 30 secondes est dérisoire face au coût d'un bug en prod.
Pour mon usage (sessions quotidiennes, sous-agents, projets en parallèle), oui. J'avais commencé sur le plan Pro à 20 $, je touchais le plafond de tokens en 2 jours. Au-dessus de 1 session sérieuse par jour, le plan Max devient le bon ratio. En-dessous, le Pro suffit largement.
Pour un non-dev, Claude Code direct dans le terminal est plus simple. Pas d'IDE à apprendre, pas de plug-in à configurer. Pour un dev senior qui vit déjà dans VS Code ou Zed, l'inverse peut être vrai. La vraie différence n'est pas l'outil mais la discipline (CLAUDE.md, plan, CHANGELOG) — et celle-ci marche partout.
Sans doute un peu. Je comprends mieux qu'avant ce qu'est une variable, un import, une fonction asynchrone. Mais je ne deviendrai pas dev. Ce n'est pas mon objectif. Mon objectif est de livrer des outils qui me servent, sans dépendre d'un freelance pour chaque petite modif.
C'est ma plus grosse crainte. Je m'appuie sur le sous-agent security-review de Claude après chaque feature sensible (API, paiement, auth), je vérifie systématiquement mes .env, et je rotate les clés à la moindre alerte. Sur les projets vraiment critiques (SaaS clients, données tierces), je ferais quand même relire par un dev humain. Mais pour mes outils perso, ce niveau me suffit.
Pour un non-dev qui s'y met sérieusement, 3-4 semaines pour livrer ton premier projet utile (un site simple, un script automatisé). 3 mois pour avoir le réflexe de découper en plans, d'écrire un CLAUDE.md, de demander un CHANGELOG. 6 mois pour vraiment sentir que tu pilotes l'outil et plus l'inverse.
Compte 8 à 12 heures par semaine sur les 3 premiers mois si tu pars de zéro · une à deux sessions de 90 minutes par jour, plus la lecture de docs et la digestion des erreurs. Ensuite la cadence baisse à 6-10 heures par semaine, mais le rendement par heure monte fortement (tu sais quoi prompter, tu vérifies plus vite, tu coupes les sessions qui partent en vrille).
Cinq briques suffisent · Claude Code Max (200 $/mois), un éditeur VS Code gratuit pour relire les diffs, Vercel (gratuit) pour héberger, Resend (gratuit jusqu'à 3 000 emails) pour la transactionnel, et un compte GitHub. Total · 200 $/mois pour aller de zéro à plusieurs projets en prod. Ajoute ElevenLabs (22 $) si tu fais du voix, Cloudflare R2 (gratuit) si tu héberges des fichiers lourds.
Non. Avant Claude Code je n'avais jamais commit de ma vie. Je demande à Claude de m'expliquer chaque commande la première fois (commit, branch, merge, revert), aujourd'hui c'est devenu un réflexe à chaque session. Compte 2 semaines pour être à l'aise sur les 6-7 commandes courantes. Le piège · ne JAMAIS faire git push --force sur main sans avoir compris ce que ça écrase.
Lancer une migration de base de données sans backup. Ça m'est arrivé une fois (raconté plus haut), j'ai perdu un week-end à reconstruire mes données à la main. Règle d'or · avant tout DELETE, UPDATE ou migration de schéma, demande à Claude de faire d'abord un dump SQL et de te confirmer que le fichier de backup est lisible. C'est 30 secondes, ça t'évite des sueurs froides.
Pour des outils internes, des sites perso, des scripts d'automatisation et des MVP · oui, et j'économise environ 3 000 € par mois de TJM dev freelance équivalent (chiffrage à 600 €/jour × 5 jours/mois). Pour des SaaS clients facturés ou des systèmes critiques (paiement, données médicales, SLA contractuel), non · la responsabilité juridique et la dette technique long terme demandent encore un humain qui signe.
Oui · le making-of complet du booking Eurofiscalis (un widget de prise de rendez-vous embarqué dans 4 sites WordPress) est documenté heure par heure dans cet article. Tu y verras le brief initial, les pièges rencontrés, le coût réel et les compromis assumés. C'est probablement le plus représentatif de ce que Claude Code change en non-dev sur un vrai projet client.
Un dev senior te parlera d'optimisation, de couverture de tests, d'architecture propre. Pour un entrepreneur qui veut livrer, trois choses comptent vraiment.
Ces trois règles valent tous les tips de dev senior du monde. Elles ne t'empêchent pas de lire les tips, bien sûr. Elles te disent juste · applique-les à ton rythme, et pas parce que quelqu'un d'autre le fait.
Si tu veux continuer sur cette lancée :
Si tu veux suivre mes retours d'XP concrets au fil des mois, ma veille du vendredi te les envoie directement. Pas de pub, désinscription en un clic.
Si tu as une question ou un retour sur cet article, réponds à la newsletter. Ça arrive dans ma boîte et je lis tout, je peux me tromper sur certains points et tes retours m'aident à corriger le tir.
Chaque fois que je publie un nouveau tuto Claude Code / IA, je l'envoie dans ma newsletter AI Playbook. Si tu ne veux pas manquer le prochain, laisse-moi ton email sur la home.
Voir les newsletters →