Développement WordPress : plugins, thèmes et blocs

Devenir développeur WordPress, pas seulement utilisateur

Vous savez installer WordPress, choisir un thème, brancher quelques extensions. Vient le jour où un client demande une fonctionnalité qu’aucune extension ne fournit exactement : un annuaire des artisans du quartier, un type de contenu sur mesure, un bloc d’édition maison, une donnée exposée à une application mobile. À ce moment précis, la frontière se dessine entre celui qui assemble des briques toutes faites et celui qui fabrique les briques. Ce guide principal vous fait franchir cette frontière.

WordPress 7.0, sorti le 20 mai 2026, propulse plus de quatre sites sur dix dans le monde. Derrière la simplicité de son tableau de bord se cache une plateforme d’extension remarquablement cohérente : un système de hooks pour brancher votre code sans toucher au cœur, une API de contenu pour inventer vos propres types de données, un éditeur de blocs construit en React, une API REST qui transforme n’importe quel site en back-end de données, et depuis WordPress 5.9 une édition complète du site (FSE), consolidée par la version 6.0, qui réécrit la façon dont on conçoit les thèmes. Maîtriser ces cinq domaines techniques, c’est pouvoir répondre « oui, je peux le coder » à presque n’importe quelle demande.

Cette série construit une extension réelle et un thème d’affichage de bout en bout : Annuaire Quartier, un répertoire d’artisans et de services de proximité (plombier, couturier, mécanicien, menuisier) que l’on retrouve dans toutes nos villes. Chaque tutoriel ajoute une brique concrète à ce projet, jusqu’à obtenir un module installable, éditable depuis Gutenberg, interrogeable par une API, et affiché par un thème de blocs moderne.

🎯 Ce que ce parcours vous permettra de faire

• Structurer une extension WordPress propre, activable, désinstallable proprement, conforme aux conventions de l’écosystème.
• Brancher votre code sur le cœur de WordPress avec les actions et les filtres, sans jamais modifier un fichier du noyau.
• Créer vos propres types de contenu et leurs champs personnalisés, visibles dans l’éditeur et dans l’API.
• Développer un bloc Gutenberg en React, avec ses réglages dans la barre latérale, et un rendu dynamique côté serveur.
• Exposer et consommer des données via l’API REST, avec un contrôle d’accès correct.
• Construire un thème de blocs (Full Site Editing) piloté par theme.json, modifiable sans écrire une ligne de PHP de gabarit.

🗺️ Le parcours d’apprentissage

Les six tutoriels se suivent dans un ordre pensé pour que chaque notion s’appuie sur la précédente. Voici l’itinéraire et la brique d’Annuaire Quartier que chacun construit :

1. Anatomie d’une extension — on pose le squelette du plugin annuaire-quartier : en-tête, activation, désactivation, désinstallation. Démarrer ici.
2. Les hooks : actions et filtres — on greffe nos premiers comportements sur le cœur de WordPress. Comprendre les hooks.
3. Types de contenu et métadonnées — on déclare le type « artisan » et ses champs (téléphone, quartier, métier). Créer le type artisan.
4. Un bloc Gutenberg en React — on fabrique le bloc « Liste d’artisans » pour l’éditeur. Coder le bloc.
5. L’API REST WordPress — on expose les artisans à une application externe via un endpoint maison. Exposer l’API.
6. Un thème de blocs FSE — on affiche l’annuaire avec un thème piloté par theme.json. Construire le thème.

Vous pouvez suivre l’ensemble dans l’ordre pour bâtir le projet entier, ou piocher le tutoriel qui répond à votre besoin du moment. Chacun est autonome et indique ses prérequis.

Pourquoi développer pour WordPress reste un pari rentable

Un argument revient souvent : « WordPress, c’est dépassé, il faut coder en React/Node ». La réalité du terrain raconte autre chose. Pour un commerce de Dakar, une mutuelle de Bamako, une école d’Abidjan, la commande la plus fréquente reste un site qu’on peut mettre à jour soi-même, sans développeur sous la main en permanence. WordPress remplit ce cahier des charges mieux que n’importe quelle stack maison. Le développeur qui sait l’étendre se place exactement là où la demande est dense.

