Markdown on kenji.blog

Introduction à Hugo en tant que générateur de site statique (guide de migration depuis WordPress)

Sun, 13 Sep 2026 02:00:00 +0900

Dans le développement web moderne et la gestion de blogs, la vitesse d’affichage, la sécurité et la maintenabilité d’un site sont des éléments cruciaux. Longtemps leader incontesté en tant que fondation pour les blogs et les sites d’entreprise, “WordPress” est utilisé par de nombreux utilisateurs grâce à son écosystème de plugins flexible et son interface d’administration intuitive. Cependant, parce qu’il implique une communication avec une base de données et la génération dynamique de pages côté serveur (traitement via PHP), il présente également des vulnérabilités face aux pics de trafic et des problèmes de latence (retards d’affichage).

C’est pourquoi les “Générateurs de Sites Statiques (SSG: Static Site Generator)” connaissent une diffusion rapide ces dernières années. Dans cet article, nous allons nous pencher sur “Hugo”, un SSG développé en langage Go et connu pour sa vitesse de compilation (build) impressionnante, parmi de nombreux autres SSG. Nous l’expliquerons en détail, de la comparaison de son architecture technique avec les CMS dynamiques (Content Management System) tels que WordPress, aux procédures de migration concrètes, en passant par une évaluation des performances à l’aide de modèles mathématiques, ainsi que la structure des répertoires et l’ordre de recherche des modèles (templates) spécifiques à Hugo.

1. Différences techniques entre un CMS dynamique (WordPress) et un générateur de site statique (Hugo)

Dans la façon dont ils distribuent un site web, WordPress et Hugo adoptent des approches fondamentalement différentes.

1.1 Architecture de WordPress (Génération dynamique)

WordPress est un représentant typique des CMS dynamiques qui construisent la page côté serveur à chaque requête. Lorsqu’un utilisateur (navigateur) accède à une page, le serveur web (Apache, Nginx, etc.) exécute des scripts PHP et envoie une requête à une base de données relationnelle telle que MySQL (ou MariaDB). Il combine le contenu récupéré de la base de données (données d’articles, catégories, tags, paramètres du site, etc.) avec des fichiers de modèles (templates) pour générer le code HTML final et le renvoyer au client.

Bien que ce système ait l’avantage de pouvoir générer en temps réel un contenu différent pour chaque visiteur (ex : panier d’un site e-commerce, page dédiée aux utilisateurs connectés), il consomme énormément de ressources serveur, à moins qu’un mécanisme de cache (reverse proxy, plugins, etc.) ne soit correctement configuré.

1.2 Architecture de Hugo (Génération préalable à la compilation)

D’autre part, comme son nom de “générateur de site statique” l’indique, Hugo effectue la génération du contenu au moment de la “compilation (build)” et non au moment de la “requête”. Le contenu n’est pas conservé dans une base de données, mais sous forme de “fichiers Markdown” locaux dont les versions sont gérées via Git, etc. Lorsque le développeur exécute la commande (hugo), Hugo lit les fichiers Markdown, injecte les données dans les modèles HTML spécifiés (fichiers de layout) et génère un ensemble de fichiers HTML/CSS/JS purs et complets.

L’ensemble des fichiers générés (assets statiques) peut être distribué simplement en le plaçant sur un “environnement d’hébergement statique” tel qu’Amazon S3, Cloudflare Pages, Netlify, Vercel, ou un simple serveur Nginx. Puisqu’il ne nécessite ni base de données ni langage côté serveur (comme PHP), les risques de sécurité (injections SQL, vulnérabilités PHP, etc.) sont drastiquement réduits, et la vitesse de distribution est maximisée en étant mise en cache sur les nœuds périphériques (edge nodes) d’un CDN (Content Delivery Network).

Les schémas Mermaid ci-dessous illustrent les différences entre chaque architecture.

flowchart TD
subgraph WordPress["CMS Dynamique (WordPress)"]
direction TB
Req1["Requête de l'utilisateur"] --> WebServer1["Serveur Web (Nginx/Apache)"]
WebServer1 --> PHP["Interpréteur PHP"]
PHP <--> DB["Base de données (MySQL)"]
PHP --> HTML1["Génération HTML"]
HTML1 --> Res1["Renvoi de la réponse"]
end
subgraph Hugo["Générateur de site statique (Hugo)"]
direction TB
Dev["Développeur / CI・CD"] --> HugoBuild["Processus de compilation Hugo"]
Markdown["Fichiers Markdown"] --> HugoBuild
Templates["Modèles (HTML)"] --> HugoBuild
HugoBuild --> StaticFiles["Fichiers statiques (HTML/CSS/JS)"]
StaticFiles --> CDN["CDN / Hébergement statique"]
Req2["Requête de l'utilisateur"] --> CDN
CDN --> Res2["Renvoi de réponse instantanée"]
end

