Créer un thème WordPress : guide complet des thèmes de blocs

Créer un thème WordPress permet de maîtriser l’apparence, la structure et l’expérience de navigation d’un site sans dépendre entièrement d’un thème commercial. Avec l’éditeur de blocs Gutenberg, WordPress propose aujourd’hui une architecture permettant de construire des modèles de pages, des en-têtes, des pieds de page et des styles globaux à partir de fichiers HTML et JSON.

Mais concevoir un thème ne consiste pas simplement à choisir des couleurs et à déplacer des éléments dans une interface graphique. Pour obtenir un résultat fiable, il faut comprendre comment WordPress sélectionne ses modèles, interprète les blocs et applique les règles de présentation.

Dans ce guide, nous allons créer manuellement un premier thème de blocs fonctionnel, comprendre le rôle de chaque fichier et découvrir les étapes nécessaires pour le faire évoluer vers un véritable produit distribuable.

Comprendre le rôle d’un thème WordPress

WordPress repose sur plusieurs composants complémentaires.

Le noyau, appelé WordPress Core, assure le fonctionnement général du CMS. Les extensions ajoutent des fonctionnalités, tandis que les thèmes déterminent principalement la présentation des contenus.

Un thème peut notamment contrôler :

• L’organisation des pages et des articles.
• L’affichage de l’en-tête et du pied de page.
• La typographie et les couleurs.
• Les largeurs des contenus et les espacements.
• La présentation des archives et des résultats de recherche.
• La structure visuelle des menus et de la navigation.
• Les modèles disponibles dans l’éditeur de site.

Un thème ne remplace donc pas WordPress. Il fournit les instructions permettant au CMS de présenter ses contenus.

Cette distinction est essentielle pour concevoir un site maintenable.

Quelle différence entre un thème et une extension ?

Prenons l’exemple d’un site professionnel.

Le thème détermine la disposition du logo, l’apparence des boutons, la largeur des articles et l’organisation de la page d’accueil.

Une extension peut, quant à elle, ajouter un formulaire de réservation, une fonctionnalité métier ou une connexion à un service externe.

Élément	Responsabilité principale	Exemple
WordPress Core	Fonctionnement du CMS	Articles, utilisateurs, médias
Thème	Présentation et modèles	En-tête, typographie, mise en page
Extension	Fonctionnalités supplémentaires	Formulaire, outil métier, automatisation
Contenu	Informations publiées	Textes, images, pages

Cette séparation limite les dépendances.

Si un utilisateur change de thème, ses contenus et les fonctionnalités indépendantes du thème doivent normalement rester disponibles.

Un thème qui contient une fonctionnalité métier indispensable risque, au contraire, de rendre cette fonctionnalité inutilisable lorsqu’il est remplacé.

Thème classique, thème de blocs ou thème enfant : que choisir ?

WordPress prend en charge plusieurs approches de développement.

Le thème classique

Un thème classique utilise principalement des modèles PHP.

On retrouve généralement des fichiers comme :

header.php, footer.php, index.php, single.php ou functions.php.

Le développeur utilise les fonctions WordPress pour récupérer les contenus et construire les pages.

Cette architecture reste prise en charge et largement utilisée.

Elle peut être adaptée à des projets existants, à des besoins spécifiques ou à des environnements reposant sur une structure PHP traditionnelle.

Le thème de blocs

Un thème de blocs repose principalement sur des modèles HTML contenant le balisage spécifique des blocs WordPress.

Il utilise généralement un fichier theme.json pour définir les paramètres globaux de présentation.

Son principal avantage réside dans l’intégration avec l’éditeur de site WordPress, également appelé Site Editor.

L’utilisateur peut modifier visuellement des modèles, des en-têtes et des pieds de page sans nécessairement intervenir directement dans les fichiers.

Cela ne signifie pas que PHP a disparu de WordPress.

Le moteur du CMS continue de fonctionner avec PHP, et les thèmes peuvent toujours utiliser ce langage lorsque des besoins techniques le justifient.

Le thème enfant

Un thème enfant hérite d’un thème parent.

