OpenClaw - Partie 01 : Présentation et architecture cible

Introduction

Comme j'ai pu le décrire dans mon article sur les risques de l'IA en entreprise, l'IA est un domaine qui évolue extrêmement vite et à un rythme exponentiel. De simple génération de texte à travers un prompt, nous avons basculé vers ce que l'on aime appelé aujourd'hui l'agentique. La différence provient de la notion d'autonomie associée à une IA incluant une décomposition du problème de départ avec une planification des étapes, le tout associé à l'usage d'outils tiers, permettant à l'IA de s'adapter aux obstacles rencontrés en cours de route. On passe donc de l'usage d'un prompt à l'usage d'un agent.

Définition et caractéristiques d'un agent

On a parfois d'ailleurs tendance à considérer beaucoup trop de choses comme des agents. Globalement un agent peut s'identifier grâce au triptyque Perception - Décision – Action.

Un agent ne peut être réellement qualifié de la sorte que s'il présente les caractéristiques suivantes :

• Autonomie orientée vers un but : vous lui confiez un objectif et c'est à lui de trouver le chemin de résolution associé
• Capacité de planification et de réflexion : l'agent décompose une tâche complexe en sous-tâches. Il « réfléchit » avant de faire, on parle de frameworks ReAct pour Reasoning and Acting
• Utilisation d'outils (Tool Use / Function Calling) : l'agent peut interagir avec son environnement et faire appel à des outils qu'ils lui sont accessibles, comme un shell, un accès internet…
• Mémoire et gestion du contexte : l'agent doit disposer d'une mémoire pour suivre ses actions. Il se base donc sur un contexte associant souvent une base de données vectorielles pour se souvenir des actions passées.
• Autocorrection : l'agent doit analyser la sortie de ses actions, comprendre le résultat et s'adapter en conséquence jusqu'à corriger sa manière de faire si celle-ci se termine en erreur.

Dans cette course à l'agent, un acteur a connu une croissance d'utilisation fulgurante : openclaw.

OpenClaw

Publié en novembre 2025 en tant que projet open source sous le nom de Clawdbot par le développeur autrichien Peter Steinberger, il a rapidement attiré l'attention.

Historique

Peter Steinberger est à l'origine de PSPDFKit, un framework de manipulation de PDF très populaire, intégré dans d'innombrables applications d'entreprises à travers le monde. Au départ, le développement de son agent était un pur projet personnel, bricolé sur son temps libre pour répondre à son propre besoin de se doter d'un assistant IA autonome capable d'exécuter des actions sur sa machine locale. Mais l'engouement communautaire a été tel que Steinberger a été contraint de structurer l'outil et de changer son nom sous la pression d'Anthropic. En effet, l'appellation de départ était un clin d'œil à Claude Code puisque l'agent, dans sa première version, avait été conçu pour s'interfacer avec le moteur LLM d'Anthropic. L'outil a donc été renommé Molbot en janvier 2026, et a continué de connaitre un succès croissant jusqu'à son second renommage OpenClaw indiquant la stabilisation du projet et son côté agnostique, puisque plus dépendant de Claude.

Fonctionnement

OpenClaw agit comme un middleware via un fonctionnement en arrière-plan pour gérer un flux logique d'interaction avec un LLM :

• L'instruction : Vous lui envoyez un message naturel via WhatsApp, Telegram, ou Slack (ex: "Peux-tu vérifier pourquoi mon site web est lent ?").
• La réflexion (API) : OpenClaw envoie ce texte, accompagné du contexte de votre machine ou plutôt du contexte de votre agent, à un modèle de langage distant (via API) ou local (via Ollama).
• L'action locale : L'IA comprend l'intention et renvoie non pas du texte pour vous, mais une commande informatique (ex: un script curl ou une commande shell pour tester le site). OpenClaw exécute cette commande sur votre machine.
• La boucle (Proactivité) : Si la commande échoue, OpenClaw renvoie l'erreur à l'IA pour qu'elle corrige. Une fois le problème résolu, OpenClaw vous envoie un message sur WhatsApp : "C'est bon, j'ai redémarré le serveur de base de données."

OpenClaw embarque plusieurs fonctionnalités :

