ça ressemble à quoi, mon setup Claude Code ?

Dans ma veille, je vois passer beaucoup de guides de setup avec 18.000 skills et 5000 hooks pour répondre à tous les besoins mais peu de REX de setup en situation réelle. Pendant ce temps, les collègues ont vu la lumière et basculent vers Claude Code et ... se perdent dans les possibilités. J'ai décidé de vous montrer mon setup Claude Code — c'est ce qui tient après 6 mois, et dans quel ordre je l'aurais fait si c'était à refaire.

Pendant 6 mois, j'ai configuré et joué sur plusieurs paramètres (claude.md, config MCP, settings, skills). J'ai repris plein de bonnes idées de @florian Brugniaux qu'il a stockées dans son (claude code ultimate guide. 4 organisations séparées, ~12 repos et des contextes hétérogènes entre le pro et le perso : infra Terraform, blog, 2e cerveau.

Profil archi technique, pas un profil dev — vous verrez des usages infra, editorial, veille, peu de code pur.

Table des matières

• La configuration préalable du poste

• Quelle configuration de Claude a été mise en place et où ?

• Agent schedulé

• Repo par repo

• L'heure du bilan

• Conclusion

1. La configuration préalable du poste

Avant de configurer quoi que ce soit, le poste a besoin d'une base. Vos skills notamment vont réclamer plein d'outils et ... vous le découvrirez quand vous vous en servirez.

C'est un manque actuellement de ne pas avoir les prérequis à une skill et/ou un agent

Voici un extract de que qui a été installé en tools et pourquoi :

Outil Pourquoi

git + gh

Manipuler git et GitHub depuis le terminal — remplace le MCP GitHub sans le moindre regret

jq Requis par RTK

python3 + pip

Claude Code génère régulièrement des scripts Python — mieux vaut l'avoir d'emblée

nvm + Node 20 Prérequis pour installer et faire tourner les MCP servers en npm/npx

agent-browser CLI de navigation web — plus souple que Playwright CLI, moins consommateur que les MCP browser

pandoc + libreoffice

Prérequis des skills docx / pptx / pdf

RTK Proxy token-killer : réécrit les commandes verboseuses transparentement, économies sur les tokens de sortie

Tabby Terminal avec onglets paramétrables et split d'écrans en plus — devenu mon terminal fétiche

Extension Claude Code (VS Code) Plugin Claude Code dans l'IDE

2. Quelle configuration de Claude a été mise en place et où ?

