Créer votre propre agent IA comme OpenClaw

Ce qu’est réellement OpenClaw

OpenClaw est un agent IA personnel auto-hébergé. Vous l’exécutez sur votre propre serveur, vous le connectez aux applications de chat que vous utilisez déjà, et il peut exécuter des commandes shell, contrôler un navigateur, lire et écrire vos fichiers et agir sur les messages que vous lui envoyez. Il est distribué sous licence MIT, privilégie l’exécution locale et comptait plus de 380,000 étoiles sur GitHub à la mi-2026, ce qui en fait l’un des projets les plus étoilés de la plateforme. Derrière le bruit médiatique, il s’agit d’un ensemble assez réduit de composants reliés de manière cohérente. Cet article présente ces composants pour vous aider à comprendre comment un outil de ce type est construit et où se situent ses principaux risques.

Une mise en garde s’impose dès le départ, car elle détermine tous les choix de conception présentés ci-dessous. En mars 2026, neuf problèmes de sécurité ont été divulgués dans OpenClaw en l’espace de quatre jours, dont une faille critique d’élévation de privilèges notée 9.9 sur 10 (CVE-2026-32922). Le projet est conçu pour être sécurisé par vos soins, en tant qu’opérateur. Un agent capable d’exécuter n’importe quelle commande est aussi sûr que le serveur sur lequel il s’exécute et que les limites que vous lui imposez. Gardez ce point à l’esprit pendant votre lecture.

Le daemon gateway : un seul processus, à garder privé

Au centre se trouve un processus unique qui s’exécute en continu, généralement appelé gateway. Il constitue le control plane. Il reçoit les messages, détermine les actions à effectuer, exécute les outils, puis renvoie les réponses. Tout le reste s’y connecte.

Le point le plus important concernant le gateway est l’adresse sur laquelle il écoute. Par défaut, OpenClaw le lie à l’adresse loopback, 127.0.0.1, qui n’est donc pas accessible depuis Internet tant que vous ne l’exposez pas explicitement. Laissez cette configuration en place. Ce processus exécute des commandes ; un gateway exposé offre donc à toute personne qui le découvre un point d’accès distant à votre serveur. Lorsque vous devez y accéder depuis votre ordinateur portable, utilisez un VPN ou un tunnel SSH au lieu d’ouvrir un port. Un attaquant ne peut pas exploiter un port auquel il ne peut pas accéder.

Connecteurs de canaux : recevoir un message et renvoyer une réponse

Un agent personnel n’est utile que si vous pouvez lui parler depuis les applications que vous utilisez déjà. C’est le rôle des connecteurs de canaux. Chacun d’eux communique avec une plateforme donnée, comme Telegram, WhatsApp, Slack ou Discord, via l’API de bot ou les webhooks de cette plateforme.

Le fonctionnement est identique pour tous. Le connecteur enregistre un bot auprès de la plateforme, reçoit votre message entrant (en interrogeant la plateforme ou en recevant un webhook qu’elle lui envoie), transmet ce message à la gateway, puis renvoie la réponse de la gateway via la même API. Le connecteur est une fine couche de traduction. Il transforme « un message Telegram est arrivé » en « voici le texte à transmettre à l’agent », puis effectue la conversion inverse. Créer votre propre connecteur consiste principalement à consulter la documentation des bots de la plateforme et à faire correspondre son format de message à celui de la gateway.

Le cerveau et la boucle d’outils

Dans la gateway se trouve la partie qui en fait un agent plutôt qu’un chatbot. C’est une boucle.

Un message arrive. La gateway l’envoie à un modèle de langage avec la liste des outils que le modèle est autorisé à utiliser. Le modèle lit le message et décide : répondre directement ou appeler un outil. S’il appelle un outil, la gateway exécute cet outil, récupère le résultat, puis renvoie ce résultat au modèle. Le modèle examine le résultat et prend une nouvelle décision. Le processus se répète jusqu’à ce que le modèle n’ait plus rien à faire et produise une réponse finale.

Cette boucle constitue le principe d’un agent. Elle est identique, que l’agent fonctionne dans une application de chat ou dans un terminal. Pour savoir comment connecter les outils à cette boucle de manière standard, consultez connecter les outils avec le Model Context Protocol. Pour la partie consacrée au modèle, exécuter le modèle sur votre propre matériel présente l’autre moitié du fonctionnement.

