Infrastructure

Serveur :

Le setup tourne sur un VPS OVH (6 vCPU / 12 Go RAM). Le choix d'un VPS Linux plutôt qu'un hébergement Windows n'est pas anodin : une licence Windows Server représente entre 15 et 30€/mois supplémentaires, soit largement le double du budget.
Linux + Docker, même si il reste plus brut, permet d'atteindre le même résultat pour une fraction du coût.

Avant d'en arriver là, j'ai exploré plusieurs configurations :

• Serveur auto-hébergé overkill (32 CPU, 256 Go RAM) : même avec des composants basse consommation, incompatible avec un usage 24/7
• NAS auto-hébergé : trop cher, peu puissant, inadapté à ce type d'usage
• Petit serveur basse consommation auto-hébergé avec une stack HyperV : fonctionnel, mais plus complexe à maintenir, et manque de puissance.
  L'auto-hébergement pose aussi un problème structurel : en cas de faille, ce sont des données personnelles qui sont exposées sur le réseau domestique. Et une ligne fibre personnelle, aussi rapide soit-elle, est loin de garantir la disponibilité d'un datacenter.

Le VPS s'impose comme le meilleur compromis fiabilité / coût / maintenabilité / sécurité.

Services (Docker) :

Tous les services tournent en conteneurs Docker :

• Portainer : Interface web de gestion des conteneurs et API REST pour les automatisations
• Nginx proxy Manager : Reverse proxy avec interface web et API REST
• SQL Server : Base de données (contrainte stack .NET)
• MariaDB : Base de données pour les applications et conteneurs tiers
• BookStack : Documentation interne
• Trilium : Prise de notes et organisation personnelle
• ...

Gestion des codes sources :

Git est aujourd'hui une évidence pour versionner et gérer le code. Le vrai choix, c'est l'interface web qui va avec.

J'ai écarté Azure DevOps - que j'ai mis en place professionnellement - et GitLab, tous deux trop lourds en ressources pour un usage solo. Gitea est l'alternative idéale : léger, rapide, et complet pour un usage personnel (merge requests, tickets, gestion des dépôts...). Tout ce qu'il faut, sans superflu.

Quant au choix du self-hosting plutôt qu'un service tiers comme GitHub : je ne suis pas tributaire d'une plateforme externe, de ses pannes ou de ses décisions. Mon code ne sert pas à entraîner des IA. Je sais où sont mes données et mes sauvegardes. Et ça ne m'empêche pas d'utiliser des outils tiers ponctuellement - mais je maîtrise à 100% qui a accès à quoi.

Mon Gitea héberge aujourd'hui plus de 150 dépôts : projets personnels, expérimentations, outils internes.

Sécurité :

C'est probablement la partie sur laquelle j'ai le plus investi, proportionnellement à ce qu'il y a réellement à protéger. Mais partir du principe que "il n'y a rien d'intéressant à voler" est une mauvaise posture - une machine compromise peut servir à attaquer d'autres cibles.

La sécurité est mise en place en couches :

• Firewall OVH : filtrage au niveau réseau, avant même d'atteindre le serveur
• Firewall Linux : second niveau, directement sur la machine
• Fail2Ban : blocage automatique des tentatives d'intrusion (brute force SSH, etc.)
• Filtrage IP : restriction des accès aux services sensibles
• Cloudflare WAF : protection contre les attaques applicatives et filtrage géographique
• Cloudflare Tunnel : connexion sécurisée entre mon VPS et les serveurs de Cloudflare
• Cloudflare Zero Trust : authentification requise pour accéder aux services internes, sans exposition directe sur internet
• Cloudflare Turnstile : protection anti-bot sur les interfaces publiques

Sauvegardes & continuité :

Une infrastructure sans plan de reprise testé, c'est une infrastructure qui ne fonctionne que jusqu'à la prochaine panne.

La stratégie mise en place suit la règle 3-2-1 : 3 copies des données, sur 2 supports différents, dont 1 hors site.

Ce qui distingue ce setup d'un backup "sur le papier" : le plan de reprise a été testé pour de vrai - simulation d'un crash complet, remise à zéro, reconstruction depuis les sauvegardes uniquement. C'est quelque chose que certaines entreprises ne font jamais. C'est pourtant le seul moyen de savoir si ça fonctionne vraiment.

Philosophie : des outils, pas des lignes de commande

Une conviction qui guide toutes mes décisions d'infrastructure : on utilise des outils avec une interface, pas des commandes tapées à la main.

Se connecter en SSH pour chaque action du quotidien, c'est s'exposer aux erreurs, perdre du temps et rendre l'infrastructure illisible pour quelqu'un d'autre (ou pour soi-même six mois plus tard, surtout quand on ne fait pas cela tous les jours). Les outils graphiques offrent une vue d'ensemble, réduisent les erreurs et permettent d'agir vite. Les lignes de commande restent utiles pour automatiser ou déboguer quand plus rien ne marche, pas pour gérer le quotidien.

Documentation complète

Sur Bookstack, une documentation suffisamment détaillée pour reconstruire l'environnement de zéro sans avoir à se souvenir de chaque décision prise il y a six mois.
La documentation critique est aussi stockée au format PDF en local en cas de crash sévère.

Ce que ce projet m'a apporté

Partir d'une stack .NET/Windows et construire une infrastructure Linux/Docker de zéro, c'est une vraie montée en compétences. Réseau, sécurité système, conteneurisation, bonnes pratiques de backup… autant de domaines que je n'effleurais qu'à peine dans mon quotidien.

Le résultat : une infrastructure stable, documentée, sécurisée, et qui tient dans un budget personnel.