Il permet de personnaliser une base existante sans modifier directement ses fichiers.

Cette approche peut être pertinente lorsqu’un thème répond déjà à la majorité des besoins.

En revanche, elle implique de tenir compte de son architecture et de ses évolutions.

Quelle approche utiliser pour apprendre ?

Pour ce tutoriel, nous allons créer un thème de blocs autonome, sans thème parent.

Ce choix permet de comprendre directement les mécanismes modernes de WordPress, sans dépendre du code d’un produit existant.

Notre objectif n’est pas de reproduire immédiatement un thème commercial complet, mais de construire une base technique que nous maîtrisons.

Préparer l’environnement de développement

Avant de créer le thème, il faut disposer d’une installation WordPress locale.

Le développement ne doit pas être effectué directement sur un site public.

Une erreur dans un modèle peut provoquer une page vide, un affichage incorrect ou rendre certaines informations difficiles d’accès.

Pour préparer cet environnement, notre article complémentaire Installer WordPress en local : guide et outils de test présente les principales solutions disponibles.

Les outils nécessaires

Pour suivre ce guide, il faut :

1. Une installation WordPress locale fonctionnelle.
2. Un éditeur de code.
3. Un accès au répertoire des thèmes.
4. Un navigateur pour effectuer les essais.
5. Des connaissances élémentaires en HTML, CSS et JSON.

Nous utiliserons une installation compatible avec WordPress 6.6 ou une version ultérieure, car notre exemple adoptera la version 3 du format theme.json, introduite avec WordPress 6.6.

Cette indication constitue une exigence technique du format choisi, pas une déclaration de compatibilité déjà validée sur toutes les versions ultérieures.

Étape 1 — Créer la structure du thème

Dans votre installation WordPress, ouvrez le répertoire :

wp-content/themes/

Créez un nouveau dossier nommé :

atelier-blocs

Nous allons construire progressivement l’arborescence suivante :

wp-content/
└── themes/
    └── atelier-blocs/
        ├── style.css
        ├── theme.json
        ├── templates/
        │   ├── index.html
        │   ├── single.html
        │   └── page.html
        └── parts/
            ├── header.html
            └── footer.html

Cette structure comprend trois catégories de fichiers.

Les fichiers de déclaration identifient le thème et définissent ses paramètres globaux.

Les modèles, placés dans templates, déterminent la structure des différents types de pages.

Les parties de modèles, placées dans parts, permettent de réutiliser certains éléments, comme l’en-tête et le pied de page.

Quels fichiers sont réellement obligatoires ?

Pour qu’un thème de blocs soit reconnu, WordPress exige notamment :

• Un fichier style.css contenant les informations d’identification du thème.
• Un fichier templates/index.html servant de modèle de repli.

Le fichier theme.json n’est pas strictement obligatoire, mais il joue un rôle central dans le développement moderne.

Les autres fichiers sont ajoutés selon les besoins du projet.

Étape 2 — Déclarer le thème avec style.css

Commençons par le fichier style.css, situé à la racine du thème.

Ajoutez le contenu suivant :

/*
Theme Name: Atelier Blocs
Description: Thème WordPress de blocs pour apprendre le développement.
Version: 1.0.0
Requires at least: 6.6
Author: ATOOLPHA
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html
Text Domain: atelier-blocs
*/

Cet en-tête permet à WordPress d’identifier le thème.

Le champ Theme Name définit son nom visible dans l’administration.

Le champ Version renseigne sur la version du projet.

Le champ Text Domain identifie le domaine de traduction associé au thème.

La licence précise les conditions de distribution du code.

Pourquoi le fichier style.css est-il nécessaire si le thème utilise theme.json ?

Parce que ces deux fichiers ne remplissent pas la même fonction.

style.css contient les informations permettant à WordPress de reconnaître le thème. Il peut également accueillir des règles CSS personnalisées.

theme.json, que nous allons créer ensuite, permet de configurer de nombreux paramètres de présentation directement dans le système de styles de WordPress.

Il n’est donc pas nécessaire de placer toutes les règles visuelles dans style.css.