Techniquement, l’écosystème a beaucoup mûri. L’éditeur de blocs (nom de code Gutenberg) est désormais une application React à part entière ; développer un bloc, c’est faire du JavaScript moderne. L’API REST native fait de chaque site un fournisseur de données pour une application mobile ou un autre service. Le Full Site Editing rapproche le travail du thème de celui d’un système de design déclaratif. Autrement dit, les compétences que vous bâtissez ici — composants React, API HTTP, configuration déclarative — sont transférables bien au-delà de WordPress.

Enfin, l’extensibilité de WordPress repose sur un principe sain que cette série martèle : on n’édite jamais le cœur. On se branche dessus. Un cœur intact se met à jour sans casser votre travail. Cette discipline, qui paraît contraignante au début, est ce qui rend un site maintenable sur la durée.

Les concepts fondamentaux à maîtriser

Le système de hooks

WordPress exécute son code en passant par des centaines de points de branchement appelés hooks. Il en existe deux familles. Les actions déclenchent un comportement à un moment donné (« quand WordPress a fini de charger », « juste avant d’afficher l’entête »). Les filtres laissent passer une valeur que votre code peut transformer avant qu’elle ne soit utilisée (le titre d’un article, le contenu, le texte d’un bouton). Tout le reste découle de cette mécanique : une extension est, pour l’essentiel, un ensemble de fonctions accrochées à des hooks bien choisis.

Les types de contenu

Un article et une page sont deux types de contenu fournis par défaut. WordPress vous laisse en créer d’autres : « artisan », « événement », « produit », « offre d’emploi ». Chaque type personnalisé bénéficie gratuitement de l’éditeur, de la corbeille, des révisions, de l’API. À ces types on attache des métadonnées : des champs sur mesure (un numéro de téléphone, un quartier) stockés à côté du contenu principal.

Les blocs de l’éditeur

Depuis WordPress 5.0, tout contenu est composé de blocs : un paragraphe, une image, un tableau sont des blocs. Vous pouvez créer les vôtres. Un bloc moderne se décrit dans un fichier block.json et se code en React pour la partie éditeur, avec, au choix, un rendu figé (statique) ou un rendu calculé à l’affichage (dynamique, en PHP).

L’API REST

Chaque installation WordPress expose ses données en JSON sous /wp-json/. Vos types de contenu peuvent y figurer automatiquement, et vous pouvez ajouter vos propres routes pour des besoins spécifiques. C’est la porte d’entrée d’un usage « headless » où WordPress sert de back-end à une application développée séparément.

Le thème de blocs et theme.json

Le Full Site Editing remplace les gabarits PHP par des gabarits en HTML de blocs et centralise toute la configuration visuelle (couleurs, typographie, espacements) dans un unique fichier theme.json. Le thème devient un système de design déclaratif que l’on édite en grande partie depuis l’interface, sans toucher au code.

Vue d’ensemble pratique : du squelette au thème

Voici comment les briques s’emboîtent. On commence par le contenant — l’extension — puis on lui donne des comportements, des données, une interface d’édition, une API, et enfin un habillage.

1. L’extension, ce conteneur de code

Une extension WordPress est un dossier dans wp-content/plugins/ contenant au minimum un fichier PHP avec un en-tête de commentaire normalisé. Ce fichier principal sert de point d’entrée : il définit des constantes, branche les hooks d’activation et de désactivation, et charge le reste du code. Le premier tutoriel, l’anatomie d’une extension, construit ce squelette proprement, avec une protection contre l’accès direct et une routine de désinstallation.

2. Les hooks, ce système nerveux

Une fois le squelette en place, on lui donne vie en branchant des fonctions sur le cœur. Ajouter une mention en pied de page, modifier le texte d’extrait, intercepter l’enregistrement d’un contenu : tout passe par add_action() et add_filter(). Le tutoriel sur les actions et les filtres détaille la priorité, le nombre d’arguments, et la différence cruciale entre agir et transformer.

3. Le type « artisan » et ses champs

Le cœur métier d’Annuaire Quartier, c’est la donnée. On déclare un type de contenu « artisan » avec register_post_type() en l’activant dans l’API et dans l’éditeur, puis on lui attache des champs avec register_post_meta(). Le tutoriel types de contenu et métadonnées montre comment rendre ces champs visibles côté éditeur et côté API d’un seul geste.

4. Le bloc d’édition

Pour insérer une liste d’artisans dans une page, on fabrique un bloc dédié. On part de l’outil officiel d’échafaudage, on code le composant React de l’éditeur, on ajoute des réglages dans la barre latérale, et on choisit un rendu dynamique pour que la liste reflète toujours les données à jour. C’est l’objet du tutoriel créer un bloc Gutenberg en React.

