OpenClaw en production : checklist complète

Introduction

Vous avez suivi le guide pour installer OpenClaw sur un VPS, votre instance répond aux requêtes, les agents tournent. C'est le début — pas la fin. Passer en production signifie adopter une discipline opérationnelle : savoir si l'instance est saine, pouvoir revenir en arrière en moins de cinq minutes si une mise à jour casse quelque chose, et centraliser les logs pour diagnostiquer rapidement. Ce guide couvre les étapes concrètes pour fiabiliser un déploiement OpenClaw : versionning de config, health checks, stratégie de rollback, observabilité et gestion des mises à jour.

Résumé rapide

• Versionner la config : dépôt git dédié, tags à chaque changement significatif
• Health check : endpoint /health supervisé par systemd ou Docker
• Rollback : garder l'image ou le binaire N-1, procédure en < 5 minutes
• Logs : niveau INFO en prod, DEBUG à activer ponctuellement
• Mises à jour : tester sur staging, snapshotter avant de mettre à jour
• Fumée post-deploy : valider 3 endpoints critiques immédiatement après chaque déploiement

Dev vs prod : ce qui change vraiment avec OpenClaw

En développement, OpenClaw tourne souvent avec node index.js ou python main.py, la config est un fichier .env local, et les erreurs se lisent dans le terminal. C'est suffisant pour itérer vite.

En production, cette approche génère trois catégories de risques :

Risque de perte d'état. OpenClaw maintient un contexte d'exécution pour chaque agent actif. Si le processus redémarre brutalement — crash, OOM killer, redémarrage du serveur — ce contexte disparaît. Sans supervision, personne ne le sait avant que les agents ne répondent plus.

Risque de régression silencieuse. Une mise à jour d'OpenClaw ou d'une dépendance peut modifier le comportement d'un outil interne (parser, connecteur API, format de réponse). Sans versionning de config et tests de fumée, la régression passe inaperçue jusqu'au premier incident client.

Risque d'opacité. En dev, vous êtes devant le terminal. En prod, vous n'êtes pas là quand ça casse. Si les logs ne sont pas centralisés et structurés, diagnostiquer une anomalie à 3h du matin prend une heure au lieu de dix minutes.

Ce qui est spécifique à OpenClaw par rapport à un déploiement générique : la config des agents (fichiers YAML ou JSON dans agents/), les credentials des connecteurs, et le fichier de configuration principal (openclaw.config.json ou équivalent) constituent l'état fonctionnel de l'instance. Ce n'est pas du code applicatif — c'est de la configuration opérationnelle. Elle doit être versionnée séparément et protégée autant que les secrets.

Avant d'aller plus loin, assurez-vous également d'avoir lu le guide Sécuriser OpenClaw : en production, la surface d'attaque est réelle.

Déployer OpenClaw en production : checklist et procédures

1. Versionner la configuration OpenClaw

La configuration d'OpenClaw — fichiers d'agents, paramètres de connecteurs, règles de routage — évolue indépendamment du code source. Elle doit vivre dans un dépôt git dédié.

Structure recommandée :

openclaw-config/
├── agents/
│   ├── agent-seo.yaml
│   └── agent-veille.yaml
├── connectors/
│   └── openai.yaml
├── openclaw.config.json
└── CHANGELOG.md

Règles de base :

• Un commit par changement de config, message explicite (feat: ajout connecteur Notion, fix: timeout agent-seo porté à 30s)
• Un tag Git à chaque déploiement en production : v2026-04-03-1
• Un CHANGELOG.md minimal : date, auteur, nature du changement, version d'OpenClaw utilisée
• Ne jamais committer les secrets — utiliser des variables d'environnement ou un gestionnaire de secrets

Pour gérer les variables de configuration sans les secrets, consultez le guide Configurer OpenClaw qui détaille les options d'injection d'environnement.

Checklist de mise en production :

