J’ai ce blog (sous une forme ou une autre) depuis 2010.
Comme beaucoup de blogs de devs, il a accumulé des années de « voici le fix », « voici le lien » et « futur-moi va me dire merci ».
Et puis… la vie arrive. La plateforme change, le domaine change, des images disparaissent, et l’archive devient tranquillement plus difficile à maintenir.
Donc je l’ai reconstruit.
Cette fois, c’était pas « juste un redesign ».
Je migrais d’une installation BlogEngine.NET basée sur des fichiers vers Markdown + Hugo. Du vrai travail.
Mon stack est volontairement ennuyeux : Hugo pour le contenu et Azure Static Web Apps pour l’hébergement.
Le gros du travail, c’était pas de choisir les outils. C’était de garder ce qui compte intact.
Mes règles
- Les vieux liens doivent continuer de fonctionner.
- L’anglais et le français doivent rester de première classe.
- Publier doit ressembler au développement : éditer → commit → PR → merge.
Ce dernier point explique pourquoi tout vit sur GitHub. C’est pas glamour, mais c’est le workflow le plus robuste que je connais (et je l’utilise tous les jours).
Inventaire (aka : ce que je migrais vraiment)
- Des articles à travers plusieurs ères technologiques
- Un mélange de trucs rapides et d’articles plus longs
- Du contenu bilingue
- Une pile d’URLs legacy (incluant les vieilles routes
.aspx)
Migrer vers du Markdown, c’est facile. Migrer les attentes, c’est autre chose.
Ce que je refusais de briser : les URLs
Je veux pas être la personne qui casse un lien que quelqu’un a bookmarké en 2011.
Donc j’ai gardé la forme des permalinks cohérente. Dans ma config Hugo, ça ressemble à :
[permalinks]
[permalinks.page]
post = "/:year/:month/:slug/"
Et pour les vraiment vieilles routes, les alias Hugo font le travail. Exemple d’un des posts de 2010 :
aliases:
- /post/2010/03/24/ASPNet-Path.aspx
C’est pas du travail excitant. Mais c’est le genre de détail qui fait la différence.
Contenu bilingue (sans en faire un projet de maintenance)
Je maintiens des posts EN/FR depuis des années. C’est du travail supplémentaire, mais ça en vaut la peine.
Pendant la migration, j’ai aussi trouvé quelques posts qui existaient seulement dans une langue.
J’ai utilisé l’IA pour m’aider à traduire ces versions manquantes, histoire que l’archive reste cohérente (et pour éviter de transformer ça en marathon de traduction de plusieurs mois).
Ce qui a vraiment aidé, c’est d’adopter les page bundles pour les nouveaux posts : un dossier par post, avec un index.en.md et (optionnellement) index.fr.md.
Les images vivent à côté du post qui les utilise. Plus de « où est-ce que j’ai mis ce PNG en 2013? »
La config des langues dans Hugo est simple. Dans mon hugo.toml :
[Languages]
[Languages.fr]
LanguageCode = "fr"
weight = 1
[Languages.en]
LanguageCode = "en"
weight = 2
Le français est défini comme DefaultContentLanguage, le weight détermine l’ordre du menu et Hugo gère le routage.
Quand index.en.md et index.fr.md existent tous les deux, ils sont traités comme le même post dans différentes langues, pas comme des posts séparés.
Hugo : ennuyeux c’est bien
J’ai utilisé assez de moteurs de blog pour apprendre un pattern : si publier a de la friction, tu arrêtes de publier.
Hugo garde ça simple : Markdown en entrée, fichiers statiques en sortie.
Une note de mon setup : j’ai laissé les métadonnées Git désactivées (enableGitInfo).
Ça causait des problèmes dans le conteneur de build Azure pour moi, et je préfère des déploiements fiables à un beau « dernière mise à jour » automatique.
J’ai gardé les touches SEO-friendly : enableRobotsTXT = true génère un robots.txt, et j’ai ajusté le cache d’images ([caches.images]) pour que les rebuilds restent rapides.
C’est le genre de config pas sexy qui paie quand ton site se fait crawler ou quand tu itères.
Azure Static Web Apps : hébergement simple qui reste hors du chemin
Je voulais des previews sur les PRs et des déploiements automatiques sur merge, sans avoir à surveiller un serveur.
Un autre bonus : Azure Static Web Apps peut builder des sites Hugo directement.
Résultat : moins d’étapes custom et moins d’« archéologie CI » plus tard.
Le workflow est essentiellement : checkout le repo (incluant le thème comme submodule Git) → build avec Hugo → publier le dossier public.
Voici la forme pertinente de l’Action GitHub :
- uses: actions/checkout@v6
with:
submodules: true
- uses: Azure/static-web-apps-deploy@v1
with:
app_location: "/"
output_location: "public"
env:
HUGO_VERSION: 0.147.2
Le submodules: true est important : ça tire le thème (beautifulhugo) qui vit dans Git comme submodule, pas checké dans le repo principal. Épingler HUGO_VERSION a l’air d’un petit détail, mais ça prévient le classique « ça marchait hier » quand l’image de build change.
C’était surtout des petits fixes
C’était beaucoup de :
- Fixer quelques chemins d’images
- Normaliser le front matter
- Mettre à jour quelques liens internes
- Décider ce qui reste comme artefact historique vs. ce qui mérite un refresh
Pas difficile. Juste constant.
Si vous pensez à reconstruire un vieux blog, commencez par ça :
- Décidez votre forme de permalink en premier
- Gardez vos URLs legacy vivantes (aliases/redirects)
- Gardez les assets proches des posts (les page bundles aident beaucoup)
- Automatisez les déploiements pour que l’écriture reste la partie difficile
Bons déploiements (et pas de liens cassés).