OpenClaw 2.0 : la refonte simplifie l'entrée, la sécurité reste à la charge de celui qui configure

Pourquoi cette release compte pour les builders

OpenClaw — agent autonome local open sourceLogiciel dont le code source est disponible sous une licence qui autorise étude, modification, redistribution. (MIT, TypeScript) — s'est imposé comme la référence du segment en quelques mois : 247 000 stars GitHub au 2 mars 2026, plus de 370 000 deux mois plus tard, une installation en une commande (npm install -g openclaw@latest), et une intégration native avec plus de 50 canaux de messagerie et de services (WhatsApp, Telegram, Slack, Discord, Signal, iMessage, Matrix). L'agent se branche sur n'importe quel LLMLarge Language Model : modèle de langage entraîné sur d’énormes corpus pour prédire et générer du texte. — Claude, GPT, DeepSeek — et exécute des tâches concrètes : shell, navigation web, lecture/écriture de fichiers, e-mail, calendrier.

La version 2.0, publiée le 30 août 2026, n'était pas prévue comme telle. L'équipe voulait simplifier l'installation et reconstruire l'app navigateur. Le nettoyage a fini par toucher chaque couche du projet — messagerie, mémoire, skills, modèles, automatisations, plugins, sécurité — jusqu'à justifier un changement de version majeure. Le résultat : 16 000 pull requests, soit environ 50 % de tous les PR jamais mergés, portés par 933 contributeurs dont 569 primo-contributeurs.

Pour un builder ou une agence qui évalue un agent local, c'est un signal double : le projet est vivant et massivement contributif, mais la refonte touche tout, ce qui impose de requalifier ses intégrations existantes.

Ce que la 2.0 change concrètement

Une installation qui part de l'existant

Avant la 2.0, l'installation fraîche d'OpenClaw pesait plus de 1 Go avec plus de 300 paquets de dépendances, selon les tests de Firecrawl. La nouvelle approche détecte ce qui est déjà sur la machine — abonnements ChatGPT ou Claude, clés API, modèles locaux — et reporte la configuration avancée après la première conversation. L'idée : arriver plus vite à un Claw fonctionnel, puis le paramétrer en lui parlant.

L'app navigateur comme point d'entrée principal

L'app navigateur est reconstruite comme expérience de premier plan. Elle s'ouvre directement sur une conversation avec le Claw, permet de poursuivre un travail en cours ou de suivre l'exécution d'une tâche en temps réel. C'est là que la plupart des utilisateurs découvrent OpenClaw et ont leur premier échange.

Sessions cloud partagées

Pendant le développement de la 2.0, l'équipe a buté sur un problème concret : impossible de faire collaborer plusieurs personnes sur une même tâche sans perdre le contexte accumulé par l'agent. Les sessions cloud partagées comblent ce manque. Pour une agence, c'est le mécanisme qui rend envisageable un usage en équipe plutôt que strictement personnel.

Le rythme de développement en perspective

Avant cette release, OpenClaw avait livré 106 versions en 230 jours, la plupart espacées d'un ou deux jours. Les sept semaines de silence qui ont précédé la 2.0 sont donc une anomalie assumée : l'équipe a préféré stabiliser une mise à jour massive plutôt que de livrer un upgrade qui casse les installations existantes.

Ce que les chercheurs ont documenté depuis février

La puissance d'OpenClaw — exécution shell, accès fichiers, navigation web, chaînage de skills sans validation humaine à chaque étape — est aussi sa surface d'attaque. Plusieurs sources indépendantes ont documenté des risques concrets depuis février 2026.

Infostealer ciblant les configurations d'agents

En février 2026, Hudson Rock a publié le premier cas observé d'un infostealer récupérant une configuration OpenClaw complète sur un système infecté, selon Malwarebytes. Ce n'est plus seulement les mots de passe du navigateur qui sont visés : c'est l'identité entière de l'agent, ses clés cryptographiques et son historique, transformant un agent compromis en point de pivot pour une prise de contrôle de comptes.

Prompt injection, log poisoning, privilèges excessifs

En février 2026, CrowdStrike a détaillé comment des adversaires peuvent soumettre des instructions malveillantes à des instances OpenClaw exposées, directement ou indirectement via des e-mails ou pages web que l'agent ingère. Les attaques réussies peuvent exfiltrer des données sensibles ou détourner les capacités agentiques pour de la reconnaissance et du mouvement latéral. CrowdStrike indique que sa plateforme Falcon détecte les déploiements OpenClaw et leurs expositions.

En février 2026, Malwarebytes résumait la situation sans détour : traiter OpenClaw comme un outil de production durci relevait du vœu pieux à ce stade. Le 12 février 2026, l'Autoriteit Persoonsgegevens a averti les organisations de ne pas déployer d'agents expérimentaux comme OpenClaw sur des systèmes traitant des données sensibles ou réglementées. L'autorité estimait qu'environ un plug-in sur cinq pouvait contenir du code malveillant, appelait les parents à vérifier les installations présentes sur les appareils familiaux et demandait une clarification au niveau européen sur l'inclusion des agents autonomes dans le périmètre du règlement IA.

