En quelques années, les gestionnaires de contenu statique, Jekyll en tête sont devenus très populaires, de Google à Netflix en passant par Mailchimp, Mapbox ou NodeJS, ils sont partout et sont devenus le choix de la raison pour les sites de contenus à fort trafic. Leurs usages évoluent et de nouveaux services dédiés viennent enrichir et faciliter l’expérience utilisateur des contributeurs et des développeurs.

Cette stack permet aux différents intervenants de se concentrer sur l’essentiel. Les rédacteurs peuvent ainsi rédiger leurs articles au format Markdown, un format texte très simple et très lisible, qui facilité la portabilité.

L’article que vous êtes en train de lire est écrit dans une application de bureau à l’interface minimale spécialement conçue pour offrir une bonne expérience de rédaction. Comme le dit Golden Krishna dans son livre, la meilleure interface c’est encore de ne pas en avoir.

Performance, sécurité, décentralisation, portabilité, autant d’excellentes raisons derrière l’adoption croissante de cette stack qui combine souvent JavaScript, des APis et du Markup.

Essayons de comprendre ce qui pourrait passer pour un retour en arrière aux yeux de certains, alors qu’il faut simplement y voir une évolution logique d’un processus de publication parfaitement adapté à notre manière asynchrone de travailler et aux ressources technologiques actuelles.

La fatigue du dynamique

La plupart des CMS datent de l’ère LAMP et ont vu le jour au début des années 2000, encore aujourd’hui les CMS dynamiques, Wordpress et Drupal en tête, font tourner une bonne partie des sites web de la planète. Ces logiciels sont alimentés en temps réel par des bases de données et demandent un certain niveau de maintenance ne serait-ce que pour garantir la sécurité des contenus et assurer de bonnes performances aux utilisateurs. L’interface d’administration est hébergée avec le site web, cela implique que l’expérience du contributeur est fonction des performances du site. Je ne souhaite à personne de ne plus avoir accès à son interface d’administration en ligne, pour cause de fort trafic.

Malheureusement la majorité de ces sites ne sont pas bien maintenus et sont donc vulnérables à de potentielles attaques. Ils sont souvent inutilement lents car leur contenu n’est pas mis à jour en permanence, mais à chaque clic, c’est une requête vers la base de données qui est déclenchée pour servir le même contenu aux utilisateurs.

Les plus experts argumenteront qu’on peut toujours mettre en place des stratégies de cache et de serveur proxy comme Varnish, mais une telle architecture a un coût non négligeable. Et l’invalidation de cache est une des choses les plus complexes en informatique. Si vous ne le saviez pas, Martin Fowler se chargera de vous le rappeler :

There are only two hard things in Computer Science: cache invalidation and naming things — Phil Karlton

Ces problèmes sont déjà beaucoup plus simples à résoudre si on se contente de servir du contenu dit statique - rassurez-vous on sait très bien faire du dynamique côté client en JavaScript de nos jours.

Revenir à des choses simples et performantes, c’est la philosophie des générateurs de site statique. Déployés sur des CDNs à moindre coût, ils sont plus rapides, plus sécurisés et donc beaucoup moins onéreux. Les sites statiques connaissent une popularité grandissante de par leur efficacité et la facilité avec laquelle il est possible de nos jours de faire du déploiement continu, à savoir plusieurs centaines de mises en production par jour.

Ils sont fidèles en cela à la philosophie qui a toujours animé la communauté open source et qui anime aujourd’hui les startups et les organisation agiles.

Release early, release often — Eric S. Raymond, la Cathédrale et le Bazaar, 1999.

Et si vous n’êtes pas capables de déployer sans crainte en permanence, vous avez sûrement contracté une bonne dette technique.

La simplicité du statique

Des blogueurs comme le webdesigner Dan Cederholm, fondateur de Dribbble, confessent le plaisir de revenir à de l’hypertexte. Fort logiquement le blog de Dribbble est lui aussi géré en statique. Si des webdesigners l’adoptent, c’est que la courbe d’apprentissage est très rapide quand vous faites du développement web front-end. Vous ressentez ce plaisir de reprendre la main sur vos contenus et de les organiser comme bon vous semble, sans être contraints par les choix imposés par un CMS.

Pour la petite histoire, Ben Balter était un ancien contributeur Wordpress, quand il a découvert Jekyll. Il a eu une révélation et s’est empressé de développer un outil de migration de Wordpress à Jekyll. Ben travaille aujourd’hui pour Github, où il est chargé de sensibiliser les gouvernements à l’open-source et c’est un des principaux contributeurs à Jekyll et Github Pages. Il est vraiment tombé amoureux de cette stack.

