Refonte d’un site de gîte : 27 Ko, zéro cookie, zéro WordPress

Refonte d’un site de gîte : 27 Ko, zéro cookie, zéro WordPress

Il y a un moment inconfortable dans la vie d’un professionnel de WordPress : celui où l’on regarde un projet et où l’on se dit que WordPress n’est pas la bonne réponse.

L’ancienne version du site
La nouvelle version optimisée

C’est arrivé avec le site des chambres d’hôtes et du gîte de Aussé, à Saint-Mars-sur-la-Futaie, en Mayenne. Cinq chambres d’hôtes, un gîte de quatorze personnes, une propriétaire qui accueille elle-même ses visiteurs. Le site existant datait d’un logiciel de création vieillissant, six pages, une ergonomie d’un autre temps.

Le résultat de la refonte tient en trois chiffres : 27 Ko de code, aucun cookie, 100/100 sur Lighthouse. Voici le raisonnement qui y mène, et surtout les limites de cette approche.

Poser le besoin avant de choisir l’outil

La question à se poser n’est pas « quel CMS ? » mais « qui va modifier quoi, et à quelle fréquence ? ».

Réponse honnête pour ce gîte : personne, presque jamais. Les tarifs bougent une fois par an. Les photos changent quand il y a de nouvelles photos, c’est-à-dire rarement. Il n’y a pas de blog, pas de catalogue, pas de réservation en ligne : la propriétaire préfère décrocher son téléphone, et c’est un choix assumé qui fait partie de son accueil.

Face à ce besoin, installer WordPress revient à livrer une chaudière industrielle pour chauffer une chambre. Il faudrait ensuite la maintenir : mises à jour du cœur, des extensions, du thème, veille de sécurité, sauvegardes. Pour un site dont le contenu bouge une fois par an, cette charge n’a aucune contrepartie.

Nous sommes donc partis sur du HTML, du CSS et du JavaScript natifs. Une seule page, structurée en sections, avec une navigation par ancres.

Ce que la sobriété donne concrètement

Les chiffres, mesurés sur le site en production :

IndicateurValeur
Code total (HTML + CSS + JS, compressé)27 Ko
Requêtes au premier écran6
Appels à des services tiers0
Cookies déposés0
Lighthouse (ordinateur)100 / 100 / 100 / 100
LCP (GTmetrix, Paris)417 ms
CLS0
Total Blocking Time0 ms

Un CLS à zéro n’a rien de magique : chaque image porte ses attributs width et height, donc le navigateur réserve la place avant même de télécharger le fichier. Rien ne saute pendant le chargement. C’est du travail élémentaire, mais c’est exactement ce que les constructeurs de pages font rarement.

Le Total Blocking Time à zéro s’explique tout aussi simplement : il n’y a pas de framework à interpréter. Le JavaScript du site tient en 3 Ko compressés et ne gère que quatre choses : le menu mobile, la galerie photo, un filtre et l’apparition au défilement.

Les trois décisions qui font la différence

Les images, qui pèsent 99 % du poids réel

Un site de gîte, c’est des photos. Trente-cinq, en l’occurrence, déclinées chacune en trois largeurs et trois formats.

Chaque image est servie via une balise <picture> qui propose l’AVIF, puis le WebP, puis le JPEG. Le navigateur retient le premier format qu’il sait décoder et ne télécharge que celui-là. Aucune requête gaspillée, aucune configuration serveur, aucune redirection : tout se joue côté client, dans le HTML.

L’écart est net. Sur l’ensemble des photos : 15 Mo en JPEG, 12 Mo en WebP, 6 Mo en AVIF. L’image d’en-tête, celle qui détermine le LCP, passe de 387 Ko en JPEG à 187 Ko en AVIF.

À cela s’ajoute le loading="lazy" : au premier écran, aucune des trente-deux vignettes de la galerie n’est chargée. Une seule image part sur le réseau, celle de l’en-tête.

