Souverain

Pendant longtemps, Umbrel a été “assez bon” pour mon homelab.
Puis la migration Umbrel vers YunoHost est devenue inévitable.

Ce texte, c’est le deuxième épisode de l’histoire commencée avec mon OptiPlex et Umbrel, celle que je racontais dans « De l’OptiPlex au web souverain : récit (très) personnel d’un serveur maison ».
Sauf que cette fois, on parle de ce que tout le monde redoute : changer de « stack« , casser des choses, réinstaller, douter… et recommencer.

1. Umbrel : la rampe de lancement… et le plafond de verre

Umbrel a parfaitement joué son rôle de tremplin :

• interface claire, installation rapide ;
• catalogue d’apps en un clic ;
• Docker emballé dans une couche rassurante.

Mais au quotidien, plusieurs limites ont fini par me rattraper :

• HTTPS mal compris / mal maîtrisé : je n’ai jamais été vraiment à l’aise avec la gestion du HTTPS en local. Oui, c’est faisable, mais la surcouche Umbrel m’a plus brouillé les pistes qu’autre chose.
• Docker opaque (pour moi) : tout tourne en conteneurs, mais sans que je me sente vraiment en contrôle. Je voyais les « docker compose » partout… sans les comprendre.
• Accès à distance bancal : concrètement, la seule façon simple (que j’ai trouvé) d’accéder à mon serveur Umbrel depuis l’extérieur, c’était via une url Tor. Pratique pour tester, moins pour faire tourner un usage “normal” à la maison ou depuis l’extérieur.

Umbrel m’a appris des bases, m’a donné confiance. Mais si je voulais continuer à avancer sur ma souveraineté numérique, il fallait que je reprenne la main sur la suite de logiciels, d’outils et technique que je souhaitais vraiment, pas seulement cliquer sur des boutons.

2. Pourquoi YunoHost a fini par s’imposer (ce n’est que mon avis et mon expérience)

J’avais déjà croisé YunoHost. À l’époque, c’était trop tôt dans ma courbe d’apprentissage. Cette fois, j’étais prêt. Pourquoi YunoHost, concrètement ?

• Projet francophone, technocritique, assumé “pour humains” : l’objectif affiché de YunoHost est de simplifier l’auto-hébergement pour des non-admins système, tout en restant 100% logiciel libre, basé sur Debian.
• Plus besoin de gérer Docker à la main : la plupart des apps sont empaquetées au format YunoHost ; je clique, je remplis quelques paramètres, et le système gère le reste.
• Catalogue d’applications qui colle mieux à mes besoins : RSS, partage de fichiers, Mastodon, outils de productivité… c’est littéralement une boîte à outils pour reprendre le contrôle de son numérique.
• Administration centralisée : domaines, certificats, DNS, sauvegardes, mises à jour… tout est regroupé en une interface cohérente.

Seule grosse exception aujourd’hui : Immich.
La version disponible dans le catalogue YunoHost ne gère pas encore le format HEIC, ce qui m’oblige à garder une instance Immich à part en Docker. C’est le seul endroit où je n’ai pas encore réussi à me débarrasser de Docker… et ça me fatigue un peu.

3. Préparer la migration Umbrel → YunoHost sans tout casser

Je n’ai pas appuyé sur un gros bouton “Migrer vers YunoHost”. J’ai fait ça à l’ancienne, prudemment.

3.1. Sauvegarder ce qui compte depuis Umbrel

Avant toute chose :

• export de données critiques (photos, notes, flux RSS, favoris) depuis Umbrel,
• sauvegardes depuis les applications elles-mêmes quand c’était possible (par exemple export OPML pour le lecteur RSS, export des favoris, etc.),
• et surtout : conserver le disque Umbrel tel quel, prêt à être rebranché si l’aventure tournait mal.

Umbrel n’a pas de bouton magique de migration vers YunoHost, donc l’idée était simple : reprendre les données au format le plus standard possible, pour pouvoir les réinjecter plus tard.

3.2. Première installation YunoHost : en machine virtuelle, pour voir

Première étape : installer YunoHost dans une machine virtuelle sur mon ordinateur, juste pour me refaire la main :

• je reconnais l’interface,
• j’utilise un domaine de test gratuit proposé par YunoHost,
• j’installe quelques apps,
• je vérifie que tout démarre correctement.

Succès… relatif :

• l’installation est complète,
• l’interface me parle,
• mais je n’ai pas encore d’IP fixe à ce moment-là, et mon F.A.I bloque l’ouverture de certains ports.
  Résultat : impossible d’accéder à mon serveur depuis l’extérieur, et certaines apps refusent de s’installer sans ports ouverts.

Donc oui, la VM tournait, mais ce n’était pas encore un serveur “vivant”.

