OpenClaw crée par surprise la mise à jour la plus majeure de son histoire

Plus de 16 000 pull requests ont alimenté OpenClaw 2.0, soit environ la moitié des contributions fusionnées depuis la création du projet. Cette accumulation ne correspondait pourtant pas au plan initial. L’équipe voulait surtout alléger l’installation et reconstruire l’interface accessible depuis un navigateur. Chaque correction a révélé une dépendance supplémentaire, jusqu’à toucher la messagerie, la mémoire des agents, les modèles, les automatisations, les plugins et les applications natives.

Cette mise à jour majeure transforme aussi les usages collectifs. Un mode multijoueur autorise plusieurs personnes à intervenir dans une même session, sans effacer le contexte déjà enregistré. OpenClaw renforce parallèlement la gestion des secrets, migre les sessions vers SQLite et accélère fortement son tableau de bord. Le chargement annoncé passe de 1,6 seconde à 575 millisecondes. Ces changements expliquent pourquoi une opération de maintenance ciblée est devenue, par surprise, la révision la plus étendue de l’histoire du logiciel.

OpenClaw 2.0 : une mise à jour majeure née d’une refonte limitée

Le développement d’OpenClaw 2.0 devait répondre à deux problèmes concrets. L’installation comportait trop d’étapes techniques, tandis que l’application web ne reflétait plus les capacités du moteur. Les responsables ont donc entrepris de simplifier la configuration initiale et de reconstruire le point d’accès utilisé par une grande partie des utilisateurs.

Cette intervention a rapidement dépassé son périmètre. L’interface dépendait directement de la gestion des sessions, des modèles et des outils disponibles. Modifier son fonctionnement exigeait donc d’adapter les couches chargées de conserver le contexte, de transmettre les messages et d’exécuter les commandes. La modernisation du programme d’installation a produit un effet comparable sur les mécanismes d’authentification et de détection des fournisseurs d’intelligence artificielle.

Un développement étendu à toutes les couches du logiciel

Selon la présentation d’OpenClaw, la version 2.0 a mobilisé 933 contributeurs, dont 569 participaient au projet pour la première fois. Cette activité a généré plus de 16 000 demandes d’intégration. Le volume représenterait environ 50 % de toutes les pull requests fusionnées depuis les débuts de la plateforme.

Ces chiffres donnent une mesure technique de la refonte. Une pull request peut corriger quelques lignes comme modifier une fonction complète, mais son intégration nécessite toujours une revue, des tests et une validation. Traiter plusieurs milliers de propositions implique donc un travail important sur la qualité du code, les incompatibilités et la documentation.

Le rythme habituel des publications s’est interrompu pendant près de sept semaines. Cette pause a permis de stabiliser des fondations devenues insuffisantes face à l’élargissement de l’équipe et du produit. Les responsables ont revu le processus de livraison lui-même, afin que les versions futures puissent intégrer davantage de contributions sans reproduire le même engorgement.

Pourquoi le nettoyage initial a produit un effet en chaîne

OpenClaw fonctionne comme un environnement d’exécution pour agents d’IA. Une instruction envoyée depuis le navigateur ne reste pas confinée à l’interface. Elle peut appeler un modèle distant, consulter une mémoire, ouvrir un fichier, déclencher une automatisation ou utiliser une compétence installée. Chaque composant partage donc des données avec plusieurs autres éléments du système.

Une nouvelle procédure d’installation devait identifier les services déjà configurés sur la machine. Cette détection concernait les abonnements compatibles, les clés API et les modèles locaux. Il fallait ensuite transmettre ces informations au moteur sans exposer les identifiants dans les conversations. Le chantier a logiquement atteint les mécanismes de sécurité et le stockage des paramètres.

La reconstruction du navigateur a également imposé de normaliser les messages échangés avec l’agent. Un terminal web, un éditeur de fichiers et un inspecteur DOM ne produisent pas les mêmes événements. Leur coexistence demande une architecture cohérente, capable d’ordonner les actions et de préserver leur historique.

