Immich auto-hébergé : 6 Go de RAM et mises à niveau sûres

Ce que vous allez mettre en place

Immich est un service auto-hébergé de sauvegarde de photos et de vidéos, une véritable alternative à Google Photos. Son application mobile téléverse automatiquement les photos de votre pellicule en arrière-plan. Elle propose une timeline, des albums, la reconnaissance faciale et une recherche basée sur le machine learning capable de trouver « plage » ou une personne sans que vous ayez à ajouter le moindre tag. Vous l’exécutez sur un VPS que vous possédez, les fichiers originaux restent sur votre disque et personne ne les analyse pour vous vendre quoi que ce soit. Si vous hésitez encore avec l’autre candidat évident, notre comparaison entre PhotoPrism et Immich met côte à côte leurs besoins minimaux en RAM, leurs applications mobiles et leurs commandes de sauvegarde.

L’installation utilise quatre conteneurs issus du fichier Docker Compose fourni par le projet. Cette étape prend dix minutes. Le reste de ce guide concerne les difficultés réelles : le conteneur de machine learning consomme beaucoup de mémoire sur une petite machine, les fichiers originaux remplissent rapidement le disque, l’application mobile refuse un serveur en HTTP simple et Immich publie assez souvent des changements incompatibles pour qu’un docker compose pull imprudent puisse empêcher votre base de données de démarrer. Prenez ces quatre points au sérieux et Immich est très fiable. Ignorez-les et vous y passerez tout un week-end.

Prérequis et points à connaître

• RAM : la documentation officielle indique 6 GB minimum et 8 GB recommandés. Considérez 4 GB avec du swap comme le strict minimum. Les conteneurs immich-server et Postgres sont modestes. Le conteneur immich-machine-learning est le plus gourmand : il charge les modèles CLIP et de reconnaissance faciale en RAM pour créer les index de recherche. Sur une machine de 2 GB, le kernel le tue. Ajoutez du swap, même avec 4 GB de RAM.
• Disque : prévoyez un espace suffisant pour toute votre bibliothèque, avec une marge. Vos originaux sont copiés intégralement. Immich génère aussi des miniatures et des images d’aperçu, soit environ 10–20 % d’espace supplémentaire. Une photothèque de 200 GB nécessite un volume de 300 GB. Postgres est peu volumineux en comparaison.
• CPU : n’importe quel VPS KVM moderne convient, mais le ML sur CPU est lent. L’indexation de la recherche intelligente d’un import volumineux peut s’exécuter en arrière-plan pendant plusieurs heures. C’est normal. Un GPU n’est pas nécessaire.
• Un nom de domaine pointant vers le VPS. L’application mobile privilégie fortement un endpoint HTTPS. Vous aurez aussi besoin d’un reverse proxy en amont. Cette configuration ressemble à celle d’une instance Nextcloud auto-hébergée avec Docker, TLS et sauvegardes : Immich est l’équivalent photo de ce serveur de fichiers.
• Docker et le plugin Compose installés : Docker Engine et le plugin Compose v2 provenant du dépôt apt officiel de Docker, exactement comme indiqué dans notre guide sur les bases de Docker Compose.

Étape 1 : Ajoutez le swap avant toute autre opération

La cause la plus fréquente d’échec d’Immich sur un petit VPS est l’arrêt forcé du conteneur ML par le système, faute de mémoire. Commencez par fournir au noyau un espace de swap.

sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
free -h

free -h doit maintenant afficher une ligne Swap: de 4.0Gi. Cela n’accélérera pas le ML, mais empêchera le conteneur de s’arrêter au milieu de l’indexation sur une machine disposant de 4 GB.

Étape 2 : Récupérez les fichiers compose et env officiels, et utilisez-les tels quels

Immich fixe les versions de ses services et, surtout, l’image de sa base de données dans les fichiers qu’il fournit. Ne copiez pas un fichier compose depuis un blog, y compris celui-ci, comme source de référence. Téléchargez les fichiers de la release :

sudo mkdir -p /opt/immich && cd /opt/immich
sudo wget -O docker-compose.yml https://github.com/immich-app/immich/releases/latest/download/docker-compose.yml
sudo wget -O .env https://github.com/immich-app/immich/releases/latest/download/example.env