2. Évaluation des performances par des modèles mathématiques

L’un des plus grands avantages de la migration de WordPress vers Hugo est l’amélioration des performances (vitesse d’affichage). Pour comprendre cela quantitativement, exprimons-le avec un modèle mathématique simple.

Le temps jusqu’à ce que le chargement de la page soit terminé (Load Time : $T_{load}$) est principalement divisé en temps de réponse du serveur (TTFB : Time To First Byte) et en temps de rendu/récupération des ressources par le navigateur ($T_{render}$).

$$ T_{load} = T_{ttfb} + T_{render} $$

Dans le cas d’un CMS dynamique (WordPress), le $T_{ttfb}$ est la somme des éléments suivants : latence du réseau ($T_{network}$), temps d’exécution des scripts côté serveur ($T_{php}$) et temps de traitement des requêtes de la base de données ($T_{db}$).

$$ T_{ttfb\_wp} = T_{network} + T_{php} + T_{db} $$

Dans un état où les accès sont concentrés (forte charge), $T_{php}$ et $T_{db}$ augmentent de manière non linéaire, et le système dans son ensemble peut devenir un goulot d’étranglement. Exprimé sous forme de formule, par rapport au nombre de requêtes ($N$), on observe la détérioration du temps de réponse suivante ($k$ est le coefficient de surcharge de traitement).

$$ T_{php}(N) \approx O(N^k), \quad T_{db}(N) \approx O(N^k) \quad \text{where } k > 1 $$

D’autre part, dans une architecture combinant un générateur de site statique (Hugo) et un CDN, il n’y a pas de traitement dynamique côté serveur (PHP ou requêtes DB). Comme le contenu est mis en cache sur des serveurs périphériques (edge servers) répartis dans le monde entier, le $T_{ttfb}$ dépend purement et uniquement de la latence du réseau du client jusqu’au serveur périphérique le plus proche ($T_{edge}$).

$$ T_{ttfb\_hugo} = T_{edge} $$

Par conséquent, $T_{edge} \ll (T_{network} + T_{php} + T_{db})$ se vérifie, et le TTFB est drastiquement réduit à quelques millisecondes à quelques dizaines de millisecondes. De plus, même si le nombre de requêtes $N$ augmente, le temps de réponse reste presque constant ($O(1)$) grâce à la fonction de répartition de charge (load balancing) des serveurs périphériques.

$$ \lim_{N \to \infty} T_{ttfb\_hugo}(N) \approx \text{Constant} $$

Ceci est la justification mathématique expliquant pourquoi Hugo (site statique) est extrêmement robuste face aux pics de trafic (par exemple, lors d’un buzz).

3. Structure de base et principes de fonctionnement de Hugo

Pour maîtriser Hugo, il est essentiel de comprendre sa structure de répertoires unique et les concepts de “Front Matter” et de “Template Lookup Order” (Ordre de recherche des modèles).

3.1 Explication détaillée de la structure des répertoires

Lorsque vous créez un nouveau projet Hugo (hugo new site mysite), la structure de répertoires suivante est générée.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


mysite/
├── archetypes/ # Modèles (templates) lors de la création de nouveau contenu (modèles pour Front Matter)
├── assets/ # Fichiers traités par Hugo Pipes (SCSS/Sass, JavaScript, etc.)
├── content/ # Contenu réel du site (fichiers Markdown). Remplace la DB.
├── data/ # Données externes et paramètres utilisés sur l'ensemble du site (JSON, TOML, YAML, CSV, etc.)
├── layouts/ # Modèles HTML déterminant l'apparence du site (utilise Go html/template)
├── public/ # Emplacement où les fichiers statiques générés sont placés après l'exécution de la commande de compilation
├── static/ # Fichiers statiques publiés tels quels (images, favicon, fichiers texte pour robots, etc.)
├── themes/ # Répertoire pour les thèmes tiers ou créés par soi-même
└── hugo.toml # Fichier de configuration de l'ensemble du site (auparavant config.toml était courant)

Dans WordPress, le contenu est stocké dans la table wp_posts de MySQL, mais dans Hugo, il est entièrement géré en tant que fichiers texte (principalement Markdown) dans le répertoire content/. Cela facilite la gestion des versions de contenu (Git).