L’ensemble d’outils est le principe central, et le danger

Les outils sont ce qui rend OpenClaw puissant. Un outil peut exécuter une commande shell, piloter un navigateur, ou lire et écrire des fichiers. Donnez-y accès à la boucle décrite plus haut, et elle pourra presque tout faire comme vous au clavier. Cette capacité constitue l’intégralité du produit, mais aussi l’intégralité du risque.

Un agent capable d’exécuter n’importe quelle commande à partir d’instructions reçues dans une application de chat présente une vaste surface d’attaque. Une instruction malveillante, une attaque par prompt injection dissimulée dans une page web consultée par l’outil de navigateur, ou un bug comme les failles de mars 2026 peut transformer « lire mon calendrier » en « supprimer mes fichiers ». Les restrictions ne sont donc pas des options supplémentaires. Exécutez l’agent avec un utilisateur dédié et non privilégié, sans sudo, afin qu’une compromission ne puisse pas être exploitée pour obtenir davantage de privilèges. Placez les outils dangereux derrière une étape d’approbation afin que l’agent demande votre confirmation avant toute opération destructive. Exécutez les outils dans une sandbox afin qu’une commande incontrôlée reste confinée. Isolez la clé API du modèle afin qu’une fuite ne permette pas à un attaquant de prendre le contrôle de votre compte. Pensez aussi aux autres secrets présents sur le même serveur : les véritables points faibles de Vaultwarden sont son jeton d’administration et son fichier de sauvegarde, pas son chiffrement, et un agent disposant d’un accès shell peut atteindre ces deux éléments.

Avant d’exposer quoi que ce soit qui exécute des commandes shell, passez méthodiquement en revue les bases. Générez ici une checklist adaptée à votre serveur, puis suivez-la de haut en bas :

L’exécution avec un utilisateur non privilégié est expliquée en détail dans exécuter des services avec un utilisateur non privilégié, et la procédure complète de configuration sécurisée du projet réel se trouve dans exécuter OpenClaw en toute sécurité sur un VPS.

La mémoire sous forme de fichiers texte

La plupart des utilisateurs s’attendent à ce que la mémoire d’un agent soit stockée dans une base de données. Ce n’est pas le cas pour OpenClaw. Il stocke la mémoire sous forme de fichiers Markdown ordinaires sur le disque, et ce choix mérite d’être repris.

Les fichiers sont simples. Il n’y a aucun schéma à faire migrer, aucun service à maintenir en fonctionnement et aucun langage de requête à apprendre. Leur contenu est consultable : vous pouvez ouvrir le dossier et lire exactement ce que l’agent croit savoir sur vous, corriger une note erronée en modifiant un fichier ou supprimer une mémoire en supprimant le fichier correspondant. Les fichiers sont également portables, car déplacer l’agent vers un nouveau serveur consiste à copier un répertoire. Pour un agent personnel utilisé par une seule personne, un dossier de fichiers texte suffit et rend l’ensemble du système facile à comprendre.

Compétences : un moyen portable d’ajouter des fonctionnalités

Au-delà des outils intégrés, OpenClaw utilise un format de compétence portable afin que la communauté puisse étendre ses fonctionnalités sans modifier son cœur. Une compétence est un ensemble autonome d’instructions et, parfois, de code, qui apprend à l’agent à effectuer une nouvelle tâche. L’agent charge une compétence lorsque la tâche l’exige. La recherche web est généralement la première compétence ajoutée. Diriger cette compétence vers votre propre instance SearXNG évite d’envoyer vos requêtes à une API de recherche commerciale et montre clairement où se situe la limite de confiance d’une compétence, puisque tout ce qu’elle renvoie est du texte écrit par un tiers.

L’intérêt d’un tel format est de rendre les fonctionnalités partageables. Une personne écrit une compétence pour une tâche précise, la publie, puis d’autres l’installent. Cette simplicité a aussi un revers : une compétence contient du code provenant d’un tiers que votre agent exécutera sans hésiter. Il est donc préférable de soumettre tout ce que vous n’avez pas écrit à un scanner de sécurité que vous hébergez vous-même avant de le charger. Si vous développez votre propre agent, définir tôt un format d’extension petit et clair vous évitera d’intégrer ultérieurement chaque fonctionnalité directement dans le cœur.

Votre propre modèle

