L'écosystème Claude Code part dans tous les sens : agents, commandes, mémoire, workflows, hooks, MCP… Des dizaines de threads, chacun sa méthode, et personne ne te dit par où commencer. Voici la carte : les 4 briques qui comptent vraiment, les règles qui changent la qualité de sortie, et comment poser une config propre sans lire 40 fils. De quoi passer de « je bricole » à une config qui tient.
C'est quoi ce repo, et ce que fait la skill
GitHub, en clair. C'est le lieu public où les développeurs déposent et partagent leurs projets — une bibliothèque ouverte du code et de la documentation technique. Un « repo » (dépôt), c'est simplement un dossier de projet que tout le monde peut consulter et copier. Celui ci-dessous rassemble, au même endroit, les bonnes pratiques Claude Code habituellement éclatées dans des dizaines de fils.
⭐ Ouvrir le repo GitHub des bonnes pratiques →
Ce que fait la skill. Une skill, c'est un mode d'emploi que Claude Code déclenche tout seul quand le contexte s'y prête. Celle des bonnes pratiques s'appuie sur cette base pour t'éviter tout le travail de tri :
1️⃣ regroupe les bonnes pratiques au même endroit — agents, commandes, mémoire, workflows ;
2️⃣ commence par te poser des questions sur ce que tu veux construire ;
3️⃣ va chercher les bonnes infos directement dans ton projet ;
4️⃣ construit la config elle-même, sans que tu aies à tout réexpliquer.
Résultat : tu passes de « je lis 40 threads pour bricoler ma config » à « je réponds à trois questions et c'est en place ». La carte ci-dessous, c'est ce qu'elle met en musique — bon à connaître, que tu utilises la skill ou que tu règles à la main.
1La carte : les 4 briques (et quand chacune)
Avant de plonger dans le détail, sache à quoi sert quoi. La plupart des gens mélangent tout — d'où le casse-tête. Chaque brique a un seul job.
La mémoire (le fichier CLAUDE.md) : ce que Claude doit savoir en permanence sur ton projet — le contexte, les règles, le ton. C'est la brique la plus rentable : bien réglée, tu arrêtes de tout réexpliquer à chaque session.
Les commandes (tes raccourcis) : une tâche que tu répètes tous les jours devient une commande réutilisable, versionnée avec le projet. Tu la tapes une fois, elle rejoue le même prompt à chaque fois.
Les agents (les sous-traitants) : pour une tâche lourde et bornée (fouiller le code, chercher, tester), tu délègues à un agent dédié qui bosse dans sa propre bulle et te rend juste la conclusion — sans polluer ta conversation principale.
Les workflows (l'ordre des opérations) : la séquence dans laquelle tu enchaînes tout ça. Le bon ordre vaut plus que le bon outil.
2La mémoire : la brique la plus rentable
Le principe. CLAUDE.md est lu au début de chaque session. C'est là que tu mets une fois pour toutes ce que tu répètes sans arrêt : « voici mon projet, mes conventions, ce qu'il ne faut jamais faire ». Bien fait, c'est la différence entre un assistant qui « connaît la maison » et un stagiaire qui redécouvre tout chaque matin.
Ce qu'on y met. Le rôle du projet, les commandes pour lancer/tester, les conventions, les interdits. Ce qu'on n'y met pas : ce que Claude peut déjà lire dans le code ou l'historique git. La mémoire sert à ce qui n'est pas déductible.
3Le contexte : le levier n°1 sur la qualité
Le vrai secret que personne ne dit. La qualité ne s'effondre pas parce que Claude « n'est pas assez intelligent » — elle s'effondre quand la conversation est trop chargée. Plus le contexte se remplit, plus les réponses deviennent molles.
Ce que ça change dans ta pratique : ouvre une session neuve pour chaque nouvelle tâche au lieu d'empiler ; démarre en mode plan avant de laisser Claude écrire ; délègue les fouilles à un agent pour garder ta conversation propre ; quand ça part mal, reviens en arrière plutôt que d'accumuler des rustines par-dessus l'erreur.
4Automatiser vs piloter : où passe la ligne
Tout l'art est de savoir ce que tu délègues à la machine et ce que tu gardes en main. La règle : on automatise le mécanique et répétitif, on pilote le jugement.
| Ce que tu automatises (une fois) | Ce que tu gardes en main |
|---|---|
| Les tâches répétées → commandes | Le cadrage : quoi construire, pour qui |
| Le formatage, les permissions → hooks | La validation du plan avant exécution |
| Les fouilles et tests → agents | La relecture finale avant de livrer |
| Le contexte projet → mémoire | La décision quand deux options se valent |
Un hook, c'est une action déclenchée automatiquement à un moment précis (ex. reformater le code après chaque écriture). Tu le règles une fois, il tourne tout seul — c'est ça qui te fait gagner les heures de setup répétées.
5Le bon ordre : le workflow qui converge
La séquence qui revient chez tous ceux qui livrent vraiment : comprendre → planifier → exécuter → relire → livrer. Le piège classique, c'est de sauter direct à « exécuter ». Les deux premières étapes sont celles qui te font gagner du temps.
Et quand un résultat te paraît trop beau : demande-lui de prouver que ça marche plutôt que de le croire sur parole. « Montre-moi que ce cas passe » vaut mieux qu'un « c'est bon ».
Ta config propre en 3 décisions
Tu n'as pas besoin de tout brancher. Voici l'ordre de priorité si tu démarres — chaque ligne se suffit à elle-même.
| Brique | À quoi ça sert | Le piège à éviter | Priorité |
|---|---|---|---|
Mémoire (CLAUDE.md) | Arrêter de tout réexpliquer | Un pavé de 500 lignes | ★ D'abord |
| Contexte (sessions) | Garder la qualité haute | La conversation fourre-tout | ★ D'abord |
| Commandes | Rejouer tes routines | Automatiser trop tôt | Ensuite |
| Agents | Déléguer les grosses fouilles | En créer avant d'en avoir besoin | Ensuite |
| Hooks | Fiabiliser le répétitif | Sur-ingénierie | Plus tard |
Pour creuser dans le détail, tout est ici : le repo GitHub des bonnes pratiques Claude Code →
