Je dirige une TPE, je code mes propres SaaS, et je prends quelques missions freelance en parallèle. Je ne dors pas plus qu'avant. Et pourtant, depuis un an, je livre en moyenne 3 à 4 fois plus de code qu'à mes débuts.
Claude Code n'est pas la cause de ce changement. C'est le levier qui a rendu possible un mode de travail qui ne l'était pas. Voici ce qui a vraiment changé — et ce qui n'a pas changé.
Le facteur temps : 3 semaines deviennent 3 jours
Un exemple concret. L'an dernier, j'ai voulu ajouter à NaviR Field un module « plans de masse » — le technicien dessine sur le plan d'un bâtiment l'emplacement des dispositifs anti-nuisibles. Sept types de dispositifs, placement interactif sur canvas, export PDF, historique versionné.
Si j'avais dû sous-traiter cette feature :
- Rédaction du brief technique : 2 jours
- Devis + signature : 1 semaine
- Dev par un freelance : 10-15 jours
- Revue + corrections : 3 jours
- Intégration : 2 jours
- Total : 4 semaines et ~8 000 €
Avec Claude Code et ma propre connaissance du codebase :
- Brief en clair dans ma tête (je n'ai pas à l'écrire pour un tiers)
- V1 fonctionnelle en 4 heures
- Itérations sur 2 jours pour les edge cases
- Total : 3 jours, 0 € dépensé
C'est ça le vrai changement. Pas « coder plus vite » — mais supprimer 80 % de la friction organisationnelle qui s'intercale entre l'idée et le déploiement.
Les cycles courts : 20 itérations dans une journée
Avant : je finissais une feature dans la semaine, je testais en prod le lundi suivant, je corrigeais le mardi, je testais à nouveau le jeudi. Cycle hebdomadaire.
Maintenant : je déploie 3 à 5 fois par jour. Chaque déploiement est suivi d'un test réel (par moi ou par un technicien), qui remonte une observation, qui devient une nouvelle itération en 30 minutes.
À la fin d'une journée, la feature a été affinée 15 à 20 fois. Impensable avec un cycle externalisé.
La bonne mentalité : Claude écrit AVEC moi, pas À MA PLACE
Le piège classique, c'est de demander à Claude Code : « écris-moi un module X qui fait A, B, C ». Vous recevez 500 lignes de code que vous ne comprenez pas. Ça marche, mais vous venez de signer une dette de compréhension qui vous explosera à la figure dans 3 mois.
Ma règle : je dois pouvoir expliquer chaque bloc à haute voix. Si je ne peux pas, je demande à Claude de m'expliquer ce qu'il a écrit, je reformule, et seulement ensuite je valide.
Claude Code est un amplificateur de compétence. Si vous êtes junior, il vous fera produire du code de junior plus vite. Si vous êtes senior, il vous libérera de la mécanique pour vous concentrer sur les choix structurants.
Ce qui ne change pas
Beaucoup de choses restent inchangées :
- La compréhension métier. Claude ne sait pas qu'un technicien 3D a besoin de saisir une intervention avec un gant sur les doigts. C'est vous qui le savez.
- Les arbitrages produit. « Faut-il exposer ce paramètre dans l'interface admin ou le laisser en config fichier ? » — aucun LLM ne répond bien à ça sans contexte profond.
- L'architecture à gros grain. Claude est excellent sur une fonction ou un module. Il est moins bon pour décider si votre SaaS doit être multi-tenant par RLS ou par base séparée. Ces décisions restent les vôtres.
- La discipline. Si vous ne testez pas ce que Claude produit, vous accumulez des bugs à l'échelle industrielle.
Les 2 pièges à éviter
1. La dette de compréhension
On y revient : ne gardez jamais dans votre codebase un bloc que vous ne sauriez pas réécrire seul en 30 minutes. Si Claude produit un truc magique que vous ne saisissez pas, demandez-lui de le simplifier ou de vous l'expliquer ligne par ligne. Ou réécrivez-le vous-même.
2. La sur-ingénierie
Par défaut, Claude Code a tendance à produire du code « enterprise-ready » : abstractions, interfaces, design patterns. Pour une TPE, 90 % de cette complexité est du bruit. Je demande explicitement : « fais simple, direct, sans abstraction inutile ». Ça change tout.
Mon workflow type
Voici à quoi ressemble une heure de dev chez moi :
- J'ouvre un terminal dans mon repo, je lance Claude Code.
- Je lui décris le besoin en 5-10 lignes, en précisant les contraintes.
- Je lis sa proposition. Si elle est trop complexe, je demande une version plus simple.
- Je valide l'implémentation, je la teste immédiatement.
- Si bug : je décris le symptôme, Claude propose un fix, je valide.
- Je commit avec un message clair rédigé à la main (pas généré).
- Je déploie.
6 étapes. 20 à 40 minutes pour une feature mineure, 2 à 4 heures pour une feature substantielle.
En conclusion
Claude Code n'est pas un remplaçant du développeur. C'est un changement de cadence pour ceux qui savent déjà coder et qui pilotent des projets en solo. Les gains réels :
- Cycle idée → prod divisé par 3 à 5
- Itérations 10x plus fréquentes
- Indépendance organisationnelle (plus besoin de négocier avec un prestataire pour chaque feature)
- Coût marginal d'une feature proche de zéro
Le piège à éviter : confondre vitesse de production avec qualité d'un produit. Un SaaS qui répond au besoin, c'est 20 % de code et 80 % de compréhension métier, de design et de décision. Claude Code accélère les 20 %. Les 80 %, c'est toujours à vous de les porter.