Plugins WordPress : chapitre 1 | Introduction — du simple script au plugin

Aucune mise en œuvre n’est demandée à la lecture de cette introduction. Au mieux, vous pouvez faire des recherches sur certains termes rencontrés (functions.php, snippet, Custom Code…) pour vous familiariser avec le vocabulaire. La partie pratique interviendra dans le chapitre suivant.

Vous avez créé un super script JavaScript ? Vous avez imaginé une petite fonction PHP ? Bref, vous souhaitez ajouter votre propre contribution à WordPress, qu’elle ait été réalisée en hand coding ou en co-construction avec une IA.

Et maintenant arrive une question toute simple : comment injecter ce code dans WordPress ?

Pour du JavaScript, plusieurs possibilités semblent s’offrir à nous. Peut-on placer le script directement dans un widget HTML ? Faut-il plutôt le charger dans le <head> de la page ? Dans le <body> ? À la fin de la page, dans le footer ?

Et pour du PHP ? Faut-il modifier le fichier functions.php du thème ? Utiliser un système de snippets ? Où placer notre fonction pour qu’elle soit exécutée correctement par WordPress ?

Toutes ces solutions existent, mais une autre question va rapidement se poser. Que se passe-t-il si nous voulons réutiliser notre code sur un autre site ? Et si nous voulons pouvoir le désactiver en un clic ? Et si nous voulons le mettre à jour sans rechercher quelques lignes perdues au milieu d’un thème ou d’une page Elementor ?

Bref, existe-t-il une solution plus facile à maintenir, pratique, flexible et réutilisable ?

La réponse est oui : le plugin WordPress.

Mais avant d’en arriver là, nous allons faire un tour d’horizon des différentes techniques permettant d’ajouter notre propre code à WordPress. Nous verrons leurs avantages, leurs limites et surtout dans quelles situations les utiliser.

Puis nous terminerons par une étape supplémentaire : co-construire notre propre plugin WordPress avec une IA.

L’objectif ne sera pas de devenir développeur de plugins WordPress, mais de comprendre suffisamment leur fonctionnement pour être capable de piloter leur création, de savoir ce que fait le code produit et de l’intégrer proprement dans un projet.

C’est parti !

1. Première possibilité : placer directement du JavaScript dans la page

Vous avez déjà pris l’habitude, dans le chapitre précédent, de tester un script généré par IA directement dans la console DevTools — une méthode rapide, temporaire, et idéale pour valider qu’un script fonctionne bien avant d’aller plus loin.

Mais un script testé en console ne vit que le temps d’un rechargement de page : il disparaît dès qu’on quitte ou qu’on actualise. Pour qu’il continue à fonctionner durablement, il faut l’intégrer réellement quelque part dans le site — c’est là qu’intervient une deuxième étape de test, différente de la première : tester le script une fois intégré, dans son vrai contexte d’exécution sur le site concerné.

Ce chapitre reprend donc là où le précédent s’arrêtait : après avoir validé un script en console, comment le faire vivre durablement dans WordPress ?

Commençons par le cas le plus simple. Vous disposez d’un petit script JavaScript et vous souhaitez simplement le faire fonctionner sur une page de votre site.

Avec un constructeur de pages comme Elementor, une première solution consiste à utiliser un widget HTML. On peut par exemple y placer :

Lorsque la page est chargée, le navigateur rencontre la balise <script> et exécute le JavaScript.

Quand cette méthode est-elle intéressante ?

Elle est particulièrement pratique pour :

tester rapidement un petit script ;
réaliser une expérimentation ;
ajouter une fonctionnalité qui ne concerne qu’une seule page ;
comprendre le fonctionnement d’un script avant de chercher une solution plus élaborée.

Pour un prototype ou un exercice, c’est donc une solution parfaitement envisageable.

Mais elle montre rapidement ses limites

Imaginez maintenant que votre script soit utilisé sur dix pages. Vous allez devoir le copier dix fois. Puis vous découvrez une erreur dans votre code. Il faut alors retrouver et modifier les dix copies.

Notre petit script commence déjà à devenir beaucoup moins pratique à maintenir.

