Pourquoi j'ai décidé de tout auto-héberger (et pourquoi je ne reviendrai jamais en arrière)

Pendant longtemps, je me suis reposé sur les services des autres. J’utilisais Dropbox ou Skydrive (l’ancien OneDrive) pour mes fichiers, et Spotify ou Deezer pour ma musique.

Puis un jour, j’ai eu un déclic, flou mais persistant : pourquoi ne pourrais-je pas faire tourner tout ça moi-même, chez moi ?

C’était en 2009. J’étais alors en thèse de génétique, mordu d’IT mais purement autodidacte. Je n’avais aucune formation, mais une réelle envie d’apprendre. J’ai donc commencé à expérimenter avec ce que j’avais sous la main.

🚩 2009 – Mes débuts avec un Synology (et ses limites très concrètes)

Tout a commencé avec un Synology DS210j, un petit NAS d’entrée de gamme équipé d’un processeur Marvell Kirkwood à la puissance dérisoire.

Ce fut un bon point d’entrée, mais aussi une sacrée leçon sur les limites du matériel grand public.

Entre l’interface simpliste, le manque de RAM et l’impossibilité de personnaliser réellement les services, j’ai vite atteint le plafond de verre. Il était impossible de lancer plus qu’un petit serveur DLNA ou quelques sauvegardes.

Mais ce premier pas m’avait conquis. J’avais découvert une partie des possibilités de l’auto-hébergement, et j’en voulais plus.

🧱 2011 – Le vrai décollage : HP Proliant N40L

Je suis ensuite passé sur un HP Proliant MicroServer N40L. Une machine modeste, mais robuste et surtout ouverte à l’expérimentation.

J’ai enfin pu mettre les mains dans Linux en ligne de commande. Et qui dit CLI, dit aussi erreurs de débutant… forcément mémorables :

  • rm -rf * au mauvais endroit (RIP mes backups…)
  • chmod -R 777 / parce que “ça réglera les problèmes de droits, non ?”
  • Un fstab mal écrit et un boot qui se termine en emergency shell
  • Des services exposés sans réelle protection, parce que “ça marchait bien comme ça”

Chaque erreur était une occasion d’apprendre. Chaque plantage m’apportait une couche de connaissances supplémentaire : logs, scripts Bash, cron jobs, sécurité réseau…

Mais surtout, ça m’a permis d’apprendre à faire de l’infra, à aimer la CLI, et à en capter toute la puissance. J’ai découvert des concepts essentiels : comment fonctionne un service, comment le superviser, le sécuriser, le relancer automatiquement.

J’ai aussi mis le pied dans des thématiques vastes :

  • La virtualisation (KVM, libvirt…)
  • La gestion des disques sous Linux (RAID, LVM, ext4 vs Btrfs…)
  • La conteneurisation, avec Docker bien sûr, mais aussi avec LXC

Et j’ai surtout appris les limites concrètes de l’auto-hébergement :

  • Comment gérer une IP dynamique (coucou DynDNS et consorts)
  • Pourquoi il est essentiel d’avoir un nom de domaine personnel (je le dis à tout le monde : si tu bosses dans l’IT, réserve ton nom de domaine lié à ton nom de famille, tu me remercieras plus tard)
  • L’importance du PAT et des reverse proxies quand tu es limité à une seule IP et une seule interface réseau sur ton serveur perso

J’avais également installé Subsonic pour streamer ma musique perso à distance, une des premières vraies victoires de ma stack maison.

💡 2012 – La révélation : Proxmox et les conteneurs LXC

Le vrai tournant dans mon parcours a été Proxmox.

Proxmox, c’est la plateforme qui m’a donné les clés de la virtualisation propre : création de conteneurs LXC légers, snapshots, isolation, supervision.

Un vrai terrain de jeu pour comprendre, expérimenter, documenter… et “casser” sans stress.

Les conteneurs LXC m’ont ouvert une nouvelle dimension. Un service = un conteneur. C’est propre, modulaire, facile à déployer et à restaurer. En un clic (ou presque), je pouvais faire tourner :

  • Gitea pour mes projets perso
  • Uptime Kuma pour le monitoring
  • Jellyfin pour mon media center
  • Home Assistant pour ma domotique

Et tout ça sur la même machine. Avec une stabilité que je n’aurais jamais crue possible sans un “gros cloud”.

🌐 2013 – L’étape suivante : la Kimsufi à 3 € / mois