3.2 Gestion de contenu : Markdown et Front Matter

Chaque fichier d’article de Hugo possède un bloc de métadonnées appelé “Front Matter” tout en haut, suivi du corps du texte (Markdown) en dessous. Le Front Matter peut être écrit en TOML, YAML ou JSON, mais le YAML est largement utilisé.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


---
title: "Comprendre la taxonomie de Hugo"
date: 2026-09-13T10:00:00+09:00
draft: false
categories:
 - "Explication technique"
tags:
 - "Hugo"
 - "Go"
aliases:
 - "/old-category/hugo-taxonomy/"
---
Le texte commence ici. Il est écrit en **Markdown**.
Nous allons expliquer les fonctionnalités puissantes de Hugo...

Ce qu’il faut noter ici, c’est la clé aliases. Lors d’une migration depuis WordPress, si le permalien (URL) change, cela a un impact négatif important sur le SEO. En utilisant la fonction d’alias de Hugo, il suffit de spécifier l’ancienne URL, et Hugo générera automatiquement un HTML de redirection (transfert via meta refresh). C’est très pratique car cela élimine le besoin de configurer des redirections côté serveur (comme .htaccess).

3.3 Ordre de recherche des modèles (Template Lookup Order)

L’une des fonctionnalités puissantes de Hugo est son mécanisme de recherche de modèles flexible (Template Lookup Order). Lors du rendu d’une page spécifique, Hugo recherche les répertoires et les noms de fichiers dans un ordre spécifique pour trouver le meilleur modèle.

Par exemple, pour afficher un article unique (Single Page) appelé content/post/hello-world.md, Hugo cherchera généralement un fichier de layout dans l’ordre suivant :

layouts/post/single.html
layouts/post/list.html (Ce n’est pas une erreur, mais généralement utilisé pour les listes)
layouts/_default/single.html
themes/<THEME_NAME>/layouts/post/single.html
themes/<THEME_NAME>/layouts/_default/single.html

Les développeurs peuvent écraser (overrider) les modèles du thème en créant simplement un fichier du même nom dans le répertoire layouts/ de leur propre projet, sans modifier directement le code source du thème. Cela permet d’appliquer ses propres personnalisations sans bloquer les mises à jour du thème de base.

3.4 Taxonomie (Taxonomy)

Dans Hugo, le système de classification équivalent aux “catégories” et “tags” de WordPress est appelé “Taxonomie (Taxonomy)”. Hugo prend en charge par défaut les taxonomies categories et tags, mais en éditant hugo.toml, vous pouvez ajouter librement des taxonomies personnalisées (ex : series, authors, etc.).

1
2
3
4
5
6


# Exemple de hugo.toml
[taxonomies]
 category = "categories"
 tag = "tags"
 series = "series"
 author = "authors"

Cela permet d’organiser et de lister le contenu selon divers axes.

4. Processus de migration de WordPress vers Hugo

La clé du succès d’une migration de WordPress vers Hugo est la manière de convertir proprement le contenu dynamique de la base de données en fichiers statiques (Markdown + Front Matter) tout en maintenant la structure des URL existantes.

Voici le flux de travail d’un pipeline de migration typique.

flowchart LR
WPDB["Base de données WP"] -->|Plugin| Exporter["Outil d'exportation"]
Exporter -->| Extrait Texte, \nMéta, Images | ZipFile["Fichier Zip / Dossier"]
ZipFile -->|Décompression| MarkdownFiles["Fichiers Markdown \n(content/)"]
ZipFile -->|Décompression| ImageFiles["Images \n(static/wp-content/)"]
MarkdownFiles --> Formatting["Vérification et Formatage \n(Correction des Shortcodes)"]
Formatting --> Git["Commit vers Git"]

4.1 Extraction des données et conversion en Markdown

Pour exporter les données WordPress pour Hugo, l’utilisation d’un plugin dédié est la méthode la plus simple et la plus fiable. Voici quelques approches représentatives.

