De retour après une semaine d’absence, vous lancez hermes plugins list et découvrez douze plugins installés, dont sept signalés comme ayant une mise à jour. Vous vous souvenez que deux d’entre eux embarquent des correctifs. Alors vous commencez à taper des noms — hermes plugins update foo, puis bar — et vers le quatrième vous perdez le fil de ce qui reste, vous abandonnez, et vous vous promettez de régler ça plus tard.

C’est le genre de corvée qui ne casse jamais rien mais qui coûte en continu. Un changement fusionné le 19 octobre y met fin : hermes plugins update fonctionne maintenant sans nom de plugin — audit d’abord, mise à jour en une fois.

Pourquoi il exigeait autrefois un nom

La sous-commande update ne faisait qu’une chose : prendre un nom, retrouver comment ce plugin avait été installé, et tirer la version plus récente. Elle n’avait aucune idée de ce qui d’autre était installé, donc sans nom elle ne pouvait qu’afficher une erreur d’usage :

$ hermes plugins update
usage: hermes plugins update [-h] name
hermes plugins update: error: the following arguments are required: name

Mettre à jour en masse supposait d’écrire sa propre boucle, et une boucle s’écrit facilement mal. Le nom du répertoire est-il vraiment le nom du plugin ? Les installs par catalog et les installs Git se mettent à jour différemment — faut-il brancher sur ce critère ? Si l’un échoue, continue-t-on ? Tout ce jugement vivait dans votre tête.

Maintenant : pas de nom veut dire « auditer tout le monde »

hermes plugins update

Dans un terminal, la commande lance une sonde check-updates en lecture seule et affiche un tableau :

#	Plugin	Actuel	Dernière	Mise à jour
1	hermes-dreaming	2.9.3	2.9.5	re-pin du catalog
2	obsidian-sync	a1b2c3d4	9f8e7d6c	git pull

Sous le tableau, il nomme chaque plugin ignoré et la raison — par exemple skipped foo (pip): pip distribution; Hermes does not upgrade it. Puis il demande une fois :

Update all 2? [Y/n]:

Entrée ou y, et il met chacun à jour. Chaque plugin passe toujours par le chemin mono-plugin complet — ce n’est pas un force-push. Si une nouvelle version réclame de nouvelles capacités (un nouvel outil, un nouvel accès au système de fichiers), cette demande apparaît toujours plugin par plugin ; si le catalog repoente un commit de release, la question se pose là aussi. Le but du batch est de supprimer la saisie répétée, pas le consentement éclairé.

Un échec n’arrête pas le reste

Le pire comportement possible pour un batch, c’est « le troisième a échoué, donc les quatre derniers n’ont jamais tourné ». Ici, chaque plugin est indépendant :

• un échec affiche la ligne d’erreur propre au plugin et passe au suivant ;
• la passe se termine par un résumé réparti en ✓ updated, = already current et ✗ failed (avec la première ligne de la raison de l’échec) ;
• le code de sortie vaut 1 si quelque chose a échoué, 0 si tout a réussi ;
• s’il n’y a rien à faire, il affiche No plugin updates to apply. et sort en 0.

Cela le rend sûr à placer derrière un conditionnel shell ou dans une tâche planifiée :

hermes plugins update --yes || echo "some plugin failed to update"

L’exécuter dans des scripts, en cron et dans des pipes

Sans terminal (cron, CI, un pipe vers tee), le comportement par défaut est de ne rien faire : la commande affiche la liste, sort en 1, et vous invite à la relancer avec --yes. Ce conservatisme est assumé — une montée de version en masse ne doit jamais modifier les choses en silence dans un environnement non surveillé.

Avec --yes, les mises à jour s’exécutent réellement, mais le consentement reste fermé par défaut :

• les nouvelles capacités demandées par une nouvelle version ne sont pas accordées ; le plugin reste restreint ;
• un commit de catalog re-pinné n’est pas appliqué ;
• tout ce qui ne demande aucun consentement supplémentaire se met à jour normalement.

--yes n’est par ailleurs valide que sans nom. hermes plugins update foo --yes est refusé, pour que personne ne le lise comme « mets à jour celui-là et approuve automatiquement tout ce qu’il demande ».

