ai agents30 min de lecture

OpenClaw 2.0 a livré la moitié de tout ce que le projet a jamais fusionné — après sept semaines sans rien publier

Le 31 août 2026, un agent IA open source a publié la v2026.8.1 : plus de 16 000 pull requests de 933 contributeurs, soit environ la moitié de tout ce que le projet a fusionné depuis sa création, après 49 jours de silence délibéré succédant à 106 versions en 230 jours. L'assistant d'installation récupère désormais l'abonnement ChatGPT ou Claude que vous payez déjà, ou détecte vos modèles Ollama locaux. Les sessions sont passées à SQLite et les retours arrière ne sont plus gratuits. Une lecture attentive de ce à quoi ressemble vraiment « l'IA qui vous appartient » — ruptures de compatibilité et réglages encore désactivés compris.

K
Ken Jo
#openclaw#ai-agents#open-source#local-llm#agent-security#multiplayer-ai#bring-your-own-model#ai-tooling

Pendant 230 jours, OpenClaw a publié une version environ tous les deux jours — 106 au total, la plupart arrivant un ou deux jours après la précédente. Puis, à la mi-juillet 2026, tout s'est arrêté. Pendant 49 jours, cet agent IA open source aux 388 419 étoiles GitHub n'a rien publié du tout.

Le 31 août 2026, il a publié la v2026.8.1, et cette version contenait plus de 16 000 pull requests fusionnées provenant de 933 contributeurs, dont 569 n'avaient jamais contribué auparavant. Selon le décompte du projet lui-même, cette seule version porte environ 50 % de toutes les pull requests jamais fusionnées dans OpenClaw.

Le motif est difficile à manquer, et il ne concerne pas vraiment un seul projet. Ces dix-huit derniers mois, la couche modèle s'est ouverte : des poids téléchargeables, des licences lisibles, des prix effondrés. Ce que marque OpenClaw 2.0, c'est la même chose un étage plus haut, à la couche qui décide de ce qu'un modèle a le droit de toucher. Cet article est une lecture attentive de cette version : ce que mesurent réellement les chiffres de vélocité, la configuration « apportez votre propre modèle » qui importe l'abonnement que vous payez déjà, la fonction multijoueur qui s'attaque au passage de contexte, la migration qui peut casser votre installation existante, et les réglages de sécurité encore désactivés. C'est la suite de nos articles sur le modèle furtif qui s'est avéré être GLM-5.3-Flash et sur le téléchargement 27B qui a dépassé le meilleur modèle fermé de février — le même argument, une couche d'abstraction plus haut.

L'essentiel :

  • Le volume est vérifié et considérable. Plus de 16 000 PR, 933 contributeurs, 569 nouveaux, dans une version publiée le 31 août 2026 — environ la moitié du total fusionné depuis la création du projet, après 49 jours sans publication.
  • « L'IA qui vous appartient » a maintenant un sens concret. La configuration guidée réutilise une connexion CLI Codex, ChatGPT ou Claude existante, une clé API collée, une nouvelle connexion fournisseur, ou un modèle Ollama / LM Studio déjà installé — et prouve que le choix sait répondre avant de l'enregistrer.
  • C'est le virage vers la maturité, et il a un coût. Les sessions et les transcriptions sont passées dans SQLite, HEARTBEAT.md n'est plus lu à l'exécution, l'alias deactivate du SDK de plugins a disparu, et revenir en arrière après la migration exige que la CLI actuelle restaure d'abord les artefacts hérités archivés.
  • Une meilleure sécurité n'est pas la même chose que des réglages sûrs par défaut. Le bac à sable et les approbations d'exécution sont livrés désactivés, le Secret Store n'est pas chiffré au repos, et les sessions partagées sont documentées comme n'étant pas une frontière de sécurité.

Graphique de la cadence de publication d'OpenClaw : 106 versions en 230 jours de novembre 2025 à juillet 2026, puis une seule version sur 49 jours contenant plus de 16 000 pull requests de 933 contributeurs et environ la moitié de tout ce qui a jamais été fusionné

Cadence et contenu du cycle 2.0. Chiffres tirés des notes de version et de l'article de blog du projet, 31 août 2026.

Seize mille pull requests, c'est une affirmation sur les gens, pas sur le code

