Aller au contenu principal
◆ Automatisation
2 min de lecture

Le volume existe. Le projet disparaît.

Un montage Docker peut sembler correct tout en laissant le vrai dossier de projet hors de portée.

Publié le 27 septembre 2026

Mis à jour :

Proposition à confirmer sur le rendu final : poste de travail avec dossier Windows inaccessible puis visible sur une seconde cible de montage dans Hermes Agent.
Proposition à confirmer sur le rendu final : poste de travail avec dossier Windows inaccessible puis visible sur une seconde cible de montage dans Hermes Agent.

# Le volume existe. Le projet disparaît.

Un montage Docker peut sembler correct tout en laissant le vrai dossier de projet hors de portée.

C’est le problème traité par le commit Hermes Agent 1a72042 pour les équipes qui exécutent l’outil dans Docker sous Windows. Le défaut intervient lorsqu’un répertoire de travail est déjà revendiqué : le dossier de projet Windows attendu n’est alors pas monté à l’endroit où l’outil doit le voir.

Le volume est bien là. Pourtant, le projet disparaît du point de vue de l’outil.

Deux chemins, deux rôles

Le point essentiel n’est pas de multiplier les volumes. Il est de distinguer deux rôles qui peuvent être confondus :

  • le répertoire de travail déjà occupé par un volume existant ;
  • le dossier de projet Windows, qui doit rester accessible depuis le conteneur.

Lorsque le premier répertoire est déjà pris, le correctif ajoute une seconde cible de montage pour le dossier de projet. Le chemin de projet peut ainsi être utilisé sans remplacer le répertoire déjà revendiqué.

Ce changement ne transforme pas Docker en environnement universellement compatible. Il traite un cas précis : un dossier Windows non monté parce que le répertoire de travail est déjà occupé.

Ce que le correctif établit

Le commit 1a72042 corrige ce défaut de montage et ajoute des tests dédiés.

Cela établit deux choses utiles pour la lecture du changement :

  • le cas du répertoire de travail déjà revendiqué a été pris en compte ;
  • le comportement attendu fait l’objet de tests de code dédiés.

Ce que cela ne prouve pas est tout aussi important. Un commit et ses tests ne constituent pas une release générale prouvée. Ils ne garantissent pas non plus le comportement de toutes les configurations Docker sous Windows.

Les contrôles à refaire

Avant le prochain run, le contrôle le plus utile consiste à séparer clairement les questions suivantes :

  • Quel répertoire de travail est déjà occupé par un volume ?
  • Quel dossier de projet Windows doit être monté ?
  • Quelle cible de montage distincte rend ce dossier accessible au conteneur ?
  • Quel chemin l’outil voit-il réellement une fois lancé ?

Cette vérification évite de conclure trop vite qu’un volume présent suffit à rendre le projet disponible. Un volume peut exister et le dossier attendu rester absent du point de vue de l’outil.

Pour Addict AI Technology, la leçon de ce correctif est simple : dans un environnement conteneurisé, le chemin visible compte autant que le volume déclaré.

Vérifiez quel chemin vos outils voient réellement avant le prochain run.

Passer de la lecture à la décision

Un premier échange pour situer votre point de départ, préciser le besoin et déterminer les prochaines étapes possibles.