Tout le monde peut faire npm install -g @anthropic-ai/claude-code et taper claude dans un terminal. Ce n'est pas un setup d'équipe — c'est un jouet individuel. La différence entre un développeur qui s'amuse avec Claude Code et une équipe de cinq qui livre avec, c'est : un CLAUDE.md commité avec des règles non-négociables, un wrapper de commandes qui empêche les agents de faire des bêtises, des hooks qui appliquent vos standards automatiquement, et une librairie de skills partagée qui capitalise au lieu de se répéter.

Ce guide couvre exactement ça. Pas les bases — vous savez installer un package npm. Je pars du premier commit de votre CLAUDE.md jusqu'à l'onboarding du prochain développeur en 15 minutes.

1. Installation — la partie courte

Node 18+, puis :

npm install -g @anthropic-ai/claude-code
claude  # premier lancement — authentification OAuth Anthropic

Claude Code utilise votre compte Anthropic directement. Pas de clé API à distribuer à l'équipe pour le CLI (les intégrations API directes sont différentes). Chaque développeur s'authentifie avec son propre compte. Pour une équipe, créez une organisation Anthropic et partagez les modèles via un plan Team — vous aurez une facturation centralisée et des limites de tokens communes.

Ce qui compte davantage que l'installation : comprendre les deux niveaux de configuration qui définissent comment Claude se comportera pour votre équipe.

2. Architecture CLAUDE.md — global vs projet

Claude Code lit deux fichiers CLAUDE.md au démarrage, dans cet ordre :

La règle simple : le global contient ce qui ne change pas d'un projet à l'autre (votre style personnel, vos raccourcis mentaux). Le projet contient ce qui définit ce projet : namespaces, règles d'architecture, chemins de build, conventions de test propres à la solution.

Voici un extrait représentatif d'un CLAUDE.md projet pour une solution .NET Clean Architecture :

# CLAUDE.md — Projet BFF Client API

## Stack
.NET 9, Clean Architecture, DDD, CQRS, MassTransit.
Solution : Edenred.Smarter.Client.Bff.sln

## Commandes
```bash
dotnet build Edenred.Smarter.Client.Bff.sln
dotnet test tests/Edenred.Smarter.Client.Bff.Integration.Tests --no-build
dotnet format Edenred.Smarter.Client.Bff.sln --verify-no-changes
```

## Style de code (non-négociable)
- `if(` pas `if (` — idem pour `foreach(`, `for(`, `while(`, `switch(`
- Toujours des accolades — zéro corps de branche sans accolades
- `const`/`static readonly` → PascalCase, champs d'instance → `_camelCase`
- Avant tout `if`/`return`, vérifier si un ternaire ou un early return est plus simple
  Éviter : Sonar IDE0046, S3358 (ternaire imbriqué)

## Règles TDD (absolues)
- Code avant tests = DELETE — vérifier `git diff` avant tout commit green:
- Chaque test doit avoir une valeur métier — jamais tester le langage ou le framework
- Commit rouge avant d'écrire une ligne de production — sans exception

## Préfixes de commit
red: | green: | refactor: | fix: | feat: | infra: | kaizen: | security:
JAMAIS de commit multi-phase. JAMAIS de Co-Authored-By.

## Conventions namespace
- API : Edenred.Smarter.Client.Bff.Api.*
- Application : Edenred.Smarter.Client.Bff.Application.*
- Infrastructure : Edenred.Smarter.Client.Bff.Infrastructure.*

## Patterns interdits
- Logique métier dans les handlers → domaine uniquement
- `async void` — jamais, sauf event handlers UI
- `.Result` ou `.Wait()` sur une Task — jamais
- `new HttpClient()` directement — toujours IHttpClientFactory
- Catch sans log ni rethrow — silencieux est pire que cassé

Ce qui rend ce fichier utile n'est pas sa longueur — c'est sa précision. "Évitez les mauvaises pratiques" ne sert à rien. "`.Result` ou `.Wait()` sur une Task — jamais" est une règle qu'un agent peut vérifier et appliquer mécaniquement.