Ils proviennent de la release taguée, les références d’image correspondent donc aux bonnes versions. Le fichier compose définit quatre services. Il est utile de savoir à quoi sert chacun avant de modifier quoi que ce soit :

• immich-server (ghcr.io/immich-app/immich-server, conteneur immich_server), l’API et l’interface web, en écoute sur le port 2283. Il monte vos téléchargements sur /data.
• immich-machine-learning (ghcr.io/immich-app/immich-machine-learning, conteneur immich_machine_learning), la recherche CLIP et la reconnaissance faciale. Il met en cache les modèles téléchargés dans un volume model-cache. C’est le service qui consomme le plus de mémoire.
• database (conteneur immich_postgres), Postgres avec l’extension vectorielle VectorChord, qui assure la recherche par similarité. Le tag de l’image est épinglé par digest directement dans le fichier compose, par exemple ghcr.io/immich-app/postgres:14-vectorchord0.4.3-pgvectors0.2.0@sha256:.... Les anciennes installations utilisaient pgvecto.rs ; sa prise en charge a été supprimée dans Immich v3.0. Toute installation effectuée aujourd’hui utilise donc VectorChord. Ne modifiez jamais ce tag manuellement.
• redis (conteneur immich_redis), une instance Valkey/Redis pour les files d’attente de tâches.

Étape 3 : Configurez .env, qui contient vos photos et votre base de données

Ouvrez .env et définissez les quatre éléments suivants. Tout ce qui se trouve sous la ligne marquée reste inchangé.

# Where original uploads are stored on the host
UPLOAD_LOCATION=/opt/immich/library

# Where the Postgres data lives. NEVER put this on an NFS/network share.
DB_DATA_LOCATION=/opt/immich/postgres

# "v3" is a floating tag that tracks the latest v3.x. Pin a full tag like
# v3.0.2 instead — then you upgrade on purpose, not by surprise.
IMMICH_VERSION=v3.0.2

# Change this to a long random string. Letters and digits only.
DB_PASSWORD=REPLACE_WITH_A_LONG_RANDOM_STRING

# Set your timezone so timestamps and "on this day" line up
TZ=Europe/London

###################################################################################
DB_USERNAME=postgres
DB_DATABASE_NAME=immich

Deux règles vous éviteront des problèmes. UPLOAD_LOCATION doit pointer vers votre disque de grande capacité. Si vous ajoutez un volume de données plus tard, définissez dès le départ ce paramètre avec son chemin de montage, car le déplacer ensuite implique de déplacer les miniatures et de mettre à jour les chemins des ressources. DB_DATA_LOCATION doit être stocké sur un disque local : PostgreSQL corrompt les données sur un partage NFS ou SMB, et la documentation l’indique clairement. Utilisez uniquement des lettres et des chiffres dans DB_PASSWORD pour éviter une catégorie de problèmes d’échappement dans les chaînes de connexion.

Étape 4 : Premier démarrage et création du compte administrateur

cd /opt/immich
sudo docker compose up -d
sudo docker compose ps

Le résultat attendu est de quatre conteneurs, tous running, puis finalement healthy :

NAME                      STATUS
immich_machine_learning   Up (healthy)
immich_postgres           Up (healthy)
immich_redis              Up (healthy)
immich_server             Up (healthy)

Le premier up télécharge plusieurs gigaoctets d’images. L’opération peut donc prendre un certain temps. Suivez sa progression avec sudo docker compose logs -f immich-server ; une fois prêt, le serveur indique dans les journaux qu’il écoute sur le port 2283. Ouvrez ensuite http://YOUR_SERVER_IP:2283 dans un navigateur. Lors de la première visite, l’assistant Getting Started s’affiche. Le premier compte créé est le compte administrateur. Définissez un mot de passe robuste. Ce compte gère les paramètres du serveur, les utilisateurs et la configuration ML dont vous aurez besoin plus tard.

Étape 5 : l’application mobile et la sauvegarde en arrière-plan

Installez « Immich » depuis l’App Store ou le Play Store. L’écran de connexion demande une Server Endpoint URL. Saisissez l’URL complète, schéma compris, par exemple https://photos.example.com (l’application ajoute elle-même /api). Connectez-vous avec le compte que vous venez de créer, puis ouvrez l’écran Backup de l’application, sélectionnez les albums à protéger (généralement Camera et Screenshots), puis activez Background backup. Sur iOS, les sauvegardes en arrière-plan sont limitées par le système d’exploitation. Les téléversements au premier plan s’exécutent toujours. Ceux en arrière-plan s’exécutent lorsque le système d’exploitation l’autorise.

