Il y a quelques mois, j’ai déployé OpenClaw sur mon VPS pour faire tourner un agent IA accessible via Telegram. L’idée : un assistant conversationnel hosté sur mon infra, sans dépendre d’un SaaS, avec un contrôle complet sur le modèle et les données.
Trois mois plus tard, j’ai tout coupé. Voilà pourquoi.
OpenClaw Review : c’est quoi exactement ?
OpenClaw est un framework open source pour déployer des agents IA en self-hosting. Tu branches un modèle de langage (Anthropic, OpenAI ou local), tu écris un system prompt, tu choisis une interface — pour moi un bot Telegram — et tu as ton agent perso qui tourne sur ton serveur.
L’argument de vente est clair : contrôle total sur les données, personnalisation sans limite, pas de plafond d’usage imposé par un SaaS. Sur le papier, c’est exactement ce que cherche n’importe quel dev qui veut sortir de l’écosystème ChatGPT/Claude.ai.
En pratique, c’est plus rugueux.
Le setup technique
J’ai déployé OpenClaw sur un VPS Ubuntu (Hostinger), accès SSH classique. Le setup est propre dans son principe : un fichier YAML pour la personnalité et les paramètres du modèle, un process Node.js qui tourne en arrière-plan, un webhook Telegram pour l’interface. Sur le papier, c’est carré. Dans la réalité, c’est là que les premières surprises arrivent.
Ce qui fonctionne bien
- La flexibilité du system prompt — aucune barrière. Tu peux pousser la personnalisation aussi loin que tu veux, ce que les wrappers grand public ne te laisseront jamais faire.
- Le contrôle des données — tes conversations restent sur ton serveur, pas dans le datacenter d’un tiers. Si la confidentialité est un sujet sérieux pour toi, c’est le seul setup qui tient la route.
- L’intégration Telegram — fluide, stable, et l’API Bot de Telegram est l’une des mieux foutues du marché.
- Le coût marginal — une fois le VPS payé, tu ne paies que les tokens API consommés. Pas d’abonnement caché, pas de palier « premium » qui débloque les vraies features.
Ce qui est plus rugueux
- La gestion de la mémoire — pas de système de mémoire long terme natif digne de ce nom. Tu te retrouves à bricoler avec des fichiers texte ou une base externe pour simuler une continuité entre les sessions. Ce qui devrait être un acquis de base est laissé à ta charge.
- Le monitoring — aucune interface d’admin intégrée. Si le process plante à 3h du matin, tu le sauves quand tu t’en rends compte le lendemain. Pour un outil censé tourner H24, c’est limite.
- Les mises à jour — le repo n’est pas très actif. Tu finis par patcher toi-même les bugs qui traînent. À ce stade, tu es plus mainteneur du framework qu’utilisateur.
Les erreurs que j’ai commises
J’ai pas fait que des choix malins. Avec le recul, voilà ce que je referais différemment.
Erreur 1 — Sous-estimer la charge de maintenance dès le départ
J’ai démarré OpenClaw en pensant que le setup initial était le gros du boulot. Erreur classique. Le vrai coût, c’est la maintenance continue : redémarrer le process après une update système, débugger les timeouts API, surveiller la RAM du serveur. Le setup, c’est 5 heures. La maintenance, c’est toutes les semaines, pour toujours. J’aurais dû chiffrer ce coût opérationnel avant de m’engager.
Erreur 2 — Pas de monitoring dès le premier jour
Pendant plusieurs jours, l’agent était silencieux sans que je le sache. Le process avait planté sans laisser de trace visible et personne ne s’en était rendu compte. La règle est pourtant connue : tout process qui tourne en prod a besoin d’un superviseur. Pm2 avec des logs rotatifs, un healthcheck cron, n’importe quoi. J’ai mis en place une supervision propre une fois la donnée de session déjà perdue — la classe.
Erreur 3 — Trop investir dans la personnalisation avant de valider l’usage
J’ai passé des heures à affiner le comportement de l’agent — le ton, les règles, la gestion des refus — avant d’avoir validé que mon use case tenait la route. C’est le biais classique du builder : on optimise ce qui est fun plutôt que ce qui est critique. Tuner un system prompt, c’est gratifiant. Vérifier qu’on résout un vrai problème, ça l’est moins. Et c’est exactement pour ça qu’on commence par le mauvais côté.
Erreur 4 — Choisir un VPS sous-dimensionné
Mon premier VPS avait 1 Go de RAM. Avec Node.js, le process OpenClaw et les appels API concurrents, c’était mort. Les temps de réponse s’effondraient sous une charge ridicule. Passer à 2 Go a réglé le problème en cinq minutes — mais c’est exactement le genre de truc qu’on aurait dû anticiper en lisant deux articles sur les exigences de Node en prod. Économie de bout de chandelle.
Ce que ça m’a vraiment coûté
Soyons cash sur les chiffres réels, pas le marketing du self-hosting.
Coût infrastructure
- VPS 1 Go RAM (premier mois) : ~4 €/mois — sous-dimensionné, remplacé rapidement
- VPS 2 Go RAM (mois suivants) : ~7-8 €/mois — correct pour le workload
- Je prévoyais d’augmenter à 8GO de RAM pour pouvoir avoir Supabase en parralèle d’OpenClaw. pour 20€ sur Hostinger.
Coût API
- Usage modéré sur Claude Haiku : environ 3 à 6 € par mois selon l’intensité des échanges
- Pic à ~12 € sur un mois de test intensif
- Mon vrai coût en utilisant Opus & d’autres modèles : Près de 50€ d’inference.
Coût en temps — le vrai sujet
- Setup initial : 4-5 heures (installation, config, debug du webhook Telegram)
- Maintenance mensuelle : 2 à 3 heures par mois en moyenne
- Itérations sur le system prompt : 6-8 heures au total
Total sur ~3 mois : une soixantaine d’euros d’infra + API, et une quinzaine d’heures de boulot effectif. Le cash, OK. Les heures, c’est l’arnaque silencieuse du self-hosting : tu paies en temps ce que tu crois économiser en abonnement.
Pourquoi j’ai arrêté OpenClaw
La vraie raison est simple : le rapport effort/valeur n’y est pas.
Maintenir une instance OpenClaw qui tourne, ça veut dire surveiller ton serveur, gérer les pannes, garder la cohérence de la mémoire, patcher les dépendances. Pour un test, ça s’absorbe. Pour un usage sérieux, tu finis par passer plus de temps à maintenir l’infrastructure qu’à exploiter l’agent. À un moment, tu te rends compte que tu n’es plus en train de bosser sur ton produit — tu fais du sysadmin pour un side project qui ne te rapporte rien.
Et surtout : entre 2024 et 2026, les modèles accessibles via API ont tellement progressé que les gains de la personnalisation fine sur OpenClaw sont devenus marginaux. Le contrôle que tu gagnes ne compense plus le temps que tu y laisses. Aujourd’hui, des interfaces comme Comet de Perplexity ou simplement Claude.ai te donnent 90% de ce que tu cherchais à reproduire — sans avoir à toucher à un fichier SOUL.MD.
Ce que j’en retiens
OpenClaw reste un bon terrain de jeu pour comprendre concrètement comment fonctionne un agent IA persistant : la gestion du contexte, le routing des messages, l’injection de mémoire. Si ton objectif est d’apprendre, le ROI est réel.
Mais en 2026, avec la maturité des frameworks d’orchestration et les nouvelles APIs d’Anthropic qui gèrent nativement le contexte étendu, partir de zéro avec OpenClaw sur un VPS n’est plus la voie la plus efficace pour produire quelque chose. C’est la voie pour apprendre, pas pour livrer.
Si tu veux déployer un agent IA custom, commence par te poser la vraie question : tu cherches vraiment à self-host, ou tu cherches juste à éviter les limites des wrappers grand public ? Dans neuf cas sur dix, la deuxième option se règle avec une API et 50 lignes de code, pas avec un VPS.