--- service: "Publicasta" schema_version: "1.0" article_id: 605 title: "OpenClaw 2026.9.4 facilite la découverte des plugins et des skills — et leur évaluation" language: "fr" default_language: "en" canonical_url: "https://publicasta.com/open_source_radar/openclaw_2026_9_4_plugin_skill_discovery_upgrade_guide?lang=fr" json_url: "https://publicasta.com/open_source_radar/openclaw_2026_9_4_plugin_skill_discovery_upgrade_guide.json?lang=fr" api_url: "https://publicasta.com/api/public/v1/channels/open_source_radar/articles/openclaw_2026_9_4_plugin_skill_discovery_upgrade_guide?lang=fr" channel_url: "https://publicasta.com/api/public/v1/channels/open_source_radar" channel_articles: "https://publicasta.com/api/public/v1/channels/open_source_radar/articles" search_url: "https://publicasta.com/api/public/v1/search" documentation_url: "https://publicasta.com/api-docs#reading-publicasta" openapi_url: "https://publicasta.com/api-docs/openapi.json" published_at: "2026-09-14T07:03:48+00:00" updated_at: "2026-09-14T07:03:48+00:00" translations: - language: "ar" html_url: "https://publicasta.com/open_source_radar/openclaw_2026_9_4_plugin_skill_discovery_upgrade_guide?lang=ar" markdown_url: "https://publicasta.com/open_source_radar/openclaw_2026_9_4_plugin_skill_discovery_upgrade_guide.md?lang=ar" json_url: "https://publicasta.com/open_source_radar/openclaw_2026_9_4_plugin_skill_discovery_upgrade_guide.json?lang=ar" - language: "de" html_url: "https://publicasta.com/open_source_radar/openclaw_2026_9_4_plugin_skill_discovery_upgrade_guide?lang=de" markdown_url: "https://publicasta.com/open_source_radar/openclaw_2026_9_4_plugin_skill_discovery_upgrade_guide.md?lang=de" json_url: "https://publicasta.com/open_source_radar/openclaw_2026_9_4_plugin_skill_discovery_upgrade_guide.json?lang=de" - language: "en" html_url: "https://publicasta.com/open_source_radar/openclaw_2026_9_4_plugin_skill_discovery_upgrade_guide?lang=en" markdown_url: "https://publicasta.com/open_source_radar/openclaw_2026_9_4_plugin_skill_discovery_upgrade_guide.md?lang=en" json_url: "https://publicasta.com/open_source_radar/openclaw_2026_9_4_plugin_skill_discovery_upgrade_guide.json?lang=en" - language: "es" html_url: "https://publicasta.com/open_source_radar/openclaw_2026_9_4_plugin_skill_discovery_upgrade_guide?lang=es" markdown_url: "https://publicasta.com/open_source_radar/openclaw_2026_9_4_plugin_skill_discovery_upgrade_guide.md?lang=es" json_url: "https://publicasta.com/open_source_radar/openclaw_2026_9_4_plugin_skill_discovery_upgrade_guide.json?lang=es" - language: "fr" html_url: "https://publicasta.com/open_source_radar/openclaw_2026_9_4_plugin_skill_discovery_upgrade_guide?lang=fr" markdown_url: "https://publicasta.com/open_source_radar/openclaw_2026_9_4_plugin_skill_discovery_upgrade_guide.md?lang=fr" json_url: "https://publicasta.com/open_source_radar/openclaw_2026_9_4_plugin_skill_discovery_upgrade_guide.json?lang=fr" - language: "pl" html_url: "https://publicasta.com/open_source_radar/openclaw_2026_9_4_plugin_skill_discovery_upgrade_guide?lang=pl" markdown_url: "https://publicasta.com/open_source_radar/openclaw_2026_9_4_plugin_skill_discovery_upgrade_guide.md?lang=pl" json_url: "https://publicasta.com/open_source_radar/openclaw_2026_9_4_plugin_skill_discovery_upgrade_guide.json?lang=pl" - language: "ru" html_url: "https://publicasta.com/open_source_radar/openclaw_2026_9_4_plugin_skill_discovery_upgrade_guide?lang=ru" markdown_url: "https://publicasta.com/open_source_radar/openclaw_2026_9_4_plugin_skill_discovery_upgrade_guide.md?lang=ru" json_url: "https://publicasta.com/open_source_radar/openclaw_2026_9_4_plugin_skill_discovery_upgrade_guide.json?lang=ru" - language: "zh" html_url: "https://publicasta.com/open_source_radar/openclaw_2026_9_4_plugin_skill_discovery_upgrade_guide?lang=zh" markdown_url: "https://publicasta.com/open_source_radar/openclaw_2026_9_4_plugin_skill_discovery_upgrade_guide.md?lang=zh" json_url: "https://publicasta.com/open_source_radar/openclaw_2026_9_4_plugin_skill_discovery_upgrade_guide.json?lang=zh" --- # OpenClaw 2026.9.4 facilite la découverte des plugins et des skills — et leur évaluation > OpenClaw 2026.9.4 améliore la découverte des extensions, la création guidée de skills, l’installation, les sessions cloud et la récupération après mise à jour. Un gain pratique, à condition de vérifier permissions, coûts, sauvegardes et compatibilité. OpenClaw 2026.9.4 ne se définit ni par un nouveau modèle unique ni par une transformation spectaculaire de l’interface. Son apport le plus conséquent est organisationnel : le projet rend les plugins, les skills, les workers cloud et les sessions d’agents de longue durée plus faciles à découvrir, configurer et réutiliser. Cela déplace la question pratique pour les utilisateurs. Il ne s’agit plus seulement de savoir si OpenClaw peut accomplir une tâche, mais de comprendre ce qui a été ajouté au système, quel agent peut l’utiliser, quelles autorisations sont nécessaires et comment revenir à un état fonctionnel lorsqu’une mise à jour ou une étape de configuration se passe mal. ![Ordinateur portable affichant un tableau de bord abstrait de découverte de plugins et de compétences, avec un discret motif de sauvegarde et de calcul cloud.](https://publicasta.com/storage/projects/10/pages/605/2026/09/bc5c847b-b12b-4775-b9d7-14e78df71376.webp) Les notes de version décrivent une livraison importante : 1 558 pull requests, 20 commits directs et 294 contributeurs. Parmi les fonctions mises en avant figurent un navigateur de plugins unifié, un atelier de skills capable de transformer des conversations passées en instructions réutilisables, la prise en charge de GPT Image 2.5, des sessions cloud plus flexibles, des questions interactives dans le terminal et un large ensemble de corrections touchant l’installation, les mises à jour, la mémoire, la messagerie et les fonctions de navigateur. Le nombre de changements compte moins que leur direction. OpenClaw devient une plateforme dont la surface d’extension fait partie du produit, au lieu de rester une fonction secondaire dissimulée dans un répertoire de configuration. Pour un utilisateur existant, la meilleure raison de tester 2026.9.4 n’est pas d’activer toutes les options. C’est de disposer de meilleurs moyens pour inspecter et déployer progressivement les fonctions dont on dépend déjà. Une installation neuve peut profiter d’un parcours d’accueil amélioré. Une configuration multi-agents gagne à proposer une sélection plus explicite de l’espace de travail et des destinataires. Une équipe qui exploite des workers cloud peut réutiliser une préparation existante et choisir plus précisément son système d’exploitation. Chacune de ces commodités élargit toutefois la frontière de confiance. ## Ce qui change dans OpenClaw 2026.9.4 Les [notes de version officielles de v2026.9.4](https://docs.openclaw.ai/releases/2026.9.4) répartissent les changements entre l’installation, l’interface web, les skills, les plugins et les intégrations, les workers cloud, les modèles, la messagerie, l’automatisation du navigateur et la fiabilité opérationnelle. La livraison est assez vaste pour qu’il soit trompeur de la qualifier de simple mise à jour fonctionnelle. En revanche, chaque modification n’aura pas la même importance pour tous les utilisateurs. Le changement central est le passage d’une gestion dispersée des extensions à une découverte visible. L’interface web peut rechercher ensemble les plugins installés et ceux qui sont disponibles, les filtrer par usage et ouvrir des pages détaillées contenant la documentation et les informations de compatibilité. Les plugins locaux apparaissent dans la découverte aux côtés des plugins intégrés et de ceux provenant de ClawHub. Dans une conversation, OpenClaw peut recommander jusqu’à trois plugins ou skills officiels, accompagnés d’une carte ouvrant les détails correspondants. L’installation passe toujours par une étape de vérification, et les notes préviennent qu’un plugin installé peut nécessiter des réglages ou la connexion d’un compte avant de devenir utilisable. Cette dernière précision est essentielle. Découvrir n’est pas être prêt. Un plugin peut être visible, compatible avec l’hôte et pourtant incapable d’effectuer un travail utile tant que son fournisseur, son compte, ses permissions ou ses dépendances locales ne sont pas configurés. Une carte bien présentée réduit l’effort nécessaire pour trouver une extension ; elle ne supprime pas la responsabilité de décider si cette extension a sa place dans un espace de travail donné. Le flux de travail des skills progresse lui aussi. Les skills sont des instructions réutilisables qui aident un agent à reconnaître et à exécuter des tâches récurrentes. OpenClaw peut désormais rechercher ensemble les skills installés et ceux de ClawHub, afficher le véritable titre du skill, proposer des descriptions plus claires et réduire le risque que l’installation de dépendances lentes soit interrompue. Le nouvel atelier Skill Workshop peut examiner d’anciennes conversations dans un chat visible et pilotable. L’utilisateur suit le processus, ajoute des indications ou l’arrête. Le mode Auto peut appliquer les améliorations, tandis que le mode Propose laisse les suggestions à valider. Cette distinction éloigne le dispositif d’une auto-modification invisible. Démarrer un chat d’apprentissage n’active pas un auto-apprentissage automatique dans toutes les conversations à venir. Les notes de version précisent également que les coûts habituels liés au modèle et les permissions d’accès continuent de s’appliquer. La fonction est donc plus facile à cerner : il s’agit d’un flux d’édition assistée pour des fichiers d’instructions, avec une interface de chat autour de la relecture, et non d’une promesse selon laquelle l’agent progresserait silencieusement de lui-même. ## Le bénéfice réel : moins de friction autour des extensions Le modèle d’extension d’OpenClaw rencontre un problème connu. Dès qu’un système prend en charge des plugins, des skills, des canaux, des fournisseurs de modèles, des hooks, des services et des remplacements locaux, l’utilisateur doit répondre à plusieurs questions avant de pouvoir utiliser une extension. D’où vient-elle ? Quel agent la voit ? Quelle version l’emporte si deux noms entrent en collision ? Faut-il installer un paquet ? Le code s’exécute-t-il dans le processus principal ? L’extension apporte-t-elle ses propres skills ? Que se passe-t-il lorsqu’elle est mise à jour indépendamment de l’hôte ? La documentation du projet explique que la découverte commence par les manifestes, puis que le runtime peut charger le plugin et enregistrer des capacités comme des outils, des canaux, des fournisseurs, des hooks, des routes HTTP, des commandes CLI et des services. La [documentation de l’architecture des plugins](https://github.com/openclaw/openclaw/blob/main/docs/plugins/architecture.md) décrit une séparation entre la recherche des candidats, la décision de les activer et le chargement de leur runtime. Cette séparation correspond à une bonne conception de plateforme : les métadonnées peuvent être inspectées avant l’importation de chaque plugin. Elle fournit aussi un point de contrôle utile aux opérateurs : un manifeste indique ce qu’un paquet affirme fournir avant que son code exécutable ne soit actif. La [documentation des manifestes](https://github.com/openclaw/openclaw/blob/main/docs/plugins/manifest.md) rend cette frontière explicite. Les plugins natifs utilisent `openclaw.plugin.json` ; les bundles compatibles peuvent employer les formats de manifeste pris en charge qui leur sont propres. Le manifeste sert à la découverte et à la validation, tandis que le module runtime est chargé séparément. Les champs documentés comprennent les capacités, le schéma de configuration, les détails d’activation et les métadonnées du fournisseur. La documentation rappelle aussi que les métadonnées relatives aux variables d’environnement sont déclaratives. La présence d’une variable d’environnement dans un manifeste ne doit pas être considérée comme la preuve que le fournisseur est configuré ou digne de confiance. Pour les plugins qui ne fournissent que des outils, OpenClaw utilise une section de contrats afin d’indiquer quels outils appartiennent au paquet sans charger la totalité du runtime. Le [guide des plugins d’outils](https://github.com/openclaw/openclaw/blob/main/docs/plugins/tool-plugins.md) explique que des métadonnées générées obsolètes peuvent faire disparaître un outil de la découverte ou donner l’impression que l’échec d’enregistrement vient du mauvais plugin. Ce n’est pas une fonction destinée directement à l’utilisateur final, mais cela explique pourquoi la nouvelle surface de navigation peut intéresser les développeurs : les métadonnées d’extension acquièrent une importance opérationnelle. Les utilisateurs qui se limitent aux fonctions intégrées remarqueront peut-être peu de choses le premier jour. Les principaux bénéficiaires sont ceux qui travaillent avec plusieurs agents, des skills locaux ou des plugins communautaires. Ils peuvent interroger un inventaire unique, examiner la compatibilité et distinguer une capacité installée d’une capacité disponible. Pour la maintenance, c’est un meilleur point de départ que de se rappeler quel répertoire a été modifié plusieurs mois auparavant. ## Skill Workshop est prometteur, mais exige une vraie discipline éditoriale Transformer un historique de conversation en skill réutilisable semble simple jusqu’à ce que cet historique contienne des demandes contradictoires, des solutions provisoires, des secrets, du contexte sans rapport ou des décisions qui n’avaient de sens que pour un projet précis. Un bon skill doit avoir un objectif stable, des déclencheurs clairs, des hypothèses limitées et des instructions qui restent valables après l’oubli de la conversation d’origine. Une transcription n’est pas automatiquement une spécification. Le flux visible de l’atelier est donc la partie la plus intéressante de cette évolution. Il permet d’observer l’amélioration proposée et de l’orienter. Pour une équipe, le mode Propose est le premier essai le plus raisonnable : il faut examiner les changements suggérés avant qu’ils ne deviennent des instructions actives. Le mode Auto peut être pratique pour expérimenter seul, mais il doit être considéré comme un mode de rédaction accéléré, pas comme un remplacement de la relecture. La [documentation des skills](https://github.com/openclaw/openclaw/blob/main/docs/tools/skills.md) explique que les skills sont chargés depuis plusieurs racines, selon des règles de priorité. Les skills de l’espace de travail ont une priorité supérieure à ceux du projet, de l’espace personnel, des emplacements gérés et des bundles intégrés. Un skill portant le même nom dans un emplacement prioritaire peut remplacer celui d’un emplacement moins prioritaire. Un skill généré peut donc produire des effets bien au-delà de la conversation qui l’a créé, surtout s’il est enregistré dans un répertoire d’espace de travail partagé par plusieurs tâches. Une relecture pratique devrait poser quatre questions. Le skill contient-il uniquement des instructions durables, ou a-t-il conservé un détail ponctuel de la conversation source ? La description de son déclencheur est-elle assez précise pour éviter une activation trop large ? Demande-t-il à l’agent d’utiliser des outils ou d’accéder à des données dont la tâche n’a pas besoin ? Le fichier se trouve-t-il à un niveau de priorité dont d’autres agents hériteront ? Ces questions comptent davantage que l’élégance apparente du texte produit. OpenClaw 2026.9.4 améliore aussi le rafraîchissement. Après le redémarrage d’une Gateway, les fichiers de skills locaux mis à jour peuvent être utilisés par une conversation existante à son tour suivant, et les skills nouvellement installés ou réparés sont détectés de manière plus fiable. Les skills de bibliothèque gérée conservent leur version sélectionnée jusqu’à leur actualisation. Ces détails favorisent la reproductibilité, mais une équipe doit savoir si une session utilise le fichier courant, une révision gérée sélectionnée ou un remplacement local. La documentation du projet décrit la vérification et les contrôles d’installation de ClawHub, notamment les informations de confiance et les restrictions appliquées aux archives téléversées. Cela ne transforme pas un registre de skills en garantie de sécurité. Un skill est un paquet d’instructions ; son risque dépend des outils accessibles à l’agent, des données incluses dans le périmètre et du chemin d’installation. Traitez les fichiers de skills comme une configuration proche du code : relisez-les, versionnez-les et retirez les capacités inutiles. ## Une configuration plus sûre ne supprime pas tous les risques La livraison s’attaque à une source fréquente de frustration : un outil qui ne démarre pas parce que la machine utilise une version de Node non prise en charge ou incompatible. OpenClaw peut rechercher une installation compatible déjà présente sur l’ordinateur, ou proposer d’en installer une pour OpenClaw sans remplacer la version de Node utilisée par les autres applications. Après approbation, il peut réutiliser cette copie compatible. La version apporte également un chemin de réparation pour un service Gateway en arrière-plan qui pointe encore vers un ancien runtime Node. C’est une amélioration importante pour les personnes qui ne souhaitent pas qu’une plateforme d’agents réécrive leur environnement général de développement. La réparation du runtime d’OpenClaw est séparée du reste de la machine. Les notes signalent néanmoins des limites. Certains systèmes, notamment Alpine Linux, nécessitent une installation manuelle, et le comportement de SQLite peut influer sur l’acceptation du runtime et les diagnostics. Un démarrage réussi sur une machine ne suffit donc pas à démontrer la portabilité vers une autre. Les corrections d’installation couvrent les configurations Bash récentes de Homebrew, l’installation de dépendances sources dans Docker, les hooks portables d’autocomplétion du shell et des indications plus claires pour les comptes Linux. Ce sont des changements rarement visibles dans une démonstration, mais ils déterminent si un outil auto-hébergé peut être entretenu. La correction Docker concerne particulièrement les opérateurs qui construisent des images au lieu de télécharger un paquet précompilé : une dépendance source manquante peut sinon transformer une mise à niveau en échec de compilation difficile à interpréter. Le nouveau parcours d’accueil prête aussi davantage attention à l’identité et au périmètre. Dans les configurations multi-agents, la configuration guidée de la messagerie permet de choisir l’espace de travail à configurer, puis les personnes qui recevront les messages. Les instructions pour les appareils distinguent la connexion d’un appareil de l’approbation des commandes qu’il peut exécuter. Cette séparation est exactement celle dont un système utilisant des nœuds distants a besoin. Apparier un appareil ne doit pas être confondu avec lui accorder une autorité. Les indications Android recommandent d’utiliser HTTPS lorsque c’est possible, car HTTP en clair ne chiffre ni les identifiants de connexion ni les messages. C’est une règle élémentaire d’hygiène opérationnelle, mais elle mérite sa place dans la discussion sur la mise à niveau : un parcours plus convivial peut inciter à exposer un service avant d’avoir choisi un chemin réseau sûr. Même un outil conçu localement doit avoir un modèle réseau lorsqu’il se connecte à des téléphones, des navigateurs, des workers cloud ou des ordinateurs distants. ## Les workers cloud transforment le confort en décision de coût et de cycle de vie Les changements liés aux workers cloud constituent l’autre raison majeure de s’intéresser à cette version. Une nouvelle session cloud peut réutiliser un projet déjà préparé, ce qui réduit les installations et configurations répétées. Le projet peut être un projet local éligible ou un dépôt GitHub public. Une URL fournie vers un dépôt privé utilise encore une nouvelle copie, tandis qu’un projet privé déjà extrait localement peut suivre le chemin du projet local. Une configuration enregistrée a toujours besoin d’une machine pour démarrer, sauf si un worker disponible est déjà en fonctionnement. La version ajoute les workers Ready, qui gardent un ordinateur de réserve disponible pour une session correspondante ultérieure pendant qu’OpenClaw prépare un remplacement. Les valeurs par défaut documentées comprennent un worker de réserve par projet et profil Linux éligible, avec une limite partagée de quatre. Ces machines coûtent de l’argent jusqu’à la confirmation de leur suppression. L’opérateur peut définir à zéro la valeur des workers Ready d’un profil ou réduire à zéro la limite commune du pool préparé. Cette fonction doit être comprise comme une gestion de capacité, pas simplement comme un moyen d’accélérer le démarrage. Un worker chaud ou préparé est une ressource externe, avec un propriétaire, une relation de facturation, un état de projet conservé et un cycle de vie qui doit rester visible. Avant de l’activer, déterminez qui peut créer les workers, qui peut les supprimer, combien de temps ils peuvent rester actifs et quelles informations sont incluses dans une image ou un bundle préparé. Le gain de vitesse n’a de valeur que si la ressource est contrôlée. OpenClaw peut également sélectionner le système d’exploitation du worker lorsque le fournisseur le permet : Linux, Windows, WSL2 ou macOS. Une exécution Windows native lance des commandes Windows, tandis que WSL2 fournit un environnement Linux sur Windows. Les workers Mac sur AWS nécessitent un Dedicated Host et une capacité à la demande ; selon les notes de version, l’accès au bureau et les images de workers réutilisables restent limités à Linux. La disponibilité dépend donc du fournisseur, et pas seulement d’un réglage OpenClaw. Le modèle de préparation des workers offre un avantage discret en matière de reproductibilité. Les builds utilisent les fichiers du projet et les instructions de configuration validés, et un administrateur peut enregistrer, surveiller, annuler ou épingler un snapshot utile. Mais un snapshot ne constitue pas un plan complet de reprise après sinistre. Il peut contenir des dépendances installées et des hypothèses liées à la machine qui ne sont pas évidentes dans le dépôt. Gardez les instructions de configuration du projet comme référence, consignez l’image ou le snapshot utilisé pour chaque session et vérifiez qu’un worker neuf peut encore être créé. ## Les sauvegardes font partie de la mise à niveau L’avertissement le plus important des notes de version est facile à manquer parce qu’il se trouve dans la section consacrée aux workers cloud : sauvegardez les données d’OpenClaw avant la mise à niveau. Les anciennes versions ne peuvent pas lire le format de données mis à jour ; revenir à l’application précédente ne suffit donc pas. Restaurer une ancienne sauvegarde supprime également les changements réalisés après cette sauvegarde. Cela modifie le sens d’une mise à niveau rapide. Si OpenClaw conserve les conversations, les réglages, la mémoire, l’état des skills, les enregistrements des plugins ou les métadonnées des workers dans un format illisible par une ancienne version, une mise à jour échouée peut devenir un incident de récupération de données. La bonne séquence consiste à identifier l’emplacement des données, créer une sauvegarde restaurable, noter la version actuellement installée, effectuer la mise à niveau, puis vérifier les conversations ordinaires et les capacités importantes pour le déploiement. La version inclut le comportement de mise à jour plus sûr issu de la série 2026, notamment la répétition des changements du cœur et des plugins dans un état candidat isolé avant leur activation. C’est utile, car cela réduit la probabilité qu’une extension mal formée remplace immédiatement une installation saine. Cela ne supprime pas le besoin de sauvegardes. La validation d’un état candidat peut détecter une incompatibilité ; elle ne peut pas restaurer les données modifiées volontairement après la mise à niveau. Pour la plupart des installations personnelles, une courte liste de vérification suffit : - Confirmer la version actuelle et celle que l’on prévoit d’installer. - Sauvegarder les données d’OpenClaw et vérifier que la sauvegarde peut être ouverte ou restaurée. - Établir la liste des plugins et des skills réellement utilisés par les agents importants. - Tester une conversation normale, un appel d’outil et un flux planifié ou de messagerie si ces fonctions sont concernées. - Vérifier que les appareils distants et les services Gateway pointent toujours vers le runtime prévu. - Examiner les réglages des workers cloud et confirmer qu’aucune capacité chaude n’a été activée par inadvertance. Les équipes devraient ajouter une seconde vérification : comparer l’inventaire effectif des skills et des plugins pour chaque agent après la mise à niveau. Un espace de travail partagé peut donner l’impression qu’une capacité est stable alors qu’un fichier local plus prioritaire modifie discrètement son comportement. ## Sécurité et frontières de confiance Le dépôt ouvert d’OpenClaw facilite l’inspection, le suivi des problèmes et la revue indépendante. Il ne constitue pas un certificat de sécurité. Le [dépôt du projet](https://github.com/openclaw/openclaw) rassemble le code source, la documentation, le suivi des problèmes, les versions et l’espace consacré à la sécurité ; les opérateurs doivent malgré tout évaluer la version qu’ils installent et les paquets qu’ils ajoutent. Le [fichier de licence du projet](https://github.com/openclaw/openclaw/blob/main/LICENSE) doit également faire partie de la revue de déploiement, en particulier lorsque OpenClaw est intégré à un service commercial ou distribué à d’autres utilisateurs. Le système d’extensions appelle une prudence particulière, car il associe découverte et exécution. Un plugin peut enregistrer des outils appelables par l’agent, des fournisseurs de modèles, des canaux, des hooks, des services ou d’autres capacités runtime. Un skill peut influencer le moment où l’agent choisit un outil et les instructions qu’il suit. Un worker cloud peut accéder à une copie du projet et à des identifiants externes. Ces mécanismes sont différents, mais l’utilisateur les rencontre à travers un même agent. La revue doit donc couvrir toute la chaîne, et pas seulement le nom du paquet. Commencez par le moindre privilège. N’activez que les canaux, outils, comptes et emplacements du système de fichiers nécessaires à la tâche. Évitez de placer des identifiants sensibles dans les fichiers sources ou dans le texte des skills. La documentation recommande la configuration, les variables d’environnement ou les SecretRefs pour les secrets des fournisseurs ; le même principe vaut pour les extensions gérées localement. Si un plugin n’a besoin que d’un accès en lecture à un service, ne lui donnez pas un identifiant généraliste accompagné d’un accès étendu à l’espace de travail. Soyez prudent face aux recommandations affichées dans le chat. La version peut présenter jusqu’à trois recommandations officielles de plugins ou de skills, et l’installation ouvre une étape de vérification. Cela réduit les recherches au hasard, mais une recommandation officielle reste une suggestion, pas une décision d’autorisation. Vérifiez l’éditeur, la source, les permissions demandées, la plage de compatibilité, l’activité de maintenance et le chemin des données avant l’installation. Pour un plugin chargé dans le processus, une panne ou une vulnérabilité peut avoir un impact plus large que dans le cas d’un utilitaire autonome en ligne de commande. L’accès distant mérite la même attention. Utilisez un transport chiffré lorsque c’est possible, limitez l’exposition réseau, séparez l’association d’un appareil de l’approbation des commandes et tenez un inventaire des appareils connectés. Si un agent peut exécuter des commandes sur un nœud, la question n’est pas seulement de savoir si le nœud vous appartient. Il faut déterminer si la conversation actuelle, le skill, le plugin et l’identité de l’utilisateur doivent pouvoir émettre cette commande à cet instant. ## Qui devrait l’essayer en premier OpenClaw 2026.9.4 est un bon candidat pour les personnes qui entretiennent déjà plusieurs plugins ou skills et perdent du temps à les trouver et les configurer. L’inventaire unifié peut rendre la surface d’extension lisible. L’atelier peut aider à transformer un flux récurrent et stable en skill relu. Les améliorations de mise à jour et de diagnostic peuvent réduire les frictions d’installation sur les machines qui possèdent plusieurs versions de Node. La version mérite aussi un test dans les équipes qui créent régulièrement des workers cloud à partir des mêmes dépôts. La réutilisation de la configuration du projet, les profils de workers, le choix du système d’exploitation et la capacité préparée peuvent réduire le travail de mise en place. L’équipe doit toutefois traiter cette version comme un changement d’exploitation, car les images et les workers Ready influent sur les coûts, la conservation des données et le contrôle des accès. Les développeurs de plugins forment un autre public évident. La documentation des manifestes et des plugins d’outils renforce le contrat de la couche de découverte, tandis que l’interface propose un chemin plus visible vers les informations de compatibilité. Si votre plugin possède des métadonnées statiques, des manifestes générés ou des skills intégrés, 2026.9.4 est une version utile pour tester la découverte, l’installation, la mise à jour et le comportement en cas d’échec. Un utilisateur personnel prudent, avec un seul agent, aucun plugin, aucun nœud distant et aucun worker cloud, a moins à gagner immédiatement. Les corrections d’installation et de runtime peuvent tout de même compter, mais les changements les plus importants de la livraison se situent en dehors de ce flux. Attendre une fenêtre de maintenance pratique est raisonnable si l’installation actuelle est stable et si le chemin de sauvegarde n’a pas encore été testé. ## Un plan de test pratique Pour le premier passage, utilisez une copie ou une installation sans enjeu critique. Ne commencez pas par importer tous les skills et plugins disponibles. Puisque la version cherche à améliorer la sélection et la vérification, testez ce parcours avec une seule capacité à la fois. Commencez par consigner l’état actuel. Enregistrez la version d’OpenClaw, les noms des agents actifs, la liste des plugins, les racines des skills, la configuration personnalisée, les appareils connectés et les profils éventuels de workers cloud. Effectuez la sauvegarde des données avant de modifier l’installation. Si votre configuration dépend d’une révision gérée d’un skill ou d’un remplacement local, indiquez-le explicitement. Testez ensuite l’installation et le démarrage. Si plusieurs versions de Node sont présentes, confirmez quel runtime utilise la CLI et quel runtime utilise la Gateway en arrière-plan. N’essayez le chemin de réparation que dans un environnement contrôlé. Avec Docker, construisez l’image selon les mêmes hypothèses de source qu’en production et vérifiez que les dépendances sont disponibles sans invite interactive. Passez alors à la découverte. Ouvrez les pages des plugins et des skills, recherchez un élément installé, recherchez un élément disponible, consultez les informations de compatibilité et examinez l’écran de vérification avant l’installation. Vérifiez qu’un plugin local apparaît avec les métadonnées attendues. S’il est absent, contrôlez son manifeste et ses contrats générés avant de conclure que le runtime est défaillant. Pour le Skill Workshop, commencez en mode Propose. Choisissez une conversation courte qui représente un flux récurrent, mais qui ne contient ni secrets ni informations privées de clients. Examinez le skill proposé : portée du déclencheur, hypothèses implicites, demandes d’outils et détails personnels récupérés par accident. Enregistrez-le au niveau d’espace de travail le plus restreint qui réponde au besoin. Relancez la tâche d’origine et comparez le résultat. Si le skill s’active alors qu’il ne le devrait pas, corrigez sa description avant d’élargir son périmètre. Enfin, testez la récupération. Arrêtez puis redémarrez la Gateway, ouvrez une conversation existante, rechargez la liste des skills et lancez une action connue d’un plugin. Si vous utilisez des workers cloud, créez une session de test, confirmez le système d’exploitation sélectionné et vérifiez que le worker est supprimé ou renvoyé vers le pool prévu. Consultez la console du fournisseur pour repérer les ressources qui seraient encore actives. Cette procédure paraît plus lente qu’un clic sur le bouton de mise à niveau, mais elle produit des informations réutilisables. Elle révèle quelles parties de l’installation dépendent de la version, quelles extensions nécessitent des comptes externes et si la sauvegarde est réellement exploitable. C’est plus utile qu’une impression générale selon laquelle la nouvelle interface serait simplement plus propre. ## Alternatives et adéquation du choix La bonne alternative dépend du problème à résoudre. Pour un assistant local très limité, un outil plus simple, doté d’une petite surface de configuration, peut être plus facile à auditer qu’une plateforme fondée sur les canaux, les plugins, les workers cloud et les agents multiples. Pour des environnements de projet reproductibles plutôt que de l’automatisation conversationnelle, un gestionnaire classique d’environnements de développement accompagné d’un fichier de configuration versionné peut offrir une frontière plus claire. Pour une automatisation d’équipe, choisissez un système dont le modèle de permissions, la piste d’audit et le cycle de déploiement correspondent à l’organisation, au lieu de retenir une extension uniquement parce que sa carte apparaît dans un navigateur. La proposition distinctive d’OpenClaw tient à son ampleur : un même système peut relier des agents à la messagerie, aux navigateurs, aux appareils, aux fournisseurs de modèles, à la mémoire, aux skills, aux plugins et aux ordinateurs cloud. La version 2026.9.4 rend cette amplitude plus facile à parcourir. Elle ne la fait pas disparaître. Les utilisateurs qui préfèrent un outil compact et spécialisé ne devraient pas adopter OpenClaw simplement parce que la découverte des extensions s’est améliorée. Ceux qui ont déjà besoin de plusieurs de ces capacités peuvent, en revanche, trouver dans le nouvel inventaire et le nouveau flux de vérification une réduction réelle de la friction opérationnelle. Le projet présente aussi un profil de risque différent de celui d’une bibliothèque utilisée dans une application. Une dépendance applicative s’exécute généralement dans le processus et le modèle de permissions déjà établis par un service. Une plateforme d’agents peut décider quand appeler des outils, envoyer des messages, ouvrir des sessions de navigateur, lire un espace de travail ou démarrer un calcul externe. La revue humaine, les identifiants limités, le verrouillage des versions et les procédures de récupération font donc partie de l’usage normal. ## Verdict OpenClaw 2026.9.4 doit être compris comme une version de maintenance de plateforme dotée d’une couche de découverte destinée aux utilisateurs. Sa contribution la plus utile n’est pas une capacité vedette isolée. C’est l’effort pour rendre assez visibles la gestion des extensions, l’amélioration des skills, la réparation du runtime, la préparation du cloud et la récupération après mise à jour pour qu’on puisse les inspecter. Essayez-la si votre difficulté actuelle consiste à trouver et maintenir les capacités que vous utilisez déjà, ou si la préparation répétée de workers cloud ralentit un travail réel. Commencez par une sauvegarde, une installation de test, un plugin et un skill proposé. Pour le premier passage, laissez de côté l’apprentissage Auto, les identifiants trop larges, la capacité cloud chaude et les extensions communautaires non relues. Cette version mérite l’attention parce qu’elle s’attaque au travail administratif qui entoure les agents. Elle appelle la prudence pour la même raison. Lorsqu’une plateforme facilite l’ajout de nouvelles capacités, la qualité du processus de vérification devient aussi importante que les capacités elles-mêmes. ## Sources - [Notes de version OpenClaw v2026.9.4](https://docs.openclaw.ai/releases/2026.9.4) — source factuelle principale. - [Dépôt source OpenClaw](https://github.com/openclaw/openclaw) — code, versions, documentation et suivi du projet. - [Documentation des skills](https://github.com/openclaw/openclaw/blob/main/docs/tools/skills.md) — contexte sur le chargement et la priorité des skills. - [Architecture des plugins](https://github.com/openclaw/openclaw/blob/main/docs/plugins/architecture.md) — contexte sur la découverte et le chargement des extensions. - [Documentation des manifestes de plugins](https://github.com/openclaw/openclaw/blob/main/docs/plugins/manifest.md) — informations factuelles sur les manifestes. - [Documentation des plugins d’outils](https://github.com/openclaw/openclaw/blob/main/docs/plugins/tool-plugins.md) — contexte sur les contrats et les métadonnées générées. - [Licence OpenClaw](https://github.com/openclaw/openclaw/blob/main/LICENSE) — référence juridique. - [Discussion communautaire sur OpenClaw v2026.9.4](https://www.reddit.com/r/openclaw/comments/1wdl9o5/openclaw_v202694_brings_plugin_discovery_and/) — discussion, utilisée comme contexte communautaire.