On recense à ce jour plus de 450 gestionnaires de contenu statique, écrits dans différents langages et supportant diverses syntaxes pour la conception les modèles de page, certains entièrement basés sur JavaScript et les standards web. Il y en a forcément un qui sera le bon outil pour vous. Tout dépend de votre besoin, de votre stack actuelle et des compétences de votre équipe.

Jekyll, écrit en Ruby par un cofondateur de GitHub, reste le plus populaire, car il bénéficie d’une large communauté et d’un riche écosystème. Lorsqu’en 2008 Tom Preston-Werner explique comment bloguer comme un hacker, il pose les bases d’une architecture volontairement simple qui place le format des contenus, le versionnement, le déploiement, la sécurité et la performance au cœur de la philosophie de son logiciel.

Dans Jekyll1 ou Middelman, c’est Liquid, un langage de templating conçu par Shopify, qui permet d’insérer des données et de la logique dans les modèles de pages. Sa syntaxe composée d’une douzaine de balises et d’une série de filtres très utiles pour manipuler les données est très accessible aux designers web. Si vous préférez utiliser Swig, Handlebars ou React, regardez plutôt du côté d’Hexo, d’Assemble, de Metalsmith ou de Gatsby.

Comme dans des frameworks comme Rails, Ember ou Meteor, les conventions priment sur la configuration2. Vous devrez souvent respecter quelques conventions, comme stocker vos articles dans un dossier _posts ou vos données dans un dossier _data.

Ce qui est chouette, c’est que vous pouvez apprendre à votre rythme et commencer avec des fichiers HTML et CSS standards puis transformer vos fichiers HTML en modèles, les séparer en composants réutilisables et en extraire petit à petit les données.

Vous pouvez aussi créer facilement vos propres structures de données et définir autant de variables dont vous avez besoin via les entêtes Front Matter au format YAML.

Point important, à l’inverse des flat CMS comme Kirby ou Grav, il n’y a pas d’interface graphique fournie par défaut, même si elles commencent à arriver via l’ajout de plugins ou en faisant appel à des services dédiés3.

L’éditeur de contenu de Cloudcannon

Fidèles à la philosophie UNIX, les générateurs se contentent de faire une seule chose à la fois : transformer des contenus en site statique. C’est surement pour cette raison qu’il y en a autant. Certains vont plus loin que d’autres en intégrant notamment des commandes pour le déploiement. Comme dans les CMS l’enrichissement en fonctionnalités se fait à l’aide d’extensions et autres plugins.

Jekyll en action dans le terminal

Plus vous aurez de fichiers à générer, plus l’étape de build prendra du temps. Il vous faudra donc faire en sorte de limiter ce temps au minimum si vous souhaitez que vos mises en production ne prennent que quelques secondes. Si des gestionnaires de contenu statiques plus récents comme Hugo écrit en Go sont très performants, il sera parfois plus judicieux de découper vos contenus en plusieurs parties et de ne générer que le strict nécessaire.

Le gros avantage de cette stack c’est de pouvoir l’adapter à vos besoins et comme avec des LEGO™ vous pouvez créer votre propre système de publication.

Des contenus accessibles et réutilisables

the problem with WYSIWYG is that we are giving content creators an antiquated metaphor from the desktop publishing era to communicate to them what it means to publish on the web — Karen Mc Grane

Il n’y a pas que les développeurs et les designers web qui trouvent cette approche intéressante, Karen McGrane, la papesse de la stratégie de contenu, explique qu’il est important que les contenus puissent être stockés indépendamment de tout système de publication dans des formats lisibles et débarrassés de toute présentation. De plus le fameux WYSIWYG (What You See Is What You Get) est une fausse promesse de par la nature imprévisible du web car vous ne pouvez pas savoir sur quel périphérique sera affiché votre contenu : un ordinateur portable, un téléphone, une montre, une télé, des lunettes connectées ?

Des formats textes comme Markdown, au balisage minimal offrent à la fois une bonne expérience pour la rédaction et peuvent être ensuite facilement transformés en HTML, mis en forme via CSS et enrichis via JavaScript.

Le format Markdown est de plus en plus populaire chez les rédacteurs et les éditeurs et a été adopté comme format par défaut par des logiciels comme Ghost, un logiciel de blog écrit en NodeJS qui se focalise lui aussi sur l’expérience de rédaction de contenu.

Beaucoup d’applications comme MacDown, IA Writer ou Ulysses sous Mac, insérez votre application open-source préférée ici ou de services en ligne permettent aujourd’hui d‘éditer du Markdown de manière simple.

