Saviez-vous que Claude ne dispose pas d’une mémoire interne persistante entre les interactions; il dépend de l’historique de la conversation qui est renvoyé au modèle à chaque nouveau message ?
En pratique, pendant une session :
Claude conserve le contexte parce que le système réexpédie l’historique;
Il peut se souvenir des décisions prises précédemment;
Il peut poursuivre une tâche complexe;
Il peut faire référence à des fichiers lus auparavant.
Mais cela se produit parce que l’historique est renvoyé, non parce que le modèle aurait stocké quelque chose en interne.
La consommation de jetons n’est pas causée uniquement par ce que vous avez tapé. Beaucoup de développeurs pensent qu’un prompt de 20 mots ne coûte que 20 mots.
En réalité, lorsque la session contient déjà :
10 fichiers chargés;
30 réponses précédentes;
des résultats d’outils;
des spécifications;
CLAUDE.md;
Ce prompt de 20 mots peut provoquer le renvoi de centaines de milliers de jetons.
C’est exactement pourquoi des commandes comme /compact, des sessions neuves et de bons fichiers CLAUDE.md ont tendance à générer une économie significative de jetons.
Ainsi, à chaque fois que vous envoyez un message, toute la conversation est renvoyée à zéro : vos invites, les réponses de Claude et tous les résultats des outils. Tout cela, à chaque fois. Il ne lit pas un journal ; il est littéralement en train de retraiter tout l’historique à chaque interaction.
C’est ainsi que fonctionnent les transformers.
Par conséquent, le comptage des jetons des messages n’est pas seulement « ce que vous avez tapé ». C’est le total accumulé de tout ce qui a été dit ou lu dans la session, renvoyé à répétition.
Alors que dois-je faire pour éviter cela ?
Beaucoup de personnes passent à côté de cela : l’action la plus impactante que vous pouvez réaliser avant d’écrire une seule ligne de code est d’exécuter la commande /init pour générer un fichier CLAUDE.md à la racine du projet.
Claude lit automatiquement ce fichier au début de chaque session.
Pensez-y comme à vos instructions permanentes — ces éléments que vous expliqueriez normalement dès le départ à chaque fois.
Il existe plusieurs lieux de recherche, vérifiés dans cet ordre :
~/.claude/CLAUDE.md — chargé pour tous les projets, dans toutes les sessions (global)
/votre/projet/CLAUDE.md — chargé lorsque vous démarrez Claude Code dans ce répertoire
Fichiers CLAUDE.md dans les sous-répertoires — chargés au fur et à mesure que Claude navigue dans ces dossiers
Le coût en jetons du modèle
Le CLAUDE.md est chargé tout au long de la session et reste dans la fenêtre de contexte pendant toute la durée. Il n’est ni chargé à la demande ni retiré quand il n’est pas utilisé.
Un fichier CLAUDE.md de 2 000 jetons coûte 2 000 jetons, que vous envoyiez 2 ou 200 messages.
Chaque instruction ajoutée est payée dans toutes les sessions pour toujours. Un CLAUDE.md surchargé (5 000 jetons et plus) réduit significativement votre contexte de travail effectif.
Les fichiers dans les sous-répertoires s’accumulent. Cela peut être utile dans les monorépertoires. Divisez votre CLAUDE.md par projet plutôt que d’en avoir un seul. Ils ne sont pas chargés simultanément ; ils le sont au fur et à mesure que Claude navigue dans les répertoires.
Un CLAUDE.md bien structuré pour un projet réel contient généralement entre 300 et 600 jetons. Si le vôtre dépasse 2 000 jetons, il est probable que vous stockiez l’état des tâches ou de la documentation qui ne devrait pas être là.
Exemple d’un CLAUDE.md :
# CLAUDE.md ## Stack - .NET 10 - ASP.NET Core - C# - Entity Framework Core - SQL Server ou SQLite - Blazor Web App lorsque applicable ## Tests - xUnit - FluentAssertions - Moq ## Architecture - Controllers appellent Services - Services contiennent les règles métiers - Repositories sont responsables de l’accès aux données - Ne jamais accéder au DbContext directement depuis les Controllers - Toujours utiliser l’Inversion de Contrôle - Respecter le principe de responsabilité unique (SRP) ## Contraintes - Ne jamais utiliser `dynamic` sans justification explicite - Activer les Nullable Reference Types - Éviter la logique métier dans les Controllers, Components ou Pages - Éviter les méthodes trop longues (privilégier les méthodes petites et ciblées) - Éviter la duplication de code - Préférer un code lisible plutôt que des solutions excessivement complexes ## Entity Framework Core - Utiliser les migrations pour les changements de base de données - Privilégier les requêtes asynchrones - Éviter les requêtes N+1 - Utiliser `AsNoTracking()` pour les requêtes en lecture seule - Les configurations Fluent API doivent rester dans des classes séparées ## Conventions de nommage - Classes : PascalCase - Interfaces : préfixe `I` (`IClienteService`) - Méthodes : PascalCase - Propriétés : PascalCase - Champs privés : `_camelCase` - Variables locales et paramètres : `camelCase` - Constantes : PascalCase - Fichiers : même nom que la classe principale ## Blazor - Composants en PascalCase - La logique complexe doit être déplacée vers les Services - Éviter le code trop long dans les fichiers `.razor` - Préférer les composants réutilisables - Utiliser un rendu adapté au contexte (SSR, Server, WebAssembly ou Auto) ## Code - Générer le code selon les normes officielles de Microsoft - Préférer la simplicité et la maintenabilité - Toujours prendre en compte les performances, la sécurité et les tests - Expliquer les choix architecturaux lorsque cela n’est pas évident |
Pour les projets utilisant Blazor Web App (.NET 9/10), j’ajouterais aussi une section spécifique pour le rendu et le partage du code :
| ## Blazor Web App – Préférer des composants réutilisables |
Ensuite, je vais présenter quelques conseils pour optimiser l’utilisation des jetons qui peuvent varier selon l’outil utilisé. Nous nous concentrons sur Claude Code.
1. Utilisez /context pour afficher l’utilisation de la fenêtre de contexte
Vous pouvez exécuter /context et Claude affichera tout ce qui occupe votre fenêtre de contexte : fichiers ouverts, documents joints, définitions d’outils, messages de la conversation et le prompt système.
Il renvoie une vue structurée avec le compte de jetons par élément et l’utilisation cumulée par rapport à la limite de la fenêtre.
Claude charge fréquemment des fichiers dans le contexte qui ne sont plus nécessaires. Ainsi, cette commande est utile pour :
– Identifier les fichiers chargés inutilement
– Découvrir quand une conversation est devenue trop longue
– Décider entre compacter ou démarrer une nouvelle session
– Mieux comprendre ce qui se passe
Pensez-y comme à un profiler de mémoire de votre session.
2. Utilisez /compact pour sauvegarder votre session
La solution pratique est plus simple qu’elle ne paraît: « Commencez dans un nouvel onglet du terminal ».
De plus, évitez de coller des fichiers entiers alors qu’un extrait suffit. Lorsque une session devient longue, résumez l’essentiel et emmenez uniquement cela dans une nouvelle discussion.
Pour cela, exécutez /compact.
Il résumera toute la conversation en une représentation compacte et structurée, enregistrant les décisions prises, le code écrit, les questions en suspens et l’état actuel de la tâche. Puis, il continue à partir de ce résumé comme base nouvelle.
La compression est intentionnellement perte.
Ce qui est Conservé :
Decisions architecturales et justifications
Fichiers modifiés et modifications réalisées
État actuel de la tâche et prochaines étapes
Erreurs rencontrées et comment elles ont été résolues
Blocages en suspens
Ce qui est Jettié :
Chaînes intermédiaires de raisonnement
Approches abandonnées
Sorties brutes des outils
Une erreur courante est d’utiliser /compact seulement lorsque Claude commence déjà à oublier les choses. C’est une idée fausse.
Une session saine produit un meilleur résumé qu’une session dégradée. Exécutez /compact à la fin d’une phase distincte du travail, pas lorsque vous remarquez une dégradation.
Si vous avez complètement terminé une tâche et devez commencer quelque chose sans lien avec elle, utilisez /clear et non /compact.
3. Utilisez des commandes personnalisées et cessez de vous répéter
Les commandes personnalisées définissent des raccourcis nommés pour des suites d’instructions en plusieurs étapes.
Lorsqu’elles sont invoquées, Claude exécute toute la suite sans avoir à réinterpréter l’intention en langage naturel.
Les commandes sont stockées sous forme de définitions structurées (nom, description et étapes), que Claude lit au début de la session avec le CLAUDE.md.
Les invites en langage naturel sont probabilistes. La même invite peut générer des comportements légèrement différents à chaque exécution.
Exemple de commande personnalisée : /test-and-fix
Au lieu d’écrire toujours un prompt long comme :
Exécutez tous les tests du projet.
Corrigez les erreurs de compilation détectées.
Corrigez les avertissements de l’analyseur.
Exécutez à nouveau les tests.
Montrez un résumé des modifications.
Vous définissez une commande : test-and-fix et vous lui associez cette suite d’instructions.
Claude Code prend en charge les Custom Commands via des fichiers Markdown dans le dossier .claude/commands.
Par exemple, vous pourriez créer :
.claude/
└── commands/
└── test-and-fix.md
Et créer un fichier markdown ainsi :
| — description: Corrige les erreurs de compilation et les tests dans les projets .NET — # Test and Fix .NET Executez les étapes suivantes : 1. Exécutez : “`bash 2. Identifiez : – erreurs de compilation 3. Résolvez les problèmes trouvés. 4. Validez : “`bash 5. Exécutez de nouveau : “`bash 6. Générer un rapport contenant : – erreurs corrigées Règles : – Ne pas utiliser dynamic |
Ensuite vous pourriez exécuter : /test-and-fix et Claude exécutera cette séquence.
Où pourriez-vous appliquer l’utilisation de commandes personnalisées ?
Exécuter les tests + corriger les erreurs de type + lancer le lint en séquence
Générer des composants selon mes conventions de dossiers
Écrire des messages de commit selon les normes de l’équipe
Effectuer des validations avant le déploiement (bien que les hooks puissent aussi être utilisés)
4. Le mode de raisonnement est activé par défaut
Avant de fournir une réponse, Claude lance un processus interne étendu de raisonnement.
Il travaille sur le problème, envisage des approches et évalue des alternatives. Ce raisonnement se fait en arrière-plan, sans que le problème, petit ou grand, n’ait besoin d’être explicitement résolu.
Si vous n’en avez pas besoin, désactivez-le.
a- Sans raisonnement approfondi
Si vous demandez : « Renomme la variable customerList en customers »
Le modèle peut répondre presque immédiatement.
Il n’a pas besoin d’analyser l’architecture, les dépendances ou les alternatives.
C’est une tâche simple.
b- Avec raisonnement approfondi
Si vous demandez : « Analysez cette architecture Blazor et proposez des améliorations »
Le modèle peut prendre plus de temps :
évaluer des alternatives ;
analyser des compromis ;
vérifier les schémas ;
planifier la solution.
Cela produit des réponses meilleures, mais consomme plus de ressources.
5. Ne interrompez pas la tâche principale, utilisez /btw
Imaginez que vous travaillez sur une tâche importante : mettre en œuvre l’authentification JWT pour cette API ASP.NET Core.
Claude :
lit des fichiers;
analyse des services;
comprend l’architecture;
planifie des modifications.
Au milieu de cela, vous vous souvenez d’autre chose et demandez : « D’ailleurs, quelle est la différence entre IEnumerable et IQueryable ? »
Maintenant, la conversation principale est interrompue.
Sans /btw :
cette question entre dans l’historique ;
la réponse entre dans l’historique ;
les deux seront renvoyés dans tous les messages futurs.
Avec /btw :
vous obtenez la réponse ;
elle ne « pollue » pas la conversation principale.
Alors la façon correcte de faire est : /btw quelle est la différence entre IEnumerable et IQueryable ?
6. Choisissez le modèle approprié
La plupart des gens ouvrent Claude Code, se contentent du modèle par défaut et n’y pensent plus.
En mars 2026, le standard est :
Sonnet dans le plan Pro
Opus dans le plan Max
Voici une règle simple :
Opus -> Cerveau grand, très coûteux.
Utilisez-le uniquement pour planifier des problèmes difficiles en mode planification.
Haiku -> Cerveau petit.
Bon pour les tâches simples ou les questions rapides.
Ce n’est pas idéal pour la programmation.
Sonnet -> Cerveau suffisamment bon.
Utiliser pour :
Implémentation des fonctionnalités
Refactorisations
Tests
Revues de code
Pour basculer entre les modèles, utilisez : /model
7. Cessez d’être paresseux et écrivez des spécifications, pas des prompts aléatoires
La façon dont vous écrivez le prompt influence directement la quantité de jetons générés.
Des prompts vagues sollicitent des réponses verbeuses et entraînent une consommation inutile de jetons simplement pour tenter de découvrir à quel fichier vous faites référence.
Si vous avez déjà une idée de ce que vous devez faire — et vous devriez l’avoir — écrivez quelque chose comme :
Corrigez le bug [description courte] dans @fichier qui provoque [résultat inattendu] plutôt que [résultat attendu]. eux.
8. MCPs ne sont pas la « balle de prata »
La plupart des développeurs ajoutent des serveurs MCP au fur et à mesure de leur découverte.
Supabase ? On en ajoute.
GitHub ? On en ajoute.
Chrome DevTools ? On en ajoute.
Figma ? On en ajoute.
Le problème est que chaque MCP connecté charge toutes ses définitions d’outils et ses schémas dans la fenêtre de contexte au début de chaque session, que vous les utilisiez ou non.
Ces définitions ne sont pas petites. Parfois elles consomment des milliers de jetons simplement en restant là.
Ajoutez plusieurs MCP et les chiffres montent rapidement. Supprimez ce qui n’est pas nécessaire.
9. Travaillez par « contextes délimités » et non par la solution entière
Je vois beaucoup de développeurs faire ceci :
> « Analysez ma solution entière. »
ou
> « Implémentez la fonctionnalité X. »
Dans une solution comportant plusieurs couches. Cela pousse Claude à charger un nombre énorme de fichiers.
Une stratégie meilleure consiste à travailler par contexte :
Exemple peu satisfaisant :
« Implémentez le système d’actualités. »
Exemple meilleur :
« Nous travaillons uniquement sur le contexte Actualités.
Fichiers autorisés :
– Actualité.cs
– INoticiaRepository.cs
– ActualitéRepository.cs
– NoticiasService.cs
Ignorez le reste de la solution. »
En pratique :
moins de fichiers lus ;
moins d’appels d’outils ;
moins de contexte chargé ;
moins de jetons consommés.
Pour les projets Blazor et ASP.NET Core, cela fait une différence considérable.
10. Utilisez des spécifications hiérarchiques (SDD en couches)
Cela, je le vois rarement fait par les développeurs. Beaucoup créent une spec géante :
spec.md
– domaine
– base de données
– UI
– API
– authentification
– tests
– déploiement
avec des milliers de lignes.
Claude finit par tout charger pour exécuter une tâche simple.
Une meilleure approche :
/specs
overview.md
domaine/
joueurs.md
parties.md
sélections.md
frontend/
dashboard.md
actualités.md
backend/
api.md
authentification.md
Quand vous travaillez sur les actualités, utilisez : @specs/frontend/noticias.md
Quand vous travaillez sur l’authentification : @specs/backend/authentication.md
Plutôt que de charger 10 000 lignes, vous chargez 300 lignes.
Astuce bonus
Je considère celle-ci comme l’une des plus importantes pour les projets .NET.
Ne demandez pas le code immédiatement
Beaucoup de personnes font : « Implémentez la fonctionnalité ».
Le Claude :
analyse ;
planifie ;
génère le code ;
crée les tests ;
modifie des fichiers.
Tout cela en une seule interaction.
Une alternative beaucoup plus économique :
Étape 1
Analysez et proposez un plan.
Ne générez pas le code.
Étape 2
Implémentez uniquement la couche Domain
Étape 3
Maintenant, implémentez uniquement l’Infrastructure.
Étape 4
Implémentez maintenant uniquement les tests.
La consommation totale est généralement plus faible, car vous évitez des générations énormes qui seront ensuite rejetées.
Conclusion
En fin de compte, économiser des jetons ne signifie pas seulement réduire les coûts ou éviter d’atteindre des limites d’utilisation.
Cela signifie travailler plus efficacement avec l’IA. Maintenir le contexte mince, utiliser de bonnes spécifications, organiser des instructions permanentes et diviser des problèmes complexes en étapes plus petites aide le modèle à produire des réponses meilleures et plus cohérentes.
Plus votre utilisation du contexte sera intentionnelle, plus la valeur que vous retirerez de l’outil sera élevée.
