Souverain

Il y a quelques mois, un premier cap avait été franchi avec la migration d’Umbrel vers YunoHost. Cet article racontait surtout un basculement : passer d’un environnement rassurant, mais parfois trop opaque, à une solution pensée pour simplifier l’administration serveur et démocratiser l’auto-hébergement, tout en restant ancrée dans l’univers Debian et du logiciel libre.

Depuis, mon « laboratoire » a continué d’évoluer. Pas de révolution spectaculaire, pas de promesse magique non plus. Plutôt quelque chose de plus intéressant : une progression lente, concrète, parfois bancale, mais formatrice. Et s’il fallait résumer cette nouvelle étape en une phrase, ce serait peut-être celle-ci : l’auto-hébergement devient vraiment passionnant au moment où il cesse d’être un simple test technique pour devenir un exercice d’autonomie.

YunoHost, confirmé sans ambiguïté

Sur un point au moins, le doute n’existe plus pour moi : YunoHost reste, et il restera. Umbrel avait joué son rôle de porte d’entrée. L’outil a permis de commencer, de prendre confiance, d’oser mettre les mains dans un serveur maison. Mais le plafond de verre a fini par apparaître. Avec YunoHost, quelque chose s’est débloqué : davantage de compréhension, davantage d’autonomie, et surtout le sentiment de ne plus seulement utiliser un système, mais de commencer à l’habiter. YunoHost se présente lui-même comme une distribution serveur conçue pour simplifier l’administration, avec une interface web, un catalogue d’applications, la gestion des certificats SSL, des sauvegardes et même une brique « courriel » complète.

Il faut toutefois reconnaître une chose, avec humilité : ce type de récit risque toujours de froisser les administrateurs système de métier. Elena Rossini, dans l’un de ses guides pour débutants sur YunoHost (en anglais), l’écrit très bien : « ⚠️ Avertissement : cet article risque de déplaire aux administrateurs système. » La formule est juste. Car ici, il n’est pas question de se faire passer pour un expert. Le métier d’admin système n’est pas le sujet. L’objectif est plus modeste, et sans doute plus honnête : comprendre les concepts, reproduire au plus près ce qui semble propre, apprendre à corriger ses erreurs, et progresser sans jouer un rôle.

Cette logique d’apprentissage a porté ses fruits. Aujourd’hui, ce ne sont plus un, mais trois serveurs qui tournent à la maison. Le choix s’est porté sur des mini-PC reconditionnés, pour éviter une facture énergétique absurde et garder une infrastructure cohérente avec le discours sur la sobriété numérique. Les machines continuent par ailleurs à s’éteindre automatiquement la nuit, et jusqu’ici cela n’a pas créé de contrainte évidente. Sur ce point, les retours d’expérience d’autres auto-hébergeurs seraient d’ailleurs précieux : le débat reste ouvert en commentaire.

Il y a aussi une petite fierté très concrète dans cette progression : le recyclage d’un ancien onduleur. Une batterie neuve, quelques réglages, et voilà désormais une quinzaine de minutes de sécurité en cas de coupure, avec arrêt propre des serveurs quand le niveau devient critique. Cela paraît modeste. Pourtant, dans un parcours d’auto-hébergement, ces petites victoires comptent beaucoup. Elles marquent le moment où l’on cesse simplement d’installer des services pour commencer à penser continuité, résilience et dépendances.

Le vrai point faible : les sauvegardes

Le gros point noir, lui, n’a pas disparu. Il s’est même imposé comme la question centrale : la sauvegarde existe, mais la restauration n’a pas encore été réellement éprouvée. Et c’est précisément là que se niche le danger.

Oui, des sauvegardes automatiques partent vers un NAS depuis le serveur le plus sensible. Oui, le réflexe de protéger les données est installé. Mais tant qu’une restauration complète n’a pas été testée, une part de cette sécurité reste théorique. C’est le genre de vérité qu’on préfère repousser, souvent par peur de provoquer soi-même la catastrophe qu’on cherche justement à éviter. Rescuezilla, de son côté, se présente comme un outil graphique d’image disque et de restauration, amorçable depuis une clé USB, pensé justement pour rendre ces opérations plus accessibles. Ce pourrait être une piste sérieuse pour enfin passer du principe à l’épreuve réelle.

