Claude Code ralentit : comment choisir entre skills, sous-agents, MCP et plugins

Pourquoi « bourrer Claude Code » est-il devenu le principal problème en 2026 ?#

Même la documentation officielle ne proposait pas de réponse complète toute faite à la question « quand faut-il choisir quoi ? »

L’expérience d’un mois décrite dans cet article couvre les quatre mécanismes dans des projets opérationnels : une pile de sous-agents pour une tâche complexe, un petit ensemble de skills pour les procédures récurrentes, quelques serveurs MCP pour les données en temps réel et le choix de quelques plugins parmi une vingtaine environ. Ce guide rassemble l’exemple dans une matrice de sélection avec un arbre de décision prêt à l’emploi, des citations d’Anthropic et sept anti-patterns qui rendent Claude inutilisable.

En quoi une skill diffère-t-elle d’un sous-agent, de MCP et d’un plugin ? Un tableau#

Matrice de sélection :

Une analogie simple pour un entrepreneur : imaginez que vous êtes PDG d’une entreprise de dix personnes :

• CLAUDE.md — la charte de l’entreprise. Toujours affichée au mur ; tout le monde la lit ; personne ne la conteste.
• Skill — une procédure interne. « Comment nous faisons les revues », « comment nous rédigeons les notes de version », « comment nous acceptons les paiements ».
• Sous-agent — un spécialiste avec son propre bureau et une liste d’autorisations restreinte. Donnez-lui les clés de tout et vous obtiendrez un second PDG, pas un employé.
• Serveur MCP — les systèmes de l’entreprise : CRM, banque, entrepôt. Ce n’est pas du savoir, c’est une connexion.
• Plugin — une solution toute faite achetée en magasin. Un paquet de procédures, de spécialistes et d’intégrations dans une seule boîte.

Dès que vous comprenez qu’il s’agit de quatre couches d’un seul système et non de quatre concurrents, la question « lequel est le meilleur ? » disparaît. Il reste la question « qu’est-ce qui va où ? »

Qu’est-ce qu’une skill dans Claude Code, et quand en installer une ?#

Définition officielle d’Anthropic :

Une skill comporte trois niveaux :

1. Métadonnées. Toujours chargées au démarrage de la session : le nom et la description du frontmatter. Une skill utilise environ 100 tokens au démarrage.
2. Instructions. Chargées uniquement lorsque Claude reçoit une demande correspondant au déclencheur. Jusqu’à 5 000 tokens — le corps de SKILL.md.
3. Ressources. Chargées uniquement si les instructions le demandent explicitement. Fichiers du paquet, scripts dans scripts/, documents de référence dans references/. Les scripts s’exécutent via bash ; le code lui-même n’entre pas dans le contexte.

Anthropic appelle ce principe la divulgation progressive :

Et, dans le même article, une métaphore qui explique l’idée mieux que tout le reste :

Quand utiliser une skill :

• Pour une procédure standard que vous répétez encore et encore. Revues de PR, notes de version, revue de code selon votre guide de style.
• Lorsqu’une section de CLAUDE.md est devenue une procédure plutôt qu’un simple fait et commence à gêner tout le reste.
• Lorsque vous voulez que la même instruction soit suivie de manière cohérente dans différents projets.

Formule pratique : si vous faites quelque chose plus de deux ou trois fois, confiez-le au système. La première fois, utilisez un prompt manuel. La deuxième fois, c’est une candidate pour une skill.

Quand NE PAS utiliser une skill :

• Si la tâche exige des données en temps réel (base de données, API, recherche, cours actuel de la Bourse). C’est le rôle de MCP, pas d’une skill. Une skill qui tente de « récupérer le cours actuel » va halluciner.
• Si la tâche exige un contexte isolé. C’est le rôle d’un sous-agent.
• Si vous voulez un contrôle appliqué (« bloquer un commit contenant .env »), utilisez un hook sur le chemin de commit couvert. Vérifiez et testez sa portée réelle : il ne bloque pas tous les moyens de lire, copier ou publier le fichier. Une skill seule ne garantit pas ce contrôle.