Aperçu de cet article dans MacDown

Les contenus ne sont donc plus enfermés dans une base de données, ils sont stockées dans des formats texte comme Markdown, YAML ou JSON. Il est dès lors possible d’exposer vos contenus au format JSON et de proposer une API RESTful pour que vos données puissent être réutilisées par d’autres sites.

En privilégiant ces formats, les gestionnaires de contenu statiques vous garantissent l’accessibilité, la réutilisation et des migrations grandement facilitées.

Une adoption croissante

Si le besoin de départ était de simplement versionner et servir son blog sous forme de contenu statique, les avantages mentionnés plus haut ont vite intéressés les sites de contenu à fort trafic. Ainsi en 2011 Mailchimp annonçait la refonte de son site avec un gestionnaire de contenu statique.

En 2012, c’est l’équipe de Barack Obama qui choisit Jekyll, pour recueillir les dons pour le financement de sa campagne. Les objectifs sont dépassés, le site est 60% plus rapide et grâce à une démarche UX agile et au déploiement continu, l’objectif de départ est dépassé, et c’est 250 millions de dollars qui seront récoltés.

Un code source ouvert, des données accessibles à d’autres services, le geste est fort de la part d’une administration publique.

En 2016, les leçons ont bien été apprises et on ne s’étonne plus de voir que le site d’Hillary Clinton soit servi en statique. Il existe même un service dédié pour publier les sites gouvernementaux américains en statique. Si la France pouvait s’inspirer de cette démarche ouverte…

De son côté, le trio GitHub Pages, Jekyll et CDN continue d’être très utilisé que ce soit par les administrations, des sociétés privées ou des associations.

Afin de faciliter les contributions et ajouter une couche d’abstraction du versionnement pour les rédacteurs, on peut utiliser le service prose.io, qui propose une interface graphique pour éditer des fichiers Markdown reliée avec votre dépôt Github.

Un workflow naturel

Jekyll transitions smoothly between prototyping, content authoring, and deployment tasks — Young Hahn

Le gestionnaire de contenu statique peut être utilisé dès la phase de prototypage, les contenus peuvent être ajoutés au fur et à mesure et après avoir itéré jusqu’à parvenir à un premier résultat assez satisfaisant, le déploiement en production en devient anecdotique.

La documentation et le styleguide, voire le Design System, peuvent également être générés lors de l’étape de build, ce qui assure qu’ils soient tout le temps à jour. Grâce à Git, les développeurs, les designers et les rédacteurs partagent un processus de travail commun.

Unless it’s part of your build, your styleguide is just more documentation to maintain — Phil Hawksworth

Des services gratuits

Tous les jours les webdesigners et les développeurs front-end du monde entier consultent des sites de documentation servis en statique : Bootstrap, Foundation, NodeJS ou Google Web fundamentals pour n’en citer que quelques uns.

Beaucoup sont hébergés sur Github pour faciliter les contributions et à ce jour le service GitHub Pages héberge près d’un million de sites statiques, qui sont tous stockés sur des CDN. Le service étant gratuit pour les projets open source, il serait dommage de s’en priver. C’est d’ailleurs ce que nous avons fait pour le site de Sud Web. D’autres services similaires ont depuis vu le jour comme Gitlab Pages ou Netlify, qui proposent des formules gratuites pour les projets en open source.

Cela ne vous coûte donc rien d’essayer !

Un web de services

Les générateurs de site statique ne font qu’une chose et le font bien et si vous avez besoin de fonctionnalités supplémentaires comme du paiement en ligne, vous passez par des services tiers comme en dynamique. On s’éloigne du monolithique pour se rapprocher de la philosophie des microservices, votre application interagit avec plusieurs services, chacun est interchangeable et vous permet de choisir le plus adapté à vos besoins.

Comme Github Pages ou prose.io, de nouveaux services permettent de faciliter le déploiement ou d’améliorer l’expérience utilisateur :

  • Cloudcannon propose une interface graphique pour gérer Jekyll et ses contenus. Parmi ses clients, Netflix l’utilise pour présenter la diversité d’appareils avec lesquels il est possible de consulter leurs contenus.

  • Contenful est un service de modélisation et d’édition de contenus et propose ensuite des APIs pouvoir les diffuser sur différents supports. Vos contenus peuvent être récupérés de différents endroits et assemblés avant d’être importés dans Jekyll, Middleman ou Gatsby par exemple.

  • Netlify se propose d’optimiser la performance et l’hébergement de vos sites statiques sur leurs CDN et d’automatiser vos assets et le déploiement en y connectant directement votre dépôt Github, GitLab ou Bitbucket. NodeJS est dispo par défaut, à vous les web apps performantes !

