Retour d'expérience honnête
6 mois d'utilisation intensive de Claude Code sur 48 projets. Voici les chiffres réels, les échecs, et ce que je ferais différemment si c'était à refaire.
1. Combien ça coûte ?
J'ai analysé mes 10 629 sessions Claude Code sur 6 mois (novembre 2025 - avril 2026). Voici la réalité des coûts :
Évolution mensuelle des sessions
ROI concret
Le plan Max à 180€/mois a remplacé des outils qui coûtaient plus cher collectivement :
Remplacé
- JotForm + Make.com - 200€/mois
- Portainer - licence pro ou temps perdu
- Datadog - monitoring payant
Construit avec Claude Code
- comrenov - remplace JotForm+Make.com
- iolite-ifrit - remplace Portainer
- granit-golem - remplace Datadog
2. Les échecs - ce qui n'a pas marché
Je ne vais pas faire semblant que tout a fonctionné. Voici mes trois plus gros échecs avec Claude Code :
sioule-2 : le gouffre à sessions
ratio 94:1Fork de sioule pour tester l'upgrade Node v24 + Angular 11 vers 21. Une quantité énorme d'exploration et de tentatives de migration. La plupart du travail n'a jamais été committé - des explorations sans issue, des impasses techniques, des cascades de breaking changes.
siliceum-website : le piège du pixel-perfect
ratio 16:1Refonte complète du design system - 6 sprints. Beaucoup d'itérations sur le design (couleurs, marges, typographie) qui ne produisent pas de commits. Chaque ajustement visuel nécessite un aller-retour complet.
Projets sans CLAUDE.md
0 lignes de configDeux projets utilisés intensivement sans aucun CLAUDE.md. Chaque session recommence à zéro : exploration du projet, compréhension de la stack, redécouverte des conventions.
3. Quand NE PAS utiliser Claude Code
Après 10 000+ sessions, voici les situations où je déconseille Claude Code :
Migrations de frameworks majeurs
Angular 11 vers 21, Rails 4 vers 7... Trop de contexte implicite, cascades de breaking changes. Mon ratio 94:1 sur sioule-2 parle de lui-même.
Design pixel-perfect
Les itérations visuelles coûtent cher en sessions. Ratio 16:1 sur siliceum-website. Mieux vaut utiliser un éditeur visuel pour les ajustements fins.
Debugging hardware / drivers
Pas de contexte système suffisant. Claude Code ne peut pas voir les logs kernel, les interrupts ou l'état du matériel.
Code avec beaucoup d'état implicite
Callbacks imbriqués, event systems complexes, state machines non documentées. Claude Code perd le fil des effets de bord.
Sans CLAUDE.md
Commencer par écrire le CLAUDE.md, PUIS utiliser Claude Code. L'inverse est un gaspillage prouvé par mes données.
4. Avant / Après concret
Pour contrebalancer les échecs, voici ce qui a été livré. Les durées sont extraites des dates de premier et dernier commit git :
comrenov
remplace JotForm + Make.comiolite-ifrit
remplace Portainergranit-golem
"le Datadog de la qualité"basalt-beholder
PWA offline-first + BMAD5. Sécurité et confidentialité
La question revient systématiquement : "tu envoies ton code dans le cloud ?". Voici comment je gère la sécurité :
Claude Code Max plan
Le code ne quitte pas la session. Pas de training sur mes données. Politique contractuelle claire d'Anthropic.
.env systématiquement dans .gitignore
Aucun fichier de credentials n'est versionné. Vérification automatique via gitleaks en CI.
Jamais de credentials dans le contexte
API keys, tokens, mots de passe - jamais dans les prompts ni dans les fichiers lus par Claude Code.
Token Grafana trouvé en clair
Un token Grafana en clair dans .mcp.json. Détecté, corrigé, leçon apprise. Maintenant je fais un grep systématique avant chaque commit sur les fichiers de config.
Projets sensibles en local only
Pour les projets très sensibles, j'utilise le mode local only - pas de communication avec l'API cloud.
6. Passage à l'échelle en équipe
Mon setup est optimisé pour un solo dev avec 48 projets. En équipe, les dynamiques changent :
Solo (mon setup actuel)
- CLAUDE.md personnel et itératif
- MEMORY.md comme journal de bord
- Agents spécialisés par domaine
- Conventions implicites (dans ma tête)
En équipe (recommandations)
- CLAUDE.md = document partagé (comme un wiki)
- MEMORY.md personnel par développeur
- Agents = "experts" que l'équipe n'a pas
- Conventions explicites, versionnées
7. Comparaison avec les alternatives
J'ai testé ou évalué les alternatives. Voici mon avis honnête :
| Outil | Force principale | Faiblesse | Mon usage |
|---|---|---|---|
| Cursor | Édition inline, UX fluide | Moins bon pour l'orchestration multi-fichier | Quick editing ponctuel |
| GitHub Copilot | Autocomplétion rapide | Pas de capacité agentic, pas d'orchestration | Non utilisé |
| Claude Code | Orchestration (git, tests, build, multi-fichier) | Pas d'UI graphique, courbe d'apprentissage CLI | Outil principal - projets structurés |
| Aider | CLI similaire, open-source | Pas de MCP, pas d'agents, moins de features | Évalué, pas adopté |
Mon choix : Claude Code pour les projets structurés (95% de mon temps), Cursor pour le quick editing quand je veux voir le diff en temps réel.
8. Ce que je ferais différemment
Avec le recul de 6 mois et 10 000+ sessions, voici ce que je recommande à quiconque démarre :
Écrire le CLAUDE.md AVANT la première session
Pas après 200 sessions. Même 30 lignes suffisent : stack, commandes de test, conventions de commit. J'ai appris cette leçon à mes dépens.
Commencer par les quality gates, pas les features
Les quality gates évitent les régressions dès le début. J'ai passé des semaines à corriger des bugs qui n'auraient pas existé avec un pipeline en place dès le jour 1.
Utiliser les agents spécialisés plus tôt
J'ai attendu le mois 3 pour créer mes premiers agents. Les skills d'audit, les workflows BMAD - tout cela aurait dû être en place dès le départ.
Ne pas tenter les migrations legacy en mode autonome
sioule-2 m'a coûté 1 416 sessions pour ~15 commits. Les migrations de frameworks legacy nécessitent un pilotage humain étape par étape.
Documenter les échecs en temps réel
J'ai reconstitué ces données après coup. Si j'avais un journal d'échecs dès le début, j'aurais identifié les patterns problématiques plus tôt.