Quand on commence à s’auto-héberger, on tombe vite sur une évidence gênante : la plupart des services qu’on installe n’ont aucune raison d’être exposés sur Internet. Un Jellyfin, un gestionnaire de mots de passe, un panel d’admin interne — leur place est dans le réseau local. Sauf qu’on a quand même besoin d’y accéder de l’extérieur : depuis le téléphone, depuis un café, depuis l’autre bout du pays. C’est exactement ce trou que WireGuard vient combler, et il le fait avec une élégance qui m’a fait repenser tout mon réseau perso.
Le premier argument, c’est la taille. Là où OpenVPN traîne des centaines de milliers de lignes de code et un héritage de choix cryptographiques discutables, WireGuard tient dans environ quatre mille lignes. Ce n’est pas qu’une coquetterie de développeur : un protocole de tunnel chiffré qu’on peut lire en une après-midi, c’est auditable, et c’est rare. Cette minceur se ressent aussi à l’usage — ouverture de tunnel quasi instantanée, débit proche du natif, surcharge CPU négligeable.
Mais ce qui m’a vraiment convaincu, c’est le modèle mental. WireGuard ne se pense pas comme un « VPN » avec ses sessions négociées et ses handshakes à dépanner. Il se pense comme une simple interface réseau, qui se trouve être chiffrée. Chaque machine (chaque peer) a une paire de clés. On déclare les autres pairs autorisés, et pour chacun on liste trois choses :
[Peer]
PublicKey = clé publique du pair
AllowedIPs = 10.0.0.2/32 # son IP dans le tunnel
Endpoint = exemple.fr:51820 # où le joindre (optionnel)C’est tout. Pas de mode opératoire à choisir, pas de session à diagnostiquer. Une fois ces quelques lignes en place de chaque côté, le tunnel devient transparent.
Je n’expose qu’un seul port public : 51820/UDP, celui de WireGuard. Tout le reste — Jellyfin, FileBrowser, les interfaces d’admin de mes services, l’accès SSH aux machines — reste strictement privé. Depuis mon téléphone, j’active le tunnel et je retrouve instantanément l’ensemble de mon réseau domestique, comme si j’étais physiquement chez moi. Pas de port forwarding qui s’accumule, pas de reverse proxy à monter pour chaque nouveau service, pas de surface d’attaque éparpillée.
Et il y a un bénéfice que je n’avais pas anticipé : la discipline. Un VPN bien intégré force à trancher, pour chaque service, entre ce qui doit être public et ce qui doit rester interne. La distinction paraît évidente sur le papier, mais en pratique elle se brouille — on expose un truc « juste pour tester », on oublie de le refermer, on en empile un deuxième. WireGuard m’a fait basculer vers la bonne logique par défaut : tout est privé, sauf preuve du contraire.
Le tunnel tourne en permanence sur servyass, et plus aucun service domestique n’est exposé en direct. Quand je rentre chez moi, la bascule est invisible. Pour un outil réseau, c’est sans doute le plus beau compliment qu’on puisse faire.
J’ai longtemps mis tout mon code sur GitHub. C’est la norme du métier, c’est gratuit, c’est là que vivent les autres développeurs. Mais au fil des projets perso qui s’accumulaient — des bots Discord, des thèmes WordPress, deux ou trois applis Symfony, des modules Foundry — une question s’est installée : est-ce que tout doit vraiment vivre chez Microsoft ? Le jour où j’ai installé Forgejo sur mon serveur, j’ai eu ma réponse.
Forgejo est un fork récent de Gitea, né d’un désaccord sur la gouvernance. La communauté qui a forké voulait un projet purement open source, porté par une fondation à but non lucratif, à l’abri d’un rachat commercial. Cette histoire de fork n’est pas anecdotique : la gouvernance d’un outil, c’est ce qui décide de ce qu’il deviendra dans cinq ans. C’est rarement le critère qu’on regarde en premier, et souvent celui qui compte le plus longtemps.
À l’usage, le dépaysement est minime. L’interface ressemble à GitHub, les pull requests s’appellent pull requests, les issues fonctionnent pareil, l’éditeur web permet les retouches rapides, et l’API est assez compatible pour que la plupart des outils tiers tournent sans rien changer. Pour un usage perso ou en petite équipe, la transition est invisible — pas seulement techniquement, mais dans la tête.
Autant être honnête, quitter GitHub n’est pas gratuit. Trois pertes, concrètes :
Pour un développeur en recherche d’emploi, ça pèse. Ma réponse a donc été pragmatique plutôt que dogmatique : Forgejo pour tout, et un miroir public vers GitHub pour les projets dont je veux la vitrine. Le dépôt de référence reste chez moi ; GitHub devient une devanture, plus un coffre-fort.
Ce choix n’a de sens que si on tient à garder la main complète sur son versioning, ou qu’on a des contraintes de souveraineté sur le code. Si on dépend vraiment de l’écosystème social de GitHub, ça n’a aucun intérêt — et c’est un choix, pas une faiblesse. De mon côté, Forgejo tourne sur servyass depuis plusieurs mois, tous mes commits passent par lui, et le jour où GitHub changera ses CGU, je n’aurai rien à migrer.
Quand j’ai monté mon premier serveur Minecraft, j’avais quatorze ans et aucune idée de ce qu’était un fichier de configuration. J’éditais server.properties à la main parce qu’un forum disait qu’il fallait changer max-players. Le serveur redémarrait, ça marchait ou ça plantait, et j’apprenais lentement, par essai-erreur, que chaque ligne voulait dire quelque chose. Dix ans plus tard, j’ouvre config/packages/security.yaml dans un projet Symfony, et je fais exactement le même geste. Le vocabulaire a changé, pas le geste.
On me demande parfois comment je suis « passé » du bidouillage de serveurs de jeu à un projet Symfony noté en formation. La vérité, c’est que je ne suis pas vraiment passé de l’un à l’autre. Le bidouillage — le tinkering — n’est pas une étape qui précède le développement : c’en est la forme la plus brute.
Parce que le tinkering, ce n’est pas un niveau de compétence, c’est une posture : ouvrir un système, lire sa config, comprendre ses interactions, modifier prudemment, mesurer l’effet. Que je bidouille un level.dat, un Dockerfile ou un EntityRepository Doctrine, le geste mental ne bouge pas — décomposer, isoler, formuler une hypothèse, tester. Ce qui sépare un développeur d’un simple utilisateur, ce n’est ni le diplôme ni la techno : c’est cette habitude de considérer les outils comme ouverts par défaut.
Concrètement, le serveur Minecraft m’a tout appris avant que j’en connaisse les noms. Avant de comprendre la JVM, j’avais compris qu’il fallait lui donner de la mémoire. Avant de connaître systemd, j’écrivais des scripts screen qui relançaient le serveur quand il tombait. Avant d’avoir entendu parler de reverse proxy, je redirigeais un sous-domaine vers une IP fixe pour que mes potes se connectent sans retenir un numéro de port. Aucune de ces bricoles n’avait de nom canonique à l’époque — mais elles m’ont préparé à reconnaître les concepts le jour où la formation me les a présentés.
Du coup, quand je découvre un bundle, un pattern ou une annotation, je ne pars jamais de zéro : je rattache le truc à quelque chose que j’ai déjà manipulé ailleurs.
.sql que je versionnais déjà dans mes premiers projets PHP.Alors si tu doutes d’un parcours fait de bidouille plutôt que de cursus bien rangé : ces années à bricoler pour toi-même n’ont produit aucun diplôme, c’est vrai, mais elles ont produit autre chose, plus dur à monnayer et plus durable — une compréhension intuitive de la façon dont les systèmes se cassent. C’est précisément ce qu’on cherche quand on recrute un dev ou un admin sys. Je n’ai pas appris Symfony en commençant Symfony ; je l’ai appris en passant dix ans à bidouiller tout ce qui me tombait sous la main. La formation, elle, a juste mis des noms sur ce que je faisais déjà.
Pendant plusieurs semaines, mon serveur Minecraft s’est coupé tout seul, à des heures aléatoires, sans rien laisser dans les logs côté Java. Pas de crash, pas d’exception, juste un silence. Le serveur s’arrêtait comme si on avait débranché la prise. Jusqu’à ce que je tombe sur cette ligne, planquée dans journalctl -k :
Out of memory: Killed process 1234 (java)L’OOM killer du noyau Linux était passé par là. Et, comme souvent, le coupable n’était pas celui que j’accusais.
Le réflexe, quand un processus disparaît, c’est d’aller lire ce que l’application elle-même en dit. Pour Minecraft, c’est latest.log. Et il n’y avait rien : aucune panique, aucune erreur applicative. C’est normal — quand le noyau décide de tuer un processus pour récupérer de la mémoire, il ne lui laisse pas le temps d’écrire ses dernières volontés. Sous Linux, lorsque la RAM vient à manquer, l’OOM killer choisit un processus selon un score interne (oom_score) et l’abat sur-le-champ. La JVM, avec son appétit constant et sa grosse réservation mémoire, est presque toujours la première sur la liste. La logique du noyau est implacable : sauver l’ensemble du système quitte à sacrifier un processus, et sans demander la permission.
Une fois le vrai coupable identifié, la solution s’est construite en trois ajustements, chacun visant une cause différente.
-Xmx5G interdit à Java de dépasser cinq gigaoctets de heap, quoi que disent les réglages par défaut. Sans ce plafond, la JVM consomme jusqu’à ce que le noyau s’en occupe à sa place.MemoryMax=6G dans l’unité, et tout le service est arrêté proprement avant que l’OOM killer n’ait à intervenir. La différence est énorme : un systemctl restart au lieu d’un plantage muet.La vraie leçon n’est pourtant pas dans le triplet swap + Xmx + MemoryMax. Elle est dans la méthode : ne pas s’arrêter aux logs de l’application, descendre d’un cran, lire le noyau, accepter que la cause se trouve souvent en dehors du périmètre qu’on imaginait. Ce réflexe — descendre dans la pile jusqu’à la vraie cause — est sans doute la compétence la plus précieuse que m’ait apprise l’administration de mon propre serveur. Depuis que le triplet est en place, plus une seule coupure. Et maintenant, quand quelque chose tombe sur cette machine, je commence par journalctl -k.
On me demande parfois pourquoi je m’embête à faire tourner mes propres services alors qu’il existe une alternative cloud pour tout. Voilà ma réponse — sans le discours militant.
Ça a commencé par un Jellyfin, histoire d’arrêter de payer quatre abonnements streaming. Puis un Nextcloud pour rapatrier mes fichiers de chez Google. Puis un gestionnaire de mots de passe, un reverse proxy, un système de surveillance… Aujourd’hui je gère une dizaine de services sur une machine sous Debian qui tourne H24 dans mon bureau, et honnêtement, je ne reviendrais pas en arrière. Mais soyons clairs tout de suite : le self-hosting, ce n’est pas pour tout le monde, et prétendre le contraire serait malhonnête.
Ce que personne ne te dit au départ, c’est que le premier mois tu passes plus de temps à déboguer qu’à utiliser quoi que ce soit. Un container qui refuse de démarrer, un certificat SSL qui expire, un port mal exposé — chaque petite victoire arrive après une heure de logs à déchiffrer. C’est frustrant, et c’est aussi exactement là que tu apprends. Parce que le vrai bénéfice n’est pas d’économiser un abonnement : c’est de comprendre ce qui se passe derrière les interfaces bien léchées qu’on utilise tous les jours. Quand tu configures toi-même ton reverse proxy sous Nginx, que tu gères tes certificats, que tu cherches comment isoler proprement tes containers Docker, tu ne lis plus la tech, tu la pratiques.
Et il y a quelque chose de plus concret que la « souveraineté numérique » dont tout le monde parle. Mes mails passent par mon propre serveur, mes médias restent chez moi, mon code vit sur mon Forgejo. Si demain GitHub change ses CGU ou qu’un service cloud décide de doubler ses tarifs, ça ne me touche pas. Cette indépendance a un prix — de l’électricité, du temps de maintenance, parfois de vraies galères — mais c’est un prix que je choisis et que je maîtrise. Rien à voir avec un abonnement pour un service dont tu ne contrôles rien.
Alors c’est pour qui ? Pour les curieux qui veulent comprendre, pas seulement utiliser. Pour ceux que ça ne dérange pas de passer un samedi sur un problème de réseau. Pour les développeurs qui veulent un environnement de test qui leur ressemble vraiment. Et clairement pas pour ceux qui veulent juste que ça marche sans y toucher — le cloud fait ça très bien, aucune honte à le dire. Mon setup actuel tourne sur un Ryzen 3, 13 Go de RAM, Debian 12 : pas besoin de matériel de course pour démarrer. Le plus important, c’est la curiosité.