Pour les propriétés prises en charge, privilégier theme.json facilite généralement leur intégration dans l’éditeur de site.

Étape 3 — Configurer les styles globaux avec theme.json

Le fichier theme.json constitue l’un des éléments fondamentaux d’un thème de blocs.

Il permet notamment de définir :

• Une palette de couleurs.
• Les paramètres typographiques.
• La largeur des contenus.
• Les possibilités de personnalisation.
• Les styles appliqués aux blocs.
• Les parties de modèles disponibles dans l’éditeur.

Créez le fichier theme.json à la racine du thème.

Ajoutez :

{
  "$schema": "https://schemas.wp.org/trunk/theme.json",
  "version": 3,
  "settings": {
    "appearanceTools": true,
    "layout": {
      "contentSize": "760px",
      "wideSize": "1200px"
    },
    "color": {
      "palette": [
        {
          "slug": "marine",
          "name": "Bleu marine",
          "color": "#14253d"
        },
        {
          "slug": "accent",
          "name": "Bleu accent",
          "color": "#0b67b2"
        },
        {
          "slug": "clair",
          "name": "Fond clair",
          "color": "#f7f9fc"
        }
      ]
    }
  },
  "styles": {
    "color": {
      "background": "#ffffff",
      "text": "#14253d"
    },
    "typography": {
      "fontFamily": "system-ui, sans-serif",
      "lineHeight": "1.6"
    },
    "elements": {
      "link": {
        "color": {
          "text": "#0b67b2"
        }
      }
    }
  },
  "templateParts": [
    {
      "name": "header",
      "title": "En-tête",
      "area": "header"
    },
    {
      "name": "footer",
      "title": "Pied de page",
      "area": "footer"
    }
  ]
}

Comprendre les différentes propriétés

La propriété version indique la version du format theme.json.

Il ne faut pas la confondre avec le numéro de version du thème lui-même.

La propriété settings définit les paramètres disponibles dans l’éditeur.

La propriété styles indique les valeurs de présentation appliquées par défaut.

Enfin, templateParts déclare les parties de modèles que le thème souhaite mettre à disposition.

Pourquoi utiliser une palette de couleurs ?

Une palette permet de centraliser les couleurs disponibles.

Au lieu de choisir arbitrairement une nouvelle nuance dans chaque bloc, l’utilisateur dispose de couleurs cohérentes avec l’identité du site.

WordPress peut également générer des variables CSS associées à ces couleurs.

Par exemple, la couleur possédant le slug accent peut être utilisée à travers la variable :

var(--wp--preset--color--accent)

Ce mécanisme permet de construire un système graphique réutilisable.

Comprendre les largeurs de contenu

Notre configuration distingue deux valeurs.

contentSize définit une largeur de référence pour les contenus classiques.

wideSize définit une largeur destinée aux blocs utilisant l’alignement large.

Ces valeurs ne garantissent pas à elles seules un affichage parfait sur tous les appareils.

Le résultat dépend également de la structure des blocs, des styles appliqués et des dimensions disponibles.

Pourquoi éviter de multiplier les règles CSS ?

Lorsque plusieurs systèmes de styles se superposent, les conflits deviennent plus difficiles à comprendre.

Une règle définie dans style.css peut entrer en concurrence avec un style global ou une personnalisation enregistrée depuis l’éditeur.

Pour les fonctionnalités standard, utiliser les propriétés de theme.json réduit généralement cette complexité.

Le CSS personnalisé reste utile lorsqu’un besoin ne peut pas être correctement exprimé avec les paramètres disponibles.

Étape 4 — Créer l’en-tête du site

Nous allons maintenant créer le fichier :

parts/header.html

Son rôle sera d’afficher l’identité du site et un emplacement de navigation.

Ajoutez :

<!-- wp:group {"layout":{"type":"constrained"}} -->
<div class="wp-block-group">

  <!-- wp:group {"align":"wide","layout":{"type":"flex","justifyContent":"space-between","flexWrap":"wrap"}} -->
  <div class="wp-block-group alignwide">

    <!-- wp:site-title {"level":0} /-->

    <!-- wp:navigation /-->

  </div>
  <!-- /wp:group -->