2. Header, body, footer : où placer le JavaScript ?

Vous rencontrerez régulièrement ces trois termes lorsqu’il est question d’injecter du code dans une page :

Header correspond à la partie <header> du document HTML.
Body correspond au contenu de la page, situé dans <body>.
Footer désigne généralement une injection effectuée vers la fin du document, avant la fermeture de </body>.

Pourquoi existe-t-il plusieurs emplacements ?

Parce qu’un script n’a pas toujours besoin d’être exécuté au même moment. Certains codes doivent être disponibles très tôt lors du chargement de la page. D’autres peuvent attendre que le contenu HTML soit présent.

Pour beaucoup de scripts JavaScript qui agissent sur des éléments de la page, un chargement vers la fin du document est souvent adapté. Mais il n’existe pas une règle disant : « Le JavaScript doit toujours être placé dans le footer. » Le bon emplacement dépend du fonctionnement du script.

Concrètement, avec Elementor

Si votre script ne concerne qu’une seule page, la solution la plus simple reste de le placer directement sur cette page, via un widget HTML — pas besoin d’aller plus loin.

Mais si vous voulez que ce script s’exécute sur l’ensemble du site, il faut le placer dans le Header Elementor ou le Footer Elementor — les modèles globaux qu’Elementor Pro charge automatiquement sur toutes les pages du site, pas juste sur une seule.

Rappel des bons usages : placez votre script dans le footer, sauf si vous avez une vraie nécessité technique de l’exécuter dès le tout début du chargement de la page — auquel cas seulement, envisagez le header.

3. Utiliser les possibilités d’injection proposées par WordPress ou un constructeur

Certains thèmes, constructeurs de pages et extensions permettent d’ajouter du code dans différentes parties du site.

Le Custom Code d’Elementor Pro

Elementor Pro propose une fonctionnalité nommée Custom Code (accessible depuis le menu Elementor de l’administration WordPress). Elle permet d’ajouter du code — HTML, CSS ou JavaScript — sans avoir à le placer manuellement sur une page précise, et surtout de choisir son emplacement parmi trois options qui reprennent exactement la logique qu’on vient de voir : Head, Body Start, Body End.

Vous pouvez aussi définir une priorité (utile si plusieurs scripts sont chargés au même endroit, pour contrôler dans quel ordre ils s’exécutent) et des conditions d’affichage — le code entier du site, une page précise, une catégorie… Ce sont les mêmes conditions que celles utilisées pour les templates Header/Footer du Theme Builder, mais elles s’appliquent ici à du code, pas à un template visuel — c’est bien la fonctionnalité qui correspond, concrètement, à ce qu’on entendait par « Header/Body/Footer » dans ce chapitre.

D’autres solutions WordPress proposent le même principe.

Cela apporte déjà un avantage important par rapport au code copié directement dans une page : le code peut être centralisé. Un seul script peut alors être chargé sur plusieurs pages. C’est beaucoup plus facile à maintenir.

Mais nous restons encore dans une logique d’injection de code. Nous n’avons pas réellement créé une fonctionnalité WordPress autonome.

4. Et pour PHP ?

Avec PHP, la situation est différente. Le JavaScript est principalement exécuté dans le navigateur du visiteur. PHP, lui, est exécuté sur le serveur, avant que le résultat de la page soit envoyé au navigateur.

On ne peut donc pas simplement placer quelques lignes de PHP dans un widget HTML Elementor et espérer qu’elles soient exécutées. Il faut placer ce code dans un endroit où WordPress peut réellement l’exécuter.

Le fichier functions.php

Vous rencontrerez très souvent le fichier functions.php lorsque vous chercherez comment ajouter une petite fonction PHP à WordPress. Mais qu’est-ce que c’est exactement ?

functions.php est un fichier qui appartient au thème WordPress actif. On le trouve dans l’arborescence de WordPress, à l’intérieur du dossier du thème :

wp-content/ └── themes/ └── nom-du-theme/ └── functions.php

Par exemple, avec le thème Hello Elementor :

wp-content/ └── themes/ └── hello-elementor/ └── functions.php