3.3. Changement de fournisseur d’accès à Internet, IP fixe, et vraie tentative

Deuxième manche : je change de fournisseur d’accès à Internet, je récupère une IP fixe et surtout la possibilité d’ouvrir les ports nécessaires.

Je :

1. branche un nouveau disque pour YunoHost (en gardant le disque Umbrel au chaud),
2. installe YunoHost “pour de vrai” sur l’OptiPlex,
3. déclare mes domaines,
4. configure les ports sur la box,
5. installe mes applications favorites.

Pour la première fois, j’accède à mon serveur YunoHost simplement, sans passer par Tor, et je commence à utiliser mes services à distance comme un “vrai” serveur maison.

Je laisse tourner quelques semaines pour voir si ça tient.

Spoiler : oui, mais pas sans casse.

4. Les erreurs qui m’ont obligé à tout recommencer

Je ne suis pas admin système.
Je suis curieux, têtu, et parfois un peu trop confiant avec ce que me propose l’IA en ligne de commande.

Résultat : j’ai appris à la dure.

4.1. Les domaines .local / .test : la fausse bonne idée

Au début, je voulais/pensais faire “propre”, enfin surtout ne pas exposer certains services à l’extérieur :

• des domaines en .local ou .test pour le réseau local,
• des noms qui sonnent bien pour les services internes.

En pratique : gros galères DNS.
Conflits, résolutions bancales, comportements différents selon les machines… très vite, j’ai passé plus de temps à débuguer le DNS qu’à profiter de mon serveur.

Conclusion
→ Si vous débutez, évitez les TLD exotiques en local. Restez sur de “vrais” domaines ou sous-domaines, même pour le LAN, et laissez YunoHost / votre DNS faire le travail.

4.2. Installer trop d’apps “parce que c’est cool”

Une fois devant le catalogue d’apps YunoHost, j’ai eu le syndrome du gosse dans un magasin de jouets :

• “Oh tiens, ça a l’air bien.”
• “Ça aussi.”
• “Allez, je teste ça pour voir.”

Résultat :

• trop de services qui tournent,
• consommation inutile de ressources,
• et surtout : trop de maintenance pour un usage souvent plus occasionnel qu’autre chose.

Conseil simple
→ Installez d’abord ce que vous allez utiliser tous les jours.
Le “reste” peut attendre. Sinon, vous vous retrouvez avec un zoo de services semi-cassés.

4.3. L’IA + root + Linux : combo explosif

Là, on touche le cœur du problème.

J’ai demandé à l’IA de m’aider en ligne de commande, alors que :

• je ne comprenais pas pleinement l’architecture de Linux,
• je ne maîtrisais pas les implications de mes modifications,
• et je travaillais parfois directement en root.

J’ai fini par :

• toucher à des fichiers de configuration critiques,
• ouvrir des ports sans vraiment mesurer les risques,
• installer des paquets inutiles (voire contradictoires),
• casser des dépendances,
• voir des mises à jour défaire des corrections bricolées à la main.

Petit à petit, le système s’est fragilisé. Rien de spectaculaire au début, mais au bout de quelques semaines, j’étais sur une base bancale.

Recommandation honnête :
Utilisez l’IA uniquement si :

• vous comprenez ce qu’elle fait,
• vous savez où elle écrit,
• et vous êtes capable de revenir en arrière.
  Sinon, vous risquez de passer plus de temps à réparer qu’à apprendre.

5. Repartir de zéro : la vraie migration vers un YunoHost “propre”

À un moment, il a fallu trancher.

Je voyais bien que :

• YunoHost me convenait mieux qu’Umbrel,
• je ne me voyais pas revenir en arrière,
• mais mon installation YunoHost était devenue un patchwork.

J’ai donc :

1. refait des sauvegardes de ce qui comptait vraiment (et quand c’était possible, directement depuis les apps : exports, archives, etc.),
2. changé encore une fois de disque,
3. réinstallé YunoHost proprement,
4. limité au maximum les bidouilles en ligne de commande,
5. réinstallé mes services les plus importants,
6. tenté de restaurer mes sauvegardes YunoHost.

Et là, j’ai pris la plus grosse claque de tout ce projet :

Faire une sauvegarde, c’est bien.
Vérifier qu’elle se restaure vraiment, c’est vital.

Certaines apps n’ont pas du tout aimé la restauration. Certaines configs n’ont pas suivi. J’ai dû réinstaller, reconfigurer, reimporter à la main.

Leçon n°1 : tester la restauration AVANT le drame

Aujourd’hui, ma méthode est plus mature :

