La plume d’oie, le site web statique, le site web dynamique et le CMS

C’est un article d’Anthony que j’ai vu passer dans G+ qui m’a sortie de ma torpeur automnale (en fait j’ai eu plein d’embêtements, à commencer par un crash de disque dur, et je bosse comme une dingue pour rattraper), parce qu’il prétend qu’un site web statique et meilleur qu’un site web dynamique, et que ses arguments peuvent provoquer une énorme confusion entre plusieurs notions.

Pire encore, son article est “illustré” par une vidéo d’une intervention de Clément Delafargue aux Human Talks à Angers, qui contredit quasiment entièrement l'interprétation faite par Anthony, tout en étant, aussi, très discutable sur certains points.

A mon tour, donc, de vous convaincre qu’un site web dynamique est meilleur qu’un site web statique, sachant que pour cela, je vais commencer par expliquer “dekoiquoncause” aux non-spécialistes, puis dans un second article reprendre un certain nombre d’éléments de l’intervention très technique de Clément Delafargue, pour finir par essayer de faire une véritable analyse des avantages et des inconvénients de chaque solution. Il y aura donc trois articles, pour éviter de faire des énormes romans à chaque fois !

En résumé, dans son article, Anthony dit

Un site statique, c’est mieux parce qu’on fait ce qu’on veut, on n’est pas contraint par le CMS, on peut réellement l’optimiser, à la différence d’un CMS, le client peut le modifier, il est plus sûr, plus simple à administrer (sans mise à jour technique), sans base de données, et sur un hébergement moins onéreux.

L’exemple donné en final, via la copie d’écran : un site réalisé par SitinWeb, les Gîtes de la Patinerie. Ça tombe bien, le site d’hébergement touristique, c’est mon dada !

Quelques définitions pour comprendre comment on fait un site web.

Un site statique : des pages envoyées directement, sans traitement intermédiaire.

Un site web est un ensemble de pages qui sont “basiquement” des fichiers textes avec une extension particulière (.html au départ), accessibles à partir d’un nom de domaine donné. Ces pages comportent du code, écrit dans un langage qui peut être compris par le navigateur (Firefox, Internet Explorer, le regretté Netscape…) , éventuellement complété par du “style” pour mettre des couleurs, des espacements, des tailles de caractères. Ce style peut être directement dans la page html, ou appelé dans un fichier écrit avec un autre type de code, le css. On peut aussi y rajouter des sortes de macros, écrites dans un troisième langage, javascript, on a beaucoup fait ça a une époque pour changer la taille des souris..

C’est tout ce dont un navigateur a besoin, il va interpréter les différents codes et produire, selon la logique qui lui est propre, la page que vous voyez.

On parle de côté “client“, parce que le navigateur reçoit les pages qui sont envoyées par le serveur (l’ordinateur sur lequel elles sont stockées). Le navigateur ne sait que faire cela, il ne peut pas interpréter autre chose qu’une combinaison de html, css et javascript : il reçoit des pages, il les affiche. Il ne peut pas se permettre de les modifier, c’est statique. Et toutes les pages se trouvent, toutes prêtes, sur le serveur.

Bon, autant vous dire que dès que le site fait plus de 10 pages, le copié-collé des éléments répétitifs comme les menus, ça commence à profondément ennuyer le développeur web, et à tenir de la place sur le serveur…

Bref, arrive le site dynamique

On rajoute une couche de technologie, mais côté serveur. Au lieu de simplement roupiller à indiquer où sont les pages, le serveur va faire de l’assemblage, il se dynamise : je te prends un fichier qui contient les menus, et je te le mets au milieu de la page. Comme ça, hop, pas besoin de recopier le même bout de code partout, et quand on veut mettre à jour c’est bien plus simple, un seul fichier à changer, sans faire d’erreur.

Les langages de programmation principaux : asp pour les serveurs Windows, php pour les serveurs Apache et Windows, et puis des langages plus élaborés, Ruby, Python… mais principalement, php.

Le serveur génère la page html (et les css et les javascripts) qui est lue par le navigateur. Pas plus qu’avant, le navigateur ne peut changer le contenu de la page.

A partir de là, tout est possible : puisqu’il veut être dynamique, le serveur va travailler : il va afficher une heure, un message de bienvenue personnalisé grâce à un petit bout de code laissé sur votre PC (le cookie), afficher des prix, prendre des commandes, vous permettre de laisser des messages, de jouer…

Le CMS, la base de données, l’interactivité

