« Self-hosted Claude Code » revient dans les demandes d'appel d'offres depuis quelques mois, souvent mal formulé. On y lit tantôt « on veut le modèle sur nos GPU », tantôt « on veut que rien ne sorte du VPC », tantôt « on veut juste facturer sur AWS ». Ce sont trois problèmes différents avec trois réponses différentes. Cet article sépare ce qui est vraiment self-hostable (le runner, les secrets, le contexte, la CI qui appelle Claude Code) de ce qui ne l'est pas (le poids du modèle), et détaille trois patterns d'architecture qu'on retrouve en production dans des équipes soumises à RGPD ou audit ISO. Si vous cherchez d'abord à maîtriser Claude au quotidien avant d'attaquer l'infra, commencez plutôt par là. Ici, on suppose que vous savez ce qu'est un runner CI, une variable d'environnement, et un endpoint IAM.
Ce qu'on entend vraiment par « self-hosted » avec Claude Code
Claude Code est un binaire CLI. Il lit vos fichiers, exécute des commandes shell, appelle des serveurs MCP, et pour chaque tour de raisonnement, envoie une requête HTTPS à un endpoint qui héberge le modèle. Ce dernier point est celui qui coince : le modèle Claude n'existe pas en version téléchargeable. Il n'y a pas de docker pull claude-sonnet-5. Le modèle lui-même reste hébergé côté fournisseur, via l'un des points d'accès supportés officiellement : api.anthropic.com (Anthropic direct), Amazon Bedrock, Google Vertex AI, ou Microsoft Foundry. Aucun de ces points d'accès ne fait tourner le modèle sur votre matériel : ils l'hébergent tous côté cloud, chacun avec ses propres règles de région et de facturation.
Ce qui reste chez vous, en revanche, est substantiel : le repo git, les credentials qui donnent accès aux bases prod, l'historique des sessions Claude Code (fichiers dans ~/.claude/), les serveurs MCP que vous exécutez, les logs, la configuration des hooks PreToolUse. Quand un architecte dit « je veux self-hoster Claude Code », il veut presque toujours dire l'une de ces trois choses : garder les credentials hors des postes dev, choisir la région où les prompts sont traités, ou centraliser l'audit des appels LLM. Aucune de ces trois demandes n'exige d'héberger le modèle lui-même.
À noter, depuis la version 2.1.224 de Claude Code (7 août 2026), la commande claude self-hosted-runner existe officiellement pour les plans Team et Enterprise. Elle permet de faire tourner les sessions Claude Code web, mobile et desktop sur vos propres machines ou conteneurs, derrière votre pare-feu. Le travail s'exécute sur votre matériel ; la requête vers le modèle, elle, sort toujours vers l'un des points d'accès listés plus haut (Anthropic, Bedrock, Vertex ou Microsoft Foundry).
Pourquoi une équipe voudrait exécuter Claude Code sur son infra
Les cas concrets qu'on voit passer sont assez ternes, ce qui est plutôt bon signe : ce sont des contraintes réglementaires ou opérationnelles, pas des postures.
Un premier cas typique : une équipe santé qui vise l'hébergement HDS. Le DPO refuse que le code source, qui contient des schémas de base contenant des identifiants patient hashés, transite par une région non certifiée. Bedrock région Paris (eu-west-3) devient une réponse acceptable, à condition de vérifier que le modèle voulu y est déployé.
Deuxième cas : une banque en ligne dont les credentials AWS de prod ne peuvent pas se trouver sur un poste dev. Le runner Claude Code doit vivre dans un VPC séparé, avec accès aux secrets via IAM role, et ne remonter aux développeurs que les diffs de PR. Le poste local voit du code générique ; les vraies clés ne bougent pas.
Troisième cas, plus banal : une DSI qui veut auditer chaque appel LLM pour un audit ISO 27001. Le point de contrôle n'est pas le modèle, c'est la journalisation. Un proxy interne devant Claude Code règle 90 % du sujet.
Le contexte réglementaire européen renforce ces demandes. Depuis le 2 août 2026, les pouvoirs de sanction de la Commission européenne sur les fournisseurs de modèles d'IA à usage général sont actifs, et les obligations sur les systèmes « à haut risque » concernent aussi les entreprises qui déploient ces outils, pas seulement les fournisseurs. Voir les obligations concrètes de l'AI Act pour les entreprises pour le détail.
Pattern 1 : Claude Code dans un GitHub Actions self-hosted runner
C'est le pattern le plus courant. Vous installez le CLI Claude Code sur un runner GitHub Actions auto-hébergé, hébergé dans une VM de votre VPC AWS ou GCP. Le job checkout le repo, lance claude en mode headless, et pousse une PR.
# .github/workflows/claude-review.yml
name: Claude review
on:
pull_request:
types: [opened, synchronize]
jobs:
review:
runs-on: [self-hosted, claude-runner]
steps:
- uses: actions/checkout@v4
- name: Run Claude Code headless
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
run: |
claude -p "Review this PR, focus on security and error handling" \
--output-format json \
--max-turns 8 > review.json
- name: Post review
run: gh pr comment ${{ github.event.number }} --body-file review.jsonTrois pièges à connaître avant de mettre ça en prod.
D'abord, l'isolation des secrets. Un runner GitHub Actions partagé entre plusieurs repos privés peut voir passer les secrets de tous ces repos si un job malveillant s'exécute dessus. Un runner par équipe sensible, ou mieux, un runner par repo critique. Le coût de la VM supplémentaire est dérisoire face au risque.
Ensuite, le cache. Claude Code garde du contexte entre les runs si vous ne nettoyez pas ~/.claude/ entre deux jobs. Sur un runner partagé, ça peut mélanger le contexte de deux PR différentes. Ajoutez un rm -rf ~/.claude/projects/* en début de job, ou lancez chaque run dans un conteneur éphémère.
Enfin, les correctifs de sécurité récents. Début août 2026, Claude Code 2.1.222 a corrigé deux failles d'isolation touchant les worktrees git et les hooks PreToolUse en auto-allow. Si votre runner exécute plusieurs sessions en parallèle ou utilise des hooks personnalisés, la version installée compte : voir les correctifs d'isolation worktree d'août 2026. Épinglez une version dans votre image runner et suivez les changelogs.
Pattern 2 : Claude Code branché sur AWS Bedrock ou Google Vertex AI
Deux variables d'environnement suffisent à basculer Claude Code sur un provider cloud :
# AWS Bedrock, région Paris
export CLAUDE_CODE_USE_BEDROCK=1
export AWS_REGION=eu-west-3
# Les credentials AWS standards s'appliquent (rôle IAM, profile, etc.)
# Google Vertex AI, région Belgique
export CLAUDE_CODE_USE_VERTEX=1
export CLOUD_ML_REGION=europe-west1
export ANTHROPIC_VERTEX_PROJECT_ID=votre-projet-gcpL'avantage est direct : les prompts et les réponses transitent via votre compte cloud, dans la région que vous choisissez. La facturation atterrit sur votre compte AWS ou GCP, ce qui simplifie la vie de la finance et évite les cartes personnelles.
La contrainte importante, souvent oubliée : tous les modèles Claude ne sont pas disponibles dans toutes les régions. Au moment où vous lisez ces lignes, la matrice de disponibilité change régulièrement, notamment pour les modèles récents. Claude Opus 5, sorti le 24 juillet 2026, était disponible dès le lancement sur Bedrock et Vertex, mais Fable 5 ou Sonnet 5 peuvent ne pas être présents dans eu-west-3 selon le calendrier de déploiement d'AWS. Vérifiez la matrice AWS/GCP avant de promettre à un client que « tout reste en Europe ». Si le modèle voulu n'est pas en région Paris, deux options : accepter une région européenne alternative (Francfort, Irlande, Stockholm), ou attendre son déploiement.
Pour choisir le bon modèle selon vos contraintes de coût et de latence, la comparaison Opus 5 vs Sonnet 5 donne les repères. Et pour comprendre pourquoi Sonnet 5 passe à 3 $/15 $ le million de tokens à partir du 1er septembre 2026 (avec un tokenizer qui produit environ 30 % de tokens en plus), voir l'impact combiné de la hausse tarifaire.
Pattern 3 : Proxy LLM interne devant Claude Code
Dès que plusieurs équipes utilisent Claude Code, un point de contrôle unique devient utile. LiteLLM, Helicone auto-hébergé, ou un gateway maison en Go/Node se placent entre le CLI et l'API. Le proxy gère l'auth (une seule clé Anthropic centrale, jamais distribuée aux devs), log les prompts, applique éventuellement un filtre PII, et route vers Bedrock/Vertex/Anthropic selon le contexte.
Configuration côté Claude Code :
export ANTHROPIC_BASE_URL=https://llm-gateway.interne.corp
export ANTHROPIC_AUTH_TOKEN=token-court-terme-emis-par-le-gatewayCe qu'un proxy vous donne concrètement : une facture consolidée pour la direction financière, un audit centralisé pour la sécurité (chaque prompt et chaque réponse archivés avec l'identité de l'utilisateur), des quotas par équipe, et la possibilité de basculer entre providers sans toucher aux postes dev. Le jour où Anthropic ajoute un modèle plus économique ou où Bedrock ouvre une nouvelle région, vous changez le routage côté proxy et personne ne recompile rien.
Le proxy devient aussi le bon endroit pour appliquer des Inference Hooks côté Claude Enterprise si vous êtes sur ce plan, ou pour brancher un DLP maison qui refuse les prompts contenant certains patterns (numéros de carte, IBAN, identifiants patient).
Ce que vous ne pourrez pas self-host, et comment vivre avec
Il faut être clair sur le plafond de verre. Le modèle Claude ne s'installe pas on-prem. Il n'y a pas de version quantifiée, pas de checkpoint HuggingFace, pas d'endpoint air-gapped. Si votre contrainte est « aucun appel sortant, même chiffré, même vers un cloud tiers certifié », Claude Code n'est pas la bonne réponse. Il faut regarder des modèles ouverts (Llama, Mistral, Qwen) déployés sur vos propres GPU, avec les compromis de qualité que ça implique aujourd'hui sur les tâches de code agentique longues.
Pour à peu près tous les autres cas, et selon notre estimation la grande majorité des équipes qui prononcent le mot « souveraineté » sans l'avoir vraiment cadré, la combinaison Bedrock région Paris + runner dans votre VPC + secrets dans AWS Secrets Manager couvre les exigences RGPD et la plupart des audits ISO 27001 ou SOC 2. Le point que le DPO doit valider n'est pas « où tourne le CLI », c'est « où le prompt est traité et où les logs de prompts sont stockés ». Bedrock répond à ces deux questions avec un contrat AWS classique.
Checklist de mise en production pour une équipe
La liste opérationnelle, ordre de priorité descendant :
- Région du modèle validée par le DPO, écrite noir sur blanc dans le registre des traitements.
- Clé API stockée dans Vault, AWS Secrets Manager ou GCP Secret Manager, jamais dans un
.envcommité, jamais dans un secret GitHub partagé entre repos non liés. - Runner GitHub Actions isolé par projet sensible, dans un VPC dédié, sans accès sortant sauf vers l'endpoint modèle et le registre git.
- Logs des sessions Claude Code (prompts, réponses, appels d'outils) archivés au minimum 12 mois, avec chiffrement au repos, dans un bucket avec versioning et suppression protégée.
- Rotation des clés API tous les 90 jours, via le gateway si vous en avez un.
- Revue des serveurs MCP autorisés : un MCP mal configuré peut exfiltrer autant qu'une prompt injection réussie. La liste blanche des MCP validés doit être versionnée et revue trimestriellement.
- Mode auto de Claude Code : depuis le 14 août 2026, c'est le défaut sur Pro/Max/Team pour les nouvelles sessions. Sur un runner Enterprise, décidez explicitement si vous l'activez côté CI. Les règles
permissions.denyetpermissions.askgardent priorité sur le classifieur, utilisez-les pour bloquer les commandes sensibles quelle que soit la décision automatique. - Version de Claude Code épinglée dans l'image du runner, avec un processus de mise à jour trimestrielle qui inclut la revue des changelogs de sécurité.
Passer à la pratique
Self-hoster proprement Claude Code n'est pas un projet d'infra colossal : c'est un runner CI dans votre VPC, une variable CLAUDE_CODE_USE_BEDROCK=1, éventuellement un proxy si vous êtes plusieurs équipes. Ce qui prend du temps, c'est la revue avec le DPO, la matrice de disponibilité des modèles, et la discipline des secrets. Si vous voulez construire l'application qui tournera derrière ce runner, notre programme Construire votre produit IA en 5 semaines vous emmène du brief au déploiement Vercel + Supabase avec Claude Code comme moteur, sur une infra que vous contrôlez de bout en bout.