Cette surprise relève donc d’une dynamique classique du développement logiciel. Une dette technique reste souvent discrète jusqu’au remplacement d’un composant central. Dès que l’équipe modifie ce composant, les dépendances accumulées apparaissent dans les tests, les interfaces de programmation et les procédures de déploiement.

Une version 2.0 qui dépasse le changement d’appellation

Le numéro 2.0 traduit une rupture architecturale mesurable. La plateforme modifie la persistance des sessions, son expérience de démarrage et son modèle de collaboration. Elle touche également les applications natives, les compétences, la navigation automatisée et le système d’extensions. Il ne s’agit donc pas d’un simple regroupement de correctifs.

Le cas d’OpenClaw rappelle que la création d’un produit open source repose autant sur la maintenance que sur l’innovation visible. Les fonctions spectaculaires dépendent de mécanismes moins exposés : migration des données, compatibilité des formats, tests automatisés et gestion des autorisations. La portée réelle de cette version vient de la coordination de ces éléments dans un même cycle de publication.

Mode multijoueur OpenClaw : collaborer sans perdre le contexte de l’agent

Le mode multijoueur constitue le changement fonctionnel le plus visible d’OpenClaw 2.0. Une deuxième personne peut rejoindre une tâche active, examiner les échanges précédents et intervenir dans le même espace. Elle peut aussi reprendre l’exécution sans recommencer l’analyse ni reconstruire manuellement les informations déjà acquises par l’agent.

Cette continuité répond à une limite fréquente des assistants autonomes. Une session contient progressivement des décisions, des fichiers consultés, des erreurs rencontrées et des préférences opérationnelles. Lorsque la responsabilité change de personne, perdre cet historique entraîne des répétitions et augmente le risque de décisions contradictoires.

Un espace partagé pour les tâches techniques

Dans un projet de développement, un agent peut commencer par analyser un dépôt Git, identifier une régression puis préparer une modification. Un collègue peut rejoindre la session pour contrôler le correctif, consulter les commandes exécutées et demander un test supplémentaire. Le passage de relais conserve alors les éléments nécessaires à la validation.

Le même principe s’applique aux opérations numériques. Une équipe peut demander à OpenClaw de trier des données, produire un rapport ou surveiller un processus automatisé. Si une intervention humaine devient nécessaire, la personne autorisée dispose du contexte opérationnel. Elle n’a pas besoin de copier la conversation dans un autre outil.

Cette logique rapproche OpenClaw des plateformes collaboratives déjà utilisées pour le code et la gestion de documents. La différence tient au rôle actif de l’agent. Celui-ci ne conserve pas uniquement des commentaires : il exécute des actions, accède à des ressources et peut poursuivre un objectif pendant que plusieurs opérateurs supervisent son travail.

Trois garde-fous pour les identifiants et automatisations

Le partage d’une session augmente mécaniquement l’exposition des données sensibles. OpenClaw 2.0 introduit donc des contrôles destinés à réduire le risque de voir un secret enregistré dans le chat ou envoyé au modèle. Les principaux mécanismes couvrent trois situations :

• Les demandes d’identifiants peuvent être masquées, afin qu’un mot de passe ou un jeton ne soit pas écrit directement dans le fil de discussion.
• Un proxy optionnel peut restreindre la substitution d’un secret à une liste de destinations approuvées.
• Une autorisation peut être associée à une opération définie, au lieu d’accorder un accès général à une automatisation récurrente.

Le masquage réduit la présence des secrets dans le contexte transmis au modèle. Cette précaution compte particulièrement lorsque la conversation contient de nombreux messages ou qu’elle reste disponible pendant une longue période. Un identifiant absent du texte ne peut pas être reproduit accidentellement dans une réponse ultérieure.

Le proxy apporte un contrôle réseau complémentaire. Une clé prévue pour un service déterminé peut être injectée uniquement lors d’une requête vers cette destination. Si une commande tente de la transmettre ailleurs, la substitution peut être refusée. L’approche limite les conséquences d’une instruction erronée ou d’un plugin mal configuré.

