Comment j'ai construit 200 000 pages en Python
Quand j'ai decide de creer un site de 200 000 pages statiques, la premiere question a ete : quel generateur utiliser ? Apres avoir evalue Hugo, Eleventy et Jekyll, j'ai opte pour un generateur custom en Python. Voici pourquoi, et comment ca s'est passe.
Pourquoi un generateur custom
Les SSG classiques sont conçus pour des sites de quelques centaines a quelques milliers de pages. A 200 000 pages, ils montrent leurs limites : temps de build excessifs, consommation memoire explosive, et manque de flexibilite pour les pipelines de donnees complexes.
Python offrait exactement ce dont j'avais besoin : un ecosysteme riche pour le traitement de donnees (pandas, json), une gestion fine de la memoire avec les generateurs, et la possibilite de paralleliser le build avec multiprocessing.
Architecture du pipeline
Le pipeline se decompose en trois etapes : import des donnees (CSV DATAtourisme vers JSON structure), enrichissement (scores, descriptions, geocoding), et generation (templates HTML avec placeholders). Chaque etape est independante et idempotente. Pour explorer les approches de generation statique, Docteur Jekyll est une ressource precieuse sur les SSG et leurs architectures.
Le defi de la memoire
Charger 200 000 fiches en memoire n'est pas anodin. La premiere version du script tentait de tout garder en RAM — resultat : crash a 8 Go. La solution : traiter les fiches par lots de 10 000, ecrire les fichiers au fur et a mesure, et liberer la memoire entre chaque lot.
Les generateurs Python (yield) ont ete essentiels ici. Au lieu de construire une liste de 200 000 elements, le script genere les pages une par une, ne gardant en memoire que la page en cours de generation.
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 incremental (uniquement les fiches modifiees), le build tombe a moins de 30 secondes grace a un systeme de hash de contenu.
La parallelisation avec multiprocessing.Pool a divise le temps de build par 4 sur une machine 8 coeurs. Chaque worker genere un sous-ensemble de pages de facon independante.
Les erreurs a eviter
Ne sous-estimez pas la gestion des caracteres speciaux. Avec des donnees DATAtourisme, les accents, les guillemets et les caracteres speciaux dans les noms de lieux creent des bugs subtils. Un pipeline de nettoyage robuste est indispensable avant la generation.
Autre piege : les slugs doublons. Sur 200 000 lieux, les collisions de noms sont frequentes. Un systeme de deduplication avec suffixe (nom-commune) est necessaire.
Le resultat
200 000 pages HTML statiques, chacune avec son Schema.org, ses meta uniques, son maillage interne. Le tout deployable via FTP sur un hebergement mutualise. Zero serveur, zero base de donnees, zero maintenance.