OpenClaw v2026.10.1 agrège 2425 PR de 402 auteurs, et les utilisateurs sont lassés

OpenClaw a publié la version v2026.10.1. D'après les données officielles du projet, elle rassemble le travail de 402 contributeurs : 2425 pull requests et 3055 commits. Les principaux changements touchent les Skills et les MCP Apps, les deux couches sur lesquelles repose l'extensibilité de l'agent. Le média chinois Jiqizhixin a assorti l'annonce d'une réserve : une partie des utilisateurs dit être lassée de ces mises à jour.

L'ampleur de la release en chiffres

Le numéro de version suit un schéma calendaire : année, mois, numéro de publication. Cela indique des releases fréquentes, et non de rares jalons majeurs. Le volume de modifications se remarque pourtant même à côté de projets open source matures.

• Contributeurs : 402
• Pull requests : 2425
• Commits : 3055
• En moyenne, environ 6 PR et environ 7,6 commits par auteur
• Environ 1,26 commit par PR

Ce dernier ratio montre que la plupart des PR sont petites et ciblées. Il ne s'agit pas d'un seul module monolithique réécrit, mais d'un flux de petites corrections venues de centaines de personnes. Pour un projet qui ressemble à un outil personnel, un tel profil évoque plutôt une grande plateforme.

Skills et MCP Apps : ce qui a été mis à jour

Les Skills sont des paquets d'instructions et de scénarios que l'agent charge en fonction d'une tâche précise. Les MCP Apps étendent le Model Context Protocol : un outil renvoie non seulement du texte ou du JSON, mais aussi une interface interactive, avec laquelle l'utilisateur travaille directement dans la conversation avec l'agent. Ces deux sous-systèmes déterminent la facilité avec laquelle on branche de nouvelles capacités sur l'agent.

La liste précise des changements dans ces sections figure dans le changelog officiel, sur docs.openclaw.ai. Elle n'apparaît pas dans l'extrait de l'article qui nous a été transmis : impossible donc, pour l'instant, de juger de la profondeur des modifications point par point. On sait seulement que ces deux axes comptent parmi les thèmes principaux de la release.

Pourquoi les utilisateurs sont lassés

Le titre de Jiqizhixin met en avant un second angle : malgré l'ampleur de la release, la communauté parle de lassitude. La raison est facile à comprendre. Quand un projet publie des milliers de modifications dans une seule version, chaque mise à jour devient une petite migration. Il faut relire le changelog, vérifier que ses propres Skills, ses serveurs MCP connectés et ses configurations fonctionnent toujours, et s'assurer que le comportement de l'agent n'a pas changé dans les détails.

Pour les systèmes agentiques, ces détails coûtent plus cher que pour un logiciel classique. L'agent agit au nom de l'utilisateur : il lit des fichiers, envoie des messages, appelle des services externes. Un léger changement dans l'analyse des instructions ou dans le traitement de la réponse d'un outil MCP peut se traduire par une autre décision dans un workflow. C'est plus difficile à repérer et plus compliqué à annuler qu'un test qui échoue.

C'est là que se situe la tension, familière à de nombreux projets open source en forte croissance. Une communauté active apporte de la vitesse et une large couverture des cas d'usage. Mais plus il y a de modifications, plus la charge pèse sur ceux qui veulent simplement que la configuration d'hier fonctionne encore demain.

Que faire pour les utilisateurs et les équipes ?

Ces mesures pratiques ne dépendent pas des détails d'une release en particulier.

• Avant de mettre à jour, lisez le changelog et repérez-y les sections sur les Skills et les MCP Apps. Ce sont elles qui affecteront les extensions développées en interne.
• Figez la version et la configuration actuelles pour pouvoir revenir rapidement en arrière.
• Mettez d'abord à jour l'environnement de test plutôt que l'environnement principal, et rejouez-y les scénarios types : appels d'outils MCP, lancement des Skills clés.
• Ne courez pas après chaque publication. Avec un versionnage calendaire, il est raisonnable de se caler sur un calendrier, par exemple une mise à jour toutes les une à deux semaines, plutôt que le jour de la release.
• Si vous écrivez vos propres Skills ou applications MCP, abonnez-vous aux notifications du projet et suivez les notes sur les changements incompatibles.

La release montre qu'OpenClaw dispose d'une communauté nombreuse et active. La prochaine question pour le projet est de savoir s'il saura concilier ce rythme avec la stabilité qu'attendent ceux qui utilisent l'agent dans leur travail quotidien.