</div>
<!-- /wp:group -->

Pourquoi trouve-t-on des commentaires HTML dans ce fichier ?

Ces commentaires ne sont pas de simples annotations destinées au développeur.

Ils constituent le balisage spécifique utilisé par WordPress pour identifier les blocs.

Par exemple :

<!-- wp:site-title {"level":0} /-->

indique à WordPress qu’il doit afficher le titre du site.

Le contenu est dynamique : il provient des informations configurées dans l’administration.

Il n’est donc pas nécessaire d’écrire directement le nom du site dans le modèle.

À quoi sert le bloc Navigation ?

Le bloc Navigation permet de construire et d’afficher le menu du site.

Dans notre exemple, nous déclarons simplement son emplacement.

Le menu devra ensuite être configuré et contrôlé dans l’éditeur de site.

Cette séparation est intéressante : le thème définit l’organisation visuelle, tandis que l’utilisateur peut adapter les liens de navigation.

Pourquoi utiliser level: 0 pour le titre du site ?

Dans notre exemple, nous souhaitons éviter d’imposer systématiquement un H1 dans l’en-tête.

Le bloc Titre du site peut ainsi afficher l’identité du site sans créer un titre principal supplémentaire.

Cela facilite la construction d’une hiérarchie de titres adaptée aux différentes pages.

Étape 5 — Créer le pied de page

Créez maintenant :

parts/footer.html

Ajoutez :

<!-- wp:group {"layout":{"type":"constrained"}} -->
<div class="wp-block-group">

  <!-- wp:paragraph {"align":"center"} -->
  <p class="has-text-align-center">
    Un site construit avec WordPress.
  </p>
  <!-- /wp:paragraph -->

</div>
<!-- /wp:group -->

Notre pied de page est volontairement minimal.

Il pourra ensuite accueillir des informations complémentaires :

• Coordonnées professionnelles.
• Navigation secondaire.
• Mentions légales.
• Politique de confidentialité.
• Informations relatives à l’accessibilité.
• Liens vers les réseaux sociaux.

Ces éléments doivent être adaptés au site concerné.

Pour un site professionnel belge ou européen, la présence des informations juridiques et des documents de confidentialité dépend des activités et des traitements réellement effectués.

Il ne faut donc pas considérer ce pied de page pédagogique comme un modèle juridique complet.

Étape 6 — Créer le modèle principal index.html

Le fichier templates/index.html est essentiel.

Il constitue le modèle de repli utilisé lorsque WordPress ne trouve pas de modèle plus spécifique.

Nous allons y intégrer trois éléments :

1. L’en-tête du site.
2. Une liste dynamique d’articles.
3. Le pied de page.

Créez le fichier templates/index.html.

Ajoutez :

<!-- wp:template-part {"slug":"header","tagName":"header"} /-->

<!-- wp:group {"tagName":"main","layout":{"type":"constrained"}} -->
<main class="wp-block-group">

  <!-- wp:query {"query":{"inherit":true}} -->
  <div class="wp-block-query">

    <!-- wp:post-template -->

      <!-- wp:post-title {"isLink":true,"level":2} /-->

      <!-- wp:post-excerpt /-->

    <!-- /wp:post-template -->

    <!-- wp:query-pagination -->
    <div class="wp-block-query-pagination">

      <!-- wp:query-pagination-previous /-->

      <!-- wp:query-pagination-numbers /-->

      <!-- wp:query-pagination-next /-->

    </div>
    <!-- /wp:query-pagination -->

    <!-- wp:query-no-results -->

      <!-- wp:paragraph -->
      <p>Aucun article trouvé.</p>
      <!-- /wp:paragraph -->

    <!-- /wp:query-no-results -->

  </div>
  <!-- /wp:query -->

</main>
<!-- /wp:group -->

<!-- wp:template-part {"slug":"footer","tagName":"footer"} /-->

Comprendre le bloc Query Loop

Le bloc Query Loop permet d’afficher une liste de contenus récupérés par WordPress.

Il peut notamment présenter :

