Publier un plugin WordPress sur le répertoire officiel

Publier un plugin sur le répertoire officiel WordPress, c’est une étape qui fait rêver beaucoup de développeurs… mais la réalité du processus est souvent plus complexe qu’on ne l’anticipe. Entre les standards de code à respecter, la review manuelle parfois impitoyable et les pièges à éviter après la publication, il y a de quoi se perdre si on n’est pas bien préparé. Dans cet article, on passe en revue tout ce qu’il faut savoir pour maximiser ses chances de succès, de la préparation initiale jusqu’à la vie de votre plugin une fois en ligne.

Préparer son plugin avant la soumission

Avant même de penser à soumettre quoi que ce soit sur le répertoire officiel, il y a un vrai travail de fond à faire. Et c’est là que beaucoup de développeurs se plantent : ils expédient la préparation et se retrouvent avec un refus du reviewer en retour. Autant mettre toutes les chances de son côté dès le départ.

Respecter les standards de code WordPress

Les WordPress Coding Standards (WPCS), c’est un peu la règle du jeu. Le répertoire officiel n’exige pas une conformité absolue à 100%, mais les reviewers regardent de près certains points critiques, notamment tout ce qui touche à la sécurité.

Concrètement, voici ce qu’on doit retrouver dans son code :

Sanitization des données en entrée : on utilise sanitize_text_field(), absint(), sanitize_email() selon le type de donnée attendue.
Échappement des sorties : esc_html(), esc_attr(), esc_url() avant d’afficher quoi que ce soit dans le HTML.
Protection des formulaires avec des nonces : wp_nonce_field() côté formulaire, check_admin_referer() ou wp_verify_nonce() côté traitement.
Utiliser les fonctions natives WordPress plutôt que du PHP brut : wp_remote_get() plutôt que file_get_contents(), $wpdb->prepare() pour les requêtes SQL, etc.

Un exemple concret pour sécuriser un champ texte soumis via un formulaire :

// Vérification du nonce
if ( ! isset( $_POST['mon_plugin_nonce'] ) || ! wp_verify_nonce( $_POST['mon_plugin_nonce'], 'mon_plugin_action' ) ) {
    wp_die( 'Action non autorisée.' );
}

// Sanitization de la valeur
$valeur = sanitize_text_field( $_POST['mon_champ'] );

// Échappement à l'affichage
echo esc_html( $valeur );

Bon, ça paraît évident quand on le voit écrit. Mais croyez-moi, les reviewers voient passer des plugins sans la moindre vérification de nonce toutes les semaines. C’est le genre de détail qui peut coûter un refus immédiat.

Pour aller plus loin, l’outil PHP_CodeSniffer avec le ruleset WordPress (le package wp-coding-standards/wpcs) permet d’automatiser la détection des problèmes directement dans votre éditeur ou en ligne de commande. Très utile avant la soumission.

Soigner la structure des fichiers et l’en-tête du plugin

Le répertoire WordPress attend une structure précise. Pas besoin de faire compliqué, mais il faut respecter les conventions.

La structure minimale d’un plugin ressemble à ceci :

mon-plugin/
├── mon-plugin.php        ← fichier principal
├── readme.txt            ← obligatoire pour le répertoire
├── includes/
│   └── class-mon-plugin.php
├── assets/
│   ├── css/
│   └── js/
└── languages/
    └── mon-plugin.pot

L’élément le plus important : l’en-tête commenté du fichier principal. C’est lui qui permet à WordPress d’identifier et d’afficher les informations du plugin. Voici un exemple complet :

<?php
/**
 * Plugin Name:       Mon Super Plugin
 * Plugin URI:        https://mon-site.com/mon-super-plugin
 * Description:       Une description claire et concise de ce que fait le plugin.
 * Version:           1.0.0
 * Requires at least: 6.0
 * Requires PHP:      7.4
 * Author:            Etienne Dupont
 * Author URI:        https://mon-site.com
 * License:           GPL v2 or later
 * License URI:       https://www.gnu.org/licenses/gpl-2.0.html
 * Text Domain:       mon-super-plugin
 * Domain Path:       /languages
 */

Quelques points d’attention ici. Le Text Domain doit correspondre exactement au slug de votre plugin (le nom du dossier). La licence doit être compatible GPL (c’est une obligation du répertoire, pas une option). Et le champ Requires PHP est souvent oublié, alors qu’il est très utile pour éviter des problèmes de compatibilité chez vos utilisateurs.

Rédiger un readme.txt qui convainc le reviewer

