Ce petit chapitre va vous présenter brièvement le principe des générateurs de sites statiques, ainsi que leurs avantages et inconvénients. Dans un second temps, nous verrons pourquoi j’ai fait le choix de vous parler de Pelican plutôt qu’un autre, tout en restant ouvert à la "concurrence"
.
Sommaire
Un générateur de site statique, qu’est ce que c’est ?
Commençons par le début, qu’est ce qu’un site internet statique ?
S’il y a des sites statiques, c’est qu’il y en a sûrement des dynamiques
.
Rapide explication
Les sites que l’on pourrait qualifier de "dynamique" se basent sur l’utilisation d’un logiciel sur un serveur qui va générer les pages à chaque requête. Autrement dit, à chaque fois que vous allez demander une page au site en question, votre requête sera analysée, traitée, puis une page spécifique sera construite juste pour vous et vous sera envoyée. Si Bob et Alice demandent la page A, ils auront peut-être une page différente chacun.
Un site statique ne bénéficie pas de cela. Toutes les pages sont avant tout pré-générées grâce à un générateur. On obtient alors une collection de pages HTML. Ce sont ces dernières qui seront alors directement envoyées au lecteur, sans avoir d’autres traitements entre temps. Si Bob et Alice demandent la page A, ils obtiendront tous les deux exactement la même.
Pourquoi ?
Une question vous vient peut-être à l’esprit :
Pourquoi faire des sites statiques, si le contenu est gravé dans le marbre et qu’on ne peut pas interagir avec ?
Et bien pour plusieurs raisons. Tout d’abord, effectivement cela peut sembler un peu triste, un site qui ne change pas. Mais en y réfléchissant, il existe plein de cas d’usage. Le plus fréquent est sûrement le format blog. L’auteur publie des articles, qui vont créer un ensemble de pages qui fera un site internet. Un lecteur d’un blog de son côté se contente juste de lire les articles, il n’y a pas plus d’interactions que cela (oublions les cas des commentaires et/ou liens sociaux, qui sont gérables aussi sur des sites statiques). On peut aussi imaginer le cas d’une photothèque. Je veux partager mes photos de vacances à ma famille, pas besoin d’avoir plus d’interactions que ça pour eux, juste de quoi naviguer entre les pages.
Et tout cela a un énorme avantage : la vitesse .
En effet, puisque toutes les pages sont pré-générées, le serveur n’a rien d’autre à faire que de les envoyer. Aucun travail de traitement n’est effectué. Si Bob demande la page A, le serveur ne se pose pas de question et renvoie la page A.html. C’est tout. C’est rapide. Et ce genre de mécanisme peut être encore plus rapide grâce à la mise en place de cache qui sera très efficace car les ressources ne changent que très peu.
Un autre atout : La maintenance . Une fois votre site en ligne, rien d’autre à faire si ce n’est de le faire vivre en ajoutant de nouveaux articles / nouvelles pages de temps en temps. Pas de base de données à gérer, peu de risque de sécurité, voire même pas de serveur tout court à gérer si vous optez pour une offre d’hébergement mutualisée (nous y reviendrons).
Enfin, c’est facile !! Pas besoin de compétences de développeur pour faire tout cela, juste un peu de bidouille pour savoir utiliser le générateur. Ensuite, soit vous utilisez un thème pré-existant, soit vous vous faites le vôtre si vous maîtrisez un peu HTML/CSS.
Tous ces atout permettent ainsi aux créateurs de contenu de se focaliser sur la création de nouveaux articles plutôt que du développement technique et de la maintenance chronophage.
C’est ce qui m’a fait craquer pour cette technologie pour mon blog,
eskimon.fr
.
Pourquoi utiliser pelican ?
Pourquoi Pelican et pas un autre ? C’est une question légitime, à laquelle je vais essayer de répondre du mieux possible. Bien entendu, tout les goûts et les couleurs sont dans la nature. Bien que je vais essayer de rester le plus impartial possible, certains aspects seront propres à mes préférences pour certains langages et à mon historique en tant que développeur…
Parce que python
Python est un langage que j’aime beaucoup. Du coup lors de mes premiers pas avec les générateurs de sites statiques, c’est évidemment vers cet écosystème que je me suis tourné.
Plus objectivement, python a l’avantage d’avoir une communauté très importante. C’est un langage qui fait maintenant partie des leaders du marché et qui bénéficie d’une très grande communauté. Il est donc souvent très facile d’avoir des réponses à ses questions rapidement via une simple recherche internet ou en posant sa question sur des forums comme ceux de Zeste de Savoir.
L’avantage d’une grande communauté est aussi de pouvoir trouver de (très) nombreux exemples de code pour pouvoir s’inspirer et progresser. De la même façon, de nombreux plugins pour tout les systèmes existent bien souvent, faisant ainsi gagner du temps plutôt que de réinventer la roue. Et si ces derniers fonctionnent mal ou sont incomplets, il sera bien souvent possible de proposer des corrections ou améliorations à l’auteur initial si le code est open-source.
Parce que Pelican lui-même !
Pelican tire selon moi son épingle du jeu pour plusieurs aspects.
Tout d’abord, ce n’est pas un projet à l’abandon. À l’heure d’écriture de ces lignes, les derniers commits dataient de moins d’un mois ! Les commits les plus vieux ont quant à eux plusieurs années derrière eux. C’est plutôt une bonne chose, le projet semble mûr.
Autre aspect, c’est open-source. C’est toujours cool de pouvoir aller lire les sources quand on a une incompréhension ou par simple curiosité.
Après lecture de la documentation, la rédaction m’a semblé simple et intuitive (notamment pour la rédaction des métadonnées des articles). Le support natif du markdown a été pour moi un gros plus étant très familier avec de langage de rédaction.
Enfin, de manière plus pragmatique, Pelican est facile à customiser (j’en parle dans ce billet ) et surtout le rendu est simple à customiser. En effet, le moteur de template utilisé est jinja2, qui ressemble fortement à celui de base de Django et est bien connu dans le monde python (et donc offre de nombreuses réponses à toutes les questions que l’on peut se poser). Ayant pas mal utilisé ce dernier durant mes développements sur ZdS, je suis bien content d’avoir affaire à quelque chose de familier.
D’autres générateurs de sites statiques
Ne soyons pas sectaires, voyons quelles autres solutions existent, que ce soit en python ou dans d’autres langages. Ce chapitre sera rédigé grâce notamment au site staticgen qui liste les différents générateurs de site statiques open-source existant. Il est toujours bon de voir un peu plus loin que le bout de son nez. Savoir ce qu’offre chez la "concurrence" ne fait donc pas de mal, qui sait, peut-être un jour vous vous inspirerez d’une fonctionnalité existante chez un autre pour la porter sur Pelican !
Par souci de concision, je ne serai bien entendu pas exhaustif concernant tous les outils existants. Je ne ferai donc qu’une brève présentation de ceux dont j’ai le plus entendu parler ou même testé au moment de l’écriture de ce tutoriel.
En Python
Au moment d’écriture de ces lignes, le service staticgen liste un peu plus de 25 outils en python. Je vais couper sévèrement dans la liste pour vous en présenter deux, Sphinx et Lektor.
En python il existe un générateur que vous connaissez sûrement si vous lisez des documentations techniques d’outils open-source : Sphinx . En effet, sphinx est utilisé par exemple pour le site de la documentation officielle du langage python. Un autre grand acteur de la documentation open-source, ReadTheDocs, utilise aussi Sphinx pour la génération de ses contenus. Sphinx est donc un grand acteur du monde python.
Un autre outil populaire méritant d’être cité est Lektor . Je le trouve cependant un peu plus compliqué d’utilisation et de paramètrage, c’est notamment pourquoi je préfère vous présenter Pelican dans ce tutoriel. En revanche, Lektor propose un petit serveur web local permettant d’offrir un petit gestionnaire de contenu à la volée et une interface de rédaction qui est un petit plus plutôt sympa.
En javascript
En rédigeant cette section, j’ai découvert Hexo . Je ne connaissais pas avant, mais quand on voit le premier argument "générer des dizaines de pages en une seconde" forcément ça fait rêver. Cet outil utilise du Node.js, qui devient un grand classique du monde javascript. Comme partout, la rédaction se fait en markdown et la génération des pages se fait en une commande. Je ne peux pas en dire beaucoup plus, ne connaissant pas vraiment l’outil.
Un autre outil (plus connu ?) est GitBook . Il est assez connu des personnes voulant rédiger des ouvrages techniques je pense et possède notamment une interface de rédaction et publication en ligne. L’idée derrière ce générateur est de rapprocher le monde de l’édition conventionnel papier au monde de l’édition numérique, notamment en proposant par défaut une publication au format pdf. Les ouvrages sont versionnés via le compte de l’auteur sur GitHub.
D’autres langages, Go et Ruby
Tout comme pour Hexo, j’ai découvert
Hugo
lors de la rédaction et donc ne vous le présenterais que pour le principe. Hugo est codé en Go, langage édité par Google et se voulant très efficace. Ce qui fait que là encore, on retrouve la vitesse de génération comme argument principal d’Hugo. Si vous êtes familier avec le Go, allez donc y jeter un œil
En dernier lieu, je souhaiterais vous présenter Jekyll non pas parce que je suis fan de ruby (je n’en ai jamais touché), mais surtout car il fait figure d’étoile montante des générateurs de site statique. En effet, Jekyll est embarqué comme outil de rédaction par plusieurs grands services d’hébergements de pages web statiques, comme Github ou Netlify.
J’espère que les choses sont maintenant clairs sur les tenants et aboutissants des différentes technologies. Bien entendu, aucune solution n’est parfaite, mais vous avez maintenant des moyens de comparaison.
La prochaine partie va nous amener doucement vers la pratique en voyant comment installer Pelican.
