Créer un plugin WordPress de A à Z : développement manuel et publication officielle

Créer un plugin WordPress ne nécessite ni intelligence artificielle ni plateforme de génération de code. Avec des connaissances de base en PHP, un éditeur de texte et une installation locale de WordPress, il est possible de développer une première fonctionnalité, de comprendre son intégration au CMS et de préparer sa distribution.

ne nécessite ni intelligence artificielle ni plateforme de génération de code. Avec des connaissances de base en PHP, un éditeur de texte et une installation locale de WordPress, il est possible de développer une première fonctionnalité, de comprendre son intégration au CMS et de préparer sa distribution.

Mais faire fonctionner une extension sur son propre site ne signifie pas qu’elle respecte automatiquement les exigences du répertoire officiel WordPress.org. Architecture, sécurité, licences, documentation et tests constituent des étapes essentielles.

Ce guide présente la démarche complète, depuis la création des premiers fichiers jusqu’à la préparation d’une soumission officielle, avec un exemple concret et reproductible.

Comprendre ce qu’est réellement un plugin WordPress

WordPress repose sur un noyau logiciel, appelé WordPress Core, qui fournit les fonctionnalités fondamentales du système : gestion des contenus, utilisateurs, médias, thèmes et administration.

Un plugin, également appelé extension, vient enrichir ce fonctionnement sans modifier directement les fichiers du noyau.

Il peut par exemple :

• Ajouter une fonctionnalité dans l’administration.
• Créer un formulaire ou un outil interactif.
• Proposer de nouveaux blocs ou shortcodes.
• Connecter WordPress à un service externe.
• Automatiser des opérations de maintenance.
• Modifier certains comportements grâce aux hooks WordPress.

Cette séparation est fondamentale. Lorsqu’une mise à jour de WordPress remplace ses fichiers internes, les développements effectués directement dans le noyau risquent d’être perdus.

Une extension correctement conçue utilise les interfaces prévues par WordPress pour faire évoluer le site indépendamment de son fonctionnement principal.

Quelle différence entre un plugin privé et un plugin officiel ?

Il faut distinguer trois situations.

Type d’extension	Utilisation	Exigences
Plugin personnalisé	Un site ou un client particulier	Respect des bonnes pratiques techniques et de sécurité
Plugin distribué directement	Plusieurs installations, hors répertoire officiel	Compatibilité, licence, documentation et maintenance adaptées
Plugin publié sur WordPress.org	Distribution publique via le répertoire officiel	Respect des directives WordPress.org et examen par son équipe

Un plugin n’a donc pas besoin d’être publié sur WordPress.org pour être légitime ou fonctionnel.

En revanche, une publication dans le répertoire officiel implique de respecter les règles propres à cet environnement.

Préparer son environnement de développement

Avant d’écrire la première ligne de PHP, il est préférable de travailler dans une installation indépendante d’un site public.

Les outils nécessaires

Pour suivre ce tutoriel, il faut disposer :

1. D’une installation WordPress fonctionnelle en local.
2. D’une version de PHP compatible avec le plugin à développer.
3. D’un éditeur de code, comme Visual Studio Code.
4. D’un accès aux fichiers de l’installation WordPress.
5. D’un navigateur pour vérifier le résultat.

Un serveur local tel que Laragon, WordPress Studio ou une autre solution compatible peut fournir l’environnement nécessaire.

Pour découvrir ces outils et comprendre leurs différences, consultez notre guide complémentaire : Installer WordPress en local : guide et outils de test.

Pourquoi éviter de développer directement en production ?

Une erreur de syntaxe PHP peut empêcher l’activation d’une extension. Un conflit avec une autre fonctionnalité peut également modifier le comportement du site.

Le développement local permet d’identifier ces problèmes sans perturber les visiteurs.

Il facilite également les essais sur plusieurs configurations avant une éventuelle distribution.

Étape 1 — Créer la structure du plugin

Une extension WordPress peut techniquement se limiter à un seul fichier PHP.

Pour apprendre, cette simplicité constitue un avantage : elle permet de comprendre le mécanisme avant d’introduire une architecture plus complexe.

Ouvrez le répertoire suivant dans votre installation :

wp-content/plugins/

Créez un nouveau dossier nommé :

atoolpha-note-demo

À l’intérieur, créez un fichier :

atoolpha-note-demo.php

