Maîtriser Claude Code : les 7 niveaux du prompting débutant aux pipelines entièrement autonomes

Introduction

La plupart des utilisateurs de Claude Code sont bloqués au niveau deux ou trois sans le savoir. Ils tapent des requêtes, acceptent les modifications et passent à autre chose — et ils en tirent de la valeur. Mais ils laissent un levier considérable inexploité.

Depuis son lancement en février 2025 et sa disponibilité générale en mai de la même année, Claude Code est devenu un outil qui a atteint 1 milliard de dollars de revenu annualisé en novembre 2025. À ses niveaux supérieurs, il se transforme en un système autonome qui planifie, exécute, se connecte à vos applications, coordonne des équipes de sous-agents spécialisés et fait tourner des pipelines de nuit qui livrent du travail fini au matin. L’écart entre la façon dont la plupart des développeurs l’utilisent et ce dont il est réellement capable est considérable.

Cet article cartographie les sept niveaux — de la première habitude qui distingue les débutants des utilisateurs avancés, jusqu’aux frameworks et architectures qui vous permettent de prendre du recul et de superviser plutôt que d’exécuter.

Niveau 1 — Prompter avec intention : planifier avant de construire

L’habitude unique qui sépare un débutant de quelqu’un qui obtient de vrais résultats est de planifier avant d’exécuter.

Claude Code intègre un Plan Mode — un mode lecture seule où Claude ne peut modifier aucun fichier ni exécuter aucune commande. Il lit votre codebase, pose des questions de clarification et propose un plan complet avant qu’une seule ligne ne change. Vous pouvez l’activer en appuyant sur Shift+Tab deux fois pour alterner entre les modes Normal, Auto-Accept et Plan Mode, ou en tapant /plan directement dans le prompt.

Boris Cherny, le créateur et responsable de Claude Code chez Anthropic, est explicite à ce sujet dans son propre workflow : il n’entreprend aucune action d’exécution tant qu’il n’a pas fait des allers-retours avec Claude en plan mode et qu’il n’est pas satisfait du plan. Ce n’est qu’ensuite qu’il passe en mode auto-accept des modifications — et à ce stade, Claude peut généralement exécuter en une seule passe.

Pourquoi est-ce si important ? En Plan Mode, tous les outils d’écriture et de modification sont désactivés. Claude ne peut que lire, chercher et raisonner. Cela le force à réfléchir pleinement au problème — en posant des questions ciblées qui font émerger vos hypothèses et comblent les lacunes de votre brief. Au moment où vous passez en exécution, Claude dispose d’un ensemble complet de contexte pour travailler, et il y a beaucoup moins d’allers-retours pour corriger le cap.

La règle pratique : ne donnez jamais à Claude une tâche d’exécution sans d’abord la passer en plan mode. Des prompts vagues en mode exécution produisent un output générique et hors cible. Le même prompt en plan mode produit un plan structuré, aux hypothèses testées, qui s’exécute proprement.

Niveau 2 — Le fichier CLAUDE.md : donner vos règles à Claude

Claude suit des instructions. La question est de savoir si ces instructions viennent de vous ou des paramètres par défaut de Claude.

Le fichier CLAUDE.md résout ce problème. C’est un document au niveau du projet que Claude lit au début de chaque session — vos règles, votre stack, vos préférences et les erreurs que vous ne voulez pas voir se répéter. Considérez-le comme une documentation d’onboarding pour un nouveau membre de l’équipe qui se trouve avoir une mémoire parfaite. Claude assemble en fait une hiérarchie de mémoire du plus général au plus spécifique : ~/.claude/CLAUDE.md pour les préférences globales, le CLAUDE.md à la racine du projet pour les conventions d’équipe, et les fichiers CLAUDE.md dans les sous-répertoires pour les instructions spécifiques aux modules.

