Créer un plugin WordPress commence parfois par quelques lignes de PHP. Concevoir une extension destinée à rester fiable au fil des mises à jour exige toutefois davantage qu’un fichier placé dans wp-content/plugins.
Un plugin s’intègre au cycle d’exécution de WordPress. Il utilise ses hooks, ses APIs et son système de permissions. Il stocke parfois des données et ajoute une interface d’administration. Cette proximité avec le CMS explique autant sa puissance que les précautions nécessaires lors de son développement.
WordPress résume lui-même le principe fondamental du développement d’extension : les fonctionnalités personnalisées s’ajoutent au moyen de plugins plutôt qu’en modifiant les fichiers du cœur. Le CMS écrase en effet ses fichiers lors des mises à jour.
Ce guide détaille les principales étapes de création d’un plugin WordPress, depuis le premier fichier PHP jusqu’aux choix d’architecture, de sécurité et de maintenance qui transforment un simple morceau de code en extension réellement exploitable.
Sommaire de l’article
Qu’est-ce qu’un plugin WordPress ?
Un plugin est un ensemble de fichiers chargé par WordPress afin d’ajouter une fonctionnalité ou de modifier son comportement sans intervenir dans les fichiers du cœur.
Dans sa forme la plus simple, un plugin tient dans un unique fichier PHP contenant un en-tête reconnu par WordPress. Dès que le besoin s’élargit, les fichiers se répartissent généralement entre logique métier, administration, scripts, styles et fonctions spécialisées.
Cette indépendance constitue aussi la principale différence avec le fichier functions.php d’un thème. Lorsque la fonctionnalité appartient au site et non à son apparence, un plugin WordPress offre une séparation beaucoup plus cohérente.
Nous avons détaillé ce choix dans notre article consacré à plugin WordPress ou functions.php.
Avant de créer un plugin WordPress, définir précisément sa responsabilité
La première étape ne concerne pas PHP.
Elle consiste à déterminer ce que l’extension prend réellement en charge.
Concevoir un plugin autour d’une responsabilité identifiable simplifie sa compréhension et ses futures évolutions. À l’inverse, une extension qui devient progressivement le réceptacle de toutes les personnalisations du site finit souvent par concentrer des fonctions sans rapport entre elles.
Avant le développement, il est donc utile de définir le comportement attendu. Il faut également identifier les données concernées et les utilisateurs autorisés à agir dessus. Cette analyse révèle rapidement les interactions nécessaires avec WordPress.
La structure technique vient ensuite.
Choisir un nom, un slug et un préfixe distinctifs
WordPress fonctionne dans un écosystème où de nombreux plugins chargent simultanément des fonctions, des classes, des options et des hooks.
Deux extensions qui déclarent le même nom global créent une collision susceptible d’entraîner une erreur fatale ou un comportement inattendu.
La documentation officielle recommande donc un préfixe suffisamment distinctif pour les fonctions, classes, options et autres éléments exposés globalement. WordPress recommande au minimum quatre caractères et privilégie cinq caractères ou davantage. Les préfixes génériques comme wp_ sont à éviter pour le code spécifique d’un plugin.
Un plugin Evolyon fictif pourrait ainsi utiliser le préfixe :
evlyn_Une fonction générique comme :
save_settings()deviendrait :
evlyn_save_settings()Les namespaces PHP constituent une autre manière de réduire le risque de collision sur des architectures plus élaborées.
Étape 1 : créer le dossier du plugin WordPress
Les plugins classiques se trouvent dans :
wp-content/plugins/Créons par exemple un dossier :
wp-content/plugins/evolyon-exemple/Puis un fichier PHP principal :
evolyon-exemple.phpNous obtenons :
wp-content/
└── plugins/
└── evolyon-exemple/
└── evolyon-exemple.phpWordPress recommande de regrouper les fichiers d’une extension dans son propre répertoire dès que celle-ci dépasse le cas extrêmement simple du fichier unique.
Étape 2 : ajouter l’en-tête du plugin
WordPress reconnaît une extension grâce au commentaire placé au début de son fichier PHP principal.
Le strict minimum se limite à Plugin Name. Le CMS reconnaît cependant de nombreux champs supplémentaires comme la description, la version, l’auteur, la version minimale de WordPress, la version PHP requise ou le domaine de traduction.
Un premier fichier ressemble par exemple à ceci :
Après enregistrement du fichier, le plugin apparaît dans l’écran Extensions de WordPress.
La vérification de ABSPATH bloque l’exécution directe du fichier principal en dehors de WordPress. Le Plugin Handbook recommande cette précaution pour les fichiers qui exécutent du code en dehors d’une classe ou d’une fonction.
Les champs Requires at least et Requires PHP
Un plugin WordPress destiné à être installé sur plusieurs environnements gagne à déclarer ses prérequis.
Les champs :
Requires at least:
Requires PHP:indiquent les versions minimales prises en charge.
Ces valeurs ne se choisissent pas arbitrairement. Elles découlent des fonctions utilisées par le plugin et surtout des versions réellement testées.
Le champ Update URI mérite une attention particulière
WordPress prend également en charge le champ :
Update URI:Il présente un intérêt important pour certains plugins privés ou distribués en dehors du répertoire officiel.
Sa présence aide à éviter qu’une extension tierce portant un nom similaire sur WordPress.org soit considérée à tort comme une mise à jour du plugin privé. La documentation officielle inclut désormais explicitement ce champ dans les en-têtes disponibles.
C’est un détail discret, mais particulièrement pertinent lors du développement d’extensions sur mesure.
Étape 3 : créer une première fonctionnalité
Un plugin vide est déjà reconnu par WordPress, mais il n’exécute encore aucune action.
Ajoutons un exemple volontairement simple : afficher une notification dans l’administration pour les utilisateurs disposant des droits nécessaires.
function evlyn_example_admin_notice() {
if ( ! current_user_can( 'manage_options' ) ) {
return;
}
printf(
'%s
',
esc_html__( 'Le plugin Evolyon Exemple est actif.', 'evolyon-exemple' )
);
}
add_action( 'admin_notices', 'evlyn_example_admin_notice' );Ce morceau de code introduit déjà plusieurs concepts essentiels du développement WordPress.
La fonction contient la logique du plugin. current_user_can() contrôle les permissions. esc_html__() prépare une chaîne traduisible et sécurise son affichage. Enfin, add_action() relie notre fonction à un événement WordPress.
C’est précisément ce dernier mécanisme qui constitue le cœur de la majorité des plugins.
Comprendre les hooks WordPress
Les hooks créent des points d’interaction entre WordPress et les extensions.
Ils évitent de modifier le fonctionnement du CMS directement dans son code source. Un plugin attend qu’un événement se produise ou qu’une donnée passe par un point précis, puis exécute sa propre logique.
WordPress distingue deux grandes familles de hooks : les actions et les filtres.
Les actions WordPress
Une action déclenche une fonction à un moment précis du cycle d’exécution.
init, admin_menu, wp_enqueue_scripts ou save_post figurent parmi les nombreux points d’entrée disponibles dans WordPress.
Un exemple très simple :
function evlyn_example_init() {
// Initialisation du plugin.
}
add_action( 'init', 'evlyn_example_init' );Lorsque WordPress atteint l’action init, la fonction evlyn_example_init() s’exécute.
Une action réalise une opération. Elle ne renvoie pas une valeur destinée à remplacer celle reçue.
Les filtres WordPress
Un filtre intervient sur une donnée puis renvoie sa nouvelle valeur.
Prenons un exemple volontairement simple :
function evlyn_example_excerpt_length( $length ) {
return 30;
}
add_filter( 'excerpt_length', 'evlyn_example_excerpt_length' );WordPress transmet ici la longueur d’extrait existante à notre fonction. Celle-ci retourne une nouvelle valeur.
La présence du return est essentielle. Un filtre modifie une donnée destinée à poursuivre son chemin dans WordPress.
Créer ses propres hooks
Développer une extension plus évoluée ne consiste pas seulement à utiliser les hooks de WordPress.
Elle peut exposer ses propres actions et filtres afin de laisser d’autres développements adapter son comportement.
WordPress recommande cette pratique pour les plugins destinés à rester extensibles. Les hooks personnalisés utilisent do_action() et apply_filters(). Leur nom doit être suffisamment spécifique pour éviter les collisions.
Cette approche devient particulièrement intéressante lorsqu’un plugin constitue une véritable brique métier au sein du site.
Comment organiser les fichiers d’un plugin WordPress ?
Un petit plugin spécialisé n’a aucune raison de recevoir immédiatement une architecture complexe comportant vingt classes.
WordPress le rappelle dans ses bonnes pratiques : la structure dépend directement de la taille et de la responsabilité de l’extension. Une architecture excessive nuit autant à la lisibilité qu’un fichier unique devenu gigantesque.
Lorsque le plugin grandit, une organisation de ce type offre une base cohérente :
evolyon-exemple/
├── evolyon-exemple.php
├── uninstall.php
├── includes/
│ ├── class-plugin.php
│ └── helpers.php
├── admin/
│ ├── class-admin.php
│ ├── css/
│ └── js/
├── public/
│ ├── css/
│ └── js/
└── languages/Le fichier principal initialise l’extension.
Le répertoire includes reçoit la logique partagée. admin regroupe les comportements propres au back-office. public contient les ressources utilisées côté visiteur.
La séparation ne constitue pas une obligation formelle. Elle sert avant tout la lisibilité et la maintenance.
Lorsqu’il faut concevoir un plugin plus complexe, classes et namespaces structurent encore davantage le projet. L’objectif reste néanmoins identique : chaque partie du plugin doit avoir une responsabilité identifiable.
Activation, désactivation et suppression : trois événements différents
Ces trois étapes sont souvent confondues.
WordPress leur attribue pourtant des rôles distincts.
Que faire à l’activation d’un plugin ?
L’activation correspond à l’installation logique de la fonctionnalité.
Elle sert notamment à initialiser des options, créer une structure nécessaire au plugin ou actualiser des règles de réécriture lorsque le développement l’exige.
Exemple :
function evlyn_example_activate() {
add_option( 'evlyn_example_version', '1.0.0' );
}
register_activation_hook(
__FILE__,
'evlyn_example_activate'
);Le code d’activation doit rester ciblé. Une tâche coûteuse exécutée inutilement à chaque requête n’a aucune raison d’y être déplacée, pas plus qu’une opération normale du plugin n’a de raison d’être répétée à chaque activation.
Que faire à la désactivation ?
Désactiver un plugin signifie interrompre son fonctionnement, pas nécessairement supprimer ses données.
Une routine de désactivation sert par exemple à nettoyer un cache temporaire ou certaines ressources transitoires.
function evlyn_example_deactivate() {
delete_transient( 'evlyn_example_cache' );
}
register_deactivation_hook(
__FILE__,
'evlyn_example_deactivate'
);Une désactivation temporaire ne doit pas effacer aveuglément les réglages ou données métier de l’utilisateur.
Et lors de la suppression du plugin ?
La suppression répond à une autre logique.
WordPress prévoit notamment un fichier uninstall.php exécuté lorsque l’utilisateur supprime réellement l’extension depuis l’administration.
Sur un plugin métier, la stratégie de suppression mérite une décision explicite. Certaines extensions conservent volontairement leurs données. D’autres proposent un réglage laissant ce choix à l’utilisateur.
Ce comportement doit être documenté.
Où stocker les données d’un plugin WordPress ?
Tous les plugins n’ont pas besoin de créer une nouvelle table SQL.
WordPress expose déjà plusieurs mécanismes adaptés aux cas les plus courants.
Les réglages globaux trouvent naturellement leur place dans l’Options API. Les informations associées à un contenu, un utilisateur ou une taxonomie s’appuient généralement sur les mécanismes de métadonnées correspondants.
La documentation WordPress recommande d’examiner les possibilités offertes par les métadonnées avant de créer une table dédiée. Une table personnalisée devient pertinente lorsqu’un modèle de données indépendant, son volume ou ses besoins de requêtage le justifient réellement.
Utiliser l’Options API pour les réglages
Un réglage simple s’enregistre ainsi :
add_option( 'evlyn_example_color', '#000000' );Il se récupère ensuite avec :
$color = get_option( 'evlyn_example_color' );Et s’actualise avec :
update_option( 'evlyn_example_color', '#ffffff' );WordPress fournit également la Settings API pour construire des interfaces de réglages cohérentes dans l’administration et associer leur enregistrement aux mécanismes natifs du CMS.
Quand créer une table personnalisée ?
Une table spécifique devient parfois justifiée pour des données nombreuses qui ne correspondent pas naturellement aux objets WordPress existants.
Dans ce cas, WordPress fournit notamment dbDelta() pour créer ou faire évoluer la structure de la table. La documentation recommande également de versionner sa structure afin de gérer les futures migrations.
Créer une table ne constitue donc pas le point de départ systématique de la création d’un plugin WordPress.
C’est une décision d’architecture.
La sécurité doit être intégrée dès le développement
Un plugin exécute du code à l’intérieur de WordPress. Lorsqu’il reçoit des données d’un formulaire, d’un utilisateur, d’une API ou de la base de données, il doit les traiter comme potentiellement non fiables.
La documentation Security de WordPress résume cette logique de manière très claire : contrôler les données entrantes, s’appuyer sur les APIs du CMS et échapper les données au moment de leur affichage.
Consulter la documentation officielle WordPress sur la sécurité des développements
Contrôler les capacités de l’utilisateur
Être connecté à WordPress ne signifie pas être autorisé à réaliser n’importe quelle action.
Un plugin doit vérifier la capacité correspondant à l’opération :
if ( ! current_user_can( 'manage_options' ) ) {
return;
}L’utilisation des capacités WordPress reste préférable à une logique fondée uniquement sur le nom du rôle.
Utiliser les nonces pour les actions sensibles
Un nonce aide WordPress à vérifier que la requête provient d’un contexte attendu.
Il constitue une protection contre certaines requêtes forgées, mais il ne remplace jamais un contrôle d’autorisation. WordPress insiste explicitement sur ce point : un nonce ne doit pas être utilisé comme système d’authentification ou de contrôle d’accès.
La sécurité d’une action repose donc sur plusieurs vérifications complémentaires.
Valider et assainir les données entrantes
Une donnée reçue ne doit pas être stockée telle quelle.
Un champ texte classique utilise par exemple :
$value = sanitize_text_field(
wp_unslash( $_POST['evlyn_label'] ?? '' )
);Lorsque le format attendu est strict, une validation explicite reste encore préférable à une transformation silencieuse.
Échapper les données lors de leur affichage
Une valeur destinée à apparaître dans du HTML doit être échappée selon son contexte.
Pour du texte :
echo esc_html( $value );Pour un attribut HTML :
echo esc_attr( $value );Pour une URL :
echo esc_url( $url );Le bon échappement intervient au plus près de la sortie.
Concevoir une interface d’administration cohérente
Un plugin métier inclut souvent des réglages ou une interface de gestion.
WordPress fournit déjà les mécanismes nécessaires pour ajouter des menus et construire des pages de réglages. La Settings API prend notamment en charge une partie du traitement des formulaires et s’intègre au système de permissions de l’administration.
Réutiliser ces composants présente un autre avantage : l’interface reste familière pour les utilisateurs de WordPress.
Concevoir une extension sur mesure ne justifie généralement pas de recréer entièrement une application parallèle dans le back-office lorsque les composants natifs répondent déjà au besoin.
Charger les scripts et styles uniquement lorsqu’ils sont utiles
Un plugin peut ajouter du CSS ou du JavaScript au site.
Le piège consiste à charger ces ressources partout alors qu’elles ne servent que sur une page précise.
Une extension utilisée uniquement dans un écran d’administration ne devrait pas ajouter automatiquement ses scripts au front-office. Une fonctionnalité présente sur une seule page n’a pas davantage besoin de charger son JavaScript sur toutes les autres.
WordPress recommande de distinguer le code d’administration du code public et d’adapter l’architecture aux besoins réels du plugin.
Cette discipline améliore la lisibilité du projet et limite le travail exécuté inutilement.
Un plugin WordPress doit-il utiliser des classes ?
Pas nécessairement.
Le développement orienté objet constitue un outil d’organisation, pas une condition de qualité.
Un plugin de cinquante lignes centré sur une seule tâche reste parfaitement compréhensible avec quelques fonctions correctement préfixées.
Lorsque l’extension grandit, les classes et namespaces facilitent la séparation des responsabilités et réduisent les risques de collision.
WordPress souligne précisément ce principe dans ses recommandations : l’architecture doit rester proportionnée à la taille du plugin. Développer un petit plugin n’implique aucunement de reproduire artificiellement la structure d’une application beaucoup plus vaste.
La sophistication technique n’est donc jamais un objectif en soi.
Comment gérer les performances d’un plugin ?
Le nombre de fichiers ou la présence d’une classe ne détermine pas à lui seul l’impact d’une extension.
Les performances dépendent surtout du travail réalisé lors de chaque requête.
Une requête SQL coûteuse exécutée sur toutes les pages aura davantage d’impact qu’une architecture comportant plusieurs fichiers bien organisés mais chargés uniquement lorsqu’ils servent réellement.
La réflexion porte donc sur le cycle d’exécution du plugin.
Une donnée rarement modifiée mérite parfois une mise en cache. Une opération lourde n’a pas forcément sa place sur chaque chargement de page. Un script réservé à l’administration ne doit pas être chargé sur le site public.
Le développement doit également surveiller les options stockées et leur mode de chargement. Le regroupement de réglages liés dans une même option réduit parfois le nombre d’opérations en base.
Cette logique s’inscrit directement dans une démarche plus globale de développement WordPress où l’architecture de la fonctionnalité compte autant que son résultat visible.
Respecter les WordPress Coding Standards
Un plugin destiné à durer gagne à suivre des conventions constantes.
Les WordPress Coding Standards couvrent PHP, JavaScript, CSS, HTML et la documentation du code. Ils visent notamment la lisibilité, l’interopérabilité et certaines pratiques liées à la sécurité.
WordPress recommande également l’outil WordPress Coding Standards basé sur PHP_CodeSniffer pour automatiser une partie de ces contrôles.
L’objectif dépasse l’esthétique du code.
Une base cohérente accélère les revues, simplifie la reprise du plugin et réduit certaines erreurs banales lors des évolutions.
Versionner le plugin dès le départ
Même une extension privée mérite un numéro de version.
Le champ :
Version: 1.0.0donne un repère clair lors des déploiements.
Une évolution fonctionnelle ou corrective entraîne ensuite une nouvelle version. WordPress utilise la fonction PHP version_compare() pour comparer les numéros présents dans les métadonnées de plugin.
Pour les développements qui modifient leur propre structure de données, un numéro de version dédié à la base devient également utile afin de déclencher les migrations appropriées.
Le versioning facilite aussi le diagnostic lorsqu’un problème apparaît : l’environnement indique immédiatement quelle mouture du plugin est active.
Tester le plugin avant son installation en production
Un plugin fonctionnel sur le poste du développeur n’est pas encore un plugin validé.
Les tests doivent couvrir son comportement normal, mais aussi les changements d’état.
L’activation doit réussir sur une installation où le plugin n’a jamais été présent. La désactivation ne doit pas casser le site. Une réactivation doit retrouver les données attendues. La suppression doit respecter la stratégie prévue.
Les permissions méritent également plusieurs profils utilisateurs. Un administrateur et un éditeur ne disposent pas des mêmes capacités.
Les versions de WordPress et de PHP déclarées comme compatibles doivent être réellement testées.
WordPress fournit notamment wp-env, un environnement local basé sur Docker destiné au développement et au test de plugins et de thèmes. Il intègre également les fichiers PHPUnit correspondant à la version WordPress utilisée.
Un projet plus conséquent associera ces tests à une analyse du code et à des contrôles automatisés.
Faut-il développer directement sur le site en ligne ?
Non pour un développement significatif.
Une erreur PHP dans un plugin s’exécute au sein du site WordPress lui-même. Une fonction mal appelée ou une dépendance manquante entraîne parfois immédiatement une erreur fatale.
Le développement s’effectue donc sur un environnement séparé.
Le plugin rejoint ensuite un environnement de validation où son comportement est contrôlé dans des conditions proches de la production avant son déploiement définitif.
Cette séparation prend encore davantage d’importance lorsqu’une extension intervient dans les données métier du site.
Comment préparer un plugin WordPress pour sa distribution ?
Un plugin destiné à un seul projet et une extension publiée sur WordPress.org ne répondent pas exactement aux mêmes contraintes de diffusion.
Une extension privée peut être livrée sous forme d’archive ZIP et installée depuis l’administration WordPress.
Une publication sur WordPress.org implique davantage de règles. Licence compatible, documentation, fichiers de traduction, informations destinées au répertoire et respect des guidelines entrent alors dans le processus.
Dans les deux cas, l’organisation du code et la documentation restent précieuses.
Un plugin privé mérite autant d’attention à la maintenance qu’un plugin public dès lors qu’il joue un rôle important dans l’activité de l’entreprise.
Peut-on créer un plugin WordPress grâce à l’intelligence artificielle ?
Les outils d’IA générative accélèrent désormais certaines étapes de développement.
Ils produisent une structure initiale, expliquent une API ou suggèrent une fonction. Ils deviennent également utiles lors de la documentation ou de la revue d’un morceau de code.
Ils ne transforment cependant pas un cahier des charges imprécis en architecture fiable par magie.
Un code généré reste du code à auditer.
Les appels aux APIs WordPress doivent être contrôlés. Les permissions restent à vérifier. Les entrées utilisateur nécessitent validation et assainissement. Les sorties doivent être échappées. Les migrations de données et scénarios de suppression exigent également une réflexion explicite.
L’IA change donc la manière de produire une partie du code, mais pas les exigences qui rendent un plugin exploitable en production.
Quelles sont les erreurs fréquentes lors de la création d’un plugin WordPress ?
La première consiste à commencer à développer un plugin sans avoir isolé sa responsabilité réelle. Le code s’étend alors au gré des demandes et devient rapidement difficile à comprendre.
La seconde apparaît lorsque des fonctions, options ou classes reçoivent des noms trop génériques. Les collisions deviennent possibles dès qu’une autre extension utilise les mêmes identifiants.
Une autre erreur fréquente consiste à confondre désactivation et désinstallation. Effacer toutes les données dès la désactivation expose l’utilisateur à une perte inattendue.
La sécurité arrive également trop souvent après la fonctionnalité. Un formulaire qui fonctionne mais ignore les capacités, les nonces ou l’échappement n’est pas terminé.
Enfin, l’excès d’architecture pose le problème inverse. Transformer une fonctionnalité très simple en système abstrait composé d’une multitude de classes rend parfois la maintenance plus difficile au lieu de la simplifier.
La bonne architecture reste celle qui correspond au besoin réel.
Quelle structure choisir pour un plugin WordPress ?
- Fonctionnalité très courte et isolée : un fichier PHP clairement préfixé.
- Plugin comportant plusieurs fonctions liées : fichier principal et fichiers regroupés dans
includes. - Interface d’administration distincte : séparation entre logique générale et partie
admin. - Plugin comportant front et administration : répertoires dédiés aux deux contextes.
- Plugin métier évolutif : classes ou namespaces, responsabilités séparées et versioning.
- Extension stockant beaucoup de données spécifiques : analyse du modèle de données avant l’éventuelle création d’une table dédiée.
WordPress ne prescrit donc pas une architecture unique. Ses propres bonnes pratiques présentent plusieurs modèles possibles en fonction de l’ampleur du projet.
Quand un plugin sur mesure devient-il la bonne solution ?
Créer son propre plugin prend tout son sens lorsqu’une fonctionnalité mérite de vivre indépendamment du thème et qu’aucune extension standard ne répond correctement au besoin.
Le développement sur mesure devient particulièrement pertinent lorsque le site doit intégrer une logique métier précise. Il évite alors d’empiler plusieurs extensions simplement pour contourner leurs limites respectives.
Le code reste centré sur les usages réellement nécessaires.
Cette approche implique en contrepartie une responsabilité supplémentaire : l’extension doit suivre les évolutions de WordPress et de son environnement technique.
C’est précisément pour cette raison qu’un développement de plugin WordPress ne se résume pas à écrire quelques fonctions PHP. L’architecture, les tests et la maintenabilité font partie du développement dès sa conception.
Créer un plugin WordPress qui reste exploitable dans le temps
La création technique d’un premier plugin WordPress tient finalement en quelques minutes : un dossier, un fichier PHP et un en-tête suffisent pour que WordPress reconnaisse l’extension.
La vraie différence apparaît ensuite.
Un plugin destiné à durer doit s’intégrer au fonctionnement de WordPress sans modifier son cœur. Ses hooks doivent intervenir au bon endroit. Les données doivent suivre une stratégie cohérente. Chaque action sensible doit respecter les permissions et les règles de sécurité du CMS.
Son architecture doit également rester proportionnée au besoin.
C’est cette combinaison qui transforme une simple personnalisation PHP en véritable extension WordPress : une fonctionnalité identifiable, indépendante du thème et suffisamment structurée pour continuer à évoluer avec le site.
Consulter le Plugin Developer Handbook officiel de WordPress