Lors du fonctionnement du site, WordPress charge automatiquement le fichier functions.php du thème actif. Ce fichier permet au thème d’ajouter ou de modifier certains comportements de WordPress grâce à du code PHP.

On peut donc être tenté d’y ajouter directement notre propre fonction :

function mon_message() { return ‘Bonjour WordPress !’; }

Précision importante : définir une fonction ne suffit pas à la faire agir sur le site. Une fonction PHP placée seule dans functions.php ne produit aucun effet visible tant qu’elle n’est pas explicitement appelée, ou « accrochée » à un endroit précis de WordPress via ce qu’on appelle un hook (les fonctions add_action() ou add_filter()). On ne détaille pas cette notion ici — elle reviendra naturellement lorsqu’on construira notre plugin avec l’IA.

Techniquement, c’est possible. Mais attention : functions.php appartient au thème.

Si vous ajoutez directement votre code dans le fichier functions.php d’un thème provenant d’un éditeur, une future mise à jour du thème peut remplacer ce fichier et faire disparaître vos modifications.

Un vrai risque à connaître : contrairement à un plugin — qui peut être désactivé en un clic si quelque chose tourne mal — une erreur dans functions.php peut rendre le site entier inaccessible, puisque ce fichier est chargé à chaque page, avant même que WordPress n’ait fini de démarrer. Une simple faute de syntaxe peut suffire à provoquer un écran blanc sur tout le site, sans bouton « désactiver » pour revenir en arrière — il faut alors se reconnecter en FTP pour corriger ou supprimer le code fautif directement dans le fichier. C’est une raison supplémentaire, très concrète, de préférer un plugin dès que la fonctionnalité dépasse quelques lignes ponctuelles.

Le thème enfant

C’est notamment pour cette raison que WordPress utilise le principe du thème enfant.

Un thème enfant n’est pas une simple copie du thème parent — c’est un thème séparé qui hérite automatiquement de son apparence et de son fonctionnement, tout en permettant de le personnaliser sans jamais toucher à ses fichiers d’origine. Concrètement, pour qu’il fonctionne, un thème enfant a besoin, à minima, d’un fichier style.css avec un en-tête particulier qui indique explicitement à WordPress à quel thème parent il se rattache. Son functions.php, lui, vient s’ajouter à celui du thème parent — il ne le remplace pas, il agit en complément.

L’intérêt : le thème parent peut être mis à jour sans jamais effacer vos personnalisations, puisqu’elles vivent dans un fichier séparé, jamais écrasé.

wp-content/ └── themes/ ├── hello-elementor/ │ └── functions.php │ └── hello-elementor-child/ ├── style.css └── functions.php

Vous pouvez alors ajouter certaines personnalisations PHP dans le functions.php du thème enfant sans modifier directement le thème principal.

Concrètement, avec votre configuration habituelle : si votre site utilise le thème « Hello Elementor », et que vous souhaitez ajouter une personnalisation directement liée à ce thème, il faudrait créer un thème enfant de Hello Elementor — pas modifier Hello Elementor lui-même, pour les raisons de mise à jour qu’on vient de voir.

La création d’un thème enfant n’est pas abordée dans ce chapitre — elle suit une procédure propre, avec ses propres règles à respecter. Ce qu’il faut retenir ici, c’est simplement le principe : une personnalisation liée au thème doit vivre dans un thème enfant, jamais directement dans le thème original.

Mais une autre question doit être posée : notre fonctionnalité appartient-elle vraiment au thème ?

Imaginons que nous développions une fonctionnalité permettant d’ajouter un comportement particulier à WooCommerce. Pourquoi cette fonctionnalité devrait-elle être liée au thème Hello Elementor ? Et pourquoi devrait-elle disparaître si nous changeons de thème ?

Nous arrivons à une distinction importante : une personnalisation directement liée au thème peut avoir sa place dans le thème enfant ; une fonctionnalité indépendante du thème a davantage vocation à être séparée.

5. Les plugins de snippets : gérer ses petits codes PHP plus facilement

Et avant de créer notre propre plugin, il existe justement une solution intermédiaire très pratique.

