TL;DR

Le plugin Cloudflare de hugo-mcp v2.0 implémente 3 modes de purge cache (full, partial, smart). Le mode partial calcule les URLs liées à invalider (canonique + sitemap + RSS + listing + home) pour préserver 95% du cache CDN à chaque modification. Concrètement : 6 URLs purgées au lieu de tout vider. Ce post détaille le calcul, les pièges, et pourquoi smart est devenu le défaut.

TL;DR

hugo-mcp v2.0.0 introduit un plugin-system Python qui permet à n’importe qui d’ajouter des hooks après chaque create_page / update_page / delete_page. 200 lignes de code pour le coeur, 3 plugins de production fournis (IndexNow, Google Indexing, Cloudflare). Ce post explique le design, les arbitrages, la sécurité, et montre comment écrire son propre plugin en 5 minutes.

TL;DR

Le 9 mai 2026, j’ai livré en une session marathon les 10 chantiers du sprint sécurité MCP que j’avais annoncé en début de journée. hugo-mcp est désormais en v1.9.0 (GitHub Release), commit 1404f83 GPG-signé.

Voici le recap haute-volée + un zoom pédagogique sur 2 chantiers qui ont une vraie valeur en dehors de mon contexte précis : C2 token rotation et C6 TLS interne.

Recap des 10 chantiers

Détails complets dans le CHANGELOG v1.9.0 et le commit 1404f83.

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

Le symptôme

Je viens de finaliser un endpoint webhook dans le hugo-mcp-proxy qui recevra des notifications de GitHub à chaque push sur le repo arleo.eu. Implementation propre : HMAC-SHA256, rate limiting, IPAddressAllow GitHub ranges côté systemd.

Test fonctionnel depuis un client externe :

$ curl -X POST https://mcp-hugo.arleo.eu/webhook/test \
    -H "Content-Type: application/json" \
    -d '{"test": true}'

Réponse : 403 Forbidden.

Curieux. Le service tourne, l’IP source de mon test est dans le whitelist, le HMAC est correct. Pourquoi 403 ?

Investigation côté serveur

Logs nginx côté NUC :

$ sudo tail -100 /var/log/nginx/mcp-hugo.access.log | grep webhook

Vide. Aucune requête n’arrive sur nginx.

Logs mcp-oauth-proxy :

$ sudo journalctl -u mcp-oauth-proxy -n 100 | grep webhook

Vide aussi. La requête n’arrive pas jusqu’au service.

Soit elle est bloquée par firewall avant nginx (CrowdSec ou ufw), soit en amont par Cloudflare.

La vérité côté Cloudflare

Le bug

mcp-installer est un script bash que j’ai écrit pour automatiser l’installation du mcp-oauth-proxy (FastAPI + nginx + systemd) sur un nouveau host. Workflow standard : clone, run, c’est tout.

Sauf qu’en relançant le script sur un host déjà installé (par exemple pour mettre à jour la version), j’ai découvert un bug d’idempotence : tous les secrets étaient régénérés.

$ sudo ./install.sh
[+] Generating MCP_TOKEN...
[+] Generating CLIENT_ID...
[+] Generating CLIENT_SECRET...
[+] Generating TOKEN_SECRET...
[+] Writing /etc/mcp-oauth-proxy/.env...

Si tu as déjà un .env avec des tokens en service, l’installer les écrase. Tous les clients OAuth déjà enregistrés (Claude.ai dans mon cas) se retrouvent avec des credentials invalides. La connexion casse.

Pourquoi c’est arrivé

Le script utilisait cette logique :

MCP_TOKEN=$(openssl rand -hex 32)
CLIENT_ID=$(openssl rand -hex 16)
CLIENT_SECRET=$(openssl rand -hex 32)
TOKEN_SECRET=$(openssl rand -hex 32)

cat > /etc/mcp-oauth-proxy/.env <<EOF
MCP_TOKEN=$MCP_TOKEN
CLIENT_ID=$CLIENT_ID
CLIENT_SECRET=$CLIENT_SECRET
TOKEN_SECRET=$TOKEN_SECRET
EOF

Le pattern « génère puis écris » est correct pour une première install. Mais en relance, il ignore complètement le .env existant.

C’est l’erreur classique : l’auteur (moi) a testé le script uniquement sur un host fresh. Le mode “réinstall sur host existant” n’a jamais été testé.

Reproduction du bug

$ sudo ./install.sh
[OK] Installation complete
$ cat /etc/mcp-oauth-proxy/.env | head -1
MCP_TOKEN=a7f3e9d2c4b8a1...

$ sudo ./install.sh
[OK] Installation complete
$ cat /etc/mcp-oauth-proxy/.env | head -1
MCP_TOKEN=8c2f6a1b9e4d7c...   ← DIFFÉRENT