Utilisation du plugin Jekyll Exporter Comme Hugo a une structure de données très similaire à celle de Jekyll, un autre SSG, l’utilisation du plugin “Jekyll Exporter” pour WordPress est une méthode courante. En installant et en exécutant ce plugin, toutes vos publications et pages statiques seront converties en fichiers Markdown avec Front Matter et pourront être téléchargées sous forme de fichier ZIP avec vos fichiers d’images.
Scripts personnalisés utilisant l’API WordPress Il s’agit de la méthode consistant à créer un script (par exemple en Python ou Node.js) qui interroge l’API REST de WordPress (/wp-json/wp/v2/posts), analyse les données JSON et génère des fichiers Markdown par vous-même. Ceci est efficace pour les sites qui utilisent intensivement des champs personnalisés complexes (comme ACF) qui ne peuvent pas être entièrement gérés par des plugins.
Utilisation de l’outil wp2hugo Il existe également une approche qui consiste à utiliser un outil CLI écrit en langage Go, par exemple, pour convertir directement le fichier XML d’exportation de WordPress (WXR) au format Hugo.

4.2 Maintien de la structure des permaliens (URL)

Pour conserver les acquis SEO, il est extrêmement important de conserver l’URL de l’époque WordPress telle quelle. Si vous aviez configuré des permaliens tels que https://example.com/2026/09/13/my-post/ dans WordPress, vous devez spécifier la structure du permalien dans le hugo.toml de Hugo.

1
2


[permalinks]
 post = "/:year/:month/:day/:slug/"

Alternativement, il est également possible de force une URL fixe pour chaque article en spécifiant directement le paramètre url dans le Front Matter. De plus, pour les pages dont les URL changent, utilisez aliases comme mentionné précédemment pour configurer des redirections.

4.3 Conversion des shortcodes

Les shortcodes spécifiques à WordPress (ex : [gallery], [caption], et codes propres à divers plugins) restent souvent sous forme de chaînes de caractères brutes lors de l’exportation et nécessitent donc une attention particulière. Celles-ci peuvent être soit supprimées en masse à l’aide de scripts de remplacement (sed ou Python), soit migrées pour être correctement rendues du côté de Hugo en utilisant la puissante fonctionnalité de shortcodes personnalisés de Hugo (en créant un layout personnalisé dans layouts/shortcodes/).

5. Outil CLI de Hugo, Compilation et Déploiement

Une fois la migration terminée, il est temps de compiler (build) le site avec Hugo et de le publier dans le monde entier. Hugo, fourni sous forme de binaire du langage Go, offre une vitesse incroyable, compilant un site de plusieurs milliers ou dizaines de milliers de pages en seulement quelques secondes.

5.1 Démarrage du serveur de développement local

Lors de la rédaction d’articles ou de l’ajustement du design, démarrez le serveur local.

1
2


# Commande pour démarrer le serveur de développement (utilisez -D pour inclure les articles brouillons)
hugo server -D

En exécutant cette commande, vous pouvez prévisualiser le site sur http://localhost:1313/. Hugo possède une puissante fonctionnalité intégrée de “LiveReload”. Dès l’instant où vous modifiez et enregistrez un fichier Markdown, un modèle ou un fichier CSS, l’écran de votre navigateur est automatiquement et très rapidement mis à jour. Ainsi, l’expérience de rédaction et de développement est bien plus confortable que sur l’écran d’administration de WordPress.

5.2 Compilation pour la production et optimisation des performances

Pour générer des fichiers statiques à déployer en environnement de production, tapez simplement hugo.

1
2


# Exécution de la compilation pour la production. L'option --minify minimise HTML/CSS/JS
hugo --minify

Grâce à cette commande, les fichiers de l’ensemble du site sont exportés vers le répertoire public/. En ajoutant l’option --minify, les sauts de ligne et espaces inutiles sont supprimés, réduisant encore davantage la taille des fichiers. Cela contribue directement à la réduction de la latence du réseau ($T_{network}$) dans le modèle mathématique mentionné précédemment.

5.3 Automatisation du déploiement (CI/CD)

Générer des fichiers statiques sur votre PC local à chaque fois et les télécharger via FTP, etc., est inefficace. Dans l’exploitation moderne des SSG, la meilleure pratique consiste à créer un environnement CI/CD qui compile et déploie automatiquement en utilisant un push vers un dépôt Git (GitHub, etc.) comme déclencheur.

Par exemple, la forme de base d’une configuration (fichier YAML) pour déployer sur Cloudflare Pages ou GitHub Pages en utilisant GitHub Actions est la suivante :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47


# Exemple de .github/workflows/hugo.yml
name: Déployer le site Hugo vers GitHub Pages

on:
 push:
 branches: ["main"]
 workflow_dispatch:

permissions:
 contents: read
 pages: write
 id-token: write