L’autorisation ciblée répond aux besoins des scénarios répétitifs. Une entreprise peut permettre à l’agent de consulter régulièrement un état précis sans lui ouvrir l’ensemble du système. La permission reste attachée à une action connue, ce qui facilite son audit et sa révocation.

Une collaboration qui ne remplace pas l’isolation

OpenClaw indique que ces protections ne constituent pas une séparation adaptée à des utilisateurs mutuellement hostiles. Une passerelle partagée entre collègues de confiance reste différente d’une infrastructure isolée pour chaque client. Cette distinction doit guider les entreprises qui traitent des données contractuelles, financières ou personnelles.

Les projets sensibles gagnent à utiliser des environnements distincts, avec des secrets séparés et des droits minimaux. Une validation humaine reste pertinente pour les actions irréversibles : publication d’un fichier, suppression de données, paiement ou modification d’une infrastructure. Le mode collaboratif améliore la coordination, mais il ne supprime pas les exigences classiques de gouvernance.

La journalisation prend également davantage d’importance. Une organisation doit pouvoir identifier l’auteur d’une instruction, l’action exécutée par l’agent et les ressources consultées. Sans cette traçabilité, un espace partagé complique l’analyse d’un incident. Avec des journaux structurés, il devient possible de contrôler les opérations et d’ajuster les permissions.

Cette conception illustre l’évolution des agents vers des outils d’équipe. Les assistants individuels fonctionnent autour d’une seule conversation, alors qu’un environnement collectif doit gérer les rôles, les reprises et les approbations. OpenClaw 2.0 inscrit ces contraintes directement dans le produit.

Pour les équipes de programmation, cette approche s’inscrit dans un écosystème plus large où des outils comme OpenAI Codex pour la programmation assistée modifient déjà la revue de code. La spécificité d’OpenClaw réside dans la persistance du contexte et dans la possibilité de partager l’exécution avec d’autres utilisateurs.

Installation d’OpenClaw 2.0 : détection automatique et configuration allégée

L’installation figurait parmi les deux objectifs initiaux de la mise à jour. Les versions précédentes demandaient de sélectionner un fournisseur, de renseigner plusieurs paramètres et de vérifier manuellement certaines dépendances. Ce parcours pouvait convenir aux développeurs habitués aux lignes de commande, mais il freinait les utilisateurs souhaitant tester rapidement un agent local.

OpenClaw 2.0 examine désormais les éléments déjà présents sur la machine. Le programme peut reconnaître une configuration associée à ChatGPT ou Claude, une clé API enregistrée ou un modèle exécuté localement. Les paramètres détectés ne sont plus systématiquement redemandés pendant la première ouverture.

Une configuration initiale adaptée à l’environnement existant

La détection automatique réduit les saisies redondantes. Une personne disposant déjà d’un fournisseur compatible peut démarrer avec cette configuration. Les réglages restent modifiables ensuite, y compris au cours d’un échange avec l’agent. Cette possibilité évite de quitter une tâche pour parcourir plusieurs panneaux techniques.

Le mécanisme doit cependant distinguer disponibilité et autorisation. Trouver une clé sur un ordinateur ne signifie pas que chaque espace de travail peut l’utiliser. Dans une organisation, le déploiement doit donc conserver une politique explicite sur les comptes autorisés, les quotas et les destinations accessibles.

Un poste personnel et un serveur partagé requièrent aussi des traitements différents. Sur une machine individuelle, la détection accélère la prise en main. Sur une infrastructure collective, l’administrateur doit privilégier des variables isolées, des coffres de secrets et des comptes de service. Le confort du démarrage ne doit pas contourner les règles d’accès.

Les modèles locaux trouvent une place plus directe