C’est précisément à cette étape que les utilisateurs restent souvent bloqués. Lisez donc l’étape 6 avant d’essayer de résoudre le problème dans l’application.

Étape 6 : HTTPS via un reverse proxy et règle de l’URL complète

L’application mobile exige réellement HTTPS. Placez un reverse proxy devant le port 2283 et terminez TLS à cet endroit. Si vous exécutez déjà plusieurs conteneurs, Traefik avec TLS automatique pour plusieurs applications Docker est l’option la plus propre : un bloc de labels achemine photos.example.com vers le conteneur immich-server et récupère le certificat à votre place. Si vous préférez nginx, le guide Let’s Encrypt avec Certbot et nginx vous fournit un certificat et un bloc proxy_pass http://127.0.0.1:2283;. Une fois ce proxy en place, l’ajout du service suivant consiste principalement à créer un nouveau sous-domaine. C’est ainsi qu’une interface multimédia comme Halcyon, l’interface de vidéoclub des années 90 pour Jellyfin peut fonctionner à côté d’Immich sur le même serveur. Il en va de même pour HarnessRouter auto-hébergé, qui place Codex et Claude Code derrière une API unique : il se lie volontairement à loopback et ne devient accessible qu’une fois que le proxy termine TLS devant lui. Modifiez donc son identifiant et son mot de passe par défaut avant de lui associer un sous-domaine. Tous les conteneurs ne justifient toutefois pas un nom d’hôte public. Un outil réservé à l’administration, comme un scanner de sécurité open-kritt auto-hébergé, doit plutôt rester complètement en dehors du proxy et être accessible via un tunnel SSH lorsque vous ouvrez rarement son interface. D’autres services ignorent le proxy, car HTTP ne correspond pas du tout à leur protocole. Un serveur relais RustDesk auto-hébergé en est l’exemple le plus clair : il écoute sur quelques ports TCP et UDP bruts et nécessite des règles de pare-feu plutôt qu’un sous-domaine. Un réglage du proxy est important pour Immich : augmentez la limite de taille des uploads, car les vidéos des téléphones sont volumineuses. Avec nginx, il s’agit de client_max_body_size 50000M; dans le bloc server. La valeur par défaut de 1 MB rejette les uploads vidéo avec 413 Request Entity Too Large.

La règle appliquée par l’application est la suivante : l’endpoint doit être accessible et, en pratique, doit utiliser HTTPS. Les endpoints http://, ou une adresse IP directe sans port indiqué, sont à l’origine du message « l’application ne peut pas joindre le serveur ». Ce cas est décrit ci-dessous comme une panne identifiée.

Étape 7 : bibliothèques externes et uploads, importer un arbre de photos existant

Il existe deux façons d’ajouter des photos dans Immich. Elles ne fonctionnent pas de la même manière.

• Les uploads sont des fichiers dont Immich assure la gestion. L’application ou l’uploader web copie le fichier dans UPLOAD_LOCATION. Immich peut les renommer, les déplacer et les supprimer.
• Les bibliothèques externes sont des imports en lecture seule de fichiers déjà présents dans un dossier du serveur, par exemple un ancien arbre Pictures ou une exportation NAS. Immich les indexe sur place et les affiche dans la timeline, mais ne modifie et ne supprime jamais les fichiers originaux.

Pour importer un arbre existant, montez-le en lecture seule dans le conteneur du serveur. Modifiez docker-compose.yml sous immich-server: et ajoutez un volume :

  immich-server:
    volumes:
      - ${UPLOAD_LOCATION}:/data
      - /etc/localtime:/etc/localtime:ro
      - /srv/photos:/mnt/media/photos:ro

La directive :ro garantit qu’Immich ne pourra jamais modifier les fichiers originaux. Recréez le conteneur avec sudo docker compose up -d, puis dans l’interface web ouvrez votre avatar → Administration → Bibliothèques externes → Créer une bibliothèque, sélectionnez l’utilisateur propriétaire, cliquez sur Ajouter sous Dossiers et saisissez le chemin du conteneur, /mnt/media/photos, et non le chemin de l’hôte /srv/photos. Cliquez sur Analyser. Utiliser le chemin de l’hôte au lieu de celui du conteneur est l’erreur la plus fréquente avec les bibliothèques externes : l’analyse ne trouve rien et indique 0 fichier.