Aucun cookie, et ce n’est pas un slogan

Pas de bandeau de consentement sur ce site. Non pas parce qu’on l’a caché, mais parce qu’il n’y a rien à consentir.

Pas d’outil de mesure d’audience. Pas de formulaire. Pas de compte utilisateur. Les polices sont auto-hébergées, en quatre fichiers woff2 découpés par plage Unicode, au lieu d’être appelées chez Google Fonts, ce qui enverrait l’adresse IP du visiteur à un tiers. La carte de localisation est un iframe OpenStreetMap, qui ne dépose pas de cookie publicitaire, là où une carte Google en dépose avant même le premier clic.

Résultat : un site conforme au RGPD par construction, et non par empilement de rustines. Et un visiteur qui accède à l’information immédiatement, sans avoir à congédier une fenêtre.

L’accessibilité comme contrainte de départ

Le 100/100 en accessibilité ne s’obtient pas à la fin, en corrigeant les alertes d’un outil. Il se décide au moment des choix de couleurs.

Chaque couple texte/fond du site a été calculé pour tenir les seuils WCAG AA. Ça a des conséquences concrètes : l’ocre de la marque, joli sur du crème, tombe à 1,2:1 sur une photo. Il a donc fallu une variante éclaircie pour les titres posés sur l’image d’en-tête. Trois nuances d’ocre coexistent dans la feuille de styles, chacune avec son usage et son ratio de contraste vérifié.

Même logique pour le reste : navigation au clavier complète, galerie ouvrable au clavier, focus visible partout, animations désactivées si le visiteur a réglé son système sur « mouvement réduit ».

Quand cette approche est une mauvaise idée

Il faut être clair, sinon cet article n’est qu’une publicité déguisée.

Un site statique est le bon choix ici parce que le contenu est stable et que la propriétaire ne souhaite pas éditer elle-même. Changez un seul de ces deux paramètres et le raisonnement s’inverse.

Dès qu’il faut publier régulièrement, gérer un catalogue, encaisser des réservations en ligne, faire intervenir plusieurs contributeurs, ou simplement laisser le client autonome sur ses textes, WordPress redevient la réponse évidente. Son écosystème, sa communauté et sa capacité à mettre l’édition entre les mains de quelqu’un qui n’est pas développeur n’ont pas d’équivalent à ce niveau de budget.

L’erreur n’est pas d’utiliser WordPress. L’erreur est de ne jamais se poser la question.

Ce que le client y gagne vraiment

Au-delà des scores, qui ne paient pas les factures, le bénéfice se mesure sur la durée.

Il n’y a rien à mettre à jour. Pas d’extension à surveiller, pas de version de PHP à suivre, pas de faille à combler dans l’urgence un dimanche soir. La surface d’attaque d’un site sans base de données ni code exécuté côté serveur est proche de zéro. Pour une propriétaire de gîte qui n’a ni prestataire à demeure ni budget de maintenance mensuel, c’est le vrai sujet.

L’hébergement, lui, se contente de servir des fichiers. Le site tournerait sur à peu près n’importe quoi.

Le résultat est visible sur les chambres d’hôtes et le gîte de Aussé : une page unique, une galerie filtrable entre les chambres d’hôtes et le gîte, une carte, et de quoi joindre la propriétaire en un geste.

Et pour ceux qui vont fouiller : il y a une vache cachée dans la page d’erreur 404. Elle traverse l’écran en vingt-six secondes. C’était le propos.

En résumé

La sobriété technique n’est pas une performance sportive ni une posture militante. C’est le résultat d’une question posée au bon moment : de quoi ce client a-t-il réellement besoin, et qu’est-ce qui lui coûtera cher dans trois ans ?

Ici, la réponse tenait en 27 Ko.


Thierry Pigot est président de WeAre[WP], agence spécialisée WordPress, consultant SEO et architecte technique.

Publié le Catégories Communication