Flux de travail quotidien avec Claude Code pour les fondateurs qui codent

Il y a trois mois, j'ai failli embaucher un deuxième développeur backend. On avait un backlog embarrassant, quatorze fonctionnalités promises aux clients, deux personnes surchargées, et moi qui context-switchais entre des appels commerciaux et des pull requests comme un complet idiot. Ensuite j'ai commencé à vraiment utiliser Claude Code correctement. Pas juste coller des fonctions dans une fenêtre de chat. Je veux dire l'intégrer dans le flux quotidien réel. On a liquidé ce backlog en six semaines. Je n'ai pas embauché le deuxième développeur.

C'est pas une présentation commerciale. C'est juste ce qui s'est passé.

Ce que « Correctement » veut vraiment dire

La plupart des gens que je croise aux meetups utilisent les outils de codage IA de la même façon paresseuse. Ils collent une fonction, récupèrent quelque chose, le collent dans leur éditeur, ça ne marche pas, ils abandonnent. Ce n'est pas un flux de travail. C'est de la désespérance.

Correctement, pour moi, ça signifie que Claude Code vit dans mon terminal via la Claude Code CLI, travaillant directement sur mon vrai repo, lisant des vrais fichiers, pas des snippets aseptisés. La différence est énorme. Quand il a le contexte complet d'un plugin WordPress de 4 000 lignes qu'on a construit pour un client du secteur de la santé américain l'année dernière, la sortie est utilisable. Quand il travaille à l'aveugle sur un copier-coller de 40 lignes, il devinne.

Je l'utilise sur un MacBook Pro M3. Mon éditeur c'est toujours VS Code avec les suspects habituels, Prettier, ESLint, GitLens. Claude Code ne remplace rien de tout ça. Il se place à côté.

Le setup que j'utilise réellement

Claude Code CLI installé globalement via npm
Un répertoire .claude à la racine de chaque projet avec un fichier CLAUDE.md, c'est essentiellement un brief que j'écris pour Claude sur le projet : la stack, les conventions, ce qu'il ne faut pas toucher.
iTerm2 avec des volets divisés : le code à gauche, la session Claude à droite
Des commits Git après chaque modification générée par Claude, sans exception. J'en ai fait les frais.

Ce dernier point. En 2022, un projet client, migration Shopify pour un détaillant de meubles basé à Manchester, j'ai laissé s'accumuler trois heures de modifications assistées par IA sans committer. Toute la session s'est corrompue. Six heures de travail envolées. Maintenant je fais des commits de façon compulsive, presque névrotique. Claude Code ou pas.