OpenClaw est indépendant du modèle utilisé. Il ne fournit pas son propre modèle de langage. Il se connecte à celui que vous choisissez, qu’il s’agisse d’une API hébergée ou d’un modèle que vous exécutez vous-même.

Cette séparation a des conséquences sur le coût, la confidentialité et le contrôle. Une API hébergée donne accès aux modèles les plus performants sans matériel à administrer, avec une facturation par token et l’envoi de vos prompts en dehors de votre serveur. Un modèle auto-hébergé, servi avec un outil comme Ollama, conserve chaque message sur votre propre serveur et ne coûte que le matériel et l’électricité, au prix d’un modèle plus petit ou plus lent. Beaucoup de personnes combinent les deux. Si vous voulez conserver un agent totalement privé, auto-héberger le modèle sur votre VPS est ce qui permet de supprimer cette dernière faille, et Hermes Agent est un autre agent auto-hébergé qu’il peut être utile de comparer.

En construire un ?

Vous pouvez construire tout cela. Les composants ne sont pas exotiques : un daemon, quelques connecteurs de chat, une boucle modèle-outils, un dossier de fichiers Markdown et un format de plugin. Il est réellement utile de les comprendre, car cela démystifie chaque agent que vous utiliserez et vous indique précisément où se situe le danger.

Mais pour la plupart des utilisateurs, la réponse honnête consiste à exécuter le logiciel réel et à le sécuriser, plutôt qu’à le réinventer. OpenClaw a déjà résolu la gestion des connecteurs, la boucle d’exécution et le format des skills, et a fait l’objet d’un véritable examen de sécurité. Vous avez intérêt à consacrer vos efforts à ce qui relève réellement de votre responsabilité : installer et sécuriser le service sur votre propre serveur. Si vous préférez d’abord apprendre en suivant cette approche, progresser par étapes dans les concepts est plus efficace que de lire directement le code source de l’agent, car chaque étape vous laisse avec un élément que vous avez réellement construit. Construisez-en un petit pour apprendre. Exécutez ensuite le système réel et sécurisez-le pour l’utiliser.

Les bases générales sont présentées dans construire votre propre agent IA sur un VPS, et construire un agent avec Claude reprend les mêmes idées avec un modèle spécifique comme cerveau.

FAQ

Est-il difficile de créer un agent comme OpenClaw ?

Les différents composants ne sont pas difficiles à créer. Un processus gateway, un connecteur de chat, une boucle modèle-outils et un répertoire de fichiers sont chacun simples à mettre en place. La difficulté consiste à le faire de manière sûre. Un agent qui exécute des commandes shell à partir de messages de chat représente une surface d’attaque importante. Configurer correctement le sandboxing, les permissions et l’exécution avec un utilisateur non privilégié demande plus de travail que de relier les fonctionnalités.

Pourquoi OpenClaw stocke-t-il la mémoire dans des fichiers Markdown plutôt que dans une base de données ?

Parce que, pour un agent personnel utilisé par une seule personne, des fichiers suffisent et sont beaucoup plus simples. Aucun service de base de données n’est nécessaire, la mémoire est facile à lire et à corriger manuellement, et déplacer l’agent vers un autre serveur revient simplement à copier un répertoire. Une base de données devient pertinente à plus grande échelle, mais pas dans ce cas.

Quelle est la partie la plus dangereuse d’un agent IA personnel ?

Ce sont les outils qui lui permettent d’agir : exécuter des commandes shell, contrôler un navigateur et écrire des fichiers. C’est ce qui justifie la création de l’agent, mais aussi ce qui peut vous nuire. L’incident de sécurité d’OpenClaw de mars 2026, avec neuf problèmes en quatre jours, dont une faille critique notée 9.9, montre clairement qu’il faut traiter la couche d’outils avec prudence : exécutez l’agent avec un utilisateur non privilégié, contrôlez les actions destructrices et isolez l’exécution dans un sandbox.

Dois-je disposer de mon propre modèle de langage pour en créer un ?

Non. Les agents comme OpenClaw sont agnostiques vis-à-vis du modèle : vous pouvez donc connecter celui de votre choix. Il peut s’agir d’une API hébergée pour utiliser les modèles les plus performants, ou d’un modèle que vous exécutez vous-même pour préserver totalement la confidentialité. L’auto-hébergement avec Ollama conserve tous les messages sur votre propre serveur, au prix de l’utilisation d’un modèle plus petit.