Étape 8 : La discipline de mise à niveau exigée par Immich

C’est ce qui fait la différence entre une instance Immich fonctionnelle et une instance hors service. Immich publie rapidement ses versions et ne rétroporte pas les correctifs ni ne prend en charge les rétrogradations. Suivre aveuglément le tag flottant v3 finira par casser votre base de données. La même discipline — figer la version, puis lire les notes — s’applique à chaque conteneur maintenu dans le temps sur le serveur. C’est pourquoi un agent KiroCrew auto-hébergé est figé sur un tag connu comme fonctionnel au lieu de changer de version à votre insu lors du prochain redémarrage. La méthode est la suivante :

1. Figez une version. Laissez IMMICH_VERSION défini sur un tag concret tel que v3.0.2, et non sur le tag flottant v3, qui récupère toujours la dernière version v3.x.
2. Lisez les notes de version à chaque fois avant la mise à niveau. Les changements incompatibles, en particulier ceux qui concernent la base de données ou les extensions vectorielles, y sont indiqués. La version v3.0 en est l’exemple évident : elle a supprimé pgvecto.rs, si bien que les utilisateurs de l’ancienne extension devaient terminer la migration vers VectorChord, introduite dès la version v1.133, avant de pouvoir effectuer la mise à niveau.
3. Sauvegardez d’abord la base de données (étape 9). Faites-le toujours, et plus encore lorsque les notes mentionnent la base de données.
4. Récupérez également le nouveau fichier compose. IMMICH_VERSION ne fige que les images du serveur et de ML. L’image Postgres est figée par digest dans docker-compose.yml. Une version qui nécessite une extension de base de données plus récente fournit donc un nouveau fichier compose. Téléchargez à nouveau les deux artefacts de la release, réappliquez vos valeurs .env, puis effectuez la mise à niveau.
5. Mettez vos clients mobiles à jour à peu près au même moment. Le serveur ne communique qu’avec la version majeure correspondante, et l’application prend en charge la version majeure actuelle et la précédente. Si le serveur est passé à une version plus récente que l’application, celle-ci affiche Your app major version is not compatible with the server! sur le téléphone jusqu’à sa mise à jour. Il est donc plus sûr de mettre d’abord l’application à jour.

Les commandes à exécuter, une fois les nouveaux fichiers en place :

cd /opt/immich
sudo docker compose pull
sudo docker compose up -d
sudo docker image prune

Étape 9 : sauvegardez la base de données et les originaux, puis testez la restauration

Une sauvegarde d’Immich comprend deux éléments. L’un sans l’autre est inutilisable. La base de données contient la structure des albums, les visages, les index de recherche et l’association entre chaque asset et son fichier. Le répertoire des originaux contient les photos elles-mêmes. Restaurer un seul de ces éléments produit soit des photos sans organisation, soit une structure vide qui pointe vers des fichiers absents. Cette structure en deux parties n’est pas propre à Immich : un centre de support Chatwoot auto-hébergé nécessite la même association entre un dump PostgreSQL et son répertoire d’uploads. Sinon, la boîte de réception restaurée revient avec toutes ses pièces jointes manquantes. Copier le répertoire de données PostgreSQL comme une arborescence de fichiers peut sembler éviter l’étape du dump, mais cela ne constitue pas une sauvegarde utilisable. C’est un piège que le guide complet de sauvegarde et de restauration d’Immich traite avec le cas d’une restauration qui laisse une timeline vide.

Effectuez le dump de la base de données avec pg_dump depuis le conteneur PostgreSQL, spécifiquement pour la base immich, et non pour l’ensemble du cluster :

sudo docker exec -t immich_postgres pg_dump --clean --if-exists \
  --dbname=immich --username=postgres | gzip > /opt/immich/immich-db-$(date +%F).sql.gz

