10 min de lecture
Étude de cas Musō Jiu-Jitsu Académie : un site FSE 76/97 PageSpeed avec un vrai parti pris visuel
La Musō Jiu-Jitsu Académie, c'est un projet auquel je suis intimement lié : j'en suis l'un des cofondateurs, avec entre autres Catherine Tournadre (la DA dont je parle plus bas, qui est aussi membre fondatrice). Cet article n'est donc pas un cas client distant, c'est un retour d'expérience sur un site monté pour notre propre club, avec toute la liberté et toutes les exigences que ça implique. J'ai préféré l'assumer dès l'ouverture plutôt que de jouer la carte du « client mystère ».
Le besoin était clair : il nous fallait un site qui sente le club. Pas un thème de sport générique téléchargé sur ThemeForest, pas un Wix saupoudré d'IA, pas un Webflow proprement aligné qui aurait pu être celui d'une agence de comm. Un site avec une vraie identité visuelle, qui parle au public du jiu-jitsu brésilien à Clermont-Ferrand. Et qui, en bonus, soit assez rapide pour ne pas faire fuir les gens qui se renseignent depuis leur téléphone à 22h après l'entraînement.
Le résultat : un thème WordPress FSE entièrement sur-mesure, designé avec Catherine, intégré directement dans Gutenberg natif, qui tourne aujourd'hui à 76/100 sur PageSpeed mobile et 97/100 sur PageSpeed desktop. Voici comment on y est arrivé, et ce que ce projet a appris.
Le brief et le contexte
La Musō Jiu-Jitsu Académie est un club de jiu-jitsu brésilien basé à Clermont-Ferrand. L'objectif du site n'était pas commercial à proprement parler. C'était de transmettre une atmosphère, donner envie de franchir la porte du dojo pour un premier cours d'essai, et donner toutes les infos pratiques (planning, tarifs, lieu, philosophie) sans détour.
Comme on est nous-mêmes derrière le projet (et derrière le tatami), la qualité a primé sur tout le reste. Pas de devis à boucler en mode « c'est l'enveloppe, on rentre ce qu'on peut dedans ». On s'est donné le temps de faire les choses proprement, parce que c'est nous qui allons utiliser ce site au quotidien et c'est notre image qui est en jeu. Cette posture change beaucoup de choses dans les arbitrages, j'y reviens à plusieurs reprises plus bas.
Quelques contraintes encadraient quand même le projet. Un budget temps réaliste, déjà, parce que la Musō n'est pas notre activité principale et que monter un site de cette qualité aurait été financièrement prohibitif en prestation externe. Des contenus visuels forts à servir sans plomber le site (les photos d'entraînement et d'ambiance du dojo, c'est l'âme du site, on ne pouvait pas les sacrifier sur l'autel de la performance). Et derrière, une vraie autonomie éditoriale : le reste de l'équipe devait pouvoir éditer ses pages et mettre à jour le planning sans m'appeler pour chaque virgule.
La collaboration avec la DA
Le design a été pensé en amont avec Catherine Tournadre, directrice artistique et, comme moi, membre fondatrice de la Musō. C'est elle qui a posé l'identité visuelle : choix typographique, palette, intentions de mise en page, photos d'ambiance. On a travaillé sur Figma sur quelques itérations rapides, principalement la home et deux gabarits intérieurs. Pas de design exhaustif page par page, mais assez d'éléments pour fixer le système visuel.
Travailler avec un membre fondateur du projet n'est pas la même chose que travailler avec un client externe. Catherine connaît le club de l'intérieur, elle sait à qui le site s'adresse, et elle assume avec moi les choix qu'on prend. Ça permet d'aller plus vite sur certains arbitrages (pas de cycle d'allers-retours pour valider une nuance) et plus en profondeur sur d'autres (on peut se permettre une session de trois heures sur un détail typographique parce qu'on porte tous les deux le projet).
Quand le travail entre une DA et un dev fonctionne bien, c'est aussi parce que personne n'essaie de gérer la moitié du métier de l'autre. Elle a posé l'esthétique et les principes (les espacements, les rythmes typo, la hiérarchie). Moi je me suis concentré sur la transposition fidèle dans Gutenberg, en signalant les points où l'idée design demanderait un effort technique disproportionné par rapport à l'impact, et en proposant des alternatives quand c'était pertinent. Aucune guerre d'ego, juste deux métiers qui se complètent.
theme.json.La stack : Bedrock + FSE + Composer + WP-CLI
Sous le capot, le projet est un Bedrock (la structure WordPress repensée par Roots.io), avec gestion des dépendances en Composer, environnement local en DDEV, déploiement scripté avec WP-CLI. C'est plus de mise en place qu'un WordPress classique au démarrage, mais ça paie sur trois ans : les mises à jour de plugins se font en une commande versionnée, l'environnement est reproductible à l'identique, les déploiements sont propres.
Le thème lui-même est un thème Full Site Editing (FSE) pur. Pas de PHP de templating à la main, pas de constructeur tiers. Tout passe par le theme.json, des templates HTML, des patterns, et l'éditeur de site WordPress natif. Cette discipline a un coût (la courbe d'apprentissage du FSE est réelle), mais elle apporte deux choses précieuses : un site qui respire la même grammaire visuelle partout, et un éditeur WordPress qui devient enfin agréable à utiliser pour le client final.
La tokenisation dans le theme.json
Avant d'écrire la première ligne de markup, j'ai pris une demi-journée pour transposer tout le système visuel dans le theme.json (version 3) : palette de couleurs nommées sémantiquement (primary, accent, contrast, neutral…) avec plusieurs paliers de luminosité, deux échelles typo (une fixe pour l'interface, une fluide pour les titres qui passent par exemple de 48 à 84px selon la viewport), une vingtaine de paliers d'espacement dont plusieurs fluides, et les fontes Geologica + IBM Plex Mono auto-hébergées en .woff2 (zéro requête vers Google Fonts).
Cette étape est la moins glamour du projet, et c'est pourtant celle qui décide si le site sera maintenable ou pas. Un thème FSE sans tokenisation devient un patchwork de styles inline en quelques semaines. Avec une tokenisation propre, n'importe quelle modification visuelle se propage partout en une ligne. Si demain on veut changer la dominante visuelle, c'est une heure de travail sur le theme.json, pas trois jours de chasse aux color: #c44321 oubliés dans des blocs.
100% sur-mesure, et pourtant 100% Gutenberg natif
C'est sans doute le point le plus intéressant à raconter sur ce projet. Le design final, malgré un parti pris très assumé, est entièrement réalisé avec les blocs Gutenberg natifs et quelques patterns custom. Pas de bloc React custom, pas de page builder caché, pas de shortcode propriétaire. Quelqu'un qui ouvre la home dans le back-office voit exactement la même chose que le visiteur sur le front, à un poil de chrome près.
Pourquoi c'est rare ? Parce que la plupart des thèmes sur-mesure tombent dans l'un de deux pièges. Le premier, c'est de bricoler un Elementor ou un Divi pour livrer un design fort. Dans ce cas, l'éditeur back-office est un cauchemar de panneaux empilés. Le second, c'est de coder des blocs React custom partout. Ça marche très bien, jusqu'au jour où il faut faire évoluer un de ces blocs et qu'on se retrouve à maintenir un mini-framework JavaScript dans son thème.
Sur Musō, on a tenu la ligne : tout en blocs natifs, tout en patterns. Quand un effet visuel demandait quelque chose qui n'existait pas en natif (un overlay sur image avec texte centré et angle particulier), on l'a obtenu via la composition de blocs (Group + Cover + Spacer + Text) et un peu de CSS ciblé dans le thème. Pas de bloc custom, pas de plugin tiers.
Côté éditeur et côté visiteur, voilà ce que ça donne :
Pour le reste de l'équipe qui édite le site (et qui n'est pas développeuse), c'est concret : on voit ce qu'on édite. Pas de surprise au passage en preview, pas de sentiment de devoir maîtriser un outil opaque. Et côté tech, c'est tout aussi concret : pas de couche d'abstraction supplémentaire à maintenir. Si Gutenberg évolue, le site évolue avec lui sans dette technique. C'est exactement le compromis que je voulais pour un projet qu'on va faire vivre des années.
La bibliothèque de patterns réutilisables
Pour que le reste de l'équipe puisse éditer le site sans me solliciter, et sans pour autant se retrouver face à une page blanche Gutenberg, j'ai construit une bibliothèque de patterns custom. Une dizaine au total, déclarés en PHP dans patterns/*.php, regroupés sous une catégorie dédiée dans l'inserter Gutenberg. On y trouve les CTAs récurrents (cours d'essai, mise en avant des stages), les cards d'articles et d'événements, ainsi que les blocs de signature des coachs.
Chaque pattern est une composition de blocs natifs avec les bons réglages d'espacement, d'alignement et de typo déjà en place. Il suffit d'insérer le pattern, de remplacer le contenu, et c'est aligné avec le reste du site. Cette bibliothèque a probablement été l'investissement à plus haut ROI du projet. Elle a pris environ une journée à construire à la fin, et elle a permis depuis le lancement d'ajouter plusieurs nouvelles pages sans que j'aie à toucher au code une seule fois.
Le pipeline images : AVIF + WebP + fallback
Sur un site qui mise autant sur les visuels, le poste image pèse forcément lourd dans le bilan performance. La règle qu'on s'est fixée : chaque photo servie en AVIF par défaut, WebP en fallback pour les navigateurs un peu plus anciens, JPEG en dernier recours. Toutes les images sont aussi déclinées en plusieurs tailles via les srcset WordPress, pour que le navigateur charge la version qui colle à l'écran qu'il affiche.
Côté outillage, j'ai utilisé un plugin de conversion qui automatise la génération AVIF/WebP au moment de l'upload, sans transformer la médiathèque en usine à gaz. Concrètement, une image hero de 320 ko en JPEG d'origine se retrouve servie à 60 ko en AVIF sur un Chrome récent, sans qu'on voie la différence à l'œil nu. Sur la home, ça fait plusieurs centaines de kilo-octets gagnés sur le LCP, et plusieurs points sur Lighthouse.
Pour des photos d'ambiance qui sont littéralement l'âme visuelle du site, c'est la combinaison qui permet de garder la qualité photographique sans sacrifier les Core Web Vitals. Pas besoin de réduire les images à des miniatures floues pour gagner en vitesse. On peut avoir les deux.
Les résultats PageSpeed
À la livraison, le site sortait à 76/100 sur PageSpeed mobile (mesuré en émulation Moto G Power sur connexion 4G lente) et 97/100 sur PageSpeed desktop, avec 93 en accessibilité et 100 en bonnes pratiques et SEO sur les deux profils. Pour un site qui pousse autant de contenu visuel et avec un parti pris design aussi assumé, c'est honnête. Beaucoup de sites équivalents montés sur des thèmes du commerce ou des page builders tournent à 30-40 sur mobile.
Les Core Web Vitals associés sont bons : LCP sous les 2,5 secondes en mobile sur 4G simulée, CLS quasi nul (le layout est verrouillé par les dimensions explicites des images), INP largement sous les 200 ms (pas de JavaScript lourd côté client). Ces chiffres ne sont pas une fin en soi, ils traduisent juste une expérience de chargement fluide pour quelqu'un qui découvre le site depuis son téléphone à 22h après l'entraînement (boucle bouclée avec l'intro).
Ce que ce projet a appris
Avec quelques mois de recul, deux ou trois choses ressortent assez nettement.
La première, c'est qu'il n'y a aucune fatalité à choisir entre design fort et performance. La petite musique du « si vous voulez un beau site, ça sera lent » est largement portée par les agences qui livrent sur Elementor ou WPBakery. Et c'est faux. Avec un FSE bien fait et un peu de discipline sur les images, on peut servir une identité visuelle forte à 76 sur mobile sans tordre le projet.
La deuxième, c'est que la collaboration design/dev fonctionne d'autant mieux qu'on évite la chaîne classique « Figma livré, dev qui copie ». Sur Musō, Catherine et moi avons discuté tôt des contraintes techniques de chaque proposition. Elle a pu adapter quelques détails au passage (un dégradé qui aurait demandé un fond fixed en JavaScript, une animation qui n'apportait rien au final) sans drama. Trois ou quatre journées de retouche évitées en aval, sans douleur.
Et la dernière, c'est que la bibliothèque de patterns est probablement la meilleure manière de pérenniser un site WordPress. C'est ce qui transforme une livraison en outil utilisable au quotidien, au lieu d'une page statique qu'on n'ose plus toucher de peur de tout casser.
Une remarque honnête pour finir, parce que je l'ai dit en intro : monter le site de son propre projet, c'est un cas particulier. On peut se permettre des arbitrages qualité que la facturation au temps passé rend rarement possibles en prestation classique. Tout n'est pas transposable tel quel à un projet client lambda. En revanche, la stack et la méthode (FSE, theme.json, patterns, pipeline AVIF/WebP) le sont, et je les remets en œuvre, à des échelles différentes, sur les sites que je livre par ailleurs.
Pour donner un ordre de grandeur concret, si Musō avait été commandé en prestation externe avec le même périmètre (design sur-mesure avec une DA, thème FSE complet, tokenisation poussée, bibliothèque de patterns, pipeline image optimisé, intégration WooCommerce et événements), la fourchette aurait été de l'ordre de 6 000 à 9 000 € HT. C'est l'enveloppe que je donne aujourd'hui aux clients qui me demandent un projet équivalent, pour avoir un point de comparaison avec ce qui est montré ici.
Si vous voulez voir le résultat en vrai, la page projet du portfolio détaille un peu plus le contexte : Musō Jiu-Jitsu Académie. Et si vous avez un projet de site qui demande à la fois une vraie identité visuelle et une exigence sur les performances, on peut en parler quand vous voulez. Pas besoin d'avoir un design fini sous le bras, on regarde d'abord le besoin.