Le même site, cinq fois

Le site de Taekwondo Meylan a toujours eu le même cahier des charges. Les horaires. Où s’entraîner. Qui enseigne. Comment s’inscrire. Les résultats du week-end et les photos du passage de grade. Un club fondé en 1995, entre 70 et 90 adhérents par saison, des bénévoles, pas de budget.

Je m’en occupe depuis 2001. En vingt-cinq ans, je l’ai construit cinq fois, avec quatre technologies différentes. Ce qui a changé, ce n’est jamais le besoin. C’est ce qu’il fallait savoir pour y répondre, et qui pouvait le faire.

2001 : du HTML à la main, sur chez.com

J’étais étudiant. Le site s’appelait tkdm.chez.com, sur l’hébergement gratuit de l’époque. Il est toujours en ligne, et je viens d’en relire le code.

La page d’accueil a un fond étoilé, une animation Flash de 400 pixels de côté qu’aucun navigateur ne sait plus lire, un compteur de visiteurs fourni par l’hébergeur, et la mention « Dernière mise à jour : 29/10/2003 ». Derrière, un jeu de cadres HTML : le sommaire à gauche sur 20 % de la largeur, en jaune souligné sur une texture violette, et le contenu à droite, sur un dragon en filigrane. Le sommaire dit : présentation du club, tarifs, news, calendrier, un peu d’histoire, un peu de cours, photos, forum, liens. Le texte d’accueil promet que le site « n’en est qu’à ses débuts » et « est destiné à s’améliorer au fil du temps ».

Chaque page était un fichier écrit à la main. Changer un horaire voulait dire l’ouvrir dans l’éditeur, corriger, renvoyer par FTP. C’était rudimentaire et ça marchait : rien à mettre à jour, rien à pirater, et ça chargeait instantanément. Le défaut était ailleurs. J’étais le seul à pouvoir le modifier. Et le sommaire de 2001 couvre déjà, presque rubrique pour rubrique, celui du site de 2026 : le forum est devenu un blog, les liens une boutique, le reste n’a pas bougé.

2010 : Joomla, un système de gestion de contenu

En 2010, j’étais secrétaire du club, webmaster historique et, dans les faits, le seul contributeur. Le site de 2001 avait fait son temps, et je l’ai refait sous Joomla : des articles, un calendrier, une mise en page gérée par un thème, plus de fichiers à retoucher à la main.

Cette capture date de janvier 2014. Le premier article de la page annonce déjà la version suivante.

Ce que j’ai gagné : publier une actualité sans ouvrir un éditeur de code. Ce que j’ai perdu : de la simplicité. Un CMS, c’est une base de données, un serveur PHP, des extensions, des mises à jour de sécurité qu’il faut suivre, et une mise en page qui dépend d’un thème que quelqu’un d’autre maintient. Le site est devenu quelque chose qu’il fallait entretenir, pas seulement écrire.

2014 : WordPress, même famille d’outils

En 2014, passage à WordPress, sur le même domaine. Même famille d’outils que Joomla, avec un écosystème plus large de thèmes et d’extensions.

Le compromis, lui, n’a pas bougé : une base de données, du PHP, des mises à jour à suivre. Et un seul contributeur, toujours le même.

2022 : WordPress encore, avec un thème premium et un constructeur de pages

En 2022, deux choses en même temps : l’hébergeur cessait son activité, et je voulais que d’autres puissent contribuer sans dépendre de moi. Migration chez OVH et refonte complète, toujours sous WordPress et toujours sous mon impulsion : nouvelle identité visuelle, nouveau logo. C’est le design que le site porte encore aujourd’hui, la version de 2026 l’a repris tel quel.

Avec un thème premium et un constructeur de pages : on glisse des blocs, on obtient une page qui a l’air professionnelle sans écrire de code. Un calendrier d’évènements en extension, des types de contenu pour les cours et pour l’équipe.

Pendant quatre ans, ça a suffi. Mais avec le recul, voilà ce qui s’est installé sans que personne le décide :

• Un seul administrateur. Moi, à nouveau, alors que le but était l’inverse. Le constructeur de pages est trop fragile pour qu’un bénévole y touche sans casser la mise en page.
• Des informations en double. Les horaires étaient écrits sur la page d’accueil et sur chaque fiche de cours. Modifier l’un sans l’autre rendait le site incohérent, et rien ne le signalait.
• Des liens qui périment. Les inscriptions passent par HelloAsso, et le lien change chaque saison. En août 2026, la page d’accueil pointait encore sur le formulaire 2025-2026. Personne ne l’avait vu.
• Des mises en page invisibles. Les pages du constructeur sont stockées sérialisées en base de données. On ne peut ni les relire, ni les versionner, ni les corriger en série.
• Pas de préproduction. On travaillait directement sur le site public, avec une sauvegarde de la base avant chaque opération. Ça tenait parce que j’étais seul et prudent.