L’équipe de Boris Cherny maintient un seul fichier CLAUDE.md, versionné dans Git, auquel toute l’équipe contribue. Quand Claude fait une erreur récurrente, ils ajoutent une règle. Quand une règle devient obsolète, ils la suppriment. Le fichier évolue avec le projet.

Un cadre pratique pour rédiger le vôtre :

1. C’est quoi ce projet ? Une ligne. « Ce projet génère du contenu quotidien pour les réseaux sociaux sur LinkedIn, X et Instagram dans ma voix de marque, en puisant les sujets dans un calendrier de contenu dans Airtable. »
2. Comment on lance les choses ? Les étapes exactes — où vivent les données, où vont les outputs, les conventions de dossiers.
3. Voix et règles. Vos non-négociables. Les exigences de format. Les mots que vous n’utilisez jamais.
4. Erreurs courantes. Les cas limites qui piègent Claude — conflits de nommage, noms de champs ambigus, comportements contre-intuitifs dans votre stack.
5. Comment on travaille ? Conventions de nommage des fichiers, ce qu’il ne faut jamais faire automatiquement, comment gérer le contenu réutilisé.

La règle d’or : restez concis. La documentation officielle conseille « moins c’est plus » — incluez le moins d’instructions raisonnablement nécessaire et utilisez la divulgation progressive, en référençant des fichiers externes pour le détail plutôt que de tout mettre en ligne. Un CLAUDE.md qui prend plus de 60 secondes à lire est trop long.

Si vous démarrez dans un projet existant, lancez /init — Claude scannera votre dépôt et générera un fichier de départ que vous pourrez élaguer et affiner.

Niveau 3 — Commandes Slash, Skills et Hooks

Une fois que Claude connaît vos règles, le prochain déverrouillage est d’éliminer le prompting répétitif. Le niveau 3 introduit trois mécanismes qui automatisent la façon dont vous interagissez avec Claude.

Commandes Slash — Des prompts sauvegardés que vous déclenchez manuellement

Les commandes slash sont des prompts réutilisables stockés sous forme de fichiers Markdown dans .claude/commands/. Vous les invoquez avec un préfixe / et pouvez passer des arguments dynamiques en utilisant le placeholder $ARGUMENTS.

Exemple : un fichier à .claude/commands/linkedin-post.md avec le contenu « Écris trois variantes de post LinkedIn sur $ARGUMENTS. Utilise la voix de marque dans /docs/brandvoice.md. Commence par une accroche, puis un saut de ligne, puis le corps. Termine chaque post par une question ou un CTA. Moins de 200 mots. Pas de hashtags. Sauvegarde les brouillons dans /output/drafts. » — et vous l’invoquez avec /linkedin-post <sujet>.

Toute tâche que vous exécutez plus de deux fois par semaine est candidate pour une commande slash. Les commandes dans .claude/commands/ sont scopées au projet, tandis que ~/.claude/commands/ les rend disponibles pour tous vos projets.

Skills — Du contexte qui se charge automatiquement

Les Skills sont une version améliorée des commandes. Ce sont des dossiers stockés dans .claude/skills/, chacun contenant un fichier SKILL.md avec un frontmatter YAML et des instructions en Markdown, plus des fichiers de support — guides de style, exemples de sorties, documents de référence. Contrairement aux commandes, les skills ne sont pas uniquement déclenchées manuellement : Claude lit les métadonnées du skill au démarrage et charge le skill complet automatiquement quand il est pertinent pour la tâche.

Un skill de « humanisation » qui supprime les patterns d’écriture générés par l’IA, par exemple, s’activera chaque fois que Claude produit du contenu — sans que vous ayez besoin de vous souvenir de l’invoquer. Vous pouvez toujours l’appeler explicitement avec un préfixe slash si nécessaire.

La marketplace communautaire SkillsMP propose une bibliothèque croissante de skills prêts à l’emploi dans des catégories incluant le contenu, le design frontend, le SEO et l’email — tous utilisant le standard ouvert SKILL.md. Vous pouvez cloner n’importe quel skill directement dans le dossier skills de votre projet et le modifier selon vos besoins.