La configuration de Claude impose de se projeter sur l'organisation et les permissions/hooks/skills/... que l'on veut configurer et à quel niveau. Soit en général (le settings.json et le settings.local.json de l'organisation), soit par projet.

L'anatomie du dossier ~/.claude/ global

Claude Code hérite et compose trois niveaux de configuration :

~/.claude/settings.json → global /.claude/settings.local.json → organisation /CLAUDE.md → projet

~/.claude/settings.json → global /.claude/settings.local.json → organisation /CLAUDE.md → projet

Enter fullscreen mode

Exit fullscreen mode

La couche organisation reste pour l'instant vide (à travailler quand on sera en Claude Enterprise)

settings.json : déterministe vs inférentiel

settings.json est déterministe : si git push --force est dans la deny list, l'opération est physiquement impossible. Le modèle ne peut pas l'exécuter, quoi qu'il arrive.

CLAUDE.md est porté par l'inférence : l'agent lit les instructions et fait de son mieux pour les respecter. Mais "De son mieux" n'est pas une garantie : Une règle dans CLAUDE.md peut être mal interprétée, oubliée en fin de contexte, ou contredite par une instruction conversationnelle.

Conséquence pratique : tout ce qui est critique ou irréversible va dans settings.json. Le reste va dans CLAUDE.md.

{  "permissions": {  "deny": [  "Bash(git push --force*)",  "Bash(git reset --hard*)",  "Bash(git branch -D*)"  ]  } }

{  "permissions": {  "deny": [  "Bash(git push --force*)",  "Bash(git reset --hard*)",  "Bash(git branch -D*)"  ]  } }

Enter fullscreen mode

Exit fullscreen mode

Hooks globaux

La configuration des Hooks se fait aussi dans le settings.json. Elle peut faire référence (souvent) à des scripts qu'il faut télécharger (voir doc install)

La différence avec la liste de permission : La liste de permission bloque/autorise les patterns de commandes connus à l'avance. Les hooks inspectent le contenu réel de ce qui va être exécuté.

Trois hooks en place, extraits du Claude Code Ultimate Guide :

dangerous-actions-blocker.sh — couvre les commandes destructives (rm -rf, fork bomb, DROP TABLE), le force push sur main/master, l'édition des fichiers sensibles (.env, clés SSH, credentials), et avertit sur toute suppression de fichier.

security-check.sh — bloque toute commande Bash contenant des patterns de secrets (password=, api_key=, sk-xxxxx). Deuxième couche après la blocklist git.

rtk-auto-wrapper.sh — réécrit automatiquement les commandes verboseuses (git log, git diff, cargo test...) vers leurs équivalents rtk. Transparent pour l'agent, 60-90% d'économies sur les tokens de sortie.

MCP globaux

Toujours dans le settings.json, j'avais déclaré 3 serveurs MCP — disponibles dans tous les projets sans configuration par repo.

INFO: Claude code hérite de la configuration des MCP de Claude.ia Vous pouvez en configurer d'autres directement via la commande claude mcp add (doc) ou via le fichier settings.json L'usage de npx dans les paramètres d'exécution du MCP permet l'installation et exécution du MCP

github — accès à l'API GitHub. Devenu superflux en pratique : gh fait tout aussi bien depuis le terminal, et Claude Code l'utilise nativement. À retirer.

context7 — documentation à jour des librairies. Utile ponctuellement quand on touche une stack peu familière et qu'on veut éviter les hallucinations de versions obsolètes. Usage au besoin, pas systématique.

puppeteer — browser headless Chrome. Pratique mais remplacé depuis par le CLI agent-browser, plus souple et mieux intégré dans les workflows Claude Code. A retirer.

MCP de Claude.ai :

Slack — connecteur Slack (pour se connecter à Slack, pratique quand on a un Slack gratuit, ça permet d'extraire des infos intéressantes facilement)

Excalidraw — génération et édition de schémas visuels directement depuis Claude Code.

Mermaid Chart — production de diagrammes textuels (flowcharts, séquences, entités) intégrable en format markdown.

Skills et Plugins globales

Les skills sont des procédures configurées au global et réutilisables entre projets.

Vous pouvez télécharger des Skills existantes et les déposer dans ce répertoire pour les installer

Les plugins Skills sont des lots de skills proposés sur un marketplace et installables dans un contexte donné :

• Install for you (users scope) préconisé pour plugin global

• Install for all collaborators on this repository (project scope)

• Install for you, in this repo only (local scope) Ils s'installent dans claude code (via la commande /plugin)

Les plugins que j'ai installés et conservés : superpowers le plugin PowerTools de Claude Code :) link Utilisé de manière plutôt transparente, il surperforme les actions de Claude Code : • Commands: execute-plan, brainstorm, write-plan • Agents: code-reviewer

document-skills doc-coauthoring, mcp-builder, skill-creator (pour créer des skills et des MCP) docx , pdf, pptx, xlsx (pour gérer les fichiers office, lecture, création et modifications)

Ces plugins m'ont permis de ne pas avoir besoin de créer trop de skills spécifiques et sont maintenus par Anthropic.

• 2 skills persos.

save-config — git add / commit / push de tout ~/.claude/ vers un repo GitHub privé. Versionner sa config Claude Code comme du code. Utile avant de modifier des hooks ou des CLAUDE.md globaux. Work in progress : il manque le restore config

document-organizer — tri et déplacement de fichiers (du dossier Téléchargements en bordel) vers leurs destinations (NAS ou local). Utilisé avec la commande /trier.

CLAUDE.md vs /commandes vs agents

Une nuance qui explique que j'ai aussi peu de commandes custom : il y a trois façons d'exposer des procédures à l'agent.

Les prompts dans CLAUDE.md sont contextuels — l'agent les lit et peut les appliquer selon son interprétation. Flexible, mais pas garanti.

Les /commandes réelles (fichiers dans .claude/commands/) sont des procédures fixes — l'agent les exécute telles quelles, sans interprétation. Utile pour les workflows critiques où la reproductibilité prime.

Les agents (fichiers dans .claude/agents/) sont des sous-processus avec leur propre contexte, leurs propres outils, leur propre modèle. Le pattern le plus utile : L'agent orchestre un ensemble de skills pour atteindre un objectif, chacune de ces skills effectuent une action technique précise.

Les custom commands (.claude/commands/) deviennent finalement peu utilisées en pratique — la plupart des procédures trouvent leur place dans le CLAUDE.md ou dans la déclaration d'agents qui consomment peu de tokens.

3. Agent schedulé

DevwithIA produit beaucoup de contenu — canaux actifs, threads, partages de ressources. Pas toujours le temps de tout lire.

Du coup, j'ai créé un remote trigger qui tourne chaque matin à 8h30 sur claude.ai : En sandbox uniquement connecté aux MCP de claude.ai, l'agent lit tous les canaux, résume l'activité des dernières 24h et m'envoie un DM Slack avec le contenu des jours précédents.

Ce qui distingue ce setup d'un simple cron en local : l'agent vit entièrement dans le cloud Anthropic. Localement, j'ai conservé la configuration du trigger ID afin de le retrouver.

Une limite à connaître : ces agents ne peuvent pas faire d'appels HTTP directs vers des APIs externes. Pas de webhook custom, pas d'email via Resend. Uniquement les connecteurs MCP approuvés (Slack, GitHub...). Découvert en essayant d'envoyer un résumé par email — le proxy egress du sandbox bloque le trafic sortant vers des tiers.

Note: ce remote trigger impose d'utiliser un MCP dans claude.ai. On va le retrouver configuré pour Claude code donc pas nécessaire d'installer un plugin en plus

4. Repo par repo

Chaque folder (repo) peut aussi accueillir une configuration dédiée. Il est recommandé de versionner ce répertoire .claude/ spécifique au projet.

3 Etapes :

• créer un repository vide

• git clone

• dans le répertoire, claude puis /init ou copie-colle du CLAUDE.md

• prompt 1 "configure le .gitignore et versionne le répertoire .claude"

• prompt 2..n : "installe la skill / command / à partir de l'URL <...>"

Blog éditorial

Problème : Un repo qui a commencé comme simple espace de rédaction d'articles, et qui a grandi : récolter les idées qui me passent par la tête, créer des bases de savoir, et pouvoir générer des livrables sous formes multiples (articles, docs, REX, talks). Maintenir une cadence LinkedIn régulière demandait des relectures systématiques — pas une fois sur deux selon la fatigue du jour. Et chaque session recommençait à zéro : expliquer le pipeline, rappeler le ton attendu, préciser la cible.

Solution : CLAUDE.md éditorial complet (200lignes) — pipeline idée → knowledge → output, familles de contenu, guide de style avec anti-patterns IA nommés et justifiés, session start ritual avec choix de phase (idée, knowledge, output).

Deux prompts de review nommés :

Review Article : persona journaliste expérimenté. Focus : hook (2 lignes ?), exemples concrets vs abstractions, ton (praticien vs promotionnel), comptage vs cible LinkedIn, qualité du CTA.

Review Article : persona journaliste expérimenté. Focus : hook (2 lignes ?), exemples concrets vs abstractions, ton (praticien vs promotionnel), comptage vs cible LinkedIn, qualité du CTA.

Review Lecteur : lecteur saturé du contenu IA générique. Scoring /10 sur 4 axes : rigueur argumentaire, qualité sources, professionnalisme du ton, précision des données.`

Enter fullscreen mode

Exit fullscreen mode

Le scoring /10 reste aussi pratique pour mesurer la progression (ou récession).

le setup étant gros, contactez-moi si vous voulez le contenu

Lab Scaleway / infra

Problème : Un lab infra en cours, avec deux besoins parallèles : écrire un REX publiable ET conserver une doc technique précise des choix, des décisions, des problèmes rencontrés. Et pour être probant — montrer que l'IA a vraiment été utilisée sur un projet réel — il fallait des traces : durée des sessions, nombre d'itérations, complexité des opérations. Sans ça, "j'ai fait ça avec Claude Code" reste invérifiable.

Solution : Hooks PostToolUse et SessionEnd qui journalisent chaque appel d'outil dans des fichiers Markdown horodatés. Commande Bash exécutée, fichier écrit, fichier édité — tout est loggué dans un sous-répertoire du repo ia-logs/. Cela apporte une observabilité native des sessions sur un repo où les erreurs ont des conséquences réelles.

Deux personas de review dans le CLAUDE.md : un ingénieur senior et un speaker de conférence — pour relire la doc technique avec deux angles différents.

Thinking — le 2e brain perso

Problème : Des projets personnels sans code — refonte de CV, tri de 15 ans de photos sur un NAS et deux comptes Onedrive, recherche d'une maison. Des sujets hétérogènes, des besoins ponctuels, chacun avec son contexte propre à ne pas réexpliquer à chaque session.

Solution : Un répertoire thinking/ structuré comme un 2e cerveau, avec un CLAUDE.md par domaine. Le principe est le même que pour les repos code : poser la problématique une fois, travailler en équipe avec l'IA, développer des stratégies adaptées au besoin.

thinking/jobs/ — refonte du CV et analyse d'adéquation CV/annonce. Le CLAUDE.md contient un persona /headhunter complet : chasseur de tête IT senior, formulations types, cas d'usage. Plutôt que d'expliquer le rôle attendu à chaque fois, il est encodé une fois et activé à la demande.

thinking/IT/ — au départ pour les sujets IT, il a porté surtout un sujet de tri de photos NAS + OneDrive sur deux comptes sans perte. Les règles métier sont dans le CLAUDE.md : déplacer vers trash/ plutôt que supprimer, scripts idempotents, chemins via variables d'environnement. Et surtout, Claude ne fait que fournir les commandes, c'est moi qui les exécute.

thinking/maison/ — plusieurs sujets immobiliers : scraping d'annonces, comparaison de biens, stratégies de recherche. Le CLAUDE.md conserve le contexte après la fin d'un projet — mémoire de ce qui a été fait, pour ne pas repartir de zéro si le sujet reprend. Faire une liste excel à partir des pdf des différentes annonces (merci les skills pdf et xlsx :)

thinking/orga/ — ici, un truc tout bête : reposer l'organisation de la semaine pour en créer des évènements à rajouter dans un agenda Google. Du one-shot pour générer des fichiers .ics avec la récurrence nécessaire pour Google Agenda.

thinking/voiture/ — Calcul de TCO global et comparatif de scénarios entre thermique, EV, hybride. Donc recherche sur Internet sur les différents modèles avec consommation, prix, moteur, et création d'un xlsx de comparaison.

5. L'heure du bilan

Ce qui fonctionne bien

Le digest Slack automatisé chaque matin est appréciable pour repérer ce que je ne dois pas rater dans le slack. Les "skills" de review restent pour moi utiles pour leurs retours et critiques, même si c'est facile de craquer avec ces avis qui deviennent parfois contraires entre les sessions. Les sessions du lab génèrent bien des logs de sessions de manière automatique.

Et ces skills docx/pptx sont une super découverte : Elles vous permettent de travailler en markdown versionné puis de de créer rapidement et sans trop d'efforts un doc/ppt Office.

Enfin, le 2e cerveau, c'est peut-être ce qui m'impacte le plus sans que je réalise vraiment : Entre ce thinking/ pour les projets perso et le blog pour les idées tech, ma charge mentale s'est allégée.

Moins de Post-it mentaux à garder en tête et plus d'espace pour penser. (mais du coup, hop une nouvelle idée, vite, claude, mon dieu cela ne s'arrêtera pas)

Ce qui m'irrite encore

L'aide à la rédaction de l'IA ramène toujours aux mêmes éléments de ton et de style rédactionnel. Et ce style "formaté IA", c'est insupportable pour moi. Vraiment, sur un petit bout de texte, c'est bien. Mais lui demander de réécrire un article, ça peut virer au cauchemar.

En plus, les skills d'amélioration rajoutent beaucoup de verbose dans les fichiers de configuration. Donc si à chaque erreur, Claude décide de rajouter une règle, ça empile et ça empire. A force, je trouve que cela dégrade les performances des réponses.

Enfin, je n'ai pas encore trouvé comment partager entre 2 ordinateurs un repo commun avec une configuration de Claude code globale (le blog sur lequel je travaille aussi sur mon temps perso). Je perds systématiquement la memory qui est stockée dans le ~/.claude et pas dans le projet. Vous avez vu la skill save-config qui tente déjà de sauvegarder, reste à restaurer maintenant :) En environnement d'entreprise, je partirais sur des solutions plus robustes comme Packmind par exemple.

Ce qui manque encore

Je ne systématise pas encore le Plan Mode (/plan, lecture seule avant toute opération lourde). Alors que pourtant j'applique un process "spec->plan->ask". Je lui demande de "planifier avant d'agir" mais ça reste une instruction, pas une contrainte technique. /plan rend l'agent physiquement incapable d'écrire pendant la phase d'exploration. Ce ne sont pas deux façons équivalentes de faire la même chose.

Les rules/ (fichiers d'instructions modulaires, réutilisables entre projets) ne sont pas encore utilisées. Je ne vois pas encore comment elles peuvent fonctionner et ce qu'elles peuvent apporter.

6. Conclusion

Voici un point d'entrée concret (setup et usage) : De quoi voir par vous-même si les enthousiastes de l'IA ont raison — ou pas.

Et vous, au fait, vous avez quoi comme setup Claude Code ?