jobs:
 build:
 runs-on: ubuntu-latest
 steps:
 - name: Checkout
 uses: actions/checkout@v3
 with:
 submodules: recursive # Si vous gérez les thèmes avec des sous-modules
 fetch-depth: 0

 - name: Setup Hugo
 uses: peaceiris/actions-hugo@v2
 with:
 hugo-version: 'latest'
 extended: true

 - name: Build
 run: hugo --minify

 - name: Upload artifact
 uses: actions/upload-pages-artifact@v2
 with:
 path: ./public

 deploy:
 environment:
 name: github-pages
 url: ${{ steps.deployment.outputs.page_url }}
 runs-on: ubuntu-latest
 needs: build
 steps:
 - name: Deploy to GitHub Pages
 id: deployment
 uses: actions/deploy-pages@v2

En configurant ainsi, la simple action de “rédiger un article en Markdown et de le pousser (Push) vers GitHub” complète un pipeline automatisé où le site mis à jour est publié en environnement de production en quelques minutes.

6. Le SEO après la migration et les avantages opérationnels

Les administrateurs de site qui ont achevé la migration de WordPress vers Hugo ressentent souvent les 3 avantages notables suivants.

6.1 Amélioration spectaculaire de la vitesse du site et des Core Web Vitals

Les requêtes de base de données et le rendu côté serveur étant éliminés, le temps de chargement de la page est réduit à l’ordre des millisecondes. Cela conduit directement à une amélioration significative des scores “Core Web Vitals” (LCP, FID/INP, CLS) qui sont des facteurs de classement pour Google. On peut s’attendre à une baisse du taux de rebond (bounce rate) des utilisateurs et à une amélioration du classement SEO.

6.2 Libération face aux menaces de sécurité

Étant largement utilisé à travers le monde, WordPress est une cible constante d’attaques. Des risques persistent, tels que la falsification exploitant les vulnérabilités de plugins, ou la violation de l’écran de connexion par des attaques par force brute (brute-force). Cependant, dans un site statique généré par Hugo, il n’y a pas de base de données, pas d’environnement PHP, et même pas d’interface d’administration (formulaire de connexion). Il n’y a aucune place pour qu’un pirate informatique s’introduise dans le serveur et réécrive la base de données, les risques de sécurité s’approchant au plus près de zéro.

6.3 Une exploitation sans maintenance

L’utilisation de WordPress requiert des tâches de maintenance constantes : mise à jour du cœur du système, mise à jour des plugins, suivi des versions de PHP, etc. Vous devez constamment redouter le risque que votre site soit cassé en raison de problèmes de compatibilité. Dans le cas de Hugo, il suffit de mettre à jour l’outil lui-même si nécessaire. Le code du site étant constitué d’ensembles de fichiers texte indépendants, cela offre un sentiment de tranquillité absolue : “même s’il est laissé tel quel, il ne se cassera pas”.

7. Conclusion

Dans cet article, nous avons détaillé la migration d’un CMS dynamique tel que WordPress vers “Hugo”, un puissant générateur de site statique basé sur le langage Go, en couvrant les différences d’architecture technique, la preuve de performance via des modèles mathématiques, ainsi que les étapes concrètes de la migration.

Bien que la migration vers un générateur de site statique nécessite un coût d’apprentissage initial (utilisation de Git, syntaxe Markdown, exécution de commandes CLI depuis un terminal, compréhension des spécifications du moteur de templates, etc.), elle offre en retour une “vitesse d’affichage écrasante”, une “sécurité robuste” et un état “sans maintenance” qui compensent largement cet effort.

Si votre site web ne nécessite pas de changements fréquents de design ou de traitements dynamiques complexes (tels que des fonctionnalités réservées aux membres ou des fonctions e-commerce avancées) et que son objectif principal est la diffusion d’informations (blog, média, site d’entreprise), la migration vers Hugo constituera l’un des investissements techniques les plus efficaces. N’hésitez pas à faire de cet article votre point de départ vers la gestion de site web de nouvelle génération utilisant Hugo.

Blog technique écrit en Markdown : Paramètres d'éditeur pour doubler votre vitesse de rédaction

Sat, 12 Sep 2026 12:00:00 +0900

Pour écrire continuellement sur un blog technique, il est essentiel d’optimiser l’environnement de rédaction. Dans cet article, nous allons explorer en profondeur les paramètres d’éditeur avancés qui permettront d’améliorer de façon spectaculaire votre vitesse de rédaction de blogs techniques à l’aide de Markdown. Nous couvrirons tout de manière exhaustive : la personnalisation extrême de Visual Studio Code (VS Code) et Neovim, l’utilisation de snippets, l’introduction de textlint (un outil de vérification grammaticale), l’automatisation dans le pipeline CI/CD, et enfin les techniques de rédaction de pointe utilisant des LLM comme GitHub Copilot.

