Arrêtez de faire des sites dynamiques

La plupart des personnes souhaitant créer un site Web vont se tourner d’emblée vers un CMS (« Content Management System » ou « Outil de gestion de contenu » en français).

En effet, utiliser un CMS est facile et relativement rapide (pour peu qu’on passe la barrière initiale de l’installation, pas toujours à la portée des néophytes) : après avoir choisi un joli thème, trouvé un nom pour son site, quelques clics suffisent pour publier une première page.

Écran d’ordinateur affichant du code PHP (WordPress)

Illustration de Lavi Perchik.

Néanmoins, une fois passée cette phase de découverte d’un outil qui semble magique, on en découvre les coûts cachés (maintenance, complexité de personnalisation des templates, failles de sécurités, etc. pour finalement terminer avec la perte de la base de données et de tout ses contenus rédigés avec amour…)

C’est quoi un site dynamique ?

Depuis l’avènement des langages de programmation web côté serveur (je pense notamment à ASP 3 et PHP 4 au début des années 2000), la majorité des sites sont devenus « dynamiques » : les contenus sont stockés dans une base de données (BDD), un script charge ces données – à la demande – et les affiche dans la page Web consultée par l’internaute.

Une page web dynamique est servie par un serveur qui déclenche un langage, par exemple PHP, qui lui-même interroge une base de données et va chercher des fichiers statiques de modèle (templates).

Schéma illustrant le principe d’une page web dynamique, par teleporthq.io.

De fait, la consultation de chaque page d’un site nécessite l’exécution de tâches par le serveur afin d’afficher le résultat dans le navigateur.

Bien entendu, il existe des mécanismes de mise en cache, c’est-à-dire la création d’une copie statique à un instant T, afin de ne pas avoir à re-réaliser les tâches permettant d’afficher la page si celle-ci est consultée dans un contexte équivalent par un autre visiteur.

Si les sites dynamiques ont un intérêt certain dans un objectif d’interaction avec l’internaute (création de compte, formulaire de saisie de commentaire, ajout au panier d’un site e-commerce, etc.), on peut se poser la question de leur utilité, voire de leur impact, dans le cas d’un site dont les contenus sont uniquement disponibles pour consultation, ce qui est le cas de la majorité des contenus sur le Web.

Mais alors, quelle serait l’alternative ?

Un site statique en 2022 ?

Depuis une dizaine d’années, les outils de création de sites statiques, tels que Jekyll ou Hugo, ne cessent de prendre de l’ampleur, et sont utilisés par de nombreux acteurs du Web : Google, Netflix, Mailchimp, Mapbox, etc.

Dans un site web statique, le navigateur demande un fichier statique, le serveur lui envoie.

Schéma illustrant le principe d’un site web statique, par teleporthq.io.

Cette manière de « générer » un site Web permet aux différents intervenants de se concentrer sur ce qui est réellement important, à savoir :

  1. le contenu : les rédacteurs peuvent rédiger dans un format simple (le plus courant étant Markdown) qui facilite la portabilité et l’autonomie ;
  2. une mise en forme efficace : les graphistes et les développeurs front-end peuvent se concentrer sur le rendu HTML et CSS sans être contraints par la technologie plus ou moins propriétaire d’un CMS.

Avantages

  • Performance : pas de tâches applicatives côté serveur ;
  • Sécurité : pas de CMS exposé en frontal, donc un risque réduit d’intrusion ou de défaçage ;
  • Découplage : distinction entre l’outil de gestion des contenus et l’outil de création du site ;
  • Portabilité : le contenu, rédigé en Markdown, peut être importé et exporté à loisir.

En finir avec le dynamique systématique

Pourtant aujourd’hui la plupart des sites Web sont motorisés par des CMS (WordPress, Drupal, etc.) afin d’offrir à l’utilisateur une interface de gestion du contenu : écrire, mettre en forme, publier.

Néanmoins, l’avantage du dynamique, à savoir la possibilité d’éditer rapidement un contenu, est devenu contre-performant en embarquant un système complexe et coûteux alors que, dans la pratique, la plupart des contenus ne sont plus jamais modifiés après la publication initiale.

De plus, la majorité des sites concernés ne sont pas ou plus maintenus et exposent des failles de sécurité potentielles : c’est très souvent le cas avec des sites WordPress qui sont transformés en espaces publicitaires par des hackeurs malveillants.

Alors pourquoi ne pas revenir à une approche statique, simple et adaptée au besoin de la plupart des gens ?

Créer un site statique n’est pas si difficile

Si créer un site statique peut paraître technique et accessible uniquement aux « nerds », c’est en réalité plutôt simple pour peu qu’on n’ait pas peur de lancer une ligne de commande.