Le travail du serveur, dans le cadre d’un site dynamique, consiste à comprendre quel contenu l’internaute veut afficher (généralement à partir de l’url : example.com/contact.php est un contenu différent de example.com/aurevoir.php), et envoyer ce contenu en fonction de règles définies par les programmes.

C’est donc, même de façon très rudimentaire, un système de gestion de contenu, ou Content Management System.

Mon premier site dynamique avec des fichiers pour chaque contenu, je créais la page dans un fichier texte, en html et en php. Ensuite, mon “CMS” déterminait la page à afficher, en fonction de la page, il choisissait le menu, les pubs à afficher, les albums photos. Rien n’était stocké en base de données : j’avais un gros fichier texte, qui me listait toutes les pages avec leurs caractéristiques, des fichiers avec les contenus, et des fichiers avec les modèles de page et d’autres avec les programmes.

Il est toujours en ligne, et je traine des pieds pour le mettre à jour, on verra pourquoi… Mais un CMS peut très bien être construit sans utiliser de base de données, contrairement à ce que dit l’article. C’est juste “plus simple” de faire une base de données, parce que la base de données, généralement MySQL, est livrée avec une interface toute prête avec php, qu’elle a des mécanismes pour gérer ce qu’on fait quand deux utilisateurs différents veulent modifier le même contenu au même instant, etc…

Mais il y a des CMS excellents qui fonctionnent sans bases de données : CMS Made Simple (en), par exemple. L’avantage ? Ca tourne facilement sur des petits hébergements (il y a eu une époque ou Mysql était une option payante), et sur un petit site, la performance peut être excellente.

Et si vous allez sur mon premier site, celui de l’agence de voyage de mon mari, vous verrez que, en dehors du blog, tout le site est fait, certes, sur un CMS, mais un CMS maison,créé sur mesure, avec un template sur mesure, unique… (bon, c’était 2007… de l’indulgence !). Une partie du contenu est géré à partir de fichiers, une autre (les circuits) est gérée en base de données directement (mais sans interface admin).

Bref, site dynamique n’est pas synonyme de site “pas sur mesure”, et CMS n’est pas synonyme de WordPress, Joomla, Drupal ou autre, ni de template standard, ni de site qu’on ne peut pas modifier…

Qui fait des sites webs, et comment ? Développeur, intégrateur, ou amateur

C’est cela, le point qui m’a vraiment fait réagir dans cet article : quand je vois écrit

le développeur web est libre d’apporter les modifications qu’il souhaite dans le code source directement, pas d’intermédiaire avec un plugin ou un module développé par une personne extérieure à votre site internet.

j’ai envie, au choix, de pleurer ou d’éclater de rire, tellement c’est typique d’une vision totalement fausse du travail qui consiste à créer un site dynamique, entre autres sous WordPress.

Pour simplifier, il y a ceux qui n’y connaissent rien, les intégrateurs et les développeurs.

Celui qui n’y connait rien d’abord

C’est souvent un particulier, ou une PME qui pense ne pas avoir les moyens ou les besoins de passer par une agence. Effectivement, celui là va prendre des plugins, des thèmes, ne pas savoir les modifier, faire une page blanche dans son site quand il essaye de changer une déclaration css, On en voit beaucoup sur le forum de support.

Ca peut aussi être le développeur web qui n’a pas pris le temps de vraiment s’intéresser au CMS, qui fait donc, en réalité, les mêmes conneries que celui qui n’y connait rien. Exemples typiques :

• la déclaration de Clément Delafargue dans la vidéo, qui explique sans sourciller que
  

  dès qu’on a deux – trois plugins on se retrouve avec une centaine de requêtes, et donc que la base de données est super lourde.

  (Vu le profil, c’est de la mauvaise foi ou une méconnaissance de l’outil…ça peut être comme ça, mais pas quand on connait bien).

• Ou l’agence qui construit un site Drupal avec Views, sans corriger les requêtes générées…

La faute n’est pas au CMS, mais à l’utilisateur.

Ma vision de mon métier, c’est

tu veux un bon site ? on définit ton besoin, et quel que soit le CMS, on te fait autant que possible tes plugins spécifiques qui utilisent l’API pour éviter de te surcharger de fonctions inutiles, et ça prend un peu plus de un jour ou deux

L’intégrateur, lui, est un peu codeur, mais pas trop.

Le boulot de l’intégrateur est de mettre ensemble des éléments qui lui sont fournis, et de les rendre présentables. Généralement, il code peu la génération des pages sur le serveur (en php), c’est souvent un excellent spécialiste css et html, il peut aussi être très fort côté accessibilité, ergonomie… Dans une grosse agence, il travaille main dans la main avec les développeurs et les graphistes.

