OpenClaw est-il vraiment sécurisé ?

Ce qu’est OpenClaw (d’abord Clawdbot, puis Moltbot, et maintenant OpenClaw), en termes simples

OpenClaw se présente comme un assistant ou un agent IA personnel open source que tu fais tourner sur tes propres appareils. En pratique, tu exploites un petit « système d’agent » joignable depuis des messageries, qui peut utiliser des intégrations et des outils pour faire du vrai travail à ta place.

La promesse et le risque tiennent en une phrase : il ne se contente pas de générer du texte, c’est un logiciel qui peut détenir des secrets (tokens, clés API, identifiants) et exécuter des actions en ton nom.

Le modèle de menace : « local par défaut » ne veut pas dire « sûr par défaut »

L’auto-hébergement change à qui tu fais confiance, pas le fait que tu fasses confiance.

Avec OpenClaw, tu évites de tout confier à un éditeur SaaS, mais tu endosses d’autres responsabilités opérationnelles : sécuriser une interface web, gérer les mises à jour, faire tourner les clés et t’assurer que la machine qui héberge l’agent est durcie. Quand un maillon de cette chaîne est mal configuré, les dégâts peuvent être immédiats, parce que les agents se trouvent généralement tout près des « clés du royaume ».

C’est aussi pour ça que les incidents de sécurité liés aux agents font plus peur que les vulnérabilités applicatives classiques. Si une app de notes fuit, c’est grave. Si un agent fuit, ça peut être grave et actif.

L’injection de prompt : un risque qui ressemble à du phishing, mais qui se comporte comme un logiciel

Voici un exemple concret qui montre pourquoi cette catégorie de risque est différente.

Imagine que tu configures une automatisation pour que, chaque fois qu’un e-mail est classé « client », ton agent rédige une réponse à ta place. Un attaquant peut se faire passer pour un client et glisser dans le corps de l’e-mail des instructions pour exfiltrer des données confidentielles de Notion et les envoyer en réponse, sans confirmation.

La défense n’est pas un prompt magique unique. C’est une question de conception du produit et du système.

Tu réduis ce risque en plaçant des étapes de confirmation avant les actions sortantes, surtout tout ce qui envoie des messages, publie du contenu ou partage des fichiers. Tu le réduis en utilisant des comptes dédiés aux agents, avec le minimum de privilèges, pour qu’un workflow compromis ne puisse pas tout voir. Tu le réduis en évitant les automatisations qui s’exécutent directement sur du contenu externe non fiable, ou en limitant les entrées pour que l’agent ne voie que les champs strictement nécessaires. Tu le réduis avec des listes d’outils autorisés, un périmètre de données strict et un filtrage ou un masquage des sorties, pour que du contenu sensible ne puisse pas être copié par accident vers un canal sortant.

La posture de sécurité d’OpenClaw (et les petites lignes que la plupart des gens ratent)

La documentation de sécurité d’OpenClaw fait deux remarques importantes qu’on survole facilement.

D’abord, l’interface web est prévue pour un usage local et n’est pas durcie pour être exposée publiquement. Ce n’est pas inhabituel pour un outil auto-hébergé encore jeune, mais ça veut dire que « il a une interface web » n’est pas une invitation à le mettre sur une IP publique.

Ensuite, l’injection de prompt est considérée comme hors périmètre. Ce n’est pas choquant non plus vu la difficulté du problème, mais la conséquence pratique est claire : c’est à toi de construire des garde-fous autour des entrées non fiables et de ce que l’agent a le droit de faire.

OpenClaw face à Notis : deux profils de risque par défaut différents

L’argument d’OpenClaw, c’est le contrôle local et la flexibilité de l’open source. La contrepartie, c’est que tu hérites de la posture de sécurité de ta propre installation : ce que tu exposes, ta façon de faire les mises à jour et ta gestion des secrets.

Notis, à l’inverse, est conçu pour ne pas être directement exposé au monde extérieur par défaut, et construit pour que le code et les agents ne puissent pas accéder aux données des autres utilisateurs : il n’agit que pour l’utilisateur qui a donné son accès. Ça n’élimine pas le risque, mais ça en change la forme.

Côté confidentialité et gouvernance, notre position est volontairement explicite, parce que c’est dans le flou que la confiance meurt. « Nous faisons de notre mieux pour respecter les normes du RGPD et ne travaillons qu’avec des fournisseurs conformes au RGPD, en particulier aux exigences de résidence des données dans l’UE. » « Nous n’accédons pas à tes données sans consentement préalable et appliquons un contrôle d’accès strict à notre environnement de production. » « Les tokens sont stockés chiffrés et peuvent être révoqués à tout moment. » « Non, tes données personnelles ne servent pas à entraîner des grands modèles de langage (LLM). » « Quand nous recevons une demande de suppression, nous retirons tes données personnelles de nos systèmes actifs sous 30 jours (le plus souvent en quelques heures). » « Les données peuvent subsister dans des sauvegardes chiffrées jusqu’à 90 jours… » et « Contrôles d’accès stricts… Seul Flo, le fondateur et créateur de Notis, y a accès… ».

Notis vise aussi le chiffrement de bout en bout et ce que nous appelons en interne une « sécurité de niveau mondial », mais la vérité inconfortable, c’est qu’à partir du moment où tu laisses un agent ingérer du contenu externe non fiable, le problème de l’injection de prompt revient. La principale exception pour Notis, ce sont les automatisations déclenchées par un webhook ou par des intégrations, parce qu’elles peuvent ingérer des entrées non fiables. Si tu construis ce genre de workflows, tu as besoin de la même discipline que pour une API publique.

Alors, OpenClaw est-il vraiment sécurisé ?

Assez sécurisé pour la bonne personne avec les bonnes habitudes, et assez fragile pour que de mauvais réglages par défaut fassent mal.

Si tu fais partie de ces builders qui gardent les panneaux d’administration en local, font les mises à jour rapidement, vérifient les extensions, limitent strictement les identifiants et considèrent que tout ce qui vient d’internet est hostile jusqu’à preuve du contraire, OpenClaw peut être une approche puissante.

Si tu comptes le faire tourner avec un panneau de contrôle public, des tokens à longue durée de vie, des permissions larges et des automatisations qui s’exécutent sur du texte non fiable, alors la vague de signalements de janvier 2026 est ton étiquette d’avertissement. Les agents ne tombent pas en panne en douceur : ils cèdent pile à l’endroit où tu as placé ta confiance.

Si tu ne te sens pas capable de gérer tout ça toi-même, tu as probablement intérêt à utiliser un agent comme Notis, où l’essentiel du travail de sécurité a déjà été fait pour toi et où il est bien plus difficile de te mettre par accident dans une situation très inconfortable.