Limites à connaître à l’avance :

• Nom de la skill : jusqu’à 64 caractères, uniquement des lettres minuscules, des chiffres et des traits d’union. Les mots anthropic et claude sont réservés.
• Description : jusqu’à 1 024 caractères. Le total de description + when_to_use est tronqué à 1 536 caractères dans la liste.
• Corps de SKILL.md : la recommandation est de ne pas dépasser 500 lignes. Déplacez tout ce qui dépasse dans references/ et scripts/.
• Lors de la compaction automatique du contexte (auto-compaction), les 5 000 premiers tokens de chaque skill active sont réattachés. Le budget total pour toutes les skills est de 25 000.

Qu’est-ce qu’un sous-agent, et pourquoi existe-t-il 5 niveaux d’imbrication ?#

D’après la documentation officielle :

Claude Code dispose de trois sous-agents intégrés que vous utilisez déjà sans le savoir :

Le 10 juin 2026, Anthropic a publié Claude Code v2.1.172 et supprimé une restriction en vigueur depuis le lancement des sous-agents : les agents enfants peuvent désormais lancer leurs propres sous-agents jusqu’à 5 niveaux de profondeur.

Le nombre 5 est un plafond de sécurité, pas un objectif d’optimisation.

Une analyse détaillée de la fonctionnalité avec des modèles YAML d’orchestrateur figure dans le guide sur les sous-agents imbriqués.

Quand utiliser un sous-agent :

• Pour explorer du code ou des journaux, lorsque vous n’avez besoin que d’une courte conclusion.
• Pour des tâches parallèles qui peuvent s’exécuter côte à côte.
• Pour déléguer par spécialité : backend / frontend / test / revue — chacun chargé d’une fonctionnalité.
• Pour maîtriser les coûts : un sous-agent Haiku plutôt que Sonnet ou Opus. Cela réduit la facture de 5 à 7 fois.

Quand NE PAS utiliser un sous-agent :

• Pour une tâche ponctuelle et triviale ou un simple appel d’outil. Un sous-agent a un coût de démarrage.
• Lorsque les tâches doivent partager leur état. Les sous-agents ne peuvent pas voir le contexte des autres ; le travail lié devrait rester dans le fil principal.

Le principal anti-pattern :

Donner Opus et tous les outils à un sous-agent ne fait que créer une autre session principale. Si sa liste d’outils correspond à celle de l’agent principal, le sous-agent n’est pas réellement limité.

Autrement dit, un sous-agent doté des mêmes autorisations que son parent n’est qu’un deuxième PDG. Inutile et coûteux.

Qu’est-ce qu’un serveur MCP, et quand le connecter à Claude Code ?#

Définition officielle :

Ce que MCP permet concrètement :

• Connecter Claude à Google Calendar et Notion pour obtenir un assistant personnel.
• Se connecter à Figma pour que Claude génère un projet web prêt à l’emploi à partir d’un design.
• Connecter un chatbot d’entreprise à plusieurs bases de données simultanément.
• Se connecter à Blender et à une imprimante 3D pour créer des modèles et les imprimer immédiatement.

Les serveurs MCP les plus connus, souvent installés en premier :

Les connexions et commandes d’installation sont réunies dans le catalogue MCP.

Quand utiliser MCP :

• Pour toute connexion à des données ou actions externes : « récupérer des lignes dans la base de données », « lire les tickets Jira », « publier dans Slack ».
• Lorsque le même service est nécessaire à plusieurs projets ou agents, il est plus simple de conserver un serveur centralisé.

Quand NE PAS utiliser MCP :

