L’essentiel
- Anthropic ouvre en bêta publique les environnements auto-hébergés : une session Claude Code s’exécute sur l’infrastructure de l’entreprise, plus sur celle de l’éditeur.
- Les sessions atteignent services internes, bases de données et registres privés sans les exposer sur l’Internet public ; dépôts, artefacts de build et secrets restent sur place.
- Les prompts, réponses et résultats d’outils continuent de partir chez Anthropic pour l’inférence, et le transcript de session est conservé.
- Réservé aux plans Team et Enterprise, désactivé par défaut, indisponible en Zero Data Retention, et il faut une équipe pour opérer les runners.
Un agent de programmation qui tourne derrière votre pare-feu, à côté de vos bases de données internes et de vos registres privés : c’est ce qu’Anthropic vient d’ouvrir en bêta publique avec les environnements auto-hébergés de Claude Code. La session démarre depuis le web, le mobile, le poste de travail ou une routine, puis s’exécute sur des machines que vous provisionnez.
Ce déplacement de l’exécution donne à l’agent un accès qu’aucun service en ligne ne pouvait lui offrir : le réseau interne.
Le prompt continue de voyager
Sur ce point, l’annonce est claire, et elle mérite une seconde lecture. Les dépôts clonés sur vos machines, les artefacts de build, les secrets et tous les fichiers qu’une session crée ou modifie restent sur l’infrastructure que vous contrôlez. La conversation, en revanche, part chez Anthropic pour l’inférence : prompts, réponses et résultats d’outils, ce qui inclut le code que le modèle lit au passage. Le transcript est stocké, précisément pour qu’une session puisse être reprise depuis n’importe quel appareil.
L’auto-hébergement rapatrie donc l’exécution, pas l’inférence. Une DSI (direction des systèmes d’information) qui signerait ce déploiement en espérant un Claude Code hors ligne se tromperait de produit, et les conditions d’accès le confirment : le mode Zero Data Retention (aucune conservation de données côté éditeur) est justement incompatible avec la fonctionnalité.
Interroger une base interne sans l’ouvrir sur Internet
Le gain décisif est ailleurs, et Anthropic le place en tête de ses trois motifs d’adoption : l’accès réseau. Une session peut interroger un service interne, une base de données, un registre d’artefacts privé, sans qu’aucun de ces systèmes soit exposé sur l’Internet public.
C’est un plafond qui saute. Jusqu’ici, un agent hébergé chez l’éditeur ne connaissait de votre système d’information que ce qu’un tunnel, un proxy ou une passerelle voulait bien lui montrer : autant de dispositifs coûteux à ouvrir, et qui élargissent la surface d’attaque à chaque exception. Là, l’agent est déjà à l’intérieur. Anthropic n’ouvre pas ce terrain le premier : depuis octobre 2025, GitHub laisse tourner son agent Copilot sur des runners auto-hébergés, justement pour lui donner accès à des ressources internes qu’aucune adresse publique n’expose.
Vient ensuite la préparation de l’environnement : on y pré-installe les compilateurs, les SDK (kits de développement) et les outils maison en ligne de commande, si bien que chaque session démarre avec la chaîne d’outils déjà en place. Un agent capable de lancer votre chaîne de build interne ne rend pas du tout le même service qu’un agent qui produit du code dans le vide. George Jacob, senior engineering manager cité dans l’annonce, décrit l’usage visé : générer des pull requests, aider à corriger les échecs d’intégration continue (CI), réagir aux événements du workflow de développement, avec une capacité de calcul qui suit la demande.
Anthropic prend soin de distinguer ces environnements du Remote Control, qui permet de reprendre depuis un téléphone une session lancée sur sa propre machine : celle-ci s’arrête avec la machine et reste liée à l’utilisateur qui a tapé la commande. Les environnements auto-hébergés, eux, tournent sur une infrastructure partagée qu’une équipe plateforme opère, et n’importe quel membre de l’organisation peut s’en servir. La différence n’a rien de cosmétique : elle fait passer l’agent du poste de travail au parc.
Des runners à déployer, et une équipe pour les tenir
L’éditeur ne masque pas la facture, et c’est assez rare pour le relever : il recommande « fortement » son offre hébergée à la plupart des entreprises, et réserve l’auto-hébergement aux équipes dont le réseau, l’outillage ou la conformité l’imposent. Avec un avertissement explicite : prévoyez des ingénieurs pour l’installation et la maintenance dans la durée.
Concrètement, vous déployez des runners, ces processus de longue durée qui prennent les sessions en charge et lancent un processus Claude Code pour chacune. Deux modes cohabitent. En mode fixe, un nombre constant de runners se partage les sessions. En mode à la demande, un orchestrateur surveille la file, démarre un runner quand une session arrive et l’arrête quand le travail est fini, pour que la capacité colle à l’usage. Un runner mène plusieurs sessions de front, mais toutes pour le même compte : il se verrouille sur celui du premier développeur servi, si bien que le code sorti des dépôts ne se mélange jamais d’un utilisateur à l’autre.
Traduction budgétaire : il faut une équipe plateforme, developer experience ou productivité, qui prenne ce composant en charge comme elle assume déjà la chaîne de CI. Une licence activée dans une console ne suffit plus, il faut exploiter un service.
Le sujet de sécurité glisse des données vers les droits
Sur les douze prochains mois, les organisations régulées (banque, assurance, santé, secteur public) inscriront l’exécution sur infrastructure maîtrisée dans leurs appels d’offres, exactement comme elles l’ont fait pour l’hébergement des données il y a dix ans. Ensuite, les runners rejoindront le catalogue interne aux côtés des agents de CI, avec quotas, refacturation et supervision.
Le basculement le plus profond viendra après. Dès lors qu’un agent dispose nativement des accès internes, la question de sécurité change de nature. Un agent qui atteint une base de production sans passer par Internet est aussi un agent qui peut y écrire si son compte de service a été taillé trop large. Revues d’habilitation, comptes de service dédiés par équipe, journalisation des actions d’agent : voilà ce qui occupera les RSSI (responsables de la sécurité des systèmes d’information) en 2027, bien avant la confidentialité des prompts.
Ce scénario tient à une condition : que l’exploitation reste soutenable. Si maintenir des runners coûte plus cher que la productivité gagnée, les équipes rebasculeront vers l’offre hébergée, et l’éditeur le suggère lui-même en la recommandant par défaut.
La contradiction, elle, saute aux yeux : les organisations en Zero Data Retention, aujourd’hui exclues du dispositif, sont précisément celles qui réclament le plus fort ce type de déploiement. Le jour où Anthropic lèvera cette incompatibilité, l’auto-hébergement cessera d’être une option de niche pour devenir le réglage par défaut des grands comptes.
Mon avis
L’auto-hébergement va provoquer plus d’incidents de sécurité qu’il n’en évite. Le danger ne vient pas de l’inférence distante, qui reste inchangée, mais des comptes de service qu’on va accorder à ces runners dans la précipitation, avec les droits d’un compte technique historique parce que c’était le plus rapide à câbler. Mon conseil est simple : démarrez en lecture seule sur un périmètre étroit, instrumentez chaque appel sortant, et n’élargissez qu’avec des habilitations propres à l’agent. Ceux qui feront l’inverse s’en apercevront avant l’été prochain, et pas par un rapport d’audit.