5. L’API pour les applications externes

Si un développeur mobile veut afficher l’annuaire dans une application, il lui faut un point d’accès JSON propre. On enregistre une route annuaire/v1/artisans avec register_rest_route(), on contrôle qui y accède, et on renvoie une réponse normalisée. Le tutoriel sur l’API REST WordPress couvre ce parcours.

6. Le thème qui affiche tout

Reste à présenter l’annuaire aux visiteurs. Plutôt qu’un thème classique en PHP, on construit un thème de blocs piloté par theme.json, avec des gabarits en HTML de blocs pour la fiche d’un artisan et pour la liste. Le tutoriel construire un thème de blocs FSE boucle le projet.

L’environnement de développement

Avant de coder, il faut un poste de travail sain. Trois choix structurent le reste.

Un site local. On ne développe jamais directement sur le site en production. Un environnement local — via un outil comme un serveur LAMP local, ou un environnement conteneurisé — vous donne un WordPress jetable sur lequel casser des choses sans conséquence. Activez le mode débogage en plaçant define('WP_DEBUG', true); dans wp-config.php : les avertissements PHP qui resteraient invisibles en production deviennent visibles, et ils vous épargnent des heures.

Un éditeur de code et la chaîne JavaScript. Pour le PHP, n’importe quel éditeur sérieux convient. Pour les blocs Gutenberg, il faut Node.js et npm, car le code React doit être compilé. WordPress fournit l’outil @wordpress/scripts qui masque toute la complexité de cette compilation : une commande pour développer, une autre pour produire la version finale.

La documentation officielle. Le site des développeurs WordPress est la seule source qui fasse autorité sur les fonctions, leurs arguments et leurs évolutions. Prenez l’habitude de vérifier une signature de fonction à la source plutôt que de copier un extrait trouvé au hasard : l’écosystème évolue, et un extrait de 2018 peut utiliser une approche aujourd’hui dépréciée.

Composer avec un hébergement contraint

La plupart des projets clients tournent sur de l’hébergement mutualisé bon marché, avec des limites de mémoire PHP basses (souvent 128 Mo) et pas d’accès SSH. Votre code doit rester économe : on évite de charger l’API REST ou des requêtes lourdes sur chaque page, on met en cache ce qui peut l’être. Testez votre extension avec WP_DEBUG et un profileur de requêtes pour repérer les requêtes SQL inutiles avant qu’elles ne pénalisent un serveur modeste.

Ensuite la bande passante du visiteur final. Un bloc Gutenberg qui charge un gros paquet JavaScript pour afficher trois lignes est un mauvais calcul quand une partie du public est en 3G sur un forfait compté. Préférez, quand c’est possible, le rendu dynamique côté serveur — le bloc renvoie du HTML déjà calculé plutôt que de faire travailler le navigateur. Le thème de blocs aide aussi : theme.json ne charge que les styles utiles.

Côté déploiement, sans SSH ni intégration continue sur les offres d’entrée de gamme, la mise en ligne se fait souvent par transfert FTP/SFTP ou par le gestionnaire de fichiers de l’hébergeur. Versionnez tout de même votre code avec Git en local : un dossier d’extension est un projet Git comme un autre, et vous remercierez votre rigueur le jour d’un retour en arrière. Enfin, prévoyez des coupures de courant : un commit fréquent et une sauvegarde locale du site de développement évitent de perdre une journée de travail à cause d’une panne au mauvais moment.

La discipline du développeur WordPress

Au-delà des APIs, quatre réflexes séparent le code amateur du code professionnel. Ils traversent tous les tutoriels de la série, et il vaut la peine de les nommer une bonne fois.

Sécuriser les entrées et les sorties. WordPress résume sa doctrine de sécurité en une formule : « échapper tard, valider tôt ». Toute donnée qui entre (un champ de formulaire, un paramètre d’URL) doit être nettoyée avec une fonction comme sanitize_text_field() avant d’être enregistrée. Toute donnée qui sort vers le navigateur doit être échappée avec esc_html(), esc_attr() ou esc_url() selon le contexte. Et toute action qui modifie l’état (enregistrer, supprimer) doit être protégée par un jeton anti-CSRF, le nonce WordPress. Ces trois gestes neutralisent la grande majorité des failles d’injection sur un site sur mesure.

