Le retour des sites statiques

À l’époque où j’ai commencé à faire des sites internet, tout le monde (ou presque) faisait ce qu’on a appelé plus tard des sites statiques. Puis est arrivée l’ère des CMS (au sens large: Wordpress, SPIP, Joomla, …) et/ou des frameworks web (Django, Ruby on Rails, Zend, …).

L’hydre du bricolage sous Dreamweaver était terrassée, et tout était pour le mieux dans le meilleur des mondes possibles.

Et pourtant… si on regarde attentivement ce qui se passe actuellement, on assiste à un retour - timide mais indéniable - du site statique.

Alors… nostalgie déplacée de quelques passéistes ou nouveau trend dans la conception web? Étant donné que les personnes faisant le pas se recrutent plutôt dans les geeks purs et durs, la première explication semble discutable.

Pour mieux comprendre ce revirement, j’ai profité de quelques sites à concevoir ces derniers mois pour faire du statique… et vous proposer un petit retour d’expérience.

Terrain de jeu

Mon terrain de jeu s’est composé essentiellement de:

• Le site de vente en ligne bilingue Retro.02

  Réalisé avec une version patchée de Poole.

• Le nouveau site des Chemins de Traverse

  Réalisé en duo avec Nicolas Friedli; se base sur une combinaison flask/frozen-flask avec un backend ad hoc se basant sur des fichiers en yaml et rst.

Vraies et fausses évidences

Quand on pense site statique, on pense presque immédiatement

• facilité de déploiement (il suffit souvent de copier les fichiers sur le serveur!)
• rapidité du site
• un hébergeur “bas de gamme” suffit largement

Ces avantages sont bien réels, mais finalement assez anecdotiques. On passe normalement plus de temps à concevoir et tenir à jour le site qu’à le déployer, on peut faire des sites dynamiques très rapides, et le prix de l’hébergement a bien chuté ces dernières années.

On pourrait aussi penser que:

• Un site statique est limité à l’affichage de quelques informations simples.

  FAUX: On peut sans problème faire un site à la structure complexe, composé de plusieurs dizaines ou centaines de pages. Et en externalisant les fonctionnalités les plus “dynamiques” (panier paypal, commentaires Disqus, recherche et/ou statistiques Google, …) on peut obtenir des sites très complexes en gardant un coeur statique.

• Un site statique (techniquement) ne pourra pas être dynamique (dans son contenu)

  FAUX: Ceux qui ont vu comme moi Reinout van Rees publier ses notes de conférences presque en temps réel sur son blog statique (mises en forme, avec images, code highlighting, tags, commentaires, …) se rendront compte de l’efficacité que peut atteindre un tel système.

• Un site statique doit être maintenu par une seule personne, puisqu’il est géré localement sur une machine

  VRAI OU FAUX? Le grand plus des CMS a été de bien séparer les rôles de responsable technique, rédacteur, … et de leur donner un moyen d’interagir harmonieusement (l’interface d’administration du site). Doit-on renoncer à tout ça en revenant à un site statique? Pour répondre à cette question, nous allons introduire un nouvel acteur…

La vraie surprise (en tout cas pour moi…)

En concevant un site statique moderne, on va écrire un peu de code, des templates html, du css et des fichiers de contenu. Comme on n’est pas des sauvages, on va organiser tout ça joliment dans des répertoires et sous-répertoires et utiliser un système de gestion de versions.

Et ce que je n’avais pas vu venir, c’est que cet outil va prendre la place de l’interface d’administration du CMS, mais en bien mieux:

• Si on doit faire des changements interdépendants sur plusieurs pages, on fait une nouvelle branche, on change tout ce qu’on veut, on teste, on merge et on déploie. Le site déployé est dans un état cohérent à tout moment.

  La plupart des CMS forcent à changer les pages une à une, d’où un site dans un état incohérent pendant une période de quelques minutes à quelques heures.

• On peut travailler à plusieurs de manière concurrente sur le site. Les éventuels conflits seront gérés correctement.

  Je ne suis pas un expert, mais combien de CMS gèrent-ils cette situation? Il me semble que la plupart du temps, si deux personnes modifient la même page en même temps et soumettent leurs modifications, celles de la première personne seront écrasées par celles de la seconde…

• On “versionne” le code du site, sa présentation et son contenu dans le même dépôt. Retrouver une version antérieure du site revient essentiellement à un checkout.

  Essayez de récupérer votre site Wordpress d’il y a deux mois: rétablir une ancienne version de WP, les anciennes versions des plugins, la base de données, les photos et autres fichiers de medias, …

• La plupart des CMS proposent des workflows relativement élémentaires; avec un système de gestion de version (en ajoutant au besoin un peu de porcelaine), les rêves les plus fous en termes de workflow deviennent possibles! (gestion de plusieurs version du site en parallèle, avec passages d’informations de l’une à l’autre, etc.)

On pourrait continuer longtemps, mais pour moi une constatation s’impose: après quelques mois déjà, je commence à me sentir à l’étroit dans les interfaces des CMS que j’utilise, et la souplesse d’un git me manque…

En plus de ces avantages, j’ai constaté une autre chose: en générant localement un site statique, j’hésite beaucoup moins à expérimenter avec le code et le contenu du site: je n’ai pas peur des plantages, failles de sécurités et autres problèmes sur le serveur… et je sais que je pourrai très facilement revenir en arrière si nécessaire!

Et l’ergonomie?

Aucun doute, l’édition locale de fichiers en langage de balisage léger avec gestion de version demande un peu d’apprentissage avant de devenir efficace.

Plus que l’utilisation de l’éditeur WYSIWYG de Wordpress en tout cas… mais est-ce vraiment plus difficile à prendre en main que l’interface d’administration d’un Typo3? Ça reste à prouver…

De plus, les systèmes de gestion de versions sont actuellement optimisés pour l’utilisation par des développeurs. Des outils comme Github montrent ce qu’il est possible de faire dans ce cas.

Mais si on réfléchissait à la mise en place d’un système de gestion de versions (ou d’une interface vers un système existant - à la github) optimisé pour l’entretien et la rédaction d’un site web, on pourrait probablement baisser le seuil d’entrée de plusieurs crans…

Ma conclusion (du moment)

Dans certains cas, le dynamique reste incontournable:

• Vous faites un site à haut niveau d’interactivité: forum, réseau social, …

• Les pages potentielles de votre site présentent une explosion combinatoire:

  Si vous faites un site de réservation en ligne d’hôtel, il n’est pas raisonnable de générer une page statique par combinaison date de départ/date d’arrivée/lieu/catégorie de prix/…

• …

Mais pour de nombreux sites perso ou institutionnels, il me semble que le site statique tel que décrit ci-dessus est une alternative à prendre très sérieusement en considération… bien qu’elle manque encore un peu d’outillage la mettant à la portée d’un plus grand public.