Statut : 🤔 RÉFLEXION — décision en attente

Cette page documente une question d’architecture de contenu Hugo pour laquelle je n’ai pas encore tranché.

Le contexte

Le thème LoveIt (que utilise arleo.eu) suit la convention Hugo recommandée : les articles de blog vont dans content/posts/. La home filtre where .Site.RegularPages "Type" "posts".

Or, par historique de migration depuis Grav, mes 16 articles éditoriaux sont à la racine de content/, pas dans content/posts/ :

content/
├── csp-nonce/index.fr.md          ← article
├── post-mortem-522-wan-failover/  ← article
├── jquery-migration/              ← article
├── ...
├── privacy-policies/              ← page de référence (footer)
├── documentation/                 ← page de référence (menu)
└── scripts/                       ← page de référence (menu)

Hugo considère par défaut tous ces dossiers comme des pages de “Type: page”, pas “Type: posts”. Donc le filtre LoveIt sur la home ne les voit pas, et je dois soit overrider layouts/index.html, soit filtrer manuellement.

La question

Faut-il migrer les 16 articles vers content/posts/ pour suivre la convention LoveIt, ou les laisser à la racine ?

Option A — Migrer vers content/posts/

content/
├── posts/
│   ├── csp-nonce/index.fr.md
│   ├── post-mortem-522-wan-failover/
│   ├── jquery-migration/
│   └── ...
├── privacy-policies/
├── documentation/
└── scripts/

Avantages

• Conformité au thème : pas d’override de layouts nécessaire
• Lisibilité repo : on voit immédiatement quels dossiers sont des articles vs des pages de référence
• Évolutivité : si LoveIt évolue (nouvelles features sur Type=posts), elles s’appliquent gratuitement
• Mental model standard : tout dev Hugo qui découvre le repo comprend instantanément

Inconvénients

• Changement d’URL : /csp-nonce/ deviendrait /posts/csp-nonce/ par défaut. Casse tous les liens entrants (Google, Reddit, hackernews, mes propres articles internes)
• Mitigation possible via url: explicite dans le front matter : url: /csp-nonce/ — Hugo génère alors la page à /csp-nonce/ même si le source est dans posts/. Les URLs sont préservées.
• Friction migration : 16 dossiers à déplacer, 16 fichiers à éditer pour ajouter url:
• Liens internes dans le contenu Markdown — nombreux articles se citent les uns les autres. À auditer pour s’assurer qu’ils restent corrects.

Option B — Garder la racine

content/
├── csp-nonce/index.fr.md
├── post-mortem-522-wan-failover/
├── ...
├── privacy-policies/
├── documentation/
└── scripts/

Avantages

• URLs identiques sans rien faire — /csp-nonce/ reste /csp-nonce/
• Pas de migration : 0 fichier touché
• Liens internes : intacts par définition
• Override layouts/home.html déjà en place : 1 ligne de différence, ça marche

Inconvénients

• Override custom à maintenir si LoveIt évolue
• Lisibilité repo : pages de référence et articles mélangés à la racine
• Convention bizarre : un dev Hugo découvrant le repo se demande pourquoi pas de posts/

Considérations SEO

Le SEO craint le changement d’URL. Si je migre vers posts/ SANS url: override, les 16 articles passent de arleo.eu/csp-nonce/ à arleo.eu/posts/csp-nonce/. Cloudflare cache, Google indexe, robots.txt connaît la map du site… tout doit être ré-indexé.

Avec url: override (Option A v2), aucun changement d’URL. Mais alors quel est l’intérêt de migrer ? Juste la lisibilité du repo. Le coût (16 fichiers à éditer) vs le bénéfice (lisibilité interne) → probablement pas rentable.

Considérations Hugo MCP

Les outils MCP que j’utilise pour éditer le contenu (hugo-mcp v1.8.1) acceptent une route comme paramètre : create_page(route="/csp-nonce"). Le mapping route → fichier est défini par Hugo.

Si je migre vers posts/ :

• Avec url: override : MCP appelle create_page(route="/csp-nonce"), le fichier est créé à content/posts/csp-nonce/index.fr.md mais la page est servie à /csp-nonce/. Workflow inchangé pour l’utilisateur.
• Sans url: override : MCP doit appeler create_page(route="/posts/csp-nonce"). Workflow différent. Tous les articles existants tombent sur des routes inconnues.

Je penche fortement pour l’Option A v2 (migration + url: override) si je migre.

La décision (provisoire)

Statut : ✅ LIVRÉ — sprint clos le 9 mai 2026

