Agent IA : une VM de test dédiée par agent

Réponse courte : une machine virtuelle par agent IA permet d’exécuter des changements risqués dans un périmètre indépendant. L’agent peut démarrer une base, ouvrir ses ports de test et modifier un rôle Ansible.

Il peut ensuite lancer ses scénarios E2E. L’IaC rend ce périmètre reconstruisible et supprimable sans ambiguïté.

Pourquoi une VM par agent IA plutôt qu’un environnement partagé ?

Un agent autonome n’est pas seulement un éditeur de fichiers. Il installe des paquets, lance des services, modifie des variables, crée des données et exécute des tests parallèles.

Sur un hôte partagé, ces actions se croisent vite. Deux agents peuvent réclamer le même port, réutiliser un conteneur, remplacer une dépendance ou lire un fichier d’environnement commun.

Le problème n’est pas qu’un agent fasse une erreur. Le problème est que son erreur devienne difficile à attribuer, à reproduire et à annuler.

Une worktree Git reste très utile : elle isole les branches et les fichiers modifiés. Elle n’empêche toutefois pas deux branches d’utiliser le même daemon Docker, la même base locale ou le même proxy.

La VM complète cette séparation. Elle fournit un noyau, un espace disque, un réseau virtuel et une table de processus propres à l’agent. Un échec est alors contenu dans un lab identifié.

Le modèle d’isolation : code, exécution, réseau et secrets

Le dépôt doit décrire la VM : système, CPU, mémoire, réseau, disques, ports exposés et provisioning. Vagrant avec KVM/libvirt convient bien à un lab local ; Terraform ou OpenTofu peuvent compléter le dispositif côté cloud.

Chaque lab possède un nom, un sous-réseau et des variables distinctes. Ainsi, les journaux et les artefacts remontent vers le bon agent sans mélange.

Les secrets de test ne sont pas copiés depuis la production. Utilisez des comptes de démonstration, des jetons à privilèges minimaux et des variables injectées uniquement au démarrage du lab.

Cette discipline prolonge les pratiques d’automatisation déjà nécessaires à une infrastructure fiable. Elle évite surtout de transformer un environnement de développement en terrain d’expérimentation permanent.

Quels tests méritent une machine virtuelle dédiée ?

Le premier cas est le test d’un provisioning. Modifier un rôle Ansible, une image système ou une configuration réseau mérite un système neuf, pas un serveur déjà configuré à la main.

Le second concerne les services stateful. PostgreSQL, Redis, MinIO, un proxy ou une stack de logs accumulent des données et des réglages qui rendent un test partagé peu fiable.

Le troisième est le test E2E. L’agent peut monter application, dépendances et navigateur de test dans un périmètre isolé, puis conserver les logs utiles à la revue.

À l’inverse, un contrôle statique ou une lecture de logs n’a pas toujours besoin d’une VM. Le bon niveau d’isolation dépend du rayon d’action de la tâche et de son besoin d’état.

Comment faire : créer une VM de test par agent avec QEMU/KVM et Vagrant

Il existe plusieurs façons d’isoler des agents : conteneurs, Incus/LXD, VMs cloud éphémères ou Kubernetes. Pour une équipe Linux qui veut démarrer simplement sur son poste, QEMU/KVM avec libvirt et Vagrant reste une option pragmatique.

QEMU/KVM exécute la machine virtuelle. Libvirt la pilote. Vagrant décrit son cycle de vie dans un Vagrantfile. Le provider vagrant-libvirt relie Vagrant à libvirt.

Le dépôt public agent-vagrant-vm-lab contient le Vagrantfile et un workflow Markdown portable à fournir à n’importe quel agent.

Déployer par un agent IA

Sur le poste hôte, il suffit de récupérer le dépôt et de transmettre le fichier Markdown à l’agent avec le nom de lab attendu.

git clone https://gitlab.com/babidi34/agent-vagrant-vm-lab.git
cd agent-vagrant-vm-lab

# Donner VAGRANT-LAB-WORKFLOW.md à l’agent.
# Exemple de nom à lui attribuer : agent-api-42

