La meilleure config Claude Code pour 2026 (guide 30 min)

Toutes les configurations Claude Code que j'ai examinées tombent dans l'un de ces deux travers. Le premier, c'est le défaut nu : pas de CLAUDE.md, pas de skill, une invite de permission à chaque commande, et l'utilisateur qui se demande pourquoi Claude oublie sans cesse comment son projet se build. Le second, c'est la machine sur-configurée : 40 skills, 9 serveurs MCP, un CLAUDE.md long comme une dissertation, et une fenêtre de contexte déjà à moitié consommée avant le premier prompt.

La bonne configuration se situe entre les deux, et elle prend environ 30 minutes à construire si vous traitez les couches dans l'ordre des dépendances. Cet ordre compte. Les skills supposent une installation fonctionnelle. Les décisions de permissions dépendent des serveurs MCP que vous faites tourner. La séparation par projet n'a de sens qu'une fois que vous savez ce que vous séparez. C'est le guide qu'on remet aux nouvelles recrues de SkillProof le premier jour, débarrassé des erreurs qu'on a commises pendant six mois.

Couche 1 : installation et authentification, cinq minutes

Vous l'avez probablement déjà fait, je vais donc faire court.

npm install -g @anthropic-ai/claude-code
cd your-project
claude

Au premier lancement, /login vous guide dans l'authentification. Deux options de facturation s'offrent à vous : un abonnement Claude (Pro ou Max) ou une clé API facturée au token. Si vous codez avec Claude au quotidien, l'abonnement est presque toujours moins cher ; la facturation API sur des sessions agentiques intensives grimpe plus vite qu'on ne l'imagine. Si vous êtes en équipe, vérifiez si votre organisation dispose d'un siège Claude for Work avant de brûler une clé API personnelle.

Vérifiez avec une question triviale (« que fait ce repo ? ») et confirmez que Claude peut lire vos fichiers. C'est toute la couche. Tout ce qui suit, c'est là où les configurations divergent vraiment.

Couche 2 : un CLAUDE.md qui mérite ses tokens

CLAUDE.md est un fichier markdown que Claude charge dans son contexte au début de chaque session sur ce projet. Chaque session, que le contenu soit pertinent ou non. Ce comportement de chargement dicte tout ce qui doit y figurer.