Commençons par ce que ce chiffre n'est pas. 16 000 PR fusionnées ne font pas 16 000 fonctionnalités, et quiconque a observé un dépôt actif sait que l'essentiel de ce volume relève de corrections de documentation, de montées de dépendances, de durcissement de tests et de corrections d'une ligne. Les notes de version le confirment : des sous-sections entières sont des listes d'entrées du type « Corriger la commande de configuration d'intégration » ou « Retirer les soulignements des cartes de session du tableau de bord ».

Ce que ce chiffre mesure réellement, c'est la participation, et c'est la quantité la plus intéressante. 933 personnes ont contribué à cette version et 569 d'entre elles n'avaient jamais rien apporté à OpenClaw auparavant — un taux de primo-contribution de 61 %. Ce ratio est celui d'un projet dont la base de contributeurs s'élargit encore, au lieu de se resserrer autour d'une équipe centrale.

La trajectoire autour est plus raide que la version elle-même. Wikipédia recense le projet à 247 000 étoiles et 47 700 forks au 2 mars 2026. Lorsque nous avons interrogé l'API GitHub le 1er septembre 2026, le même dépôt renvoyait 388 419 étoiles et 81 534 forks — une hausse d'environ 141 000 étoiles et 34 000 forks en six mois, pour un dépôt qui n'existait pas avant le 24 novembre 2025.

2 mars 20261er septembre 2026Évolution
Étoiles GitHub247 000388 419+141 419
Forks47 70081 534+33 834
Issues ouvertes5 949
Jours depuis la première publication98281

Chiffres de mars via l'article Wikipédia sur OpenClaw ; chiffres de septembre récupérés directement depuis l'API REST de GitHub le 1er septembre 2026. Le nombre d'étoiles est un signal de popularité, pas une mesure d'usage.

Cette dernière réserve compte. Les étoiles sont l'approbation la moins coûteuse qui soit : un signet, pas une installation. Nous les citons parce que l'écart dit quelque chose sur l'attention, pas parce que 388 419 personnes font tourner un agent sur leur portable.

Voici le point, et nous marquons le basculement clairement : tout ce qui précède est de la mesure, ce qui suit est notre lecture. Cette version mérite un article parce que, jusqu'ici, l'histoire de l'IA open source était presque entièrement une histoire de poids. Les laboratoires publiaient des modèles ; tout ce qui décidait de ce que ces modèles pouvaient faire — lire vos e-mails, cliquer sur un bouton, écrire à votre frère — restait dans le produit fermé de quelqu'un. Une version à 933 personnes au niveau du harnais est la première preuve solide que la couche agent suit la couche modèle vers l'ouverture — et plus vite que la couche modèle ne l'a fait.

Pourquoi un projet rapide a délibérément cessé d'être rapide

L'écart de sept semaines est le fait le plus citable de cette version et le moins commenté.

L'explication de l'équipe est inhabituellement directe. Dans leur article de publication, ils écrivent que la cadence a ralenti pendant que le développement accélérait : « notre équipe grandissait, et l'augmentation du volume et du rythme de travail a dépassé à la fois les fondations d'OpenClaw et le processus que nous utilisions pour publier, alors nous avons refait les deux en même temps. » Les semaines supplémentaires ont servi à faire en sorte que la version survive au contact des installations existantes, pas seulement des nouvelles.

Lisez cela à côté des 106 versions en 230 jours et vous obtenez le portrait d'une transition très précise. Publier tous les deux jours, c'est ce que fait un projet quand le coût d'une mauvaise version est faible, parce que la configuration de presque personne n'est encore porteuse. S'arrêter 49 jours pour écrire un chemin de migration, c'est ce que fait un projet quand ce n'est plus vrai.

Nous appellerions cela le virage infrastructure : le moment où un outil qui allait vite accumule assez d'utilisateurs réels pour que « aller vite » et « ne pas casser ce sur quoi les gens comptent » cessent d'être compatibles, et où le projet doit choisir. OpenClaw a choisi, publiquement, et les notes de version en portent les reçus : un avertissement stockage-et-rétrogradation en tête de la section installation, une procédure de sauvegarde documentée, et des migrations openclaw doctor --fix pour deux sous-systèmes distincts.

Un petit indice que le processus rattrape encore son retard : les notes de version s'ouvrent sur un avertissement indiquant qu'un paquet publié sous 2026.9.1-beta.1 a été versionné par erreur et correspond en réalité à 2026.8.1-beta.4, et ne doit pas être considéré comme plus récent que la version stable 2026.8.1. Une erreur de versionnement assez sérieuse pour mériter une bannière est exactement le genre de chose que le virage infrastructure est censé éliminer. Ce n'est pas encore fait.

