Claude Code : auditer ses CLAUDE.md et ses skills pour consommer moins de tokens

Points clés de cet article :

• La commande /claude-api prompt-audit relit vos CLAUDE.md, AGENTS.md, skills, commandes et sous-agents pour un modèle cible, puis propose un diff.
• À chaque mise à jour du modèle, les CLAUDE.md, skills et agents se reprennent : une consigne écrite pour l'ancien coûte des tokens à chaque requête, et le nouveau l'applique plus largement qu'elle ne le demandait.
• Avec Opus 5.5, notre CLAUDE.md d'équipe est passé de 404 à 175 lignes.
• L'audit ne modifie rien sans demande explicite, et laisse à votre arbitrage les contradictions entre fichiers et les faits périmés.
• L'effort et le modèle de la session se règlent à la main, avec /effort et /model, avant le premier message.
• RTK compacte la sortie des commandes : en trois mois, rtk gain relève 1,34 milliard de tokens économisés sur le poste de notre directeur technique, et 26 % de tokens en moins sur les sorties ordinaires.
• Une automatisation IA se maintient : ses consignes se relisent à chaque nouveau modèle, et ses permissions se vérifient.

Votre CLAUDE.md a commencé à quelques lignes. Une règle s'y est ajoutée après chaque erreur, une procédure après chaque livrable raté, un sous-agent pour chaque type de tâche. Claude Code charge aujourd'hui tout cela au démarrage de chaque session et le relit à chaque requête, y compris quand vous lui demandez de renommer une variable.

La facture en tokens se voit. Le comportement change aussi, et ça se remarque moins vite. Les modèles récents suivent les consignes de plus près et plus littéralement que ceux pour lesquels elles ont été écrites. Une règle en majuscules, ajoutée parce qu'un ancien modèle l'oubliait, se déclenche maintenant là où elle n'a rien à faire. Une procédure pas à pas, écrite pour un modèle qui planifiait mal, empêche le modèle actuel de choisir un meilleur ordre.

La commande /claude-api prompt-audit

Dans Claude Code, la commande est /claude-api prompt-audit. Elle lit tout ce qui parvient au modèle sous forme de texte : CLAUDE.md, AGENTS.md, fichiers de règles, skills, commandes personnalisées, définitions de sous-agents, styles de sortie. Chaque consigne est confrontée au modèle cible, au projet et aux autres fichiers.

Elle produit un rapport et un diff. Dans le rapport, chaque constat donne son emplacement (fichier:ligne), le motif reconnu, la raison pour laquelle la consigne ne sert plus et un niveau de confiance. Le diff propose les modifications correspondantes.

Par défaut, la commande s'arrête au diff proposé. Pour qu'elle modifie les fichiers, la demande doit le dire et nommer le périmètre :

/claude-api prompt-audit
Audite ~/.claude et ~/projets/facturation pour Opus 5.5 et applique les corrections.

La configuration utilisateur (~/.claude) et tout fichier situé hors du répertoire courant ne sont audités que si la demande les nomme. Une modification à cet endroit touche tous vos projets à la fois, et le rapport le signale.

Pour une application qui appelle l'API Claude (choix du modèle, réflexion, tool_choice), la commande voisine est /claude-api migrate.

Ce que l'audit relève dans un CLAUDE.md et ses skills

Un CLAUDE.md trop long. Le fichier est chargé à chaque session, et sa taille se paie sur chaque requête. Visez deux cents lignes environ. Une procédure qui ne sert qu'à certains moments, comme la mise en forme d'un document ou le déroulé d'un déploiement, se relit à chaque session, y compris pour corriger un test. L'audit propose de la déplacer dans une skill, que Claude ne charge que lorsque la tâche la demande. Avec Opus 5.5, notre CLAUDE.md d'équipe est passé de 404 à 175 lignes, et notre CLAUDE.md global de 268 à 198.

Des consignes écrites en criant. « RÈGLE ABSOLUE », majuscules, croix rouges : ces marques servaient à se faire entendre d'un modèle qui appliquait mal une règle. Opus 5.5 les prend au mot et les étend à des cas voisins. L'audit les ramène à un volume normal sans toucher au fond, à condition de lui dire quelles règles sont des choix métier. Chez nous, ne jamais afficher de TVA dans un devis en fait partie : nous l'avons déclaré avant de lancer l'audit, et la règle est restée.

Des consignes qui se contredisent. Un paragraphe demande de passer en mode plan pour toute tâche non triviale et d'attendre la validation du plan. Un autre, ou une skill, demande de corriger un bug en autonomie. À chaque bug, le modèle arbitre entre les deux, et le résultat change d'une session à l'autre. La réécriture tranche : une fonctionnalité ou un choix d'architecture passe par un plan validé, un bug ou un test en échec se corrige directement.

