Choisir un thème WordPress blocs ou classique n’est pas un référendum sur le passé et le futur. C’est une décision d’architecture : qui modifie les modèles, comment les styles sont gouvernés, quelles intégrations existent, quel niveau de code l’équipe maintient et comment le site évoluera.
Un thème de blocs peut offrir une grande autonomie dans l’Éditeur de site. Un thème classique peut rester parfaitement adapté à une base existante, à un flux éprouvé ou à des modèles PHP spécialisés. La bonne réponse se prouve avec un inventaire et un prototype.
Sommaire
La réponse courte
Choisissez un thème de blocs lorsque l’équipe doit éditer en natif en-tête, pied de page, modèles et styles globaux, et qu’elle accepte de gouverner cette liberté. Choisissez ou conservez un thème classique lorsque ses modèles, hooks, personnalisations et intégrations répondent déjà au besoin avec un coût de maintenance raisonnable.
Dans les deux cas, mesurez performance, accessibilité, traduction, SEO, compatibilité et expérience éditoriale sur les vrais contenus. N’installez pas une architecture uniquement pour son étiquette.
Le Theme Handbook définit deux types principaux : les thèmes de blocs utilisent surtout des modèles HTML et des blocs ; les thèmes classiques s’appuient principalement sur PHP, JavaScript et CSS.
Principes qui restent valables
L’Éditeur de site et theme.json se sont enrichis, mais les thèmes classiques restent pris en charge et largement utilisés. Certains thèmes classiques adoptent des fonctionnalités de blocs ; on les qualifie souvent d’hybrides, sans que cela constitue un troisième type officiel universel.
La différence technique n’indique pas automatiquement la qualité. Un thème de blocs peut charger trop de styles ou contenir des modèles fragiles. Un thème classique peut être léger, accessible et bien maintenu.
Comprendre le thème de blocs
Un thème de blocs possède des modèles composés de balisage de blocs et permet d’éditer les zones du site dans l’Éditeur. En-tête, pied de page, archive et modèle d’article deviennent des compositions réutilisables.
theme.json centralise de nombreux réglages et styles. L’utilisateur peut créer des variations et enregistrer des modifications en base. Cette puissance exige une stratégie : qui peut changer les modèles, comment revoir les modifications et comment les transférer entre environnements.
La documentation officielle précise qu’un thème de blocs possède au minimum un modèle index.html dans le dossier approprié.
Comprendre le thème classique
Un thème classique utilise des modèles PHP et la hiérarchie historique de WordPress. Les fonctions, hooks et filtres peuvent assembler des vues complexes et intégrer des systèmes existants.
Il peut parfaitement utiliser l’éditeur de blocs pour le contenu, déclarer des supports et même adopter theme.json. Le choix « classique » ne signifie donc pas revenir à l’ancien éditeur.
Cette architecture peut convenir lorsque les développeurs contrôlent les modèles et que les éditeurs travaillent dans un espace volontairement limité.
Définir qui édite quoi
Listez les changements courants : couleur, typographie, landing page, en-tête, navigation, archive, modèle d’article et composant réutilisable. Attribuez chaque changement à un rôle.
Si les éditeurs doivent créer régulièrement de nouvelles mises en page sans déploiement, les modèles et compositions de blocs peuvent réduire la friction. Si la marque exige un cadre strict, verrouillez les éléments essentiels ou maintenez les templates dans le code.
La flexibilité sans gouvernance provoque des divergences ; la rigidité sans processus ralentit chaque campagne.
Examiner les contenus existants
Inventoriez blocs, shortcodes, constructeurs, champs personnalisés, types de contenus, widgets et modèles. Ouvrez des exemples longs, des tableaux, des galeries, des formulaires et des pages atypiques.
Un changement de thème ne convertit pas automatiquement le contenu d’un constructeur. Il peut laisser des shortcodes visibles ou supprimer une mise en page. Prévoyez une stratégie de transformation et une sortie possible.
Sur un nouveau site, créez un jeu de contenu représentatif avant de juger un thème.
Comparer l’édition des modèles
Dans un thème de blocs, les personnalisations enregistrées via l’Éditeur peuvent vivre dans la base et supplanter les fichiers du thème. Documentez leur origine et la méthode d’export ou de versionnement.
Dans un thème classique, les modifications de modèles appartiennent souvent au code d’un thème enfant ou d’un dépôt. L’éditeur peut avoir moins d’autonomie, mais le changement est plus directement relié à un déploiement.
Testez le flux complet : créer, relire, approuver, déployer et revenir en arrière.
Tester les compositions et le verrouillage
Les compositions accélèrent la création de sections cohérentes. Définissez celles qui sont libres, synchronisées ou verrouillées. Vérifiez ce qui se passe lorsque l’utilisateur remplace un média, réorganise une colonne ou colle du contenu.
Un bon système fournit assez de variations pour le travail réel sans transformer chaque page en design unique. N’utilisez pas le verrouillage pour cacher un problème d’ergonomie ; expliquez le cadre.
Le guide blocs Gutenberg et performance détaille la construction native sans empiler des bibliothèques inutiles.
Évaluer la performance
Installez seulement le thème et les extensions nécessaires, puis mesurez plusieurs modèles. Observez HTML, CSS, JavaScript, polices, images, requêtes et cache. Comparez dans les mêmes conditions.
Le type de thème n’est qu’un facteur. Les choix de blocs, scripts tiers, images et fonctionnalités dominent souvent le résultat. Un test sur la démo commerciale du thème ne représente pas votre site.
Mesurez avant et après chaque personnalisation importante.
Vérifier l’accessibilité
Testez navigation clavier, ordre de focus, contrastes, zoom, reflow, titres, régions, menus, formulaires et messages d’erreur. Ouvrez l’en-tête et le menu mobile avec un clavier et un lecteur d’écran si possible.
Un composant fourni par le thème doit rester accessible après modification des couleurs et tailles. Vérifiez aussi l’Éditeur : les équipes doivent pouvoir produire un contenu correct sans contourner des blocs.
Une mention « accessibility ready » n’est pas une certification du site final.
Contrôler SEO et données structurées
Vérifiez un H1 principal cohérent, titres, fil d’Ariane, canonicals, métadonnées, schéma, pagination et contenu d’archive. Évitez que le thème duplique des fonctions déjà fournies par une extension SEO.
Testez l’HTML public, pas seulement l’apparence dans l’Éditeur. Un modèle peut afficher deux titres ou masquer une description importante.
Conservez les URLs lors d’un changement de thème sauf projet de migration séparé.
Vérifier WooCommerce et les extensions
Pour une boutique, testez catalogue, variations, mini-panier, panier, compte, paiement et extensions de passerelle. Les Cart et Checkout blocks et les équivalents classiques n’ont pas toujours la même surface d’intégration.
Vérifiez la compatibilité déclarée et le parcours réel. Le support d’une page produit ne prouve pas celui d’un abonnement ou d’une réservation.
Conservez un thème de repli connu et une procédure de retour.
Évaluer traduction et internationalisation
Changez la langue, testez chaînes longues, pluriels, direction si nécessaire et sélecteurs de langue. Les modèles et compositions personnalisés peuvent contenir du texte stocké différemment du thème.
Définissez où se traduisent les chaînes : fichiers, contenu, options ou outil multilingue. Un thème qui semble simple en une langue peut créer un flux complexe en plusieurs langues.
Vérifiez les archives et messages système, pas seulement la page d’accueil.
Comparer la maintenance
Examinez fréquence des mises à jour, journal des changements, support des versions récentes, politique de sécurité, documentation et licence. Identifiez le coût des personnalisations lors de chaque mise à jour.
Pour un thème classique très modifié, un thème enfant et un dépôt peuvent préserver les changements. Pour un thème de blocs, définissez comment exporter les modèles modifiés et éviter une divergence invisible en base.
La maintenabilité dépend du processus autant que du code.
Construire un prototype représentatif
Créez sur staging un article long, une page commerciale, une archive, une recherche, une erreur 404 et un formulaire. Ajoutez les blocs et contenus réels, sans données personnelles.
Demandez à un éditeur de réaliser trois tâches et à un développeur de corriger un modèle. Mesurez temps, erreurs et compréhension. Comparez les deux candidats sur les mêmes scénarios.
Le prototype remplace les débats abstraits par des preuves.
Planifier une migration de thème
Sauvegardez, clonez, inventez un plan de contenu et testez sur staging. Recréez widgets, menus, modèles et styles. Vérifiez chaque type de page et les modèles rares.
Préparez une fenêtre, un gel éditorial si nécessaire et un retour au thème précédent. Purgez les caches après bascule et surveillez erreurs, recherche et parcours.
Ne supprimez pas l’ancien thème avant la période de validation convenue.
Matrice de décision
Pondérez autonomie éditoriale, gouvernance, intégrations, performance, accessibilité, traduction, compétence d’équipe, migration et maintenance. Notez chaque solution avec une preuve et un risque.
Un thème de blocs peut gagner sur l’autonomie, tandis qu’un thème classique existant gagne sur la compatibilité. Le poids des critères dépend du projet.
Conservez la matrice pour réévaluer la décision après une évolution majeure.
Les erreurs à éviter
- Choisir selon une capture de démo.
- Confondre thème classique et éditeur classique.
- Autoriser tous les modèles sans gouvernance.
- Modifier le thème parent directement.
- Ignorer les personnalisations stockées en base.
- Tester seulement la page d’accueil.
- Affirmer qu’un type est toujours plus rapide.
- Migrer thème, URLs et hébergement en une seule opération opaque.
Checklist thème WordPress blocs ou classique
- [ ] Les personnes qui éditent chaque zone sont identifiées.
- [ ] Les contenus et intégrations existants sont inventoriés.
- [ ] Les modèles, compositions et verrous sont testés.
- [ ] Performance et accessibilité sont mesurées sur le vrai contenu.
- [ ] SEO, traduction et WooCommerce sont vérifiés.
- [ ] La source des personnalisations est documentée.
- [ ] Maintenance, support et licence sont évalués.
- [ ] Un prototype compare les scénarios réels.
- [ ] La migration possède une sauvegarde et un retour.
- [ ] La décision est conservée dans une matrice pondérée.
Conclusion
Le choix d’un thème WordPress blocs ou classique doit suivre le flux de travail, les intégrations et la capacité de maintenance. Les blocs offrent une surface d’édition plus large ; le classique conserve un modèle de templates et de code qui peut rester très robuste.
Prototypez, mesurez et gouvernez. Pour compléter cette architecture par un environnement cohérent, consultez choisir un hébergement WordPress.