« L'IA qui vous appartient » commence à l'écran de configuration, et ce n'est pas rien

L'expression « l'IA qui vous appartient » est employée à la légère. Dans cette version, elle a un sens précis et vérifiable : la première chose que fait l'installateur, c'est chercher l'accès à l'IA que vous possédez déjà, plutôt que de vous demander d'en acheter davantage.

La configuration guidée accepte quatre sources, dans la même exécution :

  1. Une connexion CLI existante et vérifiée — Codex, ChatGPT ou Claude. Si vous payez déjà un abonnement grand public, l'agent peut s'en servir.
  2. Une clé API collée, pour qui préfère mesurer sa consommation directement.
  3. Une nouvelle connexion fournisseur, pour qui n'a ni l'un ni l'autre. Les nouvelles configurations OpenAI utilisent GPT-5.6 par défaut.
  4. Des modèles installés localement — la configuration analyse la machine à la recherche d'installations Ollama et LM Studio existantes.

Puis vient l'étape que la plupart des parcours d'intégration sautent : elle prouve que le modèle sélectionné sait effectivement répondre avant d'enregistrer ce modèle et ces identifiants. Quiconque a passé vingt minutes à découvrir qu'une clé API enregistrée était limitée au mauvais projet reconnaîtra la valeur de cette vérification.

Le chemin local a aussi eu droit à du travail structurel. node-llama-cpp a été remplacé par un llama-server géré, Gemma 4 est devenu le modèle llama.cpp par défaut selon la RAM disponible, et la fenêtre de contexte par défaut de llama.cpp est passée à 64K. Retenez ce dernier chiffre : 64K tokens de contexte local par défaut, c'est à peu près une transcription de réunion de 90 minutes, sur du matériel qui vous appartient, sans facture au token.

Schéma de la configuration guidée d'OpenClaw montrant quatre sources d'identifiants — connexion CLI Codex, ChatGPT ou Claude existante, clé API collée, connexion fournisseur avec GPT-5.6 par défaut, et modèles Ollama ou LM Studio installés localement — qui alimentent une étape de vérification exigeant que le modèle réponde avant d'être enregistré dans la passerelle

Les quatre sources acceptées par la configuration guidée et l'étape de vérification. Source : notes de version v2026.8.1, 31 août 2026.

Maintenant, comparez cette forme aux écosystèmes d'assistants fermés que la plupart des gens utilisent réellement, car le contraste est l'argument.

Produits d'assistant fermésOpenClaw 2.0
Source du modèleLes modèles maison de l'éditeurVotre abonnement existant, votre clé API ou un modèle local
Lieu d'exécutionLe cloud de l'éditeurUne passerelle sur votre machine, liée au loopback par défaut
Interface principaleL'application de l'éditeurTelegram, Signal, Discord, Slack, iMessage, WhatsApp ou l'application navigateur
Stockage des sessionsLes serveurs de l'éditeurSQLite sur votre disque
Modèle d'extensionUn annuaire validéPlugins, compétences et serveurs MCP que vous installez
Si l'éditeur augmente ses prixVous payez ou vous partezVous pointez la configuration vers un autre modèle

Comparaison structurelle, pas qualitative. Les produits fermés sont souvent mieux finis ; la colonne qui compte ici, c'est la dernière ligne.

Cette dernière ligne est toute la thèse. Dans la colonne fermée, le modèle, l'interface, le stockage et la politique d'extension sont regroupés en une décision unique que vous prenez une fois et ne pouvez pas dégrouper. Dans la colonne ouverte, ce sont quatre décisions distinctes. Rien là-dedans ne garantit un meilleur produit — cela garantit un mode de défaillance différent. Quand un assistant fermé augmente ses prix ou supprime une fonction, vous n'avez aucun coup à jouer. Quand le modèle de votre propre agent devient cher, vous changez un réglage.

La messagerie d'abord est un pari de conception, pas une commodité

La plupart des produits d'IA se logent dans une nouvelle application et espèrent votre visite. Le pari central d'OpenClaw, depuis ses toutes premières versions, est l'inverse : l'agent vit dans les applications de messagerie que vous avez déjà ouvertes.

