Comme vous pouvez le voir dans le bas de page de mon site, j'utilise Pelican pour générer ce blog depuis presque 4 ans.
Avant ma migration sous Pelican, j'utilisais le moteur de blog/CMS Dotclear pour sa simplicité, sa légèreté et ses possibilités mais son developpement est fortement ralenti, et demande un serveur exécutant PHP et une base de données MySQL. En cas de problème sur le serveur ou de démenagement, il faut tout sauvegarder puis tout réinstaller (même si l'installation est facilitée par un installateur pas à pas) puis réimporter tous les articles et images.
Je voulais changer de moteur de blog pour passer sur un CMS "flat file" basée sur de simples fichiers textes que je pouvais éditer de n'importe où (par exemple, depuis mon smartphone) et qui alimenteraient mon site, qui soit léger et facilement transportable. J'ai donc choisi Pelican car je suis familier avec Python, mais cela aurait pu être Hugo ou Jekyll.
Dans cette article, je vous présente donc comment je gère la création et publication de mes articles de blog avec une stack simple mais efficace basée sur Pelican.
Pelican : le générateur de sites statiques
Pelican est un générateur de sites statiques écrit en Python qui transforme des fichiers Markdown (ou reStructuredText) en site web complet. Contrairement aux CMS dynamiques comme WordPress ou Dotclear, un blog statique présente plusieurs avantages majeurs :
- Performance : pas de base de données à interroger, pas de PHP à exécuter. Le serveur web sert directement les fichiers HTML/CSS/JS, ce qui garantit des temps de chargement optimaux.
- Sécurité : surface d'attaque minimale. Pas de plugins vulnérables, pas d'injections SQL possibles, pas de backdoors dans du code dynamique.
- Simplicité de maintenance : pas de mises à jour de CMS, pas de plugins à maintenir. Le serveur web suffit.
- Portabilité : les fichiers statiques peuvent être hébergés n'importe où. Un simple espace d'hébergement livré avec un nom de domaine suffit.
Structure du projet
Sur mon PC local, mon projet blog utilise la structure standard générée par pelican-quickstart lors de son inialisation :
blog.mathdatech.fr/
├── content/ # Articles en Markdown
├── output/ # Site généré (HTML/CSS/JS)
├── pelicanconf.py # Configuration développement
├── publishconf.py # Configuration production
└── Makefile # Commandes de génération
Tous mes articles sont dans le dossier content/, organisés avec les métadonnées Pelican en en-tête de chaque fichier Markdown. Ce dossier contient aussi des sous-dossiers pour les fichiers statiques associés (images, pages statiques et autres fichiers).
L'architecture générale
Mon setup repose sur une séparation claire entre création locale et hébergement distant :

Local (PC de bureau) :
- Logiciel de rédaction : un éditeur Markdown (ReText, Marker, ...) ou une base de connaissance (Logseq, Zettlr, ...) ou un simple éditeur de texte
- Génération de site : Pelican (Python)
- Logiciel d'Upload : FileZilla (SFTP)
Distant (VPS Debian 12 + YunoHost) :
Double sauvegarde des articles
J'utilise deux méthodes complémentaires pour sauvegarder mes articles via des applications installées sur mon VPS :
- Forgejo : pour versionner mes articles et la config Pelican
- Nextcloud : pour synchroniser mes articles Markdown entre tous mes périphériques (PC, smartphone, tablette)
1. Synchronisation automatique via Nextcloud
Le dossier content/ est synchronisé automatiquement avec mon instance Nextcloud via Nextcloud Desktop Sync. Cette approche offre :
- une Synchronisation automatique et en temps réel qui permet une sauvegarde continue sans intervention manuelle : dès qu'un fichier est modifié, il est uploadé, cela procure une protection contre la perte de données
- un Accès multi-périphériques : je peux rédiger des articles depuis mon PC de bureau ou depuis n'importe quel appareil ayant accès à mon Nextcloud.
2. Versioning via Git/Forgejo
En parallèle, je commite manuellement l'ensemble du projet (articles + configuration Pelican) sur mon instance Forgejo :
- Historique complet : chaque modification est trackée avec des messages de commit explicites
- Rollback : retour facile à une version précédente en cas de problème
- Sauvegarde structurée : commits organisés par fonctionnalité/article
Cette double approche me donne le meilleur des deux mondes : la praticité de Nextcloud pour l'accès nomade et la rigueur de Git pour le versioning.
Le workflow de création
1. Rédaction des articles
Je rédige directement en Markdown avec mon éditeur de texte (ReText en ce moment). Pas de WYSIWYG, pas de complexité inutile. Le Markdown me donne :
- Un contrôle précis de la mise en forme
- Une syntaxe légère et lisible
- Une portabilité totale des contenus

Je peux controler la mise en forme du texte directement dans l'éditeur de texte, s'il prend en charge la pré-visualisation du markdown, ou avec Pelican qui peut générer le site avec un serveur de développement avec la commande make devserver et qui permet donc d'avoir une prévisualisation du blog à chaque modification.
2. Génération et publication avec Pelican
Une fois l'article rédigé, je génère le site avec la commande make publish. Cette commande exécute Pelican avec la configuration de production (publishconf.py) qui :
- Parse tous les fichiers Markdown du dossier
content/
- Applique le thème et les templates Jinja2
- Génère les pages HTML, le flux RSS, les index par catégorie/tag
- Optimise les assets (CSS, JS) selon la configuration
- Place tout dans le répertoire
output/
3. Upload SFTP avec FileZilla
Une fois le site généré dans output/, je synchronise ce dossier vers le serveur via SFTP avec FileZilla. Le processus :
- Connexion SFTP à l'espace My Webapp de YunoHost sur le VPS avec les credentials
- Navigation vers le répertoire web du blog (
/www/)
- Synchronisation : FileZilla compare les fichiers locaux et distants
- Upload sélectif : seuls les fichiers modifiés/nouveaux sont transférés
- Vérification des permissions et de l'intégrité
FileZilla affiche clairement les différences, me permettant de contrôler exactement ce qui est publié.
Pourquoi cette stack ?
Les avantages sont :
- Contrôle total : je maîtrise chaque étape
- Performance : site statique = temps de chargement minimal
- Sécurité : pas de CMS à maintenir/patcher
- Backup simple : tout est en fichiers, facile à versionner
- Offline : je peux rédiger sans connexion
Les inconvénients sont :
- Pas de commentaires natifs (nécessite un service externe)
- Processus manuel pour la publication et la sauvegarde
- Courbe d'apprentissage pour les non-techniques
Conclusion
Cette stack évolue progressivement d'un processus manuel vers une approche plus automatisée. La base reste solide : Markdown pour la rédaction, Pelican pour la génération, double sauvegarde Nextcloud/Git.
Des améliorations du workflow sont prévues pour passer de 3 étapes manuelles à 1 seule commande make deploy via de nouvelles fonctions dans le Makefile :
- Upload SFTP automatisé avec
lftp (fonction native de pelican-quickstart)
- Commits Git automatisés vers Forgejo
- Fonction globale
deploy orchestrant "génération -> upload -> versioning"
Ce qui permettra d'éliminer les tâches répétitives tout en conservant le contrôle et la simplicité qui font l'attrait de cette solution.