• Les derniers articles.
• Les articles d’une catégorie.
• Les résultats d’une recherche.
• Les contenus correspondant à une requête particulière.

Dans notre exemple, nous utilisons :

{"query":{"inherit":true}}

Cette configuration indique que la boucle doit hériter de la requête principale de la page.

Elle permet notamment de respecter le contexte de navigation et les paramètres associés à certaines archives.

Pourquoi utiliser post-template ?

Le bloc post-template définit la structure répétée pour chaque contenu récupéré.

Dans notre exemple, chaque article possède :

• Un titre cliquable.
• Un extrait.

Il serait également possible d’ajouter une image à la une, une date, un auteur ou des catégories.

À quoi sert la pagination ?

La pagination permet de naviguer entre plusieurs ensembles de résultats.

Elle évite de devoir afficher tous les articles sur une seule page.

Son fonctionnement dépend notamment de la requête et des paramètres de lecture de WordPress.

Pourquoi ce modèle ne suffit-il pas pour un site complet ?

Parce que le fichier index.html sert également de solution de repli.

Sans modèles supplémentaires, certaines pages peuvent utiliser une structure qui n’est pas adaptée à leur contenu.

C’est pourquoi nous allons maintenant créer des modèles spécifiques pour les articles et les pages.

Étape 7 — Créer le modèle des articles

Créez :

templates/single.html

Ce fichier définira la présentation des articles individuels.

Ajoutez :

<!-- wp:template-part {"slug":"header","tagName":"header"} /-->

<!-- wp:group {"tagName":"main","layout":{"type":"constrained"}} -->
<main class="wp-block-group">

  <!-- wp:post-title {"level":1} /-->

  <!-- wp:post-date /-->

  <!-- wp:post-featured-image /-->

  <!-- wp:post-content {"layout":{"type":"constrained"}} /-->

</main>
<!-- /wp:group -->

<!-- wp:template-part {"slug":"footer","tagName":"footer"} /-->

Comprendre les blocs dynamiques

Le bloc post-title affiche le titre de l’article actuellement consulté.

Le bloc post-date récupère sa date de publication.

Le bloc post-featured-image affiche son image à la une lorsqu’elle existe.

Enfin, le bloc post-content insère le contenu rédigé dans l’éditeur WordPress.

Le thème ne contient donc pas directement les textes des articles.

Il fournit leur structure d’affichage.

Pourquoi placer le titre de l’article en H1 ?

Un article possède généralement un titre principal qui doit être identifiable dans la structure du document.

Dans notre modèle, nous utilisons :

<!-- wp:post-title {"level":1} /-->

Cela permet de présenter le titre comme un H1.

Les titres présents dans le contenu de l’article peuvent ensuite utiliser les niveaux H2, H3 et suivants selon leur organisation.

Attention : un thème qui affiche déjà automatiquement le titre principal ne doit pas conduire le rédacteur à répéter ce même titre dans le contenu Gutenberg.

Étape 8 — Créer un modèle pour les pages

Les pages WordPress ne remplissent pas toujours la même fonction que les articles.

Une page peut servir à présenter une entreprise, des services, une politique de confidentialité ou un formulaire de contact.

Nous allons donc créer un modèle plus simple.

Créez :

templates/page.html

Ajoutez :

<!-- wp:template-part {"slug":"header","tagName":"header"} /-->

<!-- wp:group {"tagName":"main","layout":{"type":"constrained"}} -->
<main class="wp-block-group">

  <!-- wp:post-title {"level":1} /-->

  <!-- wp:post-content {"layout":{"type":"constrained"}} /-->

</main>
<!-- /wp:group -->

<!-- wp:template-part {"slug":"footer","tagName":"footer"} /-->

Ce modèle reprend la structure générale du site, mais n’impose ni date de publication ni image à la une.

Il constitue une base neutre pour les pages classiques.

Pourquoi séparer single.html et page.html ?

Cette séparation permet d’adapter la présentation à la nature du contenu.

Un article peut nécessiter des informations éditoriales, une image à la une ou des éléments de navigation entre publications.

