Claude Code en équipe, en CI et dans le cloud

Tout ce qui précède décrivait un usage individuel. Ce chapitre traite du passage à l’équipe : ce qui se partage, ce qui reste personnel, et ce qu’on peut faire tourner sans personne devant l’écran.

Ce qui se partage, ce qui ne se partage pas#

La règle est simple et elle évite les frictions.

Le .gitignore qui va avec :

.claude/settings.local.json
CLAUDE.local.md

Déployer progressivement#

L’erreur classique est de préparer une configuration complète et de la livrer d’un coup. Personne ne l’adopte, parce que personne ne comprend d’où viennent les comportements.

L’ordre qui fonctionne, à raison d’une étape par semaine environ :

1. Le CLAUDE.md. /init, puis une demi-heure de rédaction sur ce que Claude ne pouvait pas deviner. Rien d’autre.

2. La commande de vérification unique. npm run verify ou son équivalent, inscrite dans le CLAUDE.md. C’est ce qui referme la boucle.

3. Les garde-fous. Trois règles deny sur ce qui ne doit jamais arriver. Pas quinze.

4. Une commande partagée. Celle que tout le monde retape.

5. Le reste. Sous-agents, hooks, plugin — quand le besoin est exprimé, pas avant.

Le mode non interactif#

claude -p exécute une demande et écrit le résultat sur la sortie standard. C’est ce qui rend Claude Code scriptable.

# Analyse simple
claude -p "Liste les endpoints HTTP exposés par ce projet, en CSV : méthode;chemin;fichier"

# Sortie structurée, exploitable par un script
claude -p "..." --output-format json | jq -r '.result'

# Permissions verrouillées pour l'exécution automatique
claude -p "..." \
  --allowedTools "Read,Grep,Glob" \
  --output-format json

Trois règles pour un usage sain.

Restreindre les outils explicitement. En non interactif, personne ne peut refuser une action. --allowedTools est votre seul garde-fou immédiat, en plus des fichiers de réglages.

Préférer la lecture. Un script qui analyse et rapporte est utile immédiatement et sans risque. Un script qui modifie demande une confiance qui se construit.

Traiter la sortie comme une donnée à valider. Le format JSON facilite l’analyse ; il ne garantit pas que le contenu soit juste. Le chapitre 4 s’applique intégralement.

En intégration continue#

Le bon premier usage : une analyse qui commente, sans rien modifier.

name: Revue assistée

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  revue:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Installer Claude Code
        run: npm install -g @anthropic-ai/claude-code

      - name: Analyser le diff
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: |
          git diff origin/${{ github.base_ref }}...HEAD > /tmp/diff.patch
          claude -p "$(cat <<'EOF'
          Voici le diff d'une pull request. Analyse-le et produis un
          commentaire de revue en Markdown.

          Signale tout ce que tu trouves, y compris ce dont tu n'es pas
          sûr. Pour chaque point : fichier, ligne, ce qui cloche, un
          scénario concret où ça casse, et ton niveau de confiance.

          Termine par « Rien de bloquant » si c'est le cas. Ne remplis
          pas le commentaire pour donner l'impression d'avoir travaillé.
          EOF
          )" \
            --allowedTools "Read,Grep,Glob" \
            --output-format text > /tmp/revue.md

      - name: Publier le commentaire
        env:
          GH_TOKEN: ${{ github.token }}
        run: gh pr comment ${{ github.event.number }} --body-file /tmp/revue.md

Quatre points de sécurité dans ce fichier, et ils sont tous délibérés.

Les permissions du job sont minimales : lecture du dépôt, écriture des commentaires. Pas d’écriture de contenu.

Les outils sont restreints à la lecture.

Aucun secret de production n’est exposé : seule la clé d’API est présente.

La dernière consigne de l’invite évite le commentaire de complaisance qui rendrait la revue automatique inutile en trois semaines.

Les agents en arrière-plan et le cloud#

Au-delà des exécutions ponctuelles, plusieurs sessions peuvent tourner en parallèle et être suivies depuis un seul endroit, y compris sur une infrastructure distante plutôt que sur votre machine.

Trois conséquences pratiques.

Votre machine n’est plus le goulot. Une migration longue tourne ailleurs pendant que vous travaillez.

L’isolation devient naturelle. Une session distante n’a pas accès à vos clés SSH, à vos autres dépôts ni à votre disque.

La supervision devient un vrai sujet. Cinq sessions autonomes demandent une méthode : le chapitre 21 l’a donnée — journal des décisions, points d’arrêt, critère de réussite annoncé. Elle s’applique identiquement ici.

Gouvernance#

Pour une organisation qui déploie à grande échelle, quelques mécanismes existent au-delà des fichiers de projet.

Les réglages gérés. Déployés par l’informatique, non contournables par l’utilisateur. C’est là que vivent les interdictions non négociables : chemins de secrets, commandes réseau, fournisseur d’API imposé.

Un CLAUDE.md d’organisation. Déployé au niveau machine, chargé avant tous les autres. Pour les règles de conduite : rappels sur les données, standards de qualité.

La distinction à garder en tête. Les réglages gérés appliquent ; le CLAUDE.md d’organisation oriente. Ce qui doit être empêché va dans les réglages.

La télémétrie et les journaux. Configurables pour suivre l’usage et alimenter la revue de sécurité.

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Edit(./migrations/**)",
      "Bash(psql *)"
    ],
    "ask": ["Bash(git push *)"]
  }
}

Ce qu’il faut retenir#