• La config est dans un dépôt git avec historique propre
• Un tag de version est posé avant chaque déploiement
• Les secrets sont injectés via l'environnement, pas en clair dans les fichiers
• Le CHANGELOG.md est à jour
• L'image Docker ou le binaire N-1 est conservé et accessible
• Le health check est configuré et supervisé
• Les logs sont centralisés (fichier rotatif ou agrégateur)
• Une procédure de rollback documentée existe et a été testée
• Des tests de fumée sont définis et exécutés après chaque déploiement

2. Configurer les health checks OpenClaw

OpenClaw expose un endpoint de santé (vérifiez la documentation de votre version — généralement /health ou /api/health). Il doit retourner un statut HTTP 200 avec un payload JSON minimal :

{ "status": "ok", "version": "1.4.2", "uptime": 3842 }

Avec systemd :

Créez le fichier service /etc/systemd/system/openclaw.service :

[Unit]
Description=OpenClaw Agent Runtime
After=network.target

[Service]
Type=simple
User=openclaw
WorkingDirectory=/opt/openclaw
ExecStart=/opt/openclaw/bin/openclaw serve --config /etc/openclaw/openclaw.config.json
Restart=always
RestartSec=5
StandardOutput=append:/var/log/openclaw/openclaw.log
StandardError=append:/var/log/openclaw/openclaw-error.log
Environment=NODE_ENV=production
EnvironmentFile=/etc/openclaw/env

[Install]
WantedBy=multi-user.target

Activez et démarrez :

systemctl daemon-reload
systemctl enable openclaw
systemctl start openclaw
systemctl status openclaw

Pour superviser le health check avec systemd, utilisez un timer :

# /etc/systemd/system/openclaw-healthcheck.service
[Unit]
Description=OpenClaw health check
After=openclaw.service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/openclaw-healthcheck.sh

# /etc/systemd/system/openclaw-healthcheck.timer
[Unit]
Description=Run OpenClaw health check every minute

[Timer]
OnCalendar=*:*:0/30
Persistent=true

[Install]
WantedBy=timers.target

Script /usr/local/bin/openclaw-healthcheck.sh :

