CMS classique, flatfile, site statique, ces termes sont limpides pour les gens du métier mais pour la plupart des utilisateurs, ce n'est pas très parlant. Ce petit billet vise à leur donner quelques précisions.
Aux premières lueurs du web, les sites étaient développés "à la main" via un éditeur de texte en utilisant le langage de présentation HTML. Puis, CSS pour la mise en forme et des langages de scripts comme JavaScript ont permis d'obtenir une certaine interactivité.
Des logiciels tels que Frontpage ou Dreamweaver (pour les dinosaures) ont permis de ne plus écrire directement en HTML mais d'utiliser un éditeur graphique pour générer le code (pas forcément toujours très propre par ailleurs).
Les puristes dont je fais partie ont toujours préféré ecrire le code avec leurs petits doigts mais ces premiers outils ont ouvert la création de sites web à un public moins averti. Il faut dire qu'avec un site de plusieurs dizaines de pages, retoucher l'ensemble des pages à chaque fois qu'on voulait changer quelque chose dans un menu, ce n'était pas spécialement marrant (les "iframe" pouvaient par ailleurs régler ce problème, j'en vois déjà certains sourire à la simple évocation de l'iframe).
A chaque fois qu'on voulait mettre à jour son site web, il fallait sortir son client FTP (File Transfer Protocol) pour transférer les pages web chez son hébergeur. Je me souviens même qu'avant d'avoir un accès FTP à mon hébergeur, je lui envoyais par email un zip de mon site à chaque fois que je le faisais évoluer.
Mais, très vite, on a voulu faire des sites web avec des formulaires de contact, pouvoir afficher des informations disponibles dans des bases de données, discuter avec des services distants. CGI (Common Gateway Interface) permettait de développer du code dans n'importe quel langage (en C par exemple), de communiquer avec ces programmes depuis une page web pour aller beaucoup plus loin avec un simple site web. Mais, ces langages n'étaient pas développés à l'origine pour le web. Ce n'était pas si simple de brancher une base de données à un site web par exemple.
Des langages beaucoup plus spécialisés sont apparus dont un certain PHP, aujourd'hui encore un langage largement utilisé sur le web.
Celui-ci (même si on peut réaliser toutes sortes d'outils avec lui) a d'abord été conçu pour le web embarquant des fonctionnalités très utiles. Avec PHP, il devenait possible de communiquer avec une base de données par exemple, directement en ajoutant du code dans les pages web sans avoir besoin de faire appel à un programme externe avec CGI. C'était une véritable petite révolution. Même si PHP est souvent décriré aujourd'hui, je remercie vivement Rasmus Lerdorf pour cette belle création que j'utilise quotidiennement. Je reste fidèle à PHP, un langage qui a su évoluer avec le temps.
Avec PHP, réaliser un site web récupérant des informations dans une base de données, le permettant alors d'évoluer à l'infini dynamiquement sans avoir besoin de modifier les pages à chaque fois, une boutique en ligne, est devenu bien plus facile.
Ces langages permettent d'aller très loin et de réaliser de véritables logiciels (mais c'est une autre histoire).
Pour concevoir un blog, un site complexe, il fallait encore réaliser beaucoup de choses à la main.
C'est là que les CMS (Content Management System ou Système de gestion de contenu) ont commencé à faire leur apparition. Je pense à Dotclear, Joomla, SPIP, WordPress.
Ces applications, développés en PHP pour ces 3 exemples (mais il existe des CMS développés dans de nombreux autres langages), ont été pensées de manière générique pour servir de socle à la création de sites web.
L'idée générale est de séparer la structure du site (le template, le thème) de son contenu. Une fois la structure du site conçue (en développant un thème sur-mesure, en achetant un thème générique), une interface graphique permet d'ajouter facilement des pages, des images, des articles de blog (etc ...) sur son site sans toucher à la partie technique.
L'utilisateur final peut donc faire vivre son site tout seul sans avoir besoin de connaissance technique poussée. Il doit simplement être à l'aise avec l'utilisation d'un navigateur web.
Un véritable tournant est né avec l'utilisation des CMS. Bien sûr, il était déjà possible de créer des sites administrables par l'utilisateur final mais ça coûtait relativement cher. Avec ces CMS "génériques", souvent des logiciels libres, tout a changé.
Des CMS plus spécialisés ont aussi été inventés pour la réalisation de boutiques en ligne par exemple (Os Commerce puis Plici, Magento, Thelia, Prestashop) ainsi que des plugins (extensions) pour CMS classiques afin d'ajouter une composante e-commerce à un CMS standard (Woocommerce pour WordPress par exemple).
Aujourd'hui encore, des sites complexes sont réalisés "à la main" en utilisant des frameworks (un cadre de travail préconçu) pour gagner du temps. Mais, pour la réalisation de sites vitrines, de blogs, de boutiques en ligne, les CMS sont devenus majoritaires.
Selon W3Techs, WordPress fait tourner aujourd'hui pas loin de 43% des sites web. Enorme non ?
Les agences web s'appuient largement sur les CMS pour réaliser les sites de leurs clients.
La plupart de ces CMS utilisent une base de données pour stocker les articles, les pages.
Mais, une base de données est-elle vraiment toujours nécessaire ? Pour un site de taille moyenne, pas forcément.
Sont nés alors les CMS "flatfile" (Grav, par exemple). Au lieu d'utiliser une base de données, les informations sont conservées dans de simples fichiers.
C'est performant et avec un bon système de cache, encore plus performant. Bien entendu, ceci ne convient pas très bien à des sites complexes nécessitant des moteurs de recherche poussés, énormément de données à stocker, à filtrer mais beaucoup de sites n'ont pas besoin de tout ça. D'ailleurs avant l'arrivée des CMS "classiques", des développements "maison" utilisaient déjà ce genre de techniques, très simples.
Depuis un moment, on observe une remise en question du tout CMS pour différentes raisons.
Souvent, on obtient des sites relativement lourds quand ils n'ont pas été optimisés (trop de plugins, pas de cache systématique).
Il n'est pas rare de trouver un site lent au chargement. Beaucoup de sites web tournent sur des serveurs mutualisés, c'est à dire à côté de plein d'autres sites web (et c'est très bien). En fonction de l'offre d'hébergement, certains sites trop gourmands n'obtiennent pas des performances correctes.
La part du numérique dans la catastrophe environnementale que l'on vit est enfin pris en compte et nombreux sont ceux qui se posent des questions (j'en fais partie) et souhaitent réduire son empreinte. Comment ? En limitant la fabrication de matériel. Si on peut faire tourner davantage de sites sur un même serveur alors moins de machines seront nécessaires pour faire tourner le web.
A-t-on toujours besoin d'un CMS bourré de plugins ? D'un CMS tout court ? D'un système dynamique ?
La réponse est clairement non. Ça ne veut pas dire qu'il ne faut jamais les utiliser car ils sont très utiles mais dans certains cas, ils ne le sont pas.
Bien entendu, les ressources matérielles nécesaires pour faire tourner un site basé sur un CMS et un site statique conçu en HTML comme je l'expliquais au début de ce billet n'ont absolument rien à voir. A l'échelle d'un site web, c'est probablement négligeable mais à l'échelle du web entier, c'est énorme.
Nous avons pris l'habitude d'utiliser des CMS sans se poser de question. Aujourd'hui, ça change et c'est très bien.
Un site vitrine présentant les activités d'une entreprise, un blog, pourrait tout à fait devenir statique.
Est-ce que cela veut dire revenir à des outils à la Frontpage de la fin des années 90 ou développer tout à la main ?
On pourrait mais ce n'est pas obligatoire. Si le site à créer ne dispose que d'une ou deux pages, pourquoi pas.
Mais, les CMS ont mis en avant quelque chose de très important : la séparation de la structure du site (le fameux template, l'aspect général de chaque page) de son contenu.
Disposer d'un outil permettant de mettre en place des templates d'un côté avec des règles complexes, de stocker du contenu de l'autre, puis capable de transformer le tout en une suite de page HTML brute, ce serait bien pratique non ?
C'est ce que des outils comme Hugo, Jekyll ou Pelican permettent de faire (il en existe beaucoup d'autres).
Je vais vous donner un exemple précis. Vous avez un blog avec une page principale qui contient le dernier article du blog et une page qui liste les articles du plus récent au plus ancien. Le template de la page principale du blog contient une règle expliquant que le dernier article du blog doit s'afficher. Sur la page du listing, une règle définie qu'un lien vers l'ensemble des articles doit s'afficher dans l'ordre décroissant de la date de l'article.
Une fois ce template en place, vous décidez d'ajouter un nouvel article dans la zone dédiée au contenu.
Lorsque que la génération du site sera lancée, les pages seront intelligement créées en fonction des ces règles.
Moi non plus, je n'ai pas envie de modifier à la main X pages à chaque fois que j'ajoute un article sur mon blog. On est donc relativement proche de ce qu'on peut faire avec un CMS mais c'est beaucoup plus léger.
Bien entendu, ce n'est pas la solution ultime pour réaliser tous les sites web. C'est une solution complémentaire parfois plus intéressante mais pas toujours.
J'ai moi aussi décidé de m'intéresser de prêt aux générateurs de sites statiques et d'en créer un pour générer le site web que vous lisez actuellement. Il se nomme Fruga.
En utilisant un CMS quand c'est nécessaire, une base de données ou pas, et en revenant vers le site statique quand c'est possible alors nous irons probablement vers un web plus raisonné.
Je termine l'écriture de ce billet. Je vais sauvegarder celui-ci puis lancer deux commandes sur mon ordinateur :
php fruga.php generate yoan
php fruga.php deploy yoan alwaysdata
Ce billet sera alors accessible sur mon site, le classement respecté sur la page qui liste les articles et le plus vieil article de cette page aura été déplacé sur la page d'archive.
Cet article sera une simple page HTML brute dans un répertoire sur un des serveurs de mon hébergeur.
Et ... c'est largement suffisant.