Claude Code : le prompt à coller pour ne jamais manquer de tokens

Une ligne dans ton contexte système = plus jamais de réponse tronquée à mi-chemin

Tu écris une grosse fonction. Claude Code commence bien, génère les premières lignes, pis… s’arrête. Réponse tronquée. Tu relances, tu perds le fil, tu recolles, tu perds encore du contexte. C’est exactement ce problème qu’on règle aujourd’hui, avec un seul prompt à coller une fois. Aujourd’hui tu vas apprendre à :

• Comprendre pourquoi Claude Code coupe ses réponses avant la fin
• Coller le prompt exact au bon endroit pour modifier ce comportement
• Décortiquer ce que ce prompt signale à Claude Code et pourquoi ça marche
• Identifier les scénarios où le gain est le plus marqué
• Être honnête sur ce que cette astuce ne peut pas faire

Ce dont t’as besoin avant de commencer

1. Un compte Claude avec accès à Claude Code

Claude Code est inclus dans tous les plans payants de Claude, à partir du plan Pro à 20 $US/mois. Si tu es sur le plan gratuit, tu n’y as pas accès. Assure-toi que ton compte est actif et que tu peux lancer claude dans ton terminal.

2. Claude Code installé et fonctionnel en local

Tu dois avoir @anthropic-ai/claude-code installé globalement via npm (ou l’équivalent sur ton gestionnaire de paquets). Si tu tapes claude --version dans ton terminal et que ça retourne quelque chose, tu es bon.

3. Un fichier CLAUDE.md dans ton projet (ou la configuration système)

C’est là que le prompt va vivre. Claude Code lit automatiquement ce fichier au démarrage de chaque session dans un répertoire. Si tu n’en as pas, tu vas en créer un. C’est un simple fichier Markdown à la racine de ton projet.

4. Compréhension de base de Markdown

Le fichier CLAUDE.md est en Markdown. Tu n’as pas besoin d’être expert : les headers ## et les listes à puces suffisent pour structurer tes instructions.

Le workflow, étape par étape

Là, écoute. Claude Code opère dans une fenêtre de contexte qui a une limite physique. Cette limite est massive (et Anthropic ne la publie pas précisément pour chaque version), mais ce n’est pas la seule contrainte en jeu. Le vrai problème, c’est la limite sur les tokens de sortie (output tokens). Claude peut lire beaucoup, mais il est configuré par défaut pour produire des réponses d’une certaine longueur. Quand tu lui demandes de générer un fichier de cinq cents lignes, il peut décider de s’arrêter à mi-chemin, pas parce qu’il ne peut pas continuer, mais parce que son comportement par défaut est calibré pour des réponses conversationnelles normales.

En plus de ça, Claude Code peut aussi anticiper qu’une longue génération risque de dépasser les limites de son contexte combiné (entrée + sortie) et choisir de livrer une version incomplète plutôt que de planter à mi-chemin. C’est un comportement de sécurité. Le problème, c’est que ce comportement de sécurité te laisse avec du code à moitié écrit.

Ce qui rend ça particulièrement frustrant : le modèle est conscient qu’il coupe. Il sait. Il ne te le dit pas toujours clairement, il te livre juste quelque chose d’incomplet avec parfois un petit commentaire comme // ... reste de la fonction. C’est ce commentaire-là qui est le signal que tu aurais eu besoin du prompt ci-dessous.

Va à la racine de ton projet dans le terminal. Vérifie si un fichier CLAUDE.md existe déjà :

ls -la | grep CLAUDE

S’il n’existe pas, crée-le :

touch CLAUDE.md

Le truc c’est que ce fichier est différent d’un .cursorrules ou d’un fichier de config d’autre éditeur IA. Claude Code lui accorde un statut particulier : il est injecté automatiquement dans le contexte système de chaque session lancée dans ce répertoire. Tu n’as pas besoin de le rappeler à chaque fois. Tu le configures une fois, ça s’applique à toutes tes sessions dans ce projet. Si tu veux un comportement global qui s’applique à tous tes projets, Claude Code supporte aussi un fichier de configuration dans ton répertoire home (~/.claude/CLAUDE.md selon la documentation). Vérifie la doc officielle pour le chemin exact selon ta version.