La reconnaissance des modèles exécutés sur la machine élargit les scénarios hors cloud. Une équipe peut réserver certaines tâches à un moteur local lorsque les données ne doivent pas quitter son réseau. Elle peut garder un modèle distant pour des traitements nécessitant davantage de capacité ou une fonction spécifique.

Cette combinaison demande une définition précise des routes. Les requêtes contenant du code propriétaire ou des documents internes peuvent être dirigées vers l’environnement local. D’autres opérations peuvent utiliser un fournisseur externe après validation. OpenClaw sert alors de couche d’orchestration entre plusieurs moteurs.

Le choix d’un modèle ne dépend pas uniquement de sa qualité linguistique. La mémoire disponible, le temps de réponse, la longueur de contexte et la compatibilité avec les outils comptent aussi. Un petit modèle local peut convenir à la classification de fichiers, tandis qu’une analyse complexe mobilisera une solution différente.

Les interfaces en ligne de commande participent également à cette évolution. Le positionnement de Mistral Vibe CLI montre que l’assistance au développement devient un service intégré au terminal. OpenClaw adopte un périmètre plus transversal, puisqu’il relie modèles, navigateur, mémoire, automatisations et plugins dans un environnement commun.

Une procédure de mise à niveau à préparer

La simplicité du nouvel installateur ne dispense pas de contrôler la migration. Les extensions existantes peuvent dépendre d’anciens chemins, de paramètres renommés ou d’un comportement modifié. Un essai sur une copie de l’environnement reste préférable avant le remplacement d’une instance utilisée en production.

Une procédure méthodique peut suivre plusieurs étapes :

1. Inventorier les modèles, plugins, automatisations et connexions utilisés par l’instance existante.
2. Effectuer une sauvegarde complète des données, des configurations et des secrets nécessaires.
3. Tester la version 2.0 dans un environnement séparé avec une copie contrôlée des sessions.
4. Vérifier les permissions, les destinations réseau et les opérations déclenchées automatiquement.
5. Mesurer le comportement des tâches récurrentes avant d’autoriser les utilisateurs à migrer.

Chaque étape répond à un risque différent. L’inventaire évite d’oublier une dépendance peu visible. La sauvegarde permet un retour à l’état précédent, tandis que l’environnement séparé protège l’activité principale. Les tests d’autorisation contrôlent les effets de la nouvelle gestion des secrets.

Le déploiement progressif convient particulièrement aux grandes équipes. Un premier groupe peut vérifier les parcours essentiels, documenter les écarts et transmettre des consignes internes. Le reste des utilisateurs migre ensuite avec une procédure stabilisée. Cette méthode réduit le nombre d’incidents simultanés.

La simplification d’OpenClaw 2.0 concerne donc surtout l’expérience courante. Elle retire des étapes inutiles lorsque l’environnement contient déjà les éléments requis. Les administrateurs conservent la responsabilité de vérifier les accès, la compatibilité des extensions et le comportement des automatisations.

Migration SQLite : un nouveau socle pour les sessions OpenClaw

OpenClaw 2.0 abandonne le stockage des sessions sous forme de fichiers plats au profit de SQLite. Cette base relationnelle légère fonctionne dans un fichier local et ne nécessite pas de serveur séparé. Elle apporte des transactions, des requêtes structurées et des mécanismes d’indexation mieux adaptés à un volume croissant de conversations.

Les fichiers plats restent pratiques au début d’un projet. Ils sont faciles à lire, à copier et à inspecter avec des outils simples. Leur gestion devient plus délicate lorsque plusieurs processus écrivent simultanément, que les sessions se multiplient ou que le logiciel doit retrouver rapidement une information précise.

Pourquoi SQLite convient au stockage des interactions

Une session d’agent ne contient pas uniquement une suite de messages. Elle peut associer des outils appelés, des fichiers modifiés, des états intermédiaires, des permissions et des métadonnées. Une base permet de relier ces éléments sans charger l’ensemble de l’historique à chaque requête.