Au fond, l’auto-hébergement oblige à une forme de maturité. Il pousse à regarder en face ses angles morts. Et celui-ci est évident : tant que la restauration n’est pas maîtrisée, l’autonomie reste partielle.

Ce qui fonctionne, et qui est de moins en moins négociable

Dans les services qui se sont installés durablement, LaSuite Meet (Visio) fait partie des évidences. L’outil est utilisé plusieurs fois par semaine, sans friction, sans mise en scène, ce n’est pas une usine à gaz. Et c’est peut-être cela, le meilleur compliment possible pour une brique numérique : quand l’interlocuteur en face est presque surpris par la simplicité du service. Visio est d’ailleurs présenté par DINUM comme une solution de visioconférence souveraine, ouverte, sécurisée et hébergée en France.

Docs, dans le même écosystème, reste plus ambivalent. L’outil a de vraies qualités et son positionnement est clair : un espace d’écriture collaborative simple, pensé pour rédiger, partager et publier. Il entre progressivement dans mes usages. Mais l’expérience d’auto-hébergement rappelle aussi une réalité moins glamour : entre la promesse d’un logiciel et la qualité de son paquet sur une distribution comme YunoHost, il peut subsister un écart frustrant. Quand l’insertion d’une image dans un document ne fonctionne toujours pas, l’adoption reste freinée, même si le potentiel est là.

Karakeep, lui aussi, mérite de rester. La solution pour gérer les favoris est bonne, pratique, et franchement convaincante à l’usage. Mais il faut y ajouter un avertissement de terrain : avant chaque mise à jour, mieux vaut prévoir une sauvegarde ou un export. Ce n’est pas une posture paranoïaque, c’est un retour d’expérience. Trop souvent, la mise à jour tourne mal et impose une désinstallation, une réinstallation, puis une réimportation des données.

Et puis il y a Mastodon. Sans doute la brique la plus symbolique de tout cet ensemble. Parce qu’au-delà du service lui-même, une instance Mastodon auto-hébergée donne une sensation très particulière : celle d’être enfin maître chez soi dans un espace social numérique. Mastodon stocke par défaut les fichiers sur le système de fichiers du serveur, et sa documentation rappelle bien que les médias et caches peuvent vite prendre de la place. Les versions récentes proposent certes des réglages depuis le terminal via des commandes de maintenance, mais sur une petite installation maison, tout cela reste encore trop technique dès qu’il faut vraiment reprendre la main sur l’espace disque.

Le grand chantier toujours repoussé : le courriel

S’il reste un sujet qui concentre à la fois frustration, prudence et appréhension, c’est bien l’hébergement du courrier électronique.

Le passage à l’acte n’a pas encore eu lieu. Pas sérieusement. L’idée serait plutôt d’avancer un jour, par petits pas, avec un domaine dédié, sans exposer d’emblée une adresse critique. Car le courriel n’est pas un service comme les autres. La marge d’erreur y semble plus faible. Il y a la peur du spam, la peur du mauvais paramétrage, la peur d’atterrir dans les indésirables, la peur aussi d’un espace disque mal géré ou d’une panne au mauvais moment.

Une inquiétude revient souvent : un serveur coupé la nuit risque-t-il de faire perdre les messages reçus pendant ce laps de temps ? Sur le fond, le protocole SMTP est plus tolérant qu’on l’imagine. Les serveurs expéditeurs sont censés mettre les messages en file d’attente et réessayer plus tard. La RFC 5321 recommande même des tentatives espacées d’au moins 30 minutes et un abandon seulement après plusieurs jours, généralement au moins quatre à cinq. Cela ne rend pas l’auto-hébergement mail simple pour autant, mais cela évite au moins une idée fausse : un serveur de courriel indisponible quelques heures ne signifie pas automatiquement des messages perdus.

Le contexte, en revanche, ne me rassure pas. Google a renforcé ses exigences depuis le 1er février 2024 pour tous les expéditeurs qui écrivent vers Gmail, avec SPF ou DKIM, DNS cohérents, TLS et contrôle du taux de spam. Pour les expéditeurs volumineux, les contraintes montent encore d’un cran. Yahoo a suivi la même tendance, en demandant notamment l’authentification du courrier, un DNS valide et, pour les envois importants, SPF, DKIM et DMARC. Autrement dit : même pour un petit auto-hébergeur, l’époque ne pousse pas à l’improvisation. Je vous invite d’ailleurs à regarder la vidéo de Benjamin Bayart avec Quentin Adam, qui évoquent justement ce sujet, ainsi que le Fediverse.

