On s’est habitués à un web “tout-en-un” : ton site sur une plateforme, tes notes dans une appli, tes fichiers dans un cloud, tes flux dans un service… C’est pratique, souvent gratuit, et ça marche très bien — jusqu’au jour où ça change de prix, ça ferme, ça se dégrade, ou ça disparaît.
L’idée qui se répand n’est pas de “prédire la fin d’Internet”, mais de construire une forme de résilience numérique : reprendre une partie de ses outils et de ses données, et les faire tourner sur une infrastructure qu’on contrôle, avec une logique simple, frugale, et durable.
1) Le déclic : “je ne veux plus dépendre d’un seul bouton ON/OFF”
Quand tu publies un site via Netlify, Vercel ou GitHub Pages, tu gagnes une facilité incroyable : push du repo, et c’est en ligne. Pour démarrer, c’est imbattable.
Le problème, c’est l’asymétrie : tu n’es pas propriétaire de la plateforme. Elle peut être rachetée, réorientée, fermer une fonctionnalité, abandonner un produit (et ton stack avec), ou simplement changer ses règles.
C’est là qu’entre une question très “IndieWeb” : qu’est-ce que je peux héberger moi-même, sur du matériel que je contrôle, tout en restant réaliste ?
2) La philosophie : le “permacomputing”, ou faire mieux avec moins
Le terme permacomputing a été proposé en 2020 par Ville-Matias « Viznut » Heikkilä : l’informatique inspirée de la permaculture, qui vise à maximiser la durée de vie du matériel, minimiser l’énergie, et utiliser le calcul quand il “renforce” vraiment l’écosystème au lieu d’alimenter la dépendance.
Ce courant pose une question intéressante :
Où la technologie n’est-elle pas nécessaire ? Où peut-on la retirer ?
Et quand on la garde : comment la rendre plus sobre, plus réparable, plus locale.
Un exemple concret souvent cité : Hundred Rabbits, qui a conçu Uxn, une mini-VM pensée pour tourner sur du matériel très limité (dont des machines type Game Boy Advance ou Raspberry Pi Pico).
3) Le plan réaliste : apprendre sur une “petite” machine, puis rapatrier chez soi
Avant de tout héberger “à la maison”, on peut apprendre sur un serveur simple chez DigitalOcean ou ailleurs, histoire de casser des choses sans stress (et sans couper son site principal). L’auteur décrit une approche progressive : comprendre le back-end, les bases de données, le déploiement, la surveillance, puis migrer sur du matériel perso.
Le socle technique utilisé est très courant dans l’auto-hébergement moderne :
-
Docker pour empaqueter les services
-
Caddy comme reverse proxy (et HTTPS automatique)
-
un panneau d’administration type Portainer
-
une base partagée PostgreSQL pour plusieurs applis
4) À quoi ressemble un “mini-Internet personnel” ?
L’idée n’est pas de reproduire tout le web, mais de couvrir tes besoins essentiels avec des services légers. Dans l’exemple présenté, on retrouve trois blocs très parlants :
A) Infrastructure de base (le cockpit)
-
page d’accueil + statut des services
-
monitoring (CPU/RAM/stockage, alertes)
-
gestion de fichiers
-
wiki de documentation (config, décisions, dépannage)
B) Outils perso (productivité)
-
gestion de tâches (ex. Vikunja)
-
notes collaboratives en Markdown (ex. HedgeDoc)
-
favoris (ex. Linkding)
-
musique (ex. Navidrome)
C) Communauté (si tu veux aller plus loin)
-
blog minimaliste (ex. WriteFreely)
-
forum (ex. Flarum)
-
agrégateur RSS (ex. FreshRSS)
-
partage temporaire de fichiers (ex. Plik)
-
sondages / planning (ex. Rallly)
5) “Local-first” : une règle simple qui change tout
Le vrai gain n’est pas seulement “héberger chez soi”. C’est aussi la méthode :
-
tu écris et configures en local (Markdown, fichiers de conf)
-
tu versionnes tout dans Git
-
tu déploies ensuite vers le serveur
Pourquoi c’est puissant ?
-
tu peux travailler même sans connexion
-
tu sais exactement ce qui a changé (et revenir en arrière)
-
tu peux reconstruire ton infrastructure à partir du dépôt (plan de reprise)
6) Préserver la connaissance : Wikipédia hors-ligne et archives personnelles
Auto-héberger des applis, c’est une chose. Mais il y a un autre enjeu : l’accès durable aux contenus.
Wikipédia hors-ligne avec Kiwix
Kiwix permet de télécharger des bibliothèques complètes (format ZIM) et de les consulter sans Internet. Kiwix donne aussi accès à d’autres projets et collections éducatives.
Ordres de grandeur utiles :
-
Wikipédia EN avec images : ~91 GB (chiffres Kiwix, oct. 2022)
-
des versions “sans images” existent et réduisent fortement la taille
Le point clé : c’est assez petit pour vivre sur un SSD externe, et tu peux servir ça sur ton réseau local via un serveur (pratique en famille, en asso, en atelier).
Archiver “ton web” (recherche, preuves, veille)
-
ArchiveBox : pour conserver des pages, articles, PDFs et références consultables hors-ligne
-
HTTrack : pour cloner un site en miroir (dans la limite des sites autorisant ce type d’usage)
Mirrorer des bibliothèques ouvertes
Project Gutenberg propose des recommandations pour mettre en place un miroir, notamment via rsync.
Et pour des collections très larges, Internet Archive explore aussi des approches “offline mirror” comme dweb-mirror.
7) La vraie contrainte (et le vrai prof) : peu de RAM, peu de CPU
Travailler avec des ressources limitées (ex. 2 GB de RAM) force à apprendre les bons réflexes :
-
plafonner la mémoire par service
-
mutualiser la base de données quand c’est raisonnable
-
choisir des images plus légères
-
segmenter les réseaux (prod / DB / monitoring)
-
mesurer en continu (sinon tu pilotes à l’aveugle)
C’est exactement l’esprit “permacomputing” : faire durer, simplifier, éviter la surconsommation.
8) Sécurité : “assez bien” mais propre
Pour un homelab perso, l’objectif n’est pas d’être un SOC d’entreprise, mais d’éviter les erreurs basiques :
-
SSH par clés (pas de mot de passe)
-
pare-feu minimaliste (seulement les ports nécessaires)
-
isolation réseau entre services
-
HTTPS automatique via Caddy
Comment démarrer sans se perdre
Si tu veux une version ultra-simple :
-
Un petit PC / mini-PC / vieux laptop + SSD
-
Docker + Caddy
-
3 services utiles max (ex. fichiers, notes, RSS)
-
Une doc interne (wiki Markdown)
-
Une sauvegarde hors machine (disque externe)
Tu obtiens déjà un “noyau” : tes données, tes outils, ton contenu… chez toi, avec des briques remplaçables.
Conclusion
Ce n’est pas un mouvement “apocalyptique”, ni une mode : c’est une compétence. Comme apprendre à cuisiner, réparer un vélo ou tenir une trousse de secours, l’auto-hébergement et le local-first redonnent de la marge de manœuvre.
Et surtout, ça te force à poser la bonne question : de quoi ai-je vraiment besoin pour que mes outils et ma connaissance restent disponibles, stables et à moi ?