L’organisation initiale est donc :

wp-content/
└── plugins/
    └── atoolpha-note-demo/
        └── atoolpha-note-demo.php

Le nom du dossier doit être descriptif et suffisamment distinct pour limiter les risques de conflit avec une extension existante.

Pour une future publication sur WordPress.org, il faudra également vérifier la disponibilité du nom et du slug.

Étape 2 — Déclarer officiellement le plugin auprès de WordPress

WordPress détecte une extension grâce à un commentaire d’en-tête spécifique placé dans son fichier PHP principal.

Dans notre exemple, ouvrez atoolpha-note-demo.php et ajoutez :

<?php
/**
 * Plugin Name:       ATOOLPHA Note Demo
 * Description:       Display a simple note using a shortcode.
 * Version:           1.0.0
 * Requires at least: 6.6
 * Requires PHP:      8.1
 * Author:            ATOOLPHA
 * License:           GPLv2 or later
 * License URI:       https://www.gnu.org/licenses/gpl-2.0.html
 * Text Domain:       atoolpha-note-demo
 */

if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

Les versions WordPress 6.6 et PHP 8.1 sont ici des minimums choisis pour l’exemple, et non des versions déjà qualifiées par des tests. Avant toute distribution, ces déclarations doivent correspondre à la compatibilité réellement vérifiée.

À quoi servent ces informations ?

Le champ Plugin Name permet à WordPress de reconnaître le nom de l’extension. Le numéro de version indique l’évolution du logiciel.

Les champs Requires at least et Requires PHP déclarent les versions minimales nécessaires.

Le champ License renseigne sur les conditions de distribution du code, tandis que Text Domain permet d’associer les chaînes traduisibles à l’extension.

Enfin, la condition ABSPATH empêche la poursuite de l’exécution du fichier lorsqu’il est appelé directement en dehors du chargement normal de WordPress.

Cet exemple constitue une base. Il ne réalise encore aucune opération visible.

Étape 3 — Ajouter une première fonctionnalité

Pour comprendre comment WordPress exécute une extension, nous allons créer un shortcode simple.

Son objectif sera d’afficher un message dans une page ou un article, sans interface d’administration et sans stockage dans la base de données.

Ajoutez le code suivant à la suite du contenu précédent, dans le même fichier PHP :

/**
 * Display a simple editorial note.
 *
 * @param array|string $atts Shortcode attributes.
 * @return string HTML output.
 */
function atoolpha_note_demo_render( $atts ) {

    $atts = shortcode_atts(
        array(
            'text' => __(
                'Back up your website before making changes.',
                'atoolpha-note-demo'
            ),
        ),
        $atts,
        'atoolpha_note_demo'
    );

    $message = sanitize_text_field( $atts['text'] );

    if ( '' === $message ) {
        return '';
    }

    return '<p class="atoolpha-note-demo"><strong>'
        . esc_html__( 'Note:', 'atoolpha-note-demo' )
        . '</strong> '
        . esc_html( $message )
        . '</p>';
}

add_shortcode(
    'atoolpha_note_demo',
    'atoolpha_note_demo_render'
);

Comprendre le fonctionnement du code

La fonction add_shortcode() enregistre un nouveau shortcode dans WordPress.

Elle associe le nom atoolpha_note_demo à une fonction PHP chargée de produire son affichage.

La fonction shortcode_atts() récupère les paramètres autorisés et leur attribue des valeurs par défaut.

La fonction sanitize_text_field() nettoie le texte fourni, tandis que esc_html() protège son affichage dans le HTML.

Les fonctions __() et esc_html__() participent au système de traduction de WordPress.

Les préfixes employés limitent également les risques de collision avec des fonctions et shortcodes appartenant à d’autres extensions.

Pourquoi retourner du HTML plutôt que l’afficher directement ?

Un shortcode doit retourner le contenu qu’il souhaite insérer dans l’article.

L’utilisation de return permet à WordPress de placer le résultat à l’emplacement prévu, contrairement à un affichage direct avec echo, qui peut provoquer un résultat inattendu.

Étape 4 — Tester l’extension dans Gutenberg

Une fois le fichier enregistré, ouvrez l’administration de votre WordPress local.

Accédez à Extensions > Extensions installées.

L’extension ATOOLPHA Note Demo doit apparaître dans la liste si son en-tête est correctement reconnu.

