OpenClaw change d’échelle. Avec sa version 2.0, la plateforme open source d’agents IA ne se contente plus d’assister un utilisateur isolé : elle introduit des sessions partagées, des rôles d’équipe, une nouvelle interface Web et une gestion plus structurée des secrets afin de devenir un véritable outil collaboratif pour les entreprises.
Mais, cette montée en gamme s’accompagne d’un paradoxe important. OpenClaw propose désormais des mécanismes avancés de sandboxing et de contrôle d’accès, tout en laissant l’isolation des agents désactivée par défaut. Pour une plateforme capable de lire des fichiers, exécuter des commandes et manipuler des identifiants, ce choix mérite clairement l’attention des administrateurs.
OpenClaw 2.0 transforme l’agent personnel en outil d’équipe
La nouvelle version, référencée comme OpenClaw 2.0, représente l’une des plus grosses évolutions du projet. Le développement a mobilisé plusieurs centaines de contributeurs et une quantité considérable de changements de code.
La philosophie évolue surtout en profondeur. Jusqu’ici, OpenClaw était largement pensé comme un environnement personnel dans lequel un utilisateur installait et pilotait ses propres agents. La nouvelle génération veut permettre à plusieurs personnes de travailler autour des mêmes agents, sessions et ressources.
L’une des nouveautés centrales concerne les sessions collaboratives. Plusieurs utilisateurs peuvent reprendre ou poursuivre un même contexte de travail sans devoir repartir de zéro. Pour une équipe de développement, cela peut devenir extrêmement pratique. Un premier collaborateur demande à l’agent d’analyser un problème, un second reprend la session et un troisième peut ensuite poursuivre l’exécution sans avoir à reconstituer tout l’historique.
La session devient presque un document de passation vivant.
Le contexte de l’agent devient lui-même un objet collaboratif
C’est un changement important dans la manière de penser les agents IA. Avec un chatbot classique, la conversation appartient généralement à un utilisateur. Avec OpenClaw 2.0, le contexte peut devenir une ressource de groupe.
L’agent sait ce qui a déjà été tenté, il conserve les décisions prises, il peut retrouver les fichiers utilisés, et il peut poursuivre un workflow là où un collègue l’a laissé. Cette continuité est particulièrement intéressante pour les équipes techniques, où une tâche complexe peut facilement passer d’une personne à une autre.
L’interface Web a été profondément remaniée
OpenClaw introduit également une nouvelle interface navigateur beaucoup plus accessible. Son design reprend les codes devenus familiers des assistants modernes comme ChatGPT : installation, configuration, conversations, gestion des agents. Une plus grande partie de l’expérience peut désormais être pilotée depuis le navigateur.
Ce changement réduit la dépendance à la ligne de commande et élargit potentiellement le public de la plateforme. OpenClaw ne vise plus uniquement les utilisateurs très techniques.
Les entreprises peuvent définir des rôles plus précis
La version 2.0 apporte également des rôles opérateurs nommés. Un administrateur peut déterminer quels utilisateurs ont accès à certains agents, sessions ou privilèges. Il devient ainsi possible de créer des profils correspondant à différentes fonctions dans l’entreprise.
Développeur, opérateur, administrateur, collaborateur limité. Ces rôles peuvent également imposer certaines politiques, notamment l’utilisation obligatoire d’un environnement sandboxé pour les nouvelles sessions.
Mais ces rôles ne constituent pas une isolation de sécurité forte
C’est une nuance particulièrement importante. La documentation d’OpenClaw précise elle-même que les contrôles d’équipe sont conçus pour organiser la collaboration entre des personnes appartenant au même périmètre de confiance. Ils ne sont pas présentés comme une frontière suffisante contre des utilisateurs hostiles.
Autrement dit, deux départements qui doivent être strictement séparés ne devraient pas nécessairement partager la même instance simplement parce que des rôles existent. Même chose pour deux clients différents d’un prestataire.
Pour une véritable isolation, plusieurs instances ou environnements séparés restent recommandés.
OpenClaw devient plus adapté à l’entreprise, mais pas automatiquement multi-tenant
C’est une distinction essentielle pour les responsables IT. Un produit collaboratif n’est pas forcément une plateforme multi-tenant sécurisée. OpenClaw 2.0 peut très bien être utilisé par une équipe dans laquelle tous les membres appartiennent à la même organisation et partagent globalement le même niveau de confiance.
En revanche, héberger plusieurs groupes qui ne doivent jamais pouvoir accéder aux ressources les uns des autres demande davantage de séparation.
Le nouveau système de permissions améliore la gouvernance, il ne transforme pas pour autant une instance OpenClaw en forteresse cloisonnée.
Le sandboxing est la principale protection contre les agents trop puissants
OpenClaw possède justement une fonction destinée à réduire ce risque : le sandboxing. Lorsque le sandboxing est activé, les outils utilisés par un agent peuvent être exécutés dans un environnement isolé.
Cela concerne notamment les opérations sensibles comme : la lecture de fichiers, l’écriture, la modification de fichiers, l’exécution de commandes, et la gestion de processus. L’objectif est de limiter les dégâts si l’agent effectue une action erronée ou interprète mal une instruction.
Et pourtant, le sandboxing est désactivé par défaut
C’est probablement le point le plus controversé de cette version. Dans la configuration standard d’OpenClaw, le mode de sandboxing global reste réglé sur off. Cela signifie qu’en l’absence de configuration supplémentaire ou de rôle imposant explicitement une sandbox, les outils peuvent s’exécuter directement sur l’hôte.
La documentation le dit clairement : le répertoire de travail par défaut n’est pas une frontière de sécurité. Des chemins absolus peuvent permettre d’accéder à d’autres parties du système si l’isolation n’est pas activée.
Pour un environnement personnel contrôlé, cela peut être un choix de flexibilité. Dans une entreprise, le risque change complètement d’échelle.
Un agent IA avec accès au système n’est pas une application ordinaire
Le problème vient de la nature même d’un agent. Un chatbot traditionnel produit essentiellement du texte. Un agent peut agir, lire un dépôt de code, modifier un fichier, exécuter un script, interroger un service, manipuler des données, ou encore ouvrir un navigateur. Lorsqu’un tel système travaille directement sur l’hôte, une mauvaise décision ne se limite plus à une réponse incorrecte.
Elle peut avoir un impact concret sur la machine.
Le prompt injection rend cette question encore plus sensible
Les agents peuvent également être exposés à des contenus externes. Une page Web, un document, un e-mail, ou encore un dépôt Git, ces contenus peuvent contenir des instructions malveillantes destinées à influencer le modèle.
C’est le problème du prompt injection. Si un agent compromis dispose d’un accès très large au système de fichiers et au shell, l’impact potentiel est évidemment plus important. Le sandboxing ne résout pas entièrement le prompt injection.
Mais, il réduit le périmètre des actions possibles lorsque quelque chose tourne mal.
La sandbox OpenClaw propose pourtant des réglages assez stricts
Lorsque la fonction est correctement activée, OpenClaw offre plusieurs protections intéressantes. L’administrateur peut choisir de sandboxer toutes les sessions ou seulement certaines d’entre elles. L’accès au workspace peut être supprimé, limité en lecture seule ou autorisé en lecture-écriture. Les environnements Docker peuvent également fonctionner avec un système de fichiers racine en lecture seule et sans accès réseau par défaut dans certaines configurations. Les capacités Linux peuvent être retirées.
Ces options permettent de construire un environnement nettement plus restrictif. Le problème n’est donc pas l’absence d’outils de sécurité, c’est le fait qu’ils demandent une configuration volontaire.
Le choix du « sécurisé par défaut » reste discutable
Pour les experts sécurité, c’est précisément là que le débat commence. Une plateforme destinée aux entreprises pourrait adopter la philosophie inverse. Isolation maximale à l’installation, puis ouverture progressive selon les besoins. OpenClaw privilégie davantage la compatibilité et la puissance immédiate. Cette décision peut faciliter l’expérience des utilisateurs avancés.
Mais, elle augmente aussi le risque qu’une équipe déploie le produit rapidement sans mesurer toutes les implications. Dans un environnement professionnel, un réglage par défaut est rarement anodin.
Les secrets bénéficient d’un nouveau système dédié
OpenClaw 2.0 améliore également la gestion des identifiants. La plateforme dispose désormais d’un store d’identifiants partagé au niveau de l’équipe. Les secrets peuvent y être enregistrés sans être directement exposés dans les conversations. Pour les valeurs marquées comme secrets protégés, l’interface et les commandes classiques ne permettent pas simplement de les relire en clair.
L’agent peut utiliser une référence vers le secret plutôt que recevoir directement sa valeur dans son contexte. C’est une amélioration importante par rapport à une clé API copiée dans un prompt.
Mais, les secrets stockés localement ne sont pas chiffrés au repos
Là encore, une limitation importante doit être soulignée. La documentation indique que les valeurs placées dans le magasin de secrets local ne sont pas chiffrées au repos. Elles sont conservées dans la base SQLite de l’état partagé et protégées essentiellement par les permissions du système de fichiers.
OpenClaw utilise des permissions restrictives sur les fichiers et dossiers concernés. Mais, pour une entreprise exigeant une véritable protection cryptographique des identifiants stockés, cela peut être insuffisant.
OpenClaw recommande lui-même des coffres externes pour les environnements sensibles
Le projet prévoit justement plusieurs alternatives. Les identifiants peuvent être remplacés par des SecretRefs, c’est-à-dire des références vers une source externe. OpenClaw peut notamment travailler avec des gestionnaires comme 1Password ou des solutions de type Vault. La plateforme récupère alors les secrets au moment où ils sont nécessaires plutôt que de les laisser dans la configuration locale.
Cette architecture réduit considérablement la surface d’exposition. Pour un déploiement professionnel, elle semble beaucoup plus adaptée.
1Password bénéficie d’une intégration spécifique
La version 2.0 introduit notamment un broker optionnel pour 1Password. L’idée est de permettre à OpenClaw d’accéder uniquement aux identifiants nécessaires à une tâche donnée. Les administrateurs peuvent contrôler les éléments exposés, les journaux d’audit peuvent également fonctionner sans enregistrer la valeur du secret lui-même.
Pour certains workflows, le gestionnaire peut injecter l’identifiant sans qu’il apparaisse directement dans le chat. C’est exactement le genre d’intégration dont une plateforme d’agents a besoin pour être crédible en entreprise.
Le stockage en clair reste néanmoins possible
OpenClaw conserve aussi des mécanismes de compatibilité moins stricts. La documentation précise que des identifiants peuvent encore être stockés directement dans certains fichiers ou profils. Le mode d’installation par défaut peut notamment persister certaines clés API sous forme de valeurs classiques plutôt que de références vers un coffre.
Les outils d’audit peuvent rechercher ces résidus. Mais là encore, la sécurité optimale demande une action de l’administrateur. Cette philosophie revient régulièrement dans OpenClaw 2.0 : les bonnes protections existent, mais elles ne sont pas toujours celles qui s’activent automatiquement.
La plateforme dispose désormais d’outils d’audit
Il serait injuste de présenter OpenClaw comme indifférent au problème. Le projet fournit plusieurs commandes permettant d’auditer la configuration de sécurité. Les administrateurs peuvent rechercher des secrets encore présents en clair, ils peuvent effectuer des vérifications plus approfondies sur le Gateway et ils peuvent également appliquer certains correctifs ou examiner les paramètres effectifs.
C’est précieux pour les équipes DevOps. Mais, ces outils supposent encore une fois que quelqu’un pense à les utiliser.
Le nouveau modèle d’entreprise exige donc une vraie administration
OpenClaw 2.0 n’est pas un produit que l’on devrait installer sur un serveur puis ouvrir immédiatement à toute une organisation. Un déploiement sérieux demande de réfléchir à plusieurs éléments. Quels agents peuvent exécuter du code ? Quels dossiers sont accessibles ? Quels utilisateurs appartiennent réellement au même périmètre de confiance ? Quels secrets doivent rester dans un coffre externe ? Quelles sessions nécessitent une sandbox ? Quels outils doivent être désactivés ? La réponse dépend de l’entreprise, mais ces questions doivent être posées avant la mise en production.
Il vaut mieux traiter un agent comme un utilisateur privilégié
C’est probablement la meilleure approche conceptuelle. Un agent IA capable d’exécuter des commandes doit être considéré comme un compte technique doté de permissions. Et comme tout compte technique, il devrait fonctionner avec le minimum de privilèges nécessaire.
Pas d’accès au répertoire personnel entier si seul un dépôt Git est nécessaire, pas d’accès réseau complet lorsqu’une seule API suffit, pas de clés administrateur lorsqu’un jeton en lecture seule fait l’affaire. L’intelligence du modèle ne remplace pas les principes classiques de cybersécurité. Au contraire, elle les rend encore plus nécessaires.
Le cloud collaboratif augmente mécaniquement la surface d’attaque
Le passage d’une installation personnelle à un environnement partagé change aussi le modèle de menace. Un utilisateur unique possède un périmètre relativement simple. Dès que plusieurs personnes se connectent au même environnement, le nombre de scénarios augmente.
Compte compromis, permission mal configurée, session partagée par erreur, secret accessible à trop de personnes ou encore agent disposant de droits trop importants. Chaque fonction collaborative apporte de la valeur, mais aussi de nouvelles frontières à sécuriser.
C’est un problème classique dans le logiciel professionnel. Une plateforme qui fonctionne immédiatement avec un accès large paraît agréable à utiliser, et une plateforme fortement cloisonnée demande davantage de configuration.
OpenClaw semble avoir choisi de préserver une certaine liberté opérationnelle. Cela correspond bien à ses origines open source et à son public technique. Mais, à mesure que le projet cible des entreprises moins expérimentées avec les agents autonomes, ce compromis devient plus difficile à défendre.
La documentation donne d’ailleurs une recommandation assez claire pour les environnements nécessitant une vraie séparation. Il vaut mieux utiliser des agents ou Gateways distincts avec des outils minimaux. Une équipe interne partageant les mêmes ressources peut fonctionner dans une même instance. Mais des clients distincts ou des équipes manipulant des données strictement cloisonnées devraient bénéficier d’environnements séparés.
Ce principe rappelle davantage l’administration de serveurs que l’utilisation d’un chatbot SaaS. Et, c’est probablement ainsi qu’il faut penser OpenClaw.
OpenClaw 2.0 franchit malgré tout un cap important
Les réserves de sécurité ne doivent pas masquer l’ampleur du changement. Sessions partagées, rôles opérateurs, gestion centralisée des secrets, interface Web plus accessible, installation cloud et permissions plus fines. Toutes ces fonctions rapprochent clairement OpenClaw d’une plateforme réellement exploitable par des équipes professionnelles.
L’agent n’est plus simplement un assistant individuel, il devient une infrastructure collaborative.
C’est là que la prochaine étape semble évidente. OpenClaw a déjà beaucoup des briques nécessaires pour sécuriser correctement un déploiement. Le défi consiste désormais à faire de ces protections le chemin le plus simple, et non une option réservée aux administrateurs qui ont lu toute la documentation.
Une plateforme destinée aux entreprises ne peut pas seulement être sécurisable, elle doit idéalement être difficile à déployer de manière dangereuse.