Les transactions réduisent aussi le risque d’état partiellement enregistré. Si une opération doit ajouter un message, modifier un statut et consigner un appel d’outil, SQLite peut valider l’ensemble en une seule unité. En cas d’échec, la transaction peut être annulée avant de laisser des données incohérentes.

L’indexation accélère la recherche des sessions par identifiant, date interne, projet ou état. Cette capacité devient utile avec le mode multijoueur, car plusieurs personnes consultent ou reprennent des tâches existantes. Le tableau de bord doit alors retrouver rapidement le contexte concerné sans parcourir chaque fichier.

SQLite bénéficie par ailleurs d’une implantation étendue dans la technologie grand public et professionnelle. Les navigateurs, applications mobiles et outils de bureau l’utilisent pour conserver des données locales structurées. Son format compact correspond à un logiciel qui doit rester simple à installer.

La sauvegarde complète reste indispensable

Le projet recommande de sauvegarder les données avant le lancement de la mise à niveau. La migration transforme le format de persistance et peut devenir difficile à inverser si les fichiers d’origine sont remplacés. Une copie séparée doit donc inclure les sessions, la configuration, les extensions et les éléments nécessaires à leur réouverture.

Une sauvegarde valable doit être testée. Copier un dossier ne garantit pas que les données pourront être restaurées si un processus écrit encore pendant l’opération. Il convient d’arrêter proprement l’instance, de vérifier la taille des fichiers et de tenter une restauration dans un emplacement distinct.

Les organisations soumises à des obligations de conservation doivent examiner le nouveau format. Les politiques de rétention, de suppression et d’export doivent continuer à fonctionner. Une session supprimée depuis l’interface doit suivre les règles internes applicables aux journaux et aux copies de sauvegarde.

La base peut également contenir des fragments sensibles issus des conversations. Son fichier nécessite donc des permissions système adaptées et, selon le contexte, un chiffrement du volume de stockage. SQLite structure les données, mais ne remplace pas les contrôles du système d’exploitation.

Des bénéfices directs pour le mode collaboratif

Le passage au multijoueur rend la cohérence du stockage plus importante. Deux utilisateurs peuvent consulter une même tâche pendant qu’un agent ajoute des événements. Une base transactionnelle fournit un cadre plus robuste pour ordonner les modifications et éviter certaines collisions.

La reprise d’une session devient également plus prévisible. Le logiciel peut charger l’état utile, les actions récentes et les autorisations liées sans reconstruire tout le contexte depuis plusieurs fichiers. Cette organisation soutient la continuité attendue lors d’un transfert entre collègues.

La migration prépare aussi des fonctions d’administration plus fines. Des requêtes structurées peuvent alimenter des vues par équipe, par projet ou par type d’activité. Le produit peut calculer des indicateurs sans analyser manuellement chaque journal textuel. Ces possibilités dépendent toutefois des schémas choisis et des outils d’export disponibles.

La transformation reste invisible pour une personne qui ouvre simplement une conversation. Elle joue pourtant un rôle central dans la stabilité de la version 2.0. Le stockage devient compatible avec une utilisation plus dense, une recherche plus rapide et un accès partagé mieux ordonné.

La réussite de cette évolution se mesure surtout après plusieurs semaines d’exploitation. Les équipes devront surveiller la taille de la base, la durée des sauvegardes et le comportement des accès concurrents. Ces indicateurs permettront d’adapter les procédures de maintenance aux volumes réellement produits.

Nouvelle application web OpenClaw : performances, Git et outils intégrés

L’application web a été entièrement reconstruite pour devenir un espace de travail plus complet. Elle ne sert plus uniquement à envoyer des messages à l’agent. OpenClaw 2.0 y rassemble désormais l’édition de fichiers, le contrôle Git, l’observation des tests d’intégration continue et l’exécution de commandes.

Cette concentration réduit les changements de fenêtre. Une tâche de développement peut commencer par une instruction en langage naturel, se poursuivre dans un fichier puis nécessiter une vérification dans le terminal. L’utilisateur conserve le même contexte visuel pendant que l’agent et les outils manipulent le projet.