Cette version approfondit considérablement ce choix. Telegram gagne des messages et des médias plus riches. Slack garde désormais la progression en direct et la réponse finale au même endroit. Discord ajoute des Activities optionnelles et des salons vocaux qui savent qui est présent. Les réponses Signal conservent leur bloc de citation natif à travers la livraison ordinaire, fragmentée, média et durable, et les messages reçus juste avant un plantage peuvent reprendre depuis le stockage local. Sur les canaux pris en charge, les questions à choix unique éligibles s'affichent en contrôles natifs de la plateforme sur Telegram, Discord et Slack plutôt qu'en « répondez 1, 2 ou 3 ».

Sous le vernis se cache une histoire de fiabilité que nous jugeons plus importante. Quand un envoi expire sans résultat confirmé, OpenClaw marque désormais ce résultat comme incertain et peut vous avertir au contact suivant plutôt que de créer un message probablement en double. Quiconque a construit des intégrations de messagerie sait combien de travail ingrat se tient derrière cette phrase, et à quel point l'alternative est désagréable : un agent qui envoie deux fois la même chose à votre collègue parce qu'une socket a hoqueté.

L'illustration que l'équipe donne elle-même est volontairement peu spectaculaire, et c'est pour cela qu'elle porte. Extrait de leur article : faites surveiller par l'agent votre boîte de réception pour les e-mails de l'école de vos enfants et faites-vous envoyer un message Telegram quand quelque chose d'important arrive — un devoir à rendre, une activité à préparer. Une boîte, quelques choses à repérer, une destination. Leur second exemple va un cran plus loin : votre frère envoie un iMessage pour demander quel iPad vous avez acheté pour votre père, et au lieu de fouiller vos e-mails à la recherche de la facture, vous dites à votre Claw que votre frère a écrit et vous lui demandez de trouver la réponse et de la lui envoyer.

Aucun des deux exemples ne fait intervenir un benchmark. Les deux font intervenir un agent qui détient un identifiant que vous lui avez confié, lit quelque chose qui vous appartient et écrit à une personne que vous avez choisie. C'est la vraie catégorie de produit, et elle est plus proche d'« un script doté d'une mémoire et d'un numéro de téléphone » que d'« un chatbot ».

IA multijoueur : le difficile n'a jamais été l'écran, c'était le contexte

La fonction de collaboration phare de la 2.0, ce sont les sessions cloud partagées, et l'équipe reconnaît franchement qu'elles viennent de sa propre douleur. En construisant cette version, elle a confié davantage de travail à ses agents, puis a voulu répartir les tâches, collaborer et parfois passer entièrement la main — pour découvrir qu'« OpenClaw n'avait aucun moyen d'amener un autre membre de l'équipe dans le travail sans perdre ce que le Claw savait déjà ».

Cette phrase nomme un problème bien plus vaste qu'OpenClaw. Appelons-le la falaise de passation : le point où le travail passe d'une personne à une autre, et où tout ce que l'outil avait accumulé — les faux départs, les corrections, la chose que vous lui avez interdite deux fois — bascule dans le vide. Le remplacement, c'est un résumé, et un résumé n'est pas du contexte. C'est un artefact compressé qui préserve les conclusions et jette le raisonnement qui les rendait sûres.

Les sessions cloud partagées attaquent cela de front. Une deuxième personne peut rejoindre un travail en cours ou le reprendre avec le contexte intact, et le propriétaire ou un administrateur choisit lequel des quatre niveaux cette personne obtient : lire, proposer des modifications, travailler dans un brouillon, ou participer directement. Les brouillons se créent et se publient sans course critique, les suggestions conservent leur auteur, et des indices légers de présence et de saisie montrent qui est là sans encombrer une configuration solo.

Le créateur Peter Steinberger a écrit sur X tôt le 31 août 2026 que l'équipe avait passé deux mois sur la mission « construire OpenClaw avec OpenClaw », quittant les harnais de codage locaux individuels pour un environnement d'agents partagé sur team.openclaw.ai. « Le codage multijoueur + une puissance de calcul infinie avec les nœuds et les sessions cloud a changé la donne dans notre façon de construire », a-t-il écrit, ajoutant que les harnais locaux semblent désormais « des reliques du passé ». C'est un fondateur qui décrit son propre produit : pondérez en conséquence. Mais la version existe, et elle a été construite ainsi.

Schéma avant-après d'une passation d'agent : sans sessions partagées, la deuxième personne repart d'un agent vide et le contexte accumulé est perdu ; avec les sessions cloud partagées, les deux personnes travaillent sur une même session au contexte intact, sous quatre niveaux de permission choisis par le propriétaire — lire, proposer des modifications, travailler dans un brouillon, participer directement