Des faits périmés. Un sous-agent retiré reste cité dans d'autres fichiers, une skill renvoie à un document supprimé ou décrit un hook qui n'existe plus. Le modèle les cherche, ne les trouve pas, et dépense des tokens à comprendre pourquoi.

Des sous-agents sans modèle déclaré. Un sous-agent dont la définition n'indique pas de model hérite de celui de la session. Des relecteurs de code lancés en parallèle depuis une session sur le modèle le plus cher tournent tous à ce tarif, sans que personne l'ait décidé. L'audit écrit le modèle dans chaque définition. Un petit modèle convient pour chercher, résumer ou lire des journaux. L'écriture du code et les arbitrages restent au modèle principal : quand un petit modèle se trompe de fichier, le modèle principal part travailler sur le mauvais.

Régler l'effort et le modèle de Claude Code

L'effort et le modèle de la session ne sont écrits dans aucun fichier audité. Sur Opus 5.5, la réflexion est toujours active, et c'est l'effort qui en fixe la quantité.

• /effort : medium par défaut, pour le travail bien délimité. high quand le modèle cale, puisqu'une relance évitée paie l'effort supplémentaire. low pour les modifications mécaniques. Baissez l'effort avant d'écrire « réfléchis moins » dans une consigne.
• /model : choisissez le modèle en ouvrant la session, en fonction de la tâche.
• Avant le premier message : effort, modèle et serveurs MCP se règlent au démarrage. Les changer en cours de session invalide le cache de la conversation, et tout se relit au prix fort. Avant une pause, /compact réduit ce qui sera relu au retour.

Appliquer les corrections de l'audit

Les contradictions entre fichiers et les faits périmés ne s'appliquent jamais sur une simple demande de nettoyage. L'audit les propose, et c'est à vous de dire laquelle des deux règles est la bonne, ou si le fait a vraiment changé.

En mode auto, Claude Code refuse d'écrire dans les CLAUDE.md et dans les définitions d'agents : c'est un garde-fou contre l'auto-modification. Nous l'avons rencontré en passant l'audit sur nos propres fichiers. L'audit prépare alors un script d'application, que vous lancez vous-même depuis la session avec ! bash appliquer.sh. Une règle de permission dédiée fait le même travail si l'audit revient souvent.

Le guide de la commande pose aussi qu'un audit qui ne trouve rien ne change rien : un diff vide vaut mieux qu'un diff fabriqué. Retirer une consigne reste une hypothèse tant qu'on ne l'a pas vérifiée, et demander au modèle s'il en a besoin ne mesure rien. Relancez vos tâches habituelles après l'application, et comparez le résultat.

RTK : moins de tokens dans la sortie des commandes

Le CLAUDE.md pèse au démarrage. La sortie des commandes pèse pendant toute la session : un git status sur un gros dépôt, une suite de tests qui déroule des centaines de lignes, un ls -la, tout arrive dans le contexte du modèle, qui n'en utilise qu'une partie.

RTK (Rust Token Killer) s'intercale entre Claude Code et le terminal. Un hook réécrit les commandes au passage (git status devient rtk git status), et RTK compacte la sortie avant qu'elle n'atteigne le modèle. Il garde l'historique de chaque commande, avec la taille de la sortie brute et celle de la sortie envoyée.

Le bilan de rtk gain sur le poste de Cédric Lombardot, fondateur et directeur technique de DonkeyCode, qui travaille avec Claude Code tous les jours, du 8 juillet au 5 octobre 2026 :

$ rtk gain
RTK Token Savings (Global Scope)

Total commands:    86444
Input tokens:      1513.4M
Output tokens:     175.0M
Tokens saved:      1339.6M (88.5%)

Command                   Count    Saved    Avg%
rtk read                  17966  1231.2M    8.8%
rtk grep                  10017    55.8M   20.4%
rtk:toml make check         661    27.6M   16.0%
rtk:toml ps aux              89     8.1M   99.0%
rtk:toml make phpunit       193     6.0M   13.5%
rtk ls -la .                653   651.5K   75.6%
rtk diff                     49   405.7K   60.5%
rtk git diff HEAD             2   373.5K   95.2%

1,34 milliard de tokens économisés, 88,5 % de la sortie brute. Le gros de ce chiffre vient de journaux de plusieurs centaines de mégaoctets, ouverts d'un simple cat. Sur les commandes de tous les jours, l'historique de RTK donne 26 % de tokens en moins, soit 8,8 millions de tokens : 62 % sur les listes de fichiers (ls), 47 % sur les recherches dans le code (grep, rg), 24 % sur les tests, 11 % sur git.