Une page institutionnelle peut nécessiter une présentation différente.

Le système de modèles permet de gérer ces différences sans dupliquer toute l’architecture du thème.

Étape 9 — Installer et activer le thème

Notre structure pédagogique est maintenant constituée.

Avant toute activation, vérifiez que les fichiers sont enregistrés au bon emplacement.

Ouvrez ensuite l’administration de votre installation locale.

Accédez à :

Apparence > Thèmes

Le thème Atelier Blocs doit apparaître parmi les thèmes installés si sa structure et ses informations sont correctement reconnues.

Activez-le.

Puis ouvrez :

Apparence > Éditeur

Cette interface permet de modifier visuellement les modèles, les parties de modèles et les styles du site.

Premier contrôle visuel

Vérifiez successivement :

1. L’affichage du titre du site.
2. Le comportement du bloc Navigation.
3. L’affichage de la liste des articles.
4. La pagination lorsque plusieurs pages de résultats existent.
5. L’ouverture d’un article individuel.
6. L’affichage d’une page classique.
7. La présence du pied de page.
8. Le comportement sur différentes tailles d’écran.

Le résultat sera volontairement sobre.

Nous n’avons pas encore construit un système graphique complet avec composants, variations de styles et mises en page élaborées.

L’objectif de cette première version est de comprendre la structure technique.

Que faire si le thème n’apparaît pas ?

Plusieurs points doivent être examinés.

Le fichier style.css doit se trouver directement à la racine du dossier du thème.

Le fichier index.html doit se trouver dans le répertoire templates.

Les noms des dossiers et des fichiers doivent être correctement orthographiés.

Le fichier theme.json doit contenir du JSON valide.

Enfin, il faut vérifier que l’installation WordPress utilisée prend en charge les fonctionnalités choisies.

Une erreur de syntaxe, un fichier mal placé ou une incompatibilité peut empêcher le résultat attendu.

Étape 10 — Comprendre une particularité importante de l’éditeur de site

Le fonctionnement de l’éditeur de site introduit une distinction que les développeurs doivent connaître.

Modifier un modèle depuis l’administration ne revient pas nécessairement à modifier son fichier sur le disque.

Lorsqu’un utilisateur personnalise un modèle dans l’éditeur et enregistre ses modifications, WordPress peut conserver cette version dans sa base de données.

Cette personnalisation peut alors prendre le dessus sur le modèle fourni dans le dossier du thème.

Exemple concret

Imaginons que vous modifiez parts/header.html directement dans votre éditeur de code.

Vous ajoutez un nouvel élément et enregistrez le fichier.

Pourtant, l’en-tête affiché sur le site ne change pas.

Une explication possible est qu’une version personnalisée de cette partie de modèle existe déjà dans la base de données.

WordPress utilise alors la personnalisation enregistrée plutôt que le fichier d’origine.

Pourquoi ce comportement est-il important ?

Parce qu’il influence directement le développement et la distribution.

Un thème testé sur un site déjà personnalisé peut sembler fonctionner correctement, alors que certains fichiers du thème ne correspondent plus au résultat affiché.

À l’inverse, une modification du code peut paraître inefficace parce qu’une personnalisation utilisateur possède la priorité.

Il faut donc distinguer :

Élément	Emplacement principal	Rôle
Modèle fourni	Dossier du thème	Structure distribuée
Modèle personnalisé	Base de données WordPress	Modification propre au site
Paramètres theme.json	Fichier du thème	Styles et réglages par défaut
Styles personnalisés	Configuration enregistrée du site	Adaptations utilisateur

Avant de distribuer un thème, il est indispensable de le tester sur une installation propre, sans dépendre de personnalisations enregistrées uniquement sur la machine du développeur.

Étape 11 — Améliorer la qualité du thème

Un thème qui s’active correctement n’est pas nécessairement prêt à être utilisé sur un site professionnel.

Plusieurs domaines doivent encore être examinés.

Accessibilité

Le thème doit permettre aux visiteurs de comprendre et d’utiliser le site, y compris lorsqu’ils naviguent au clavier ou utilisent des technologies d’assistance.