Dans une petite agence, “mono”, en free-lance, il va faire le travail de celui qui n’y connait rien, mettre ensemble des thèmes et des plugins, modifier le graphisme, mais en y connaissant quelque chose :

• il passe du temps sur les forums, pour identifier les bon plugins
• il est abonné à des listes sur la sécurité, pour savoir quel plugin ou quel thème peut être dangereux
• il a sélectionné “ses” plugins et ses thèmes, qui fonctionnent bien ensemble, il teste avant de faire les mises à jour

Le développeur met les mains dans le cambouis

Il a les compétences complémentaires à celles de l’intégrateur :

• il sait modifier un css, mais il n’a sans doute pas les compétences pour bâtir de A à Z un css léger, accessible, responsive (je parle des vrais css, où on joue sur les sélecteurs parents et enfants, au lieu de rajouter des lignes de code inutiles pour un cas précis..)
• il maîtrise l’API de son CMS, php, mysql,
• il sait bâtir des requêtes optimisées,
• il vérifie les inputs et les outputs pour ne pas se faire hacker,
• il sait faire ses propres plugins qui correspondent exactement aux besoins de ses clients
• il modifie les thèmes pour les optimiser pour le seo,
• il rajoute des descriptions différentes sur les pages d’archives pour éviter le duplicate content,
• il passe une partie des menus en javascript pour concilier le référencement, le marketing et l’ergonomie

Quand il intervient sur les forums, il passe son temps à dire “mais pourquoi tu veux utiliser un plugin pour mettre ton code analytics alors que c’est si simple de le rajouter toi même dans ton thème” ? (C’est tout moi, ça…)

Alors, oui, c’est exact, je ne modifie pas la balise HTML dans le fichier.html, je vais la modifier dans un template ou dans une fonction. Et vous savez quoi ? C’est beaucoup mieux comme ça !

Les CMS, il n’y a pas que WordPress

WordPress – qui a commencé comme un blog – est loin d’être le seul CMS, même s’il est désormais le plus utilisé (en nombre d’installations).

Le site CMSMatrix recense plus de 1.200 CMS ! Si un certain nombre d’entre eux sont Open Source et gratuits, d’autres sont propriétaires et / ou payants.

Dire qu’un CMS présente un risque de sécurité parce que tous le monde a accès aux sources, c’est confondre un outil (un CMS) et un type de licence (l’Open Source).

Confondre CMS et WordPress, c’est aussi ne pas avoir une vision claire des choses. C’est souvent l’attitude d’ingénieurs de formation, qui méprisent le côté accessible de WordPress ou Joomla et consorts. Si c’est simple, c’est nul. Le geek de base…