Sauvegardez ensuite UPLOAD_LOCATION, c’est-à-dire toute l’arborescence /opt/immich/library, notamment ses sous-répertoires library/, upload/ et profile/, avec restic, rsync ou borg vers une autre machine ou un object storage. Quelle que soit la méthode de planification utilisée, une entrée cron ou un timer systemd, cette tâche doit disposer d’un moyen de vous alerter en cas d’échec. Une unité systemd OnFailure= configurée pour utiliser votre propre serveur push ntfy envoie un message sur votre téléphone la nuit où un dump échoue, au lieu de vous laisser le découvrir pendant une restauration. Effectuez d’abord la sauvegarde de la base de données, puis celle des fichiers. Ainsi, le dump ne référencera jamais une photo que la sauvegarde des fichiers n’a pas encore copiée. Sauvegardez séparément les bibliothèques externes depuis leur source réelle. Immich ne les gère pas.

Passons maintenant à l’étape que tout le monde ignore : testez la restauration. Une restauration doit être exécutée sur une stack neuve, dont le serveur n’a jamais démarré, avec une image PostgreSQL dont l’extension vector est compatible avec le dump. C’est précisément pourquoi vous ne devez jamais choisir le tag de l’image DB au hasard. Sur une machine de test utilisant le même compose et .env, supprimez tout état existant, démarrez uniquement la base de données, puis chargez le dump :

cd /opt/immich
sudo docker compose down -v
sudo docker compose pull
sudo docker compose create
sudo docker start immich_postgres
sleep 10
gunzip --stdout immich-db-2026-07-15.sql.gz |
  sed "s/SELECT pg_catalog.set_config('search_path', '', false);/SELECT pg_catalog.set_config('search_path', 'public, pg_catalog', true);/g" |
  sudo docker exec -i immich_postgres psql --dbname=immich --username=postgres --single-transaction --set ON_ERROR_STOP=on
sudo docker compose up -d

La réécriture sed de search_path est obligatoire sur une base de données VectorChord. Si vous l’omettez, la restauration s’interrompt en cours d’exécution. Lorsque la stack redémarre avec vos originaux en place, ouvrez l’interface web. Si vos photos et vos albums sont présents, votre sauvegarde fonctionne. Si vous n’avez jamais effectué ce test, vous n’avez pas de sauvegarde, seulement un espoir.

Modes d’échec, avec les chaînes que vous verrez

Le conteneur ML est arrêté par OOM killer. sudo docker compose logs immich-machine-learning se termine brutalement, docker compose ps indique Restarting, et le code de sortie est 137. sudo dmesg | grep -i oom le confirme : Out of memory: Killed process ... (python3). Les tâches de recherche et de reconnaissance faciale restent alors bloquées. La cause est une quantité de RAM insuffisante pour les modèles. Procédez dans cet ordre : ajoutez du swap (étape 1) ; augmentez la RAM du VPS ; ou, si vous ne pouvez réellement pas faire autrement, désactivez le ML dans Administration → Settings → Machine Learning Settings en désactivant Smart Search et Facial Recognition. Vous conservez les sauvegardes et les albums, mais vous perdez la recherche par contenu. Supprimer le service immich-machine-learning du fichier compose produit le même effet.

Postgres refuse de démarrer après une mise à niveau. Le journal du serveur boucle sur une ligne comme The database currently has VectorChord 0.5.3 activated, but the Postgres instance only has 0.4.2 available. This most likely means the extension was downgraded. ou, avec les stacks plus anciennes, The pgvecto.rs extension is not available in this Postgres instance.. La cause est une image de base de données dont la version de l’extension est antérieure à celle vers laquelle vos données ont été mises à niveau. Cela vient presque toujours de la modification manuelle du tag de l’image ou de la restauration d’un dump plus récent sur une image plus ancienne. Pour corriger le problème, utilisez l’image Postgres correspondante, récupérez le fichier compose de la release correspondant à votre base de données, n’effectuez pas de downgrade et ne restaurez les données que sur une image compatible.

L’application mobile ne peut pas joindre le serveur. L’écran de connexion affiche une erreur de connexion ou Server is not reachable après la saisie de l’URL. Trois causes sont possibles : vous avez saisi http:// alors que le proxy ne sert que https:// ; vous vous êtes connecté directement au backend sans préciser le port, l’application a donc essayé example.com (port 443) au lieu de example.com:2283 ; ou le reverse proxy ne transmet pas /api. Saisissez l’URL https://photos.example.com complète et vérifiez d’abord qu’elle s’ouvre dans le navigateur du téléphone. Si le navigateur fonctionne, mais pas l’application, le proxy supprime le chemin ou le certificat est auto-signé ; l’application rejette les certificats non approuvés.