Hooks — Des vérifications mécaniques qui ne coûtent aucun token

Les Hooks sont des déclencheurs automatiques qui se lancent à des moments spécifiques du cycle de vie — avant qu’un outil ne s’exécute, après qu’un outil a terminé, quand Claude envoie une notification, ou au démarrage de la session. Aucun raisonnement LLM n’est impliqué. Ils sont définis dans .claude/settings.json (ou .claude/settings.local.json pour les surcharges personnelles) et exécutent des scripts shell ou des vérifications de façon programmatique.

Utilisez les hooks pour les choses qui ne nécessitent pas de réflexion : vérification de mots interdits, validation du nombre de mots, formatage automatique, application des conventions de nommage de fichiers. Ces vérifications s’exécuteront toujours, ne consommeront pas de tokens et ne pourront pas être contournées par le raisonnement de Claude.

L’aide-mémoire : Skills = comment Claude réfléchit. Hooks = ce qui se passe automatiquement autour des actions de Claude. Commandes = ce que vous déclenchez manuellement.

Niveau 4 — Serveurs MCP : connecter Claude à tout

Jusqu’à présent, Claude travaille sur des fichiers dans votre environnement local. Le niveau 4 brise cette frontière.

Les serveurs Model Context Protocol (MCP) sont des ponts entre Claude Code et les applications externes — Airtable, Notion, Slack, GitHub, bases de données, API. Au lieu de copier des données hors de vos outils et de les coller dans Claude, vous connectez les outils directement. Claude lit depuis ces outils, agit sur eux et écrit les résultats en retour.

La configuration est simple : utilisez la commande CLI claude mcp add pour enregistrer un serveur — par exemple, claude mcp add github -- npx -y @modelcontextprotocol/server-github. Cela écrit la configuration dans votre fichier .claude.json. Vous pouvez aussi éditer ce fichier directement quand des paramètres complexes sont nécessaires. Une fois configuré, utilisez la commande slash /mcp dans Claude Code pour visualiser et gérer tous les serveurs connectés.

Un exemple pratique : un pipeline de contenu stocké dans Airtable. Sans MCP, vous copiez le brief de contenu, le collez dans Claude, obtenez un résultat, le recopiez et le collez dans Airtable. Avec MCP, vous dites à Claude « récupère toutes les idées ajoutées après le 20 janvier, passe-les dans /linkedin-post, et mets à jour la colonne system message dans Airtable avec la meilleure variante. » Claude lit les enregistrements, génère les posts et écrit le résultat directement dans votre table — le tout en une seule commande.

Des milliers de configurations de serveurs MCP sont disponibles via des dépôts communautaires, couvrant les outils SaaS les plus courants. MCP supporte trois modes de transport — stdio, SSE et Streamable HTTP — avec stdio comme mode par défaut.

Niveau 5 — Le framework GSD : la planification sous stéroïdes

Pour les projets larges et au périmètre peu défini, le plus gros problème avec Claude Code est la dégradation du contexte (context rot).

À mesure que votre conversation s’allonge, la fenêtre de contexte se remplit. Quand elle atteint environ 95 % de sa capacité de 200 000 tokens, Claude compresse automatiquement le contenu ancien en résumés. La recherche de Chroma montre que les performances du modèle se dégradent de façon non uniforme à mesure que la longueur de l’input augmente, les informations les plus anciennes étant perdues en premier une fois la fenêtre de contexte remplie à plus de la moitié. Les sessions longues produisent des outputs progressivement moins bons, et la dégradation varie selon la complexité de la tâche.

Le framework GSD (Get Stuff Done) résout ce problème en conservant le contexte dans des fichiers plutôt que dans la fenêtre de conversation. Il crée un dossier .planning/ avec :