Ouvre ton CLAUDE.md dans ton éditeur. Ajoute cette section, idéalement en haut du fichier ou dans une section dédiée au comportement de génération :

## Comportement de génération de code
Quand tu génères du code, des fichiers ou du contenu long, tu dois TOUJOURS compléter la sortie jusqu'à la fin, sans jamais tronquer, résumer ou ajouter des commentaires placeholder comme `// ... reste du code`, `// TODO: continuer`, ou `/* reste de l'implémentation */`.
Si tu anticipes que la sortie sera longue :
- Continue jusqu'à la fin du fichier ou de la fonction demandée
- Si tu manques de place dans une seule réponse, divise le fichier en sections logiques et annonce clairement : « Voici la partie 1/N. Demande-moi la partie 2 pour continuer. »
- Ne laisse JAMAIS du code partiel sans indiquer explicitement que c'est intentionnel et qu'il y a une suite
Ne sacrifie jamais la complétude pour la brièveté. Un fichier incomplet est inutilisable.

Pourquoi cette formulation précise ? Chaque partie fait un travail différent. La première phrase élimine les comportements d’échappement les plus communs. Claude Code a plusieurs façons de “tricher” sur une sortie longue : il peut tronquer sans avis, résumer la fin, ou pire, insérer des commentaires placeholder qui semblent légitimes mais qui sont du code non fonctionnel. En nommant explicitement ces patterns, tu les bloques. La deuxième partie (les bullets) lui donne une sortie de secours acceptable. Au lieu de tronquer silencieusement, il va maintenant annoncer proactivement qu’il y a une suite. C’est un comportement beaucoup plus honnête et praticable pour toi. La dernière phrase établit une priorité explicite : la complétude l’emporte sur la brièveté. Claude Code essaie d’être concis par défaut. Tu l’informes que dans ce projet, cette règle est inversée.

Lance une nouvelle session Claude Code dans ton projet :

claude

Dès l’ouverture, demande directement :

Quelles instructions as-tu reçues concernant la génération de code long?

Si Claude Code te répond en paraphrasant les règles que tu as écrites dans CLAUDE.md, c’est bon. Il les a lues. Si sa réponse est vague ou ne mentionne pas tes instructions, deux causes probables :

1. Tu as créé le fichier mais tu n’as pas relancé une nouvelle session Claude Code (les instructions sont lues au démarrage, pas en cours de session)
2. Le fichier n’est pas à la racine du répertoire dans lequel tu as lancé claude

Pour valider que l’astuce fonctionne vraiment, tu as besoin d’un test qui pousse la limite. Voici trois types de demandes qui sont particulièrement efficaces pour le test : Génération d’un fichier complet avec structure complexe : demande à Claude Code de créer un fichier de configuration complet avec commentaires pour un outil que tu utilises (un webpack.config.js détaillé, un fichier de définitions de types TypeScript exhaustif, une suite de tests complète pour un module existant). Refactoring d’un fichier existant : ouvre un fichier long et demande à Claude Code de le réécrire avec des améliorations spécifiques. C’est le scénario où les coupures sont les plus douloureuses : tu te retrouves avec une version à moitié refactorisée qui compile mais qui a une logique incohérente. Génération de documentation technique : demande un fichier README complet avec toutes les sections, ou une documentation d’API exhaustive pour un module.

Dans les scénarios qui fonctionnent, tu vas remarquer un changement de comportement net. Au lieu de s’arrêter avec un commentaire placeholder, Claude Code va soit : compléter la sortie entière, soit annoncer clairement « Voici la partie 1 de 3. Demande-moi la partie 2 pour continuer. » Les deux comportements sont acceptables. Le premier est préférable. Le second est honnête et traçable.

Le prompt que je t’ai donné est volontairement générique. Il couvre la majorité des cas. Mais tu peux le raffiner selon ce que tu construis. Si tu travailles sur des projets avec beaucoup de fichiers interdépendants (une codebase volumineuse où un changement dans un fichier affecte plusieurs autres), ajoute cette ligne :

- Quand une modification affecte plusieurs fichiers, liste explicitement TOUS les fichiers qui doivent changer avant de commencer à générer le premier.

Ça force Claude Code à planifier avant d’exécuter, ce qui évite un autre problème fréquent : il commence à modifier le fichier A, s’arrête à mi-chemin, et tu réalises que le fichier B qui dépend de A n’t a pas été mis à jour. Si tu fais beaucoup de génération de tests unitaires, où les fichiers de tests peuvent être très longs :

- Pour les suites de tests, génère tous les cas de test annoncés sans en sauter. Un `describe` annoncé doit contenir tous ses `it` / `test`.

Si tu fais du prototypage rapide où la complétude absolue est moins critique que la vitesse :

- En mode prototypage (quand je préfixe ma demande par [PROTO]), tu peux livrer une implémentation partielle mais tu dois lister explicitement ce qui manque à la fin.

Cette dernière variante est utile parce qu’elle te donne un mode de secours : parfois tu veux vraiment juste un squelette rapide. Tu ne veux pas que Claude Code génère cinq cents lignes de tests complets quand tu testes juste une idée.

Le hic

Soyons clairs. Cette astuce est utile. Elle change un comportement frustrant en comportement gérable. Mais elle ne fait pas de miracles, et si tu l’appliques sans comprendre ses limites, tu vas être déçu à un moment. Elle ne repousse pas la limite physique du contexte. Si ton fichier est plus long que ce que le modèle peut physiquement produire en une seule réponse, le prompt ne va pas magiquement doubler la capacité de sortie. Ce qu’il fait, c’est forcer Claude Code à être transparent sur cette limite : au lieu de tronquer silencieusement, il va annoncer qu’il y a une suite. Tu passes d’un problème invisible à un problème visible et gérable. C’est déjà beaucoup. Elle ne règle pas les problèmes de cohérence sur plusieurs sessions. Si tu divises la génération d’un fichier sur plusieurs échanges (partie 1, partie 2, partie 3), Claude Code peut perdre le fil de ce qu’il a déjà généré. La fenêtre de contexte a une limite. Si tes échanges précédents dans la session sont très longs, les instructions dans CLAUDE.md restent actives, mais le modèle peut avoir moins de “mémoire de travail” disponible pour suivre un fil narratif complexe. Elle ne compense pas un prompt de tâche mal formulé. Si tu demandes « réécris tout mon projet », tu vas avoir des problèmes même avec le meilleur CLAUDE.md du monde. L’astuce optimise la sortie d’une tâche bien définie. Elle ne compense pas une tâche trop vague ou trop large. Découpe tes demandes en unités cohérentes (un fichier à la fois, une fonction à la fois) et l’astuce sera beaucoup plus efficace. Elle peut ralentir les réponses courtes. Si Claude Code interprète chaque demande comme potentiellement longue, il peut être plus verbeux qu’avant sur des échanges conversationnels simples. C’est pourquoi la variante [PROTO] mentionnée plus haut est utile : tu lui donnes un signal explicite pour les modes différents. Claude Code peut ignorer les instructions dans certaines conditions. C’est rare, mais ça arrive. Si la session est très longue et que la fenêtre de contexte est presque pleine, les instructions du CLAUDE.md peuvent être “poussées” vers la fin de la mémoire disponible et avoir moins d’influence. Si tu remarques que le comportement de coupure revient après une longue session, relance une nouvelle session claude plutôt que de continuer la même.

Elle ne remplace pas la gestion de projet. Si tu construis quelque chose de complexe avec Claude Code, tu as besoin d’une stratégie de découpe des tâches, pas juste d’un prompt qui dit « va jusqu’au bout ». L’astuce est un filet de sécurité. Elle n’est pas une méthode de travail.

Quelques trucs bons à savoir

• Le fichier CLAUDE.md est versionnable. Commite-le dans ton dépôt Git. Ton équipe bénéficiera des mêmes instructions sans que chacun ait à les reconfigurer.
• Les instructions dans CLAUDE.md s’accumulent. Si tu as un fichier global dans ton home et un fichier par projet, Claude Code les lit tous les deux. Fais attention aux conflits : une instruction dans le fichier projet peut contredire une instruction globale. En général, le fichier le plus spécifique (projet) a la priorité, mais vérifie ce comportement dans la doc de ta version.
• Claude Code supporte le protocole MCP. Si tu branches des outils externes via MCP, tes instructions dans CLAUDE.md s’appliquent aussi aux interactions avec ces outils. Un outil MCP qui génère du code sera soumis aux mêmes règles de complétude que le reste.
• Le prompt anti-coupure est particulièrement efficace sur les fichiers de configuration. Les fichiers comme docker-compose.yml, les configs webpack, les définitions de schémas de base de données, ont tendance à être longs et très structurés. Une coupure à mi-chemin produit un fichier invalide plutôt qu’incomplet. C’est le pire cas. Cette astuce est ta priorité no. 1 pour ce type de génération.
• Sur les plans Max, tu as un quota d’utilisation beaucoup plus élevé selon ton plan (Max 5x à 100 $US/mois, Max 20x à 200 $US/mois). Si tu travailles régulièrement sur des projets volumineux, le plan Pro à 20 $US/mois peut atteindre ses limites plus rapidement. L’astuce ne change pas les limites de ton plan, elle optimise l’utilisation de chaque échange.
• Teste le prompt sur une tâche simple avant de l’appliquer à quelque chose de critique. Lance Claude Code, demande-lui de générer un fichier utilitaire de taille moyenne, et vérifie que le comportement correspond à tes attentes. Mieux vaut découvrir un problème de configuration sur un test bas-risque.
• Si Claude Code annonce « partie 1 de N », nota ce N et suivi-le. Il arrive que le modèle sous-estime le nombre de parties. Si tu as demandé une suite de tests et qu’il dit « partie 1 de 2 », prépare-toi à peut-être avoir besoin d’une partie 3. Ce n’est pas une erreur de l’astuce, c’est une estimation approximative du modèle.

Check-list finale

Verdict + prochaines étapes

Cette astuce vaut largement cinq minutes de setup. Elle ne repousse pas les limites physiques du modèle, mais elle convertit un comportement silencieusement frustrant (coupure invisible) en comportement explicite et gérable (annonce de suite). Pour quiconque génère des fichiers de code de longueur non triviale avec Claude Code, c’est la première chose à coller dans CLAUDE.md avant n’importe quelle autre configuration. Le gain est particulièrement marqué si tu travailles sur du refactoring de modules existants, de la génération de suites de tests exhaustives, ou de la configuration de projets complexes avec plusieurs fichiers interdépendants. Ce sont les scénarios où une coupure à mi-chemin te coûte le plus de temps à rattraper. Prochaine étape concrète : ouvre ton projet principal, crée ou complète ton CLAUDE.md avec le prompt ci-dessus, et teste avec la prochaine tâche de génération longue que tu avais déjà prévue. Tu verras la différence sur la première session.

Texte par David Cyr

David Cyr

L'Opérateur AI · Fondateur Taverne AI

Opérateur québécois. J'ai construit LeadLoup, un mandat acheteur véhicules pour Complexe Kia, et plusieurs systèmes IA en production. À la Taverne, je teste des outils qu'on me paie pour utiliser, et je dis si c'est utile ou si c'est de la marde.

À propos·Méthodologie