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