Activez-la.

Créez ensuite une nouvelle page dans Gutenberg, ajoutez un bloc natif Code court, puis insérez :

[atoolpha_note_demo text="Pensez à sauvegarder votre site avant toute modification."]

Enregistrez la page et consultez son aperçu public.

Si tout fonctionne, le message suivant apparaît :

Note: Pensez à sauvegarder votre site avant toute modification.

Le résultat est volontairement simple. Aucun CSS particulier, service externe ou outil d’intelligence artificielle n’est nécessaire.

Cette première expérience illustre le principe fondamental des extensions WordPress : enregistrer une fonctionnalité auprès du CMS, puis laisser WordPress l’exécuter au moment approprié.

Un shortcode est-il identique à un bloc Gutenberg ?

Non.

Le shortcode constitue une interface historique et toujours utilisable de WordPress. Gutenberg propose un bloc dédié permettant de l’intégrer.

Un bloc Gutenberg personnalisé utilise une architecture différente, souvent fondée sur l’API des blocs et JavaScript.

Pour un premier développement en PHP, le shortcode permet de se concentrer sur les mécanismes essentiels avant d’aborder les technologies supplémentaires.

Étape 5 — Comprendre les exigences de sécurité

Un plugin fonctionnel n’est pas nécessairement un plugin sécurisé.

La sécurité doit être envisagée dès le développement, même si la première version semble modeste.

Nettoyer, valider et échapper les données

Ces trois opérations remplissent des fonctions différentes.

Opération	Objectif	Exemple WordPress
Sanitization	Nettoyer une valeur entrante	sanitize_text_field()
Validation	Vérifier qu’une valeur est acceptable	is_numeric() ou règles métier
Escaping	Sécuriser une valeur au moment de l’affichage	esc_html(), esc_attr(), esc_url()

Le choix dépend du type de donnée et de son contexte d’utilisation.

Un texte destiné à l’intérieur d’un paragraphe HTML ne se traite pas exactement comme une URL ou un attribut HTML.

Vérifier les permissions

Si une extension ajoute une interface d’administration ou réalise des opérations réservées à certains utilisateurs, elle doit contrôler leurs capacités.

WordPress propose notamment current_user_can() pour effectuer ces vérifications.

Il ne suffit pas de masquer un bouton aux utilisateurs non autorisés. Le traitement serveur doit lui-même refuser une opération interdite.

Protéger les actions avec des nonces

Les nonces WordPress contribuent à protéger certaines opérations contre les requêtes non souhaitées, notamment les attaques de type CSRF.

Ils ne remplacent toutefois ni l’authentification ni les contrôles d’autorisation.

Notre plugin de démonstration ne reçoit aucun formulaire et ne modifie aucune donnée. Il n’a donc pas besoin d’un mécanisme de nonce pour sa fonctionnalité actuelle.

En revanche, l’ajout futur d’un formulaire d’administration imposera une nouvelle analyse de sécurité.

Étape 6 — Préparer la structure d’une extension distribuable

Lorsque le projet évolue, placer tout le code dans un seul fichier devient moins pratique.

Une architecture plus organisée peut alors être adoptée :

atoolpha-note-demo/
├── atoolpha-note-demo.php
├── readme.txt
├── includes/
│   └── class-note-renderer.php
├── assets/
│   └── note.css
└── languages/

Cette structure est une possibilité d’évolution, pas une obligation imposée à toutes les extensions WordPress.

Le répertoire includes peut accueillir la logique PHP réutilisable, tandis que assets reçoit les ressources utilisées par l’extension.

Le dossier languages peut servir à gérer les fichiers de traduction dans les configurations qui le nécessitent.

Faut-il obligatoirement créer un fichier uninstall.php ?

Non.

Ce fichier est utile lorsqu’une extension doit supprimer ses propres options, tables ou données persistantes lors de sa désinstallation.

Notre démonstrateur n’enregistre aucune donnée. Il n’a donc rien à effacer.

Il faut également distinguer la désactivation et la désinstallation : désactiver une extension ne signifie pas nécessairement supprimer sa configuration.

Pour une extension plus complexe, la politique de conservation et de suppression des données doit être définie explicitement.

Étape 7 — Préparer le fichier readme.txt

Le répertoire WordPress.org utilise un format spécifique de documentation nommé readme.txt.

