Ablation du prompt système : comment j'ai réduit la config de Claude Code de 19 736 à 3 585 lignes sans perte de qualité

• Volume initial des compétences : 19 736 lignes réparties en 29 modules
• Volume après révision : 3 585 lignes en 2 modules de base
• Configuration en production : 361 compétences, 84 commandes, 39 agents et 35 plugins
• Contrôle des fuites : 179 détecteurs avec canari forcé

En un an et demi de travail quotidien, ma configuration pour Claude Code s'est transformée en monolithe. Compétence après compétence, règle après règle — jusqu'au soir où j'ai ouvert le répertoire racine et compris que la moitié de cette montagne entravait déjà les mains du modèle.

J'ai récemment visionné une intervention de trente-six minutes de Boris Cherny, le créateur de Claude Code, sur le travail des ingénieurs chez Anthropic. Ses quatre principes correspondaient exactement aux conclusions auxquelles j'étais arrivé par mes propres erreurs.

Pourquoi effacer le prompt système et les compétences tous les six mois ?

Chez Anthropic, à chaque sortie d'un nouveau modèle de base, les équipes appliquent une méthode d'ablation : le prompt système est entièrement effacé, puis chaque ligne est réintroduite une par une pour mesurer la contribution réelle de chaque règle. Les instructions qui, un an plus tôt, évitaient au modèle des erreurs grossières sont désormais intégrées aux poids d'Opus 5.5 et de Fable 5.1. En les laissant dans `CLAUDE.md`, on paie deux fois : on gaspille la fenêtre d'attention sur des évidences, et on enferme le modèle dans un couloir étroit d'heuristiques obsolètes.

Avant même de voir cette vidéo, j'avais effectué ce nettoyage sur toute ma pile. J'ai parcouru chaque fichier avec une seule question : le modèle actuel peut-il résoudre la tâche sans cette indication ? Si oui, la règle passait à la trappe. Le corps des compétences est passé de 19 736 à 3 585 lignes, et sur vingt-neuf modules lourds, il n'en reste que deux. La qualité des réponses s'est améliorée immédiatement. La discipline est simple : ne réintroduire une ligne dans le prompt que lorsque le modèle trébuche trois fois de suite au même endroit.

Pourquoi les instructions pas à pas fonctionnent-elles moins bien

qu'une description des limites de la tâche ?

Une erreur classique en travaillant avec un agent consiste à lui détailler un algorithme étape par étape : ouvre ce fichier, modifie cette fonction, lance ce script. Pour les modèles de raisonnement, ce micro-management est contre-productif. Il est bien préférable de monter d'un niveau : fixer un objectif, des limites, et un critère de réussite vérifiable.

Chez Anthropic, l'équipe Bun a réécrit le runtime de Zig vers un autre langage avec un seul prompt, via un pipeline dynamique de sous-agents — onze jours de travail et cent mille lignes de code qui tournent aujourd'hui en production dans Claude Code. Boris lui-même a porté une application de bureau d'Electron vers Swift avec une seule tâche : l'agent lançait l'original sur une machine virtuelle, prenait une capture d'écran, la comparait pixel par pixel avec la version Swift, et envoyait des rapports dans un canal Slack.

Selon la même logique, j'ai assemblé un ensemble reliant une plateforme éducative, un CRM, un gestionnaire de tâches et une flotte d'agents. Au lieu de passer un mois à rédiger des spécifications, je définissais le contrat final, puis corrigeais uniquement les points où l'agent peinait réellement.

Comment organiser la vérification pour que le script de contrôle ne

mente pas sur un résultat vert ?

Confier une tâche complexe au modèle n'est envisageable qu'en couplant cela à une deuxième règle : à chaque étape, l'agent doit disposer d'un oracle externe d'auto-vérification. Et il faut aussi tester les outils de validation eux-mêmes.

En une seule journée, j'ai débusqué six défauts silencieux dans mes propres scripts de sécurité, qui affichaient pourtant joyeusement un statut vert. Le scanner de fuites, avec le drapeau d'analyse sémantique activé, imprimait un en-tête puis sortait avec le code zéro sans avoir lancé un seul détecteur. Ailleurs, un paramètre vide désactivait complètement le scanner, et le mot « Anthropic » dans une ligne masquait une clé de production se trouvant juste à côté.

Le remède tient en un principe : une vérification doit être capable d'échouer. Désormais, mon scanner s'injecte lui-même un « canari » de contrôle avant chaque exécution, avec un secret synthétique, et exige que les 179 règles capturent leur cible. Si une seule reste muette, tout le rapport est rejeté.

Comment récupérer une architecture déjà prête de 361 compétences sans

tout reconstruire ?

Les modèles actuels savent déjà faire bien plus que ce que leur permettent les interfaces de chat standard. Lorsqu'on retire la couche produit superflue et qu'on donne au modèle un accès direct au terminal, à un navigateur connecté au compte de travail, à un assembleur de diapositives, au montage vidéo et à un catalogue local de 2 061 scénarios n8n, la vitesse de travail change d'un ordre de grandeur.

J'ai publié l'ensemble de la configuration reconstruite, soit 361 compétences et 39 agents, en accès libre sur le canal [@jemal_hamidun](https://t.me/jemal_hamidun). Pour ceux qui souhaitent déployer cette pile en local avec un contrôle total de la confidentialité, nous développons l'environnement [Nomad AI](https://nomadnet.ai). Un parcours pratique pas à pas sur l'orchestration, avec un essai de 72 heures, est disponible chez [Hamidun Academy](https://academy.hamidun.com), et des masterminds réguliers ainsi que la bibliothèque complète de plus de 370 compétences sont accessibles sur [Vibe Club](https://hamidun.com/club).