Préparer la traduction dès le départ. Même si Annuaire Quartier est en français, on enveloppe chaque chaîne affichée dans une fonction d’internationalisation — __('Téléphone', 'annuaire-quartier') — avec un text domain cohérent. Cela coûte trois caractères à l’écriture et ouvre la porte à une version arabe ou anglaise sans réécrire le code. C’est une habitude, pas une corvée de fin de projet.

Respecter les conventions de nommage. WordPress vit dans un espace de noms global partagé par des milliers d’extensions. Préfixer vos fonctions, vos options et vos métadonnées (ici aq_) évite les collisions qui font planter deux extensions installées côte à côte. Pour du code plus ambitieux, on encapsule dans des classes ou des espaces de noms PHP, ce qui résout le problème à la racine.

Désinstaller proprement. Une extension bien élevée range sa chambre en partant : elle supprime ses options et ses données lors de la désinstallation, via le fichier uninstall.php ou un hook dédié. Un site qui accumule les résidus d’extensions désinstallées finit avec une base de données encombrée. Cette propreté est un signe de maturité que les clients et les pairs remarquent.

Erreurs fréquentes à éviter

Questions fréquentes

Faut-il savoir coder en PHP pour développer sur WordPress ?

Oui pour la partie serveur — extensions, hooks, types de contenu, API REST reposent sur PHP. Pour les blocs Gutenberg, c’est du JavaScript et du React. Un développeur WordPress complet manie les deux, mais on peut commencer par le PHP et venir au JavaScript au moment des blocs.

Extension ou thème : où mettre mon code ?

Règle simple : une fonctionnalité (un type de contenu, une API, un comportement métier) va dans une extension, car elle doit survivre à un changement de thème. La présentation (gabarits, styles) va dans le thème. Mettre la déclaration du type « artisan » dans le thème serait une faute : changer de thème ferait disparaître vos artisans de l’administration.

Gutenberg a-t-il rendu obsolètes les anciens thèmes en PHP ?

Non, les thèmes classiques restent pleinement supportés. Mais les thèmes de blocs (FSE) sont la direction officielle et offrent une édition visuelle complète. Pour un nouveau projet en 2026, le thème de blocs est le choix par défaut, sauf contrainte particulière.

Dois-je utiliser une extension de champs personnalisés ou coder les métadonnées ?

Les deux approches coexistent. Une extension de gestion de champs accélère le prototypage. Coder vos métadonnées avec register_post_meta() vous donne un contrôle total, aucune dépendance, et une intégration native à l’API. Cette série montre la voie « code » pour que vous compreniez ce qui se passe réellement.

Mon bloc doit-il être statique ou dynamique ?

Statique quand le contenu est figé une fois écrit (un encadré, une citation). Dynamique quand le contenu dépend de données qui évoluent (une liste d’artisans qui s’allonge). Pour Annuaire Quartier, la liste est dynamique : elle est recalculée à chaque affichage.

L’API REST de WordPress est-elle sûre par défaut ?

Les routes en lecture des contenus publics sont ouvertes, ce qui est normal. Dès que vous créez une route qui lit des données sensibles ou qui écrit, le permission_callback devient votre rempart : c’est lui qui décide qui a le droit. Le négliger est la faille la plus répandue des endpoints maison.

Comment tester une extension sans casser un site en production ?

Sur un site local ou un sous-domaine de préproduction, jamais directement en production. Activez WP_DEBUG, reproduisez la configuration du client (mêmes extensions, mêmes données d’exemple), et ne déployez qu’après avoir vérifié l’activation, la désactivation et la désinstallation.

Par où commencer

Si vous débutez en développement WordPress, suivez la série dans l’ordre : commencez par l’anatomie d’une extension, qui pose les fondations sur lesquelles tout le reste s’appuie. Si vous avez déjà écrit une extension simple, le tutoriel sur les hooks approfondira la mécanique que vous utilisez sans toujours la nommer. Pour les besoins « données », enchaînez avec les types de contenu puis l’API REST. Pour l’interface, le bloc Gutenberg et le thème de blocs complètent le tableau.

Pour aller à la source, gardez sous la main la documentation des extensions et celle de l’éditeur de blocs : ce sont les références qui font autorité, mises à jour à chaque version de WordPress.

Mots-clés : développement WordPress, extension WordPress, hooks actions filtres, custom post type, bloc Gutenberg React, API REST WordPress, thème de blocs FSE, theme.json.