Ces différents services permettent de mettre en place des architectures décentralisées comme l’a fait l’agence Carrot, éditrice du générateur Roots (devenu Spike) :

Exemple d’architecture de services pour servir du statique

On peut se poser la question de la dépendance à des services tiers, mais rien ne vous empêche d’héberger ou de sauvegarder vos sites statiques sur vos propres serveurs.

Tom Preston-Werner expliquait lors de la première JekyllConf, que si certains sites redeviennent statiques, c’est qu’ils auraient toujours du le rester, mais que nous ne disposions pas il y a dix ans de tous les outils actuels. Lorsque le dynamique est arrivé c’est devenu la solution par défaut. Sauf que vous ne pouvez pas servir du dynamique à des millions de personnes en même temps. Vous vous heurtez à un moment à des problèmes d’échelle. Générer le même contenu pour tous vos visiteurs est souvent préférable, c’est ce que fait Github la plupart du temps. Les lignes entre le statique et le dynamique sont floues car ces derniers peuvent aussi générer du statique, le mettre en cache et le servir sur des CDNs.

Il existe en effet des extensions pour générer du statique à partir de Drupal ou de Wordpress si vos contenus ne changent pas en permanence. Si vous préférez y aller en douceur, sachez que le statique cohabite très bien avec le dynamique, vous pouvez donc tirer le meilleur parti des deux mondes.

La tendance actuelle est bien au découplage du front et du back : un CMS headless, à savoir un service dédié uniquement à la modélisation et à l’édition des contenus, un générateur pour assembler le tout et créer des pages HTML, un workflow de déploiement continu pour la publication automatique. Peuvent ensuite se greffer des services comme de la gestion de panier grâce à des services comme Snipcart, de l’indexation et de la recherche performante avec Algolia, etc. Les possibilités sont grandes, surtout que grâce à l’essor en parallèle des functions lambdas et du serverless, les providers de Cloud comme Amazon, Google et Microsoft ne vous demandent plus que quelques centimes pour exécuter des programmes distants. À moins que vous deviez absolument gérer votre propre infrastructure, les coûts de fonctionnement sont bien moindres.

Conclusion

Servir du « statique » — ou du JS côté client si vous préférez - n’est pas du tout une mode destinée à rester confidentielle parmi les hackers, c’est une réponse simple à des problématiques complexes. Gardez en tête que 78% des sites sous Wordpress souffrent de vulnérabilités et que quand une faille de sécurité impacte Drupal, des millions de sites sont concernés.

C’est donc une solution que vous devriez sérieusement considérer si vous souhaitez réduire vos coûts d’infrastructure sur des sites à fort trafic. Sur des sites très fréquentés le coût peut être divisé par 15 ou plus.

Le full statique est idéal pour des sites de contenus : présentation produit, documentation, blog ou application web (progressive) en JavaScript, en revanche il n’est pas adapté pour des sites où le contenu est majoritairement généré par les utilisateurs.

L’écosystème autour est en plein essor et va fort logiquement continuer de se développer. Une des priorité est maintenant de rendre ces outils encore plus accessibles aux rédacteurs. Ainsi les CMS headless pullulent ainsi que différentes plateformes de Content as a Service.

Vous l’aurez compris, la mouvance statique ne fait que commencer et l’engouement devrait continuer de croître dans les années qui viennent.

J’espère que cet article vous fera réfléchir à deux fois avant de partir les yeux fermés sur un bon vieux gros CMS dynamique pour votre prochain projet. Vous connaissez maintenant les nouveaux paradigmes qui laissent présager une ère post-CMS comme certains l’appellent déjà.

Cet article a été rédigé suite à une présentation dont voici les slides.

Ne passez pas à côté des choses simples, c’est le message que vous avons voulu faire passer avec Bertrand Keller lors de Paris Web 2016.

Jamstatic regroupe quelques utilisateurs francophones de générateurs de site statique. Nous publions des liens d’actualité autour des générateurs sur Twitter. Nous échangeons et nous nous entraidons sur le channel Slack.

Notes

  1. Jeyll est le gestionnaire de contenu statique le plus populaire, en partie car il est supporté nativement par Github Pages. ↩

  2. Quand les conventions priment, le développeur a moins de choix à faire, mais ne perd pas pour autant en flexibilité - source Wikipedia. ↩

  3. Quelques services d’édition de contenu en ligne : Cloudcannon et Siteleaf pour Jekyll, Forestry.io pour Jekyll et Hugo, ou Bowtie pour n’importe quel générateur de site statique. ↩