- Met l’accent sur l’expérience et l’importance de l’indépendance technique et du self-hosting
- Explique que la possession de son domaine et l’autonomie dans l’exploitation de son blog offrent de grands avantages à long terme pour la carrière et le développement personnel
- Évoque la valeur de la communauté et de l’apprentissage que l’on retire en partageant ses connaissances et son code dans un écosystème open source ouvert
- Présente la mise en place d’un homelab et divers outils open source auto-hébergés, en soulignant la liberté ressentie lorsqu’on les utilise réellement hors des limites des services sur abonnement
- Souligne l’impact positif du partage de contenu basé sur Markdown et de l’esprit open source sur l’écosystème logiciel et le renforcement des compétences individuelles
Introduction : la valeur de l’indépendance technique et du fait de construire soi-même
- En voyant PewDiePie publier une vidéo où il installe Arch Linux et fabrique lui-même des produits basés sur l’open source, l’auteur a été amené à réfléchir de nouveau à l’importance du self-hosting et de l’indépendance technique, c’est-à-dire de créer quelque chose qui lui appartient vraiment
- Le domaine, le blog et les services que l’on gère soi-même deviennent des actifs qui s’accumulent sur le long terme, avec une portée bien plus grande qu’un simple changement de plateforme
La force de posséder son domaine et de gérer son blog soi-même
- À celles et ceux qui veulent recommencer à écrire ou qui réfléchissent à leur recherche d’emploi, l’auteur recommande d’abord d’acheter leur propre domaine et de gérer leur blog
- Comme le changement de plateforme entraîne souvent la perte répétée de contenus précieux et de domaines, il est important de posséder directement son domaine et de continuer à accumuler du contenu à la même adresse
- Avec le temps, les backlinks, les anciens articles et les investissements consentis se transforment en crédibilité durable
L’expérience de self-hosting et l’apprentissage de l’auteur
- L’auteur héberge lui-même divers services, comme son blog, son second cerveau, ses livres et sa liste d’abonnements, en utilisant GoHugo, Listmonk, Memberstack, etc.
- Il développe progressivement ses compétences techniques à travers la mise en place d’un environnement homelab, SSH, les sauvegardes, la gestion des photos, Gitea, ainsi que l’automatisation des proxys et des certificats SSL
- Même si cela peut sembler difficile au départ, la sensation d’apprendre et d’accomplir quelque chose constitue la plus grande récompense du processus
La valeur de l’open source et de la communauté
- L’usage et la contribution aux logiciels open source rendent l’indépendance technique possible, et l’auteur publie également ses propres connaissances et outils sur GitHub
- Dans l’open source, les différentes licences permettent à tout le monde d’utiliser librement les logiciels, tout en multipliant les occasions de retours de la communauté et de collaboration
- L’auteur a commencé à être attiré par l’écosystème open source après avoir utilisé un outil BI open source, et aujourd’hui la plupart de ses activités en ligne ainsi que ses écrits sur le data engineering reposent sur cet univers
Linux et Linus Torvalds
- Linux est au cœur des appareils numériques du monde entier, et le fait que Linus Torvalds ne l’ait pas commercialisé a permis sa diffusion massive à l’échelle mondiale
- Torvalds a aussi créé git, devenu un outil indispensable pour tous les développeurs logiciels dans le monde
- En publiant son travail dans l’open source, on permet aux autres d’apprendre, de donner un retour, de contribuer et de créer des liens, ce qui favorise non seulement sa propre progression mais aussi celle de la communauté
Remerciements et outils open source
- L’auteur utilise fréquemment et apprécie particulièrement plusieurs outils open source
- Quartz : alternative open source à Obsidian Publish
- GoatCounter : outil d’analyse de trafic de site anonymisé
- Listmonk : système open source de gestion de listes de newsletter
- listmonk-rss : envoi automatique d’e-mails lors de la publication d’un article de blog
- Exemples de logiciels open source recommandés pour un homelab :
- Paperless : numérisation et gestion de documents
- PhotoPrism : gestion de photos auto-hébergée basée sur l’IA
- Pi-hole : blocage des publicités à l’échelle du réseau
- Nginx Proxy Manager : routage de domaines et automatisation SSL
- Audiobookshelf : serveur d’audiobooks et de podcasts
- Calibre : gestion de livres électroniques
- Syncthing : synchronisation de fichiers distribuée
- Gitea : service Git auto-hébergé léger
Expérimenter suffit, même avec du matériel peu coûteux
- Il n’est pas nécessaire d’avoir un serveur récent et onéreux : un serveur client d’occasion et un bon système d’exploitation suffisent largement pour monter un homelab
- L’auteur accorde une grande importance au plaisir d’apprendre et au sentiment d’indépendance que procurent la construction et l’exploitation directes
Indépendance technique et risques liés aux plateformes
- En construisant et en hébergeant soi-même, on s’affranchit des risques liés aux grands services comme Google ou Apple, qu’il s’agisse de changements de fonctionnalités ou d’arrêts de service
- Le véritable avantage de la Tech Independence réside dans la liberté de concevoir et de modifier soi-même son propre environnement et ses caractéristiques
Conclusion et importance de Markdown
-
L’auteur insiste sur la joie de l’open source, du fait maison et du partage d’expérience, tout en soulignant que l’ensemble de ses solutions et de sa production de contenu repose sur Markdown
-
Markdown garantit la compatibilité entre différentes plateformes et est devenu un outil standard de la culture open source et du partage des connaissances
-
Davantage d’articles de blog sur le data engineering, de notes de second cerveau et le livre actuellement rédigé publiquement sont tous disponibles sur ssp.sh et GitHub
-
Le partage d’expérience et la discussion avec les lecteurs sont toujours les bienvenus
1 commentaires
Discussion sur Hacker News
Désolé pour l’auto-promo, mais je voulais dire qu’en self-hosting, il n’est pas forcément nécessaire d’acheter du nouveau matériel. Après quelques années, un vieux portable devenu trop lent sous Windows peut encore offrir des performances tout à fait suffisantes comme serveur Linux. Il y a de fortes chances de trouver chez soi ou chez des amis un ancien laptop qui traîne, et de mon côté j’utilise encore très bien un portable i3 de 2011 à deux personnes, sans qu’en 2025 une mise à niveau paraisse nécessaire. Les ordinateurs portables ont aussi une bonne efficacité énergétique en veille, ce qui en fait à long terme un choix encore plus rationnel qu’un desktop. Je pense qu’un laptop est un excellent premier serveur pour les débutants en self-hosting. (À noter que les portables n’ont pas d’UPS intégré, donc si vous comptez le laisser branché 24 h/24, je recommande vraiment de retirer la batterie.)
Article sur la réutilisation de vieux matériels
J’avoue que j’écris ce message en ce moment même sur un Acer vieux de 13 ans sous Linux Mint XFCE. J’ai toujours trouvé dommage de jeter les anciens appareils, donc même après avoir acheté un nouveau portable, j’ai branché l’ancien à la TV du salon en HDMI avec un clavier/trackpad sans fil Logitech K400+ à 25 $. Ça suffit largement pour naviguer sur le web, YouTube et Netflix, et quand j’en ai besoin j’ouvre aussi VS Code ou Thunderbird. Je peux même lancer sans problème des jeux indé sur Steam avec une manette. Si les laptops Framework arrivaient dans mon pays, ce type de réutilisation se développerait encore davantage ; malheureusement, ils ne livrent toujours pas chez moi
Là où j’habite (un ensemble d’immeubles de 250 foyers en Suède), il est courant que les gens jettent de vieux ordinateurs dans la zone de déchets électroniques. Je fais du repérage plusieurs fois par jour quand je promène le chien, un peu comme un personnage de Mad Max. J’assemble des pièces venant de plusieurs machines, j’y installe debian et je fais tourner des conteneurs docker pour toutes sortes d’usages. J’ai même offert à mes parents, cousins et amis des serveurs Frankenstein montés de cette manière. C’est incroyable de voir combien de machines encore utilisables les gens jettent. Je tombe aussi assez souvent sur des portables sans mot de passe, et quand on ouvre la session Windows, on trouve plein de photos de famille. Il m’est même arrivé de trouver des iPhone d’il y a environ cinq ans encore déverrouillés. On ne peut que se dire que le monde est vraiment étrange
J’ai aussi un Mac-Mini de 2012 à la maison. On me l’a offert, donc je n’avais pas l’intention de passer à Mac, et même s’il n’est pas très puissant, ses performances restent correctes. Je l’ai redémarré à Noël dernier : il était déjà très lent avec l’OS de base, et après mise à jour de macOS il est devenu pratiquement inutilisable. J’ai suivi un tuto YouTube pour remplacer le disque par un SSD, installé Debian, puis CasaOS (un OS/UI de serveur domestique basé sur le web), et maintenant j’y accède à distance via Wireguard pour streamer ma musique avec Navidrome. Je ne maîtrise pas encore très bien Docker, mais j’apprends petit à petit, notamment le mapping de PATH et d’autres choses
Si le marché de l’occasion ne vous rebute pas, je suis en train de monter pour moins de 2 000 euros un nœud Proxmox avec un Threadripper 3e génération 32 cœurs / 64 threads, 256GB ram, 2x10G, 2x2.5G, une interface 1G dédiée à l’administration IPMI, et 64 lignes PCIe gen 4
Avec une configuration en dessous de RAID6/RAIDZ2, il existe un risque assez important de perte de données. La plupart des portables n’ont pas assez de ports SATA/M.2 pour mettre en place une configuration avec parité, donc si vous voulez une vraie tolérance aux pannes de niveau RAID, il faudra au final du matériel neuf. Et si vous respectez le principe de répartir les sauvegardes sur au moins deux emplacements physiques, le mieux est idéalement de cumuler les deux
Je comprends pourquoi on veut faire du self-hosting, mais je comprends tout autant pourquoi on n’en a pas envie. C’est une activité pénible : il faut mettre à jour docker, si quelque chose casse c’est à moi seul de le réparer, et même quand tout fonctionne, on a souvent une impression de bricolage plutôt que de fluidité. Aujourd’hui, la liste des outils self-hosted qui marchent vraiment bien et me font gagner du temps est très courte (le premier étant firefly), et il y a eu beaucoup de cas où j’ai tenté une installation, ça a cassé, puis j’ai fini par abandonner. Ces temps-ci, quand une entreprise respecte la vie privée et propose un prix correct, je paie simplement pour utiliser son produit
Je pense que Docker est la source du problème. Docker ajoute des couches d’indirection inutiles pour le stockage, le réseau, etc., et pour les mises à jour de sécurité il faut reconstruire les conteneurs ou espérer que quelqu’un d’autre le fasse. Si possible, mieux vaut s’en tenir à des services distribués sous forme de paquets de l’OS upstream ou de binaire unique (comme on le voit souvent dans les projets en Go), car c’est plus simple à exploiter sur le long terme
Je me demande pourquoi il faudrait absolument mettre Docker à jour. Dans mon cas, cela fait plus d’un an que je l’exécute sans mise à jour. Quant aux mises à niveau des images Docker, j’y passe à peine 15 minutes par mois. Et dans les faits, les entreprises qui respectent la vie privée sont extrêmement rares, et il est difficile de croire qu’elles conserveront indéfiniment des politiques réellement indépendantes au fil des années
Il est déjà extrêmement difficile de trouver une entreprise qui respecte la vie privée tout en ayant des prix corrects
Je serais curieux de savoir sur quels projets vous avez eu des problèmes. Dès qu’un projet fournit même un Docker Compose, j’ai l’impression que presque tout fonctionne sans difficulté. Et je pars du principe que presque toutes les entreprises finissent un jour par trahir votre confiance. Donc autant ne même pas leur laisser cette occasion. Moi, j’auto-héberge Home Assistant, et cette entreprise est assez particulière en ce qu’elle a même mis en place des garde-fous juridiques pour éviter d’agir contre les intérêts de ses utilisateurs
J’auto-héberge la plupart de ce dont j’ai besoin, mais récemment j’ai connu une vraie crise quand ma connexion Internet s’est mise à décrocher par intermittence. Je me suis retrouvé à me poser ces questions
Au final, cela m’a fait comprendre que j’ai besoin d’archiver davantage de documentation, et que NixOS est presque inutilisable hors ligne si l’on n’a pas son propre serveur de cache — ce qui est très pénible. Cela dit, cette expérience m’a aussi montré que j’auto-héberge la plupart de ce dont j’ai besoin même sans Internet, et que ma productivité a au contraire beaucoup augmenté dans cet environnement
En auto-hébergeant "devdocs" et en utilisant zeal sous Linux (un lecteur de documentation hors ligne), j’ai réglé une bonne partie du problème de la documentation hors ligne.
devdocs github
site officiel de zealdocs
Chaque panne devient pour moi une occasion d’identifier les faiblesses de mon système. Si c’est un problème upstream inévitable, tant pis, on ne peut pas l’éviter ; mais quand il existe une réponse possible, j’aime établir des scénarios qui équilibrent coût et probabilité, et je trouve ce travail amusant en lui-même
J’ai personnellement poussé cette logique hors ligne à l’extrême. Les périodes de coupure totale d’Internet ont correspondu à mes pics de productivité. J’ai un alias bash qui sauvegarde récursivement des sites entiers avec wget, j’utilise yt-dlp pour télécharger les vidéos que je veux, je garde une copie complète de Wikipédia hors ligne avec Kiwix, mes e-mails sont stockés localement avec prise en charge de la rédaction hors ligne et de la mise en file d’attente pour l’envoi, l’extension SingleFile est efficace pour enregistrer des pages individuelles, et je recommande aussi Zeal comme navigateur de documentation open source
Je compatis sur le problème du « NixOS inutilisable hors ligne sans son propre cache ». Pour n’importe quel logiciel géré par un gestionnaire de paquets, il faut absolument un cache ou une sauvegarde du dépôt. Le fait que le système complet dépende de toute une chaîne de personnes à l’extrémité de l’arbre des dépendances est, à mes yeux, l’un des aspects les plus inquiétants du développement logiciel moderne. Pour les logiciels destinés à l’utilisateur final, je préfère de loin des paquets autonomes qui embarquent toutes leurs dépendances. De toute façon, c’est bien sous cette forme qu’ils finissent stockés sur le disque réel
Kiwix (solution hors ligne pour Wikipédia) et diverses installations de jellyfin sont de puissantes ressources hors ligne. En revanche, des distributions comme NixOS ou Gentoo ont tendance à exiger une connexion Internet continue. Miroiter l’intégralité des paquets est pratiquement irréaliste
À propos du conseil « achète d’abord un domaine », en réalité un domaine, ça se loue ; on ne peut pas vraiment l’acheter. Si un seul paiement échoue, on se fait expulser immédiatement. C’est même assez effrayant. Il y a quelque chose de triste dans cette fragilité de l’identité en ligne
Sur le point « un domaine ne fait que se louer », c’est vrai si l’on n’utilise que la root zone et les registres approuvés par l’ICANN, mais à titre expérimental j’exploite depuis des années mon propre registre avec une root zone personnalisée que je ne partage avec personne. J’ai aussi expérimenté des TLD personnalisés pour refléter dans les noms de domaine tous les systèmes de classification des produits et services du monde, ce qui m’a permis de ressentir très concrètement à quel point les TLD de l’ICANN peuvent être ambigus ou inadaptés
C’est en quelque sorte une limite technique. Si je configure tous mes appareils (c’est-à-dire tous les consommateurs de noms de domaine) pour reconnaître comme “XorNot.com” tout ce qui est signé par une certaine clé publique, on peut remplacer le système. Avec un peu plus de support technique, je pense qu’on pourrait remplacer toute la structure actuelle par une « liste fiable de correspondances clé-nom »
Nous vivons à une époque où l’écosystème des outils de self-hosting a énormément progressé. On peut commencer avec des composants hébergés, puis remplacer chaque élément un par un par des versions auto-hébergées. Mon blog aussi est auto-hébergé sur un serveur à la maison.
En frontal, j’utilise Cloudflare Tunnel, mais auparavant j’ai aussi utilisé nginx+letsencrypt+public_ip, et pour le stockage des données je peux remplacer Cloudflare R2, S3 ou un NAS local selon les besoins (et via FUSE, le mode d’accès reste identique).
En pratique, les seules ressources qu’il faut forcément louer sont le domaine (même si cela ressemble à un achat, ce n’est qu’une location) et la connexion Internet ; le reste est aujourd’hui largement optionnel. Bien sûr, si l’on coupe certains services, cela devient moins pratique, mais le fonctionnement de base reste assuré.
C’est devenu incroyablement plus simple qu’avant. Dans les années 90 et au début des années 2000, un tel environnement outillé était inimaginable.
Le seul vrai inconvénient, c’est que les exigences anti-spam pour l’e-mail sont devenues extrêmement strictes. J’administrais encore moi-même mon e-mail il y a huit ans, mais aujourd’hui j’utilise G Suite
Pour moi, l’enjeu n’est pas « faut-il self-hoster ? », mais « a-t-on la capacité de le faire ? ». Le fait de pouvoir déléguer à d’autres quand on manque de compétences techniques ou qu’on préfère payer me paraît être une approche inclusive. Ceux qui disent simplement « il suffit de payer » sont en réalité ceux qui s’exposent au plus grand risque sur le long terme. Les entreprises d’aujourd’hui conçoivent souvent leurs modèles pour capturer les clients en prenant en otage leur dépendance technique de long terme. Même sans s’intéresser au FOSS, il est vraiment important d’être conscient de la possibilité de changer de fournisseur. Une fois enfermé dans un lock-in, on peut à tout moment subir des conditions abusives. Beaucoup d’entreprises raisonnent exactement de cette manière
J’apprécie beaucoup Zulip comme service open source, auto-hébergeable, proposé aussi en cloud, et permettant la migration dans les deux sens
À une époque où les développeurs abondent et où l’IA augmente fortement, depuis chez soi, la quantité de code de qualité très variable qu’on peut produire, le self-hosting peut clairement devenir une tendance
Même avec seulement les bases de Linux, beaucoup trouvent le self-hosting séduisant non pas par nécessité, mais pour le plaisir et le sentiment d’accomplissement que procure le fait d’exécuter ses propres services.
L’effet le plus important, c’est aussi d’éliminer un risque bien réel : se faire exclure sans raison d’une plateforme dont on dépend totalement. Si vous perdez même votre compte Gmail, les « gens ordinaires » peuvent se retrouver incapables d’accéder à toute leur identité en ligne, à leurs réinitialisations de mot de passe, voire à leurs connexions d’applications. Il y a sûrement sur Hacker News des gens dont la vie deviendrait très compliquée s’ils perdaient leur compte Gmail. Voilà pourquoi je pense qu’au minimum son identité e-mail doit nous appartenir. Et ce principe devrait être appliqué de la même manière à l’hébergement web, AWS, Spotify, Netflix et à tous les autres services en ligne : remplacer simplement un cloud host par un autre ne résout pas vraiment le problème.
Installer un serveur e-mail est facile et bien documenté, mais ce qui manque à mon avis, ce sont des ressources sur l’exploitation réelle au quotidien (surtout pour les problèmes de compatibilité ou la gestion des incidents). Par exemple, si Google place mon serveur sur liste noire, qui faut-il contacter, existe-t-il une procédure pour traiter le message d’erreur, etc. En situation réelle, on manque de points d’appui. Il faudrait un guide expliquant comment réagir correctement face à des facteurs externes déraisonnables comme les blocs d’IP globaux. Le problème n’est pas DKIM, DNS ou les protocoles eux-mêmes, mais la manière de répondre concrètement aux autres entreprises quand on opère réellement un service
Il suffit de posséder son domaine, de le rattacher au fournisseur e-mail de son choix, puis de migrer immédiatement ailleurs en cas de problème. Le domaine lui-même coûte peu cher, et la bonne pratique consiste à ne jamais utiliser l’adresse propre au fournisseur e-mail.
Et ce principe reste valable qu’on héberge soi-même son serveur e-mail ou qu’on utilise un service commercial. Ce sont deux sujets distincts
Le risque est bien réel et clairement identifié, mais je me demande s’il touche vraiment un grand nombre de personnes. Si Gmail a été adopté par tant de monde au départ, c’est parce que la qualité des alternatives existantes s’était fortement dégradée. Les e-mails d’ISP, d’université ou d’entreprise pouvaient disparaître à tout moment. Le self-hosting peut « partiellement » résoudre ce problème, mais si vous n’êtes pas capable de maintenir la sécurité, vous n’avez pas non plus un contrôle total sur un serveur mail que vous administrez vous-même. Il faut surveiller le renouvellement du domaine et bien d’autres choses ; au final, si vous ne faites pas attention, vous perdez aussi votre compte de cette manière. Je comprends donc pourquoi Gmail et quelques grands acteurs restent si populaires. Pour la plupart des gens, c’est encore, à court et moyen terme, la meilleure option en pratique
Quand on fait du self-hosting chez soi, je me demande quel risque est le plus grand : perdre un disque dur ou perdre son compte Gmail. Dès qu’on commence à héberger soi-même, il faut soudain penser à l’espace pour le matériel, à la stratégie de sauvegarde, aux mises à jour, et si l’on tient compte d’une coupure de courant pendant une mise à jour ou une sauvegarde, il faut au final aussi acheter un UPS. Dans mon cas, j’ai même eu un UPS défectueux qui a fini par détruire les disques de mon NAS. Au bout du compte, cela fait tellement de choses à gérer qu’on a moins de temps pour se concentrer sur la vie quotidienne
Je pense que le self-hosting peut au contraire introduire des risques majeurs. Si vous perdez votre clé privée locale ou votre domaine e-mail principal, il n’y a pas de récupération possible. Le 2FA et la récupération de compte sont bien plus pratiques avec des services externes. Je ne suis pas opposé au self-hosting en soi, mais pour la plupart des gens, le chemin le plus sûr est de garantir la possibilité de récupérer leurs comptes
Depuis l’arrivée de l’installateur officiel d’Arch Linux, je pense qu’il est difficile de dire que c’est encore vraiment compliqué. Cela reste une entrée en ligne de commande, bien sûr, mais c’est beaucoup plus simple qu’à l’époque où il fallait se casser la tête sur des calculs complexes de blocs de partition
À la maison, je gère à la fois un cluster Kubernetes de 4 nœuds sur pi et un mini PC Intel N150 avec Portainer.
Parmi les outils open source d’exploitation, ceux-ci ont eu un gros impact sur ma productivité (ils tournent tous dans un environnement conteneurisé)