• Feuille de route (ROADMAP.md) — le projet complet découpé en phases
• Fichier d’état (STATE.md) — décisions, blocages et position qui persistent entre les sessions
• Fichiers de plan par phase — découpage atomique des tâches avec structure XML et étapes de vérification
• Résumés d’exécution par phase — rédigés après chaque phase complétée, versionnés dans l’historique
• Fichiers de tests d’acceptation utilisateur (UAT) — checklists auto-générées que Claude utilise pour vérifier la complétion avant de passer à la suite

Le mécanisme critique : GSD lance des instances fraîches de Claude pour chaque tâche, chacune recevant une fenêtre de contexte propre de 200 000 tokens. La tâche 50 s’exécute avec la même qualité que la tâche 1 — aucune dégradation. La boucle d’exécution est : Discuter, Planifier la phase, Exécuter (en « vagues » parallèles selon les dépendances), Vérifier contre l’UAT, Marquer comme terminé, Démarrer la phase suivante avec un contexte frais.

GSD est le bon outil quand le périmètre est incertain et que la profondeur de planification compte. Si votre tâche est « construire une application SaaS avec authentification, gestion de données, un pipeline de génération IA et facturation Stripe », GSD fournit la structure pour exécuter cela sans effondrement du contexte.

Niveau 6 — Équipes d’agents : sous-agents parallèles

Au niveau 5, vous supervisez un seul Claude. Au niveau 6, vous supervisez une équipe coordonnée.

Les sous-agents sont des instances spécialisées de Claude avec un contexte isolé. Chacun est défini comme un fichier Markdown dans .claude/agents/ avec une description, des outils autorisés et un prompt ciblé. Claude détecte automatiquement ces fichiers et les invoque en fonction de la correspondance avec la tâche. Ils ne partagent pas de contexte entre eux — c’est justement le but. Un contexte isolé signifie des réponses plus rapides, moins de tokens et aucune contamination croisée entre différents types de travail.

Il y a deux raisons distinctes d’utiliser des équipes d’agents :

1. La qualité par la spécialisation. Un sous-agent chercheur avec accès web collecte et synthétise l’information. Il transmet un brief de recherche à l’instance principale de Claude, qui fait office de rédacteur. Un sous-agent relecteur vérifie le résultat par rapport aux guidelines de voix de marque et aux règles de la plateforme — mais n’est autorisé qu’à suggérer des modifications, pas à les effectuer. Chaque agent fait ce pour quoi il est spécialisé.

2. La vitesse par le parallélisme. Ouvrez plusieurs fenêtres de terminal, chacune faisant tourner une instance Claude séparée sur des tâches indépendantes. Un terminal rédige des posts LinkedIn. Un autre rédige du contenu Instagram. Un troisième gère des séquences d’emails. Ils n’ont pas besoin d’interagir — vous obtenez trois outputs dans le temps qu’un seul prendrait.

Boris Cherny fait tourner cinq instances de Claude en parallèle localement, chacune utilisant son propre checkout Git pour éviter les conflits, plus cinq à dix de plus sur claude.ai simultanément — toutes utilisant Opus, le modèle le plus capable d’Anthropic. C’est le plafond de levier : pas un assistant IA, mais une équipe coordonnée travaillant en parallèle pendant que vous révisez les outputs.

Pour les environnements à haute confiance où les demandes de confirmation ralentissent tout, --dangerously-skip-permissions supprime toutes les vérifications de permissions pour la session entière. Anthropic avertit explicitement que ceci ne doit être utilisé que dans des conteneurs ou machines virtuelles isolés — jamais sur votre machine principale — en raison du risque d’actions destructives involontaires.

Niveau 7 — Pipelines entièrement autonomes : la boucle Ralph

Le niveau 7, c’est quand vous configurez, vous partez, et vous revenez trouver le travail terminé.

Le pattern Ralph englobe deux implémentations qui résolvent toutes deux le même problème : faire avancer Claude à travers une liste de tâches de façon autonome jusqu’à ce qu’une condition de complétion soit remplie.

