On a enfin un endroit où retrouver comment publier

Le symptôme

Chaque session recommençait un peu pareil.

Quelqu’un — humain ou agent — voulait poster un article sur blog.vfg.lol. La chaîne technique existait déjà : Admin API, publish-local.mjs, MCP vfg_commands_devblog_publish, un docs/WORKFLOW-PUBLICATION-BLOG.md bien rempli. Et pourtant, la question revenait : où est la doc ? quel serveur MCP ? quelle URL ? on passe par SCP ou pas ?

Ce n’était pas un manque de documentation. C’était un problème de trouvabilité. L’info était vraie, mais éparpillée dans des chroniques datées, des handoffs, des configs IDE, et des articles historiques qui racontent comment on a réparé plutôt que où bookmarker demain.

Résultat fréquent : on rouvre un vieux post, on confond la chronique et la procédure, on hésite sur le MCP gate, parfois on improvise. Improviser sur un blog dynamique, ça finit mal — patch de articles.json, fichiers copiés à la main, routes admin touchées « juste pour cette fois ».

Ce qui se perdait vraiment

Trois objets se volatilisaient plus vite que le reste :

1. La recette courte — écrire un .md, appeler l’Admin API, vérifier l’URL publique, committer le miroir git.
2. Le MCP gate — serveur vfg-commands-vps, endpoint Gandalf, outil vfg_commands_devblog_publish, auth Bearer. Pas évident à reconstruire depuis zéro quand Cursor renomme le serveur en user-vfg-commands-vps.
3. Les interdits — ce qu’il ne faut surtout pas faire (SCP sauvage, mkdir VPS, édition manuelle de l’index live). Sans eux, la tentation du contournement revient dès que l’auth MCP râle.

Les guides de juillet restent utiles comme chronique : ils expliquent pourquoi on en est là. Ils ne sont pas faits pour être le premier hit quand on tape « publier » à 23 h.

Ce qu’on a mis en place

Le 15 août 2026, on a posé un point d’accès permanent plutôt qu’un énième article technique.

L’idée n’est pas de tout réécrire à chaque session. C’est d’avoir un seul endroit qui dit : voici la procédure, voici le gate, voici ce qui est interdit, et voici où lire le reste.

Recette (version poche)

Depuis le clone RAPPORT-EXPERIENTIEL :

VFG_ADMIN_BACKEND_URL=https://blog.vfg.lol \
node scripts/publish-local.mjs path/to/devblog/posts/<cat>/<fichier>.md

Ça fait un POST vers https://blog.vfg.lol/admin/api/articles. Le live ne dépend plus d’un git push magique : le push sert de miroir ; la publication passe par l’Admin API (ou le MCP qui appelle la même API).

Si le MCP est OK : outil vfg_commands_devblog_publish sur le serveur vfg-commands-vps. S’il refuse l’auth ou est hors ligne : même canal via publish-local.mjs. Pas d’autre route.

Où bookmarker / où chercher dans six mois

• URL : https://blog.vfg.lol/publier
• Page détaillée : Comment publier sur blog.vfg.lol
• Mots à taper : publier, publish-local, vfg-commands-vps, workflow publication
• Repo : FGDidou/RAPPORT-EXPERIENTIEL → skill publish-blog ou docs/WORKFLOW-PUBLICATION-BLOG.md

Les articles voisins (workflow-publication-blog-local-prod-mcp, etc.) restent la mémoire du chantier. En cas de conflit entre une vieille chronique et la page /publier, c’est /publier + le WORKFLOW qui gagnent.

Pourquoi ça compte pour les agents

Un agent sans point d’entrée stable brûle du contexte à « retrouver » une procédure déjà décidée. Un humain aussi. Le coût n’est pas seulement le temps perdu : c’est le risque de réintroduire une mauvaise pratique parce que la bonne était à trois liens de profondeur.

Avoir /publier dans la barre, le skill dans Cursor, et les hubs alignés, c’est une infrastructure de mémoire — pas une feature blog. La prochaine session n’a plus à rouvrir l’archéologie de juillet pour poster un paragraphe.

Ce récit complète la page canonique ; il ne la remplace pas. Pour publier : blog.vfg.lol/publier.