« On part de ce thème, il a une belle démo, ça ira plus vite. » Cette phrase a lancé plus d’un projet qui a finalement pris du retard. Sur plusieurs chantiers menés en 2024, nous avons chronométré le temps réellement passé à démonter le contenu de démonstration d’un thème bloc riche, avant même de commencer l’intégration du contenu client : sur l’un des projets, ce nettoyage représentait 40 % du temps total d’intégration.
Ce constat a changé notre pratique de production : nous partons désormais, par défaut, d’un thème bloc quasiment vide plutôt que d’un thème riche en démonstrations préconçues, sauf demande explicite du client pour un cas d’usage très proche d’une démo existante.
Pourquoi une démo riche coûte cher à démonter
Un thème avec de nombreuses démonstrations embarque généralement des patterns imbriqués les uns dans les autres, des styles spécifiques à chaque démo qui polluent la feuille de style globale, et des dépendances à des plugins tiers utilisés uniquement pour recréer certains effets visuels de la démonstration. Retirer un seul de ces éléments implique souvent de vérifier qu’aucun style résiduel ne continue de s’appliquer ailleurs sur le site.
Sur un projet particulièrement dense, retirer la démo « agence créative » du thème choisi initialement a nécessité de désactiver quatre plugins d’accompagnement, de purger des styles CSS spécifiques répartis dans six fichiers différents, et de recréer depuis zéro les patterns de mise en page dont le client avait réellement besoin.
Ce qu’apporte un thème quasiment vide
Un thème bloc minimal ne fournit que l’essentiel : un theme.json propre avec une palette neutre, quelques templates de base (page d’accueil, article, archive), et aucun pattern préconçu qui ne correspondrait pas au projet en cours. Chaque élément visuel ajouté au site l’est parce que le projet en a réellement besoin, pas parce que le thème l’imposait par défaut.
- Aucun style CSS résiduel d’une fonctionnalité de démo non utilisée par le client.
- Aucune dépendance à un plugin d’accompagnement propre au thème, source fréquente d’incompatibilités futures.
- Une base de code plus simple à auditer lors d’une reprise de projet, sans avoir à distinguer ce qui vient de la démo de ce qui a été réellement personnalisé.
Le vrai rôle de la démo : vendre, pas produire
Les démonstrations riches ont un rôle légitime : convaincre un client de la qualité d’un thème lors d’un choix commercial, en montrant un rendu abouti visuellement. Le problème survient quand cette même démo devient, par facilité, la base de travail technique du projet réel. Ces deux usages devraient rester distincts : s’inspirer visuellement d’une démo pour cadrer une direction artistique n’implique pas d’en garder le code sous-jacent.
Une discipline saine imposée dès le départ
Partir d’un thème vide oblige l’équipe à documenter chaque décision de mise en page dès sa création, plutôt que de la découvrir implicitement dans un thème déjà rempli. Cette contrainte, qui peut sembler ralentir le démarrage du projet, évite en réalité l’accumulation silencieuse d’éléments non maîtrisés qui se paie plus tard, souvent au moment le moins opportun : une mise à jour de sécurité urgente qui touche un plugin de démo oublié depuis des mois.
Un thème vide qu’on remplit sciemment vaut mieux qu’un thème plein qu’on vide à moitié sans être certain d’avoir tout retiré.
Quand un thème de démo reste pertinent
Cette approche ne s’applique pas systématiquement. Un client qui souhaite reproduire une démonstration presque à l’identique, avec un budget limité et un besoin très proche de ce qui existe déjà, peut légitimement bénéficier d’un thème de démo peu modifié. La bonne question à se poser en amont du projet n’est donc pas « quel thème a la plus belle démo » mais « quelle proportion de cette démo correspond réellement au besoin du client ».
Notre verdict
Notre production a gagné en prévisibilité depuis que nous avons généralisé le thème bloc quasiment vide comme point de départ par défaut. Le temps gagné à ne pas démonter une démo compense largement le temps supplémentaire passé à reconstruire les quelques éléments réellement utiles, d’autant que ces éléments sont alors parfaitement adaptés au projet plutôt qu’hérités d’un contexte différent.