C’est d’ailleurs pour cela qu’avant de basculer un jour le courrier en auto-hébergement, la partie sauvegarde et restauration devra être sérieusement maîtrisée. Tant que ce socle n’est pas solide, la tentation de « laisser faire les professionnels » reste parfaitement compréhensible.

Le Fediverse, cette fois comme terrain d’expérimentation concret

Ces derniers temps, le vrai centre de gravité s’est déplacé vers un autre sujet : le Fediverse.

Mastodon, d’abord, est validé. L’outil fonctionne, il est compris, il est assumé. Et surtout, il a montré qu’il était possible, même sans bagage d’admin système, de déployer et maintenir un service fédéré à domicile avec un niveau d’autonomie déjà très satisfaisant.

Pixelfed, en revanche, raconte une autre histoire. L’installation avance bien, le paquet existe dans le catalogue YunoHost, et l’idée d’une alternative fédérée à Instagram est évidemment séduisante. Mais la question de la migration reste, pour l’instant, un vrai point faible. Le sujet n’est pas bloquant dans l’immédiat avec seulement deux photos publiées sur une instance de test, mais il devient important dès que l’on réfléchit à long terme. Migrer proprement d’une instance à une autre, sans perdre le fil de son usage, devrait être une évidence dans un univers qui fait de l’interopérabilité et de la fédération un argument central. Or, même dans les discussions du dépôt Pixelfed, des utilisateurs décrivent une procédure vague, difficile à déclencher et parfois incomplète.

Le message, au fond, est simple : Pixelfed a des promesses, mais sa pédagogie côté migration n’est pas encore au niveau. Et pour un projet qui prétend ouvrir une voie crédible hors des plateformes centralisées, ce n’est pas un détail.

Dans le même mouvement, un autre chantier s’est ouvert avec Matrix. Plus exactement avec Tuwunel, qui se présente comme un serveur Matrix alternatif, évolutif, économique, écrit en Rust, pensé comme une alternative plus scalable et moins coûteuse à Synapse (maintenant Element Synapse). Le choix de Tuwunel s’est donc fait dans une logique de légèreté perçue et d’expérimentation, tout en restant ouvert à la contradiction (en commentaire) si l’analyse mérite d’être corrigée par des utilisateurs plus aguerris du protocole.

Le reverse proxy, ou comment plusieurs serveurs ont commencé à cohabiter

Avec plusieurs serveurs à la maison, une difficulté très concrète s’est imposée : un même port entrant sur un routeur ne peut pointer que vers une seule machine à la fois. Dit autrement, si un service web public sur le port 80 ou 443 doit être servi par plusieurs machines internes, il faut un intermédiaire capable de recevoir la requête et de l’orienter vers le bon serveur. C’est précisément le rôle d’un proxy inverse et le paquet Reverse Proxy de YunoHost est justement conçu pour exposer un autre service web, y compris en HTTPS, vers une destination interne.

Le plus intéressant, ce n’est pas vraiment la définition du reverse proxy, mais le moment où l’on comprend à quoi il sert face à une situation concrète.

Dans mon cas, la mise en place s’est faite en plusieurs étapes très simples à comprendre une fois le principe assimilé.

D’abord, sur le serveur qui est directement exposé à Internet depuis le routeur, il a fallu créer dans YunoHost le sous-domaine qui servira à publier le service, puis lui associer un certificat SSL avec l’option Let’s Encrypt. Cette étape est importante, car c’est ce serveur qui recevra les connexions venant de l’extérieur.

Ensuite, sur le second serveur, celui qui héberge réellement l’application, il a fallu créer exactement le même sous-domaine dans YunoHost. En revanche, cette fois, il n’était ni possible ni utile d’y ajouter un certificat SSL. Ce second serveur n’étant pas exposé directement sur le port 80 du routeur, c’est le premier serveur qui joue le rôle d’intermédiaire.