Le plugin officiel Ralph Wiggum, inclus dans le dépôt de plugins de Claude Code, fonctionne au sein de votre session courante. Vous lancez /ralph-loop "Votre description de tâche" --completion-promise "DONE" --max-iterations 20, et le plugin utilise un Stop hook pour bloquer la sortie normale de la session, créant une boucle d’auto-référence. Claude travaille sur la tâche, essaie de quitter, reçoit le même prompt à nouveau, et répète jusqu’à ce que la promesse de complétion soit atteinte ou que la limite d’itérations soit atteinte.

L’implémentation communautaire de Ralph adopte une approche différente : elle s’exécute comme un script bash qui lance des instances fraîches de Claude Code pour chaque itération. Elle utilise un fichier prd.json comme input — une liste structurée de user stories avec descriptions, critères d’acceptation et statut réussite/échec. Chaque itération sélectionne la story incomplète de plus haute priorité, l’implémente, exécute les contrôles qualité, committe si les contrôles passent et met à jour prd.json. La mémoire persiste via l’historique Git et un fichier progress.txt.

Les deux approches partagent le même choix de conception critique : le rafraîchissement du contexte entre les itérations. Chaque tâche démarre avec une fenêtre de contexte propre, ce qui prévient directement la dégradation du contexte. Fixez toujours une limite --max-iterations pour éviter une consommation de tokens incontrôlée.

Ralph fonctionne mieux sur des tâches bien délimitées et répétitives avec des critères d’acceptation sans ambiguïté. « Écris six posts LinkedIn sur ces sujets, chacun de moins de 200 mots, sans mots interdits » est une tâche Ralph parfaite. Les critères sont mesurables, le résultat est déterministe, et il n’y a rien à comprendre — seulement du travail à faire.

GSD vs. Ralph :

• GSD est un planificateur et exécuteur. Utilisez-le quand le périmètre est flou et que le projet doit être décomposé avant de commencer le travail.
• Ralph est un pur exécuteur. Utilisez-le quand les tâches sont déjà entièrement définies et que vous avez juste besoin qu’elles soient faites — vite, sans supervision.

La progression complète en un coup d’œil

Niveau	Ce que vous débloquez	Outil principal
1	Planifier avant d’exécuter	Plan Mode (Shift+Tab ×2 ou /plan)
2	Claude suit vos règles	CLAUDE.md
3	Éliminer le prompting répétitif	Commandes, Skills, Hooks
4	Se connecter à vos applications	Serveurs MCP
5	Gérer de grands projets sans effondrement du contexte	Framework GSD
6	Agents spécialisés en parallèle	.claude/agents/
7	Pipelines nocturnes entièrement autonomes	Boucle Ralph

La plupart des développeurs utilisant Claude Code aujourd’hui opèrent aux niveaux 1 ou 2 — et c’est déjà précieux. Mais l’architecture décrite aux niveaux 4 à 7 représente une relation fondamentalement différente avec les outils IA : une relation où vous concevez des systèmes et supervisez les résultats, plutôt que de prompter et d’attendre.

La transition d’opérateur à architecte est ce qui distingue les équipes qui obtiennent un gain de productivité de 2x de celles qui atteignent 10x.

Sources et lectures complémentaires

• Documentation officielle de Claude Code — Anthropic
• Le workflow Claude Code de Boris Cherny — VentureBeat
• Dans les coulisses du workflow du créateur de Claude Code — InfoQ
• Model Context Protocol : Introduction — MCP Official
• Recherche sur la dégradation du contexte — Chroma
• Framework GSD — GitHub
• Vaincre la dégradation du contexte avec GSD — The New Stack
• Plugin Ralph Wiggum — Anthropic GitHub
• Boucle autonome Ralph — snarktank GitHub
• SkillsMP : Marketplace de Skills pour agents
• Dépôt GitHub de Claude Code — Anthropic