Un snippet est tout simplement un petit morceau de code.

Il existe des plugins WordPress spécialement conçus pour enregistrer et gérer ces petits morceaux de code sans avoir à modifier directement le fichier functions.php. Parmi les solutions les plus connues, vous rencontrerez notamment les plugins Code Snippets et WPCode.

Le principe est très simple. Vous installez le plugin, puis vous disposez d’une interface dans l’administration de WordPress permettant d’ajouter votre code. Par exemple :

function mon_message() { return ‘Bonjour WordPress !’; }

Votre snippet peut ensuite être enregistré et géré depuis WordPress.

L’intérêt devient immédiatement évident :

pas besoin de modifier directement functions.php ;
vos snippets sont centralisés ;
vous pouvez les retrouver facilement ;
vous pouvez les modifier ;
vous pouvez les activer ou les désactiver ;
ils ne disparaissent pas simplement parce que vous changez de thème.

Pour de petites personnalisations PHP, c’est donc une solution particulièrement pratique.

Deux limites à garder en tête, notamment si vous livrez le site à un client :

Installer un plugin de snippets qui exécute du PHP reste une porte ouverte : le client a accès à cette interface dans son administration WordPress, et peut très bien s’y aventurer — par curiosité ou par erreur — et altérer accidentellement le code de votre fonction, sans forcément s’en rendre compte.

Et la question de la réutilisation reste entière : pour faire fonctionner ce même snippet sur un autre site, il faut réinstaller le plugin de snippets à chaque fois — un plugin qui, lui aussi, peut un jour souffrir d’une mise à jour non compatible, ou être abandonné par son éditeur.

Alors, pourquoi aller plus loin ?

Imaginons maintenant que votre petit snippet devienne une véritable fonctionnalité. Vous souhaitez l’installer sur plusieurs sites. Vous souhaitez pouvoir transmettre cette fonctionnalité à quelqu’un d’autre. Elle commence à utiliser plusieurs fonctions. Elle a besoin de son propre fichier JavaScript. Peut-être même de plusieurs fichiers. Vous aimeriez lui donner un nom et un numéro de version.

Bref, notre petit morceau de code commence à devenir un petit logiciel pour WordPress.

C’est précisément le rôle d’un plugin.

6. Synthèse des solutions

Avant de passer au plugin lui-même, voici un récapitulatif de toutes les solutions vues jusqu’ici, chacune résumée en deux phrases : son avantage principal, et sa limite principale.

Solution	Avantage	Inconvénient
Injection directe dans la page (widget HTML)	Rapide à mettre en place, idéal pour tester ou expérimenter.	À dupliquer manuellement sur chaque page, donc très difficile à maintenir au-delà d’un usage ponctuel.
Injection centralisée (Custom Code Elementor Pro, ou équivalent)	Un seul endroit à maintenir, applicable à plusieurs pages avec des conditions d’affichage précises.	Reste une simple injection de code, pas une vraie fonctionnalité WordPress autonome, activable/désactivable en un clic.
functions.php du thème	Exécution PHP fiable, directement intégrée au thème actif, sans plugin supplémentaire.	Une erreur peut rendre tout le site inaccessible, et le code disparaît à la prochaine mise à jour du thème s’il n’est pas dans un thème enfant.
functions.php du thème enfant	Les personnalisations survivent aux mises à jour du thème parent.	Pertinent uniquement si la fonctionnalité est vraiment liée à ce thème précis, et disparaît si on change de thème.
Plugin de snippets (Code Snippets, WPCode)	Interface centralisée dans l’administration, snippets activables/désactivables, indépendants du thème.	Dépend d’un plugin tiers à réinstaller sur chaque site, accessible et modifiable par erreur par le client une fois le site livré.
Plugin WordPress dédié	Fonctionnalité autonome, activable/désactivable, réutilisable et transmissible telle quelle, indépendante du thème.	Demande de connaître (ou de faire piloter par une IA) la structure minimale d’un plugin WordPress.

7. Transformer notre code en plugin WordPress