Il faut notamment contrôler :

• La hiérarchie des titres.
• La navigation au clavier.
• La visibilité du focus.
• Les contrastes de couleurs.
• La lisibilité des textes.
• L’adaptation aux écrans de petite taille.
• Le comportement des menus.
• Les textes alternatifs des images informatives.

Le respect de ces principes ne se déduit pas automatiquement de l’utilisation des blocs natifs.

Les réglages graphiques et les personnalisations peuvent introduire de nouveaux problèmes.

Performance

Un thème peut dégrader les performances d’un site même lorsqu’il ne contient aucune fonctionnalité complexe.

Des images trop lourdes, des polices externes inutiles, des animations excessives ou des scripts chargés sans nécessité peuvent ralentir l’affichage.

Pour une première version, il est préférable de limiter les dépendances.

Notre démonstrateur utilise volontairement une police système et ne charge aucune bibliothèque JavaScript supplémentaire.

Cela simplifie l’architecture, sans constituer une mesure de performance réelle.

Sécurité

La sécurité d’un thème ne se limite pas à l’absence de formulaires.

Si le développement évolue vers l’utilisation de PHP, d’options personnalisées ou de données provenant des utilisateurs, il faudra appliquer les règles de validation, de contrôle des permissions et d’échappement adaptées.

Un thème ne doit pas non plus masquer volontairement des traitements externes ou introduire des mécanismes inutiles de collecte de données.

Traduction et internationalisation

Un thème destiné à plusieurs utilisateurs doit pouvoir être traduit.

Les chaînes définies dans les fichiers PHP doivent utiliser les fonctions d’internationalisation appropriées.

Les textes présents dans les modèles de blocs et les parties de modèles nécessitent également une stratégie de traduction adaptée à leur mode de distribution.

Le simple fait de déclarer un Text Domain ne rend pas automatiquement tous les textes traduisibles.

Étape 12 — Préparer un thème pour WordPress.org

Il faut distinguer deux objectifs.

Le premier consiste à créer un thème pour un usage personnel ou pour un client.

Le second consiste à publier ce thème dans le répertoire officiel WordPress.org.

La seconde démarche implique des exigences supplémentaires.

Respecter les règles de distribution

Un thème proposé au répertoire officiel doit notamment respecter les exigences de licence et les directives de l’équipe chargée de leur examen.

Le code et les ressources distribuées doivent être compatibles avec les conditions applicables.

Il faut également examiner les licences des images, icônes, polices et éventuelles bibliothèques tierces.

Ne pas transformer le thème en plugin

Les directives WordPress.org distinguent les fonctionnalités de présentation des fonctionnalités qui doivent rester disponibles indépendamment du thème.

Un thème ne doit pas servir à distribuer des fonctionnalités métier qui disparaîtraient lors de son remplacement.

Les formulaires métier, types de contenus personnalisés et autres fonctionnalités indépendantes relèvent généralement d’une extension.

Tester avec Theme Check

WordPress propose une extension de contrôle appelée Theme Check.

Elle permet d’identifier différents problèmes susceptibles d’affecter la conformité du thème.

Il faut toutefois distinguer les contrôles automatisés et l’examen réalisé pour une publication officielle.

Un rapport favorable ne constitue pas une certification ni une garantie d’acceptation.

Compléter le dossier de distribution

Avant une soumission, il faut notamment préparer :

• Une documentation claire.
• Les informations de licence.
• Les éventuelles mentions relatives aux ressources tierces.
• Une capture représentative du thème.
• Les fichiers nécessaires à son fonctionnement.
• Une archive ZIP propre.
• Les résultats des essais de compatibilité.

Les exigences exactes doivent être contrôlées dans les directives officielles au moment de la soumission.

Notre exemple constitue une base pédagogique. Il n’a pas été soumis à une revue officielle et ne doit pas être présenté comme un thème approuvé.

Les erreurs fréquentes lors de la création d’un thème

Confondre le contenu et sa présentation

Insérer directement les textes d’un site dans les modèles limite leur réutilisation.