Fin août 2026, à trois semaines de la rentrée, le thème n’était plus maintenu et le site montrait des signes de fatigue. La rentrée d’un club sportif, ce sont les trois semaines où le site sert vraiment. Il n’y avait pas de fenêtre pour le couper.

2026 : Astro, et le retour aux fichiers

Le 20 août, j’ai commencé la cinquième version. Le 21, elle était en production.

Le principe est presque celui de 2001 : le site est un ensemble de fichiers HTML servis tels quels, sans base de données ni PHP. La différence, c’est que ces fichiers sont générés à partir de texte, et que ce texte est vérifié avant chaque publication.

Le contenu est du texte versionné. Un fichier YAML pour les horaires, les tarifs, l’adresse, les liens HelloAsso, la saison en cours. Un fichier Markdown par membre de l’équipe (quatorze), par article, par évènement. Tout est dans Git. Chaque modification a un auteur, une date, et peut être annulée.

Le contenu est vérifié au build. Un schéma décrit ce qu’un cours, une fiche, un évènement doivent contenir. Un cours sans horaire, une fiche sans photo, un grade écrit « 3eme Dan » au lieu de « 3e dan », des coordonnées GPS hors de Meylan : le site refuse de se construire. Et surtout : un lien HelloAsso qui ne porte pas la saison déclarée fait échouer la publication. C’est ce contrôle qui manquait en août.

Les horaires ne sont écrits qu’une fois, sous forme structurée, et la phrase affichée sur la page d’accueil comme les heures d’ouverture transmises à Google en découlent. La duplication de WordPress ne peut plus se produire.

Les anciennes adresses continuent de fonctionner. 104 redirections exactes, plus 18 familles d’adresses rattrapées par leur préfixe, et un build qui refuse une redirection vers une page qui n’existe pas. Le tout est vérifié à chaque déploiement. Google n’a rien perdu.

Le site est plus rapide. La police est servie depuis le site plutôt que depuis Google Fonts : c’était la ressource bloquante la plus coûteuse, 0,8 seconde sur mobile, et chaque visite envoyait une adresse IP à Google sans consentement. Lighthouse mobile est passé de 94 à 99, le premier affichage de 2,5 à 0,9 seconde. L’image de partage, qui partait en 3,3 Mo dans chaque aperçu WhatsApp, fait maintenant 141 ko.

Le déploiement est automatique. Un push sur la branche principale construit le site dans GitHub Actions et l’envoie chez OVH, l’hébergeur du club. Le dépôt Git est la source de vérité. WordPress reste sur le serveur, dans un dossier que plus aucune adresse ne sert : c’est le plan de retour, qui n’a pas servi.

Et les bénévoles ?

C’est la question qui a limité la version de 2001 et compliqué toutes les autres. Des fichiers texte dans Git, ce n’est pas plus accessible qu’un éditeur HTML pour un trésorier de club.

La réponse, cette fois, est un chat d’administration. On écrit en français : « décale le cours ado-adultes du vendredi à 19 h 15 », « ajoute le passage de grade du 14 décembre au gymnase ». Un agent modifie les fichiers concernés, lance la vérification, corrige si le schéma refuse, et propose un aperçu du site. Rien n’est publié tant que quelqu’un n’a pas cliqué sur Publier. Ce bouton n’est pas un outil de l’agent ; c’est le seul chemin vers la production. Annuler efface le brouillon sans trace.

L’agent ne peut faire que sept choses : lister, lire, écrire dans les dossiers de contenu, supprimer, chercher, vérifier, proposer. Il ne touche pas au code du site.

Ce que je retiens de cinq versions

Le besoin n’a pas bougé d’un millimètre en vingt-cinq ans. Horaires, inscriptions, résultats, qui enseigne.

Ce qui a bougé, c’est le compromis entre deux choses : la simplicité de ce qu’on met en ligne, et l’autonomie de ceux qui l’alimentent. En 2001, j’avais la première et pas la seconde. Avec Joomla puis WordPress, j’ai acheté la seconde au prix de la première, et je l’ai perdue quand même, parce que le CMS est devenu trop fragile pour être confié.

En 2026, pour la première fois, je n’ai pas eu à choisir. Le site est aussi simple qu’en 2001 : des fichiers. Et un bénévole peut le modifier en écrivant une phrase.

Il aura fallu vingt-cinq ans pour revenir au point de départ, avec ce qui manquait.