• sauvegardes via YunoHost + sauvegardes depuis les outils eux-mêmes quand c’est possible ;
• tests de restauration réguliers dans un environnement de test (machine virtuelle, autre disque, etc.) ;
• moins de confiance aveugle dans le bouton “Sauvegarde”.

6. Ce qui tourne aujourd’hui sur mon YunoHost

Malgré les doutes, les réinstallations et les erreurs, j’ai maintenant un serveur YunoHost qui me convient (pour l’instant).

6.1. Les briques “infrastructure”

• Un serveur DNS avec filtrage de publicité
  C’est la brique la plus sensible de mon installation : toute ma maison dépend de lui. Je réfléchis sérieusement à le migrer sur un Raspberry Pi 5 dédié, uniquement pour cette fonction, histoire de réduire les risques.
• Fail2ban pour limiter les tentatives de brute force.
• Cockpit pour garder un œil général sur la machine.
• Uptime Kuma pour surveiller que les services essentiels répondent vraiment.
  

6.2. Les apps du quotidien

Ce sont celles qui justifient, à elles seules, que je garde ce serveur :

• FreshRSS : mon lecteur RSS, pour reprendre le contrôle sur l’info.
• Karakeep : mes favoris structurés (mais je dois penser à faire des sauvegardes manuelles). J’ai d’ailleurs rédigé un article si vous voulez en savoir +
• Linkstack : ma page de liens “publique”.
• Mastodon : ma petite instance maison, pour garder un pied dans le fediverse.
• Pairdrop : échange de fichiers à la maison, simple et rapide (et pratique entre iOS et Android par exemple)
• Piped : YouTube, mais sans YouTube (sans pub et sans tracking).
• Send : pour partager de gros fichiers ponctuels.
• Stirling PDF : mon couteau suisse pour les PDF, déjà présent à l’époque d’Umbrel.

6.3. Les services en suspens

Il y a aussi des services sur lesquels je n’ai pas encore tranché :

• Serveur de courriel (Postfix, Rspamd, SnappyMail, etc.)
  J’en parle en détail dans mon article dédié à l’auto-hébergement de courriels avec YunoHost. Pour l’instant, c’est un labo, pas encore ma messagerie principale.
• Vaultwarden
  Super outil de gestion de mots de passe… mais :
  • il fait doublon avec le gestionnaire intégré à mon navigateur,
  • c’est une brique ultra sensible,
  • je veux d’abord tester, sur le temps long, que :
    • les sauvegardes fonctionnent,
    • les mises à jour se passent bien,
    • la réactivité en cas de faille de sécurité est raisonnable.

Mon plan :
→ sauvegarder mes mots de passe navigateur,
→ désactiver cette fonction dans le navigateur,
→ n’utiliser que Vaultwarden pendant un moment,
→ voir si ça remplace vraiment l’outil natif sans me mettre en danger.

7. Les trois gros “points noirs” qui restent

Soyons honnête : je ne suis pas encore au bout de ma quête de souveraineté numérique.

7.1. Immich natif et le support HEIC

C’est mon gros sujet du moment.

• Je veux une alternative solide à Google Photos.
• Immich est, pour moi, la solution idéale.
• Mais la version YunoHost ne gère pas encore le HEIC.
• Je garde donc une instance Docker Immich à part, avec :
  • mises à jour manuelles en ligne de commande,
  • maintenance séparée,
  • cycle de release différent de celui de YunoHost.

Tant que je n’ai pas une version native YunoHost + HEIC, je reste dans ce compromis un peu bancal. J’ai également une autre solution : m’intéresser d’un peu plus près au fonctionnement de Docker.

7.2. Une vraie alternative à Google Docs

L’autre frustration majeure : les documents collaboratifs.

J’ai testé pas mal de solutions (j’en parle dans un autre article) et, pour l’instant, je n’ai pas trouvé d’alternative qui coche toutes les cases de Google Docs pour mon usage réel :

• collaboration fluide,
• mise en page suffisamment robuste,
• compatibilité avec le monde extérieur.

Donc non, je ne suis pas encore totalement autonome sur ce point.

7.3. La migration vers YunoHost 13 / Debian Trixie

Dernier sujet d’inquiétude : la prochaine grosse migration.

• Debian 13 “Trixie” est sortie, et YunoHost 13, basé dessus, est en bêta.
• Une migration existe déjà depuis les versions récentes de YunoHost 12.x, mais reste marquée comme “testing”.

Concrètement :

• je sais qu’il y aura un risque,
• je sais que je dois avoir une stratégie de « rollback » (mais je ne sais pas encore faire cela)
• je ne m’attends pas à une expérience “100% transparente”.

