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. Plus de base de données à maintenir, tout est dans Git.
• Composants : Une structure modulaire pour une maintenabilité maximale.

2. Le Design System : Tailwind CSS

Pour l’interface, je voulais une esthétique “Dark Mode” épurée. Tailwind m’a permis d’itérer rapidement sur un layout “Bento Grid” responsive, sans la dette technique du CSS classique.

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.

🔮 Roadmap

Cette architecture pose les fondations saines de mon identité numérique. Les prochaines étapes d’ingénierie incluent :

1. L’intégration d’un pipeline CI/CD (GitHub Actions) pour le déploiement continu.
2. La mise en place de CrowdSec pour protéger le conteneur Nginx des scans malveillants.

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