En juin 2026, deux équipes ont durci le constat. Imperva a montré que des instructions dissimulées dans des contacts partagés, des vCards ou des épingles de position étaient exécutées par l'agent sans que la victime les voie. Varonis a monté un agent de test sur la plateforme, l'a doté d'une boîte mail de données synthétiques, et l'a vu transmettre à une adresse extérieure de fausses clés AWS et un faux export client — sur la seule foi d'un e-mail entrant en clair.

Ce que ça implique en contexte agence

Dans une agence, l'agent a potentiellement accès aux jetons d'accès de plusieurs clients, aux boîtes mail, aux drives partagés. La culture du « donne-lui accès pour qu'il puisse aider » — que Malwarebytes pointait en février 2026 — multiplie la surface d'exposition. Un déploiement non encadré sur une machine d'entreprise peut, selon CrowdStrike dans son analyse de février 2026, faire d'OpenClaw une porte dérobée IA capable d'exécuter les instructions d'un attaquant.

Ce que la 2.0 change côté sécurité — et ce qu'elle laisse à l'opérateur

Contrairement à ce que laisse penser un billet de blog centré sur l'onboarding, la 2.0 touche bien le modèle de sécurité. Les notes de release et la documentation sécurité, que cette release met en avant, posent trois choses : le choix du modèle est présenté comme la première mitigation contre la prompt injection, chaque gateway définit une frontière de confiance unique, et l'application des règles repose sur la politique d'outils, les approbations d'exécution et le sandboxing. La documentation cite une arène 2026 de 272 000 attaques sur 41 scénarios : le taux de réussite y est de 0,5 % contre Claude Opus 4.5, 1,0 % contre Sonnet 4.5, 1,3 % contre Haiku 4.5 et 8,5 % contre Gemini 2.5 Pro.

Le déplacement est réel mais il a un prix : les défauts sont stricts sur qui peut parler à l'agent — bind en loopback, pairing DM, groupes en allowlist et authentification gateway fail-closed — mais permissifs sur ce qu'il peut exécuter. Le profil par défaut assume un opérateur de confiance (security="full", ask="off") et le sandboxing reste à activer. Un Claw installé via le nouveau parcours guidé n'hérite donc pas automatiquement d'une politique d'exécution restrictive.

Pour une agence, la documentation donne deux gestes concrets. La commande openclaw security audit permet de vérifier la configuration ; avec --fix, elle bascule notamment les politiques de groupe ouvertes en allowlist et resserre les permissions. Et pour plusieurs clients, la réponse n'est pas de partager une même frontière de confiance : la recommandation est d'isoler une gateway par tenant. Les sessions cloud partagées ne constituent pas une frontière de sécurité ; elles sont conçues pour une équipe qui se fait confiance, pas pour cloisonner plusieurs clients.

Ce qui manque encore : aucun benchmarkJeu de référence public ou interne pour comparer des modèles (MMLU, HumanEval, etc.) — à lire avec prudence hors domaine. de performance ou de consommation de ressources n'accompagne la release, et la procédure de migration existe mais reste sommaire pour des installations fortement personnalisées.

Les notes de release complètes sont liées depuis le billet — c'est là qu'il faut chercher les détails techniques.

Hermes Agent et le signal concurrentiel

Quelques semaines après la viralité d'OpenClaw, Nous Research a publié Hermes Agent, un concurrent direct. Selon TechCrunch, Nous Research finalisait en juillet 2026 une nouvelle levée d'au moins 75 millions de dollars, menée par Robot Ventures avec la participation d'USV, pour une valorisation de 1,5 milliard de dollars. Avant ce tour, la société avait déjà levé 70 millions de dollars auprès de Paradigm, Robot Ventures, North Island Ventures, Delphi Ventures, OSS Capital et Balaji Srinivasan.

Hermes cumulait environ 214 000 stars et près de 40 000 forks sur GitHub en juillet 2026. Il partage avec OpenClaw le même format de skills SKILL.md, ce qui en fait un standard de fait émergent pour les agents locaux. Mais les deux projets divergent sur plusieurs points :

• Philosophie : OpenClaw mise sur la largeur d'intégration (plus de 50 canaux de messagerie et de services, écosystème de plugins) ; Hermes se positionne comme agent de code et d'automatisation portable, conçu pour tourner sur un VPS et apprendre de l'usage.
• Apprentissage : Hermes intègre une boucle d'apprentissage automatique à partir de l'utilisation, là où OpenClaw repose sur un système de skills manuellement configurables.
• Modèle commercial : Hermes propose une version cloud hébergée avec des paliers payants de 20 à 200 $/mois, en plus de l'auto-hébergement. OpenClaw reste auto-hébergé pour le cœur de l'agent, les sessions cloud partagées ne servant qu'à la collaboration.

Selon l'analyse Firecrawl de juin 2026, la dynamique communautaire avait évolué : Hermes gagnait en traction soutenue tandis que la croissance d'OpenClaw avait atteint un plateau — un facteur à peser pour qui choisit un agent sur le long terme.