3. Le pattern RTK — votre garde-fou contre les agents imprudents

Les agents IA émettent des commandes shell avec la même confiance quel que soit le contexte. Un agent peut émettre git push juste après avoir introduit une régression, ou git reset --hard parce que ça "simplifie" son plan. Sans interception, vous ne le verrez qu'après.

RTK est un wrapper bash trivial à écrire, mais non-trivial dans ses effets : il passe toutes les commandes sans modification par défaut, mais vous pouvez intercepter n'importe quelle commande pour ajouter une vérification, un log, ou un blocage.

#!/usr/bin/env bash
# ~/.local/bin/rtk
# Usage : rtk <commande> [args...]
# Passe tout à travers sauf les commandes interceptées.

CMD="$1"
shift

case "$CMD" in
  git)
    SUBCMD="$1"
    case "$SUBCMD" in
      push)
        # Bloquer git push si les tests n'ont pas tourné depuis le dernier commit
        LAST_COMMIT=$(git log -1 --format="%H")
        TEST_MARKER="$HOME/.rtk/last-tested-commit"
        if [ ! -f "$TEST_MARKER" ] || [ "$(cat "$TEST_MARKER")" != "$LAST_COMMIT" ]; then
          echo "[RTK] BLOQUÉ : aucun test validé pour le commit $LAST_COMMIT"
          echo "[RTK] Lancez : rtk dotnet test <solution> --no-build"
          exit 1
        fi
        git "$SUBCMD" "$@"
        ;;
      reset)
        # reset --hard nécessite confirmation explicite
        if echo "$@" | grep -q "\-\-hard"; then
          echo "[RTK] git reset --hard détecté. Tapez 'CONFIRMER' pour continuer :"
          read -r CONFIRMATION
          if [ "$CONFIRMATION" != "CONFIRMER" ]; then
            echo "[RTK] Annulé."
            exit 1
          fi
        fi
        git "$SUBCMD" "$@"
        ;;
      *)
        git "$SUBCMD" "$@"
        ;;
    esac
    ;;
  dotnet)
    SUBCMD="$1"
    case "$SUBCMD" in
      test)
        START=$(date +%s)
        dotnet "$SUBCMD" "$@"
        EXIT=$?
        END=$(date +%s)
        DURATION=$((END - START))
        echo "[RTK] dotnet test terminé en ${DURATION}s (exit: $EXIT)"
        if [ $EXIT -eq 0 ]; then
          # Marquer les tests comme validés pour le commit courant
          mkdir -p "$HOME/.rtk"
          git log -1 --format="%H" > "$HOME/.rtk/last-tested-commit"
        fi
        exit $EXIT
        ;;
      build)
        START=$(date +%s)
        dotnet "$SUBCMD" "$@"
        EXIT=$?
        END=$(date +%s)
        echo "[RTK] dotnet build terminé en $((END - START))s (exit: $EXIT)"
        exit $EXIT
        ;;
      *)
        dotnet "$SUBCMD" "$@"
        ;;
    esac
    ;;
  *)
    # Tout le reste passe sans modification
    "$CMD" "$@"
    ;;
esac

Rendez-le exécutable et placez-le dans votre PATH :

chmod +x ~/.local/bin/rtk
# Dans votre CLAUDE.md global, préfixez toutes les commandes :
# TOUTES les commandes shell utilisent le préfixe rtk
# Même : rtk git add . && rtk git commit -m "msg" && rtk git push

Le point important : dans votre CLAUDE.md, vous indiquez à Claude que toutes les commandes shell doivent être préfixées par rtk. L'agent obéit. RTK intercepte. Vous dormez mieux.

4. Hooks — ce que Claude fait automatiquement