Test reproductible en 30 secondes. C’est presque comique que je ne l’aie pas vu plus tôt.

La leçon : “idempotent” est un contrat, pas un espoir

Un script d’installation doit être idempotent par défaut. C’est-à-dire : ./install.sh 1 fois, 2 fois, 5 fois → le système est dans le même état stable.

J’avais ce contrat dans ma tête. Je ne l’avais pas dans le code.

Le fix : pre-flight checks + force flag explicite

Contexte

J’ai mis en production un Hugo MCP Server (FastAPI, 7 tools) qui me permet d’éditer arleo.eu depuis Claude.ai. Architecture : claude.ai → mcp-oauth-proxy NUC → hugo-mcp-proxy NUC → MCP server VM.

Le problème

Tu as un site Hugo. Tu veux pouvoir :

1. Éditer le contenu via Claude.ai (publier un article, corriger une coquille, mettre à jour un draft) sans toucher à un terminal SSH.
2. Versionner la structure (layouts, themes, hugo.toml, scripts de déploiement) dans Git, comme un dev sérieux.

Premier réflexe : « tout dans Git ». Les articles aussi. Le MCP commit, push, le webhook GitHub fait un rebuild. Propre, dans la philosophie GitOps.

Sauf que ça ne marche pas si bien. Voici pourquoi, et la solution simple que j’appelle la Stratégie 4.

Pourquoi « tout dans Git » casse en pratique

Imaginons que ton MCP fait un git commit à chaque create_page. Stratégie naïve, mais souvent proposée. Voici les problèmes :

Problème 1 — Conflit MCP ↔ Git

Tu push depuis ton laptop un nouveau layout (layouts/index.html modifié). Au même moment, le MCP est en train de commiter une nouvelle version d’un article. Race condition, le MCP peut faire un git pull --rebase qui échoue, ou pire, écraser ton commit local.

Problème 2 — Identité Git du MCP

Le MCP commit en tant que qui ? Avec quelle clé GPG ? Si tu as une politique « commits signés obligatoires », le MCP doit gérer une clé GPG, qu’il faut sécuriser, faire tourner, etc.

Problème 3 — Auto-commit indésirable

Tu fais un test, tu crées un article draft pour expérimenter, tu le supprimes. Mais le MCP a déjà commité. Maintenant tu as un commit “wip test” dans l’historique, à rebaser ou squasher manuellement.

Problème 4 — Réversibilité asymétrique

Un git revert côté repo n’a aucun effet sur les fichiers que le MCP a déjà créés. Tu te retrouves avec un repo et un état filesystem désynchronisés.

La Stratégie 4 : séparer les zones

L’idée : MCP et Git n’écrivent jamais sur les mêmes fichiers.

Le .gitignore côté repo :

content/
public/
resources/

Implications :

• Le MCP peut écrire dans content/ quand il veut. Aucun conflit Git possible.
• Tu peux faire git reset --hard côté repo en confiance — content/ reste intact.
• Pas besoin que le MCP gère une identité Git.
• Pas de “commit pollution”.

Trade-off : pas de versioning du contenu

Tu perds le versioning Git du contenu. C’est une perte réelle :

• Pas de git blame sur un article pour voir qui a écrit quoi.
• Pas de git log content/csp-nonce/index.fr.md pour voir l’historique.
• Pas de PR review pour les articles.

Mitigation : snapshots VM + backup content/ chiffré quotidien sur QNAP. Ça couvre la récupération en cas de désastre, mais pas le versioning fin (qui-a-changé-quoi-quand).

Pour mon homelab perso (un seul auteur, articles techniques, pas de workflow de validation éditoriale), c’est un trade-off acceptable. Pour un blog d’équipe avec 10 contributeurs, je reconsidérerais.

Architecture finale

⚡ En bref

Connecter Claude.ai à un site Hugo hébergé dans une VM KVM en 30 minutes : un serveur FastAPI expose 6 outils MCP (lire, créer, modifier, supprimer des pages, rebuilder le site) via JSON-RPC 2.0, un proxy OAuth réutilise l’infrastructure existante, et chaque modification déclenche automatiquement un rebuild Hugo + une purge du cache Cloudflare.

Le code est disponible sur GitHub :

• 🔌 Serveur MCP Hugo : jmrGrav/hugo-mcp
• 🔐 Proxy OAuth : jmrGrav/mcp-oauth-proxy

🧠 Pourquoi

Le protocole MCP (Model Context Protocol) d’Anthropic permet à Claude.ai de se connecter à des sources de données externes via des outils standardisés. Contrairement à Grav CMS qui est dynamique (PHP), Hugo génère du HTML statique — ce qui rend la gestion de contenu via MCP encore plus puissante : chaque modification est compilée et déployée instantanément.