Contexte de l’auteur
- Ingénieur logiciel depuis 7 ans (Amazon, Disney, Capital One), aujourd’hui CTO d’une startup.
- Utilise Claude Code quotidiennement pour construire des systèmes robustes à grande échelle.
- Partage un guide débutant basé sur son expérience réelle en production.
1. Penser avant de taper
- La plus grosse erreur est de commencer à écrire sans réfléchir.
- Le mode planification donne systématiquement de meilleurs résultats que l’improvisation.
- Plus l’input est réfléchi, plus l’output est de qualité.
- Même pour de petites tâches (résumer un mail), réfléchir d’abord améliore le résultat.
Conseils :
- Apprendre les bases (architecture, raisonnement).
- Dialoguer avec le LLM pour explorer plusieurs options de conception avant d’implémenter.
2. L’architecture est cruciale
- Des demandes vagues produisent du code médiocre.
- Des instructions précises et architecturées réduisent l’ambiguïté et les erreurs.
- Exemple :
- ❌ « Construis un système d’authentification »
- ✅ Instructions détaillées (méthode, stockage, contraintes, périmètre)
- 5 minutes de planification peuvent éviter des heures de debug.
3. Le fichier CLAUDE.md est un levier majeur
- Fichier Markdown lu par Claude au début de chaque session.
- Sert de document d’onboarding permanent pour le modèle.
Bonnes pratiques :
- Être court : trop d’instructions dégradent la qualité.
- Être spécifique au projet (particularités, workflows, commandes utiles).
- Expliquer le pourquoi, pas seulement le quoi.
- Le mettre à jour en continu (document vivant).
- Un bon
CLAUDE.mdressemble à des notes personnelles, pas à une doc RH.
4. Limites de la fenêtre de contexte
- La qualité commence à baisser dès 20–40 % du contexte, pas à 100 %.
- Plus de contexte dégradé = pires résultats.
Bonnes pratiques :
- Une conversation par fonctionnalité.
- Utiliser une mémoire externe (
plan.md,SCRATCHPAD.md). - Faire des resets intelligents (copier l’essentiel,
/compact,/clear). - Ne pas hésiter à repartir de zéro.
- Claude est stateless : tout doit être explicitement fourni.
5. Le prompting est essentiel
- Communiquer clairement est plus important que le modèle lui-même.
- Être précis, poser des contraintes, donner des exemples.
- Dire explicitement ce qu’il ne faut pas faire (éviter l’overengineering).
- Donner le contexte métier et les contraintes (performance, prototype, etc.).
6. Mauvais input = mauvais output
- Si les résultats sont mauvais, le problème vient presque toujours du prompt.
- Le modèle compte, mais l’humain est le principal goulot d’étranglement.
Améliorer :
- La rédaction des prompts.
- La structuration des demandes.
- Le contexte fourni.
7. Choisir le bon modèle
- Sonnet : rapide et économique, idéal pour l’exécution.
- Opus : plus lent et cher, meilleur pour la planification et le raisonnement.
- Workflow recommandé :
- Opus pour concevoir → Sonnet pour implémenter.
CLAUDE.mdassure la cohérence entre les modèles.
8. Outils avancés : MCP, hooks, commandes
- MCP : connexion à des services externes (GitHub, Slack, bases de données).
- Hooks : automatisations (formatage, tests, lint).
- Slash commands : prompts réutilisables.
- Tester les fonctionnalités permet de gagner du temps et de l’argent.
- Les modèles évoluent vite : rester curieux et réessayer.
9. Quand Claude bloque
- Ne pas insister en boucle.
- Changer d’approche est souvent plus efficace.
Stratégies :
/clearet repartir proprement.- Découper le problème.
- Montrer un exemple minimal.
- Reformuler le problème.
- Reconnaître rapidement les boucles.
10. Construire des systèmes, pas des tâches isolées
- Claude peut être utilisé en mode headless et automatisé.
- Intégration dans des pipelines (PR reviews, support, documentation).
- Amélioration continue via logs + ajustement du
CLAUDE.md. - Les systèmes s’améliorent avec le temps, sans changer de modèle.
TL;DR
- Réfléchir avant d’écrire.
- Planification et architecture > tout le reste.
CLAUDE.mdest le point de levier principal.- Le contexte se dégrade vite : savoir le gérer.
- La qualité dépend directement du prompt.
- Tester les outils avancés.
- Changer d’approche quand ça bloque.
- Automatiser et construire des systèmes durables.
