Vous utilisez trois Profiles Hermes : un pour le travail, un pour les projets personnels, un pour les expériences. Chaque Profile est configuré avec le backend terminal Docker, si bien qu’à chaque démarrage, plusieurs conteneurs se lancent sur votre machine — plus de disque, des démarrages plus lents, des dépendances installées séparément dans chacun, et des changements d’environnement à synchroniser conteneur par conteneur. Le PR #94633, fusionné le 25 août, propose une correction élégante : les Profiles de confiance peuvent partager un seul conteneur Docker persistant, contrôlé par une unique clé de configuration.

Avant : un conteneur par Profile

D’abord, le comportement par défaut. Le backend Docker de Hermes (terminal.backend: docker) donne à chaque Profile son propre conteneur — la règle d’isolation établie le même jour par le PR #94560 : les conteneurs sont délimités et nommés par Profile (profile:<name>), sans interférence. L’avantage, c’est une isolation nette ; l’inconvénient, ce sont des ressources dupliquées : trois Profiles signifie trois ensembles de dépendances, trois caches, trois environnements.

Si vous utilisez surtout Docker pour des tâches isolées ponctuelles, ce comportement par défaut est parfait — aucun changement nécessaire. Mais si plusieurs de vos Profiles forment une « famille de confiance » — disons un Profile de travail et un Profile d’expériences qui utilisent en réalité le même environnement de dev — la duplication est un pur gaspillage.

Maintenant : une clé, un conteneur

Le PR #94633 introduit une nouvelle clé de configuration : terminal.docker_shared_container_key. Les règles sont simples :

• Non définie (chaîne vide par défaut) : comportement actuel, chaque Profile conserve son propre conteneur ;
• Plusieurs Profiles définissent la même valeur : ils partagent un conteneur persistant, identifié comme shared:<your-key> ;
• Les exécutions CLI directes (sans contexte de Profile) avec la même clé configurée atterrissent également dans ce conteneur partagé.

Configuration :

hermes config set terminal.docker_shared_container_key team/ws

Ou modifiez directement le fichier de configuration (hermes config path en indique l’emplacement) :

terminal:
  backend: docker
  docker_shared_container_key: "team/ws"

Une fois que les Profiles work et research utilisent tous deux team/ws, leurs commandes atterrissent dans le même conteneur : installez les dépendances une seule fois et tout le monde les voit, les caches restent chauds, les changements d’environnement s’appliquent en un seul endroit. Dans les tests officiels, les deux Profiles aboutissent à la même clé de conteneur shared:team/ws.

Les cas où le partage est volontairement ignoré

Ce n’est pas une fusion aveugle — trois limites méritent d’être connues :

• Les backends SSH ne participent pas : terminal.docker_shared_container_key n’affecte que le backend Docker ; les environnements SSH l’ignorent totalement ;
• Le mode non persistant reste isolé : si vous utilisez des sessions Docker jetables (non persistantes), la clé partagée ne fourrera pas deux sessions éphémères dans un même conteneur — l’isolation par session est préservée ;
• Clés différentes = pas de partage : la clé est la frontière d’isolation ; les Profiles avec des valeurs différentes utilisent chacun leur propre conteneur.

Par ailleurs, les fichiers produits dans le conteneur partagé (par exemple les pièces jointes MEDIA) restent récupérables depuis les sessions — les tests officiels ont spécifiquement couvert la livraison de médias depuis le sandbox partagé.

Quand l’activer, quand s’en passer

Bons candidats : des Profiles qui ne sont en réalité que des points d’entrée différents vers le même environnement de dev ; un « conteneur d’environnement » partagé pour une équipe ; les utilisateurs personnels multi-Profile qui veulent économiser du disque et du temps de démarrage.

Gardez le défaut : les Profiles avec une faible confiance mutuelle (par exemple hébergeant de l’automatisation non fiable) ; les environnements nécessitant une isolation stricte à des fins d’audit ; les Profiles expérimentaux dont les versions de dépendances pourraient entrer en conflit. L’isolation est toujours plus sûre que le partage — la clé partagée est destinée aux Profiles « de confiance », ce qui est exactement le sens de « trusted profiles » dans le titre du PR.

Résumé

Une seule clé de configuration transforme « un conteneur Docker par Profile » en « un conteneur pour toute la famille » : terminal.docker_shared_container_key laissée vide conserve l’isolation par défaut, tandis que plusieurs Profiles définissant la même valeur partagent un conteneur persistant. Pour en savoir plus sur les workflows multi-Profile, consultez notre guide multi-instance des Profiles ; pour les opérations sur le fichier de configuration, la référence de la commande hermes config couvre le reste. Vous hésitez encore à savoir si Docker est le bon backend ? Le guide d’installation passe en revue toutes les options de backend.