1. Modèle mathématique de l’amélioration de la vitesse de rédaction

Commençons par modéliser l’impact de l’optimisation des paramètres de l’éditeur sur le temps de rédaction avec une formule mathématique simple. Soit $T_{total}$ le temps de saisie total pour écrire un article de blog.

$$ T_{total} = T_{think} + T_{type} + T_{format} + T_{review} $$

Ici, $T_{think}$ est le temps de réflexion, $T_{type}$ est le temps de frappe, $T_{format}$ est le temps de formatage (pour Markdown, etc.), et $T_{review}$ est le temps de relecture et de correction.

Le temps économisé $T_{saved}$ grâce à la personnalisation de l’éditeur (comme l’introduction de snippets ou la configuration de Linter) peut être exprimé comme suit, en utilisant le nombre d’occurrences $N$ d’un modèle spécifique (par exemple, un shortcode Hugo ou un tableau Markdown), le temps requis pour une saisie manuelle $t_{manual}$, et le temps pris par l’automatisation via des snippets $t_{snippet}$.

$$ T_{saved} = \sum_{i=1}^{k} N_i \times (t_{manual, i} - t_{snippet, i}) + T_{review\_saved} $$

De plus, l’introduction d’outils de formatage automatique et de Linting réduit considérablement le temps de vérification visuelle humaine $T_{review}$. La maximisation de ce $T_{saved}$ est le but même de cet article.

2. La meilleure configuration pour Visual Studio Code (VS Code)

VS Code est actuellement l’un des éditeurs les plus populaires et dispose d’un puissant écosystème d’extensions pour l’écriture en Markdown.

Extensions recommandées

Pour accélérer la rédaction, nous recommandons fortement d’installer les extensions suivantes.

Markdown All in One : Il dispose de toutes les fonctionnalités de base nécessaires à la rédaction en Markdown, telles que le gras/italique avec des raccourcis clavier, la continuation automatique des listes, et la génération automatique d’une table des matières (TOC).
markdownlint : Il vous avertit en temps réel des erreurs de syntaxe Markdown et des violations de style.
vscode-textlint : Il applique un ensemble de règles destinées aux documents techniques pour éviter les incohérences de notation et les erreurs grammaticales.

Configuration de snippets personnalisés pour Hugo (`markdown.json`)

Si vous utilisez un générateur de site statique comme Hugo ou Docusaurus pour votre blog technique, vous devrez fréquemment saisir le Frontmatter ou des shortcodes spécifiques. En utilisant la fonctionnalité de snippet de VS Code, vous pouvez les développer instantanément.

Sélectionnez Preferences: Configure User Snippets dans la palette de commandes et ajoutez la configuration suivante à markdown.json.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38


{
 "Hugo Frontmatter": {
 "prefix": "frontmatter",
 "body": [
 "---",
 "title: \"${1:Titre}\"",
 "slug: \"${2:slug-name}\"",
 "date: \"$CURRENT_YEAR-$CURRENT_MONTH-$CURRENT_DATE T$CURRENT_HOUR:$CURRENT_MINUTE:$CURRENT_SECOND+09:00\"",
 "image: \"img/eyecatch.jpg\"",
 "math: true",
 "mermaid: true",
 "categories: [\"${3:Catégorie}\"]",
 "tags: [\"${4:Tag1}\", \"${5:Tag2}\"]",
 "---",
 "",
 "${0}"
 ],
 "description": "Développe le YAML Frontmatter pour Hugo"
 },
 "Hugo Figure Shortcode": {
 "prefix": "hfig",
 "body": [
 "{{< figure src=\"${1:image.jpg}\" title=\"${2:Titre de l'image}\" >}}"
 ],
 "description": "Shortcode Figure de Hugo"
 },
 "Markdown Table": {
 "prefix": "mtable",
 "body": [
 "| ${1:En-tête 1} | ${2:En-tête 2} | ${3:En-tête 3} |",
 "| :--- | :---: | ---: |",
 "| ${4:Ligne 1} | ${5:Données} | ${6:Données} |",
 "| ${7:Ligne 2} | ${8:Données} | ${9:Données} |",
 "$0"
 ],
 "description": "Génère un tableau Markdown à 3 colonnes"
 }
}

