TL;DR — Mémoire persistante, commandes personnalisées et serveurs MCP suppriment la majorité des frictions quotidiennes. Les sous-agents fonctionnent sur des tâches précises, pas sur des rôles — erreur que font la plupart des développeurs. La revue de code avant chaque déploiement reste indispensable.
- Mémoire + commandes = zéro répétition de contexte entre sessions
- Sous-agents efficaces sur des tâches délimitées, pas sur des rôles d'équipe
- Context7 réduit les hallucinations sur la documentation des librairies
Claude Code peut sembler erratique selon la façon dont on l'utilise. La plupart du temps, ce n'est pas un problème de modèle — c'est un problème de setup. Après plusieurs centaines d'heures de pratique en développement solo, j'ai identifié six fonctionnalités que la majorité des développeurs n'utilisent pas, soit parce qu'elles sont peu documentées, soit parce qu'elles demandent un investissement initial qui peut rebuter. Cet article détaille ces six leviers, dans quel ordre les mettre en place, et les erreurs à éviter — notamment sur les sous-agents, où plusieurs heures de tests ont conduit à une conclusion contre-intuitive.
Pourquoi Claude Code semble inutile sans configuration initiale
Sans configuration, Claude Code ressemble à un IDE sans extensions ni snippets : techniquement fonctionnel, mais peu efficace au quotidien. Trois fonctionnalités forment le socle indispensable — mémoire persistante, commandes personnalisées, serveurs MCP. Sans elles, on passe une part considérable du temps à répéter du contexte ou à compenser les lacunes de connaissance du modèle sur les versions récentes des librairies.
Le premier point d'entrée est la touche # dans Claude Code, qui permet d'injecter des instructions sauvegardées dans le fichier CLAUDE.md. Ces instructions persistent entre sessions et peuvent être versionnées dans le dépôt. On choisit de les appliquer au projet en cours ou globalement à toutes les sessions. J'y stocke les conventions de nommage, les middlewares à inclure systématiquement, et le format d'erreur attendu dans les réponses API — cela supprime une dizaine de minutes de réexplication par session de travail.
Commandes personnalisées Claude Code : automatiser les prompts répétitifs
Pour créer une commande personnalisée, il suffit d'ajouter un répertoire commands dans le dossier .claude du projet, puis d'écrire la commande en Markdown. Les commandes peuvent accepter des arguments, ce qui les rend réutilisables dans des contextes différents.
L'utilité devient réelle dès qu'on identifie des prompts récurrents : créer un endpoint API avec middleware spécifique et gestion d'erreur typisée, lancer le linter TypeScript et corriger toutes les erreurs dans le codebase. Ce sont des tâches exécutées plusieurs fois par semaine. Les transformer en commandes prend une dizaine de minutes une seule fois. Des dépôts GitHub communautaires proposent également des bibliothèques de commandes prêtes à l'emploi — utiles pour découvrir des patterns auxquels on n'aurait pas pensé soi-même.
Serveurs MCP Claude Code : documentation live et outils externes
Les serveurs MCP (Model Context Protocol) sont des connecteurs qui donnent à l'agent l'accès à des outils externes — bases de données, APIs, navigateurs, documentation à jour. L'idée centrale : plutôt que de copier-coller de la documentation dans chaque prompt, Claude la récupère lui-même au moment où il en a besoin.
Le serveur le plus utile pour réduire les hallucinations sur les API est Context7. Il indexe la documentation officielle des principales librairies et la sert en temps réel à l'agent. Pour l'activer, il suffit d'ajouter « use context7 » dans le prompt. Claude interroge alors automatiquement la source à jour — particulièrement utile pour des frameworks à cycle de release rapide où les données d'entraînement du modèle peuvent déjà être obsolètes.
Parmi les autres serveurs utiles en développement solo : Supabase MCP pour interroger directement la base de données, effectuer des migrations ou créer des tables ; Playwright MCP pour permettre à Claude de déboguer des problèmes front-end en contrôlant le navigateur et en inspectant la console et le DOM ; Stripe MCP pour les fonctionnalités liées aux paiements. L'utilité de chacun dépend du stack utilisé — difficile d'évaluer sans les tester sur son propre contexte technique.
Sous-agents Claude Code : tâches ou rôles, la distinction qui change tout
Les sous-agents sont des instances Claude isolées qui s'exécutent en parallèle et remontent leurs résultats à l'agent orchestrateur. Chacun dispose de sa propre fenêtre de contexte, de son propre système prompt et de ses propres permissions d'outils. L'avantage principal est de préserver le contexte de l'agent principal en lui déléguant des tâches secondaires.
L'erreur classique est d'assigner des rôles aux sous-agents : « tu es le développeur front-end », « tu es le product manager ». Après plusieurs heures de tests, les résultats de cette approche sont décevants comparés à une session Claude Code standard. Les sous-agents ne sont pas encore capables de brainstormer ni de travailler de façon vraiment autonome sur des tâches créatives ou de prise de décision.
Ce qui fonctionne bien, c'est de les assigner à des tâches délimitées et reproductibles : nettoyage et optimisation du code récemment écrit, génération de documentation, collecte de données depuis le web, ou revue de l'interface depuis le navigateur via Playwright MCP. Un sous-agent qui inspecte les composants UI dans le navigateur et renvoie un feedback sur l'ergonomie traite un travail concret qui aurait autrement consommé des tokens précieux du contexte principal. Pour créer un sous-agent, la commande /agents dans Claude Code propose une interface de configuration avec choix des permissions d'outils.
Plugins Claude Code : dupliquer un workflow complet en une commande
Les plugins permettent de regrouper un ensemble de configurations — commandes personnalisées, sous-agents, serveurs MCP — dans un package partageable. L'installation se fait via une commande unique, ce qui permet de récupérer le workflow complet d'un autre développeur sans reconfigurer chaque composant manuellement. C'est une fonctionnalité récente d'Anthropic, l'écosystème de plugins publics reste encore limité, mais le principe est solide pour les équipes qui veulent standardiser leur environnement Claude Code.
Prompts et revue de code : le mindset qui détermine l'efficacité réelle
Le modèle ne peut pas produire un meilleur résultat que le prompt qu'on lui fournit. Si une instruction est vague, c'est souvent parce que l'idée elle-même n'est pas encore claire. Travailler la formulation force à décomposer le problème — ce qui clarifie la logique avant même que Claude écrive une ligne de code. Pour les cas où l'idée reste floue, le mode plan de Claude permet une session de questions-réponses : Claude pose des questions de clarification jusqu'à ce que les deux parties soient alignées avant de passer à l'implémentation.
La revue systématique avant déploiement est l'autre pilier. Ouvrir une nouvelle session et demander à Claude de revoir les fichiers récemment modifiés — sécurité, gestion d'erreur, performance — prend peu de temps et évite des bugs coûteux. La vitesse de génération de code ne compense pas une faille de sécurité non détectée, et l'accumulation de dette technique invisible finit toujours par coûter plus cher que la rigueur initiale.
FAQ
Comment activer la mémoire persistante dans Claude Code ?
En appuyant sur la touche # dans l'interface Claude Code, on saisit des instructions qui seront sauvegardées dans le fichier CLAUDE.md. On choisit si ces instructions s'appliquent au projet courant ou à toutes les sessions globalement. Le fichier est éditable directement pour modifier ou supprimer des entrées existantes.
Quels serveurs MCP sont prioritaires pour un développeur solo ?
Context7 est le premier à installer : il résout les hallucinations sur les API en fournissant la documentation à jour. Playwright MCP est indispensable dès qu'on touche au front-end. Supabase MCP simplifie les opérations de base de données. Les autres (Stripe, Vercel) ne valent l'installation que si le projet les utilise effectivement.
Les sous-agents Claude Code peuvent-ils remplacer une équipe de développeurs ?
Non, pas à ce stade. Assigner des rôles humains aux sous-agents (développeur front-end, designer, product manager) donne des résultats inférieurs à une session Claude Code standard. Ils sont efficaces sur des tâches délimitées et répétables, pas sur du travail créatif ou de la prise de décision produit.
Qu'est-ce que Context7 et comment l'utiliser dans Claude Code ?
Context7 est un serveur MCP qui indexe la documentation officielle des principales librairies de développement et la rend accessible à Claude en temps réel. Pour l'utiliser, il suffit d'ajouter « use context7 » dans le prompt. Claude appelle alors automatiquement le serveur au lieu de s'appuyer uniquement sur ses données d'entraînement potentiellement obsolètes.
Le mode plan de Claude Code est-il utile pour les petites tâches ?
Pour des tâches simples, le mode plan ajoute une friction inutile. Son intérêt apparaît sur des fonctionnalités complexes ou quand l'idée est encore floue : il permet d'aligner l'agent sur les contraintes du projet avant de générer du code, évitant ainsi des itérations coûteuses en tokens et en temps de débogage.
À retenir
- Mémoire et commandes en premier : ces deux fonctionnalités suppriment la majorité des répétitions dès la première semaine d'utilisation — investissement initial faible, gain quotidien élevé.
- Context7 contre les hallucinations : pour tout framework à documentation évolutive, ajouter « use context7 » dans les prompts réduit significativement les erreurs d'API.
- Sous-agents sur des tâches, pas des rôles : l'approche « tu es le développeur front-end » ne fonctionne pas ; les tâches délimitées (revue UI, génération de docs, optimisation de code) sont le bon usage.
- Revue systématique avant déploiement : ouvrir une nouvelle session pour revoir les fichiers modifiés reste indispensable — la vitesse de génération ne remplace pas une relecture sur la sécurité et la robustesse.
- Plugins pour standardiser les setups : si plusieurs développeurs travaillent avec Claude Code sur le même projet, les plugins permettent de partager la configuration complète en une commande.