Désormais, on publie tous du contenu en ligne chaque jour, via des plateformes centralisées et autres formats plus ou moins ouverts. Mais lorsque l'on veut déplacer son blog, son CV ou ses données, c'est la galère. Le retour à un web « low tech » veut casser cette mécanique. Avec bien d'autres avantages.
Avec le web est apparue une faculté nouvelle : la possibilité pour chacun de faire porter sa voix. Tout internaute est ainsi libre de publier son propre site, une page personnelle, un blog, un album photo afin de partager avec le monde entier. Mais voilà, même en 2020, c'est souvent considéré comme compliqué.
En la matière, il y a ailleurs une forte fracture numérique : les premiers touchés sont ceux qui ne maîtrisent pas toutes les arcanes de la technique. Héberger son site, apprendre le langage HTML, choisir ses outils, etc. sont autant de choix qui rebutent et incitent à se tourner vers des solutions clé en main ou vers la facilité des réseaux sociaux.
Tant de plateformes qui troquent la facilité qu'elles apportent contre une limitation des libertés de leurs utilisateurs, d'une manière ou d'une autre. Il est donc opportun de s'intéresser aux alternatives. Surtout qu'il existe de nombreuses ressources gratuites, ouvertes et simples à prendre en main qui permettent à chacun de publier en ligne, sans connaissances particulières et sans concessions sur ses données. De participer à des projets communs.
Nous l'avons vu dans de premiers articles de ce dossier, où il a déjà été question de sites statiques, de PWA ou même de pull request pour les plus courageux. Tant d'actions qui peuvent paraître inaccessibles mais pourtant simples lorsque l'on y regarde de plus près. Comme la gestion de documents via Git, leur écriture via le format de balisage Markdown, leur conversion en un site ou en différents formats via Pandoc.
Une initiative qui s'inscrit dans une volonté, plus générale, de documenter et expliquer comment fonctionne Internet, les différentes solutions techniques de stockage, la gestion de vos données, les protocoles modernes et autres solutions pour disposer de mails sécurisés, complets mais ne vivant pas de vos données.
Tant d'articles qui sont progressivement rendus accessibles à tous, que vous pouvez partager ou simplement utiliser pour vous guider sur le long chemin de la réappropriation de l'outil informatique et du numérique. Autant de raisons de nous aider à poursuivre notre ilot d'information indépendant en ligne... en vous abonnant 😉.
Préserver votre liberté et la portabilité de vos publications
Nous explorerons donc dans les semaines à venir différentes possibilités en partant du principe que vous disposez des bases pour maitriser l'outil informatique, mais pas plus. Merci donc aux puristes de la technique de nous pardonner les quelques simplifications qui pourront y être utilisées.
Car depuis les débuts de l'hébergeur français Mygale en 1996, aux plateformes mondiales simples à prendre en main comme Medium en passant par les réseaux sociaux, que de chemin parcouru. Une évolution symbolisant la contradiction de cette liberté donnée à chacun : malgré elle, l'internaute s'exprime le plus souvent... mais sur des plateformes toujours plus géantes et centralisées. L'humain est souvent grégaire.
Facebook, Instagram, Snapchat, Twitch, Twitter, YouTube ou encore TikTok plus récemment sont nés de cette réalité. Nouveaux rois du partage de la parole en ligne, prenant le pas sur la vague des blogs des années 2000. Une tendance vers une expression plus simple, plus anecdotique, passant progressivement du texte à la vidéo.
Un phénomène qui s'étend jusqu'aux médias, qui suivent le même parcours. Cette concentration est parfois justifiée par l'existence d'un service qui se veut global. Besoin du CV de quelqu'un ? Il est forcément sur LinkedIn. Facebook ? Un annuaire géant pour rester en contact avec ses proches. Instagram ou Twitter ? Une manière de scénariser la perception de votre vie et promouvoir votre activité en ligne. Besoin de quelque chose ? Amazon est là. D'apprendre à faire quelque chose ? Il existe forcément une vidéo YouTube qui explique comment faire.
Tant d'outils promettant de nous faire gagner du temps et de faciliter notre quotidien, cachant un problème plus profond gagnant en importance : notre dépendance à des services tiers n'offrant pas la possibilité de récupérer ses données pour les placer ailleurs. Comme si, finalement, le Minitel avait gagné en douce (loin de ses concepteurs français) face à l'approche ouverte et décentralisée qui était celle qui a porté la victoire d'Internet à ses débuts.
Ce, malgré les lois qui sont venues renforcer la portabilité en France et en Europe. Mais pouvez-vous déplacer vos publications Twitter chez Facebook ? Non. Car il s'agit avant tout de cages dorées, conçues pour l'accès à vos données. L'inscription y est simple, leur prise en main facile, leurs audiences énormes. Mais de là à vous aider à en partir... Sur le sujet, Laurent Chemla propose d'ailleurs d'imposer l'interopérabilité aux plateformes.
Car si demain l'un d'entre eux venait à disparaître, à changer complètement de stratégie. Que deviendront ses utilisateurs ? Que deviendront leurs contenus ? Quel impact cela aura-t-il sur des pans entiers du web ?
Reprendre son indépendance, ça parait parfois compliqué
Les impossibilités peuvent aussi tenir à des questions techniques, à la conception même des outils qui n'intègrent pas la notion de liberté de l'utilisateur. C'est notamment le cas de la plupart des CMS (Content Management System) qui dépendent d'un langage, d'une infrastructure et d'un système de gestion de bases de données (SGBD).
Si des exports/imports sont possibles, ils ne sont pas toujours à la portée du premier venu. Passer d'un site hébergé sur Wordpress.com à un Drupal chez OVH, puis à un Framasite ? Oubliez tout de suite l'idée. Un service professionnel pourra se permettre de telles migrations, mais pas un simple particulier.
Sans parler de l'accès aux serveurs nécessaire à l'installation de certaines applications. Des connaissances qu'il faut pour les maintenir en fonctionnement, assurer leur mise à jour, en toute sécurité. Des contraintes qui découragent même ceux qui veulent s'exprimer en dépassant le cadre imposé par les réseaux sociaux : l'expression en 280 caractères, les photos de repas, les stories plus ou moins artificielles et autres pensées visant à attirer les « J'aime ».
Heureusement, il existe d'autres modèles vous permettant de publier en ligne selon deux critères : simplicité et liberté. Et parfois de manière gratuite. Les CMS dit headless, qui découplent le contenu de sa gestion, sont une alternative possible. Mais on peut aller bien plus loin pour faire du partage en ligne une activité simple accessible.
Markdown et générateurs de sites statiques : le combo gagnant
Ici, les solutions ouvertes et open source sont des alliés de poids. L'une de celles qui nous serviront dans le cadre de ce dossier a été conçue par John Grubber en collaboration avec Aaron Swartz en 2004 : Markdown.
Ce langage de balisage vise à proposer une alternative plus simple et plus lisible à HTML dans le cadre de la mise en forme de documents. Ce n'est pas une solution standardisée, il en existe différentes variantes, mais elle est exploitée par un nombre croissant de services ces dernières années.
Ainsi, il existe des dizaines d'éditeurs en ligne, mais aussi d'applications gratuites ou payantes, proposées sur différentes plateformes, qui permettent de rédiger simplement du contenu en suivant quelques règles simples à comprendre. Il fait l'objet de plusieurs évolutions depuis, et autres tentatives de standardisation.
Titre
=====
## Sous-titre
### Sous-sous-titre
_Texte en italique_
**Texte en gras**
`Code informatique`
> Ceci est une citation
Liste à puces :
*
*
*
Liste à puce ordonée :
1.
2.
3.
Ceci est [un lien](https://www.nextinpact.com).
Ligne horizontale :
---
Notez qu'il existe parfois plusieurs possibilités pour un même élément. Ainsi les symboles « * », « + » ou « - » peuvent être utilisés pour une liste à puces, les liens peuvent être passés sous la forme de références, etc.
Ce format prend tout son sens lorsqu'on l'utilise avec un outil complémentaire : le générateur de site statique. Pour faire simple, il s'agit de prendre du contenu rédigé en Markdown, puis de l'utiliser pour créer un site web composé de pages HTML, de feuilles de styles CSS et parfois même d'un peu de JavaScript.
Ces trois éléments sont regroupés sous la forme de thèmes qui ne nécessitent pas de connaissances particulières. Ainsi, l'utilisateur peut se contenter d’en choisir un dans une liste et de rédiger ses pages en Markdown dans un simple éditeur de texte. Le générateur se charge de tout le reste.
C'est là que vous entendrez en général parler de la JAMStack pour le trio JavaScript, API, Markdown. Le résultat sera constitué de pages pouvant être stockées n'importe où, sans technologie particulière côté serveur : ni base de données ni langage ou configuration spécifique. Un simple transfert des fichiers est nécessaire. De quoi assurer une grande liberté côté portabilité, mais aussi un faible temps de chargement puisque le contenu est fixe.
Bonne nouvelle, il s'agit aussi de solutions qui nécessitent peu de ressources à l'utilisateur lorsqu'il navigue sur votre site. En ces temps où l'éco-conception des services est au centre des préoccupations, ce n'est pas rien.
Ceci est un site web à héberger où vous voulez
Un tel site n'est pas pour autant figé, puisqu'ajouter un billet à un blog peut être effectué assez simplement, certaines solutions proposant même une gestion via une interface d'administration. Là aussi sans besoin particulier côté serveur. Vous pouvez également exploiter des modules côté client pour l'ajout de commentaires par exemple. Mais aussi à travers des requêtes ou API maison grâce à une autre évolution technique récente : le serverless.
Il existe plusieurs générateurs de pages statiques. Le plus connu est sans doute Jekyll qui est utilisé par GitHub pour l'hébergement des Pages de ses utilisateurs. Mais ce logiciel open source, développé en Ruby, peut également être installé sur n'importe quelle machine pour générer votre site.
Citons également 11ty (JS), le français Cecil (PHP), Hakyll (Haskell), Hexo (Node.js), Hugo (Go), ou Pelican (Python). Pour l'édition, des environnement de développpement (IDE) gérant Markdown peuvent vous simplifier la vie comme Notepad++, Visual Studio Code/Atom, Sublime Text. Vous pouvez également compter sur des services et applications dédiés tels que Caret, Dillinger, Editor.md, HackMD, Remarkable, StackEdit ou Typora.
Des outils de gestion de contenus (CMS) se sont aussi spécialisés dans ces solutions headless à la manière du français Strapi, Contentful, Cockpit, Directus ou Prismic. Chacun avec ses avantages et ses inconvénients.
Quelle solution pour l'hébergement ?
Une fois le contenu de votre site rédigé et les pages générées, se pose en général une question : où les héberger ? La solution la plus directe est de passer par... un hébergeur, comme Gandi, Infomaniak, OVH ou Scaleway. Ils proposent en général des services à prix réduit pour un petit site web. Ou gratuit comme Forestry et Netlify :
- Hébergeons (gratuitement) un site statique avec accès sécurisé
- Comment créer un nom de domaine personnalisé et votre propre adresse email
Si vous leur achetez un nom de domaine, vous pourrez parfois avoir droit à un petit espace de stockage inclus, suffisant pour un site statique sans trop d'images. Vous pouvez également le faire avec un espace Free.fr, un petit serveur hébergé chez vous via un Raspberry Pi ou un NAS. Aussi bien Asustor que QNAP et Synology proposent une telle solution, mais cela peut demander des connaissances techniques particulières.
Il est également possible de se reposer sur un service gratuit/Freemium qui n'est pas forcément pensé pour ça au départ, comme du stockage S3 ou Google Drive par exemple, en plaçant votre site dans un dossier public. Pour éviter une telle plateforme, il y a Bitbucket, GitHub ou GitLab qui permettent aussi de diffuser des pages pour vos projets. Mais elle peut être utilisée par n'importe qui, parfois de manière simplifiée comme avec les Pages et Jekyll.
Dans tous les cas, vous pouvez garder une URL fixe en achetant un nom de domaine et en effectuant une redirection, ce qui est en général proposé de manière assez simple par votre hébergeur ou certains de ces services. Vous n'aurez ainsi plus d'excuse pour vous reposer sur une plateforme centralisée ou un outil complexe comme Wordpress pour héberger un simple blog ou de renvoyer vers LinkedIn pour votre CV en ligne.
Vous avez d'autres idées ? N'hésitez pas à nous en faire part en commentaires.
Commentaires (20)
#1
Je confirme que Jekyll est très pratique pour générer du statique. Il m’a permis sans trop me prendre la tête (vu que je connais Markdown) de monter un front sympa via github pages avec en plus un DNS perso (simple CNAME à créer).
Exemple : https://hakuneko.download (source : https://github.com/manga-download/manga-download.github.io ).
Le theme jekyll utilisé est https://mademistakes.com/work/minimal-mistakes-jekyll-theme/ qui a plusieurs couleurs et de nombreuses options.
#2
C’est surtout l’utilisation d’un CMS reposant sur un SGBD qui complique sérieusement la portabilité du contenu. Mais on peut conserver la simplicité du Markdown dans des fichiers avec le confort d’un CMS avec les CMS dit “flat file”, comme Grav. Je l’utilise pour mon site perso : www.luminescence-software.org.
Je trouve que c’est un excellent compromis entre site statique et CMS usine à gaz.
#3
Le principe du headless, c’est justement de découpler les deux. De ne plus penser que back et front sont intrinsèquement liés. Tu peux très bien avoir un gestionnaire de contenus utilisant telle ou telle techno, et ensuite utiliser tes données pour générer un site statique en bout de chaîne. La portabilité vient du fait que tu récupères une liste de fichiers HTML (+CSS/images, etc.) posables n’importe où.
Le principe du flat-file c’est d’en rester aux fichiers tout au long du processus, avec ses avantages et ses limites, ce qui est un peu l’approche GitHub Pages d’une certaine manière (mais avec une interface d’édition dédiée dans les CMS FF). Grav est intéressant sans son approche, mais nécessite tout de même un serveur web avec PHP et ça reste une solution tout-en-un.
De toutes façons quand on plonge dans le sujet on voit qu’il existe des dizaines de solutions possibles chacune s’imbriquant potentiellement avec une autre. L’idéal est de trouver ce qui nous convient le mieux selon nos besoins et contraintes
#4
Je ne connaissais pas vraiment les CMS, jusqu’à ce que ma sœur me demande pourquoi son site rame, après avoir farfouillé en vain dans les logs serveurs et l’interface d’admin, je lui ai proposé de lui installé sur un dédié pas cher.
Et bien malgré ma formation d’ingénieur réseau et système distribué, et une forte expérience (datée) sur PHP / JS, je n’ai pas réussi à migrer parfaitement son site Wordpress. C’est une usine à gaz sans nom, vu la complexité du bouzin, je suppose qu’il doit avoir une tonne de failles, on parle de green programming; Avec Wordress on a l’exemple parfait de tout ce qui ne faut jamais faire (bouffer une tonne de CPU pour quasi rien : afficher une page statique).
Franchement ces sites en markdown n’ont que des avantages :
Il y’a du négatif :
#4.1
Pour le tuto comme dit on avait fait un rendu côté client volontairement. Mais tu peux très bien le faire en amont, par exemple à la génération (ou même avec du server side via le framework de la PWA si tu en utilises.
#4.2
Beaucoup moins d’emmerdes si tu ne pousses que le statique (même si potentiellement moins pratique évidemment selon les usages), et chouette copie de sauvegarde indépendante de toute techno si ton site tombe pour whatever raison (surtout quand tu le laisses pourrir pendant des mois… ahem).
“Et bien malgré ma formation d’ingénieur réseau et système distribué, et une forte expérience (datée) sur PHP / JS, je n’ai pas réussi à migrer parfaitement son site Wordpress. C’est une usine à gaz sans nom, vu la complexité du bouzin, je suppose qu’il doit avoir une tonne de failles,”
Note: bien que je ne suis pas grand fan de cet outil pour autant, on ne peut pas dire que “Wordpress est une usine à gaz sans nom”. C’est probablement plutôt “Wordpress une fois configuré en mode explo par des gens qui croient naïvement que c’est secure”.
Là est le vrai souci de Wordpress (cruellement fort la dernière fois que j’ai testé il y a 2-3 ans, j’espère que ça s’est amélioré) : le manque de guidelines et de contrôles qualité pour les extensions, et la (trop grande) souplesse du coeur fait que tu es complètement dépendant de la rigueur du dev quand tu installes une extension. Et en vrai, bah c’est la loterie : donc si tu n’as pas les moyens d’aller analyser le code pour vérifier ce qu’il en est, t’es obligé de faire le saut de la foi.
Or, Wordpress est marketé comme un outil “simple à configurer et utiliser”, donc ciblant des gens non-techniques.
D’où la propension à se retrouver avec des sites absolument dégueulasses, sans que l’on puisse en tenir rigueur aux administrateurs. ^^
Pour en revenir au sujet de la news
Le statique, c’est chouette, ça a plein d’avantages, et c’est facile à comprendre. Pour autant, dès qu’on commence à rentrer dans le dur en termes de structuration sémantique ou d’interactions utilisateurs (même pas trop compliquées), on déchante vite.
C’est donc parfaitement adapté pour les cas d’usage de type “blog / information généraliste”, moins pour des usages plus précis/poussés, à moins d’avoir la compétence technique requise pour au mieux savoir identifier les bonnes briques à utiliser (et comment les intégrer), au pire écrire un truc qui fonctionne soi-même (avec du coup la responsabilité que ça implique en termes de sécurité).
Les CMS ont ce gros inconvénient de nécessiter pour la plupart d’être couplés à une base de données, donc impossibilité d’exploiter “directement” les contenus de manière individuelle et intègre, mais ils apportent… À peu près tout le reste.
Ça peut donc valoir le coup de faire l’effort d’apprentissage. :)
#5
Ca me fait vraiment plaisir de voir ces articles sur le web statique. Ca fait des années que j’essaye de pousser mon entourage à réfléchir à ces solutions au lieu de site très complexe, à la sécurité douteuse, et très consommateur de ressources, pour des blog dont les pages s’affichent en gros pareil pour tous les visiteurs.
Pour ma part, j’utilise Pelican.
Je pense que ce qui manque le plus, ce serait une interface un peu “wisiwig”, et qui permette sans connaissances techniques de mettre à jour son site, et de pousser les modifications sur git.
C’est en tout cas le principal point négatif qui à motivé certains refus dans mon entourage : un CMS à beau être exagérément complexe dans la majorité des cas, l’interface d’administration qu’il présente est plus facile a ppréhender qu’un éditeur de text pour du markdown couplé à un client git.
Merci à la rédaction d’avoir mis en lumière cette solution !
#5.1
Il me semble que Blogdown propose une solution un peu “WYSIWYG” ou, tout du moins, avec une interface graphique. Par contre, faut se manger R et R-Studio…
#6
parcourut non parcouru oui :)
#7
Je ne savais pas qu’il y avait un retour en grace du web statique, ca a commencé quand?
#8
Perso je reste sur mon petit oText, un outil resté sur du code PHP de 2006, mis à jour et évolué depuis (mais resté en procédural, pas en POO), et tout en material design.
J’y ais mon blog, mes liens, mes fichiers, mon lecteur RSS, la liste de contact, mon agenda et mon propre bloc-note (comme des post-it).
Lowcost, lowtech, pas de lib tierces, juste PHP, SQLite et du JS côté client et une forte recherche de simplicité à l’usage. Ça marchait y a 15 ans, ça marchera encore dans 15 ans. Et ça me va, je n’ai pas de raisons de changer d’outil :-)
Par contre je ne me fais pas au Markdown, je reste au BBcode, qui entre moins en conflit avec certains partages de code/équations (#patapé).
#9
Vous n’avez pas cité Dreamwaeaver dans vos outils de page statique.
Le markdown, c’est assez limité niveau sémantique. C’est bien pour écrire une petite doc, mais aller au delà, c’est compliqué.
Même si ces 2 textes seront généralement respectivement en italique et en gras, c’est une conséquence de ce que représente ces balise, c’est en effet respectivement une emphase (balise em) et une emphase forte (balise strong).
Même si je trouve que l’HTML5 se traine la lourdeur syntaxique du XML, il y au moins l’avantage d’avoir une liste de balise sémantique assez large. De plus, grace au système de classe, il est possible de l’étendre à l’infini (et avec JS, il est même possible de créer ses propre balise). Par exemple, en français, un terme étranger (tout particulièrement les termes en latin) devrait être typographié en italique. Ce n’est pas une emphase, donc on de devrait pas utiliser cette balise. En Markdown, on est donc bloqué. En HTML on peut s’en sortir.
#9.1
Tu peux le plus souvent insérer du HTML dans un fichier Markdown, et il sera conservé.
#9.2
Ce qui revient à mélager 2 langages dans un fichier ce qui n’est pas terrible. Sachant qu’il est très simple de convertir du MD en HTML, autant tout écrire en HTML.
Le principal but du MD, c’est que le fichier texte est déjà visuellement mise en forme. L’autre intérêt, c’est que c’est facile à mettre en œuvre et que ça s’écrit très vite. Mais si tu commence sà rajouté du HTML, c’est que tu commence à sortir de cette usage.
Je me suis toujours dis qu’il faudrait que je regarde comment redéfinir des règle d’écriture du XML (un truc à la latex par exemple
\balise(name=value){data}et les versions simplifiée\balise{data}et\balise) pour avoir une version du HTML moins lourde à écrire.ps : les balise code inline dans les commentaires ne marche pas très bien.
#10
Effectivement, le static c’est super efficace et sécurisé. J’avais utilisé cette technique pour mon moteur de blog il y a presque 10 ans : des articles en Markdown avec un “YAML Frontmatter” pour stocker les métadonnées dans le même fichier.
https://github.com/nagius/tanitblog
#11
Le web statique a deux grands avantages pour moi :
1/ C’est super rapide ! Pas de page à générer, pas de SGBD à consulter. Et il suffit d’un petit serveur web de rien du tout et donc aussi du petit matos pas cher et qui consomme pas beaucoup. Donc la consultation d’un tel site est très rapide.
2/ Comme je suis paranoïaque (je travaille dans la sécurité informatique), la “surface d’attaque” est beaucoup plus petite. Autrement dit : il y a beaucoup moins de risques de se faire attaquer un site web statique qu’un CMS.
#12
Le statique, on en revient.
Pour l’édition, ça va tant qu’on fait du texte et des images sans plus. Quand on voit ce que permet WordPress avec un l’éditeur “Gutenberg”, c’est vraiment beaucoup beaucoup plus attractif pour un internaute lambda. La génération statique, avec l’ambiance “tout en CLI, rien en GUI”, c’est une lubie de dev ou de power user.
Oui, c’est génial sur pleins de trucs (portabilité, écoconception, pas de BDD à exporter), mais ça a aussi de gros défauts. Si on part dormir 1 an, on peut revenir pour découvrir que son générateur préféré / son thème a été semi-abandonné… ou à l’inverse qu’il a tellement avancé que le mettre à jour va casser tout notre projet (du vécu :p).
À mon avis, il manque encore une solution qui allie le meilleur des 2 mondes et qui soit pensée pour toucher le grand public. Matt Mullenweg en parlait récemment en disant que la JAMstack était pas une concurrence pour les CMS traditionnels.
#12.1
Partir du principe que bidule est concurrent de machin et va le remplacer est presque toujours une mauvaise approche en soi. Il y a des outils différents, des besoins différents, des solutions souvent complémentaires. C’est comme dit que le statique c’est du full CLI. C’est une vision étriquée qui confond le concept et certains de ses outils.
Oui après tu ne peux pas tout faire côté client, et ce n’est pas toujours la bonne approche. C’est aussi pour ça que JS est passé côté serveur (pour le meilleur comme pour le pire).
#13
Depuis que JS est revenu en grâce et permet d’avoir du dynamisme coté client sans PHP…
#14
Merci pour cet article.