Un système complet que je fais tourner, avec des preuves vérifiables en direct
Le site que vous lisez tourne sur un serveur que j'ai installé, que je sécurise, mets à jour et surveille moi-même — de la machine nue jusqu'à cette page.
Le besoin
Un portfolio devrait prouver des compétences, pas seulement les lister. L'héberger sur une plateforme clé en main cacherait justement ce que je veux montrer : faire tourner un service fiable et sûr dans la durée.
L'idée
Faire de l'hébergement lui-même la démonstration : tout ce qui est écrit ici se vérifie en direct, sur la machine même qui sert cette page.
Ce que j'ai construit
- Un serveur cloud en région parisienne, obtenu après six tentatives sur plusieurs jours — la capacité gratuite y est rare.
- Toute la chaîne web, chaque service dans son propre espace restreint, pour qu'un problème ne se propage pas aux autres.
- Durcissement dès la première nuit — 7 mesures appliquées en une seule nuit sans aucune coupure — puis poursuivi pas à pas.
- Des mises à jour automatiques : une modification validée part en ligne toute seule, est contrôlée, et revient en arrière automatiquement si la nouvelle version ne répond pas.
- Une sauvegarde continue de la base, plus des instantanés chaque nuit conservés à la journée, à la semaine et au mois.
- Une sonde séparée qui contrôle la sécurité du site toutes les heures et publie le résultat — visible juste en dessous.
Le résultat
- 5contrôles de sécurité rejoués toutes les heures par une sonde séparée
- 7appliquées en une nuit, zéro coupure
- 6tentatives pour obtenir le serveur
- 1 hentre deux contrôles de sécurité indépendants
Il sert ce portfolio depuis août 2026, aux côtés d'EventMap. Les contrôles ci-dessous sont mesurés par une sonde séparée, pas écrits à la main.
À vérifier soi-même
Contrôles en direct
- TLS vérifié
- origine vérifié
- en-têtes vérifié
- DNSSEC vérifié
- disponibilité vérifié
En images
Ce que j'ai appris
Ne jamais tester seulement depuis la machine elle-même : avec deux pare-feux empilés, un service peut répondre parfaitement en local pendant que personne ne peut l'atteindre depuis Internet. Et savoir ne pas installer quelque chose — ici, un serveur de base de données — est aussi une compétence d'exploitation.
Détails techniques Stack, architecture et choix — pour les lecteurs techniques
Stack
- Ubuntu 22.04
- Oracle Cloud ARM (Always Free)
- nginx
- Node.js + Express
- SQLite (node:sqlite)
- systemd
- fail2ban
- iptables
- Cloudflare
- GitHub Actions
- Litestream + restic
L'architecture en un coup d'œil
- Le navigateur du visiteur
- Cloudflare — TLS et cache
- nginx — en-têtes de sécurité, limitation de débit
- Node.js + Express — pages rendues côté serveur, en 7 langues ; un service systemd isolé
- SQLite (node:sqlite) — projets et visites mesurées sans tiers
- Autour : GitHub Actions teste chaque changement ; la VM tire la version validée, vérifie /health et revient en arrière en cas d'échec ; l'Observatoire recontrôle la sécurité toutes les 30 minutes.
Comment ça marche
- VM 4 OCPU / 24 Go (Ubuntu 22.04). nginx en reverse proxy devant des services isolés, chacun sous un utilisateur système dédié sans shell, avec ProtectSystem=strict et NoNewPrivileges.
- Première nuit (23/08/2026) : mot de passe d'administration régénéré, fail2ban sur SSH, en-têtes de sécurité stricts (CSP, HSTS, X-Frame-Options), dernier octet des IP mis à zéro dans les journaux, rétention journald bornée, rotation des journaux nginx, sauvegarde chiffrée des secrets stockée hors de la VM.
- Ensuite : limitation de débit nginx, rpcbind coupé, swap, bureau distant lié à 127.0.0.1 (tunnel SSH uniquement), authentification SSH par mot de passe désactivée, certificat Cloudflare Origin CA en mode Full (strict).
- Déploiement continu en mode pull : un push sur master est validé par GitHub Actions, qui déplace un tag prod ; la VM le tire via un timer systemd, le contrôle et revient en arrière automatiquement. Aucun port entrant, aucun identifiant de la VM chez GitHub.
- Deux pare-feux empilés (iptables sur la VM + Security List côté cloud) — la raison pour laquelle je ne teste jamais seulement depuis la machine elle-même.
- Arbitrage assumé : les correctifs de sécurité s'installent seuls, mais la VM ne redémarre ni ne change de version majeure sans moi.
- Mesure d'audience en première partie uniquement : aucun cookie tiers, adresses IP hachées avant stockage, enregistrements purgés au bout de 12 mois.
Choix et compromis
- Pages rendues côté serveur plutôt que chargées dans le navigateur : elles restent indexables dans sept langues et lisibles sans JavaScript.
- Services systemd plutôt que Docker : la production tourne en unités systemd isolées, avec quotas CPU et mémoire — un conteneur jamais déployé ne prouverait rien.
- Un seul flux JSON public (/api/contenus.json), réutilisé par la Mindmap, plutôt qu'une seconde API : une seule source de vérité, rien à synchroniser.
Incidents et corrections
- Après la refonte, le rapport automatique des pull requests dépassait la limite de 65 536 caractères des commentaires GitHub (captures intégrées) : les tests passaient, la publication échouait. Corrigé par des miniatures plus légères et un budget de 60 000 caractères.
- Cloudflare servait encore d'anciens scripts jusqu'à 4 heures après un déploiement : chaque URL CSS et JavaScript porte désormais une empreinte de contenu (?v=), une nouvelle version ne se mélange jamais à d'anciens fichiers.
- En arabe, une valeur comme « 43 → 9.9 MB » s'affichait à l'envers à cause de l'algorithme bidirectionnel : les valeurs latines sont désormais isolées par des marques Unicode.
Ce qui manque encore
- Pas de redémarrage automatique — un choix assumé