• Pour des connaissances statiques ou une procédure. C’est le rôle d’une skill, pas de MCP. « Instructions pour effectuer une revue de code » est une skill. « Lire la dernière PR sur GitHub et la réviser » nécessite MCP.
• Pour une commande CLI ponctuelle. Il est plus simple d’utiliser Bash que de configurer un serveur.
• Pour construire MCP « au nom d’une architecture bien faite ». C’est une question d’esthétique, pas une tâche.

Le principal piège de MCP est l’une des causes les plus fréquentes en 2026 des plaintes disant que « Claude Code est devenu idiot » :

Lorsque vous installez tous ces MCP en même temps, vous étouffez la fenêtre de contexte du LLM : tous les outils disponibles sont chargés dans le contexte.

Une règle pratique : gardez au maximum 2–3 serveurs MCP actifs ciblés sur des tâches précises. Dans l’expérience décrite avec de nombreux serveurs, le démarrage était plus lent et les erreurs plus fréquentes.

La recherche d’outils MCP a été ajoutée dans Claude Code v2.1.x : les outils ne sont plus chargés de manière systématique dans le contexte, mais indexés et récupérés à la demande. Cela réduit le coût lié à « de nombreux MCP dans un projet », sans toutefois le supprimer complètement.

En quoi un plugin diffère-t-il d’une skill, et pourquoi la frontière s’est-elle estompée ?#

Formulation officielle :

Les plugins les plus installés en juin 2026 :

L’analyse complète de la sélection figure dans le guide des 10 meilleurs plugins parmi 101.

Quand utiliser un plugin :

• Pour un ensemble communautaire prêt à l’emploi qui couvre une grande partie d’un workflow, comme le design ou la revue.
• Si vous ne voulez pas assembler vous-même une configuration « skill + sous-agent + MCP + hook », vous pouvez en utiliser une toute faite.
• Pour la distribution en entreprise : un administrateur crée une marketplace d’équipe, et les développeurs installent les plugins à partir d’un seul préfixe.

Quand NE PAS utiliser un plugin :

• Si une seule skill suffit à résoudre la tâche, mais que le paquet ajoute cinq autres MCP « au cas où ». C’est du pur encombrement du contexte.
• Pour un plugin à code source fermé sans audit. Il s’exécute avec vos autorisations — lisez son contenu avant de l’installer.
• Si vous avez déjà votre propre plugin sur le même sujet. Un doublon dans le contexte signifie deux fois plus de problèmes.

Avant l’installation, Claude Code v2.1.143+ affiche Context cost, une estimation du nombre de tokens que le plugin ajoutera à chaque message. Depuis v2.1.145+, il affiche également le champ Will install, qui donne la liste complète des commandes, agents, skills, hooks, composants MCP et LSP du paquet. C’est le premier écran à consulter avant de cliquer sur « Installer ».

Quelle matrice de sélection fonctionne en 2026 ?#

Six questions, par ordre de priorité :

1. S’agit-il d’une procédure, d’un style ou d’une liste de contrôle récurrente ? Si oui — skill.
2. Avez-vous besoin de données ou d’actions externes (base de données, API, Slack, GitHub, Figma) ? Si oui — serveur MCP.
3. Est-ce que je veux un contexte séparé pour ne pas encombrer le principal ? Si oui — sous-agent.
4. Est-ce que je veux un contrôle ou une étape automatique lors d’un événement défini ? Si oui — hook, avec une couverture testée ; utilisez les permissions ou l’isolation de l’environnement pour des limites d’accès plus larges.
5. Est-ce que je veux un ensemble prêt à l’emploi de 1 à 4 en un clic ? Si oui — plugin de la marketplace.
6. Est-ce une tâche complexe qui nécessite des données, du contexte et du style ? Utilisez alors une combinaison : sous-agent Haiku + skill préchargée + un MCP au périmètre restreint.

Formule de combinaison :

Un sous-agent Haiku avec une skill préchargée pour les conventions et un serveur MCP au périmètre restreint pour les données en temps réel est une configuration qui porte vraiment ses fruits.