• Des "Skills" (Compétences) natives : Il est livré avec une cinquantaine d'outils prêts à l'emploi. Il sait manipuler un navigateur web (browser automation), éditer des fichiers locaux, exécuter des scripts Python/Node.js, et utiliser votre terminal. Il est bien entendu possible d'étendre ces skills via des développements de la communauté.
• Une intégration omnicanale : Il embarque de quoi se brancher nativement aux messageries que vous utilisez déjà (WhatsApp, Telegram, Slack, iMessage, Discord).
• Une mémoire persistante : Il se souvient de vos préférences, de l'architecture de vos dossiers et des conversations passées entre différentes sessions.
• Un système de "Heartbeat" (Surveillance) : Il peut agir de manière proactive. Il ne dort jamais, ce qui lui permet de vous notifier si un événement se produit pendant que vous ne travaillez pas.
• Un module de Sandboxing : Des garde-fous pour éviter qu'il ne détruise votre système d'exploitation par erreur.

À l'inverse OpenClaw ne dispose pas de l'Intelligence Artificielle en elle-même. OpenClaw est une "coquille". Il ne contient pas de modèle d'IA natif. Pour qu'il soit intelligent, vous devez lui fournir un accès à un LLM, soit distant soit local.

La base technique

OpenClaw repose sur une base technique exploitant les langages TypeScript et Node.js. Pour les interactions web, on y retrouve Playwright, l'outil open source de Microsoft. Il embarque également une base vectorielle pour la gestion de la mémoire à long terme (ChromaDB ou SQlite avec l'extension vector).

En résumé OpenClaw est une grosse boite à outils permettant de créer tout un contexte d'exécution autonome propre au lancement d'un agent dont le cerveau sera un LLM choisi par l'utilisateur. Une sorte de code Claude, personnalisable à l'infini et ouvert à différents modèles de langage, et non limité au code.

La sécurité

Le plus gros problème d'Openclaw et qui a fait beaucoup de bruit est sa sécurité. Comme on l'a vu dans l'historique, le projet de départ n'avait pas du tout vocation à être un standard pour l'exécution des agents et a d'abord été développé comme projet personnel d'un développeur pour répondre à ses propres besoins. Il n'a donc pas été pensé au départ pour pouvoir être déployé à grande échelle, qui plus est dans des contextes critiques.

Et pourtant, l'engouement pour la mode et la hype entourant l'agentique ont fait que beaucoup de gens, pas nécessairement bien formés, ont déployé l'agent à tour de bras sans se préoccuper des questions de sécurité. Bien que la situation s'améliore, l'installation ne se fait pas à travers un simple exe, et, si on ne fait pas attention, on peut transformer OpenClaw en une véritable bombe à retardement pouvant accéder à tout votre écosystème personnel pour y exécuter tout un ensemble d'actions. Sans compter, les pirates qui ont très vite tiré parti du phénomène pour proposer des skills vérolées ou l'utilisateur étaient invités à renseigner ses données personnelles, ses clefs API et autres logins.

On a vu fleurir des instances d'openclaw sur des VPS non sécurisé ou via de simples commandes distantes il était possible de prompter l'agent et de lui faire faire ce qu'on voulait avec les identités enregistrées par l'utilisateur. Certains ont donc tous simplement, à travers openclaw, exposés leur serveurs et ordinateurs avec tout les identifiants et accès nécessaire pour laisser un attaquant faire toutes les actions autorisées pour le fonctionnement de l'agent.

Des solutions concurrentielles ont émergé en exploitant le manque de sécurité de OpenClaw. L'initiative de Nvidia, Nemoclaw, est un exemple de ces alternatives. Il s'agit d'une version améliorée de OpenClaw qui inclut un pare-feu applicatif permettant un contrôle précis des autorisations et du périmètre d'accès accordé à l'agent. Dans la même veine, on peut évoquer le concept de Nanoclaw, qui utilise la technologie de conteneurisation pour confiner les agents dans des milieux contrôlés.