Les hooks s'configurent dans .claude/settings.json à la racine du projet (commitable) ou dans ~/.claude/settings.json (global). Voici un fichier complet avec les trois hooks les plus utiles pour une équipe .NET :

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "bash -c 'CMD=$(echo \"$CLAUDE_TOOL_INPUT\" | python3 -c \"import sys,json; print(json.load(sys.stdin).get(\\\"command\\\",\\\"\\\"))\"); if echo \"$CMD\" | grep -qE \"rm -rf|git reset --hard|DROP TABLE|truncate\"; then echo \"[HOOK] Commande dangereuse bloquée : $CMD\" >&2; exit 1; fi'"
          }
        ]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Edit",
        "hooks": [
          {
            "type": "command",
            "command": "bash -c 'FILE=$(echo \"$CLAUDE_TOOL_INPUT\" | python3 -c \"import sys,json; print(json.load(sys.stdin).get(\\\"file_path\\\",\\\"\\\"))\"); if echo \"$FILE\" | grep -qE \"\\.cs$\"; then dotnet format --include \"$FILE\" 2>/dev/null || true; fi'"
          }
        ]
      }
    ],
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "bash -c 'echo \"\"; echo \"=== Session Claude terminée ===\"; echo \"Fichiers modifiés depuis le dernier commit :\"; git diff --name-only HEAD 2>/dev/null || echo \"(pas de dépôt git)\"; echo \"\"'"
          }
        ]
      }
    ]
  }
}

Ces trois hooks couvrent les cas les plus fréquents :

Les hooks s'exécutent dans le harness Claude Code, pas dans le modèle. L'agent ne peut pas les désactiver, les contourner, ou les ignorer. C'est la seule façon d'appliquer des contraintes qui tiennent vraiment.

5. Librairie de skills — capitaliser plutôt que répéter

Un skill est un fichier SKILL.md dans un dossier nommé, accompagné d'un prompt d'activation. Quand vous tapez /review dans Claude Code, le harness lit skills/review/SKILL.md et exécute les instructions qu'il contient avec le contexte courant.

La valeur n'est pas dans l'invocation — c'est dans la capitalisation. Un skill bien écrit contient six mois d'expérience de ce qui fonctionne réellement sur votre codebase. Voici l'arborescence type :

.claude/
  skills/
    review/
      SKILL.md         ← instructions de review + checklist des 50 points
    test-design/
      SKILL.md         ← comment concevoir une suite de tests sur ce projet
    kaizen/
      SKILL.md         ← cycle d'amélioration continue automatique
  references/
    learned-errors.md  ← erreurs capturées en production
    kaizen-tracker.md  ← patterns qui montent en sévérité
    dotnet-kill-list.md ← patterns interdits, jamais de wontFix

Skill review — squelette réel

# SKILL — Review
# Déclencheur : /review

## Objectif
Code review profonde sur les changements en cours (git diff HEAD).
Couvre : spec, architecture, sécurité, performance, observabilité.

## Protocole
1. Lire git diff HEAD (ou le périmètre spécifié)
2. Lancer les sous-agents en parallèle :
   - Review Agent : spec + 50 checks techniques
   - Security Agent : OWASP Top 10, IDOR, authz, validation input
   - Performance Agent : N+1, allocations, async pitfalls, EF Core
   - Observability Agent : logs, métriques, health checks
3. Consolider les findings par sévérité : CRITIQUE / MAJEUR / MINEUR / INFO
4. Pour chaque finding CRITIQUE ou MAJEUR : proposer le fix exact, pas juste le problème

## Règles de sortie
- Format : [SÉVÉRITÉ] Fichier:ligne — Description — Fix proposé
- Findings CRITIQUE : bloquer le merge, fix obligatoire
- Findings MAJEUR : fix avant merge sauf exception justifiée dans le PR
- Findings MINEUR et INFO : à traiter dans un ticket kaizen: séparé
- Ne jamais approuver si un finding IDOR est ouvert

## Kill-list automatique
Après chaque /review, relire C:\Users\mikae\.claude\references\learned-errors.md
et vérifier que les patterns de la kill-list ne sont pas présents dans le diff.

Skill test-design — pour ne jamais écrire de mauvais tests

# SKILL — Test Design
# Déclencheur : /test-design

## Objectif
Concevoir une suite de tests pour un aggregate ou un use-case.
Sortie : liste exhaustive de cas de test avec nommage Given_When_Then.