J’en veux pour preuve le nombre important de webdesigners qui migrent vers Jekyll ou Eleventy afin de publier leur blog ou leur portfolio.

En pratique

Créer un site statique « moderne » tient en 4 étapes :

  1. rédiger le contenu dans un éditeur de texte, idéalement au format Markdown pour plus de liberté ;
  2. créer un template, c’est-à-dire une page HTML contenant des balises dynamiques ;
  3. exécuter une commande qui va s’occuper de fusionner le contenu et le template ;
  4. déployer le site ainsi généré, c’est-à-dire copier les fichiers sur un serveur Web.

Des contenus réutilisables

L’un des éléments clef de l’approche statique est certainement le découplage entre les contenus et la mise en forme : nous avons d’un côté des fichiers plats, éditables via n’importe quel éditeur de texte, et de l’autre des templates.

D’autre part, les données structurées (ou « méta données ») qui permettent de qualifier une page de contenu (titre, date, catégorie, auteur, etc.) sont dans un format répondant à un standard, le plus souvent YAML ou JSON, donc réutilisables.

Il est donc possible d’exploiter ces données dans un autre contexte, ou via un autre support de diffusion : un même contenu peut ainsi être diffusé via un site Web, une application mobile, un web service (statique) ou encore un livre imprimé !

Sautez le pas !

Depuis la sortie de la version 1 de Jekyll et de Hugo en 2013, de très nombreux générateurs de sites statiques ont vu le jour, chacun avec ses avantages et ses inconvénients, à choisir selon ses besoins et ses contraintes.

Aussi je vous invite à sauter le pas, en essayant par vous-même via un vaste choix : https://jamstack.org/generators/.

4 commentaires sur cet article

  1. Julien Wilhelm, le vendredi 23 décembre 2022 à 08:18

    Merci pour ce petit pavé courageux dans la mare : l’approche CMS first est clairement à proscrire, et pourtant, c’est encore ce que l’on privilégie de nos jours (+40% du Web sous WordPress, pour ne citer que lui) !

    Par contre, je ne n’aurais pas fait le raccourci dynamique = CMS. Il y a tout un monde entre les deux.

    Au plaisir d’essayer Cecil un de ces quatre,
    Bonnes fêtes !

  2. Anne-Sophie, le samedi 24 décembre 2022 à 08:57

    Merci pour ce plaidoyer pour sortir de WP !

    Je trouve ces solutions très intéressantes mais vraiment réservées à des spécialistes : pas du tout adaptée à ma prof de danse ou mon groupe de photographes locaux qui veulent faire un site.

    Comme @Julien, j’aime explorer un peu entre les deux : par exemple KirbyCMS qui n’est pas entièrement statique (c’est sans BDD mais avec une génération des fichiers quand même côté serveur), mais qui reprend tous les autres avantages que tu cites, et même plus (panneau d’administration, markdown, etc etc).

  3. Arnaud Ligny, le samedi 31 décembre 2022 à 13:24

    @Julien merci pour ton commentaire, et je serais très intéressé par ton retour d’expérience concernant Cecil :-)

    En effet, j’ai pris le parti de rédiger un article court, avec quelques raccourcis, afin de privilégier le message de fond.
    Tu as tout à fait raison : la réalité n’est pas aussi manichéenne et il est tout à fait possible, par exemple, d’utiliser un CMS (y compris WP) pour la gestion / édition des contenus combiné à un générateur de site statique qui va se nourrir depuis l’API du CMS (approche « headless »).

  4. Arnaud Ligny, le samedi 31 décembre 2022 à 15:38

    @Anne-Sophie merci !

    Oui, l’approche de ces solutions peut sembler réservée à des spécialistes parce qu’elle nécessite une phase de paramétrage plus importante.
    Néanmoins des solutions clef en main existes déjà et d’autres apparaissent, comme par exemple Siteleaf (https://www.siteleaf.com), DatoCMS (https://www.datocms.com) ou encore Publii (https://getpublii.com).

    Et en effet, comme je l’indiquais en réponse à Julien : il est également possible de s’appuyer sur un CMS headless combiné à un générateur de site, comme par exemple Kirby + Eleventy (https://www.11ty.dev) ou encore Strattic pour WordPress (https://www.strattic.com).

    Ces approches ne sont pas encore aussi intuitives qu’un WP.com mais je suis convaincu que de plus en plus de solutions grand public vont encore émerger dans un avenir proche :-)

Laisser un commentaire

Les commentaires sont modérés manuellement. Merci de respecter : la personne qui a écrit l'article, les autres participant(e)s à la discussion, et la langue française. Vous pouvez suivre les réponses par flux RSS.