À mesure que mes services prenaient de l’ampleur, l’auto-hébergement à la maison atteignait ses limites : coupures électriques, box capricieuse, bande passante famélique.

J’ai alors sauté le pas vers une Kimsufi à 3 € par mois. Une offre d’entrée de gamme chez OVH, mais largement suffisante pour héberger tout ce qui nécessitait :

  • Une meilleure disponibilité
  • Une IP fixe et fiable
  • Une bande passante décente

Et surtout… la tranquillité d’esprit de ne pas dépendre de mon installation personnelle pour faire tourner des services essentiels.

Pendant près de 10 ans, cette Kimsufi a été le prolongement de mon infra perso, mais avec les avantages du cloud, même minimaliste.

J’en ai profité pour héberger tout ce que je considérais comme essentiel à mon usage quotidien :

  • Seafile pour gérer mes documents, façon Dropbox
  • Mes sites web personnels (quand j’en avais encore)
  • FreshRSS pour suivre mes flux RSS (que j’utilise toujours)
  • Syncthing pour synchroniser mes fichiers entre machines (et notamment les photos sur mon téléphone et ceux de ma famille)
  • et j’en oublie…

🏗️ 2025 – Ma stack actuelle

Aujourd’hui, je n’ai plus de Kimsufi. Toute mon infrastructure est de nouveau auto-hébergée à la maison, mais de façon beaucoup plus robuste et organisée. Et il faut dire que nos réseaux domestiques ont aussi bien changé, merci la fibre.

J’utilise à présent deux serveurs Proxmox :

  • Mon fidèle HP Proliant N40L, toujours en service, qui me permet de gérer surtout mes baies de disques en 3.5 : pas le plus économique en termes d’énergie, mais plus évolué qu’une simple exposition de disques sur le réseau via un NAS simple.
  • Un serveur plus moderne basé sur un NUC avec un Intel Atom N100.

Ma stack tourne majoritairement sur du LXC, avec une particularité :

Du Docker dans des conteneurs LXC, pour combiner la flexibilité de Docker avec la simplicité de snapshot et de backup des conteneurs Proxmox.

Les workloads les plus lourds (comme Jellyfin pour le transcodage vidéo) tournent sur le NUC, afin d’utiliser le GPU intégré.

Et j’ai continué à remplacer les services cloud grand public par des alternatives auto-hébergées :

  • Readeck pour remplacer Pocket (pas merci Mozilla)
  • Kopia pour les backups (en complément de Borg)
  • Vaultwarden comme alternative à Bitwarden
  • Navidrome pour streamer ma musique
  • Et bientôt Colanode, pour voir si je peux me passer de Notion

Ce que l’auto-hébergement m’a vraiment apporté

Au-delà du simple fait de posséder mes données, l’auto-hébergement m’a appris à :

  • Comprendre en profondeur comment fonctionnent mes outils et services. Ce n’est plus de la magie noire, mais du concret ; je peux intervenir en cas de problème.
  • Aimer la ligne de commande : c’est un outil puissant, indispensable, et surtout pédagogique.
  • Approfondir des sujets vastes comme la virtualisation, la gestion des systèmes de fichiers sous Linux, et la conteneurisation (Docker et LXC).
  • Gérer les contraintes du monde réel : IP dynamiques, reverse proxies, sécurisation, sauvegardes.
  • Prendre le contrôle total de mes données et de mon environnement, avec la sérénité que cela apporte face à la dépendance aux fournisseurs tiers.
  • Développer une culture du dépannage, de la documentation et de l’apprentissage continu.

Mes conseils pour se lancer

L’auto-hébergement peut sembler intimidant, mais il faut juste commencer petit et monter en puissance progressivement :

  • Un vieux laptop pour tester Docker et exposer ses premiers services.
  • Un Raspberry Pi pour un serveur à faible consommation, pouvant tourner 24/7 sans trop de frais.
  • Puis un NUC ou un serveur home-made quand tu veux monter en puissance, avec des outils comme Proxmox, ou même un Kubernetes auto-géré.

L’essentiel est de ne pas avoir peur de casser, d’apprendre de ses erreurs, et surtout de s’amuser à construire son propre univers numérique.

Conclusion

L’auto-hébergement est bien plus qu’une simple démarche technique : c’est un engagement vers l’indépendance numérique, la compréhension de ses outils, et la souveraineté sur ses données.

Alors, prêt à franchir le pas ?