Et la règle principale concernant le sens des dépendances :

Les sous-agents peuvent utiliser des serveurs MCP. Les serveurs MCP ne peuvent pas utiliser de sous-agents.

Autrement dit, MCP fournit toujours des données et des actions, pas des agents. Pour déléguer une tâche, c’est un sous-agent qui appelle MCP, et non l’inverse.

Un exemple concret décrit ici : le moteur éditorial d’une agence numérique qui rédige un article SEO en 60 minutes. Il comprend 25 sous-agents et 14 étapes de révision — ils s’exécutent séquentiellement, chacun avec son propre contexte, ses propres autorisations et une skill consacrée aux conventions éditoriales. Un sous-agent se connecte à un serveur MCP contenant une base de données de tags prêts à l’emploi et d’anciens articles. L’agent orchestrateur principal fonctionne sur Opus ; les agents enfants fonctionnent sur Haiku, ce qui permet de maîtriser le budget.

Ce n’est pas une « usine à articles », mais un exemple de la manière dont les quatre mécanismes se combinent en un système lorsque la tâche exige de privilégier la qualité plutôt que la vitesse.

Quelles sont les 7 erreurs à éliminer dès maintenant de Claude Code ?#

1. Installer les 10 meilleurs plugins « parce qu’ils sont à la mode ». Chacun ajoute des tokens à chaque message. Ouvrez /plugin list et vérifiez le Context cost de chacun. Supprimez ceux que vous n’avez pas utilisés depuis deux semaines.

2. Copier 15 serveurs MCP depuis le .mcp.json de quelqu’un d’autre. La configuration d’une autre personne est adaptée à ses propres projets et tâches. Gardez au maximum 2–3 MCP actifs pour le projet en cours. Déplacez les autres dans une configuration distincte pour un autre projet ou supprimez-les dès maintenant.

3. La skill et le plugin MCP font la même chose. La skill dit « faire une revue de code », tandis que le plugin pr-review-toolkit lance son propre processus de revue. Ils se disputent la priorité. Symptôme : « Claude, pourquoi reviens-tu sans cesse là-dessus ? » Solution : conserver une seule source de vérité. Dans la configuration décrite, la skill a été choisie pour garder le contrôle des instructions.

4. Utiliser une skill pour faire respecter une règle alors qu’il faut un hook. Une skill est une suggestion, pas une garantie. Pour « bloquer .env dans un commit », un hook pre-commit peut vérifier le chemin de commit couvert. Testez séparément le contenu indexé et les autres chemins ; cela ne bloque ni toutes les lectures ni toutes les publications. Une skill seule ne peut pas imposer cette limite.

5. Un sous-agent avec les mêmes autorisations que son parent. Vous lui avez donné Opus et tous les outils, et vous vous retrouvez avec une autre session principale. Le prompt système de la documentation officielle recommande de donner au sous-agent une liste d’outils restreinte et une tâche limitée. Sinon, ce n’est qu’un clone coûteux.

6. Ne pas vérifier le champ Will install avant d’installer un plugin. Dans Claude Code v2.1.145+, ce champ présente le contenu complet du paquet. Souvent, un plugin « pour un petit détail » contient trois serveurs MCP, deux sous-agents et cinq hooks. Ils finissent tous par occuper votre contexte.

7. Les anciens .claude/commands/ font doublon avec les nouvelles skills. Anthropic l’indique dans sa documentation :

L’ancien dossier commands/ fonctionne toujours, mais les skills sont désormais la norme. Dans l’exemple décrit, les deux dossiers étaient utilisés ; commands/ a été supprimé, et les skills avec leurs fichiers intégrés et leurs déclencheurs ont été conservées.

Signes indiquant que Claude Code est devenu « encombré » :

