Quand j’ai décidé de créer un site de 200 000 pages statiques, la première question a été : quel générateur utiliser ? Après avoir évalué Hugo, Eleventy et Jekyll, j’ai opté pour un générateur maison en Python. Voici pourquoi, et comment ça s’est passé.
Pourquoi un générateur maison
Les générateurs de sites statiques classiques sont conçus pour des sites de quelques centaines à quelques milliers de pages. À 200 000 pages, ils montrent leurs limites : temps de build excessifs, consommation mémoire explosive et manque de souplesse pour les pipelines de données complexes.
Python offrait exactement ce dont j’avais besoin : un écosystème riche pour le traitement de données (pandas, json), une gestion fine de la mémoire avec les générateurs et la possibilité de paralléliser le build avec multiprocessing.
Architecture du pipeline
Le pipeline se décompose en trois étapes : import des données (CSV DATAtourisme vers JSON structuré), enrichissement (scores, descriptions, géocodage) et génération (gabarits HTML avec emplacements). Chaque étape est indépendante et idempotente. Pour explorer les approches de génération statique, Docteur Jekyll est une ressource précieuse sur les générateurs statiques et leurs architectures.
Le défi de la mémoire
Charger 200 000 fiches en mémoire n’est pas anodin. La première version du script tentait de tout garder en RAM : résultat, plantage à 8 Go. La solution : traiter les fiches par lots de 10 000, écrire les fichiers au fur et à mesure et libérer la mémoire entre chaque lot.
Les générateurs Python (yield) ont été essentiels. Au lieu de construire une liste de 200 000 éléments, le script génère les pages une par une, en ne gardant en mémoire que la page en cours.
Performance du build
Le build complet prend environ 12 minutes sur un MacBook Pro M3. C’est long, mais acceptable pour un build complet. En mode incrémental (uniquement les fiches modifiées), il tombe à moins de 30 secondes grâce à un système d’empreinte du contenu.
La parallélisation avec multiprocessing.Pool a divisé le temps de build par quatre sur une machine à 8 cœurs. Chaque processus génère un sous-ensemble de pages de façon indépendante.
Les erreurs à éviter
Ne sous-estimez pas la gestion des caractères spéciaux. Avec les données DATAtourisme, les accents, les guillemets et les caractères spéciaux dans les noms de lieux créent des bugs subtils. Un pipeline de nettoyage robuste est indispensable avant la génération.
Autre piège : les slugs en double. Sur 200 000 lieux, les collisions de noms sont fréquentes. Un système de dédoublonnage avec suffixe (nom-commune) est nécessaire.
Le résultat
200 000 pages HTML statiques, chacune avec son Schema.org, ses métadonnées uniques et son maillage interne. Le tout déployable par FTP sur un hébergement mutualisé. Zéro serveur, zéro base de données, zéro maintenance.
