Au départ, le chantier tenait en deux lignes : simplifier l’installation, refondre l’interface consultable depuis un navigateur. Sept semaines de silence plus tard, OpenClaw ressort avec près de la moitié des pull requests fusionnées depuis la création du projet. Personne n’avait prévu cette version, à commencer par ceux qui la signent.
La version 2.0 du harness (l’enveloppe logicielle qui pilote l’agent et lui ouvre les fichiers, le terminal et les outils) est publiée sous le nom v2026.8.1. Elle agrège plus de 16 000 pull requests venues de 933 contributeurs, dont 569 arrivés pour l’occasion. Le communiqué du projet assume l’enchaînement : nettoyer l’installateur obligeait à toucher au code alentour, puis au processus de publication lui-même, jusqu’à redessiner la quasi-totalité du logiciel. La pause, inhabituelle pour un projet habitué aux publications rapprochées, vient de là. L’équipe avait grossi plus vite que ses fondations techniques.
Deux manières d’écrire une feuille de route
Un éditeur d’agents pour l’entreprise procède exactement à l’inverse. Il collecte les demandes, les arbitre, les range dans un trimestre, puis livre ce qu’il avait annoncé. La feuille de route descend du produit vers les utilisateurs, et sa valeur tient à sa prévisibilité : une direction technique achète un calendrier autant qu’un logiciel.
OpenClaw a laissé le mouvement remonter dans l’autre sens. Ses utilisateurs ne réclament pas une fonctionnalité, ils la poussent, et la version finit par ressembler à la somme de ce qu’ils ont envoyé. Le premier modèle promet la tenue des engagements, le second la vitesse d’adaptation. Aucun des deux ne sait offrir ce que promet l’autre.
Un éditeur classique aurait refusé ce chantier : trop de surface touchée d’un seul coup, trop de contributeurs inconnus, un gel de publication de deux mois impossible à justifier à des clients sous contrat. Le projet ouvert, lui, n’avait de comptes à rendre à personne. Il a encaissé la vague, et il en est sorti avec une plateforme que sa propre équipe n’avait pas dessinée.
L’agent quitte le terminal pour l’établi partagé
Le modèle dominant des agents de développement est resté individuel : un développeur lance un agent dans son terminal, son IDE (environnement de développement) ou une application de bureau, lui ouvre un dépôt et le laisse travailler dans ce périmètre. Tout ce que l’agent accumule meurt avec la fenêtre.
OpenClaw 2.0 déplace ce point d’ancrage. Une session devient un espace de travail persistant : elle survit au terminal comme à l’employé qui l’a ouverte, se partage avec un collègue, se supervise depuis un navigateur et peut tourner sur d’autres machines, y compris dans le cloud. La nouvelle interface de contrôle installe la conversation au centre : fils de discussion en colonne, fichiers, validations, configuration et activité en direct réunis dans un même espace.
Le mode multijoueur en tire la conséquence la plus concrète. Un second utilisateur peut rejoindre une tâche déjà lancée ou reprendre la main sans que l’agent perde le contexte accumulé. Peter Steinberger, créateur du projet, décrit sur X une équipe qui a passé deux mois à « construire OpenClaw avec OpenClaw », migrant vers un environnement partagé où l’agent sait sur quoi travaillent les autres. Les outils cantonnés à une seule machine, écrit-il, ressemblent désormais à des vestiges.
Le mouvement dépasse le logiciel libre : chez Anthropic, Claude Code expérimente l’orchestration de plusieurs sessions réunies en équipe, avec liste de tâches partagée et messagerie directe entre agents. Le sens de la marche, lui, diffère : l’éditeur fait collaborer des agents entre eux, OpenClaw fait entrer plusieurs humains dans la même session.
Pour une organisation, le glissement est net : le contexte d’un agent n’appartient plus à une session personnelle, il devient un actif d’équipe, avec ce que cela suppose de traçabilité et de gouvernance.
Le multijoueur s’arrête à la confiance entre collègues
La mise à jour élargit le modèle de sécurité en proportion : sandboxing (cloisonnement de l’exécution) renforcé, permissions par rôle, contrôles de validation, gestion des secrets, journalisation. Le partage d’une tâche ajoute des demandes d’identifiants masquées, pour éviter qu’un secret atterrisse dans le fil de discussion ou dans le contexte envoyé au modèle. Un proxy optionnel limite l’usage d’un identifiant à des destinations approuvées, et les autorisations se rattachent à une opération précise plutôt qu’à un accès large.
Le projet pose lui-même la limite, et c’est à son honneur : ces contrôles ne constituent pas une isolation conçue pour des utilisateurs mutuellement hostiles. Partager une passerelle entre collègues de confiance ne vaut pas un environnement séparé par client. Des alternatives sont nées de cette inquiétude, NanoClaw en tête, et le désaccord porte sur un seul point : les capacités de cloisonnement existent, l’étanchéité par défaut, non. Une agence qui fait tourner des agents sur les données de plusieurs clients devra continuer à segmenter elle-même.
Migrer sans perdre des mois d’historique
La plomberie, elle, se regarde avant de lancer la mise à jour. Le stockage des sessions abandonne les fichiers plats pour SQLite, et le projet recommande explicitement une sauvegarde complète au préalable : une conversion de base ratée, sur des mois d’historique d’agents, ne se rejoue pas. L’installation, en revanche, se simplifie : elle détecte seule un abonnement ChatGPT ou Claude, une clé d’API ou un modèle exécuté en local, et renvoie les réglages restants à un échange avec l’agent.
L’arbitrage de fond arrive ensuite. Adopter cet outil, c’est accepter que sa surface bouge au gré de ce que 933 contributeurs décident d’y ajouter. La contrepartie de la vitesse est l’instabilité, et elle se paie en configuration versionnée, en projets sensibles cloisonnés, en liste explicite des opérations qui exigent encore une validation humaine.
Il aura fallu sept semaines à une communauté pour refondre un outil d’agents que personne ne lui avait demandé de refondre. Les éditeurs qui vendent aux entreprises regardent ce calendrier avec un mélange d’envie et d’effroi, parce qu’ils savent qu’un client leur pardonnera un trimestre de retard, jamais une refonte non annoncée. Ils devront pourtant expliquer, dans les mois qui viennent, pourquoi leur feuille de route avance moins vite que celle d’un projet qui n’en a pas.