Mise à jour 9 mai 2026 (fin de session) : les 10 chantiers sont livrés en une session marathon, et les 3 releases coordonnées sont publiées (hugo-mcp v1.9.0, mcp-oauth-proxy v2.1.0, mcp-installer v1.3.0). Tout l’écosystème MCP est durci dans la même journée. Recap technique complet : Sprint sécurité MCP livré : v1.9.0, 10 chantiers, écosystème durci.

Cette page reste publiée à fins d’archive — pour montrer la trajectoire d’un sprint annoncé puis tenu. Tout le contenu original ci-dessous est préservé.

Statut original (avant livraison)

Cette page documentait publiquement un sprint de hardening en cours sur l’infrastructure MCP d’arleo.eu. Pour des raisons de sécurité, les détails précis des chantiers n’étaient pas exposés tant que les correctifs n’étaient pas livrés (philosophie “sec-first” : ne pas publier de roadmap d’attaque).

Pourquoi cette transparence

J’ai débattu de publier ou non cette page. Arguments pour la transparence :

• Engagement public = pression saine sur soi-même pour livrer
• Documentation d’un homelab dont l’objectif est apprendre et partager
• Honnêteté vis-à-vis des lecteurs qui consomment les autres articles techniques

Arguments contre :

• Roadmap d’attaque : si je liste précisément ce qui n’est pas encore protégé, je donne des indices à un attaquant patient
• Pression artificielle : annoncer un sprint puis ne pas livrer = pire que ne rien annoncer

Compromis adopté : publier la direction et les domaines de hardening sans préciser ce qui est faible aujourd’hui. Détail technique précis publié à la livraison.

Domaines couverts par le sprint

Le sprint couvrait 10 chantiers regroupés en 4 domaines :

1. Hardening applicatif (FastAPI + Pydantic)

Renforcement des couches d’entrée du MCP : validation stricte des inputs, gestion d’erreurs unifiée, pas de leak d’information dans les responses (stack traces, paths internes, versions de libs).

2. Authentification et tokens

Refonte de la gestion des tokens d’accès au MCP : durée de vie, rotation, révocation, hashing en stockage. Permettre de couper l’accès d’un client compromis sans redéployer le service.

3. Observabilité et audit

Intégration de logs structurés JSON ingérés dans BetterStack via Vector. Chaque appel MCP doit produire un événement traçable : qui, quoi, quand, durée, statut. Permet la détection d’anomalies en quasi-temps réel.

4. Infrastructure et résilience

TLS pour le trafic interne entre le NUC et la VM, règles ModSec dédiées au path /mcp, runbook de récupération en cas de désastre (vol de tokens, compromise serveur, perte de données).

Ce qui était déjà en place avant le sprint

Pour ne pas créer de fausse impression, voici les couches déjà en place sur l’infrastructure avant le sprint (donc hors scope) :

• nginx + TLS 1.3 obligatoire (Mozilla Modern config)
• Cloudflare WAF + Bot Management + IP whitelist
• ModSecurity + OWASP CRS 4.x sur tous les vhosts
• CrowdSec en mode WAF + bouncer Cloudflare
• systemd hardening niveau 1.7 (cf. hardening systemd)
• HMAC validation sur les webhooks
• Frontmatter validation Pydantic (1 chantier sur 4 dans la catégorie validation)

Le sprint visait à compléter cette base, pas à la remplacer.

Méthode

Pour chaque chantier :

1. Implémenté en local + tests unitaires
2. Validé sur mcp-test-vm (VM de pré-prod)
3. Déployé sur prod uniquement après tests réussis
4. Audit log structuré JSON pour traçabilité du déploiement
5. Article post-mortem ou write-up technique publié après livraison

Aucun déploiement direct prod sans étape pré-prod.

Releases publiées

Statut : 🗂️ BACKLOG — pas encore implémenté

Cette page documente une intention d’architecture qui sera implémentée dans une prochaine itération. Le code n’est pas encore en prod.

Contexte

Dans la Stratégie 4 (séparation MCP / Git), j’ai expliqué pourquoi content/ est dans .gitignore côté repo arleo.eu : pour qu’aucun conflit ne soit possible entre l’écriture MCP et l’écriture Git.

Concrètement, ça veut dire que quand je push depuis VS Code une nouvelle version de layouts/, themes/, static/, hugo.toml, ou deploy.sh, rien ne se passe automatiquement côté serveur. Je dois SSH dans la VM Hugo et faire git pull && hugo --minify && rsync à la main.

C’est pas critique (push de structure = ~1× par semaine), mais c’est de la friction inutile. Donc : webhook GitHub → rebuild auto.

Architecture cible