Avec cette configuration, il suffit de taper frontmatter et d’appuyer sur la touche Tab pour déployer instantanément le YAML Frontmatter incluant l’heure actuelle, augmentant ainsi considérablement la vitesse initiale de rédaction.

Assistance à la rédaction grâce à GitHub Copilot

Lorsque GitHub Copilot est activé dans VS Code, la complétion par l’IA basée sur le contexte fonctionne également en Markdown. Particulièrement pour les blogs techniques, l’IA anticipe et suggère “la prochaine structure à expliquer” ou “les blocs de code associés”, ce qui permet de réduire considérablement le temps de frappe $T_{type}$.

3. Personnalisation extrême dans Neovim

L’interface graphique de VS Code est excellente, mais pour les amateurs de terminal et les Vimmers, Neovim est le choix ultime pour tout accomplir sans jamais retirer les mains du clavier.

Architecture LSP de Neovim

L’architecture du LSP (Language Server Protocol) et du Linter de Neovim dans un environnement Markdown est la suivante.

classDiagram
class Neovim {
+"Tampon de texte"
+"Raccourcis clavier"
}
class nvim_lspconfig {
+"marksman (LSP Markdown)"
}
class null_ls_or_none_ls {
+"markdownlint"
+"textlint"
}
class LuaSnip {
+"Snippets dynamiques"
}
class CMP {
+"Moteur d'auto-complétion"
}
Neovim --> nvim_lspconfig : "Fournit des fonctionnalités sémantiques"
Neovim --> null_ls_or_none_ls : "Diagnostics et formatage"
Neovim --> CMP : "Requête de complétion"
CMP --> nvim_lspconfig : "Source LSP"
CMP --> LuaSnip : "Source de snippet"

Développement de snippets avancés avec LuaSnip

Plus puissant encore que les snippets JSON de VS Code, il y a le plugin Neovim LuaSnip. En utilisant la logique de Lua, vous pouvez calculer et déployer dynamiquement le contenu des snippets.

Voici un exemple de configuration LuaSnip qui récupère dynamiquement la date et l’heure actuelles (JST) et développe le Frontmatter de Hugo.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


local ls = require("luasnip")
local s = ls.snippet
local t = ls.text_node
local i = ls.insert_node
local f = ls.function_node

-- Fonction pour obtenir l'heure actuelle JST
local function get_current_date_jst()
 return os.date("!%Y-%m-%dT%H:%M:%S") .. "+09:00"
end

ls.add_snippets("markdown", {
 s("frontmatter", {
 t({"---", "title: \""}), i(1, "Titre"), t({"\"", "slug: \""}), i(2, "nom-du-slug"), t({"\"", "date: \""}),
 f(function() return {get_current_date_jst()} end, {}),
 t({"\"", "image: \"img/eyecatch.jpg\"", "math: true", "mermaid: true", "categories: [\""}), i(3, "Catégorie"), t({"\"]", "tags: [\""}), i(4, "Tag"), t({"\"]", "---", "", ""}),
 i(0)
 }),
 s("mtable", {
 t({"| "}), i(1, "En-tête 1"), t({" | "}), i(2, "En-tête 2"), t({" |", "|---|---|", "| "}), i(3, "Cellule 1"), t({" | "}), i(4, "Cellule 2"), t({" |"}),
 })
})

Ainsi, en exploitant la puissance d’un langage de programmation (Lua), vous pouvez créer des snippets complexes qui ne se contentent pas de chaînes de caractères fixes, mais intègrent des valeurs de retour de fonctions ou ajustent dynamiquement le nombre de colonnes d’un tableau en fonction du nombre de caractères saisis.

4. Analyse statique (textlint et expressions régulières) pour allier qualité et rapidité de rédaction

Pour garantir la qualité de votre blog, vous devez éviter les fautes de frappe et les incohérences de notation. Faire cela manuellement augmenterait de façon exponentielle $T_{review}$, c’est pourquoi nous introduisons l’analyse statique avec textlint.

Introduction de textlint et de l’ensemble de règles

Installez textlint dans l’environnement Node.js.

1

npm install -D textlint textlint-rule-preset-ja-technical-writing textlint-rule-prh textlint-filter-rule-comments

Créez un fichier .textlintrc.json à la racine de votre projet et configurez-le comme suit.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


{
 "filters": {
 "comments": true
 },
 "rules": {
 "preset-ja-technical-writing": {
 "ja-no-mixed-period": {
 "periodMark": "。"
 },
 "sentence-length": {
 "max": 100
 }
 },
 "prh": {
 "rulePaths": ["./prh.yml"]
 }
 }
}

