Claude Code auto-hébergé : ce qui reste dans l’entreprise et ce qui ne le fait pas
Il est rare qu’un fournisseur publie une fonctionnalité et recommande dans le même texte à la plupart des clients de la laisser de côté. Anthropic l’a fait le 6 août 2026, ouvrant la version bêta publique des environnements auto-hébergé pour Claude Code avec un postulat qui vaut plus que le titre : pour la majorité des entreprises l’offre managée reste recommandée, et celui qui prend l’autre voie doit prendre en compte le personnel technique dédié à sa construction et à sa maintenance. Un mois plus tard, l’annonce circule dans les audiences d’adoption d’automne comme si c’était la réponse à la question de la confidentialité du code source, et la documentation technique dit quelque chose de différent.
Dans les infrastructures, une distinction a toujours été faite entre le plan sur lequel s’effectue l’exécution et celui sur lequel voyage le contenu, et c’est la même distinction qui s’impose ici : l’auto-hébergement amène le premier à l’intérieur du réseau d’entreprise et laisse le second exactement là où il était. Cela ressemble à l’ère du cloud privé d’il y a dix ans, lorsque le mot d’ordre était le contrôle et que la bonne question venait après la signature.
Le code reste à la maison, pas la conversation
Une session cloud Claude Code est toute session qui ne s’exécute pas sur l’ordinateur portable du développeur : elle démarre depuis claude.ai, l’application mobile ou de bureau, le terminal ou une routine planifiée, et s’exécute par défaut sur l’infrastructure d’Anthropic. Dans un environnement auto-hébergéd cette même session s’exécute sur les machines de l’organisation, à l’intérieur du périmètre du réseau, aux côtés des services internes.
Ce qui reste réellement là est indiqué dans la documentation : l’extraction du référentiel, les artefacts de construction, les secrets et chaque fichier créé ou modifié par la session restent sur les machines fournies par l’entreprise. Immédiatement après vient la partie que peu ont rapportée, et qui bouleverse la lecture la plus répandue : la conversation, c’est-à-dire les invites, les réponses et les résultats des outils, y compris le code que le modèle lit pendant le travail, est envoyée à api.anthropic.com pour inférence, et le transcription de la session est conservée pour pouvoir être reprise depuis une autre surface.
Le plan de contrôle, avec l’orchestration de session, les files d’attente et l’interface claude.ai, continue de fonctionner sur l’infrastructure d’Anthropic. Ce qui bouge, c’est l’exécution. Un exécuteur interne retire le travail de la file d’attente, clone le référentiel, lance un processus enfant de Claude Code et toutes les connexions sont hors du réseau d’entreprise vers Anthropic, qui n’ouvre jamais de canal vers l’intérieur.
Excellente architecture du point de vue du pare-feu, peu pertinente par rapport à la question que se posent de nombreux responsables techniques, à savoir où finissent les lignes de code propriétaire pendant que le modèle y réfléchit.
L’inférence ne peut plus passer par Bedrock
Trois exclusions indiquées dans la documentation vous indiquent de qui cette fonctionnalité a réellement besoin, et la première est quelque peu paradoxale. Les environnements auto-hébergés ne sont pas disponibles pour les organisations qui ont activé Zero Data Retention, c’est-à-dire celles qui ont négocié le régime de rétention le plus strict. Ceux dont les exigences en matière de données sont les plus strictes sont exclus de la fonctionnalité présentée en réponse aux exigences en matière de données.
La deuxième exclusion pèse spécifiquement sur les entreprises européennes. Dans les sessions auto-hébergées, l’inférence utilise l’API Anthropic, le plan de contrôle fournit à chaque session le point de terminaison et la session s’authentifie avec un jeton OAuth généré par Anthropic et limité à une seule session, de sorte que l’inférence ne peut pas être acheminée via Amazon Bedrock, Google Cloud Agentic Platform, Microsoft Foundry ou une passerelle LLM d’entreprise. Traduit pour un DSI italien : dans l’environnement géré par Anthropic, une entreprise peut faire de l’inférence sur son locataire Bedrock dans une région européenne, avec le contrat cloud qu’elle a déjà signé et les contrôles qu’elle a déjà passés ; en apportant l’exécution en interne, cette possibilité disparaît et le trafic d’inférence redevient une connexion directe avec Anthropic. Ceux qui s’auto-hébergent pour des raisons de conformité risquent de perdre l’effet de levier de conformité qu’ils utilisaient déjà en cours de route.
Le troisième concerne le périmètre fonctionnel, et est le plus prosaïque. Les sessions reprennent les dépôts de GitHub, les sessions Claude Security et Code Review ne sont pas encore routées vers les environnements auto-hébergés, et Claude Tag y tourne mais sans pouvoir utiliser les bundles d’accès. Ceux qui ont déjà construit des flux sur ces surfaces découvrent que la transition n’est pas complète.
Un coureur ne s’attache qu’à un seul propriétaire
L’architecture comporte trois éléments et une analogie explicite : l’environnement est une destination nommée, créée par les paramètres d’administration de claude.ai, qui regroupe les coureurs ; le coureur est un processus de longue durée qui s’exécute sur les machines de l’entreprise, et l’idée, écrit Anthropic, est la même que celle d’un coureur d’intégration continue auto-hébergé ; la session est la tâche unique initiée par un développeur. Ceux qui disposent déjà d’une flotte de runners GitLab ou GitHub savent donc avec une bonne approximation à quoi ils sont confrontés, y compris l’image à construire et à entretenir.
Il existe cependant une contrainte d’isolation qui modifie le dimensionnement, et qui reste en toile de fond dans l’annonce commerciale. Un runner ne sert qu’un seul propriétaire à la fois : lors de la première session, il se connecte au propriétaire de cette session et à partir de ce moment, il effectue uniquement son propre travail, dans la limite de la capacité configurée. Cela permet d’éviter que du code extrait de deux développeurs différents ne se retrouve sur le même disque, et c’est une garantie raisonnable. La conséquence opérationnelle est mise noir sur blanc dans la documentation : la taille minimale de la flotte est le nombre de propriétaires censés être actifs en même temps, en comptant les utilisateurs et les agents de Claude Tag. La flotte n’évolue pas avec la charge de travail, mais avec le nombre de personnes qui travaillent en même temps, ce qui constitue une fonction de coût beaucoup moins favorable.
A partir de là, les choix sont les classiques de l’infrastructure. Un certain nombre de runners restent activés, ou un orchestrateur d’autoscaling est mis en place, un deuxième processus à héberger, qui active les runners au fur et à mesure que les sessions s’alignent. Le cycle de vie est plein de détails qui deviennent des accidents s’ils sont ignorés : le runner interroge la file d’attente, donnant dix secondes à chaque requête et cette interrogation agit également comme un battement de cœur, si elle s’arrête pendant environ soixante secondes, le serveur remet la session dans la file d’attente d’un autre runner, et un proxy qui intercepte la requête en répondant avec sa propre page produit une réponse que le runner ne peut pas interpréter.
Ceux qui pensent pouvoir économiser de l’argent en plaçant des coureurs sur des instances ponctuelles doivent passer le paramètre qui fixe l’heure de ramassage quelques minutes avant la révocation, sinon la machine qui disparaît sans signal ne se distingue pas d’un crash et le quart de travail en cours est perdu.
Le coût de l’auto-hébergement n’est pas dans la liste de prix
Rien ne change dans la consommation : séances dans un environnement auto-hébergé consommez l’utilisation de Claude Code de votre organisation comme celle des environnements gérés. Pas de remise pour le calcul mis à disposition, pas de réduction sur le prix des tokens. Les machines, l’image du coureur, l’orchestrateur, la gestion des informations d’identification git, lesortie et les personnes qui font que tout continue, et Anthropic dit explicitement que nous avons besoin d’une plate-forme ou d’une équipe d’expérience de développement pour prendre en charge la responsabilité opérationnelle.
Le calcul n’a de sens que si d’un autre côté il y a une valeur que l’environnement géré ne peut pas produire, exactement comme cela s’est produit avec le cloud privé, où les entreprises avec une réelle contrainte de réseau ou de latence sont celles qui ont gagné et non celles qui ont acheté de l’assurance. Les organisations du programme Preview y sont arrivées pour des raisons mesurables. Les sessions s’exécutent au sein du réseau et atteignent les services internes, les bases de données et les registres sans avoir à les exposer à Internet ; l’image du coureur est livrée avec des compilateurs, un SDK et une CLI interne déjà installés, de sorte que chaque session démarre prête à être compilée ; les contrôles de sécurité et les politiques réseau restent ceux de l’entreprise.
George Jacob, responsable principal de l’ingénierie chez Faire, affirme que la configuration permet à Claude de générer des demandes d’extraction, d’aider à résoudre les problèmes d’intégration continue et de réagir aux événements de flux de travail des développeurs, le calcul suivant la demande.
Ce sont tous des avantages d’accès et d’environnement, aucun d’eux ne concerne la confidentialité de ce que lit le modèle, et sur les tables où sont discutées ces adoptions, la confusion entre les deux familles d’avantages est ce que je vois le plus souvent, presque toujours parce que la résolution mentionne le mot conformité sans préciser quelle exigence.
Lorsqu’une base de données ne peut pas quitter le réseau
Le critère de choix peut se réduire à une seule question, qu’il convient de poser avant d’ouvrir un ticket à l’équipe de la plateforme : la valeur attendue vient-elle du fait que la session atteint quelque chose à l’intérieur du réseau, ou du fait que quelque chose ne doit pas en sortir ? Dans le premier cas le auto-hébergement est la bonne réponse et le coût est justifié, car un agent qui doit interroger la base de données de mise en scèneextraire des packages du registre interne et les exécuter sur un service non exposé n’a pas d’alternative propre. Dans le second cas, l’infrastructure et la protection sont payées pour un résultat qui n’est pas obtenu, étant donné que les invites, les réponses et les résultats des outils continuent de voyager vers l’inférence.
Restent deux vérifications préalables qui sauvent les rencontres. La première : si une équipe travaille uniquement depuis un terminal et un environnement de développement intégré, il n’y a rien à configurer, car ces sessions s’exécutent déjà sur la machine du développeur. La seconde concerne ceux qui souhaitent simplement piloter une session démarrée sur leur ordinateur depuis leur téléphone, ce qui est une fonction différente, également disponible sur les forfaits individuels, et ne nécessite aucune flotte.
Par rapport au cloud privé, auquel cette histoire ressemble beaucoup, il existe un avantage initial. Les environnements auto-hébergés de Claude Code ont le rare mérite de déclarer par écrit leurs limites, de l’exclusion du Zero Data Retention à l’inférence qui ne passe pas par les passerelles, et la documentation technique d’un fournisseur, lue avant la décision plutôt qu’après, reste l’outil d’approvisionnement le plus sous-estimé dont nous disposons.