Un thème doit privilégier les blocs dynamiques pour afficher les contenus gérés par WordPress.

Modifier un thème commercial directement

Les modifications peuvent être perdues lors d’une mise à jour.

Lorsqu’il s’agit de personnaliser un thème existant, un thème enfant ou une autre méthode d’extension adaptée est généralement préférable.

Multiplier les dépendances

Chaque bibliothèque supplémentaire peut introduire des contraintes de maintenance, de sécurité et de compatibilité.

Il faut justifier les dépendances par un besoin réel.

Ignorer les personnalisations enregistrées

Un modèle modifié depuis l’éditeur de site peut prendre le dessus sur le fichier fourni avec le thème.

Cette particularité doit être prise en compte lors des essais et des migrations.

Oublier les pages particulières

Une page d’erreur 404, une archive, une recherche ou une page sans image à la une peuvent révéler des défauts invisibles sur la page d’accueil.

Le développement d’un thème complet nécessite des essais sur plusieurs types de contenus.

Confondre fonctionnement et conformité

Un thème qui fonctionne sur une installation locale n’est pas automatiquement compatible avec toutes les versions de WordPress, tous les navigateurs ou les exigences du répertoire officiel.

Chaque affirmation de compatibilité doit reposer sur des essais documentés.

Comment faire évoluer notre premier thème ?

Une fois cette base maîtrisée, plusieurs évolutions deviennent possibles.

Il est notamment envisageable d’ajouter des modèles spécifiques pour les archives, les recherches et les erreurs 404.

Le thème peut également proposer plusieurs variations de styles, des compositions de blocs réutilisables et des modèles de pages adaptés à différents usages.

Une architecture plus avancée pourra intégrer une stratégie typographique complète, des espacements cohérents, des composants réutilisables et une documentation de maintenance.

Le développement peut ainsi progresser par étapes, sans transformer immédiatement un exercice pédagogique en projet complexe.

Conclusion — Construire un thème, c’est comprendre l’architecture de WordPress

Créer un thème WordPress moderne ne nécessite pas obligatoirement un constructeur de pages commercial ou une plateforme de génération de code.

Un fichier de déclaration, un fichier de configuration JSON et quelques modèles de blocs permettent déjà de comprendre les mécanismes essentiels.

La véritable difficulté apparaît lorsque le thème doit fonctionner dans des situations variées : contenus différents, personnalisations utilisateur, appareils mobiles, exigences d’accessibilité et évolutions de WordPress.

C’est précisément pour cette raison qu’une démarche progressive est préférable.

Un thème professionnel ne se résume pas à son apparence. Il doit être compréhensible, maintenable, adaptable et suffisamment fiable pour accompagner l’évolution d’un site.

Notre premier thème de blocs constitue une base d’apprentissage. La prochaine étape consistera à approfondir son système graphique, ses modèles et ses contrôles avant d’envisager une distribution.

Sources et documentation officielle

Les références suivantes ont été consultées pour préparer ce guide :

WordPress Developer — Theme Structure

Theme Structure

WordPress Developer — Introduction to theme.json

Introduction to theme.json

WordPress Developer — Templates

https://developer.wordpress.org/themes/templates/templates

WordPress Developer — Template Parts

https://developer.wordpress.org/themes/templates/template-parts/

WordPress Developer — Template Hierarchy

https://developer.wordpress.org/themes/templates/template-hierarchy

WordPress Developer — Query Loop

https://developer.wordpress.org/block-editor/reference-guides/core-blocks/core-blocks-theme/core-block-query

WordPress Developer — Releasing Your Theme

https://developer.wordpress.org/themes/releasing-your-theme/

WordPress Developer — Theme Review Guidelines

https://developer.wordpress.org/themes/releasing-your-theme/theme-review-guidelines/

WordPress Developer — Testing

https://developer.wordpress.org/themes/releasing-your-theme/testing

Article pédagogique ATOOLPHA — 22 octobre 2026. Les extraits présentés constituent un exemple de développement manuel. Leur fonctionnement complet, leur accessibilité et leur conformité à une distribution officielle doivent être vérifiés sur une installation WordPress de test.