Mais c’est le jeu : quand on s’auto-héberge, on accepte que les grosses migrations demandent un minimum de préparation. L’idéal, mais je ne sais pas encore le faire, serait d’avoir une copie de mon système actuel sur une autre machine, et de faire la migration vers Yunohost 13 pour voir si tout fonctionne, pour enfin réaliser la « vraie » mise à jour sur mon serveur en production, mais ça c’est dans la théorie car dans la pratique, je ne pense pas avoir les compétences suffisantes.

8. Auto-hébergement : liberté, mais pas de service après-vente

Ce que m’a appris cette migration Umbrel vers YunoHost, c’est surtout ça :

L’auto-hébergement, c’est la liberté mais aussi la responsabilité.

• Si quelque chose casse, il n’y a pas de hotline.
• Il faut accepter les délais entre :
  • la correction par les développeurs de l’app,
  • les tests par l’équipe YunoHost,
  • la disponibilité de la mise à jour dans l’interface.

Et plus mon infrastructure quotidienne dépend de mon serveur (DNS, mails, services du quotidien…), plus cette réalité est visible :

• panne d’électricité,
• disque qui lâche,
• sauvegarde corrompue,
• redémarrage délicat…

Chaque incident potentiel devient un vrai sujet.

9. Le support YunoHost : où trouver de l’aide (et où ne pas la chercher)

Mon retour d’expérience perso sur le support autour de YunoHost :

• IRC : existe, mais je ne l’ai pas trouvé très vivant.
• Matrix : beaucoup plus actif. C’est là que j’ai eu le plus d’échanges utiles.
• Forum : très bien, mais la procédure pour créer un ticket (logs, contexte, etc.) peut être décourageante quand on arrive déjà en bout de course après avoir :
  • cherché sur les moteurs de recherche,
  • fouillé la doc,
  • questionné l’IA.

Quand j’arrive sur le long formulaire du forum, je suis parfois au bout de mon énergie.

Côté réseaux sociaux :

• X (Twitter) : inutile pour YunoHost, d’après mon expérience.
• Mastodon : quelques annonces, mais c’est surtout la communauté qui aide, pas forcément l’équipe YunoHost elle-même.

Et c’est logique : YunoHost est un projet libre, non lucratif, maintenu par des bénévoles.
On ne peut pas attendre le même niveau de support qu’une solution propriétaire payante.

En revanche, on peut :

• contacter directement les développeurs de certaines apps,
• contribuer à notre tour (traductions, documentation, retours de bugs),
• participer à la communauté pour faire circuler l’info.

C’est ce que j’ai fait, par exemple, autour d’Immich ou de traductions en français : donner un peu de temps, pas seulement consommer.

10. Alors, faut-il quitter Umbrel pour YunoHost ?

Si vous êtes arrivé jusqu’ici, la question est probablement dans un coin de votre tête.

Voici ma réponse honnête :

Quand Umbrel suffit

• Vous débutez,
• Vous voulez tester quelques services sans trop réfléchir,
• Vous ne voulez pas (encore) plonger dans la logique DNS / mails / multiservices.

Dans ce cas, Umbrel reste une très bonne rampe de lancement.

Quand YunoHost devient logique

YunoHost commence à s’imposer quand :

• vous voulez aller un cran plus loin dans l’auto-hébergement ;
• vous cherchez une solution plus cohérente pour :
  • gérer plusieurs domaines,
  • installer des apps variées,
  • centraliser sauvegardes et diagnostics ;
• vous êtes prêt à :
  • lire un peu plus de documentation,
  • accepter quelques migrations “sérieuses”,
  • apprendre à tester vos sauvegardes.

Pour moi, la migration Umbrel vers YunoHost est un succès, mais :

• elle m’a demandé du temps,
• elle m’a forcé à reconnaître mes limites,
• elle m’a appris à être plus humble avec Linux, avec l’IA et avec les backups.

La prochaine étape ?
Garder ce serveur en vie le plus longtemps possible sans tout faire sauter.
Et, peut-être un jour, regarder mon homelab en me disant :
“Ok, là, je peux couper Google Docs, Docker pour Immich, et arrêter de me demander si j’ai oublié un port ouvert quelque part.”

En attendant, la souveraineté numérique reste ce qu’elle a toujours été pour moi :
une suite de petites victoires fragiles, mais extrêmement satisfaisantes.

Si vous êtes arrivé jusque-là, d’abord merci. Ensuite, j’ai vraiment besoin de vos retours : si vous voyez des pistes pour améliorer ma configuration, dites-le-moi en commentaire. Et surtout, si j’ai raconté des bêtises techniques ou fait des approximations, n’hésitez pas à me corriger : je suis totalement ouvert à la critique, je n’ai aucun problème à reconnaître mes erreurs et à me remettre en question. Je ne me prends pas pour un admin système, j’essaie juste d’apprendre en chemin, et vos retours font clairement partie de cet apprentissage.