Le mot plugin peut donner l’impression que nous allons entrer dans quelque chose de très complexe. Pourtant, dans sa forme minimale, un plugin WordPress peut être extrêmement simple.

Un plugin est avant tout un ensemble de fichiers que WordPress est capable d’identifier et de charger. Dans le cas le plus élémentaire, nous pouvons même commencer avec :

mon-plugin/ └── mon-plugin.php

Un dossier. Un fichier PHP. C’est tout.

Le fichier PHP contient notamment un en-tête permettant à WordPress de comprendre qu’il s’agit d’un plugin :

<?php /** * Plugin Name: Mon premier plugin * Description: Une petite fonctionnalité personnalisée. * Version: 1.0 */

Une fois le dossier placé dans :

wp-content/ └── plugins/ └── mon-plugin/ └── mon-plugin.php

WordPress peut reconnaître notre extension. Elle apparaît alors dans la liste des extensions de l’administration.

Et surtout, nous obtenons quelque chose de très intéressant : Activer. Désactiver. Notre fonctionnalité possède désormais son propre interrupteur.

8. Comment installer notre propre plugin dans WordPress ?

Nous avons maintenant notre plugin :

mon-plugin/ └── mon-plugin.php

Très bien. Mais comment l’envoyer dans WordPress ? Il existe principalement deux méthodes.

Méthode 1 : déposer directement le dossier du plugin

La première solution consiste à travailler avec le dossier du plugin tel quel, sans créer d’archive ZIP. Il suffit de déposer le dossier complet :

mon-plugin/

dans le dossier des plugins de WordPress :

wp-content/ └── plugins/ └── mon-plugin/ └── mon-plugin.php

Avec Local by Flywheel

Si vous travaillez en local avec Local by Flywheel, c’est probablement la méthode la plus pratique pour développer et tester votre propre plugin.

Vous pouvez ouvrir les fichiers de votre site avec l’Explorateur de fichiers, vous rendre dans :

app/ └── public/ └── wp-content/ └── plugins/

puis y déposer directement le dossier de votre plugin. Vous pouvez ensuite modifier ses fichiers, retourner dans WordPress, actualiser la page et tester vos modifications.

C’est particulièrement pratique pendant la phase de développement : pas besoin de recréer un fichier ZIP à chaque modification.

Et sur un site distant ?

Le même principe peut être utilisé sur un véritable serveur à l’aide d’un client FTP ou SFTP. Vous vous connectez à l’hébergement, vous ouvrez :

wp-content/plugins/

et vous transférez le dossier complet de votre plugin.

Dans les deux cas, le principe est donc identique :

mon-plugin/ ↓ wp-content/plugins/

Une fois le dossier présent à cet emplacement, WordPress peut détecter le plugin.

Méthode 2 : créer une archive ZIP et utiliser l’installateur WordPress

Il existe une méthode encore plus simple lorsque le plugin est terminé ou lorsque vous souhaitez le transmettre à quelqu’un.

Nous allons compresser le dossier complet du plugin au format ZIP :

mon-plugin.zip

Attention à conserver la structure du plugin à l’intérieur de l’archive :

mon-plugin.zip └── mon-plugin/ └── mon-plugin.php

Dans l’administration de WordPress, rendez-vous ensuite dans :

Extensions → Ajouter une extension → Téléverser une extension

Sélectionnez mon-plugin.zip, puis lancez l’installation.

WordPress décompresse l’archive et place automatiquement le plugin dans wp-content/plugins/. Il ne reste alors plus qu’à activer le plugin.

Quelle méthode choisir ?

Pendant la création et les tests : dossier en brut + Local by Flywheel est particulièrement pratique. Vous modifiez directement les fichiers et pouvez immédiatement tester le résultat.

Sur un serveur auquel vous accédez directement : dossier en brut + FTP/SFTP permet également de transférer ou modifier le plugin.

Pour distribuer, conserver ou installer facilement un plugin : archive ZIP + installateur WordPress est généralement la solution la plus pratique.

9. Pourquoi créer un plugin pour quelques lignes de code ?

Parce que le nombre de lignes n’est pas forcément le bon critère.

