Migration Architecture : De WP à la JAMstack Dockerisée

🛑 Le Constat : L’obsolescence de WordPress

Mon ancien portfolio tournait sous WordPress. C’est un CMS puissant, mais pour un site vitrine personnel, c’est comme utiliser un semi-remorque pour aller acheter une baguette.

J’identifiais quatre dettes techniques majeures :

1. Lourdeur : Une stack LAMP (Linux, Apache, MySQL, PHP) gourmande pour servir de simples pages statiques.
2. Surface d’attaque : La nécessité critique de patcher les plugins et le cœur WP pour éviter les failles RCE ou SQLi.
3. Maintenance : Une difficulté à versionner le contenu (base de données binaire) dans Git.
4. Performance : Un Time-to-First-Byte (TTFB) ralenti par la génération dynamique des pages.

En tant qu’Administrateur Système et futur expert Cyber, je voulais une plateforme qui soit le miroir de mes compétences : rapide, souveraine et sécurisée by-design.

🛠️ La Réponse Technique : Une approche “Static First”

J’ai opté pour une architecture JAMstack (Javascript, API, Markup). Le principe est de pré-générer tout le HTML lors de la compilation (Build time), pour ne servir que des fichiers statiques immuables aux visiteurs.

1. Le Moteur : Astro 🚀

J’ai choisi Astro pour son architecture “Island”. Contrairement à React ou Next.js qui hydratent toute la page en JavaScript (lourd), Astro envoie 0kb de JS par défaut.

• Gestion de contenu : Mes projets sont désormais de simples fichiers Markdown (.md) typés avec Zod. Plus de base de données à maintenir, tout est dans Git.
• Composants : Une structure modulaire pour une maintenabilité maximale.

2. Le Design System : Tailwind & Dark Mode

Pour l’interface, je voulais une esthétique épurée mais fonctionnelle. Tailwind m’a permis d’itérer rapidement sur un layout “Bento Grid” responsive.

J’ai également implémenté un thème hybride (Light/Dark) persistant, géré via localStorage et respectant les préférences système de l’OS.

3. L’Infrastructure : Docker Multi-stage & Nginx 🐳

C’est ici que la magie opère. Pour garantir une image Docker ultra-légère et sécurisée, j’utilise un Multi-stage Build.

Mon Dockerfile de production :

# --- ÉTAPE 1 : BUILD (NodeJS) ---
FROM node:20-alpine AS builder
WORKDIR /app
# Installation des dépendances et compilation
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build  # Génère le dossier /dist

# --- ÉTAPE 2 : RUN (Nginx) ---
FROM nginx:alpine
# On ne copie QUE le résultat statique (pas de node_modules en prod !)
COPY --from=builder /app/dist /usr/share/nginx/html
COPY nginx.conf /etc/nginx/conf.d/default.conf

EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

Pourquoi cette stratégie ?

• Sécurité : L’image finale ne contient pas Node.js, ni npm, ni le code source. Juste Nginx et du HTML/CSS. Impossible d’injecter du code JS serveur.
• Légèreté : L’image passe de ~1Go (Node) à quelques Mo (Alpine Nginx).

📊 Benchmarking & Résultats

La transition est quantifiable et sans appel. Grâce à l’optimisation des images (AVIF/WebP) et au chargement différé :

🔮 Écosystème Connecté

Cette architecture n’est pas isolée. Elle s’intègre désormais dans un écosystème complet que j’ai déployé :

1. CI/CD (GitHub Actions) : Chaque push sur main déclenche le build et déploie le conteneur sur mon VPS en moins de 40 secondes.
2. Sécurité (CrowdSec) : Un agent analyse les logs Nginx en temps réel pour bannir les IPs malveillantes via un bouncer Firewall.

Ce projet prouve qu’avec les bons outils modernes, on peut allier performance extrême, sécurité militaire et sobriété numérique.