ProjetsProduction auto-hébergée
Les sites et applications que je livre, et l'infrastructure que je conçois pour les servir : le schéma d'ensemble, les décisions détaillées, les patterns, le journal d'exploitation et la suite du chantier.
Réalisations : sites & applications en production
Le schéma, en vue logique cliquable
Les blocs marqués de cette flèche sont cliquables : chacun ouvre son record de décision, avec le besoin, les options, le choix et le tradeoff.
Études de cas, par domaine
Patterns & write-ups techniques
Journal d'exploitation
Les incidents réels de la plateforme, en format court : le symptôme, le diagnostic, le correctif, et ce que chacun a changé.
19 juin 2026 · Panne chez l'hébergeur : serveur injoignable
Symptôme. Vendredi 19 juin, mi-journée : plus aucun nom de domaine ne résout sur les appareils du tailnet, alors que la connexion Internet est bonne. Cause immédiate : ces appareils utilisent le DNS interne de la plateforme comme résolveur, et le serveur qui l’héberge ne répond plus.
Diagnostic. Connexion correcte mais résolution muette : le problème est du côté du serveur. Confirmation rapide chez l’hébergeur : incident de refroidissement dans le datacenter de Roubaix, annoncé sur la page de statut d’OVHcloud (source publique). Environ deux heures trente d’indisponibilité vécue pour ce serveur ; la résolution complète de l’incident a pris une douzaine d’heures pour les derniers serveurs touchés.
Correctif. Aucun levier pendant l’incident : la panne est physique, chez l’hébergeur. Le travail utile se fait avant et après.
Ce que ça a changé. Deux enseignements. La dépendance DNS d’abord : faire du serveur le résolveur des appareils du tailnet transforme une panne d’hébergeur en panne de résolution générale sur tous les appareils. Corrigé depuis : un résolveur de secours est déclaré dans la configuration DNS du tailnet, les appareils gardent une résolution si le serveur ne répond plus. Le mono-serveur ensuite : le risque est connu et accepté à cette échelle, et une infrastructure multi-serveurs reste un objectif d’apprentissage (chantier au-delà du mono-serveur). Changer d’hébergeur ne protégerait de rien : ce type d’incident peut arriver partout.
1 juin 2026 · Une mise à jour automatique coupe l'accès aux services privés
Symptôme. Tous les services privés répondent 403 : coffre de mots de passe, outils internes, dashboards. Les sites publics fonctionnent normalement. Découvert deux jours après le début de l’incident, en remarquant que le coffre de mots de passe ne se synchronisait plus : les services du tailnet ne servent pas tous les jours, la panne est restée silencieuse le temps d’un week-end.
Diagnostic (1 h 30). Les logs du reverse proxy montrent une adresse
source en 172.x, celle de la passerelle du réseau Docker, au lieu de
l’adresse tailnet du client. Le filtre tailscale-only, qui n’autorise que
le réseau privé, refuse donc tout le monde. Remontée de piste : Tailscale
s’était mis à jour automatiquement quelques jours plus tôt, et la nouvelle
version introduit des règles de marquage de connexions qui, combinées au
masquerading existant, réécrivent la source des paquets entrants avant
qu’ils n’atteignent les conteneurs.
Correctif. Désactivation persistante du SNAT des routes locales côté Tailscale, sans effet de bord ici puisque ce nœud ne route aucun sous-réseau.
Ce que ça a changé. Deux jours d’incident silencieux sur la moitié de la plateforme, détectés par un hasard d’usage : c’est précisément ce que le chantier observabilité et alerting de la roadmap doit rendre impossible. Leçon complémentaire : une mise à jour automatique peut modifier le comportement réseau à bas niveau ; pour les composants réseau, lire le changelog avant de mettre à jour, quitte à épingler la version.