(Je laisse de côté l'argument important de la sécurité, qui vaut un long paragraphe à lui tout seul, trop long pour cet article).

Un site plus long à créer qu’un site dynamique

J’ai cherché dans mes archives… je peux vous montrer des sites que j’ai faits sur mon mini-cms personnel, parce que le client n’a jamais voulu payer une migration vers quelque chose de mieux, mais je n’ai plus en ligne un seul site statique. (Et pour être honnête, j’en ai fait deux seulement. A la fin du deuxième, je me suis regardée dans l’écran du PC, et je me suis dit “ma grande, il est temps de découvrir le php”).

Parce que créer un site statique de plus de cinq pages, c’est pénible, c’est lent, bref c’est tout comme écrire à la plume d’oie.

Le site statique a, au mieux, des parties qui sont des modèles, dans l’outil de développement. Mais chaque page est un fichier, qu’il faut modifier à la main, si par hasard :

• on s’est trompé dans la définition des zones, “uniques” ou répétitives
• il faut modifier un conteneur

Si par hasard on modifie un des “modèles inclus”, il faut regénérer toutes les pages webs, et les réenvoyer sur le serveur, via FTP.

Si on a beaucoup de pages, on risque les micro-coupures, les erreurs lors du transfert FTP.

Par ailleurs, le contenu de la page s’écrira “en code”, notamment les titres, les balises métas (je vous rappelle, on est dans un vrai site statique, pas un CMS sans base de données !). A chaque fois, la bête erreur de frappe est possible. Elle sera alors unique, sur une page…

Bref, on est aux antipodes de l’informatique : éviter les tâches répétitives.

Quel site n’a pas besoin de mise à jour ?

Voici quelques bonnes raisons de faire des mises à jour :

• la législation évolue (déclaration CNIL, cookies)
• le référencement évolue (quand je revois mes liens toutes pages en footer, mon Dieu que j’ai honte)
• les prix changent (on va y revenir)
• le client fait une promo pour une période donnée
• le client a été interviewé à la télé, il veut en parler sur son site
• le client rajoute un service supplémentaire…

L’exemple de la mise à jour des prix

Si vous prenez encore un autre site d’hébergement touristique, un petit hôtel à Merzouga, vous verrez que les mêmes prix sont mentionnés plusieurs fois :

• en page d’accueil
• dans la page sur les chambres
• dans le récap des tarifs

Et en français, en anglais, bientôt en espagnol et en italien.

On n’est pas dans le cadre d’une boutique en ligne, mais le prix est important. Sur le site statique d’Anthony, je ne le vois pas.

Or ce client là m’a fait changer plusieurs fois ses prix.

La première fois, il avait un site statique. J’ai duré que “plus jamais”.

Mon minicms inclut donc une table de gestion des tarifs, multi-prestation, multi-groupe de prestations, multi-saison. Comme je suis une grosse feignasse, il était hors de question que je recode à chaque fois ma requête “analyse croisée, j’ai donc passé une journée à digérer ça… aujourd’hui, c’est exactement la même fonction qui est utilisée pour ce mini-cms et pour cette page de tarif dans un site d’hôtel et celle là, pour une agence de location de voiture, tous les deux faits sur WordPress.

La seule différence ? Dans WordPress, je n’ai pas eu à me soucier de créer l’interface d’admin, et le client peut changer ses prix lui-même, sans que j’ai à développer un ensemble lourd avec les contrôles de qualité de données. De plus, cette interface est la même s’il souhaite éventuellement faire une annonce en page d’accueil, changer les éléments en promo.

Les mises à jour imposées par l’extérieur

Les deux sites que j’ai faits “avant WordPress” n’ont pas bougé parce que les clients ne veulent pas payer une évolution. Ils ont été faits en 2007-2008, ils sont adaptés aux résolutions d’écrans de l’époque, pas responsive.

D’autres ont été passés sur WordPress, ce qui a impliqué une resaisie des textes, des metas, mais qui a permis aussi, entretemps, de changer de template extrêmement facilement, les contenus étant totalement séparés du template.

Là encore gain de temps.

L’absence de base de données et le coût de l’hébergement

C’était un argument tout à fait recevable il y a quelques années. Désormais…si une activité professionnelle a vraiment un problème de rentabilité à payer les presque 3 € par mois nécessaires pour un hébergement entrée de gamme chez OVH qui sera suffisant pour un site dynamique de quelques dizaines de pages, je lui conseillerais de ne même pas avoir de site web.

Le véritable coût d’un site statique ?

Des éléments impossibles à mettre en place, comme un formulaire de contact qui permet de garder en mémoire les messages, les adresses mails, ou un livre d’or.

Des mises à jour difficiles, parce que faites “dans le code”. Donc, contrairement à ce que dit Anthony, ce n’est pas le client qui met à jour, mais le développeur. Et l’heure de développeur, ça coute… avec deux mises à jour dans l’année, ça coute plus cher que l’hébergement bas de gamme d’OVH.

Qui fait encore réellement des sites totalement statiques ?

Si une agence vous dit “à ma bonne dame, moi je fais du site statique sans aucun CMS”, vous pouvez vous dire que c’est au choix :

• quelqu’un qui a arrêté sa compétence informatique aux années 2002-2003
• quelqu’un qui utilise encore Dreamweaver avec ses templates ou qui copie-colle des structures
• quelqu’un qui utilise en réalité un outil pour générer son site, un gestionnaire de contenu qui va générer des pages HTML, et qui vous parle de site statique pour simplifier
• … ou pire, j’en ai vu aussi, qui se le garde pour lui pour vous tenir prisonnier

Bref, vous risquez d’être face à un professionnel du transport de marchandises qui se limite aux carrioles à cheval des Amish ! S’il arrive à vous convaincre, la prochaine étape, c’est d’abandonner votre Smartphone, de ressortir la plume d’oie et l’encrier pour envoyer de vos nouvelles, au lieu de textos… Mais attention, l’encre ça tache, la plume il faut la tailler, et il n’y a pas de crtl+z . Alors, discutez-bien avec lui, et soyez sur et certain que vous ne voudrez aucune mise à jour avant de signer. Si c’est le cas, effectivement, vous aurez un site léger et économique. Si ce n’est pas le cas, les problèmes arriveront !!

(La photo des plumes d’oie et de l’encre est, quant à elle, une photo sous licence CC BY de Charles Stanford)