Un éditeur natif relié aux actions de l’agent

L’éditeur permet d’ouvrir et de modifier les fichiers depuis le navigateur. Cette fonction facilite la vérification d’un changement généré automatiquement. Une personne peut comparer le résultat avec la demande initiale, corriger une ligne puis relancer les tests sans recourir immédiatement à un environnement externe.

L’intérêt ne réside pas seulement dans l’écriture du code. Les fichiers de configuration, la documentation et les modèles de contenu peuvent être examinés dans le même espace. Le contexte de la conversation reste accessible, ce qui aide à relier une modification à la consigne qui l’a provoquée.

Le suivi Git affiche l’état des fichiers et les informations liées à l’intégration continue. Une équipe peut identifier les éléments modifiés, repérer un test en échec et demander à l’agent d’analyser le journal correspondant. La revue humaine conserve sa place avant la fusion du changement.

Un inspecteur DOM destiné aux tâches sur navigateur

L’inspecteur DOM permet d’annoter des captures d’écran et de cibler des éléments d’une page. Cette fonction améliore la communication avec un agent chargé de modifier une interface. Une annotation visuelle peut désigner un bouton, un formulaire ou un bloc dont le comportement doit être corrigé.

Les instructions visuelles réduisent certaines ambiguïtés du langage. Dire qu’un élément est mal aligné reste imprécis lorsque plusieurs composants se ressemblent. Pointer directement la zone concernée fournit une référence exploitable, associée à la structure du document HTML.

Cette capacité peut servir aux tests de parcours. Un agent ouvre une page, localise un élément, effectue une interaction puis consigne le résultat. L’opérateur observe l’exécution et intervient si le comportement diverge du scénario prévu. Les annotations facilitent ensuite la création d’un rapport reproductible.

Un terminal web en plein écran pour suivre les commandes

Le terminal intégré offre une vue directe sur les processus lancés. Les commandes, erreurs et sorties restent visibles pendant l’exécution. Cette transparence compte lorsque l’agent installe une dépendance, lance une suite de tests ou démarre un serveur local.

Un terminal accessible depuis le navigateur augmente aussi les exigences de sécurité. Les commandes disponibles doivent correspondre aux droits de la session. Une instance exposée à plusieurs personnes doit isoler les projets et limiter les opérations susceptibles d’affecter le système hôte.

Les administrateurs peuvent compléter ces protections par des conteneurs, des comptes restreints et des règles réseau. Une commande exécutée dans un environnement jetable présente moins de risques qu’un accès direct à une machine contenant plusieurs projets. L’interface facilite l’usage, tandis que l’architecture de déploiement détermine le niveau réel de séparation.

Un tableau de bord presque trois fois plus rapide

OpenClaw annonce un passage de 1,6 seconde à 575 millisecondes pour le chargement du tableau de bord. La réduction atteint un peu plus d’une seconde. Sur une ouverture isolée, le gain paraît limité, mais il devient perceptible lors des consultations répétées au cours d’une journée.

Une interface plus rapide améliore surtout la continuité d’usage. Le tableau de bord sert à retrouver une session, observer une tâche ou rejoindre un espace collectif. Chaque attente interrompue ralentit la supervision, particulièrement quand plusieurs opérations sont contrôlées en parallèle.

Cette performance peut provenir de plusieurs optimisations combinées : chargement sélectif des données, composants frontaux révisés et requêtes mieux structurées grâce à SQLite. La mesure annoncée doit néanmoins être comparée dans des conditions similaires, avec un volume de sessions et une configuration réseau équivalents.

La refonte illustre une orientation claire du produit. OpenClaw cherche à devenir un environnement opérationnel central pour les agents, avec les outils nécessaires à la modification, au contrôle et à la collaboration. L’application web matérialise ce changement auprès des utilisateurs, tandis que le nouveau stockage et les permissions soutiennent son fonctionnement.