Le disque est plein au milieu de l’importation. Les téléversements échouent, les miniatures deviennent vides et les journaux affichent ENOSPC: no space left on device ou, côté Postgres, could not extend file ... No space left on device. df -h indique que le volume UPLOAD_LOCATION est rempli à 100%. C’est pourquoi il faut dimensionner le disque avant d’importer une bibliothèque volumineuse. Pour récupérer la situation, attachez un volume plus grand, arrêtez la stack, déplacez UPLOAD_LOCATION vers ce volume, mettez .env à jour et redémarrez. Vous pouvez aussi étendre le disque existant si votre fournisseur l’autorise. Postgres peut se bloquer lorsqu’il n’a plus d’espace ; libérez de l’espace et redémarrez le conteneur de base de données avant de conclure à une corruption.

FAQ

De quelle quantité de RAM et d’espace disque Immich a-t-il besoin ?

Les prérequis officiels d’Immich sont de 6 GB de RAM au minimum et de 8 GB recommandés. Avec du swap, 4 GB constituent le minimum pratique pour une petite bibliothèque. Configurez du swap dans tous les cas, car le conteneur de machine learning est celui qui provoque les pics de consommation. Pour le stockage, prévoyez la taille totale de votre bibliothèque, plus environ 10–20 % pour les miniatures et les aperçus générés. Utilisez un stockage local : ne placez jamais le répertoire de données Postgres sur un partage réseau. Si vous déterminez encore quels autres services exécuter, le guide des services à auto-héberger en 2026 compare l’empreinte d’Immich à celle d’autres services.

Puis-je exécuter Immich sans GPU ?

Oui. Le conteneur de machine learning fonctionne parfaitement sur CPU. Un GPU accélère uniquement l’indexation de la recherche intelligente et, avec la bonne variante d’image, le transcodage vidéo. Sur CPU, l’indexation initiale d’une grande bibliothèque peut prendre plusieurs heures en arrière-plan, mais elle ne bloque ni les sauvegardes ni la navigation. Si votre serveur est trop limité pour exécuter le machine learning, vous pouvez désactiver Smart Search et Facial Recognition dans les paramètres d’administration, et conserver toutes les autres fonctions.

Comment mettre Immich à niveau en toute sécurité ?

Épinglez IMMICH_VERSION sur un tag concret comme v3.0.2, lisez les notes de version avant chaque mise à niveau et sauvegardez d’abord la base de données. Comme l’image Postgres est épinglée dans docker-compose.yml plutôt que par IMMICH_VERSION, retéléchargez le fichier compose et example.env depuis la version cible, réappliquez vos valeurs, puis exécutez docker compose pull && docker compose up -d. Ne laissez jamais la version évoluer automatiquement sans supervision. Immich publie des changements incompatibles et ne prend pas en charge les rétrogradations.

Que dois-je sauvegarder exactement ?

Deux éléments, ensemble : un pg_dump de la base de données immich et l’intégralité du répertoire des originaux UPLOAD_LOCATION. La base de données contient les albums, les visages et la correspondance entre les assets et les fichiers. Le répertoire contient les photos elles-mêmes. Une restauration nécessite les deux, ainsi qu’une image de base de données avec une extension vectorielle compatible. Effectuez d’abord le dump de la base de données, puis copiez les fichiers. Testez au moins une fois la restauration sur un serveur de test : une sauvegarde non testée n’est pas une sauvegarde.

Comment importer mon dossier de photos existant ?

Montez le dossier en lecture seule dans le conteneur immich-server comme volume supplémentaire, par exemple - /srv/photos:/mnt/media/photos:ro, recréez le conteneur, puis dans Administration → External Libraries, créez une bibliothèque et ajoutez le chemin dans le conteneur /mnt/media/photos. Immich indexe les fichiers sur place et ne les modifie ni ne les supprime. L’erreur la plus fréquente consiste à saisir le chemin de l’hôte au lieu du chemin dans le conteneur, ce qui fait que l’analyse ne trouve aucun fichier.