OpenClaw : un agent IA autonome aux risques cachés
200 000 étoiles GitHub en quelques mois. Un marketplace de plugins avec plus de 10 000 skills communautaires. Une architecture suffisamment sophistiquée pour que des ingénieurs sérieux la qualifient de véritable percée dans la conception d'IA autonome.
Et 30 000 instances actives exposées sur l'internet public — beaucoup avec des ports par défaut et des identifiants en clair — en ce moment même.
Cette tension résume OpenClaw en une phrase. Et c'est exactement pour ça que j'ai passé la semaine dernière à décortiquer son architecture, lire les divulgations de sécurité, et comprendre ce que signifie réellement un « usage sûr » par rapport à ce que les gens font en pratique.
Voici mon avis honnête en tant que quelqu'un qui construit des systèmes IA professionnellement : la conception d'OpenClaw est réellement impressionnante. Les décisions que l'équipe a prises autour de l'isolation des sessions, de l'architecture mémoire et de l'exécution des skills empruntent des patterns aux systèmes d'exploitation et aux bases de données — pas au playbook classique des startups IA du type « on fait marcher d'abord, on s'inquiète du reste après ». Ce sont de bonnes idées implémentées avec soin.
La situation sécuritaire, c'est une autre histoire. En janvier, une vulnérabilité critique permettait à n'importe quelle page web malveillante de détourner silencieusement ton token d'authentification en exploitant l'absence de vérification d'origine sur les websockets. Une campagne coordonnée a semé le marketplace de plugins avec des malwares ciblant les clés cryptographiques et les identifiants d'agent. Meta a interdit l'outil en interne.
Ce ne sont pas des problèmes marginaux. C'est l'écart entre « architecturalement élégant » et « prêt pour un déploiement sans supervision sur ta machine personnelle ».
Comprendre les deux côtés — la sophistication et l'exposition — c'est le sujet de cet article. Si tu es développeur IA ou un builder soucieux de la sécurité qui évalue des agents autonomes, tu as besoin du tableau complet. Pas juste la démo. Pas juste la liste des CVE. Les deux.
Ce qu'est OpenClaw — et pourquoi c'est différent de tous les outils IA que tu as utilisés
Tous les outils IA que tu as probablement utilisés fonctionnent de manière réactive. Tu ouvres ChatGPT, tu tapes une question, tu obtiens une réponse. Tu ouvres Copilot, tu écris du code, tu reçois des suggestions. L'IA reste en veille jusqu'à ce que tu l'invoques explicitement.
OpenClaw n'attend pas.
C'est un agent autonome auto-hébergé qui tourne en continu sur ton appareil — laptop, VPS, Mac Mini, peu importe où tu le déploies — et agit de manière proactive en fonction de déclencheurs. Un email arrive qui correspond à un certain pattern : OpenClaw se réveille, le traite, rédige une réponse, planifie un suivi. Un événement de calendrier est dans quarante-huit heures : l'agent commence à rassembler le contexte pertinent et à préparer des notes de briefing. Un fichier dans un dossier surveillé change : un workflow se déclenche automatiquement.
Il s'intègre avec WhatsApp, Slack, Telegram, Discord, Signal, iMessage, tes clients email, ton calendrier et ton système de fichiers. Pas via des API bancales qui te demandent de configurer des webhooks manuellement — via un serveur gateway local qui agit comme un broker de messages unifié pour l'ensemble.
Cette architecture « toujours active » est ce qui rend OpenClaw catégoriquement différent des outils que la plupart des développeurs connaissent. La comparaison n'est pas avec ChatGPT ou Copilot. C'est plus proche d'avoir un employé junior qui a accès à tous tes canaux de communication et peut agir en ton nom — sans demander la permission à chaque fois.
Cette description devrait immédiatement susciter à la fois de l'enthousiasme et de l'inquiétude. Les deux sont la bonne réaction.
L'architecture : pourquoi les ingénieurs prennent ça au sérieux
Avant les problèmes de sécurité, le design mérite sa propre discussion. Parce que l'équipe a fait des choix que la plupart des projets IA ne font pas — des choix qui montrent une vraie pensée systémique.
OpenClaw repose sur une architecture à quatre couches.
Le Gateway est un serveur websocket local qui agit comme broker de messages et orchestrateur. Chaque plateforme connectée — chaque application de messagerie, chaque client email, chaque intégration — passe par le gateway. Il gère l'authentification, le routage et la coordination entre les autres couches. Pense à lui comme le gestionnaire d'interruptions du noyau pour la pile de communication de l'agent.
La couche de raisonnement héberge le LLM. Mais ce n'est pas un simple pass-through. La couche de raisonnement fusionne les messages entrants avec le contexte système, gère les budgets de tokens à travers l'historique de conversation, et gère la sélection de modèle en fonction de la complexité de la tâche. Les tâches légères sont routées vers des modèles plus rapides et moins coûteux. Les tâches de raisonnement lourdes sont escaladées. Ce n'est pas juste une optimisation de coûts — c'est une décision architecturale qui maintient le système réactif sans épuiser le budget d'inférence sur chaque requête à faible enjeu.
Le système de mémoire stocke l'état dans des fichiers markdown en clair sur le disque. Logs de session, préférences utilisateur, mémoires sémantiques, contexte de tâche — tout ça se trouve dans des fichiers lisibles plutôt que dans une base de données. Le mécanisme de compaction emprunte au write-ahead logging des bases de données et au paging de mémoire virtuelle des systèmes d'exploitation : à mesure que le contexte grandit, les entrées plus anciennes sont compressées et archivées tandis que le contexte récent reste actif. C'est une solution véritablement intelligente au problème du maintien de la continuité de l'agent sur des déploiements de longue durée.
La décision d'utiliser des fichiers markdown au lieu d'une base de données mérite qu'on s'y attarde. Ça garde le système de mémoire lisible par un humain et auditable — tu peux ouvrir un fichier et voir exactement ce que l'agent sait, modifier des entrées manuellement, ou supprimer du contexte que tu ne veux pas conserver. Une base de données traditionnelle serait plus performante à grande échelle, mais le compromis en termes de transparence est raisonnable pour un agent local où la confiance et l'inspectabilité comptent plus que la vitesse de requête. Ce pattern signifie aussi que les sauvegardes de mémoire sont d'une simplicité triviale : copie les fichiers. La restauration est tout aussi simple : restaure les fichiers. Pas de migrations de base de données, pas de casse-têtes de versionnage de schéma.
Les skills et l'exécution, c'est là que l'agent fait réellement des choses. Exécuter des commandes, lancer des scripts, contrôler le navigateur, appeler des API externes. Les skills sont définis dans des fichiers markdown — lisibles, auditables, modifiables. Le marketplace Claw Hub liste plus de 10 000 skills contribués par la communauté, couvrant tout, du tri d'emails à l'automatisation de revue de code.
L'isolation des sessions est gérée via des conteneurs Docker. Chaque canal de communication obtient son propre conteneur, empêchant le contexte de fuiter entre les conversations et imitant le modèle d'isolation de processus des systèmes d'exploitation. Si une session de canal est compromise, elle ne compromet pas automatiquement les autres.
Ce sont des patterns de conception matures appliqués avec soin au contexte d'un agent IA. Le système de mémoire en particulier mérite d'être étudié même si tu ne déploies jamais OpenClaw — c'est une solution pratique à un problème que tout agent IA de longue durée doit résoudre : comment maintenir la continuité sans une croissance de contexte illimitée ?
Mais l'architecture révèle aussi exactement où se trouve la surface d'attaque. Et la surface d'attaque est large.
La vulnérabilité de janvier : comment une page web pouvait prendre le contrôle de ton agent
En janvier, une faille de sécurité critique a été divulguée, illustrant parfaitement le risque.
Le serveur Gateway — le hub par lequel tout transite — ne validait pas les en-têtes d'origine des websockets. Ça paraît technique et abstrait. La conséquence pratique était la suivante : n'importe quelle page web malveillante pouvait inclure du JavaScript caché qui ouvrait une connexion websocket vers ton Gateway local et détournait tes tokens d'authentification.
Aucun mot de passe requis. Aucune authentification supplémentaire. Visite la mauvaise page et un attaquant obtient le contrôle total à distance de ton instance OpenClaw.
L'attaque ne nécessite pas que la victime fasse quoi que ce soit d'autre que naviguer sur un site web pendant que son instance OpenClaw tourne. Le JavaScript malveillant s'exécute silencieusement dans le navigateur, la validation manquante laisse passer la connexion, et l'attaquant a désormais la capacité d'envoyer des commandes à ton agent — des commandes qui s'exécutent avec tes permissions sur toutes les plateformes intégrées.
Un agent connecté à ton email, ton Slack, ton WhatsApp, ton système de fichiers, exécutant les commandes d'un attaquant. Le rayon de l'explosion est considérable.
Cette vulnérabilité a été corrigée. Mais son existence révèle quelque chose d'important sur l'écart entre l'ambition architecturale et l'implémentation sécuritaire. L'isolation des sessions entre conteneurs a été conçue avec soin. Le point unique de défaillance au niveau du gateway — le composant le plus exposé de tout le système — ne l'a pas été.
Des vulnérabilités supplémentaires divulguées depuis incluent des attaques de type server-side request forgery, path traversal et contournement d'authentification. Ce ne sont pas des cas marginaux obscurs — ce sont les catégories de sécurité fondamentales que tout service accessible par le réseau doit traiter avant le déploiement.
La vélocité de correction s'est améliorée. Le projet est activement maintenu. Mais l'historique compte quand tu évalues s'il faut déployer quelque chose qui a accès à tes communications et tes fichiers.
Le marketplace de plugins : 20 % des 10 000 skills étaient malveillants
C'est la découverte qui m'a véritablement alarmé.
Les audits de sécurité de Claw Hub — le marketplace communautaire de plugins — ont identifié environ 800 plugins malveillants sur plus de 10 000 disponibles. Soit un taux de malware d'environ 20 %, concentré principalement autour d'une campagne coordonnée avec une stratégie de ciblage spécifique.
Les plugins malveillants n'étaient pas du code poubelle aléatoire ou des faux évidents. C'étaient des skills fonctionnels, d'apparence utile, qui en plus extrayaient trois fichiers spécifiques :
openclaw.json— les tokens d'authentification du gatewaydevice.json— les clés cryptographiques utilisées pour l'appairage sécurisésoulm— les définitions de personnalité et de comportement de l'agent
Pourquoi ces trois-là ? Parce qu'avec openclaw.json et device.json, un attaquant a un accès authentifié à ton instance d'agent. Avec soulm, il comprend comment ton agent se comporte et peut formuler des instructions qui s'alignent avec ses patterns de comportement existants plutôt que de déclencher des réponses inattendues.
La sophistication du ciblage — savoir exactement quels fichiers contiennent les identifiants et la configuration qui importent — pointe vers des acteurs qui ont étudié l'architecture du système spécifiquement pour extraire un maximum de valeur d'une compromission.
L'échelle de 10 000 skills rend la vérification manuelle impossible au niveau utilisateur. Parcourir Claw Hub et télécharger des skills qui semblent utiles est exactement le comportement que la campagne a été conçue pour exploiter. La plupart des utilisateurs ne lisent pas le code source d'un skill avant de l'installer. La plupart des utilisateurs font confiance au fait qu'un marketplace avec des milliers de contributions dispose d'une forme de contrôle qualité.
La comparaison avec npm mérite d'être faite explicitement. L'écosystème npm a subi des attaques de supply chain à répétition — des packages malveillants qui semblent légitimes, sont installés par des développeurs qui font confiance au registre, et exfiltrent des identifiants ou installent des backdoors. Le problème du marketplace de skills IA est structurellement identique mais avec un rayon d'explosion significativement plus grand : un package npm malveillant a typiquement accès à ton environnement de développement. Un skill OpenClaw malveillant a accès à tes communications, ton calendrier, tes fichiers, et la capacité d'agir en tant que toi sur chaque plateforme à laquelle l'agent est connecté.
La communauté de sécurité logicielle a passé des années à développer des pratiques autour de npm — outils d'audit, fichiers lock, épinglage de dépendances, scan de registre. Le problème du marketplace de skills d'agents IA en est à peu près au même niveau de maturité que la sécurité npm en 2016. Les attaques sont en avance sur les défenses, et les conséquences d'une attaque réussie sont plus graves que ce que la plupart des développeurs réalisent actuellement.
OpenClaw a depuis introduit un scanner de sécurité intégré — OpenClaw Doctor — qui détecte les politiques risquées, les mauvaises configurations et l'authentification manquante dans les skills installés. C'est une amélioration significative. Mais le taux de base de 20 % de malware dans le catalogue historique signifie que tout skill installé avant les améliorations de sécurité récentes devrait être audité rétroactivement, et non considéré comme sûr.
La leçon pour l'écosystème d'agents IA au sens large — pas seulement OpenClaw — est que les marketplaces de plugins pour agents autonomes nécessitent une posture de sécurité fondamentalement différente de celle des marketplaces de plugins pour logiciels traditionnels. Une extension VS Code malveillante a accès à ton éditeur. Un skill OpenClaw malveillant a accès à tout ce à quoi l'agent est connecté, fonctionnant avec ton identité.
Utiliser OpenClaw sans se brûler : la configuration concrète
Si tu vas expérimenter avec ça — et ça vaut le coup d'expérimenter, l'architecture est réellement intéressante — voici comment faire sans t'exposer aux modes de défaillance évidents.
Ne le lance jamais sur ta machine personnelle. C'est la base. Ton laptop personnel contient des identifiants, des clés, des fichiers sensibles, et un accès direct à tes vrais comptes de communication. Lancer un agent avec un historique documenté de malware ciblant les identifiants sur cette machine n'est pas un risque raisonnable. Utilise un VPS dédié ou une machine isolée.
L'isolation en conteneurs à deux couches est le minimum. Un conteneur pour le gateway, des conteneurs sandbox séparés pour l'exécution des skills. Les conteneurs d'exécution de skills ne devraient avoir aucun accès réseau par défaut (les skills qui ont légitimement besoin d'accès réseau devraient nécessiter une permission explicite), des systèmes de fichiers en lecture seule dans la mesure du possible, et des limites de mémoire qui empêchent les attaques par épuisement de ressources. Le conteneur du gateway et les conteneurs d'exécution de skills ne devraient pas partager un namespace réseau.
Utilise Podman au lieu de Docker. Podman s'exécute en mode rootless — il n'y a pas de processus daemon root qui possède le runtime de conteneur. Si une évasion de conteneur se produit (une classe d'attaque documentée contre les applications conteneurisées), le rayon d'explosion est limité aux permissions au niveau utilisateur du processus qui exécutait Podman, pas root. Pour les déploiements sensibles en termes de sécurité, l'exécution de conteneur en mode rootless est une défense en profondeur significative.
Lie le gateway au localhost uniquement. Le gateway tourne sur le port 18789 par défaut. Ce port ne devrait jamais être directement exposé à internet. Si tu as besoin d'un accès distant à ton agent, mets un reverse proxy devant avec terminaison TLS et authentification — pas du basic auth, quelque chose avec une gestion d'identifiants correcte. Beaucoup des 30 000 instances exposées le sont parce que le gateway a été lié à 0.0.0.0 plutôt qu'à 127.0.0.1 — la mauvaise configuration la plus simple possible.
Lis le code source des skills avant de les installer. Chaque skill est un fichier markdown avec du code embarqué. Ils sont lisibles par un humain. Avant d'installer un skill de Claw Hub, lis-le — cherche spécifiquement les appels réseau externes, les patterns d'accès aux fichiers, et toute logique qui lit les trois fichiers sensibles que j'ai décrits plus tôt. Utilise OpenClaw Doctor comme premier filtre, mais ne considère pas un scan propre comme une garantie. Le scanner détecte les patterns connus comme malveillants ; un attaquant sophistiqué finira par tester des patterns que le scanner ne détecte pas.
Garde la surface de skills minimale. Plus tu installes de skills, plus la surface d'attaque est grande. Commence avec les skills de base dont tu as réellement besoin, vérifie-les soigneusement, et résiste à l'attrait du catalogue de 10 000 options du marketplace. Tu n'as pas besoin de la majorité.
Fais tourner les identifiants après toute installation de skill non vétée. Si tu as installé des skills avant la fin de l'audit du marketplace et que tu n'as pas fait tourner tes tokens openclaw.json et tes clés device.json depuis, fais-le maintenant. Considère que tout skill installé depuis Claw Hub avant les améliorations de sécurité récentes était potentiellement malveillant. Le coût de la rotation d'identifiants est faible. Le coût de fonctionner indéfiniment avec des identifiants compromis ne l'est pas.
Audite régulièrement les logs d'actions de l'agent. L'un des avantages du système de mémoire basé sur le markdown est que les actions de chaque session sont enregistrées dans des fichiers lisibles. Réserve du temps chaque semaine pour examiner ce que l'agent a réellement fait — quelles commandes il a lancées, quels fichiers il a accédés, quels messages il a envoyés ou rédigés. Les anomalies dans ces logs sont le premier indicateur que quelque chose se comporte en dehors de tes paramètres prévus, que ce soit à cause d'un skill compromis ou d'une instruction mal comprise.
L'évaluation honnête : qui devrait vraiment utiliser ça
OpenClaw est le bon outil pour un ensemble restreint de cas d'usage en ce moment.
Les développeurs qui veulent étudier l'architecture d'agents autonomes dans un environnement contrôlé — spécifiquement le système de mémoire et la conception de l'isolation des sessions — tireront une vraie valeur d'une instance locale durcie. La conception du système mérite d'être comprise indépendamment du fait que tu le déploies un jour en production ou non.
Les chercheurs en sécurité ont des raisons évidentes de s'y intéresser. La surface d'attaque est riche et les divulgations sont bien documentées. Comprendre comment ces systèmes échouent est directement applicable à tout projet impliquant des agents autonomes.
Les fondateurs et builders qui évaluent si les agents IA autonomes ont leur place dans leur produit ou leur infrastructure devraient lancer une instance en sandbox et la stress-tester contre le modèle de menace qui correspond à leur cas d'usage. Mieux vaut découvrir les modes de défaillance dans une expérimentation contrôlée qu'en production.
Qui ne devrait pas utiliser OpenClaw en ce moment : quiconque veut le connecter à des systèmes de production, de vrais comptes de communication, ou des fichiers importants, et qui n'est pas prêt à investir dans la conteneurisation et la revue de sécurité que le déploiement exige. L'écart entre « installer et connecter à mon Gmail » et « installer avec une isolation correcte et des skills vétés » est significatif, et la plupart des gens qui l'installent ne comblent pas cet écart.
L'interdiction interne de Meta n'est pas de la prudence arbitraire. Elle reflète une équipe de sécurité qui a examiné l'historique des vulnérabilités et le taux de malware du marketplace de plugins et conclu que le risque n'est pas justifié pour un usage organisationnel. C'est une conclusion raisonnable étant donné l'état actuel du projet.
Rien de tout cela ne signifie qu'OpenClaw est un mauvais projet ou que les agents autonomes sont intrinsèquement trop risqués à utiliser. Cela signifie que ce projet spécifique, à ce point spécifique de son développement, nécessite un déploiement conscient de la sécurité que la plupart des installateurs occasionnels ne fournissent pas.
Ce qu'OpenClaw nous dit sur la direction que prennent les agents IA
La question intéressante n'est pas de savoir si la posture de sécurité actuelle d'OpenClaw est problématique — elle l'est clairement. La question intéressante est ce que l'existence d'OpenClaw, ses 200 000 étoiles et sa sophistication architecturale nous disent sur la direction que prend l'écosystème des agents.
Les agents IA autonomes avec un état persistant, un déclenchement proactif et une intégration profonde dans les systèmes de communication et de fichiers arrivent, que ce soit ou non un projet spécifique qui réussisse la sécurité du premier coup. La demande est claire. L'architecture est prouvée. La pièce manquante est le cadre de sécurité qui rend ces systèmes suffisamment fiables pour un déploiement à grande échelle.
Ce que le problème du marketplace de plugins d'OpenClaw illustre, c'est que le modèle de confiance actuel — des skills contribués par la communauté, la discrétion de l'utilisateur — ne passe pas à l'échelle face au modèle de menace d'un agent qui a accès à tout. L'architecture de sécurité doit être conçue autour de l'hypothèse que les skills seront malveillants, pas de l'hypothèse qu'ils ne le seront pas. Le cadrage des permissions, l'exécution en sandbox, la signature cryptographique des packages de skills et la revue de code obligatoire avant la publication sur le marketplace, voilà la direction à suivre.
La vulnérabilité d'origine websocket illustre une classe de problème différente : l'hypothèse qu'un service local est intrinsèquement protégé parce qu'il est « local ». Les services locaux qui s'authentifient par token et acceptent des connexions sans validation d'origine ne sont pas uniquement locaux. Ils sont accessibles à tout code exécuté dans le navigateur de la machine sur laquelle ils tournent. Pour les agents IA spécifiquement — qui tournent souvent sur la même machine qu'un navigateur — c'est une hypothèse de conception critique à bien poser.
Les équipes qui construisent des agents IA autonomes avec une sécurité de qualité production auront de vrais avantages sur celles qui construisent d'abord et corrigent ensuite. L'architecture d'OpenClaw mérite d'être étudiée. Sa pratique de déploiement, telle qu'actuellement répandue, mérite d'être évitée.
C'est la vraie leçon de 30 000 instances exposées et 800 plugins malveillants.
Travaillons ensemble
Tu cherches à construire des systèmes IA, automatiser des workflows ou faire passer ton infrastructure tech à l'échelle ? Je serais ravi de t'aider.
- Fiverr (builds personnalisés et intégrations) : fiverr.com/s/EgxYmWD
- Portfolio : mejba.me
- Ramlit Limited (solutions entreprise) : ramlit.com
- ColorPark (design et branding) : colorpark.io
- xCyberSecurity (services de sécurité) : xcybersecurity.io