• Chaque message commence par mentionner les outils disponibles sur plus de 200 lignes.
• Les tâches simples prennent plus de temps qu’il y a un mois.
• Claude confond deux skills ou plugins similaires.
• Des avertissements de collision de noms apparaissent au démarrage d’une session.
• Claude appelle le mauvais outil — une skill A au lieu du MCP B dont il avait besoin.

Si vous reconnaissez au moins deux de ces symptômes, ouvrez /plugin list et /skill list dès maintenant. Supprimez d’abord ce que vous n’avez pas utilisé depuis deux semaines. Vérifiez ensuite le Context cost de chaque élément. Puis corrigez les anti-patterns ci-dessus.

Combien de skills et de MCP peut-on garder sans épuiser le contexte ?#

Ce que Claude Code affiche directement :

• /skill list — toutes les skills actives et leur taille en tokens.
• /plugin list — tous les plugins et leur Context cost.
• /mcp list — les serveurs MCP et le nombre de leurs outils.

Budget de tokens en chiffres réels :

Une fenêtre de contexte indique l’espace de travail maximal, pas la consommation de chaque tâche. Comparez les entrées mesurées, les entrées en cache, les sorties et les tours répétés pour le même résultat. L’isolation peut alléger le contexte parent tout en entraînant une consommation propre au sous-agent.

Dans son blog technique, Anthropic donne les chiffres de l’auto-compaction pour les skills : les 5 000 premiers tokens de chaque skill active sont réattachés, pour un budget total de 25 000. Cela signifie qu’avec plus de 5 skills « lourdes » actives en même temps, Claude commence à perdre certaines instructions.

Règle pratique simple :

• Skills : pas plus de 5–7 actives pour le projet en cours. Placez les autres dans ~/.claude/skills/disabled/ ; vous pourrez les remettre en place si nécessaire.
• MCP : pas plus de 2–3 par projet. Context7 pour la documentation vaut presque toujours la peine ; gardez les autres selon les besoins de la tâche.
• Plugins : installez-les strictement un à la fois et vérifiez au bout de deux semaines si vous l’avez utilisé. Sinon, supprimez-le.

Une analyse détaillée de l’Anthropic 2026 Agentic Coding Trends Report et des raisons pour lesquelles 80 % des développeurs ne peuvent pas entièrement déléguer une tâche à Claude figure dans un guide distinct. Le principal chiffre de ce rapport : les gens utilisent l’IA pour 60 % de leur travail, mais ne lui confient entièrement que 0–20 % des tâches. La principale raison est la surcharge du contexte et la perte de contrôle sur les outils.

Par où commencer quand on débute : la configuration minimale fonctionnelle ?#

Configuration minimale après deux semaines de travail :

1. CLAUDE.md à la racine, avec les règles du projet.
2. AGENTS.md pour assurer la compatibilité avec d’autres outils si vous prévoyez de travailler au-delà de Claude Code. Plus de détails dans « How to Make One Instruction File for Claude Code, Codex, and Cursor ».
3. 1 skill pour votre principale tâche récurrente. Par exemple, commencez par code-review selon votre guide de style.
4. 1 serveur MCP : Context7 pour disposer d’une documentation actuelle. Sans lui, Claude continue d’halluciner des API inexistantes.
5. 0 plugins et 0 sous-agent pendant le premier mois. Il ne s’agit pas d’économiser de l’argent, mais de garder le contrôle. Tant que vous ne maîtrisez pas les bases, les paquets vous embrouilleront.

Ensuite, laissez-vous guider par les tâches. Une procédure récurrente se présente ? Transformez-la en skill. Vous avez besoin de données en temps réel provenant d’un service précis ? Ajoutez MCP. Une tâche importante commence à remplir le contexte principal ? Déléguez-la à un sous-agent.

Voilà la carte en trois niveaux : le contexte d’abord, puis confiez au système ce que vous faites plus de deux ou trois fois, et enfin des vérifications automatisées pour éviter que le système ne fasse des erreurs de son propre chef. N’ajoutez chaque niveau que lorsque le précédent fonctionne déjà.