Déployer un agent IA en production

Introduction

Un agent IA qui tourne sur votre machine locale, c'est une preuve de concept. Un agent qui tourne en production, c'est un outil qui crée de la valeur. La différence entre les deux n'est pas seulement technique — elle impose de penser containerisation, supervision, sécurité et disponibilité.

Dans ce tutoriel, vous apprendrez à prendre un agent Python fonctionnel et à le transformer en service robuste qui tourne 24h/24 sur un VPS. Nous couvrons Docker, la configuration systemd, la gestion des secrets, le monitoring et les bonnes pratiques de sécurité.

À la fin, vous aurez un agent prêt pour la production — pas une coquille fragile.

Résumé rapide

Étape	Action	Outil
1	Rendre l'agent configurable via variables d'environnement	Python os.environ
2	Containeriser avec un Dockerfile slim	Docker
3	Choisir un VPS adapté (2 Go RAM minimum)	Hetzner / OVH / Scaleway
4	Déployer avec systemd ou Docker restart policy	systemd / docker-compose
5	Configurer le pare-feu et les secrets	UFW, .env
6	Mettre en place le monitoring et les alertes	Healthcheck, logs

Préparer l'agent pour la production

Externaliser la configuration

La première étape consiste à retirer toutes les valeurs codées en dur. Un agent en production doit être configurable sans modifier le code.

import os

# Clés API — NE JAMAIS hardcoder
api_key = os.environ.get("OPENAI_API_KEY")
model = os.environ.get("MODEL_NAME", "gpt-4o")
max_tokens = int(os.environ.get("MAX_TOKENS", "2000"))

# Configuration du comportement
temperature = float(os.environ.get("TEMPERATURE", "0.7"))
max_steps = int(os.environ.get("MAX_AGENT_STEPS", "10"))

Placez ces variables dans un fichier .env et chargez-le au démarrage :

from dotenv import load_dotenv
load_dotenv()

Règle absolue : le fichier .env doit être dans .gitignore. Ne commitez jamais de clé API.

Prévoir le rechargement sans interruption

Votre agent doit pouvoir être reconfiguré sans redémarrage brutal. Un pattern courant : un fichier de configuration JSON rechargé périodiquement ou sur signal SIGUSR1.

import signal, json

def reload_config(signum, frame):
    with open("agent_config.json") as f:
        config = json.load(f)
    print(f"Configuration rechargée : {config}")

signal.signal(signal.SIGUSR1, reload_config)

Containeriser avec Docker

Le Dockerfile

Choisissez une image Python slim pour minimiser la taille et la surface d'attaque :

FROM python:3.12-slim

WORKDIR /app