La falaise de passation et ce que changent les sessions partagées. La limite documentée figure délibérément dans le schéma.

Voici maintenant la limite honnête, que la documentation énonce clairement et que la plupart des couvertures ont enterrée : ces niveaux de permission ne sont ni de l'isolation multi-locataires ni une frontière de sécurité. Un accès révoqué peut brièvement sembler encore fonctionner jusqu'à ce que l'interface se rafraîchisse ou que la passerelle refuse l'action. Le mode incognito est plus étroit que son nom ne le suggère : la conversation vit en mémoire de processus et disparaît au redémarrage de la passerelle, mais le fournisseur du modèle reçoit toujours chaque message, les outils peuvent toujours écrire des fichiers et atteindre des services externes, des métadonnées d'audit sans contenu subsistent, et celui qui exploite la passerelle peut regarder le travail en direct. Help Net Security a ajouté un détail à connaître avant de déployer cela sur une machine partagée : le démarrage plus rapide repose sur un instantané borné de la transcription, stocké non chiffré dans le profil du navigateur.

L'application navigateur est passée d'accessoire à lieu de travail réel

La Control UI reconstruite a absorbé l'essentiel de l'ingénierie visible, et elle apporte le seul chiffre de performance propre de la version.

Dans un test de chat par défaut simulé face à une passerelle mockée avec 50 ms de latence HTTP/1.1, les requêtes JavaScript sont passées de 140 à 45 et le démarrage d'environ 1,6 seconde à 575 millisecondes — 64 % de requêtes en moins et un temps d'accès au chat 2,8 fois meilleur. Elle se dégrade aussi moins sur une longue session : les panneaux masqués cessent de récupérer des données qu'ils n'affichent pas, l'état conservé est borné, et revenir dans une conversation répète moins de rendu.

Autour du chat, des panneaux ancrés hébergent désormais un éditeur de fichiers de l'espace de travail, un panneau Changes adossé à Git montrant les commits de branche, les modifications de l'arbre de travail, l'état des pull requests et les résumés de CI, un panneau navigateur capable de naviguer, cliquer, saisir, faire défiler, inspecter des éléments et annoter une capture d'écran avant de l'attacher à la conversation, ainsi qu'un terminal web plein écran. Les demandes d'approbation apparaissent dans la conversation qui les a déclenchées, avec un historique glissant de 30 jours, et une commande /btw ouvre une conversation latérale pour qu'une question rapide ne pollue pas la transcription principale.

Les notes de version sont rafraîchissantes de franchise sur les limites de ces panneaux : l'éditeur de fichiers ne peut ni créer ni supprimer de fichiers, le panneau Changes est en lecture seule, et « Create PR » passe la main à GitHub au lieu de soumettre depuis OpenClaw. Nous avons lu beaucoup de notes de version qui auraient décrit ces trois limites comme « ciblées » ou « épurées ». Les énoncer comme des limites est le bon choix et un petit dépôt de crédibilité.

Les sessions sont passées à SQLite, et c'est là que se trouvent les ruptures

C'est la section à lire avant de taper openclaw update.

Les sessions et les transcriptions ne sont plus basées sur des fichiers : elles vivent dans SQLite. Il en va de même pour une longue liste d'autres éléments jusque-là dispersés : identité de l'hôte de nœud et réglages de la passerelle, enregistrements APNs, état de configuration de l'espace de travail, état d'exécution des canaux, identifiants OAuth MCP et état de rafraîchissement, confiance des pairs Reef, et stockage BLOB borné pour les plugins de confiance. Le budget disque par défaut de l'archive de sessions est passé à 10 Gio. Sur le web, macOS, iOS et Android, les conversations adossées à SQLite peuvent désormais revenir à un message utilisateur antérieur, bifurquer la conversation et basculer entre branches conservées — mais ce retour ne change que la branche de transcription et n'annule pas les fichiers, les messages envoyés ni les autres effets de bord des outils.