Le readme.txt, c’est peut-être la partie la plus sous-estimée de tout le processus. Beaucoup de développeurs le bâclent en cinq minutes alors qu’il remplit deux rôles essentiels : c’est à la fois le document technique lu par le reviewer et la page de présentation publique de votre plugin sur WordPress.org. En clair, c’est votre argumentaire de vente.

Le format est spécifique au répertoire WP.org, inspiré du Markdown mais avec ses propres conventions. Voici la structure de base :

=== Mon Super Plugin ===
Contributors:      etiennedupont
Tags:              formulaire, contact, email
Requires at least: 6.0
Tested up to:      6.7
Stable tag:        1.0.0
Requires PHP:      7.4
License:           GPLv2 or later
License URI:       https://www.gnu.org/licenses/gpl-2.0.html

Une description courte (moins de 150 caractères) qui apparaît dans les résultats de recherche.

== Description ==

Ici, on développe vraiment ce que fait le plugin. C'est la vitrine.
On peut utiliser des listes, du gras, etc.

== Installation ==

1. Téléchargez le plugin
2. Activez-le depuis le menu Extensions

== Frequently Asked Questions ==

= Est-ce compatible avec WooCommerce ? =
Oui, totalement compatible.

== Screenshots ==

1. Capture de l'interface principale.

== Changelog ==

= 1.0.0 =
* Version initiale.

Les balises obligatoires à ne surtout pas oublier : Requires at least, Tested up to, Stable tag et License. Si Stable tag ne correspond pas à un tag existant dans votre dépôt SVN, le plugin affichera une version incorrecte sur le répertoire. C’est un piège classique.

La section Screenshots mérite qu’on s’y attarde. Une image vaut mille mots, surtout pour un utilisateur qui compare plusieurs plugins. Les screenshots doivent être placés dans un dossier /assets/ à la racine du dépôt SVN (pas dans le dossier du plugin lui-même, c’est une confusion fréquente).

Avant de soumettre, pensez à valider votre readme.txt avec l’outil officiel : https://wordpress.org/plugins/developers/readme-validator/. Il détecte les balises manquantes ou mal formatées en quelques secondes. Vraiment, prenez deux minutes pour le faire : ça évite des allers-retours inutiles avec le reviewer.

Soumettre et survivre à la review

Bon, voilà le moment de vérité. Vous avez préparé votre plugin, votre readme.txt est nickel, votre code respecte les standards… Il est temps de soumettre. Et je vais être honnête : cette étape est souvent la plus stressante pour un développeur qui publie pour la première fois.

Comprendre le processus de review officiel

La soumission se fait via https://wordpress.org/plugins/developers/add/. Vous uploadez une archive ZIP de votre plugin, et c’est parti.

Ce qu’il faut savoir dès le départ : la review est manuelle, réalisée par des bénévoles de la communauté WordPress. En 2026, le délai d’attente tourne souvent autour de plusieurs semaines (parfois 3 à 5 semaines selon la période). Pas de panique, c’est normal. Et bonne nouvelle : dès la soumission acceptée, votre plugin reçoit son slug définitif sur WP.org. Ce slug ne changera plus jamais, donc choisissez-le bien avant de soumettre.

Les erreurs qui font rejeter un plugin : la liste noire

La majorité des rejets sont évitables. Voici les erreurs les plus fréquentes que les reviewers signalent :

Fonctions dépréciées : utiliser des fonctions PHP ou WordPress obsolètes est un signal rouge immédiat.
Librairies tierces mal intégrées : inclure une librairie entière alors que vous n’utilisez que deux fonctions, ou ne pas vérifier si elle est déjà chargée par ailleurs.
Appels HTTP externes non justifiés : tout appel vers un serveur externe doit être explicitement mentionné et justifié dans la documentation.
Absence de gestion des droits : oublier current_user_can() avant d’exécuter des actions sensibles, c’est un rejet quasi automatique.
Données sensibles stockées en clair : mots de passe, clés API… tout doit être stocké de façon sécurisée.
Utilisation de eval() ou code obfusqué : le répertoire officiel n’accepte pas le code intentionnellement illisible. Point final.
Préfixes non uniques : vos fonctions, classes et constantes doivent utiliser un préfixe qui vous est propre (ex: monplugin_ma_fonction()). Sans ça, vous risquez des conflits de noms avec d’autres plugins.

Prenez le temps de relire cette liste avant de soumettre. Ce sont souvent des détails qui coûtent plusieurs semaines de délai supplémentaire.

Gérer les échanges avec l’équipe de review

Si votre plugin nécessite des corrections, vous recevrez un email du reviewer avec ses remarques. C’est là que beaucoup de développeurs commettent une erreur : ils paniquent ou, pire, ils ne répondent pas assez vite.