Ce fichier n’est pas une simple note destinée au développeur. Il contribue directement à présenter le plugin dans le répertoire officiel.

Voici un exemple simplifié :

=== ATOOLPHA Note Demo ===
Contributors: compte-wordpress-org
Tags: shortcode, note, content
Requires at least: 6.6
Tested up to: X.Y
Stable tag: 1.0.0
Requires PHP: 8.1
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html

Display a simple note in posts and pages using a shortcode.

== Description ==

A lightweight demonstration plugin that displays
a customizable editorial note.

No external service or database storage is required.

== Installation ==

1. Install and activate the plugin.
2. Edit a post or page.
3. Add a Shortcode block.
4. Enter [atoolpha_note_demo].

== Changelog ==

= 1.0.0 =
* Initial release.

Avant une véritable soumission, compte-wordpress-org doit être remplacé par un identifiant WordPress.org valide, et X.Y par la version réellement testée. Les autres informations doivent également correspondre au plugin distribué.

Il faut ensuite compléter la documentation si nécessaire : paramètres disponibles, limitations, compatibilités, captures d’écran et éventuelles dépendances.

Le validateur officiel est accessible ici :

Readme Validator

Une documentation claire évite de promettre des fonctionnalités absentes et permet à l’utilisateur de comprendre ce qu’il installe.

Étape 8 — Contrôler le plugin avec Plugin Check

WordPress.org met à disposition l’extension Plugin Check, également appelée PCP.

Cet outil analyse différents aspects du développement :

• Structure et informations de l’extension.
• Respect de plusieurs exigences du répertoire.
• Utilisation des fonctions de traduction.
• Risques de sécurité courants.
• Problèmes potentiels de compatibilité.
• Bonnes pratiques d’accessibilité et de performance.

Après installation et activation, ouvrez Outils > Plugin Check dans l’administration WordPress.

Sélectionnez votre extension et lancez les vérifications adaptées à votre objectif.

Comment interpréter les résultats ?

Un rapport peut présenter des erreurs, avertissements et recommandations.

Ces résultats ne doivent pas être ignorés, mais ils demandent une analyse technique.

Une erreur peut signaler un véritable problème de conformité. Un avertissement peut indiquer un risque, une amélioration recommandée ou parfois un faux positif.

Il convient donc de distinguer les exigences bloquantes des recommandations et de comprendre chaque résultat avant de modifier le code.

Un rapport Plugin Check favorable ne constitue jamais une certification officielle. L’outil ne remplace pas la revue humaine effectuée pour les extensions soumises au répertoire.

Plugin Check dispose aussi de fonctionnalités facultatives utilisant l’intelligence artificielle. Elles ne sont pas nécessaires pour développer manuellement le plugin ni pour exploiter ses contrôles classiques.

Quels tests complémentaires réaliser ?

Avant toute diffusion, il est pertinent de vérifier :

1. L’installation et l’activation sur une installation WordPress propre.
2. L’affichage sur ordinateur et sur mobile.
3. Le fonctionnement avec différentes valeurs du shortcode.
4. L’absence d’erreurs PHP et de messages inattendus.
5. La désactivation et la suppression du plugin.
6. Le fonctionnement avec les versions minimales officiellement annoncées.
7. Les traductions et la compatibilité avec d’autres extensions.

Ces essais doivent produire des résultats observables. Une compatibilité non testée ne doit jamais être présentée comme acquise.

Étape 9 — Comprendre les règles de WordPress.org

Publier une extension dans le répertoire officiel nécessite de respecter les directives applicables aux développeurs.

Parmi les points importants :

Licence compatible avec la GPL

Le code et les éléments distribués doivent respecter une licence compatible avec les exigences WordPress.org.

La licence GPLv2 ou ultérieure est fortement recommandée dans la documentation officielle.

Les bibliothèques tierces, images et autres ressources doivent également être examinées.

Code lisible et vérifiable

Le répertoire impose un code essentiellement compréhensible et vérifiable.

Les mécanismes destinés à dissimuler son comportement sont interdits.

Respect des utilisateurs

Les extensions doivent respecter les règles concernant la collecte de données, la confidentialité, les services externes et les restrictions commerciales.

Les fonctionnalités incluses dans le code du plugin hébergé ne peuvent pas être artificiellement bloquées derrière certains mécanismes de paiement ou d’essai.