Le coût, c'est que les retours arrière ne sont plus gratuits. Voici la procédure fixée par les notes de version, dans l'ordre :

  1. Créez une sauvegarde vérifiée avant la mise à jour, via le chemin de sauvegarde documenté, pour protéger l'ensemble de l'état d'OpenClaw — pas seulement les sessions.
  2. Mettez à jour avec openclaw update, qui détecte votre type d'installation (npm, pnpm, Bun ou git), récupère la version, exécute openclaw doctor et redémarre un service de passerelle géré. Utilisez d'abord --dry-run pour prévisualiser.
  3. Si vous utilisez la mémoire QMD, exécutez openclaw doctor --fix. La mémoire intégrée détient désormais le chemin central de recherche et de rappel ; la migration transporte les données prises en charge vers un autre cœur, et le reclassement propre à QMD, l'expansion de requête et la recherche de transcriptions inter-agents sont retirés.
  4. Si vous utilisez HEARTBEAT.md, exécutez openclaw doctor --fix. Les plannings de battement de cœur sont désormais gérés comme des Automations, et OpenClaw ne lit plus HEARTBEAT.md à l'exécution.
  5. Si vous devez un jour revenir en arrière, utilisez la CLI actuelle pour restaurer les artefacts de transcription hérités archivés avant d'installer une version antérieure basée sur des fichiers. Les sessions créées après la migration n'apparaîtront pas du tout dans les versions antérieures.

Les auteurs de plugins ont leur propre liste. Les chemins de SDK retirés de juillet et août sont supprimés, l'alias deactivate est remplacé par gateway_stop, et les clients utilisant les formes bêta v2026.7.2 de question, worker ou session-catalog doivent migrer vers les contrats renommés et aplatis. Le pont de stockage de sessions beta.5 reste disponible jusqu'au 12 octobre 2026 — une fenêtre de dépréciation réelle et datée, ce qui est plus courtois que ce qu'accordent la plupart des projets rapides. Les commandes, arguments, environnements, alias et parseurs personnalisés d'agents.defaults.cliBackends relèvent désormais d'un plugin backend plutôt que de la configuration. Enfin, les arbres de travail gérés suppriment désormais les hooks Git du dépôt sauf si un administrateur exécute délibérément un script de configuration séparé : tout dépôt qui reposait sur des hooks implicites doit déplacer cette configuration vers le chemin explicite.

Rien de tout cela n'est catastrophique. Tout cela relève du genre de chose qui transforme une mise à jour de deux minutes en une soirée de deux heures si vous le découvrez après coup.

La sécurité s'est nettement améliorée et n'est toujours pas active par défaut

C'est la partie où l'enthousiasme doit être discipliné, car un agent capable de lire vos e-mails et d'exécuter des commandes est un objet de risque différent d'un chatbot.

Les vraies améliorations sont réelles et précises. Un nouveau Secret Store local à l'échelle de l'équipe sépare les valeurs protégées des valeurs d'environnement lisibles par l'agent, en prenant en charge les demandes d'identifiants masquées, les références Vault ou 1Password, et la substitution liée à une destination, capable de placer un identifiant protégé dans une requête HTTPS approuvée hébergée par la passerelle sans qu'il apparaisse jamais dans une configuration en clair ou dans du texte visible par le modèle. Les demandes d'identifiants privées permettent à un agent de réclamer un secret via une invite masquée sans que la valeur entre dans l'historique de conversation ni dans le contexte du modèle. La politique réseau bloque désormais par défaut les cibles NAT64 non spécifiées et à usage local, et exige une exception d'hôte exacte pour les destinations de webhooks d'automatisation privées. Le texte renvoyé par la recherche, la récupération, MCP, les plugins et l'outil navigateur est borné, normalisé et explicitement marqué comme contenu externe non fiable avant que le modèle ne le voie. Les sorties terminal et CSV neutralisent les formes couvertes d'injection de séquences de contrôle et de formules. La passerelle se lie au loopback par défaut, la plupart des canaux de discussion répondent à un expéditeur de message privé inconnu par un code d'appairage, et il existe désormais une commande openclaw security audit qui vérifie l'accès entrant, le rayon d'action des outils, l'exposition réseau, l'exposition du contrôle navigateur et les listes d'autorisation de plugins.

Voici maintenant les réserves, chacune tirée de la documentation du projet lui-même et non d'un critique.

Les valeurs du Secret Store ne sont pas chiffrées au repos. Elles dépendent des permissions de système de fichiers du répertoire d'état d'OpenClaw. La substitution liée à une destination ne s'applique qu'aux commandes HTTPS hébergées par la passerelle dont le sous-processus respecte les réglages de proxy — les sockets bruts, les conteneurs, les nœuds distants, les harnais natifs des fournisseurs et le HTTP en clair restent en dehors.

Marquer un contenu comme non fiable ne le rend pas inoffensif. Les notes de version le disent directement : la frontière est rendue explicite, mais « le modèle peut toujours être influencé par du matériel hostile qu'il lit ».

