--- title: "Roadmap : faut-il migrer les 16 articles vers content/posts/ ?" description: "Réflexion sur la migration éventuelle des 16 articles de la racine content/ vers content/posts/ pour respecter la convention LoveIt. Trade-off : conserver les URLs vs cohérence section. Décision : garder la racine pour l'instant." url: "https://www.arleo.eu/posts/roadmap-migration-content-posts/" language: "fr" datePublished: "2026-05-09T12:48:49+02:00" dateModified: "2026-05-15T23:51:25+02:00" tags: ["roadmap","hugo","content","architecture"] categories: ["roadmap"] contentSignal: "ai-train=no, search=yes, ai-input=yes" --- # Roadmap : faut-il migrer les 16 articles vers content/posts/ ? Réflexion sur la migration éventuelle des 16 articles de la racine content/ vers content/posts/ pour respecter la convention LoveIt. Trade-off : conserver les URLs vs cohérence section. Décision : garder la racine pour l'instant. ## 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) {{< mermaid-svg hash="c8e7a25f" >}} **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 | Type | Localisation | Nombre | |------|--------------|--------| | Anciens articles (migrés depuis Grav) | `content/` (racine) | 16 | | Nouveaux articles (post-2026-05-09) | `content/posts/` | 9 (cette session) | | Pages de référence (privacy, docs, scripts) | `content/` (racine) | 3 | 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 : ```html {{- 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. ## Tags - roadmap - hugo - content - architecture ## Categories - roadmap