Quelques règles simples à garder en tête :

Répondez dans les 7 jours. Passé ce délai, le ticket peut être fermé automatiquement. Si ça arrive, vous devrez recommencer la procédure depuis le début.
Adoptez un ton professionnel et courtois. Les reviewers sont des bénévoles, ils font ce travail pour la communauté. Un message respectueux ouvre bien mieux les portes qu’un ton défensif.
Répondez point par point aux remarques soulevées. Listez les corrections effectuées clairement pour faciliter la re-review.
Si vous avez besoin de plus de temps pour corriger, dites-le simplement : un petit message « je travaille dessus, réponse dans 3 jours » suffit à maintenir le ticket ouvert.

Après la review : publier et versionner correctement

Votre plugin est approuvé ? Félicitations ! Mais attention, ce n’est pas fini. Pour déployer sur le répertoire WP.org, vous devez utiliser SVN (et non pas Git directement).

Le repository SVN de votre plugin a une structure bien précise :

trunk/ : contient la version de développement en cours.
tags/ : chaque version stable publiée doit avoir son propre tag (ex: tags/1.0.0/).
assets/ : les captures d’écran, bannières et icônes affichées sur la page WP.org.

Le workflow correct pour publier une nouvelle version :

Commitez vos fichiers dans trunk/.
Copiez trunk/ vers tags/1.0.0/ (ou la version correspondante).
Mettez à jour le champ Stable tag: 1.0.0 dans votre readme.txt.

Ce dernier point est crucial : c’est le Stable tag qui indique à WordPress quelle version proposer aux utilisateurs pour la mise à jour. Oubliez-le, et votre nouvelle version ne sera tout simplement pas distribuée.

Les pièges à éviter sur la durée

Bon, on a parlé de la préparation, de la soumission, du déploiement SVN… Mais la vraie vie d’un plugin commence après la publication. Et là, croyez-moi, il y a quelques erreurs classiques qui peuvent faire mal.

La compatibilité avec les nouvelles versions de WordPress, c’est probablement le point que les développeurs débutants négligent le plus. WordPress sort des mises à jour majeures régulièrement, et si vous ne testez pas votre plugin avec le plugin WP Beta Tester, vous risquez de vous retrouver avec des signalements d’incompatibilité en masse. Pensez à mettre à jour le champ Tested up to dans votre readme.txt à chaque cycle de release. C’est un signal fort pour les utilisateurs, et WP.org le prend en compte dans l’affichage de votre plugin.

Le forum de support WP.org, c’est un endroit qu’on a tendance à surveiller… de loin. Mauvaise idée. Répondre rapidement aux issues, même pour dire que vous regardez le problème, c’est aussi un indicateur de qualité aux yeux de la communauté. Et de l’équipe de review. Un plugin avec des dizaines de questions sans réponse, ça fait fuir les utilisateurs potentiels.

Il faut aussi parler d’un risque concret : la fermeture du plugin par l’équipe WP.org. Ça arrive. Une faille de sécurité non corrigée, un abandon prolongé du plugin sans communication, et hop, le plugin est retiré du répertoire, parfois sans préavis. Des milliers d’utilisateurs reçoivent alors un avertissement dans leur back-office. Ce n’est pas une situation agréable pour personne. Donc : continuez à maintenir votre plugin, même si vous n’ajoutez pas de nouvelles fonctionnalités.

Un changelog bien tenu, c’est aussi quelque chose qu’on bâcle souvent. « Bug fixes and improvements », c’est le message que tout le monde déteste voir. Soyez précis : listez les corrections, les ajouts, les changements de comportement. Vos utilisateurs apprécient de savoir ce qui change, et ça renforce la confiance.

Dernier piège, et pas des moindres : la monétisation trop agressive. La version freemium, c’est une approche tout à fait légitime. Mais les upsells intempestifs dans le dashboard, les bannières publicitaires envahissantes, les fonctionnalités de base cachées derrière un paywall mal communiqué… tout ça génère des avis négatifs rapidement. Et sur WP.org, les mauvaises évaluations restent. Prenez le temps de construire une base d’utilisateurs satisfaits avant de pousser la monétisation.

Pour finir, je veux être clair : malgré tout ce que je viens de lister, publier son premier plugin sur le répertoire officiel reste une expérience vraiment enrichissante. Vous apprenez énormément sur les standards du développement WordPress, sur la gestion d’une communauté d’utilisateurs, et sur le processus open source en général. C’est exigeant, oui. Mais c’est aussi l’une des meilleures façons de progresser concrètement en tant que développeur WordPress. Alors lancez-vous !