La routine matinale (C'est volontairement ennuyeusement spécifique)

Je suis au bureau à 8h30. Un café du café sur Exmouth Market. J'ouvre Notion, je regarde ce qu'il y a au programme pour la journée, puis j'ouvre mon terminal.

La première chose que je fais avec Claude Code chaque matin, c'est ce que j'ai commencé à appeler un « context dump ». J'ouvre le projet, je lance claude et je lui donne un paragraphe sur où je m'étais arrêté la veille. Il lit automatiquement le git diff récent. Ça prend environ trois minutes et ça veut dire que je ne passe pas vingt minutes à relire mon propre code pour me souvenir de ce que je faisais. Ça seul, ça vaut l'abonnement.

Ensuite je travaille. Je ne demande pas à Claude d'écrire des fonctionnalités de zéro, même si parfois je le fais. La plupart du temps je lui demande de faire les trucs qui me ralentissent mais qui ne demandent aucune créativité.

Des choses comme :

Écrire des cas de test PHPUnit pour des fonctions que j'ai déjà écrites
Générer des interfaces TypeScript à partir d'une réponse JSON que je colle
Refactoriser un composant de 300 lignes que je sais devoir splitter mais sur lequel je ne veux pas réfléchir.
Une première ébauche de documentation pour les APIs internes

Rien de tout ça n'est excitant. Tout cela me prenait une heure que je n'avais pas.

Où ça économise vraiment du temps (avec les chiffres)

Seahawk a construit plus de 12 000 sites à ce stade. Une bonne partie c'est WordPress, des thèmes, des plugins, des customisations WooCommerce. Il y a une catégorie de tâche dans le développement WordPress qui est insipide mais techniquement précise : écrire des hooks personnalisés, enregistrer des endpoints API REST, construire des pages de paramètres avec l'API Settings.

Je l'ai chronométré le mois dernier. Écrire une classe de méthode d'expédition WooCommerce personnalisée de zéro : historiquement ça m'prend environ 45 minutes en incluant les tests. Avec Claude Code qui fait le scaffold pendant que je décris la logique métier en langage naturel : 12 minutes. Et le scaffold est bon, il suit les standards de codage WordPress parce que je le lui ai dit dans mon CLAUDE.md.

Ce n'est pas 10 % plus rapide. C'est une catégorie de vitesse différente.

L'économie la plus importante, c'est le coût du changement de contexte. Quand je suis en plein milieu d'une feature et qu'un client me signale un bug sur un projet complètement différent, avant j'avais le choix : ignorer le client (mauvais) ou perdre totalement le fil (aussi mauvais). Maintenant je peux demander à Claude d'écrire un bloc de commentaires détaillé résumant exactement où nous en sommes dans la tâche actuelle, basculer sur le bug, le corriger, revenir, lire le commentaire, et reprendre en quatre minutes. Avant, cette récupération me coûtait vingt minutes.

Où ça s'effondre

Soyons honnête. Et c'est plus important que les victoires.

Claude Code est vraiment mauvais pour tout ce qui nécessite de comprendre pourquoi une décision a été prise historiquement. On avait un projet fintech chez Seahawk, un tableau de bord pour une startup de paiements basée à Londres, où existait une gestion d'état particulièrement complexe pour une raison qui précédait notre implication. Un cas limite dans la façon dont leur API legacy traitait les réponses par lot. Claude n'arrêtait pas de le « corriger ». Chaque suggestion était techniquement plus propre et complètement fausse. Il ne savait pas ce qu'il ne savait pas.

C'est le mode d'échec dont personne ne parle assez. Le résultat a l'air correct. Ça passe une review basique. Et puis ça casse en production jeudi soir quand un utilisateur touche cet edge case.

Ma règle maintenant : Claude Code ne touche à rien si le commentaire dit « ne change pas ceci sans demander à Ravi ». (Ravi est notre lead backend dev.) Point final.

Ça a aussi du mal avec :

Les refactors multi-fichiers où la chaîne de dépendances est plus profonde que trois niveaux
N'importe quoi impliquant un SDK tiers de moins de deux ans, il hallucine des noms de méthodes avec confiance
Du CSS qui doit correspondre à la composition pixel-perfect d'un designer (ça se rapproche, puis ça te rend fou avec de petites erreurs)
L'optimisation de performance où le goulot d'étranglement n'est pas évident, il optimise la mauvaise chose

Sur le point deux spécifiquement : j'intégrais l'API de Resend dans un projet Next.js en janvier. Claude referençait constamment une méthode .send() qui n'existe pas dans le SDK Node de Resend. Ça m'a pris plus de temps de déboguer la fausse certitude de Claude que ça m'aurait pris de simplement lire la doc moi-même. Leçon apprise. Pour n'importe quel SDK, je colle le vrai README dans la fenêtre de contexte en premier.

Les Motifs de Prompt Qui Fonctionnent Réellement

J'ai itéré là-dessus pendant des mois. Les mauvais prompts donnent de mauvaises résultats. Voici ce sur quoi je me suis arrêté.

Sois le dev senior, pas le stagiaire. Ne demande pas « écris-moi une fonction qui fait X ». Demande « j'ai besoin d'implémenter X. Voici la contrainte : Y. Voici ce que j'ai déjà écarté : Z. Quelle est ton approche avant que tu n'écrives quoi que ce soit ? » Force-le à réfléchir d'abord. Le résultat de cette conversation après est dramatiquement meilleur.

Donne-lui un persona avec des enjeux. J'écris littéralement : « Tu es un développeur WordPress senior qui tiens profondément à ne pas introduire de vulnérabilités de sécurité. Le client est une entreprise de santé. Priorise la sanitisation et la vérification des nonces par-dessus tout. » Est-ce que ça paraît stupide ? Oui. Est-ce que ça marche ? Aussi oui.

Spécifie le format de la sortie. « Donne-moi juste la fonction, pas d'explication » ou « Donne-moi la fonction, puis une liste à puces de ce que je dois vérifier manuellement. » La sortie non structurée fait perdre du temps.

Un motif auquel j'ai recours constamment :

Décris l'objectif en une phrase
Collez le code existant pertinent avec un commentaire expliquant son objectif
Énoncez la contrainte (« doit être rétrocompatible avec PHP 7.4 »)
Demandez d'abord une approche, puis le code
Examinez l'approche, remettez en question si nécessaire, puis demandez le code

Cinq étapes. Cela ressemble à du surcoût. Ça m'économise quinze minutes de mauvais code à chaque fois.

Comment cela a changé ce que je délègue

C'est le détail qui m'a le plus surpris. Claude Code ne m'a pas juste rendu plus rapide. Ça a changé ce que je confie aux développeurs juniors.

Avant, un dev junior chez Seahawk passait ses deux premières semaines juste à se familiariser avec nos conventions et notre stack. Maintenant, je leur confie un projet avec un CLAUDE.md bien rédigé et je leur dis d'utiliser Claude Code pour générer le code scaffold, puis de vérifier que ça respecte les conventions. Ils contribuent du vrai travail en trois jours au lieu de trois semaines.

Le fichier CLAUDE.md remplace le mentorat que je faisais autrefois lors de réunions horaires. C'est un changement significatif. Pas parce que je ne veux pas faire de mentorat, je le veux, mais parce que maintenant les conversations de mentorat portent sur les décisions et les compromis, pas sur « n'oublie pas d'utiliser wp_nonce_field() dans chaque formulaire ».

La documentation de spécification du modèle Anthropic vaut le coup d'être lue si tu es curieux des garde-fous dans lesquels Claude opère ; les comprendre t'aide à travailler avec ses tendances plutôt que contre elles.

L'angle spécifique au fondateur

La plupart des articles sur les outils de codage IA sont écrits pour les développeurs. D'accord. Mais il y a un problème spécifique aux fondateurs que Claude Code résout et que je n'ai pas vu bien articulé.

Quand tu diriges une agence et que tu codes aussi, ton pire ennemi n'est pas les lacunes de compétences. C'est le coût de réentrée. Tu te fais appeler pour un appel tarifaire quarante minutes, puis tu dois corriger une régression CSS, puis tu as un 1-on-1 avec un membre de l'équipe. Au moment où tu reviens à la fonctionnalité que tu construisais, tu as tellement perdu le fil que recommencer de zéro semble plus facile que de reprendre.

Claude Code, utilisé correctement, réduit dramatiquement le coût de réentrée. J'ai mentionné plus tôt l'astuce du bloc de commentaires de synthèse. Je l'utilise aussi pour générer rapidement un message Slack « où en sommes-nous » avec des points sur ce qui est fait, ce qui vient ensuite et ce qui est bloqué. Ça prend dix secondes. Ça vous économise dix minutes de reconstruction.

Ça ne fera pas de toi un meilleur manager. Ça ne libérera pas ton calendrier. Mais si tu es un fondateur qui livre toujours du code, et je pense que davantage d'entre nous devraient le faire, ça supprime un coût spécifique et douloureux sur ton temps de codage.

FAQ

Claude Code vaut-il le coup si vous n'êtes pas développeur à temps plein ?

Honnêtement, probablement moins. La valeur se compose quand tu es dans l'outil tous les jours et que tu investis du temps dans la construction de bons fichiers de contexte (CLAUDE.md, briefs de projet clairs, etc.). Si tu y plonges une fois par semaine, tu passeras plus de temps à rétablir le contexte que tu ne gagneras. GitHub Copilot conviendrait peut-être mieux aux utilisateurs occasionnels, c'est plus ambiant et nécessite moins de configuration délibérée.

Comment tu gères la qualité du code, tu fais juste confiance à ce qu'il génère ?

Jamais en aveugle. Chaque fichier généré par Claude passe par ESLint et notre config Prettier automatiquement. Pour tout ce qui touche à l'authentification, aux paiements ou à la gestion des données, je fais une relecture manuelle ligne par ligne. Pour les fonctions utilitaires et les tests, je suis plus détendu. Tu calibres en fonction du risque. L'OWASP Top Ten est une checklist mentale utile quand tu révises du code généré par IA qui traite les entrées utilisateur.

Ça marche bien spécifiquement avec WordPress ?

Mieux que je m'y attendais, avec des réserves. Il connaît WordPress profondément, les hooks, les filtres, l'API Settings, les internals de WooCommerce. Mais sa connaissance du développement de blocs Gutenberg plus récent (particulièrement l'Interactivity API) est lacunaire. Je vérifie toujours par rapport au Block Editor Handbook pour n'importe quoi lié aux blocs.

Et le coût ?

Je paie Claude Pro, qui coûte 20 $/mois. Au rythme où je l'utilise, le gain de temps est situé entre quatre et six heures par semaine. Faites le calcul sur votre propre taux horaire. Pour moi, ce n'est pas une question qui mérite d'être posée.

---

Je code encore pas mal moi-même. Je n'ai pas envie de devenir un manipulateur de prompts qui ne touche jamais une vraie fonction. Mais le fondateur qui prétend que les outils de codage IA n'ont pas changé le métier se leurre. La question n'est pas de savoir s'il faut les utiliser. C'est de savoir si tu les utilises avec assez de rigueur pour en tirer une vraie valeur, ou juste assez de négligence pour introduire de vrais problèmes.

Pour moi, la différence entre ces deux choses venait de traiter Claude Code comme un développeur capable mais junior. Intelligent. Rapide. Qui a besoin d'un bon brief. Qui a besoin de relecture. Et qui ne devrait absolument pas être laissé sans surveillance près de quelque chose d'critique pour la mission.

Ce cadre a tout changé.