Le bac à sable et les approbations d'exécution sont livrés désactivés. La lecture la plus tranchante de la posture entreprise vient de VentureBeat : la configuration de base d'OpenClaw suppose un opérateur unique de confiance et autorise l'exécution sur l'hôte tant que les administrateurs ne configurent pas de restrictions plus fortes, ce qui explique l'existence d'alternatives orientées conteneur comme NanoClaw. Leur conclusion mérite d'être citée telle quelle : « les entreprises doivent transformer ces primitives en politique. OpenClaw 2.0 ne rend pas automatiquement OpenClaw prêt pour l'entreprise, mais il rend un déploiement OpenClaw de niveau entreprise nettement plus facile dès la sortie de la boîte. »

Sur l'injection de prompt précisément, la documentation d'OpenClaw traite le choix du modèle comme première atténuation et cite une arène participative de 2026 comptant 272 000 attaques sur 41 scénarios d'agents, comptabilisées seulement lorsque l'agent exécutait l'action nuisible et la dissimulait à l'utilisateur : 0,5 % de réussite 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. La même page avertit que des attaquants humains adaptatifs dépassent encore 80 % de réussite face aux meilleures défenses connues, raison pour laquelle la politique d'outils, les approbations d'exécution et le bac à sable restent la couche d'application dure, pas le modèle.

Mettez ces deux chiffres côte à côte et vous obtenez l'état honnête de la sécurité des agents en 2026 : l'injection automatisée à grande échelle est désormais un problème sous les 2 % face à un bon modèle, et un humain déterminé reste un problème à 80 % face à tout. Rien dans cette version ne change le second chiffre.

Actif par défautLivré désactivé — à vous de l'activer
Passerelle liée au loopbackBac à sable
Code d'appairage pour les expéditeurs privés inconnusApprobations d'exécution
Marquage du contenu non fiable en sortie d'outilsMode incognito
Blocage réseau NAT64 et cibles non spécifiéesChiffrement au repos des valeurs du Secret Store (non disponible)
Apprentissage automatique de compétences en auto, nouvelles installations seulementDestinations de webhooks en réseau privé

Compilé à partir des notes de version v2026.8.1 et de la documentation de sécurité d'OpenClaw, consultées le 1er septembre 2026.

Ce qui change vraiment pour quelqu'un qui n'est pas développeur

Retirez les contrats de plugins et la migration SQLite, et il reste une chose qui compte pour les utilisateurs ordinaires : les frictions d'installation ont beaucoup baissé. Si vous voulez parcourir ce chemin vous-même, nous avons écrit un guide de démarrage pas à pas pour débutants qui couvre tout le trajet, du téléchargement à la première conversation.

Le chemin d'installation pris en charge garde désormais l'application ou la commande disponible après la configuration. Une application Mac ouverte depuis le dossier Téléchargements peut proposer de se déplacer elle-même dans Applications, là où les mises à jour et le lancement à l'ouverture de session fonctionnent correctement. Sous Linux et d'autres systèmes Unix, l'installateur rend openclaw disponible dans les nouvelles sessions de terminal sans demander de modifier un fichier de démarrage du shell. iPhone, iPad et Android placent l'appairage et les autorisations là où les gens les attendent. Et il existe désormais un compagnon de bureau Linux avec configuration au premier lancement, contrôles de la barre d'état et du service, Control UI intégrée, liens profonds, démarrage automatique et alertes natives — même si les notes de version signalent elles-mêmes que la disponibilité de ses paquets .deb et AppImage en tant que téléchargements v2026.8.1 « n'a pas encore été vérifiée ».

Les Automations ont eu le même traitement. Le surveillant IMAP fourni permet à un courrier nouveau et authentifié provenant d'une boîte existante de démarrer un agent lecteur restreint sans exposer de hook HTTP — désactivé par défaut, entrant uniquement, exigeant une liste d'expéditeurs autorisés et une authentification, et incapable d'envoyer ou de modifier du courrier. C'est l'exemple des e-mails de l'école tiré de l'article de publication, livré comme une primitive bornée à moindre privilège plutôt que comme un bouton « connectez votre Gmail ». Les automatisations Gmail peuvent désormais découper un lot accepté en une exécution isolée par message et filtrer les messages envoyés et les brouillons.

