Je vais enfin tirer un premier bilan sur les GSS, qui vaudra ce qu’il vaudra et qui sera tiré de mon expérience avec Jekyll, Pelican et Hugo.

J’ai toujours un peu d’amertume de ne pas avoir pu/su rester sur Pelican, il est vraiment bien mais je le trouve un peu archaïque/compliqué face aux deux autres, que ce soit au niveau des commandes de base –comme lancer son serveur de dev, lancer la fabrication du site…–. Sur ce dernier il faut souvent taper des commandes à rallonge comme pelican content -s publishconf.py alors que pour les deux autres, il suffit de les appeler jekyll ou hugo. C’est surtout des manques dans le markdown utilisé avec Pelican comme les parties de textes barrés comme ici ou d’autres codes à intégrer qui m’ont poussé à ne pas l’utiliser.

Donc celui-ci je vais le mettre de coté et simplement ne pas en parler. Pour Hugo, je suis de nouveau dessus, bien que j’ai commencé avec lui, j’ai toute de suite vu qu’il était complet et rapide mais pas possible d’ajouter des fonctions avec des plugins contrairement aux deux autres. En même temps il est vraiment complet et permet dès le départ de faire bien plus que ce qu’on peut faire par défaut avec Jekyll. J’ai voulu donc après plusieurs mois filer sur un truc plus simple comme Jekyll, là ce fut bien tranquille pendant deux ans.

J’avais ce que je voulais, un markdown complet, le strict nécessaire pour faire mon blog, une légèreté à toute épreuve… Bref, tranquille aussi question sécurité, oui c’est un truc qu’on parle peu ou pas, mais les CMS classiques style Wordpress pour ne parler que du plus utilisé, sont troués de failles et sont visés par tous les pirates pour être exploiter. Et ils sont tous ainsi, que ce soit les plus complets comme Drupal ou les plus simplistes comme PlumXml, c’est la même chose.

C’est bien beau l’interface d’un CMS pour faire son article, mais honnêtement on en devient tributaire et on sera jamais aussi bien à l’aise que sur son outil –ici un éditeur seulement– adoré. Non et puis la lourdeur de certaines interfaces, celle de Wordpress par exemple, c’est un truc qui m’agaçait.

Donc deux ans que je blog via un GSS, dans un éditeur voir plusieurs comme Kate/Kwrite, Gedit, Remarkable, Ghostwriter,…, et j’en passe. Les points forts sont nombreux et c’est facile d’aller en trouver sur le Web, plusieurs sites en parlent –suffit juste de rechercher site static jekyll pelican ou hugo pour s’en convaincre–, je dirais même que chaque gars qui passe ce cap –le passage d’un GMS vers un GSS– fait un billet pour parler de son vécu. Principalement, la vitesse et la légèreté du site, la simplicité de la “fabrication” du site, la sécurité du site… Je reprendrais juste un petit passage de ce billet:

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.

Je pense que c’est clair.

De mon coté, c’est surtout l’interface lourde de Wordpress et la sécurité qui m’ont poussé vers ce changement, quand on voit le nombre d’attaques par mois sur son site ça fait froid dans le dos…

Bref, je ne m’y connais pas en sécurité de site, alors la chose la moins conne à faire était de choisir un truc qui de base ne pouvait pas ou peu se faire hacker. J’en avais marre aussi de me taper des sauvegardes de bases de données ou des sauvegardes de sites. Maintenant que je suis avec un GSS, je travail sur mon PC et je pousse le résultat sur le serveur. Du reste, une simple clef USB fait office de sauvegarde, je travail en effet sur mon PC mais j’ai une sauvegarde de la totalité sur une clef, en cas ou. Ce qui supprime un des points noir des GSS, contrairement aux GMS qui sont utilisables de partout car la partie admin est accessible via le net –une cause de la facilité des piratages–, les GSS ne sont pas accessibles car la partie contruction est un dossier dans notre PC et donc pour y accéder, il faut que l’hôte ait d’installé le GSS en question et ait accès à distance à notre dossier ou qu’on ait une clef.

L’autre point intéressant, c’est qu’on n’ait même plus besoin d’un serveur classique pour faire tourner notre site, on peut très bien le faire tourner depuis son Github ou Gitlab comme c’est le cas avec le mien (c’est un test). Dans mon cas je suis attaché à un serveur web classique et je remercie Tuxfamily.

On en vient aux points négatifs, c’est du statique, donc tout ce qui est dynamique est banni ou sinon faut ruser en mettant du code dans nos pages. C’est principalement chiant pour un blog à cause des commentaires, heureusement qu’il y ait des solutions même beaucoup et de tout horizon, comme la solution propriétaire Disqus un temps utilisé ici, ou d’autres libres comme Staticman. De mon coté, je me suis penché sur NoNonsense Forum, qui est un forum en PHP sans base de données comme peut l’être PlumXml pour le site web.

Voila, dans l’idée ce que sont les avantages et les contraintes d’un GSS, maintenant, parlons de son utilisation. Je ne suis pas un hacker loin de là, je ne suis donc pas un informaticien de renom, je me débrouille et j’apprends sur le tas –ce qui pour moi, a toujours été le cas, que ce soit l’informatique dans son ensemble ou le bricolage, …–, donc si j’utilise ce genre de moteur pour faire mon site c’est que ce n’est pas si compliqué de le faire et que je gagne dans l’histoire.

En gros, l’utilisation quotidienne se résume à hugo serve pour voir en direct les changements effectués sur le site, ça va compiler et lancer un mini serveur de développement accessible localement. Une fois que j’approuve, que ce soit l’ajout d’un billet ou le changement du thème, je fais un hugo qui va compiler l’ensemble –on parle de millièmes de secondes pour 400 billets, Hugo étant le plus rapide des GSS–. Ensuite je balance le résultat qui se retrouve dans un dossier public de mon dossier hugo vers le serveur du site via rsync plus exactement rsync -e ssh -avz public/ XXXXXX@ssh.mondomaine.org:/racine/projet/adresse-de-mon-site.org-dossier/sous-dossier. Ça c’est pour la partie technique, pour écrire son billet, du markdown dans un simple éditeur comme dit plus haut fera l’affaire, rien de plus. En parlant de markdown, je ne trouve rien de mieux depuis que j’utilise ce langage, allez voir par ici pour vous en convaincre.

Le truc avec les GSS, c’est que depuis que je tourne avec ce genre de moteurs pour mon blog, je peux passer plus de temps sans “surveiller” ce qui s’y passe notamment et surtout question sécurité. J’aurai beaucoup de mal à retourner sur un CMS, pourtant j’ai voulu retourner pour voir ce que ça donnait mais non.

Bon j’espère vous avoir donné l’envie –d’au moins– tester ce genre de moteur.