1. Installer l’hyperviseur, Vagrant et le provider

Sur Debian ou Ubuntu, suivez la documentation vagrant-libvirt et la documentation officielle Vagrant. Les commandes ci-dessous constituent un point de départ local.

sudo apt update
sudo apt install -y qemu-kvm libvirt-daemon-system libvirt-clients \
  libguestfs-tools vagrant ruby-fog-libvirt
sudo usermod -aG libvirt "$USER"
vagrant plugin install vagrant-libvirt

Reconnectez-vous après l’ajout au groupe libvirt. Vérifiez ensuite que l’hyperviseur et le provider répondent avant de créer une VM.

virsh -c qemu:///system list --all
vagrant plugin list | grep vagrant-libvirt

2. Donner un nom de lab unique à l’agent

Clonez le dépôt dans la worktree de la tâche. Le nom du lab doit être propre à l’agent et à son sujet : il devient le nom de la VM et évite qu’un nettoyage touche un autre test.

git clone https://gitlab.com/babidi34/agent-vagrant-vm-lab.git
cd agent-vagrant-vm-lab
export AGENT_LAB_NAME=agent-api-42
vagrant validate
vagrant up --provider=libvirt

Le Vagrantfile n’expose aucun port public et ne monte ni socket Docker ni secret hôte. Il crée une VM Debian avec un réseau privé et un service Nginx de démonstration.

3. Le Vagrantfile à versionner

# frozen_string_literal: true
REQUIRED_PLUGINS = %w[vagrant-libvirt].freeze
abort 'Install: vagrant plugin install vagrant-libvirt' unless REQUIRED_PLUGINS.all? { |plugin| Vagrant.has_plugin?(plugin) }

lab_name = ENV.fetch('AGENT_LAB_NAME', 'agent-vm-lab')
raise 'Invalid AGENT_LAB_NAME' unless lab_name.match?(/\A[a-z0-9][a-z0-9-]{2,40}\z/)

Vagrant.configure('2') do |config|
  config.vm.box = 'generic/debian12'
  config.vm.hostname = lab_name
  config.vm.network 'private_network', type: 'dhcp'
  config.vm.provider :libvirt do |libvirt|
    libvirt.default_prefix = "#{lab_name}-"
    libvirt.cpus = 2
    libvirt.memory = 2048
  end
  config.vm.provision 'shell', privileged: true, inline: <<~SHELL
    set -eu
    apt-get update
    apt-get install -y --no-install-recommends nginx curl ca-certificates
    systemctl enable --now nginx
  SHELL
end

Le fichier complet est disponible dans le dépôt public. Il reste volontairement petit pour être relu avant d’être adapté à un service réel.

4. Dire à l’agent comment tester et nettoyer

Le workflow Markdown portable donne à l’agent les règles de nommage, de validation et de nettoyage. Il lui interdit notamment les secrets de production, les ports publics et la suppression globale de VMs.

export AGENT_LAB_NAME=agent-api-42
vagrant ssh -c 'systemctl is-active nginx'
vagrant provision
vagrant ssh -c 'nginx -t'
vagrant halt
vagrant destroy -f

Résultat attendu : Nginx est actif, le second provisioning ne crée pas de dérive et seule la VM agent-api-42 est supprimée. Conservez les logs nécessaires avant la destruction.

Les garde-fous qui rendent ce modèle exploitable en équipe

La VM est une brique d’isolation, pas une autorisation générale. Les règles d’accès doivent rester écrites et testables.

La supervision mérite la même rigueur que le provisioning. Suivez les VMs actives, leur consommation et les échecs de création pour détecter une boucle ou un lab oublié.

Une chaîne CI peut aussi recréer ce lab à chaque merge request. Les principes d’une exécution GitLab CI planifiée restent utiles : traçabilité, résultat consultable et nettoyage prévu.

Pour les métriques hôte, un socle tel que Node Exporter aide à surveiller la saturation avant qu’elle ne pénalise les autres travaux.

Erreurs courantes avec les labs d’agents

FAQ : agent IA et machine virtuelle