Immich est la réponse auto-hébergée à Google Photos : votre serveur, vos disques, une application mobile qui sauvegarde votre pellicule. L'installation se lit comme si elle prenait cinq minutes, et mécaniquement c'est le cas. Les décisions qui détermineront si vous avez encore vos photos dans trois ans se prennent toutes dans le fichier que vous éditez avant de la lancer.
Ce qu'est réellement l'installation officielle
Deux téléchargements et une commande. La documentation les donne telles quelles :
wget -O docker-compose.yml https://github.com/immich-app/immich/releases/latest/download/docker-compose.yml
wget -O .env https://github.com/immich-app/immich/releases/latest/download/example.env
Notez l'asymétrie de la seconde ligne : le fichier est publié sous le nom example.env et vous l'enregistrez en .env. Ensuite, une fois les variables renseignées, toute l'installation se résume à docker compose up -d.
Si cette dernière commande échoue, la documentation nomme la cause habituelle avant que vous ayez à chercher. Elle prévient que si vous obtenez une erreur du type unknown shorthand flag: 'd' in -d, c'est probablement que vous n'avez pas la bonne version de Docker, et que la forme correcte est docker compose avec une espace plutôt que l'ancien binaire docker-compose. Elle signale séparément un second piège de version : une erreur indiquant que can't set healthcheck.start_interval as feature require Docker Engine v25 or later, qu'elle suggère de contourner en commentant cette ligne.
Ce sont deux décalages de version, pas des fautes dans votre fichier. Aucun des deux ne mérite d'y passer la soirée.
Les deux emplacements qui décident de votre capacité à récupérer
Le fichier compose est court, mais deux de ses variables ne sont pas des réglages interchangeables. Ce sont les réponses à « que dois-je sauvegarder » et « qu'est-ce qui va se corrompre tout seul ».
UPLOAD_LOCATION est décrite dans la documentation comme l'emplacement où sont stockés vos fichiers téléversés, avec la consigne d'y indiquer l'emplacement de votre choix pour conserver ces données. C'est le répertoire qui contiendra chaque photo que vous téléverserez. Le choisir à la légère est la façon la plus courante de se retrouver avec une photothèque installée hors de toutes les sauvegardes que vous faites déjà tourner.
DB_DATA_LOCATION est la base de données, et la documentation y attache une contrainte ferme : les partages réseau ne sont pas pris en charge pour la base de données. Ce n'est pas une recommandation de performance. Les moteurs de base s'appuient sur des garanties de verrouillage et d'ordonnancement des écritures que les systèmes de fichiers réseau assurent inégalement, et le mode de défaillance est en général une corruption silencieuse découverte des semaines plus tard, pas un refus de démarrer.
En pratique : votre photothèque peut vivre sur du stockage réseau si vous acceptez qu'elle soit plus lente. Le répertoire de la base reste sur un disque local. Et quel que soit votre choix pour le premier, notez-le, parce que c'est le chemin que vos sauvegardes doivent inclure.
L'avertissement que le projet affiche sur sa propre page d'accueil
La plupart des guides d'auto-hébergement le passent sous silence, alors autant citer le projet plutôt que de le paraphraser. Le dépôt Immich porte, tout en haut, cette ligne : « Always follow 3-2-1 backup plan for your precious photos and videos! »
Cet avertissement fait quelque chose de précis. Il ne dit pas que le logiciel est peu fiable. Il dit qu'héberger son propre serveur photo n'est pas en soi une sauvegarde, et ceux qui l'ont écrit savent que les auto-hébergeurs croient couramment le contraire. Une instance unique sur une machine unique détient exactement une copie de votre photothèque. Un disque qui lâche, une mise à jour bâclée, une suppression accidentelle ou un chemin mal tapé la fait disparaître, et il n'y a aucun prestataire à qui la demander.
Le projet est sous licence AGPL-3.0, ce qui explique en partie que vous puissiez l'auditer et le faire tourner. Cela ne change rien à l'arithmétique d'une copie unique.
Ce que l'auto-hébergement déplace, et ce qu'il ne déplace pas
On présente souvent l'auto-hébergement comme l'option privée, point final. Il est plus juste, et plus utile, de dire qu'il déplace la confiance au lieu de la supprimer.
Ce qui change vraiment : aucune entreprise ne détient votre photothèque, aucun prestataire ne peut être contraint juridiquement de la livrer, aucune condition d'utilisation ne change dans votre dos, et il n'y a pas de compte à perdre. Pour beaucoup de gens c'est tout l'intérêt, et le gain est réel.
Ce qui ne change pas de soi-même : le chiffrement au repos sur vos propres disques, la sécurité physique de la machine, le maintien à jour, et le fait d'avoir plus d'une copie. Tout cela devient votre travail dès l'instant où vous le reprenez à un prestataire. C'est le marché, et il est raisonnable de l'accepter en connaissance de cause. Il l'est beaucoup moins quand on l'accepte par inadvertance, parce qu'on a supposé qu'auto-hébergé voulait dire protégé.
Vous voulez la photothèque privée sans administrer le serveur ? pCloud à vie + Crypto
Juridiction suisse · Zero-knowledge avec l'option Crypto · Paiement unique, aucune mise à jour à suivre et aucune base à sauvegarder
Choisir honnêtement entre les deux
Auto-hébergez Immich si vous voulez vos photos sur du matériel que vous contrôlez, que vous acceptez d'assumer les sauvegardes et les mises à jour, et que la maintenance vous intéresse plutôt qu'elle ne vous pèsera dans huit mois.
Prenez un service managé zero-knowledge si ce que vous vouliez réellement, c'est qu'aucune entreprise ne puisse lire vos photos, sans devenir la personne d'astreinte le jour où le disque lâche. Ce résultat-là s'obtient sans serveur, et le choisir n'est pas un renoncement sur la vie privée : c'est une autre répartition du même travail.
La seule réponse qui ne survit pas au contact du réel, c'est une instance auto-hébergée unique sans seconde copie. C'est très exactement pour cela que le projet le dit lui-même avant que vous n'installiez quoi que ce soit.
Les commandes d'installation, la précision selon laquelle le fichier d'environnement est publié sous le nom example.env, les descriptions d'UPLOAD_LOCATION et de DB_DATA_LOCATION, l'énoncé selon lequel les partages réseau ne sont pas pris en charge pour la base de données, et les deux erreurs de version Docker proviennent de la documentation officielle d'installation d'Immich par Docker Compose. La ligne de sauvegarde 3-2-1 et la licence AGPL-3.0 proviennent de la page d'accueil du dépôt du projet. Les citations sont laissées dans leur langue d'origine. Les deux sources ont été consultées au moment de la rédaction ; vérifiez sur la version que vous installez, le fichier compose étant livré avec chaque release. Les liens commerciaux portent l'attribut rel="sponsored nofollow" ; une commission d'affiliation peut s'appliquer, sans surcoût pour vous.
Guides liés
- Meilleur stockage cloud pour les photos - le versant managé de la même question, avec les services qui chiffrent les photos côté client.
- Stockage cloud auto-hébergé - le même arbitrage appliqué aux fichiers plutôt qu'aux photos, avec Nextcloud, Seafile et ownCloud.
Questions fréquentes
- Que faut-il réellement télécharger pour installer Immich ?
- Deux fichiers, publiés avec chaque version. La documentation donne les commandes telles quelles : wget -O docker-compose.yml https://github.com/immich-app/immich/releases/latest/download/docker-compose.yml et wget -O .env https://github.com/immich-app/immich/releases/latest/download/example.env. Notez que le second est publié sous le nom example.env et que vous l'enregistrez en .env. Une fois les variables renseignées, toute l'installation tient en une commande : docker compose up -d.
- Pourquoi ma commande docker compose échoue-t-elle sur une option inconnue ?
- Vous utilisez presque certainement l'ancien binaire autonome plutôt que le plugin. La documentation traite ce cas explicitement : si vous obtenez une erreur du type unknown shorthand flag 'd' in -d, c'est probablement que vous n'avez pas la bonne version de Docker, et la commande correcte est docker compose, avec une espace, et non docker-compose avec un tiret. Elle mentionne un second piège de version, sans rapport : une erreur indiquant que healthcheck.start_interval exige Docker Engine v25 ou plus récent, qu'elle suggère de contourner en commentant cette ligne.
- Où mes photos atterrissent-elles vraiment sur le disque ?
- Là où pointe UPLOAD_LOCATION, que la documentation décrit comme l'emplacement où vos fichiers téléversés sont stockés, en vous demandant d'y indiquer l'emplacement de votre choix pour conserver ces données. C'est la ligne la plus lourde de conséquences du fichier, parce qu'elle décide du répertoire que vous devrez sauvegarder. Réglez-la délibérément sur un chemin que vous protégez déjà, plutôt que d'accepter une valeur par défaut et de découvrir plus tard que votre photothèque vit à un endroit que vos sauvegardes ne regardent jamais.
- Puis-je mettre la base de données sur mon NAS ?
- Pas la base de données. La documentation l'énonce sans détour pour DB_DATA_LOCATION : les partages réseau ne sont pas pris en charge pour la base de données. Les bases ont besoin d'un verrouillage de fichiers de bas niveau que les systèmes de fichiers réseau n'assurent pas de façon fiable, et l'ignorer produit généralement de la corruption plutôt qu'une erreur nette. Votre photothèque peut vivre sur du stockage réseau si vous en acceptez le coût en performance ; le répertoire de la base, lui, reste sur un disque local.
- Auto-héberger Immich suffit-il à mettre mes photos à l'abri ?
- Le projet lui-même dit que non, et il le dit sur sa propre page d'accueil : appliquez toujours un plan de sauvegarde 3-2-1 pour vos photos et vidéos précieuses. Faire tourner le serveur vous-même change qui détient votre photothèque, cela n'en crée pas une seconde copie. Une instance auto-hébergée sur une seule machine se trouve à une panne de disque, une mise à jour ratée ou une suppression malheureuse de la perte totale, ce que la règle 3-2-1 existe précisément pour éviter.
Voir l'offre pCloud
10 jours satisfait ou remboursé
