Pas de « cloud » anonyme : une infrastructure que je construis, que je surveille et dont je publie chaque choix technique : le contexte, les options, la décision, le résultat. Les pannes aussi.
Vue volontairement expurgée : aucune adresse, aucun port, aucune topologie exacte. Montrer le raisonnement n'affaiblit pas ce qui le sert.
Chaque étape existe pour une raison, et chacune a son record de décision plus bas. C'est ce chemin qui tourne pour les sites que j'héberge, celui-ci compris.
Du navigateur du visiteur jusqu'à la page servie
En parallèle et sans rapport avec le visiteur : sauvegardes chiffrées chaque nuit, surveillance continue, et une administration qui ne passe jamais par Internet.
Le format est toujours le même : contexte, contraintes, options envisagées, décision, résultat.
Plusieurs copies sur plusieurs supports, dont une hors site chiffrée, et un mode d'emploi de restauration écrit à froid.
Fiabilité · SécuritéUn point d'entrée unique, chiffrement automatique, en-têtes de sécurité : la façade de tous les sites hébergés.
Fiabilité · SécuritéL'administration ne passe jamais par Internet : un réseau chiffré, appareil par appareil.
SécuritéUn durcissement volontaire couplé sans le savoir au démarrage du réseau privé : diagnostic, correctif d'une ligne, test de non-régression.
Décision + post-mortemRien en clair dans le code ni la base : injection par fichiers, jetons hachés, coffre auto-hébergé.
SécuritéLes formulaires de vos sites aboutissent toujours : livraison garantie, reprise après panne, historique.
FiabilitéUn prestataire qui prétend n'avoir jamais de panne vous ment. Chaque incident réel a son post-mortem public : symptôme, diagnostic, correctif, leçon.
Symptôme. Reboot de maintenance planifié (mises à jour de sécurité, noyau en attente), le premier depuis des mois. Tout redémarre seul : sites clients en ligne, conteneurs relancés par leurs politiques Docker, le pair qui répond sur le maillage Tailscale. Tout, sauf SSH : « Connection refused » immédiat, sur l’adresse publique comme sur celle du VPN. La machine répond, mais rien n’écoute.
Diagnostic. Une vingtaine de minutes entre le premier refus et le
retour de SSH, via la console KVM out-of-band d’OVHcloud (clavier
interprété en QWERTY compris). systemctl status ssh donne le verdict :
sshd, volontairement restreint à l’adresse du VPN maillé (durcissement
zero-trust), a démarré avant que Tailscale ne monte
son interface. L’adresse n’existait pas encore, le bind a échoué, sshd a
épuisé ses tentatives et est resté couché. Le serveur n’avait jamais
redémarré depuis ce durcissement : la panne dormait là depuis des mois.
Correctif. net.ipv4.ip_nonlocal_bind=1 dans /etc/sysctl.d/ : sshd
peut se binder sur une adresse qui n’existe pas encore, et n’écoute
toujours que sur le VPN. Vérifié par un test qui reproduit les conditions
du boot (VPN coupé, sshd redémarré, service actif). Les options écartées
et le tradeoff sont détaillés dans
la décision complète.
Ce que ça a changé. Un service qui tourne depuis des mois n’a jamais prouvé qu’il savait démarrer : seul un reboot le prouve, et ils font désormais partie de la maintenance régulière. Et le chemin de secours (console out-of-band) reste volontairement indépendant de tout le reste : c’est lui qui a permis de régler l’incident en vingt minutes.
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.
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.
Vous savez toujours où en est votre projet, ce qu'il coûte, et qui appeler.
à toute demande, par la personne qui fera le travail.
gratuit, poste par poste, sans engagement.
devis signé, acompte à la commande, solde à la mise en service.
nom de domaine, code, contenus et données : à votre nom, exportables, réversibles.
Les agents IA font partie de l'atelier : ils accélèrent la construction, les tests et la surveillance, et ce gain se retrouve dans vos devis. La relecture, les choix et la responsabilité restent humains : c'est moi qui signe.Ma méthode de travail avec les agents →
Je suis Alexandre Cooreman, développeur indépendant dans le Cambrésis. Je conçois les sites et les outils, je les héberge, je les surveille, et quand quelque chose casse, c'est moi que vous appelez. Le premier rendez-vous se fait chez vous, sans frais.
Documents : Parcours technique ·CV (français) · CV (anglais) · LinkedIn
Des sujets pointus traités court, pour les curieux et les confrères : ma méthode de travail avec les agents IA, les certificats par DNS, la file de livraison des messages.
Hébergement géré et maintenance : à partir de 19 € HT / mois, forfait connu d'avance.
Voir l'offre d'hébergement