Le développeur WordPress travaille à deux niveaux. En PHP, il écrit des extensions et des thèmes qui se branchent sur le cœur par les hooks, actions et filtres, déclare des types de contenu et ajoute des routes à l'API REST. En JavaScript, il construit des blocs pour l'éditeur Gutenberg avec React et block.json, et règle les thèmes à blocs dans theme.json. Les questions d'entretien d'un développeur WordPress couvrent les deux, plus la sécurité et la performance, qui font la différence en production.
Un constructeur de pages et une vingtaine d'extensions : c'est ce qu'il y a derrière beaucoup de CV qui citent WordPress. Ce savoir-faire d'intégration a sa valeur et ne suffit pas pour un poste de développement. La personne doit savoir écrire une extension propre : nonces et contrôle des droits, données nettoyées à l'entrée et échappées à la sortie, requêtes préparées, aucune modification du cœur ni d'un thème parent.
Le CMS a beaucoup bougé. WordPress 6.9 a introduit l'Abilities API et la 7.0, sortie en mai 2026, a ajouté un client d'IA au cœur et une nouvelle interface d'administration. Un profil resté aux thèmes classiques et à jQuery aura du mal sur un site en blocs. Le PDF contient 30 questions sur six axes et un cas de 20 minutes sur une extension de prise de rendez-vous.
Le socle technique d'un développeur WordPress
Hooks : actions et filtres
Le mécanisme qui permet de modifier WordPress sans toucher à son code. Une action exécute du code à un moment donné (add_action), un filtre modifie une valeur avant son usage (add_filter), avec une priorité et un nombre d'arguments. Tout le reste du métier repose dessus, et une question sur la différence entre les deux trie vite les profils.
Thèmes classiques, thèmes enfants et thèmes à blocs
Un thème classique suit la hiérarchie de templates PHP (single.php, archive.php), un thème enfant le personnalise sans perdre les mises à jour du parent. Un thème à blocs décrit ses gabarits en HTML de blocs et ses styles dans theme.json, modifiables dans l'éditeur de site. Les deux modèles cohabitent dans les projets en cours.
Blocs Gutenberg
L'éditeur de contenu est écrit en React. Un bloc sur mesure se déclare dans block.json, s'écrit avec les paquets @wordpress, se compile avec @wordpress/scripts et peut être rendu côté serveur en PHP. L'Interactivity API, dans le cœur depuis la version 6.5, ajoute de l'interactivité côté visiteur sans framework supplémentaire.
Types de contenu, taxonomies et ACF
register_post_type et register_taxonomy créent des contenus métier : offres, événements, fiches produit. Advanced Custom Fields ajoute des champs et des blocs sans écrire toute l'interface, et sa version PRO revient souvent dans les offres. WordPress.org maintient depuis 2024 un fork d'ACF, Secure Custom Fields, ce qui pose parfois des questions de compatibilité.
API REST et headless
WordPress expose ses contenus en JSON sous /wp-json/, et register_rest_route ajoute des routes sur mesure. En headless, un front Next.js ou Nuxt lit ces données, ou celles de WPGraphQL, et WordPress ne sert plus que de back-office. Chaque route doit déclarer qui a le droit de l'appeler.
WooCommerce
L'extension e-commerce de WordPress. Le développeur adapte le tunnel par des hooks ou par les blocs Panier et Commande, écrit des passerelles de paiement ou des règles de livraison, et doit connaître le stockage des commandes en tables dédiées (HPOS), activé par défaut sur les nouvelles boutiques.
Sécurité du code
La grande majorité des failles publiées concernent des extensions et des thèmes. Les réflexes attendus : nonces contre le CSRF, current_user_can pour les droits, sanitize_* à l'entrée, esc_* à la sortie, $wpdb->prepare pour le SQL, et un suivi des vulnérabilités avec Wordfence, Patchstack ou WPScan.
Performance, cache et WP-CLI
Cache de page, cache d'objets persistant avec Redis, transients pour les appels coûteux, requêtes WP_Query bornées et images optimisées. WP-CLI sert aux migrations, au remplacement d'URL dans une base aux données sérialisées et aux mises à jour scriptées. Une installation gérée avec Composer, comme Bedrock, facilite le déploiement par Git.
Selon le poste, le développeur WordPress intègre des maquettes, crée des extensions métier, maintient un parc de sites ou construit des boutiques WooCommerce. Il travaille avec un chef de projet, un designer et souvent une équipe qui édite les contenus elle-même. Les intitulés varient : développeur WordPress, intégrateur WordPress, développeur PHP WordPress, webmaster développeur. Précisez dans l'offre la part d'intégration et de développement, le type de thème en place (constructeur de pages, thème classique, thème à blocs), la présence de WooCommerce et l'hébergement, qui change les compétences attendues en déploiement et en cache.
Les compétences qui séparent un développeur d'un intégrateur WordPress
- Hooks, boucle et WP_Query
- Thèmes enfants et thèmes à blocs
- Blocs Gutenberg en React
- Extensions, types de contenu et API REST
- Sécurité du code WordPress
- Performance, cache et WooCommerce
Cinq questions techniques pour un développeur WordPress
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · junior à confirmé
Quelle différence entre une action et un filtre ? Donnez un exemple de chacun que vous avez écrit.
Une bonne réponseUne action exécute du code à un moment donné sans rien renvoyer, par exemple charger un script sur wp_enqueue_scripts ou envoyer un e-mail sur save_post. Un filtre reçoit une valeur, la modifie et doit la renvoyer, comme the_content ou excerpt_length. La personne cite la priorité et le nombre d'arguments d'add_filter, et sait retirer un hook posé par une extension avec remove_action, à la même priorité et après son ajout.
Signal d'alerteIgnorer qu'un filtre doit renvoyer la valeur, ou modifier directement un fichier du cœur ou d'une extension tierce.
Question 2 · confirmé
Un formulaire de votre extension enregistre des données en base. Quelles protections ajoutez-vous ?
Une bonne réponseUn nonce vérifié à la réception (wp_nonce_field puis check_admin_referer ou wp_verify_nonce), un contrôle des droits avec current_user_can, un nettoyage de chaque champ (sanitize_text_field, absint, sanitize_email), l'écriture par les fonctions de l'API ou une requête préparée avec $wpdb->prepare, puis un échappement à l'affichage (esc_html, esc_attr, esc_url, wp_kses).
Signal d'alerteInsérer $_POST directement dans une requête SQL, ou croire qu'un nonce suffit à vérifier les droits de l'utilisateur.
Question 3 · confirmé
Comment créez-vous un bloc Gutenberg sur mesure, et quand choisissez-vous un rendu côté serveur ?
Une bonne réponseUn fichier block.json qui déclare le nom, les attributs, les scripts et les styles, une fonction edit en React avec les composants de @wordpress/block-editor, une compilation avec @wordpress/scripts et l'enregistrement par register_block_type. Rendu serveur (render.php) quand le contenu dépend de données qui changent, comme les derniers articles, ou pour éviter les erreurs de validation après une modification du balisage. Fonction save statique pour un contenu figé.
Signal d'alerteNe connaître que les blocs ACF ou un constructeur de pages, ou ne pas savoir pourquoi l'éditeur affiche « Ce bloc contient du contenu inattendu ou non valide ».
Question 4 · confirmé
Une page d'archive met six secondes à s'afficher. Comment trouvez-vous la cause ?
Une bonne réponseQuery Monitor pour voir les requêtes SQL, les hooks lents et les appels HTTP externes. Causes fréquentes : une WP_Query avec meta_query sur une table postmeta très volumineuse, posts_per_page à -1, des requêtes dans une boucle, des options chargées en autoload trop lourdes, une extension qui appelle une API distante à chaque page. Corrections : requête revue, taxonomie plutôt que champ méta pour filtrer, transients ou cache d'objets Redis, cache de page.
Signal d'alerteInstaller une extension de cache de plus sans regarder les requêtes.
Question 5 · confirmé
Vous ajoutez une route à l'API REST pour une application mobile. Comment la sécurisez-vous ?
Une bonne réponseregister_rest_route avec un permission_callback qui vérifie les droits réels, jamais __return_true pour une donnée privée, des arguments déclarés avec validation et nettoyage, et une réponse limitée aux champs utiles. Pour authentifier une application externe : les mots de passe d'application du cœur, ou OAuth et JWT via une extension maintenue.
Signal d'alerteUne route sans permission_callback, ou une clé secrète écrite en dur dans l'application mobile.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Recruter un développeur WordPress, vos questions
Quelle différence entre un intégrateur WordPress et un développeur WordPress ?
L'intégrateur monte des sites à partir d'un thème, d'un constructeur de pages et d'extensions existantes, et adapte le CSS. Le développeur écrit du code : extensions sur mesure, blocs Gutenberg en React, routes d'API, intégrations avec d'autres outils. Les deux métiers sont utiles, mais l'entretien n'est pas le même. Si le poste comporte du développement, faites lire ou écrire un peu de PHP, même à un profil présenté comme senior.
Quelles compétences demander à un développeur WordPress ?
Un PHP récent (WordPress recommande PHP 8.3 ou plus), les hooks et WP_Query, les thèmes enfants et les thèmes à blocs avec theme.json, les blocs Gutenberg en React, l'API REST et les règles de sécurité du code. Selon le poste, ajoutez WooCommerce, ACF, le multilingue, le headless avec Next.js, WP-CLI et Composer. Git et un environnement local sont attendus partout. Un constructeur de pages ne remplace aucune de ces compétences.
Quel test technique pour un développeur WordPress ?
Une petite extension à écrire en une ou deux heures suffit : un type de contenu, un formulaire ou une route d'API, un bloc simple. Regardez les nonces, les droits, l'échappement et la structure du code plutôt que l'apparence. Une variante plus courte consiste à faire relire une extension qui contient des failles volontaires. En vingt minutes, vous voyez si la personne repère une requête non préparée ou une route sans contrôle des droits.
Faut-il un profil WooCommerce pour une boutique en ligne ?
Oui dès que la boutique a des règles propres : tarifs par client, livraison, paiement, synchronisation avec un ERP. WooCommerce a ses hooks, son stockage des commandes en tables dédiées (HPOS) et ses blocs Panier et Commande, qui changent la façon d'adapter le tunnel. Un bon développeur WordPress s'y met vite. Demandez quand même une boutique réelle qu'il a maintenue, et ce qu'il a fait lors d'une mise à jour majeure de WooCommerce.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