Imaginons un script qui ajoute une petite fonctionnalité très utile à votre site. Même s’il ne contient que 30 lignes de code, vous souhaitez peut-être :

le conserver indépendamment du thème ;
l’activer ou le désactiver facilement ;
le réutiliser sur un autre site ;
le transmettre à quelqu’un ;
le faire évoluer ;
identifier clairement à quoi il sert.

Dans ce cas, créer un petit plugin peut être beaucoup plus propre que de disperser son code dans différentes zones de WordPress.

Nous pouvons maintenant résumer notre progression :

test ponctuel → injection dans une page
code partagé → injection centralisée
petite personnalisation PHP → snippet
personnalisation liée au thème → thème enfant
fonctionnalité autonome et réutilisable → plugin

Le plugin n’est donc pas systématiquement « la meilleure solution ». Il devient la meilleure solution lorsque notre besoin devient une véritable fonctionnalité autonome.

10. Un plugin peut contenir du PHP et du JavaScript

Nous avons jusqu’ici séparé JavaScript et PHP. Un plugin va justement nous permettre de les réunir proprement.

Notre dossier pourrait par exemple évoluer ainsi :

mon-plugin/ │ ├── mon-plugin.php └── js/ └── script.js

Le fichier PHP constitue le point d’entrée du plugin. Il peut demander à WordPress de charger notre fichier JavaScript. WordPress possède justement des mécanismes prévus pour cela.

Plutôt que d’insérer manuellement :

dans nos pages, un plugin peut demander à WordPress de charger correctement son script. C’est notamment le rôle de la fonction :

wp_enqueue_script()

Le mot enqueue signifie ici que nous demandons à WordPress de prendre en charge le chargement de notre fichier.

Nous ne déposons plus notre code un peu partout dans les pages. Nous l’intégrons au fonctionnement de WordPress.

11. Et c’est ici que l’IA devient particulièrement intéressante

Nous venons cependant de franchir un cap. Créer correctement un plugin demande de connaître plusieurs notions :

la structure d’un plugin ;
les fonctions WordPress ;
les hooks ;
le chargement des scripts ;
les chemins vers les fichiers ;
certaines règles de sécurité ;
les bonnes pratiques de WordPress.

Un concepteur designer n’a pas nécessairement vocation à devenir développeur PHP ou développeur de plugins WordPress. En revanche, il peut avoir besoin de créer une petite fonctionnalité spécifique pour répondre à un besoin dans un projet.

C’est précisément là que la co-construction avec une IA peut devenir intéressante.

L’objectif n’est pas de demander : « Fais-moi un plugin WordPress. » Puis d’installer aveuglément le résultat.

L’objectif est de piloter sa construction. Nous allons pouvoir expliquer notre besoin, définir les contraintes, demander une architecture simple, faire produire le code, demander des explications, tester le résultat, identifier les erreurs et améliorer progressivement notre plugin.

Autrement dit, nous n’allons pas seulement demander à l’IA de coder à notre place. Nous allons apprendre à piloter le codage avec l’IA — exactement la même logique de co-construction déjà appliquée dans le chapitre précédent, cette fois transposée à PHP et à la structure d’un plugin.

12. Notre prochain défi : construire un plugin avec une IA

Pour la suite, nous allons partir d’un besoin concret. Nous définirons d’abord précisément ce que notre plugin doit faire. Puis nous demanderons à une IA de nous proposer une architecture. Nous vérifierons ensemble les fichiers nécessaires. Nous lui ferons produire le code progressivement. Nous installerons notre plugin dans WordPress. Nous le testerons.

Et, comme dans un véritable projet, il est fort possible que tout ne fonctionne pas parfaitement du premier coup. Ce sera justement l’occasion de voir comment dialoguer avec une IA pour corriger et faire évoluer notre réalisation.

À la fin, notre fonctionnalité ne sera plus un morceau de code perdu dans une page. Elle apparaîtra dans WordPress parmi nos extensions avec deux possibilités particulièrement appréciables :

Activer. Désactiver.

Bienvenue dans la création de plugins WordPress avec l’IA.