Réflexion - Hébergement ou gamberge ?
Cela fait plus d’un an que j’ai entamé une réflexion sur le support du blog. Wordpress est très bien et pratique mais de plus en plus lourd à gérer à force de vouloir tout faire (sans parler des incohérences créées par l’application mobile). Entre auto-hébergement, hébergement ou sous-traitance complète, j’ai tout fait et pourtant mon coeur balance toujours. Ca va être un peu technique…
Le matériel m’a pas mal forcé à changer la façon de “produire” des articles. Maintenant je le fais complètement en mode texte brut / markdown et je les partage sur un espace à moi tant que ce n’est pas finalisé. Je ne compte jamais les versions mais elles sont nombreuses. Au premier abord, on peut penser que c’est moins pratique par rapport à l’interface wordpress, mais c’est en fait bien plus efficace. Wordpress, c’est sympa mais lorsque j’ai repris l’ensemble des articles, j’ai retrouvé au moins 4 types de codage et c’est bordélique. Si j’ai arrêté de gérer moi même un site wordpress (il y en avait une copie jusqu’en Juillet hébergé ailleurs), c’est justement pour ne plus être ennuyé avec les versions, les évolutions de plugins qui créent des failles, des incohérences, le avec ou sans jetpack, etc. Un choix qui se “paye” par des incursions publicitaires et des cookies de stats, etc…Et puis, malgré un travail sur la forme pour alléger au maximum, le site est encore un peu trop lent à mon goût dans mon optique de rendre le web (le mien :p) rapide à nouveau. Je me tape en plus des googlefonts et un tas de trucs que je voudrais virer (javascripts notamment). J’ai testé aussi la lecture avec des navigateurs en mode minimal, en texte et on a de grosses surprises. Dans les zones où la 3G est minimaliste, c’est une bouée bien utile. Bosser sur du texte brut rentre donc dans cette logique, bien loin des blocs qui ne remplacent pas un bon vieux copier-coller si rapide avec quelques raccourcis clavier. En vieillissant, je travaille de plus en plus à “l’ancienne”, avec des outils simples et efficaces et finalement plus productifs.
Ce souci de revenir aux basiques s’est d’abord traduit en 2020 par la mise en place d’une github page avec donc un template très léger, des fichiers markdown qui correspondent à chaque article et qui permettent la “reconstruction” du site à chaque ajout ou mise à jour. Le problème vient que ça se base sur Jekyll qui utilise ruby comme langage, avec un peu de liquid sur les pages en plus du markdown. Ruby est lourd à installer et on se retrouve à être prisonnier de ce langage, de ses évolutions, etc. Sur windows, j’ai trouvé ça encore pire à installer mais finalement j’ai contourné l’obstacle en attaquant directement github…et en oubliant windows. Sur debian, je m’en suis démerdé avec la vieille debian de l’époque mais c’était long sur ma vieille machine à reconstruire le site (Environ 5 minutes pour 1400 pages !). Si bien que j’ai tapé directement dans l’interface web de github pour mettre toutes les pages. 1400 articles (j’ai fait du ménage, j’en suis à 1700 sur Wordpress.com) à refaire, avec quelques automatisations mais au moins un code à peu près homogène, durant l’été 2020. Si je passe à autre chose, le markdown a l’avantage d’être reconnu partout ou presque, au détail de l’en-tête jekyll en yaml (encore une autre syntaxe!). Mais donc je ne veux pas être prisonnier d’un langage, de cette plateforme et j’ai imaginé autre chose : N’avoir que des fichier markdown .md à mettre en ligne. Mais cela n’est pas raisonnable pour plusieurs raisons.
Un site statique, puisqu’il faut appeler un chat un chat, c’est un ensemble de pages html, une feuille de style, et une structure de fichier qui va avec. On ne peut se contenter de mettre des pages textes en .html, car il faut quand même du lien hypertexte entre tout ça et une mise à jour petit à petit, au fil des ajouts (au moins 5 à chaque fois si je prends archive, page de la catégorie, sitemap, feed RSS, index… plus l’article). Pour passer des articles au site, il faut un générateur de site qui peut être local ou sur un serveur. Lorsque c’est sur un serveur, c’est considéré comme un site statique hybride, car s’il n’y a pas de base de données, il y a tout de même un langage, une interface genre “CMS”. L’exemple que je connais c’est PluXML que j’ai utilisé un an avant de revenir sur wordpress. Mon problème avec ça reste la dépendance à un développeur, les failles de sécurité pour accéder au CMS (idem wordpress), les mises à jour qui parfois mettent le bordel dans les plugins. Cyrille a laissé aussi tomber pour quelques unes de ces raisons. En plus si c’est du php derriere, ca veut dire aussi bonne version de php. Sans plugins, vous me direz, ça peut le faire. Mais les templates ne sont pas des plus clairs pour moi, encore que depuis j’ai progressé. Dans le même genre, on a yellow ou même media wiki. Si je fais du local, le problème (comme pour Jekyll), c’est le langage derrière. Le Ruby, le Go (Hugo), le Vue, voire le javascript, ce n’est pas ma tasse de thé. Le python, ça pourrait se faire, car c’est devenu généralisé. Le problème est que derrière, on rustine aussi avec des ajouts via PIP (installeur de package python), et qu’il y a encore à gérer les évolutions des versions. Ca peut se faire et se gérer. Pelican aussi c’est du python mais là encore ça devient trop pour moi. J’ai l’impression de ne pas maîtriser ce qu’il se passe.
Donc j’ai trouvé une base simple (oui, je pars souvent du plus simple, ce qui explique pourquoi l’évolution de debian m’inquiète…on y reviendra une autre fois) que je comprends et peut faire évoluer : Makesite.py, développée par une indienne. Son idée a été reprise par bien d’autres, dérivée ou copiée avec inspiration. J’en suis arrivé à un autre développeur français qui tient un blog sur ce type de format (un peu différent) ainsi qu’une autre variante du même principe. Il a rajouté beaucoup de choses, dont une gestion des commentaires en statique via le mail. Ce qui rajoute aussi des dépendances mais c’est intéressant pour comprendre. Je ne ferai pas comme Stéphane Bortzmeyer avec sa solution très perso en XML, par contre, même si cela reste dans cet esprit… Il se trouve que l’ami F6K a parlé d’autres personnes qui sont aussi dans cette même optique ou ont des solutions à elles pour cela. Plusieurs cerveaux valent mieux qu’un, surtout quand ils sont mieux câblés pour ça que le mien. Nous avons exploré conjointement des solutions, des exemples et c’est toujours intéressant de confronter les points de vue.
Toute cette réflexion m’a fait aussi réévaluer les besoins, simplifier encore et encore. J’ai passé le site actuel (jekyll et wordpress) à la moulinette SEO pour comprendre aussi la mode actuelle, les oublis, les failles, sans pour autant céder à cela. D’une idée simple, on tombe vite dans le compliqué. Avec le temps, je me dis que les tags ne servent à rien d’autre qu’aux moteurs de recherche, que les commentaires, ça peut se faire autrement (disqus, mail, réponse par article de blog) et que les catégories, ça peut s’afficher dans des pages archives comme je l’avais fait avec mes scripts Liquid sur la version github. Ma démarche est extrême mais instructive pour moi. Alors j’en ai regardé des exemples. J’ai regardé les principaux moteurs de sites statiques et ça ne me plaisait pas car on s’enferme á nouveau dans autre chose. J’ai regardé d’autres blogs, imaginer des formes comme j’ai trouvé par exemple chez Karl Dubost. J’ai vu leurs difficultés, les écueils et continué à chercher mon Graal. J’ai testé 11ty, aussi mais si le système paraît ouvert, je trouve que Node.js reste un problème comme je l’ai évoqué plus haut. Ah oui, j’ai oublié de parler de Publii, de l’hybride offline…Un logiciel à installer ce qui rend encore plus prisonnier mais est orienté débutant. Pas vraiment pour moi.
Si la situation de ma github page est fiable et légère, c’est l’évolution de la plateforme qui m’inquiète (tout comme wordpress). Vu le propriétaire (Microsoft…), je peux imaginer le pire et d’ailleurs le pire arrive parfois à des développeurs ayant le malheur d’aller en Iran. D’où la recherche d’une porte de sortie, qui peut aussi être chez le concurrent Gitlab, Framagit en transition… Aujourd’hui, je suis capable de faire un article de n’importe quel terminal du moment que j’accède à un moment à un éditeur de texte qui sort de l’UTF-8. Pas de programmation d’article par contre comme du temps de wordpress. Il faut générer le site une fois l’article mis dans l’arborescence, ce qui sur mon pc ne prend que moins de 10 secondes, plus l’export en ftp/rsync. Mais tant que wordpress.com dure, je le conserve quand même. Wordpress peut transcrire le markdown en théorie mais j’ai remarqué que ça fonctionne une fois sur deux avec les bugs actuels de ce foutu gutenberg. On peut même lui envoyer un article directement par mail, là encore avec le mode draft/brouillon reconnu plus ou moins. Pas besoin non plus d’envisager d’autres formats ou navigateurs comme en parlait Ploum récemment. Je suis dans une sorte d’esprit KISS (pas le groupe! Keep It Simple, Stupid) pour le blog, au fond. Le Gemini me paraît lui même une mauvaise idée car on ajoute encore un protocole quand on pourrait faire plus simple en réunissant ce qui existe déjà : protocoles sécurisés, interprétation d’un langage balise comme markdown directement dans le navigateur, les idées ne manquent pas… Mais déjà savoir revenir aux choses simples. Lisez la FAQ de gemini, les justifications de leur choix sont bancales. Je rêverai que Mozilla soit prescripteur, mais bon, ils se refusent à aller même dans un plugin gemini, quand lex X navigateurs spécifiques développés sont indigents ou bugués. Là encore, c’est toute la gouvernance des standards du web qui pose question, aux mains des GAFAM. Autre débat.
Et puis il y a l’hébergement et l’adresse. Pas sur que icemanfr75.github.io (qui me sert maintenant de betatest) soit la meilleure adresse. Reprendre un nom de domaine pour le reste des temps, pourquoi pas? Je pourrais même orienter selon des sous domaines sur les deux versions. Ca ne me coûterait que moins de 10 euros par an, pour l’instant, mais pour quoi, au fond? Cette question ne cesse de me tarauder. Quel gain j’en tirerai puisque j’ai suffisamment de lecteurs à mon goût tel quel. L’hébergement moi même sur wordpress, pas envie d’y replonger non plus et le coût sera bien plus important (quoique ?). J’ai quand même regardé les hébergeurs fiables, mais les propositions techniques sont des plus opaques quand on rentre dans le détail. Déformation professionnelle, j’aime rentrer dans le détail pour comprendre le nombre d’adresse, les certificats ssl, le DNSSEC, le débit, les connexions simultanées, etc… Toutes ces occasions de vendre des options ou de ne pas permettre certains usages. Je pourrais en profiter pour faire mon nextcloud (ce qui n’est pas possible partout) et des tas d’autres choses mais franchement, je n’ai plus envie de m’ennuyer à ça à mon âge avec les cinglés qui peuplent le réseau aujourd’hui. Il suffirait qu’un billet ne plaise pas pour qu’on me flingue tout, non merci. Parano, vous croyez? J’en ai vu être ennuyés pour moins que cela. Donc mon besoin reste des plus simples, si je produis un site statique : Une adresse et un petit hébergement (le site fait dans les 24Mo sans les photos contre bien plus pour le Wordpress)
Comme en plus j’ai viré mes adresses free et pages qui vont avec, on oublie aussi la solution de l’hébergement gratos chez le FAI, puisqu’en plus ça ne suit pas bien sur les versions, la fiabilité. Voilà ce qui a donc occupé mon cerveau quelques temps et continue régulièrement. La solution, il n’y a finalement que moi pour la trouver car il y a beaucoup de choix. Avouons qu’aujourd’hui, il n’a jamais été aussi simple de faire un site à soi, de l’héberger. Mais il n’a jamais été aussi compliqué de faire simple. Faire simple pour qui d’ailleurs, puisque la plupart des utilisateurs sont habitués à avoir des “images qui bougent” dans un navigateur, sans vraiment comprendre ce qui se passe derrière. Quand je pense que j’ai débuté en tapant du HTML à la pogne et en créant les menus en frame, sans les feuilles de style. Autres temps… A croire que la simplicité se mérite et je me suis alors demandé finalement si je n’allais pas continuer comme maintenant et attendre d’avoir franchement le temps de me pencher sur les scripts python que j’ai vu, de savoir gérer ces p…..ns de librairies supplémentaires sur tous les OS. La clé me semble justement dans la conversion markdown avec plusieurs possibilités. Me demandez pas pourquoi, la liberté est trop compliquée. Trois exemples testés, trois convertisseurs différents. Faudrait voir à faire le ménage. Et toi lecteur, si je te demande ton avis, tu vas me répondre par…oups, des commentaires, bien sûr. Comme quoi c’est utile. Une chose est sûre, je ne recréerai plus jamais de forums, sauf si ce sont des animaux qui le fréquentent.
Et puis finalement, après quelques semaines, je me suis dit que cela serait bien d’avoir à nouveau son nom de domaine, parce que ce n’est pas très cher, pas trop prenant et que cette fois, je vais le garder ad vitam eternam, comme mon surnom. Je me suis dit aussi que je garde Jekyll parce que je le maîtrise de mieux en mieux en optimisant beaucoup “le template” pour l’adapter aux évolutions du web, l’épurer, le retravailler en profondeur pour minimiser la taille. Je me suis dit qu’il existait de petits hébergements pas cher, parfois avec les noms de domaine. Et enfin, que je ne voulais plus de stats, plus de commentaires à gérer, plus de modération, plus rien sinon ce que j’écris. Une révolution pour toi lecteur ? Entre le mail, le réseau social libre Mastodon et la possibilité de répondre sur ton blog, je suis convaincu que c’est suffisant. Je garderai les apports extérieurs (appelez ça … commentaires :p ) en éditant les fichiers, justement. Une sorte de wiki en quelque sorte.
Et enfin j’ai créé mon petit logo discret pour préciser qu’il n’y a plus rien que du bon vieux HTML bien simple et rapide, lisible partout, tout le temps, même en 3G. Je rode encore un peu le truc avant le lancement et un basculement que j’espère progressif si toi aussi lecteur tu veux du texte, du partage et pas des arbres de noël clignotant partout avec des scripts qu’on ne maîtrise plus. A suivre pour la partie plus technique de la mise en place.
ps : quand je vous dis que c’est compliqué dans ma tête…
Bande son : Zazie - J’envoie Valser
Commentaires :
@lord@pleroma.lord.re
(…) Concernant le générateur de site je te comprends à fond. Et c’est ce genre de réflexions qui m’ont poussé vers hugo. Certe c’est un générateur qui t’enferme dans sa technologie mais en fait pas tant que ça.
Déjà vu que c’est du go, ça a l’avantage de pouvoir se compiler vers un peu toutes les plateformes (ils fournissent leurs propres binaires). Le binaire se suffit à lui-même, pas de dépendances, rien à installer, un gros binaire statique autonome. Globalement la forme des articles (un entête puis l’article en markdown) est pas standardisée mais pas mal des générateurs statiques ont adoptés un format similaire. Le jour où je souhaiterai migrer de hugo vers un concurrent, il y a de fortes chances que ce soit compatible ou bien qu’un outil soit créé et au pire en scriptant un un ptit truc il devrait y avoir moyen d’adapter. La vitesse de génération même si c’est du bonus c’est quand même agréable (même si en vrai c’est la compression des images, des textes, la génération du blogroll et l’upload qui prennent 99% du temps et non la génération elle-même).
Et juste pour réagir concernant gemini, je pense que c’est plus un terrain de jeu et que ça n’aura jamais une grande audience. Un de ses principaux avantage à mon goût est la garantie pour un visiteur de ne pas être traqué/analysé/monétisé. Tu démarres ton navigateur gemini l’esprit libre, pas besoin d’être sûr d’avoir un antipub, de nettoyer les cookies, de craindre un js qui minerait, de fuiter des infos en provenance d’un autre site que tu visites ou autre. Par contre les contraintes sur le formattage que permet gemini me rebute pas mal. :-/
@icemanfr75@mastodon.social
A force de modifications je me suis détaché au maximum des spécificités jekyll pour pouvoir basculer sur autre chose le cas échéant avec tous les billets en md puis les images rangées au même endroit et retravaillées. bref j’ai supprimé tout plugin pour faire moi même la structure, fonctionnant ainsi sur n’importe quelle version de jekyll et ruby…là aussi ça aide pour autre chose. Hugo, pelican ou makesite.py qu’importe…
Je suis d’accord avec toi concernant Gemini.
@lord@pleroma.lord.re
(…) Ouaip. Je pense que si tu n’utilises pas de trucs vraiment spécifiques à ton générateur statique tu pourras migrer sans trop de difficulté de l’un à l’autre voir pourquoi pas créer ton propre générateur si vraiment tu es prêt à t’y investir lourdement mais vu la pléthore de générateurs existant…
@icemanfr75@mastodon.social
partir sur ma propre solution, ça serait peut-être croire que je ferai mieux que toutes ces solutions… Hum, j’en suis très loin et le jeu n’en vaut pas la chandelle pour l’instant.