Ce qui a sa place : les faits qui s'appliquent à presque toutes les sessions. Les commandes de build et de test. La version en deux phrases de votre architecture. Les conventions que Claude se trompe sans arrêt tant qu'on ne les lui dit pas (votre ordre d'imports, votre format de commit). Où sont enterrés les cadavres : le module déprécié auquel personne ne doit toucher, le fichier de config qui a l'air inutilisé mais ne l'est pas.

Ce qui n'a pas sa place : le savoir procédural dont vous avez besoin occasionnellement. Comment écrire une migration de base de données. Votre checklist de release. Le ton maison pour les emails clients. Chacun de ces éléments s'applique à peut-être 5 % des sessions, et dans CLAUDE.md vous les payez aussi dans les 95 % restants. Ce contenu veut devenir un skill (couche suivante), qui ne se charge que lorsqu'il est déclenché.

Notre règle de base après avoir testé ça sur notre propre repo : si votre CLAUDE.md dépasse 60 lignes, quelque chose doit en sortir. Le nôtre a démarré à 400 lignes parce qu'on le traitait comme de la documentation. Claude le suivait moins bien, pas mieux, parce que le signal se noyait. La version compressée, environ 50 lignes de commandes et de contraintes dures, est respectée presque à chaque fois.

Écrivez le premier jet en dix minutes et arrêtez-vous là. Vous l'affinerez pendant des semaines à mesure que vous repérez les erreurs répétées de Claude ; cette boucle itérative est la vraie méthode. Le traitement complet, y compris les anti-patterns qu'on voit dans les fichiers envoyés par nos lecteurs, se trouve dans notre guide CLAUDE.md.

Couche 3 : les skills, la couche que presque tout le monde saute

C'est la couche qui distingue une configuration d'une simple installation, et c'est celle que presque personne ne touche. Un skill est un dossier contenant un fichier SKILL.md qui enseigne à Claude une façon de travailler. Il coûte environ 100 tokens de métadonnées à l'état inactif et ne charge ses instructions complètes que lorsqu'une tâche correspond à sa description. Installé une fois, il s'applique pour toujours, dans toutes les sessions.

Les gens sautent cette couche pour une raison rationnelle : environ la moitié des skills communautaires sur GitHub échouent dès l'installation. On le sait parce qu'installer et tester des skills, c'est tout notre métier. Chaque skill du catalogue SkillProof subit une installation sur machine propre et des vérifications de déclenchement, puis de vraies tâches sont exécutées face à une base sans skill, avant qu'un verdict ne tombe. Sur les 73 skills catalogués à ce jour, 35 ont été validés.

Pour une configuration de développeur, voici les cinq à installer en premier, avec les scores de nos sessions de test :

1. Test-Driven Development, 9,6. Impose un cycle strict rouge-vert-refactorisation : test qui échoue d'abord, implémentation minimale, puis nettoyage. Dans notre session à trois fonctionnalités, il n'a jamais sauté le cycle, même quand on a essayé de le convaincre de le faire.
2. Systematic Debugging, 9,6. Remplace les correctifs à l'aveugle par une boucle hypothèse-test-vérification. Il a trouvé la cause racine d'une race condition que Claude avait précédemment « corrigée » trois fois en devinant.
3. Frontend Design, 9,6. Le plus grand écart avant/après qu'on ait mesuré sur un skill. Même brief de landing page, exécuté deux fois : la base a produit le look néon-dégradé-tout-centré habituel, la version avec skill avait une vraie échelle typographique et une palette qui semblait choisie.
4. Memory Management, 9,2. Donne à Claude une mémoire persistante entre les sessions. Sur une semaine de test, il s'est souvenu de manière fiable des décisions et préférences du projet, et le rappel restait précis à mesure que le stockage grandissait.
5. Webapp Testing, 8,8. Claude pilote votre application dans un vrai navigateur via Playwright et rapporte ce qui casse. Il a détecté une régression que nos tests unitaires avaient manquée.

Les deux premiers viennent de la collection Superpowers de Jesse Vincent (/plugin marketplace add obra/superpowers-marketplace, puis /plugin install superpowers). Frontend Design est livré dans le repo officiel de skills d'Anthropic et se copie directement dans ~/.claude/skills/. Les étapes précises, y compris les pièges qui font perdre leur première heure aux gens, sont dans le guide d'installation. Après l'installation, redémarrez Claude Code et testez chaque déclencheur en demandant le travail sans nommer le skill. Si rien ne change visiblement, le skill ne se déclenche pas, et un skill installé qui ne se déclenche jamais n'est qu'un dossier.

Si votre travail penche vers une autre direction, notre liste des meilleurs skills de code classe toute la catégorie, mise à jour à mesure que de nouveaux tests arrivent.

Couche 4 : les serveurs MCP, seulement ceux que vous utiliserez

Les serveurs MCP connectent Claude à des éléments extérieurs au repo : votre base de données, votre gestionnaire de tickets, un navigateur en direct. Ils sont puissants et constituent la ligne budgétaire la plus coûteuse de votre contexte. Chaque serveur connecté injecte ses définitions d'outils dans chaque session, utilisées ou non, et un seul serveur bavard peut coûter plus de tokens permanents que 50 skills installés réunis. On a mesuré ça dans le guide sur les coûts en tokens, et les chiffres ont changé notre façon de configurer nos propres machines.

La barre pour un serveur MCP doit donc être haute : il ne mérite une place que s'il permet à Claude d'atteindre quelque chose qu'il ne peut sinon pas toucher. Trois passent généralement ce test pour les développeurs :

Un serveur de base de données (Postgres ou autre). Claude qui écrit des requêtes contre votre vrai schéma plutôt qu'un schéma deviné, c'est un produit différent. C'est la connexion MCP à plus forte valeur pour la plupart des équipes.

L'automatisation de navigateur (Playwright MCP), si vous livrez de l'UI et n'utilisez pas la configuration propre au skill Webapp Testing. Voir la page rendue bat toujours le fait de l'inférer depuis du JSX.

Votre gestionnaire de tickets, mais seulement si vous travaillez vraiment ticket par ticket dans Claude Code. Si vous jetez un œil à Linear deux fois par jour, le navigateur suffit et les tokens n'en valent pas la peine.

Remarquez ce qui manque : le serveur MCP GitHub. Le CLI gh fait tout ce qu'il fait, Claude sait déjà s'en servir, et ça ne coûte aucun contexte permanent. Ce schéma de substitution se généralise. Avant d'ajouter un serveur, demandez-vous si un outil en ligne de commande que Claude peut appeler vous donne la même portée gratuitement. Et si vous hésitez entre MCP et un simple skill, la règle de décision est dans skills contre MCP : les skills changent ce que Claude sait faire, MCP change ce qu'il peut toucher.

Couche 5 : les permissions et réglages de sécurité qui valent la peine d'être changés

L'expérience de permission par défaut, c'est une invite pour presque chaque commande, ce qui entraîne les gens à cliquer sur « autoriser » par réflexe. C'est le pire résultat possible : toute la friction, aucune sécurité. Deux changements corrigent ça.

D'abord, mettez sur liste blanche les commandes que vous approuveriez de toute façon. Dans .claude/settings.json :

{
  "permissions": {
    "allow": [
      "Bash(npm test:*)",
      "Bash(npm run lint:*)",
      "Bash(git status)",
      "Bash(git diff:*)",
      "Bash(git log:*)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  }
}

Ensuite, remarquez le bloc deny, car c'est la moitié que les gens sautent. Claude n'a rien à faire à lire votre .env, et une règle de refus fait de ça une propriété du système plutôt qu'un espoir. Si vous faites tourner des serveurs MCP ou des skills tiers, ça compte encore plus, puisqu'une instruction malveillante ne peut pas exfiltrer ce que le harnais ne lit pas. Notre guide de sécurité couvre le volet audit.

Sur --dangerously-skip-permissions : le nom du flag est honnête. Dans un conteneur jetable sans identifiants, c'est un bon moyen de faire tourner de longues tâches sans surveillance. Sur votre laptop, avec vos clés SSH et vos sessions de navigateur connectées, c'est comme ça qu'on finit en vedette d'un post-mortem. On l'utilise dans des sandboxes CI et nulle part ailleurs.

Par projet contre global : où chaque élément vit

Tout ce qui précède existe à deux niveaux, et les confondre est le bazar de configuration le plus courant qu'on observe. La répartition :

Élément	Global (~/.claude/)	Par projet (.claude/ dans le repo)
CLAUDE.md	Votre style personnel : longueur de réponse, langues, manies	Commandes de build, architecture, conventions du projet (à committer)
Skills	Tout ce qui est général : débogage, TDD, écriture	Workflows spécifiques à l'équipe seulement
Settings	Votre liste blanche personnelle	Liste blanche et règles de refus de l'équipe (à committer)
settings.local.json	—	Vos surcharges propres à la machine (à mettre au .gitignore)
Serveurs MCP	Serveurs que vous utilisez partout	Le .mcp.json du projet, pour que l'équipe ait les mêmes connexions

Le principe : tout ce dont un coéquipier aurait besoin va dans le repo, tout ce qui vous concerne personnellement va en global. Le gain se voit quand quelqu'un de nouveau clone le projet et que Claude connaît déjà les commandes de build et les conventions, avec la connexion à la base de données prête. Ses couches 2 et la moitié de sa couche 4 sont offertes.

Ma configuration après six mois

Ce qui survit réellement sur ma machine, pour donner un ordre de grandeur : un CLAUDE.md de projet de 54 lignes, neuf skills, deux serveurs MCP (Postgres et Playwright), et le bloc de permissions ci-dessus. Les sessions de configuration ressemblent à celles d'il y a six mois ; la différence, c'est tout ce que j'ai supprimé.

Les suppressions m'ont plus appris que les ajouts :

J'ai retiré le serveur MCP GitHub. Je l'ai gardé quatre mois par inertie. Ses définitions d'outils coûtaient des milliers de tokens permanents par session et gh faisait le même travail. Rien ne s'est dégradé. Cette seule suppression a rentabilisé le temps passé à écrire cet article.

J'ai retiré un serveur MCP de mémoire au profit du skill Memory Management. Le serveur était un processus de plus à surveiller et une authentification de plus à maintenir. Le skill fait le travail dans de simples fichiers que je peux lire et modifier moi-même. Quand la mémoire déraille, j'ouvre le markdown et je corrige, ce que je ne pouvais jamais faire avec un stockage opaque.

J'ai réduit CLAUDE.md de 400 à 54 lignes. La version longue se lisait comme une bonne documentation et se comportait comme du bruit. Le respect des règles qui comptaient a augmenté quand les règles qui ne comptaient pas ont été supprimées. Je traite désormais chaque ligne comme un loyer.

J'ai désinstallé 19 skills sur 28. La plupart étaient des installations « ça pourrait servir » qui ne se sont jamais déclenchées en situation réelle. Le chargement paresseux fait qu'ils coûtent peu, mais des descriptions qui se chevauchaient ont causé deux vrais conflits de déclenchement, et l'audit qui les a trouvés a été fastidieux. Neuf skills qui se déclenchent chaque semaine valent mieux que 28 qui, pour la plupart, ne le font pas.

J'ai annulé une règle générale Bash(*) en autorisation. Ajoutée pendant une semaine de deadline, gardée trop longtemps. Le jour où Claude a lancé avec assurance une migration destructrice contre une base de développement qui s'est révélée moins jetable qu'étiquetée, j'ai remis les invites pour tout ce qui écrit.

Le motif commun aux cinq cas : je n'ai jamais regretté une suppression. J'ai souvent regretté des ajouts.

Les erreurs classiques de la première semaine

Cinq choses que presque tout le monde fait la première semaine, pour que vous puissiez les éviter :

1. Écrire le CLAUDE.md de 500 lignes le premier jour. Vous ne savez pas encore ce que Claude fait mal dans votre repo. Commencez avec 15 lignes et faites-le grandir à partir des échecs observés.
2. Installer tous les serveurs MCP qui semblent intéressants. Chacun taxe chaque session. Commencez à zéro et ajoutez-en un quand vous butez sur un mur qu'il résout.
3. Lancer --dangerously-skip-permissions sur votre machine principale parce que les invites vous agaçaient. Mettez plutôt les commandes sûres en liste blanche ; ça élimine 90 % des invites sans l'exposition.
4. Installer des skills sans jamais vérifier qu'ils se déclenchent. La moitié de la valeur d'un skill meurt dans un champ de description vague. Testez chacun avec une demande naturelle, sans nommer le skill.
5. Garder la configuration hors du repo. Si le CLAUDE.md et le settings.json de votre projet ne sont pas committés, chaque coéquipier reconstruit mal votre configuration de mémoire.

Maintenance : quoi revoir après chaque release de Claude

Une configuration réglée pour une version de modèle dérive sur la suivante. Après chaque release Claude significative, passez 20 minutes sur quatre vérifications.

Relisez votre CLAUDE.md et supprimez les règles dont le nouveau modèle n'a plus besoin. Les montées de version rendent régulièrement des instructions obsolètes ; la règle « lance toujours le linter » que vous avez écrite il y a un an est peut-être devenue un comportement par défaut que vous payez en tokens pour répéter.

Retestez les déclencheurs de vos skills. La correspondance de déclenchement est un comportement du modèle, pas une correspondance de mots-clés, donc une description qui se déclenchait de façon fiable sur un modèle peut devenir silencieuse sur le suivant. Notre catalogue retest les meilleurs skills après les releases majeures, et les pages de chaque skill portent le verdict actuel.

Remesurez votre surcharge de contexte. Les nouvelles releases changent parfois la façon dont les définitions d'outils MCP sont comptées ou mises en cache. L'outillage d'efficacité sur notre liste des skills d'efficacité est ce vers quoi on oriente les gens qui veulent auditer ce qui grignote vraiment leur budget ; plusieurs skills de cette catégorie existent précisément pour cette vérification.

Et vérifiez le changelog pour les changements de modèle de permission avant que les settings de votre équipe ne signifient silencieusement autre chose. Ça prend cinq minutes et ça nous a sauvés deux fois.

FAQ

30 minutes, c'est réaliste, honnêtement ?

Pour les couches 1 à 5 telles que décrites, oui, on l'a chronométré avec des nouvelles recrues. Ce qui prend plus longtemps, c'est le réglage fin : votre CLAUDE.md atteint sa forme stable après deux ou trois semaines à repérer les erreurs répétées de Claude. Prévoyez 30 minutes pour la construction et quelques minutes de réglage par jour pendant la première quinzaine.

Ai-je besoin de serveurs MCP ?

Beaucoup de bonnes configurations en font tourner zéro. Si votre travail vit dans le repo (code, tests, docs), skills plus outils en ligne de commande couvrent tout. MCP mérite son coût quand Claude a besoin d'un accès en direct à quelque chose d'externe, et une base de données est le cas concret le plus courant. Dans le doute, commencez sans et ajoutez le serveur la première fois que vous sentez le mur.

CLAUDE.md doit-il être global ou par projet ?

Les deux, portant des choses différentes. Le global (~/.claude/CLAUDE.md) porte vos préférences personnelles et s'applique partout. Le par-projet porte les commandes de build et les conventions, et a sa place dans git pour que toute l'équipe le partage. L'erreur, c'est de mettre des faits propres au projet dans le fichier global, où ils polluent les sessions de tous les autres projets.

Combien de skills, c'est trop ?

Côté tokens, le plafond est haut : même 50 skills ne coûtent que quelques milliers de tokens de métadonnées permanentes. Le plafond pratique est plus bas parce que des skills aux descriptions qui se chevauchent finissent par se disputer les mêmes déclencheurs. On en fait tourner neuf. Au-delà de 15 environ, il vaut mieux élaguer ce qui ne s'est pas déclenché depuis un mois plutôt qu'en ajouter.

Puis-je sauter la couche des permissions si je travaille en sandbox ?

Si la sandbox est vraiment jetable, sans identifiants, sans volumes montés qui comptent, alors oui, et --dangerously-skip-permissions existe exactement pour ça. La couche compte sur les machines avec de vrais secrets. La « sandbox » de la plupart des gens est un laptop avec ses clés AWS de production dans un dotfile, ce qui n'est pas une sandbox.