#!/bin/bash
STATUS=$(curl -sf -o /dev/null -w "%{http_code}" http://localhost:3100/health)
if [ "$STATUS" != "200" ]; then
  echo "$(date) — OpenClaw health check FAILED (HTTP $STATUS)" >> /var/log/openclaw/healthcheck.log
  systemctl restart openclaw
fi

Avec Docker Compose :

services:
  openclaw:
    image: openclaw:1.4.2
    restart: always
    env_file: .env
    ports:
      - "3100:3100"
    volumes:
      - ./config:/etc/openclaw:ro
      - openclaw-logs:/var/log/openclaw
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3100/health"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 20s

volumes:
  openclaw-logs:

Le paramètre restart: always garantit le redémarrage automatique après un crash ou un reboot serveur. Le healthcheck intégré permet à Docker de marquer le conteneur comme unhealthy et de le redémarrer si les sondes échouent trois fois consécutives.

3. Stratégie de rollback en moins de 5 minutes

La règle est simple : ne jamais déployer sans avoir une procédure de retour arrière testée.

Avec Docker :

# Avant de mettre à jour, noter la version en cours
docker ps --format "table {{.Image}}\t{{.Names}}"

# Déployer la nouvelle version
docker compose pull && docker compose up -d

# Si quelque chose cloche, rollback immédiat
docker compose stop openclaw
docker compose rm -f openclaw

# Modifier docker-compose.yml pour pointer sur la version N-1
# image: openclaw:1.4.1

docker compose up -d openclaw

# Vérifier le health check
curl http://localhost:3100/health

Avec systemd + binaire :

# Garder le binaire précédent
cp /opt/openclaw/bin/openclaw /opt/openclaw/bin/openclaw.bak

# Rollback si nécessaire
systemctl stop openclaw
cp /opt/openclaw/bin/openclaw.bak /opt/openclaw/bin/openclaw
systemctl start openclaw

Documentez cette procédure dans un RUNBOOK.md à la racine du dépôt de config. Elle doit être exécutable sans connexion internet et sans accès à l'historique git de l'application.

4. Logs et observabilité

OpenClaw produit des logs structurés. En production, le niveau recommandé est INFO. Le niveau DEBUG génère un volume qui peut saturer les disques en quelques heures sur une instance active.

Configuration dans openclaw.config.json :

{
  "logging": {
    "level": "info",
    "format": "json",
    "output": "/var/log/openclaw/openclaw.log"
  }
}

Rotation des logs avec logrotate :

/var/log/openclaw/*.log {
    daily
    missingok
    rotate 14
    compress
    delaycompress
    notifempty
    postrotate
        systemctl kill -s HUP openclaw.service
    endscript
}

Pour une alerte simple sans stack de monitoring complète, un script cron suffit :

# Crontab — toutes les 5 minutes
*/5 * * * * grep -c "ERROR" /var/log/openclaw/openclaw.log | awk '$1 > 10 {print "Alerte : " $1 " erreurs détectées"}' | mail -s "OpenClaw ALERTE" ops@votredomaine.com

5. Gestion des mises à jour d'OpenClaw

Ne jamais mettre à jour OpenClaw directement en production sans passer par un environnement de staging. La procédure :

1. Lire les release notes — identifier les breaking changes
2. Tester la nouvelle version sur staging avec la config de production (sans les secrets réels)
3. Exécuter les tests de fumée sur staging
4. Créer un snapshot de la VM ou un backup de la config avant de mettre à jour en prod
5. Mettre à jour en production en heure creuse
6. Exécuter les tests de fumée immédiatement après
7. Surveiller les logs pendant 30 minutes

Exemple concret : déploiement complet avec Docker Compose

Contexte : instance OpenClaw utilisée pour un agent de génération d'articles SEO. Version actuelle : 1.4.1. Mise à jour vers 1.4.2.

# 1. Vérifier l'état avant intervention
curl http://localhost:3100/health
# {"status":"ok","version":"1.4.1","uptime":86420}

# 2. Poser un tag git sur la config actuelle
cd /opt/openclaw-config
git add -A && git commit -m "chore: snapshot avant upgrade 1.4.2"
git tag v2026-04-03-pre-upgrade

# 3. Mettre à jour l'image dans docker-compose.yml
sed -i 's/openclaw:1.4.1/openclaw:1.4.2/' docker-compose.yml

# 4. Puller la nouvelle image
docker compose pull openclaw

# 5. Redémarrer le service
docker compose up -d openclaw

# 6. Vérifier le démarrage
docker compose ps
docker compose logs openclaw --tail=50

# 7. Test de fumée — 3 endpoints critiques
curl -s http://localhost:3100/health | jq .
curl -s -X POST http://localhost:3100/api/agents/agent-seo/run \
  -H "Content-Type: application/json" \
  -d '{"input": "test smoke"}' | jq '.status'
curl -s http://localhost:3100/api/status | jq .

# 8. Si tout est vert, tagger la nouvelle version
git add docker-compose.yml
git commit -m "chore: upgrade openclaw 1.4.1 → 1.4.2"
git tag v2026-04-03-1
git push origin main --tags

Si l'étape 7 révèle une anomalie, le rollback prend moins de deux minutes :

sed -i 's/openclaw:1.4.2/openclaw:1.4.1/' docker-compose.yml
docker compose up -d openclaw
curl http://localhost:3100/health

Bonnes pratiques et erreurs fréquentes

Erreurs courantes :

• Déployer sans snapshot préalable. Même une sauvegarde manuelle de /opt/openclaw-config suffit. L'absence de point de retour transforme chaque mise à jour en prise de risque non maîtrisée.
• Laisser le niveau de log en DEBUG en production. Les logs JSON structurés en DEBUG peuvent atteindre plusieurs gigaoctets par jour sur une instance active. Utilisez INFO par défaut et activez DEBUG ponctuellement avec systemctl kill -s USR1 openclaw.service si OpenClaw le supporte.
• Ignorer les tests de fumée. Trois requêtes curl prennent 30 secondes. Ne pas les faire, c'est découvrir la régression par un utilisateur.
• Mettre à jour en heure de pointe. Même avec un rollback prévu, la fenêtre de dégradation affecte les utilisateurs. Déployez en heure creuse.

Spécificités OpenClaw :

• Les fichiers d'agents YAML peuvent contenir des références à des prompts système. Un changement de format entre versions peut rendre des agents silencieusement non fonctionnels (ils démarrent mais produisent des réponses vides). Le test de fumée doit inclure un appel réel à au moins un agent.
• La rotation des credentials de connecteurs (OpenAI, Notion, etc.) doit être coordonnée avec un redémarrage d'OpenClaw — la plupart des connecteurs chargent les credentials au démarrage.

Questions fréquentes

Comment vérifier si OpenClaw est bien en production stable ?

Appelez l'endpoint /health et vérifiez que le HTTP 200 est retourné avec "status": "ok". Croisez avec systemctl status openclaw ou docker compose ps pour confirmer que le processus est actif. Un uptime supérieur à quelques heures après un déploiement et l'absence d'erreurs dans les logs sur cette période sont de bons indicateurs de stabilité.

Quelle est la différence entre openclaw prod et une instance de dev ?

En dev, OpenClaw tourne en mode permissif — logs verbeux, redémarrage manuel, config volatile. En production, trois choses changent : la supervision automatique (systemd ou Docker restart: always), le versionning strict de la config, et la présence d'un health check actif. L'environnement de prod doit être reproductible à partir du dépôt git de configuration en moins de 15 minutes.

Comment déployer openclaw en production sans interruption de service ?

Si votre infrastructure le permet, utilisez deux instances derrière un load balancer ou un reverse proxy (Nginx, Caddy). Mettez à jour l'une des instances, vérifiez le health check, basculez le trafic, puis mettez à jour la seconde. Pour une instance unique, la coupure est inévitable — minimisez-la en préparant l'image à l'avance et en exécutant la mise à jour en heure creuse.

Que faire si openclaw ne répond plus au health check ?

Vérifiez d'abord les logs (journalctl -u openclaw -n 100 ou docker compose logs openclaw --tail=100). Les causes les plus fréquentes sont : OOM killer (vérifiez dmesg | grep -i kill), erreur de lecture de la config au démarrage, ou credential expiré sur un connecteur. Si le diagnostic prend plus de deux minutes, déclenchez le rollback et diagnostiquez à froid.

Comment tester un health check openclaw avec curl ?

curl -sf http://localhost:3100/health && echo "OK" || echo "FAIL"

L'option -f fait échouer curl si le code HTTP est >= 400. Ajoutez -w "\nHTTP %{http_code}\n" pour afficher le code de retour explicitement. Intégrez cette commande dans vos scripts de déploiement comme gate de validation.

Articles liés

Mettre OpenClaw en production est une étape, pas une destination. La configuration initiale, la sécurisation de l'accès et l'automatisation des tâches SEO constituent les trois piliers d'une instance mature. Si votre instance tourne de façon stable, l'étape suivante logique est de l'exploiter pleinement pour générer de la valeur métier.

Votre instance tourne en production ? Découvrez comment automatiser votre SEO avec OpenClaw et commencer à générer de la valeur.

• Installer OpenClaw sur un VPS — guide pas à pas
• Sécuriser OpenClaw avant la mise en production
• Configurer OpenClaw : variables d'environnement et options avancées
• Automatiser son SEO avec OpenClaw
• OpenClaw et les agents IA : architecture et cas d'usage