Ce gain se multiplie. Chaque sortie de commande reste dans le contexte et se relit à chaque requête suivante de la session : un token évité en début de session est économisé à chaque requête qui suit, et la session tient plus longtemps avant d'être compactée. Pour un journal, tail -n 200 ou un grep ciblé reste plus économe que n'importe quel filtre.

La réécriture est silencieuse, et toutes les options ne passent pas. Un grep -h réécrit en rtk grep affiche l'aide au lieu du résultat ; rtk proxy <commande> lance alors la commande brute. Un autre outil porte le même nom (Rust Type Kit) : si rtk gain ne répond pas, which rtk dit lequel des deux est installé.

Maintenir ses automatisations IA

L'audit relève aussi ce qui tourne sans surveillance : une tâche planifiée qui lance Claude avec toutes les permissions accordées d'office, un hook qui échoue sur certains chemins de projet. Le hook ne plante pas. Il ne produit rien, et personne ne s'en aperçoit.

Une routine montée par un salarié motivé, sur son temps libre, fonctionne. Puis le modèle change, la personne passe à autre chose, et la routine continue de tourner avec des droits d'écriture sur le CRM ou la messagerie, des consignes écrites pour un modèle retiré, et une facture qui grossit sans que personne sache pourquoi.

Confiées à une équipe dont c'est le métier, vos automatisations ont un responsable : quelqu'un relit leurs consignes quand le modèle change, vérifie leurs permissions et suit ce que coûte chaque exécution. Nous le faisons pour les nôtres à chaque nouvelle génération de modèles, au même titre qu'une mise à jour de sécurité. Nos devis, par exemple, sont préparés par Claude à partir des comptes rendus de réunion.

Notre agence d'automatisation IA sur abonnement fonctionne ainsi : un product owner dédié, des agents IA qui automatisent votre entreprise mois après mois, un prix ferme pour chaque demande, et le même product owner pour maintenir ce qui a été livré. Les automatisations qui écrivent dans votre ERP, votre CRM ou votre messagerie passent par nos agents IA connectés au système d'information. Les droits accordés à un agent et les traces qu'il laisse relèvent de la gouvernance, traçabilité et conformité IA.

Si c'est l'application elle-même qui a été écrite avec Claude Code et qui tient mal en production, notre audit et reprise d'applications codées avec l'IA part du code tel qu'il est, et vous dit ce que coûte chaque option.

Former vos équipes à construire leurs assistants IA

Si vos équipes préfèrent construire elles-mêmes, la formation IA opérationnelle part des tâches qu'elles font déjà, sur leurs propres dossiers. Le parcours commence par ce qu'il faut savoir des tokens et de la fenêtre de contexte. Chaque participant construit ensuite un assistant réutilisable sur un livrable réel, le branche sur ses logiciels par MCP, puis en fait une routine qui tourne seule.

Cinq demi-journées dans vos locaux ou en visio, 2 500 € HT pour le groupe jusqu'à six participants. La formation est dispensée par DonkeySchool, notre organisme certifié Qualiopi, et se finance sur votre budget formation via l'OPCO : le simulateur de budget formation vous dit ce qui est pris en charge chez vous. S'il faut d'abord un vocabulaire commun dans l'entreprise, une conférence de sensibilisation le pose en une séance.

Questions fréquentes

Combien de lignes doit faire un CLAUDE.md ?

Visez deux cents lignes environ. Ce qui ne sert qu'à certaines tâches (une procédure de déploiement, une charte de documents, un lexique métier) va dans une skill ou dans un fichier de référence que Claude lit quand il en a besoin.

Quelle différence entre /claude-api prompt-audit et /claude-api migrate ?

prompt-audit relit le texte des consignes : CLAUDE.md, skills, sous-agents, ou le prompt système d'une application. migrate porte sur le code qui appelle l'API Claude : identifiant du modèle, paramètres de réflexion, tool_choice.

L'audit peut-il casser ma configuration ?

Il ne modifie rien sans demande explicite. Quand vous lui demandez d'appliquer, il ne touche qu'aux constats de confiance haute ou moyenne, et laisse les contradictions et les faits périmés à votre arbitrage. Sauvegardez les fichiers avant d'appliquer, surtout ~/.claude, qui n'est pas versionné.

Faut-il relancer l'audit à chaque nouveau modèle ?

Oui. Une consigne utile à un modèle peut devenir inutile, ou gênante, pour le suivant. L'audit se relance avec le nouveau modèle pour cible.

RTK fonctionne-t-il avec d'autres outils que Claude Code ?

Oui. rtk init --agent installe ses hooks pour Cursor, Windsurf, Cline ou Kilo Code, et d'autres options couvrent Gemini CLI et OpenCode.

Vos automatisations ou votre configuration Claude Code ont grandi sans relecture ? Dites-nous où vous en êtes, et nous regardons avec vous ce qui coûte des tokens sans servir.