Nous ne prétendrons pas pour autant qu'il s'agit d'un produit grand public. L'un des mainteneurs d'OpenClaw a été cité disant que si vous ne savez pas exécuter une ligne de commande, le projet est bien trop dangereux pour être utilisé en sécurité, et en mars 2026 les autorités chinoises ont restreint l'usage d'applications OpenClaw sur les ordinateurs de bureau des entreprises d'État et des administrations pour des raisons de sécurité. Ces faits sont au dossier et cette version ne les efface pas. Ce qu'elle fait, c'est relever le plancher : l'écart entre « personne curieuse » et « agent qui fonctionne » se mesure désormais en une configuration guidée plutôt qu'en un fichier de configuration.

Quatre choses que nous n'avons pas pu vérifier

L'affirmation selon laquelle la version « touche chaque partie d'OpenClaw » est le cadrage de l'équipe elle-même, et même si les notes de version couvrent bien l'installation, la messagerie, la mémoire, les compétences, les modèles, les automatisations, les applications navigateur et natives, les plugins et la sécurité, nous n'avons aucun audit indépendant du chiffre de 16 000 PR ni des 933 contributeurs. Les deux viennent du projet.

Les sources divergent sur la date de publication. L'infobox de Wikipédia donne la version stable 2.0 au 30 août 2026, MarkTechPost a publié sa couverture datée du 30 août, et l'objet de release GitHub pour le tag v2026.8.1 enregistre un horodatage de publication au 31 août 2026 à 03h30 UTC. Nous avons retenu le 31 août partout parce que c'est l'artefact de première main ; si vous lisez ailleurs le 30 août, c'est cette divergence.

Le champ licence est incohérent. Wikipédia présente OpenClaw comme sous licence MIT ; l'API GitHub renvoie NOASSERTION pour la licence du dépôt, ce que GitHub indique quand son détecteur n'arrive pas à classer le fichier. Nous n'avons pas tranché quelle source fait autorité et ne fonderions aucune décision de conformité sur l'une ou l'autre sans lire directement le fichier de licence.

La description que fait Steinberger du flux de travail interne — « puissance de calcul infinie », les harnais locaux comme « reliques du passé » — est celle d'un fondateur parlant de son propre produit sur sa propre timeline, publiée le 31 août 2026. Nous la citons parce qu'elle explique l'origine de la fonctionnalité, pas parce qu'elle constitue une évaluation.

En résumé : l'IA open source n'est plus une histoire de poids

Pendant deux ans, « IA ouverte » a voulu dire un fichier téléchargeable. La question intéressante était toujours un étage plus haut : la partie qui détient vos identifiants, lit votre boîte de réception et décide de la suite deviendrait-elle elle aussi quelque chose que l'on peut inspecter, forker et faire tourner soi-même — ou resterait-elle dans le produit de quelqu'un, où le choix du modèle, l'interface et le stockage sont regroupés en une décision à prendre ou à laisser.

Une version avec 933 contributeurs, un assistant d'installation qui lit vos abonnements existants, un chemin de modèle local avec 64K de contexte par défaut et une procédure de rétrogradation documentée, voilà à quoi ressemble la réponse quand elle penche de l'autre côté. Ce n'est pas une réponse polie. Le bac à sable est désactivé, les secrets ne sont pas chiffrés au repos, le partage n'est explicitement pas une frontière de sécurité, et un attaquant déterminé gagne encore quatre fois sur cinq. Mais ce sont désormais des limites publiées, avec des numéros d'issue attachés, ce qui est une situation d'une autre nature que l'ignorance.

La falaise de passation est ce que nous surveillerions ensuite. Les sessions cloud partagées sont la première tentative sérieuse que nous ayons vue pour faire survivre le contexte accumulé d'un agent à un changement d'opérateur, et le fait qu'un projet open source de 933 personnes ait atteint ce problème avant la plupart des assistants fermés vous dit où se situe la vraie frontière. Ce n'est pas la capacité. C'est la continuité.


Ce que Telli.sh apporte : la falaise de passation n'est pas propre aux agents — c'est le plus vieux problème des réunions. L'heure de contexte qui vivait dans la salle s'évapore, et ce qui parvient à la personne absente est un résumé qui a préservé les conclusions et perdu le raisonnement. Telli.sh enregistre la réunion, distingue les intervenants, traduit en direct dans 15 langues et laisse derrière lui une transcription consultable et des notes structurées, pour que la passation transporte le vrai compte rendu au lieu du souvenir compressé de quelqu'un.

Démarrer une note IA en direct

Sources


Retour au blog