N'adoptez pas à l'aveugle — Claude Code n'est pas un autocomplete, c'est un transfert total des permissions code

L'erreur la plus courante : traiter Claude Code comme « un autocomplete IA de plus » — installer le CLI, lier une clé API, livrer une fonction. La même illusion qu'un self-hosted runner « macos-latest sans file » : on voit la vitesse, pas les frontières.

Claude Code est un Agent terminal : il ne suggère pas seulement du code — il peut exécuter shell, éditer de nombreux fichiers, lire les variables d'environnement, appeler des outils MCP et boucler les tests jusqu'au vert. Lui faire confiance par défaut sur le repo principal, ce n'est pas ajouter un plugin ; c'est confier tout un ensemble de permissions code et d'exécution.

Ceci est Cloud Mac AI Stack · entrée décision L3 (L3-Q01) : après fondation L0 et couche Fact L1 (lire L1 ①②③ d'abord), nous répondons à quand un Agent doit rejoindre officiellement le workflow dev. Table série L3 à § série L3 ; vertical L0 et horizontal L4–L5 à § liens Stack. Le benchmark workstation (L3 ③) et vs Cursor (L3 ②) couvrent autre chose — cet article traite uniquement décision et permissions.

Ce que vous confiez vraiment : une carte des permissions

La plupart des équipes obsèdent sur « à quel point le modèle est intelligent » et ignorent ce que l'Agent peut faire sur disque et en processus. Utilisez le tableau ci-dessous à l'onboarding — six types de permissions ; vérifier chacun avant go-live.

La question n'est jamais « faut-il utiliser l'IA pour coder » mais : êtes-vous prêt à déléguer par défaut les six lignes ci-dessus à un processus semi-autonome ? Si vous hésitez, évitez « tout le monde installe Claude Code par défaut » et utilisez l'adoption par phases ci-dessous.

Ce n'est ni Copilot ni un plugin IDE

Copilote (Copilot / Cursor Tab) : vous pilotez dans l'éditeur ; l'IA complète ou édite le fichier courant — petits diffs, retour rapide. Chauffeur (Claude Code Agent) : vous énoncez un objectif ; l'Agent planifie, ouvre shell, édite de nombreux fichiers, retry en cas d'échec — vous reviewez les résultats, pas le volant.

Ce n'est pas lequel est « meilleur » (voir Claude Code vs Cursor) mais le type de tâche : complétion quotidienne reste dans l'IDE ; migrations cross-modules, grandes boucles test–fix et édition CI GitHub Actions déléguée vont à l'Agent. Agent comme Copilot est souvent lent et difficile à auditer ; Copilot comme Agent ne résout pas les délégations « 47 files changed ».

Déploiement aveugle vs onboarding formel · comparatif

Le « déploiement aveugle » ressemble souvent à : le lead adore, tout le monde a Max, le repo principal fait tourner le CLI en confiance par défaut. L'onboarding formel inscrit l'Agent dans la politique d'ingénierie : frontières, audit et split CI.

Trois portes : obligatoires avant onboarding formel

Traitez les trois portes ci-dessous comme la barre minimale pour onboarding formel — pas la perfection, mais éviter « transfert total des permissions sans audit ».

Porte ① · Frontière disque et CI (L1)

Agent et GitHub Runner partagent-ils des répertoires globaux non nettoyables ? Signing prod, .env et caches larges dans le même home que les sessions Agent ? Si L1 ③ one job, one workspace n'est pas fait, corriger la couche Fact avant d'ouvrir Diff (série L1 à série L1).

Porte ② · Frontière outils et secrets (L4)

MCP est-il « tout connecter » ? Le PAT Agent chevauche-t-il CI et GitHub personnel ? L'onboarding formel exige tokens séparés, scopes minimaux, rotation, plus une checklist L4 setup MCP et moindre privilège lisible par l'équipe.

Porte ③ · Frontière humains et processus (équipe)

Qui peut merger directement la sortie Agent ? Un gros repo a-t-il L4 CodeGraph ou équivalent pour réduire le risque « fichier manqué » ? Si la réponse est « le plus rapide merge », l'Agent amplifie seulement la dette process existante.

Quand onboarder formellement · quand attendre

Ce que L3 possède dans le Stack : Diff, pas Fact

Slogan série (L1–L3) : Claude Code produit Diff ; GitHub Runner produit Fact. Cette entrée L3 demande : quand confiez-vous la production Diff à un Agent ? Fact (CI vert, signing ok) reste sur Runners isolés — « tests passés » par l'Agent n'est pas une release.

L2 Inference : Ollama pour brouillons et offline ; L3 Claude Code pour exécution déléguée et Diff — peuvent coexister sur un hôte avec permissions séparées. L4 Context : hub MCP et moindre privilège gouvernent les outils. L5 Workflow : OpenHands plutôt orchestration ; Claude Code plutôt profondeur terminal — portes d'onboarding s'appliquent aux deux.

Adoption par phases (~30 % du workflow)

Une fois la décision claire, atterrir en trois phases — pas jour un « tout le monde sur Max + repo prod grand ouvert » :

1. Phase A · sandbox lecture seule (1–3 jours) : fork ou copie repo, pas de push ; observer comment l'Agent décompose les tâches et quels shell il lance. Objectif : sentir la carte des permissions.
2. Phase B · écriture supervisée (1–2 semaines) : clone lecture seule du repo principal dans un répertoire séparé, ou travail branche uniquement ; chaque merge exige review humaine ; MCP outils essentiels seulement.
3. Phase C · couche Diff formelle : split fixe avec L1 Runner ; CLAUDE.md, rotation tokens, isolation workspace dans runbook ; optionnel chaîne trigger L1 ④ pipeline OpenClaw.

# Portes onboarding Agent (phase B)
1. Racine repo doit avoir CLAUDE.md (chemins autorisés/interdits, commandes test)
2. Agent utilise PAT dédié, scope ≤ tâche courante ; jamais identique aux secrets CI
3. Délégation unique >15 changements fichiers → second reviewer requis
4. Avant merge, même commande test doit passer localement ou sur Runner
5. Utilisateur macOS ou nœud Cloud Mac différent du Runner (recommandé)

Choix hardware (acheter Mac mini vs louer Cloud Mac) hors scope — c'est l'histoire du benchmark workstation. Cette entrée décision dit seulement : une fois permissions et processus au niveau, alors parler usage quotidien.

Série L3 · répartition des articles

Cet article ouvre la ligne décision L3 (couche Diff) : répondre s'il faut confier permissions à un Agent, puis lire comparatif outils et pratique. Lire le tableau dans l'ordre ; vertical retour L0–L2, horizontal L4–L5 à § liens Stack.

Liens couches Stack · entrée verticale

Liens verticaux Stack (une entrée par couche ; lire avec série L1) :

• L0 · fondation : Mac mini vs Mac cloud · workstation IA cloud
• L1 · Fact : moteur exécution Runner · file CI · isolation workspace · pipeline OpenClaw
• L2 · Inference : inférence privée Ollama · planification parallèle Runner
• L3 · Diff : ① cet article · décision onboarding · vs Cursor · benchmark workstation
• L4 · Context : hub MCP triple-connexion · exposition moindre privilège · setup MCP · CodeGraph et edits manqués
• L5 · Workflow : plateforme Agent OpenHands

Après cette entrée L3, si les portes passent, la suite est souvent L3 ③ benchmark workstation (hardware et facturation) ; si vous choisissez encore l'IDE, lire d'abord L3 ② vs Cursor. Carte bout-en-bout L6 prévue.

FAQ

En quoi Claude Code diffère de l'autocomplete Cursor ?
Cursor est un copilote dans l'éditeur — les changements sont souvent visibles ligne par ligne. Claude Code est un Agent terminal qui peut exécuter shell, éditer de nombreux fichiers et boucler tests — il confie l'exécution à un processus semi-autonome.

Les devs solo ont-ils besoin des trois portes ?
Vous pouvez simplifier, mais tokens séparés, répertoires séparés, grands diffs à reviewer doivent rester. Repo privé ≠ risque zéro — suppressions et fuites de secrets arrivent quand même.

L'onboarding formel signifie-t-il remplacer l'IDE ?
Non. Pattern courant : IDE pour features, Agent pour délégations. Cet article répond quand écrire l'Agent dans le processus, pas quand abandonner VS Code.

Lien avec la sécurité Runner L1 ?
L1 ③ isolation workspace gouverne les frontières disque CI ; cet article (L3 ①) gouverne qui peut lancer Agent sur repos prod. L1 d'abord, puis L3 grand ouvert. Entrée Stack à § liens Stack.

Cloud Mac ou machine locale pour essai ?
Phases A/B sur L0 Cloud Mac isolé sont souvent moins chères — reset d'un env chaotique ; acheter hardware dédié après usage quotidien confirmé. Voir L3 ③ benchmark workstation.