« _s is a starter theme, not a framework, and is intended to be used as a base for building your own theme » : cette phrase, présente depuis des années dans la documentation d’Underscores, résume bien sa philosophie. Underscores fournit un squelette minimal, volontairement dépourvu d’outillage de build, de préprocesseur CSS ou de linter, à charge pour chaque développeur d’ajouter ce dont il a besoin par-dessus.
Cette sobriété a longtemps été une force : un thème généré par Underscores reste lisible, compréhensible en quelques minutes, sans dépendance à un écosystème JavaScript particulier. Mais depuis quelques années, des starter themes plus récents proposent une base bien plus outillée dès l’installation, ce qui pose une vraie question de choix pour un nouveau projet en 2025.
Ce qu’Underscores fournit, et ce qu’il ne fournit pas
Underscores génère une arborescence de fichiers PHP classiques (header.php, footer.php, functions.php), une feuille de style de base et un jeu de gabarits couvrant la hiérarchie de templates standard. Aucune étape de compilation n’est nécessaire pour l’utiliser : le CSS généré est directement exploitable tel quel, sans préprocesseur, sans bundler JavaScript, sans configuration de build à maintenir.
Ce choix a un coût pour les projets plus ambitieux : dès qu’un thème a besoin de Sass, de modules JavaScript ou d’une minification automatique des assets, il faut ajouter soi-même l’outillage correspondant, souvent en copiant une configuration webpack ou Vite trouvée sur un autre projet, sans garantie de cohérence entre les projets d’une même agence.
Ce qu’apporte un starter theme moderne
Un starter theme récent embarque directement une configuration de build fonctionnelle : compilation Sass vers CSS, regroupement et minification des scripts JavaScript, rechargement automatique du navigateur pendant le développement, et souvent une intégration avec theme.json pour synchroniser les tokens de design entre le PHP et les fichiers de style. Ce socle évite à chaque nouveau projet de reconstruire la même mécanique de build depuis zéro.
{
"scripts": {
"start": "vite",
"build": "vite build",
"lint:js": "eslint src/js",
"lint:css": "stylelint src/scss"
}
}
Ce fichier package.json, absent d’Underscores par conception, structure dès le premier jour la façon dont l’équipe développera, testera et empaquettera le thème, avec des commandes identiques d’un projet à l’autre pour toute l’agence.
Structure de dossiers imposée plutôt que suggérée
- Séparation claire entre sources (
src/) et fichiers compilés (build/), avec ces derniers exclus du dépôt Git - Convention de nommage des composants PHP réutilisables, souvent proche des blocs de l’éditeur
- Fichiers de configuration de lint fournis par défaut, plutôt qu’à écrire pour chaque nouveau projet
Le vrai gain n’est pas au démarrage
Générer un thème Underscores prend quelques minutes via son générateur en ligne, tout comme cloner un starter theme moderne. La différence se révèle des mois plus tard : sur un projet Underscores sans outillage ajouté proprement, chaque développeur qui reprend le thème doit d’abord comprendre comment sont gérés les assets, alors qu’un starter theme moderne impose une convention commune, la même sur tous les projets de l’agence.
Le squelette le plus simple à démarrer n’est pas toujours le plus simple à maintenir un an après, une fois que plusieurs personnes s’y sont succédé.
Notion à retenir
Underscores garde toute sa place pour un thème simple, sans build complexe, ou pour apprendre la structure d’un thème classique sans la couche supplémentaire d’un outillage JavaScript. Un starter theme moderne se justifie dès qu’une agence gère plusieurs projets en parallèle et veut une convention de développement partagée. Le choix ne se fait donc pas sur la richesse des fonctionnalités au démarrage, mais sur le nombre de personnes qui toucheront le thème dans sa durée de vie.