Si ces alternatives sont très intéressantes, c'est oublié que OpenClaw a lui aussi évolué. Un travail important a été fait sur la sécurité. Bien que l'utilisateur ait encore une très grande part de responsabilité, l'outil intègre la notion de sécurité de manière plus aboutie. On peut citer, par exemple, le partenariat avec VirusTotal pour protéger les skills mises à disposition de la communauté. Personnellement, j'ai essayé nemoclaw comme nanoclaw mais aucun n'a la compatibilité de OpenClaw et la richesse fonctionnelle de ce dernier pour l'instant.

Architecture retenue

J'ai donc décidé de suivre une approche différente.

Dédier une VM à l'installation de multiples agents exécutés par OpenClaw, mais conteneurisés et isoler les uns des autres, comme nanoclaw. De plus, tous les éléments d'authentification critiques nécessaires aux agents seront enregistrés dans l'outil Vault, une référence en matière de gestion des informations sensibles. Je pourrais combiner ainsi la richesse d'openclaw à la sécurité des solutions plus récentes pour créer une véritable plateforme d'agent au sein de mon homelab.

Pour une solution entièrement interne, je vais me fonder sur des llms locaux exécutés par Ollama, un outil que j'ai déjà présenté. Seule l'interaction distante exploitera un logiciel tiers, à savoir Telegram. J'aurais préféré signal mais pour l'instant, c'est un peu trop contraignant.

Je vous propose donc de partir sur une série d'articles détaillant la mise en place de cette architecture. L'objectif consiste à concevoir un premier agent IT-Claw destiné à la surveillance de mon homelab, en particulier de mon cluster Kubernetes. Ce premier agent doit pouvoir donner lieu à une procédure renouvelable pour d'autres agents en conservant cette même logique d'isolation et de sécurité. Attention, je ne garantis pas une solution sans défaut, il est possible que malgré mes efforts des failles restent ouvertes. Je tâcherai de faire au mieux et serai, bien entendu, toujours ouvert à la critique.

Détails des composants

Comme d'habitude, on va commencer par présenter l'architecture à mettre en place et détailler les composants. On va donc déployer une VM sous Rocky Linux 10, prdlinage501, celle-ci sera exécutée sur XCP-ng.

Dans cette machine virtuelle, nous allons installer Vault et activer la fonctionnalité KV (key value) pour stocker des secrets. Cela permettra d'avoir un environnement sécurisé pour stocker les informations sensibles.

Chaque agent IA conteneurisé aura accès à une branche qui lui est propre au sein de ce kV par l'intermédiaire d'un agent conteneurisé Vault (la partie cliente de Vault). C'est un peu le principe du sidecar, c'est-à-dire qu'une instance d'Openclaw se verra exposer les secrets dont elle a besoin grâce à une instance d'agent Vault chargée de communiquer avec la branche du KV contenant les secrets de l'agent IA en question.

C'est Podman qui sera retenu comme moteur de conteneurs. Le fait qu'il soit rootless augmentera encore le niveau d'isolation et de la sécurité.

La gestion des conteneurs sera possible via un compte spécifique sur la machine Linux, soit le user openclaw qui fonctionnera dans son propre home (/var/lib/openclaw). Son home servira aussi d'emplacement racine pour chaque arborescence à monter dans les conteneurs IA ou vault.

En ce qui concerne le premier agent IT-Claw, celui-ci sera exécuté à partir d'une image générée par nous-mêmes et incluant le binaire kubectl. Il pourra ainsi agir sur le cluster Kubernetes.

La configuration de kubectl sera stockée dans Vault et sera associée à un compte de service spécifique disposant uniquement de droits en lecture seule sur le cluster (sauf pour les objets de type « secret k8s » qui lui sera interdit).

Le LLM sera hébergé sur une instance Ollama, qui pourra soit s'exécuter sur mon poste personnel disposant d'un GPU NVIDIA, soit sur un MacBook pro M4, cela permettra également de comparer plusieurs modèles et plusieurs hardwares pour de l'IA locale.

Enfin, un bot Telegram servira d'interface pour interagir avec l'agent IA. La GUI d'Openclaw sera accessible via un reverse proxy NGINX intégrant une authentification de base. (Cette dernière pourra ensuite être liée à une authentification OAUTH2 via un IDP d'entreprise.)

Conclusion

Maintenant qu'on sait où on va, il va falloir se lancer. Mais pour ça il faudra attendre le prochain article nous permettant de mettre en place tous les prérequis et déployer le serveur.