Roadmap : faut-il migrer les 16 articles vers content/posts/ ?

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)

Garder la racine pour l’instant.

Raisons :

1. Le coût de migration (16 fichiers + audit liens internes + tests Hugo MCP) > bénéfice (lisibilité interne)
2. L’override layouts/home.html est minimal (1 ligne) et stable. Pas de fardeau de maintenance significatif.
3. Les articles nouveaux (depuis ce sprint éditorial du 9 mai 2026) sont créés dans content/posts/ directement. Donc le repo va devenir hybride : ancien à la racine, nouveau dans posts/. Pas idéal en théorie, acceptable en pratique.

Cette décision sera reconsidérée si :

• LoveIt fait une release qui ajoute des features à Type: posts que je veux exploiter
• Je décide de revoir entièrement la structure du contenu (refonte d’archi)
• Un dev tier veut contribuer (la lisibilité du repo devient plus importante)

État actuel

Le repo est donc actuellement hybride — c’est inhabituel mais ça marche. La home Hugo affiche les deux familles d’articles correctement grâce à l’override custom.

Référence

Pour les curieux qui veulent comprendre l’override exact :

<!-- layouts/home.html (1 ligne diff vs LoveIt original) -->
{{- range (where .Site.RegularPages "Type" "in" (slice "posts" "page")) -}}
                                                ^^^^^^^^^^^^^^^^^^^^^
                                                Diff: accepte "page" en plus de "posts"

C’est tout. Merci LoveIt d’être un thème simple à override.