## Protocole
1. Identifier les boundaries de l'agrégat concerné
2. Lister les invariants du domaine (pas les règles de framework)
3. Pour chaque invariant : cas nominal + cas limite + cas d'erreur
4. Identifier les edge cases que la spec n'a pas explicitement couverts
5. Nommer chaque test : Given_{état_initial}_When_{action}_Then_{résultat_attendu}

## Ce qu'on ne teste PAS
- Le comportement de MediatR, EF Core, ASP.NET Core — ce sont des frameworks testés
- La serialisation JSON pour des modèles sans transformation
- Les getters/setters sans logique

## Ce qu'on teste toujours
- Les invariants du domaine — si c'est une règle métier, c'est un test
- Les boundary conditions — exact sur les limites, pas juste les cas heureux
- Les cas d'autorisation — chaque endpoint a un test unauthorized + forbidden

Skill kaizen — l'amélioration continue automatique

# SKILL — Kaizen
# Déclencheur : /kaizen (ou automatique après /review, après un bug fix)

## Objectif
Cycle d'amélioration continue : capturer les patterns d'erreur,
les escalader en sévérité, les transformer en règles de kill-list.

## Cycle
1. Lire learned-errors.md + kaizen-tracker.md
2. Identifier les patterns qui apparaissent 3+ fois → escalade L1→L2
3. Identifier les patterns L2 qui apparaissent 5+ fois → escalade L2→L3
4. Les patterns L3 → ajout dans dotnet-kill-list.md (règle permanente)
5. Mettre à jour kill-list dans CLAUDE.md projet si règle applicable à tous
6. Commiter avec préfixe kaizen:

## Format learned-errors.md
| Date | Pattern | Ce qui était faux | Ce qui était attendu | Statut |
| 2026-04-15 | async void handler | async void OnMessage | async Task OnMessage | résolu |

6. Ce qu'on commite, ce qu'on ne commite pas

La règle est simple, mais souvent mal appliquée :

Ajoutez ceci à votre .gitignore :

# Claude Code — ne pas commiter
.claude/settings.local.json
.claude/**/*.env
.claude/projects/

Et vérifiez que votre .claude/settings.json (commité) ne contient aucune valeur sensible — uniquement des hooks et des permissions shell génériques.

7. Checklist d'onboarding — 15 minutes chrono

Un nouveau développeur rejoint l'équipe. Voici la séquence exacte :

Ce qui prend plus de temps : comprendre pourquoi ces règles existent. C'est pour ça que la kill-list documente chaque entrée avec un contexte — pas juste "interdit", mais "interdit parce que ça a causé X en production le Y".

Ce qui fait la différence sur le long terme

Après six mois d'utilisation équipe, ce qui capitalise vraiment ce n'est pas la configuration initiale — c'est la discipline de capture. Chaque fois qu'un agent fait une erreur, elle va dans learned-errors.md. Chaque fois qu'un pattern remonte trois fois, il monte dans la kill-list. Chaque fois qu'un skill produit un résultat médiocre, on l'améliore et on commite.

Les équipes qui abandonnent les agents IA après quelques semaines ont toutes le même problème : elles traitent chaque session comme isolée. Aucune capitalisation, aucune mémoire collective, aucun retour d'expérience codifié. L'agent fait les mêmes erreurs indéfiniment parce qu'il n'a aucun contexte sur ce qui a échoué avant.

Le CLAUDE.md commité, les skills versionnés et la kill-list maintenue sont exactement ce qui transforme un outil individuel en infrastructure d'équipe. C'est ce qui donne à l'agent le contexte dont il a besoin pour être utile — et les contraintes dont votre équipe a besoin pour ne pas subir ses erreurs.

"Un agent sans contexte est un développeur junior sans brief. Un agent avec un CLAUDE.md bien écrit et une kill-list à jour est un collaborateur qui connaît vos standards mieux que lui-même."

Vous voulez mettre en place ce setup dans votre équipe .NET ?

Je peux auditer votre configuration actuelle, écrire votre CLAUDE.md projet,
configurer les hooks et la librairie de skills pour votre contexte.

✉ Me contacter Voir mes services →