Une fois cela fait, retour sur le premier serveur, dans le catalogue d’applications YunoHost, pour installer l’application Reverse Proxy.

Au moment de l’installation, voici les champs que j’ai remplis :

• dans Libellé pour Reverse Proxy, il suffit de mettre un nom, celui que vous souhaitez
• dans Choisissez le domaine sur lequel vous souhaitez installer cette application, il faut sélectionner le sous-domaine créé sur les deux serveurs
• dans Choisissez le chemin d’URL (après le domaine) où cette application doit être installée, il faut renseigner simplement /
• dans Emplacement de destination (unix:/fichier pour socket), il faut indiquer l’adresse du serveur qui héberge réellement le service, par exemple https://192.168.0.3
• dans Qui doit avoir accès à cette application ? (Ceci peut être modifié par la suite), il faut choisir Visiteurs, si l’on veut que le service soit accessible publiquement et sans avoir besoin de s’identifier.
• enfin, dans Dossier pour les fichiers statiques, il est possible de laisser le champ vide.

À ce stade, le reverse proxy est en place. Mais pour que le service fonctionne aussi correctement à la maison, sur le réseau local, il a fallu ajouter une dernière étape. Dans mon cas, comme j’utilise AdGuard Home comme serveur DNS local, j’ai ajouté une Réécriture DNS. Cela permet d’indiquer que le nom de domaine du service doit pointer vers l’adresse IP du serveur concerné sur le réseau local. Grâce à cela, plus besoin de modifier les fichiers hosts sur chaque appareil, ni de taper l’adresse IP manuellement dans le navigateur.

Et c’est là que tout a commencé à devenir vraiment clair : une fois cette configuration terminée, le service était accessible aussi bien depuis la maison que depuis l’extérieur.

Le résultat a quelque chose de très satisfaisant : d’un côté, le service devient accessible proprement depuis la maison, de l’autre, il reste joignable depuis l’extérieur après vérification en 4G. Et surtout, cette compréhension ouvre de nouvelles perspectives. Car derrière cette réussite technique, il y a en réalité une conséquence plus importante : l’infrastructure peut commencer à se répartir intelligemment, au lieu d’empiler tous les services sur une seule machine (et de prendre trop de risques en cas de panne …).

Ce que cette progression change pour la suite

En comprenant mieux comment répartir les services entre plusieurs serveurs, de nouvelles perspectives deviennent possibles. C’est précisément dans ce cadre qu’Immich m’apparaît aujourd’hui comme une option beaucoup plus crédible. L’idée de remplacer sérieusement Google Photos existe depuis longtemps, mais jusqu’ici, installer un service aussi lourd sur la même machine que d’autres briques sensibles me paraissait trop risqué. Il y avait trop de dépendances, trop de concentration de services dans un seul serveur, et donc trop de chances qu’une panne ou une mauvaise manipulation fragilise l’ensemble.

Désormais, la perspective change. Plus l’apprentissage progresse, plus l’infrastructure elle-même appelle une nouvelle organisation. Non pas pour faire plus compliqué, mais pour éviter qu’un seul incident mette à terre toute l’autonomie patiemment construite.

Conclusion

Il faut donc garder une forme de lucidité et d’humilité. Sur le papier, tout cela a quelque chose de très séduisant. Dans la pratique, cela a un coût. Même en essayant de rester mesuré avec des mini-PC reconditionnés, il y a le prix des machines, l’électricité, l’onduleur, qui peut d’ailleurs coûter plus cher qu’un des serveurs et surtout le temps.

À ce stade, il serait malhonnête d’affirmer que tout cela est déjà rentable. Ce n’est pas encore certain. En revanche, une chose devient plus claire avec l’expérience : si demain une solution équivalente, plus simple et moins coûteuse se présente, il n’y aurait aucune raison d’en faire une question dogmatique. L’objectif de départ n’a jamais été de sanctifier l’auto-hébergement. L’objectif, au départ, consistait à tester, comprendre et apprendre, mais avec une idée plus profonde en tête : faire émerger, quand cela fonctionne, de vraies solutions d’usage, capables de réduire durablement certaines dépendances aux GAFAM.

Et rien que pour cela, le chemin valait déjà la peine d’être emprunté.