Si vous voulez vraiment des mises à jour non surveillées pour certains plugins, c’est un interrupteur distinct et explicite :

plugins:
  auto_apply: true    # installs Git suivis uniquement ; false par défaut

auto_apply ne couvre que les plugins Git suivis. Il ne touche pas aux lignes pinned, placées à la main, à provenance dérivée ou issues d’une distribution pip. Les deux chemins passent le même scan de sécurité avant mise à jour.

Quels plugins sont ignorés, et pourquoi

La mise à jour en masse n’agit que sur les deux types que update sait réellement faire avancer : les installs par catalog (re-pinnés sur le commit de catalog revu) et les installs Git suivis (pulled). Tout le reste est ignoré nommément plutôt que silencieusement « mis à jour » :

Cas	Raison du skip
distribution pip	Hermes ne met pas à niveau les paquets PyPI — c’est le travail de pip
pinned (version ou commit)	Pinned veut dire que vous voulez le garder en place
needs fixing	Réparez d’abord l’état de l’installation
statut inconnu	Le remote est injoignable, donc la commande ne devine pas

Si vous avez fait un git clone d’un plugin directement dans le répertoire des plugins, ce n’est pas un install suivi — lancez d’abord hermes plugins adopt <name> pour que Hermes sache d’où il vient. C’est intentionnel : il ne va pas pull un répertoire dont il ne comprend pas la provenance.

Un dernier détail de sécurité : si une nouvelle version modifie son manifest, ou introduit ou remplace un update_url, Hermes refuse la nouvelle adresse jusqu’à votre approbation :

hermes plugins trust-update-url my-plugin

C’est un contrôle de provenance de feed, pas un bac à sable. Il protège contre « le canal de mise à jour a été remplacé par le serveur de quelqu’un d’autre » ; il ne protège pas contre du code auquel vous faites déjà confiance et qui se mettrait à mal se comporter.

Quand les vérifications ont lieu, et comment vérifier

hermes plugins update lance la même sonde que hermes plugins check-updates, qui est en lecture seule et ne touche pas aux fichiers des plugins — pratique pour du monitoring :

hermes plugins check-updates   # rapport seulement, ne change rien

La gateway exécute aussi une vérification planifiée, espacée par plugins.auto_update_check_hours (24 heures par défaut, 0 la désactive). Son reçu est visible via hermes pm status et dans la vue de statut de synchronisation de Desktop. Cela ne règle que la fréquence à laquelle Hermes regarde — rien ne se met à jour par défaut tant que vous ne lancez pas update ou n’activez pas auto_apply.

Conseils pratiques

• Regardez avant de sauter. Si vous ne savez pas à quel point vous êtes en retard, lancez d’abord hermes plugins check-updates ; ça ne touche à rien.
• Relancez hermes plugins list ensuite. La mise à jour en masse demande toujours confirmation plugin par plugin. Si vous avez martelé Entrée sur une demande d’autorisation, ce plugin finit restreint plutôt que cassé, et rien ne vous hurle dessus — un coup d’œil s’impose.
• Ne comptez pas sur les défauts en CI. Sans terminal, la commande refuse de mettre à jour et sort en 1 ; si votre pipeline traite un code non nul comme un échec, passez --yes explicitement ou gardez les montées de version hors de la CI.
• « Nouvelle version » ne veut pas dire la même chose selon le type d’install. Un install par catalog avance vers un commit que le catalog a revu ; un install Git suit le HEAD de la branche amont. Le second a un rayon d’impact bien plus large.

Deux articles précédents donnent le contexte : comment fonctionne le catalog de plugins et la porte de supply-chain CI qui se trouve derrière. Si vous maintenez des plugins portables, la porte de confiance MCP pour plugins portables couvre l’autre moitié de l’histoire de confiance. La liste complète des sous-commandes est dans la référence de commande plugins.

En bref

La montée de version en masse n’est pas le plus dur — c’est de garder ensemble « masse » et « consentement éclairé ». Ce changement trace la ligne clairement : la saisie répétée disparaît, et chaque décision qui compte (nouvelles capacités, commit de catalog re-pinné, source de mise à jour modifiée) arrive toujours devant vous, une par une. Pour qui fait tourner une douzaine de plugins, c’est la différence entre « je m’en occuperai » et une ligne de commande hebdomadaire.