Conception d’une infrastructure IA sécurisée pour un agent autonome Claude chez Evaneos

Evaneos

Evaneos est une plateforme de voyage qui met en relation les voyageurs avec des agences locales sélectionnées afin de concevoir des voyages sur mesure directement avec des experts présents à destination.

Secteur d’activité

Tourisme / Voyage

Type d’accompagnement

Cloud & DevOps / Infrastructure IA

Technologies

Claude, GCP, Google Kubernetes
Engine (GKE), Kubernetes,
Agent Sandbox, gVisor, vCluster, Terraform, Flux CD, GitOps, Go

Consultant

Julien Dupuis

Lead DevOps

Partager ce témoignage :

Le contexte : sécuriser l’infrastructure utilisée par un agent autonome Claude

Evaneos a adopté très tôt l’intelligence artificielle dans ses processus de développement. Après une première phase reposant sur des abonnements individuels, l’entreprise est passée à un environnement Claude Enterprise partagé par les équipes et a développé un agent autonome basé sur Claude capable de prendre en charge des tâches de développement à partir de tickets Linear.

À partir d’un ticket, d’une fonctionnalité, d’un bug ou même d’une Epic, l’agent peut décomposer le besoin en sous-tâches, générer le code associé et faire sa revue. Cette utilisation avancée de Claude pose néanmoins une question structurante : dans quel environnement laisser s’exécuter un agent disposant d’un niveau d’autonomie important ?

Eleven Labs est intervenu pour répondre à cette question afin de concevoir un environnement dédié et cloisonné, permettant à l’agent de générer et tester du code sans disposer d’un accès direct à la production.

Cette mission s’inscrit dans une problématique devenue centrale avec l’adoption des agents IA Claude en entreprise : donner davantage d’autonomie aux systèmes agentiques tout en maîtrisant précisément leurs droits, leurs environnements d’exécution et leur accès au système d’information.

Les enjeux techniques pour exécuter un agent IA autonome en toute sécurité

Le premier enjeu était celui du cloisonnement de l’agent. Dans une architecture classique, un développeur travaille dans un environnement dont les accès sont contrôlés. Un agent autonome capable d’exécuter du code nécessite le même niveau de vigilance, voire davantage : une mauvaise configuration ne doit pas lui permettre d’interagir librement avec les ressources de production.

Le choix a donc été fait de ne pas exécuter l’agent sur le cluster principal, mais de créer un nouveau cluster Google Kubernetes Engine spécifiquement destiné à ces workloads IA. L’objectif était de construire une sandbox suffisamment isolée pour limiter les droits d’exécution et contenir les actions de l’agent.

Un second enjeu concernait la création d’environnements éphémères. Lorsqu’une Pull Request est créée ou que l’agent produit du code, les équipes doivent pouvoir disposer rapidement d’un environnement temporaire dans lequel déployer et tester l’application, puis supprimer cet environnement une fois les vérifications terminées.

Cette infrastructure devait par ailleurs s’intégrer à un SI technique déjà hétérogène. Evaneos utilise différentes approches d’Infrastructure as Code selon ses activités, notamment Pulumi en TypeScript sur son activité historique et Crossplane sur une autre Business Unit. Le projet devait donc trouver sa place dans cet écosystème sans ajouter inutilement de complexité.

Enfin, les enjeux économiques ont été intégrés dès la conception. La multiplication de clusters et d’environnements temporaires peut rapidement faire augmenter les dépenses cloud. Une logique FinOps a donc été appliquée dès le POC afin de rechercher le meilleur compromis entre isolation, performance et coût.

“Le sujet n’était pas simplement de faire fonctionner l’agent. Il fallait lui donner suffisamment d’autonomie pour travailler tout en s’assurant qu’il reste dans un environnement totalement maîtrisé, sans accès direct aux données et aux ressources de production.”

Julien

Lead DevOps

Les missions réalisées pour construire l’infrastructure de l’agent autonome Claude

Création d’un cluster GKE dédié aux workloads IA

Mise en place d’un nouveau cluster Google Kubernetes Engine sur GCP, distinct du cluster de production principal, afin de fournir à l’agent autonome un environnement d’exécution dédié.
Cette séparation permet de limiter son périmètre d’action et d’éviter qu’un agent générant ou exécutant du code puisse accéder directement aux ressources critiques du système d’information.

Isolation de l’agent avec Agent Sandbox et gVisor

Déploiement des composants nécessaires au cloisonnement de l’agent, avec Agent Sandbox et gVisor. gVisor fournit une couche supplémentaire entre les workloads conteneurisés et le système hôte afin de limiter les capacités d’exécution disponibles dans les pods.

Cette approche permet d’intégrer les principes de sécurité DevSecOps directement dans l’architecture d’exécution de l’agent plutôt que de les traiter uniquement après son déploiement.

Mise en place d’environnements éphémères avec vCluster

Utilisation de vCluster pour créer des clusters Kubernetes virtuels isolés sur une même infrastructure physique.

Chaque environnement de développement ou de test peut ainsi disposer de son propre cluster virtuel. Les équipes peuvent lancer temporairement un environnement pour tester le code associé à une Pull Request ou produit par l’agent, puis le supprimer lorsqu’il n’est plus nécessaire.

Automatisation de l’infrastructure avec Terraform et Flux CD

Création du cluster et de ses ressources avec Terraform, puis mise en place de la configuration et du déploiement continu avec Flux CD selon une approche GitOps.

L’objectif était de rendre l’environnement reproductible et de gérer sa configuration comme du code, dans la continuité des pratiques d’Infrastructure as Code déjà utilisées par les équipes techniques.

Collaboration avec les équipes Evaneos sur le tooling

Le travail d’infrastructure a été mené conjointement avec un développeur Evaneos dédié au projet. Celui-ci a notamment développé une CLI en Go permettant d’interagir avec les environnements vCluster.

À partir d’une commande, l’outil peut créer un environnement virtuel et y déployer l’application. Eleven Labs est intervenu sur la définition des bonnes pratiques d’infrastructure, de configuration et de sécurité nécessaires au fonctionnement de ce tooling.

Intégration des contraintes FinOps dès la conception

L’architecture a été pensée dès le départ pour éviter une surconsommation de ressources cloud.

Le cluster a notamment été configuré en monozone afin de limiter certains flux réseau entre zones, tandis qu’un travail de dimensionnement des machines a été réalisé pour trouver un équilibre entre performances et coût d’exploitation.

Cette approche permet d’éviter qu’une infrastructure destinée aux usages IA ne génère une dépense disproportionnée à mesure que les environnements éphémères se multiplient.

Les premiers résultats de l’infrastructure IA mise en place chez Evaneos

Isolation de l’agent autonome Claude

dans un cluster GKE dédié, séparé de l’infrastructure de production, avec Agent Sandbox et gVisor pour limiter ses droits d’exécution.

Création d’environnements éphémères et isolés

avec Kubernetes et vCluster afin de permettre aux développeurs de tester le code généré dans le cadre du pipeline agentique.

Infrastructure opérationnelle et testée par les équipes de développement

avec une phase de retours utilisateurs en cours avant les prochains arbitrages d’architecture.

Premières bases posées pour l’industrialisation des agents IA

avec une architecture pensée pour concilier sécurité, autonomie, automatisation de l’infrastructure et maîtrise des coûts grâce à une approche FinOps.