# Dépendances système minimales
RUN apt-get update && apt-get install -y --no-install-recommends \
    curl \
    && rm -rf /var/lib/apt/lists/*

# Dépendances Python
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# Code de l'agent
COPY agent.py .

# Usuario no root
RUN useradd -m -u 1000 agent && chown -R agent:agent /app
USER agent

CMD ["python", "agent.py"]

docker-compose pour orchestrer

version: "3.9"
services:
  agent:
    build: .
    restart: unless-stopped
    env_file:
      - .env
    volumes:
      - ./data:/app/data
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8000/health"]
      interval: 30s
      timeout: 10s
      retries: 3
    networks:
      - agent_network

networks:
  agent_network:
    driver: bridge

L'option restart: unless-stopped garantit que l'agent redémarre automatiquement après un crash ou un reboot du serveur.

Choisir et configurer le VPS

Ressources minimales

Pour un agent Python léger (pas de modèle local) :

Provider	Instance	RAM	vCPU	Prix/mois
Hetzner	CX21	4 Go	2	~4 €
OVH	Starter	2 Go	1	~3 €
Scaleway	DEV1-S	2 Go	2	~3 €

Pour un agent avec modèle local (Llama, Mistral), prévoyez un minimum de 16 Go RAM et un CPU correct — Hetzner AX42 (≈ 20 €/mois) ou équivalent.

Installation de Docker sur le VPS

# Connexion SSH
ssh root@adresse_ip

# Installation Docker
curl -fsSL https://get.docker.com | sh

# Activer Docker au démarrage
systemctl enable docker

# Ajouter l'utilisateur (votre login) au groupe docker
usermod -aG docker $USER

Transférez vos fichiers sur le VPS :

# Depuis votre machine
rsync -avz --exclude='.env' --exclude='.git' ./agent/ user@vps:/home/user/agent/

Déployer et maintenir le service actif

Option 1 : systemd (recommandé pour un seul agent)

Créez un service systemd :

# /etc/systemd/system/agent-ia.service
[Unit]
Description=Agent IA de production
After=network.target

[Service]
Type=simple
User=agent
WorkingDirectory=/home/agent/agent
EnvironmentFile=/home/agent/agent/.env
ExecStart=/usr/bin/python3 /home/agent/agent/agent.py
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

Activez et lancez :

systemctl enable agent-ia
systemctl start agent-ia
journalctl -u agent-ia -f  # suivre les logs en temps réel

Option 2 : Docker directement

Si vous préférez Docker à systemd :

docker run -d \
  --name mon_agent \
  --restart unless-stopped \
  --env-file .env \
  -v $(pwd)/data:/app/data \
  -p 8000:8000 \
  mon_agent:latest

Vérifier que l'agent est vivant

Ajoutez un endpoint healthcheck dans votre agent :

from flask import Flask
app = Flask(__name__)

@app.route("/health")
def health():
    return {"status": "ok", "agent": "production"}

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=8000)

Testez depuis l'extérieur :

curl https://votre-domaine.com/health

Sécurité de base

Pare-feu avec UFW

ufw default deny incoming
ufw default allow outgoing
ufw allow ssh
ufw allow 80/tcp
ufw allow 443/tcp
ufw allow 8000/tcp  # only if healthcheck exposed
ufw enable

Gestion des secrets

Jamais dans le code ou dans un fichier commité.

# Variables d'environnement uniquement en production
# Le fichier .env reste en LOCAL, ne contient PAS de vraie clé
# Sur le VPS, définissez les variables dans systemd :
Environment=OPENAI_API_KEY=sk-...
Environment=MODEL_NAME=gpt-4o

Pour les environnements critiques, utilisez un gestionnaire de secrets comme Doppler ou HashiCorp Vault.

Accès SSH

• Désactivez l'authentification par mot de passe (clés SSH uniquement)
• Changez le port SSH par défaut (2222 par exemple)
• Installez fail2ban pour bloquer les tentatives d'attaque par force brute

apt install fail2ban
systemctl enable fail2ban

Monitoring et alertes

Logs structurés

Envoyez les logs dans un format lisible pour l'analyse :

import logging, sys

logging.basicConfig(
    level=logging.INFO,
    format="%(asctime)s %(levelname)s %(name)s: %(message)s",
    handlers=[
        logging.FileHandler("/var/log/agent/agent.log"),
        logging.StreamHandler(sys.stdout)
    ]
)

logger = logging.getLogger("agent_ia")
logger.info("Agent démarré", extra={"model": model, "max_steps": max_steps})

Surveillance avec healthcheck

# Script de surveillance
#!/bin/bash
if curl -sf http://localhost:8000/health > /dev/null; then
    echo "OK"
    exit 0
else
    echo "FAIL"
    exit 1
fi

Placez ce script dans /usr/local/bin/agent-healthcheck et exécutez-le depuis systemd :

[Service]
ExecStartPost=/usr/local/bin/agent-healthcheck

Alerte par email en cas de panne

Utilisez un service comme Healthchecks.io ou UptimeRobot pour pinguer votre endpoint /health toutes les minutes. Configurez une alerte email/SMS si le ping échoue pendant 2 minutes.

Tableau comparatif : systemd vs Docker restart

Critère	systemd	Docker restart
Simplicité	Bon pour 1 agent	Bon pour plusieurs services
Portabilité	Lié à la machine	Portable entre machines
Supervision	journalctl natif	docker logs
Networking	Config réseau standard	Network mode intégré
Mise à jour	systemctl restart	docker pull && docker-compose up -d

Pour un seul agent, systemd est souvent le choix le plus simple et le plus robuste.

Questions fréquentes

Comment mettre à jour l'agent sans interruption de service ?

Avec Docker : docker pull télécharge la nouvelle image, puis docker-compose up -d --no-deps agent remplace le conteneur. Le flag --no-deps évite de redémarrer les services dépendants.

Avec systemd : modifiez le code, transférez via rsync, puis systemctl restart agent-ia.

Un agent IA peut-il tourner sur un Raspberry Pi ?

Un agent utilisant une API externe (OpenAI, Anthropic) oui, sans problème. Un agent avec modèle local (Llama 3) nécessite un GPU ou beaucoup de RAM — pas adapté au Pi. Dans ce cas, hebergez le modèle sur une machine séparée et connectez l'agent via API.

Comment éviter d'exposer mes clés API sur le serveur ?

Définissez les variables d'environnement dans la configuration du service (systemd Environment=) ou utilisez un gestionnaire de secrets. Le fichier .env reste en local et n'est jamais transféré sur le VPS.

Comment dimensionner le VPS ?

Commencez avec 2 Go RAM / 1 vCPU pour un agent avec API externe. Surveillez avec htop après déploiement. Si memory leak ou charge élevée, montez à 4 Go. Pour un modèle local, partez sur 16 Go minimum.

Articles liés

Déployer un agent en production n'est que la dernière étape. Avant d'en arriver là, il faut avoir construit l'agent lui-même. Le pilier de ce tutoriel est la création d'agent — maîtriser ce processus est un prérequis indispensable.

Votre agent tourne désormais en continu. L'étape suivante logique consiste à lui confier des tâches métier récurrentes : veille concurrentielle, génération de contenu, qualification de leads. L'automatisation par agents IA est le terrain de jeu naturel de ce type de déploiement.

• Créer un agent IA : guide complet
• OpenClaw sur VPS : installation complète
• Automatisation avec agents IA
• Comparatif OpenClaw vs CrewAI