Créez un fichier prh.yml pour définir les incohérences de notation des termes techniques. Par exemple, uniformisez “serveur” et “Serveur”, ou “Javascript” et “JavaScript”.

1
2
3
4
5
6
7
8


version: 1
rules:
 - expected: "JavaScript"
 pattern: "Javascript"
 - expected: "serveur"
 pattern: "Serveur"
 - expected: "interface"
 pattern: "Interface"

Grâce à cela, chaque fois que vous tapez du texte dans l’éditeur, vous êtes averti en temps réel des incohérences de notation, ce qui réduit le temps de correction à presque zéro.

Remplacement par lots et modèles structurés à l’aide d’expressions régulières

Lors de la migration d’articles existants vers Markdown ou de l’importation de texte depuis l’extérieur, le remplacement par lots avec des expressions régulières est très pratique.

Par exemple, l’expression régulière pour convertir la balise HTML gras en Markdown **gras** :

Modèle de recherche : (.*?)
Modèle de remplacement : **$1**

Pour regrouper les sauts de ligne consécutifs inutiles en un seul :

Modèle de recherche : \n{3,}
Modèle de remplacement : \n\n

En exécutant ces commandes via la fonction de recherche et de remplacement de VS Code (en mode expression régulière) ou la commande %s de Neovim (:%s/$.*?$<\/b>/**\1**/g), vous pouvez unifier le formatage en un instant.

Vérification automatique par pipeline CI/CD

De plus, en utilisant GitHub Actions, nous pouvons construire un pipeline CI qui exécute automatiquement textlint lors du push d’un article de blog. Cela permet d’empêcher à l’avance le déploiement d’articles violant les règles.

flowchart TD
A["Auteur"] -->|Pousser les modifications| B["Dépôt GitHub"]
B --> C{"Déclenchement des actions GitHub"}
C --> D["Cloner le dépôt"]
D --> E["Configurer Node.js"]
E --> F["npm install"]
F --> G["Exécuter textlint"]
G -->|Succès| H["Construire le site Hugo"]
G -->|Échec| I["Signaler l'erreur sur la PR/Commit"]
H --> J["Déployer sur l'hébergement (Vercel/Netlify)"]

5. L’art d’écrire en Markdown à l’ère des LLM

Dans la rédaction de blogs techniques modernes, l’utilisation de LLM (Large Language Models) est incontournable. En exploitant les outils d’IA intégrés à l’éditeur, la vitesse de rédaction peut être encore doublée.

Ingénierie des prompts (Prompt Engineering) dans l’éditeur

En utilisant GitHub Copilot Chat dans VS Code, ou ChatGPT.nvim et Copilot.vim dans Neovim, vous pouvez lancer des prompts comme celui-ci sans quitter votre éditeur :

“Crée un plan structuré en Markdown pour les débutants concernant les technologies suivantes : Docker, Kubernetes, CI/CD”

Immédiatement, une structure Markdown avec des titres et des puces sera générée. Il ne nous reste plus qu’à étoffer cette structure.

De plus, pour la rédaction de diagrammes Mermaid complexes ou de formules mathématiques (LaTeX), donner des instructions à l’IA permet de générer une syntaxe précise. Par exemple, la base de la mise en page des formules et diagrammes de cet article a également été accélérée grâce au pair-writing avec un LLM.

6. Conclusion

Nous avons expliqué les paramètres d’éditeur qui permettent de doubler la vitesse d’écriture lors de la rédaction d’un blog technique en Markdown.

Prise de conscience du modèle mathématique : Éliminer les tâches répétitives pour maximiser $T_{saved}$.
Utilisation de VS Code : Gagner du temps de saisie avec les extensions et les snippets de markdown.json.
Personnalisation extrême de Neovim : Snippets dynamiques avec LuaSnip et utilisation exclusive du clavier.
textlint et analyse statique : Intégration d’un Linter local et du CI/CD pour réduire le temps de correction à presque zéro.
Intégration des LLM : Laisser l’IA générer la structure Markdown et le code des diagrammes directement dans l’éditeur.

En intégrant ces paramètres à votre propre environnement, la “corvée” de l’écriture disparaîtra, et le volume ainsi que la qualité de votre production technique s’amélioreront de manière spectaculaire. Pourquoi ne pas commencer par enregistrer un simple petit snippet dès aujourd’hui ?