Skip to Content

Faire tourner un agent de développement IA sur votre propre infrastructure : ce que changent les self-hosted environments de Claude Code

Sessions cloud, exécution sur vos serveurs, souveraineté documentée : ce que cette évolution change pour les PME industrielles
August 26, 2026 by
Faire tourner un agent de développement IA sur votre propre infrastructure : ce que changent les self-hosted environments de Claude Code
IXEMELIS, Amélie DAGORN

Chez Ixemelis, nous défendons une conviction simple : l'IA doit s'intégrer dans votre système d'information, pas à côté. Une évolution récente de Claude Code, l'agent de développement d'Anthropic, étend cette logique au développement logiciel lui-même : il est désormais possible de faire exécuter les sessions de l'agent sur sa propre infrastructure. Explications et implications pour les PME industrielles.

Les sessions cloud : déléguer une tâche de développement et fermer son laptop

Commençons par le principe de base. Une session cloud Claude Code est une tâche de développement (correction de bug, nouvelle fonctionnalité, revue de code, génération de pull request) que l'on confie à l'agent depuis le web, le mobile, le desktop ou le terminal, et qui s'exécute ailleurs que sur le poste du développeur. On lance la tâche, on suit l'avancement depuis n'importe quel appareil, on valide le résultat. Le développeur n'est plus bloqué devant sa machine pendant que l'agent travaille.

Par défaut, ces sessions s'exécutent sur l'infrastructure d'Anthropic : c'est le mode « cloud environment ». Zéro installation, zéro maintenance, et la possibilité de configurer pour chaque environnement l'accès réseau, des variables d'environnement et un script de préparation. Pour la majorité des équipes, c'est le bon choix : simple, immédiat, efficace.

Le déclic : les self-hosted environments

La nouveauté qui a retenu notre attention, c'est la seconde option, disponible en bêta publique pour les organisations sur plans Team et Enterprise : les self-hosted environments.

Le principe : vous installez un « runner » (un programme léger) sur une ou plusieurs machines de votre réseau, un serveur interne ou un VPS. Ces machines s'enregistrent auprès du backend Claude Code et attendent les sessions. Quand un développeur lance une session cloud et sélectionne votre environnement, la tâche s'exécute chez vous, à l'intérieur de votre réseau. L'expérience utilisateur reste identique : mêmes écrans, mêmes validations, même suivi depuis le mobile.

Ce qui change, c'est la localisation de l'exécution :

  • le checkout du dépôt Git reste sur votre infrastructure
  • les artefacts de build restent sur votre infrastructure
  • les secrets, variables d'environnement et fichiers créés par la session restent sur votre infrastructure
  • la session peut accéder à vos services internes (bases de données, registries, instances de développement) sans que rien ne soit exposé sur internet

Soyons précis sur la souveraineté

Le mot « souveraineté » est trop souvent utilisé comme un slogan. Chez Ixemelis, nous préférons décrire exactement ce qui se passe, pour que chacun puisse évaluer si le dispositif répond à ses exigences.

Dans un self-hosted environment, le code source, les artefacts et les secrets ne quittent pas votre infrastructure. En revanche, l'inférence du modèle reste assurée par Anthropic : les prompts et le contenu des conversations, qui peuvent inclure des extraits de code que l'agent lit pour raisonner, transitent par leurs serveurs. Ce n'est donc pas un déploiement totalement hermétique, mais une réduction significative et maîtrisable de la surface d'exposition : vous contrôlez ce que l'agent peut atteindre, ce qui reste chez vous, et ce qui transite pour l'inférence.

Pour une PME industrielle soumise à des exigences de localisation du code, de cloisonnement réseau ou de traçabilité, cette distinction est précisément celle qu'attendent un RSSI ou un auditeur : une réponse factuelle et vérifiable, plutôt qu'une promesse marketing.

Les cas d'usage que nous voyons pour les PME industrielles

Développer au contact des systèmes internes. C'est le cas d'usage le plus concret. Une session peut travailler sur un connecteur ERP en accédant directement à une instance Odoo de développement, à une base de test ou à un registry interne, sans ouvrir le moindre flux vers l'extérieur. Pour les projets d'intégration (Odoo, Dynamics 365, EDI, interfaces machines), c'est un changement de dimension.

Standardiser les environnements de développement. Chaque environnement self-hosted peut être pré-configuré avec vos compilateurs, SDK, CLI internes et outillages maison. Chaque session démarre prête à builder, sans phase d'installation, avec les mêmes versions pour tout le monde.

Répondre aux appels d'offres exigeants. Dans les secteurs défense, pharma, aéronautique ou industrie, la localisation du code et des données est souvent un critère éliminatoire. Pouvoir documenter précisément où s'exécute l'agent et ce qui reste dans le périmètre de l'entreprise transforme une clause vague en réponse d'audit.

Automatiser sans poste allumé. Les tâches planifiées (routines) s'exécutent sur vos runners : veille de dépendances, correctifs de CI, génération de rapports, sans qu'une machine de développeur soit allumée.

Ce qu'il faut savoir avant de se lancer

  • La fonctionnalité est réservée aux plans Team et Enterprise, et désactivée par défaut (activation par un Owner dans les paramètres admin)
  • Les checkouts de dépôts se font depuis GitHub pour l'instant
  • Certaines surfaces (Claude Tag, Code Review) ne routent pas encore vers les environnements self-hosted
  • L'inférence ne peut pas être routée via Bedrock, Vertex ou Foundry
  • Il faut prévoir la mise en place et la maintenance des runners : c'est léger, mais ce n'est pas zéro

Côté coûts, le modèle est sain : l'usage est décompté sur l'abonnement existant, exactement comme les sessions hébergées. Le surcoût se limite à l'infrastructure des runners, un simple VPS suffisant pour démarrer.

Notre lecture

Cette évolution valide une tendance de fond que nous observons chez nos clients : l'IA générative sort de la phase « outil sur le poste du développeur » pour entrer dans la phase « brique d'infrastructure », avec les mêmes questions que n'importe quelle brique d'infrastructure : où s'exécute-t-elle, à quoi accède-t-elle, qui la maintient, que dit-on à l'auditeur.

C'est exactement le terrain d'Ixemelis. Nous expérimentons ce dispositif sur notre propre infrastructure avant de le proposer à nos clients, comme nous le faisons pour chaque brique de notre offre. Si le sujet vous concerne (agents de développement, automatisation IA au contact de votre ERP, exigences de conformité), parlons-en.

in News