Les services externes réellement distincts peuvent relever d’autres dispositions.

Extension complète et maintenable

WordPress.org attend un plugin suffisamment abouti pour être examiné au moment de la soumission.

Un nom attrayant ou une simple structure PHP ne suffit pas : le produit doit fournir une fonctionnalité identifiable, documentée et conforme aux règles.

Étape 10 — Soumettre son extension

Une fois le développement terminé et les contrôles effectués, le développeur peut préparer une archive ZIP installable.

Le ZIP doit contenir le dossier du plugin et uniquement les éléments nécessaires à son fonctionnement ou à sa distribution.

La démarche se poursuit alors sur le site officiel :

Add your Plugin

Les principales étapes sont les suivantes :

1. Disposer d’un compte WordPress.org.
2. Vérifier le nom, la documentation et les fichiers.
3. Soumettre l’archive ZIP pour examen.
4. Répondre aux éventuelles demandes de correction.
5. Après approbation, accéder au dépôt Subversion attribué.
6. Publier la version dans ce dépôt.

L’acceptation n’est pas automatique. Une demande de correction ne signifie pas nécessairement l’abandon du projet, mais elle doit être traitée sérieusement.

Pourquoi WordPress.org utilise-t-il Subversion ?

Subversion, ou SVN, est le système utilisé pour héberger et distribuer les versions des extensions dans le répertoire officiel.

Le dépôt comprend généralement trois dossiers principaux :

assets/
tags/
trunk/

trunk contient le code du plugin. tags accueille les versions publiées et assets les ressources destinées à sa présentation dans le répertoire.

La première archive ZIP sert à la demande de revue. Après acceptation, la distribution officielle s’appuie sur les fichiers déposés dans SVN.

Ce dépôt est orienté publication : il ne doit pas servir à transférer chaque essai ou modification intermédiaire.

Les erreurs fréquentes à éviter

Certaines erreurs reviennent régulièrement lors de la conception des extensions WordPress.

Modifier directement le noyau WordPress. Cette pratique complique la maintenance et expose les modifications à la disparition lors des mises à jour.

Employer des noms de fonctions trop génériques. Un autre plugin peut déjà utiliser le même identifiant, provoquant un conflit.

Faire confiance aux données reçues. Les entrées utilisateur doivent être contrôlées avant traitement, même lorsqu’elles proviennent de l’administration.

Oublier l’échappement à l’affichage. Une donnée enregistrée correctement peut devenir dangereuse si elle est insérée sans précaution dans du HTML.

Déclarer des compatibilités jamais testées. Les valeurs des en-têtes doivent correspondre à une réalité technique vérifiable.

Considérer Plugin Check comme une garantie d’acceptation. Le contrôle automatisé et la revue officielle remplissent des rôles complémentaires.

Publier sans stratégie de maintenance. Une extension distribuée devra évoluer avec WordPress, PHP et les besoins de sécurité.

Conclusion — Comprendre le fonctionnement avant de complexifier

Créer un plugin WordPress constitue un excellent moyen de comprendre l’architecture du CMS.

Un dossier, un fichier PHP correctement déclaré, une fonction et un hook permettent déjà d’ajouter un comportement réel à un site.

La suite consiste à professionnaliser cette base : architecture adaptée, sécurité, traductions, documentation, tests, gestion des versions et conformité aux exigences du répertoire officiel.

L’intelligence artificielle n’est pas une condition pour entreprendre ce travail. Les outils fondamentaux restent PHP, la documentation WordPress, un environnement de test et une démarche méthodique.

La véritable différence entre un prototype et une extension distribuable ne réside pas dans le nombre de fichiers, mais dans la maîtrise de son fonctionnement et la capacité à démontrer sa fiabilité.

Sources et documentation officielle

• WordPress Developer — Plugin Basics
• WordPress Developer — Header Requirements
• WordPress Developer — Shortcodes
• WordPress Developer — Problèmes fréquents lors des revues
• WordPress Developer — Directives officielles des plugins
• WordPress.org — Plugin Check
• WordPress.org — Validateur readme.txt
• WordPress Developer — Utiliser Subversion

Article pédagogique ATOOLPHA — octobre 2026. Le code présenté est un exemple de développement, non une extension certifiée ni une publication approuvée par WordPress.org.