En attente
Votre plugin WordPress est en attente : ce que chaque motif de refus veut dire
L'email de l'équipe de review est court et vague à dessein. Voici ce que chaque motif veut réellement dire, ce qui le déclenche, et ce qui débloque vraiment.
Vous avez soumis une extension à wordpress.org. Deux semaines plus tard, un email arrive de plugins@wordpress.org pour vous annoncer qu'elle est retenue pour les raisons suivantes, suivi de trois ou quatre paragraphes courts qui ont l'air de devoir se suffire à eux-mêmes, et qui ne se suffisent pas.
J'ai reçu cet email. Deux fois, sur la même extension, pour deux raisons différentes. Ce qui suit est ce que chaque motif signifie réellement — y compris les deux erreurs que j'ai commises et payées en semaines d'attente.
Ne les relancez pas
Leur email le dit, et c'est vrai : les demandes de statut ralentissent la file. Une review prend de une à six semaines. Il n'existe aucune procédure accélérée.
Ne discutez pas
L'équipe de review n'est pas un service client avec lequel on négocie. Chaque minute passée à expliquer en quoi votre cas est particulier est une minute qui n'est pas passée à corriger.
Collez l'email que vous avez reçu.
L'équipe de review écrit en anglais quelle que soit votre langue. Collez leur message : cette page vous dit auquel des sept motifs vous avez réellement affaire — et ce que chacun attend de vous.
Tout se passe dans votre navigateur. Rien n'est envoyé nulle part, rien n'est conservé, il n'y a aucun serveur derrière.
D'abord, comment la review fonctionne vraiment
- 01
Ils réexaminent tout
Ils ne comparent pas votre nouvelle soumission à la précédente. Un problème non mentionné au premier tour peut apparaître au second — et un changelog détaillé dans votre réponse est de l'effort perdu.
- 02
Ils lisent le code source
Pas seulement le readme, pas seulement les en-têtes. Déplacer une vérification à un endroit moins visible ou renommer une fonction ne marche pas, et transforme une objection technique en problème de confiance.
- 03
Leur email est laconique à dessein
Ils traitent une file énorme avec des bénévoles. Chaque proposition compte — relisez donc leur email comme une passe à part entière, phrase par phrase, une fois que vous vous croyez au bout.
Les sept motifs
Choisissez celui qui correspond à votre email. Chaque carte mène à ce qui le déclenche et à ce qui passe.
Guideline 5, le « trialware »
Une extension ne peut pas limiter des fonctionnalités qui s'exécutent entièrement sur l'installation de l'utilisateur.
Ce qui le déclenche
- Une fonctionnalité qui tourne entièrement sur le serveur de l'utilisateur, plafonnée artificiellement, avec une offre payante pour la débloquer
- Le cas d'école : un mode « apportez votre propre clé d'API » plafonné à N utilisations par mois — l'utilisateur fournit la clé, l'utilisateur paie le fournisseur, le calcul ne vous coûte rien
- Notez ce qui n'est pas le problème : vendre est autorisé, avoir une version Pro est autorisé
Ce qui passe
- Retirer la limite sur tout ce qui s'exécute en local
- Déplacer la fonctionnalité côté serveur, à vos frais — la limite reflète alors une dépense réelle, et la Guideline 6 l'autorise explicitement
- Vendre du support, des mises à jour ou un service hébergé — tout sauf le déverrouillage d'un code qui tourne déjà chez l'utilisateur
Ce qui a réellement marché, et qui m'a surpris
Ma première correction gardait le mode local en supprimant simplement son plafond, à côté d'un nouveau service managé. C'était conforme. C'était aussi fragile à expliquer, parce que cela laissait un relecteur devoir évaluer deux chemins de code et me croire sur parole quant à celui auquel s'appliquait la tarification.
La version qui est passée supprimait entièrement le mode local. S'il n'y a pas de code local, la Guideline 5 ne s'applique pas du tout. Une position de conformité simple vaut mieux qu'une position défendable.
Ordre de grandeur : ce n'est pas un correctif. Pour moi, cela a voulu dire supprimer un mode entier, monter un Cloudflare Worker détenant ma propre clé d'API, brancher les webhooks de licence avec validation de signature, ajouter les quotas par installation, et réécrire toute la chaîne de génération. Connaître la réponse m'a pris une heure. La livrer m'a pris des jours.
Collision de nom et de marque
pas seulement dans le nom — cela inclut … les URLs de cette extension
Ce qui le déclenche
- Le nom affiché, le slug, le text domain, le Plugin URI, chaque lien de votre interface d'administration, le readme, l'identifiant du contributeur, et le domaine lui-même
- Un conflit hors de WordPress : des projets techniques sans rapport, GitHub, npm, des produits SaaS, des registres de marques
- Un nom de remplacement qui n'est pas démontrablement le vôtre — l'autorisation de l'autre propriétaire ne résout rien
Ce qui passe
- Un nom purement descriptif ne peut entrer en collision avec la marque de personne
- Le plus sûr : reprendre la moitié descriptive du nom qu'ils suggèrent eux-mêmes et retirer l'identifiant — c'est eux qui l'ont écrite, ils peuvent difficilement la juger trompeuse
- Mettez votre repli dans le même email, sinon vous achetez un aller-retour de une à six semaines de plus
- Vérifier qu'un slug est libre : api.wordpress.org/plugins/info/1.2/?action=plugin_information&request[slug]=VOTRE-SLUG renvoie « Plugin not found. » quand il est disponible
Trois renommages qui ont survécu à un grep déclaré propre
Le nom coupé par une balise HTML. Le logo de mon site s'écrivait Plug<span class="dot">Forge</span>. Aucune recherche sur le nom complet ne trouve ça — et c'était l'élément le plus visible de chaque page.
Un slug encore plus ancien. Des dizaines de liens pointaient toujours vers le premier nom de l'extension, abandonné deux renommages plus tôt, dont le bouton d'appel à l'action principal. Cherchez tous les noms morts, pas seulement le dernier.
Ce qui part sur le réseau. Un worker en arrière-plan envoyait l'ancien nom dans son User-Agent à chaque site tiers qu'il visitait. Invisible à l'écran, parfaitement réel pour les serveurs qui le recevaient.
La ligne Contributors
Ce qui le déclenche
- Le titulaire du compte wordpress.org qui soumet l'extension n'est pas dans la ligne Contributors: du readme
- Fréquemment manqué précisément parce que la ligne existe déjà avec d'autres noms dedans — l'auteur d'un framework, un SDK de facturation — et qu'elle n'a donc pas l'air vide
Ce qui passe
- Ajoutez l'identifiant du compte qui soumet dans Contributors:
- Si vous réglez aussi un problème de marque, vérifiez cette ligne : un identifiant de contributeur construit sur le nom refusé contredit tout le renommage
Plugin URI cassé
Ce qui le déclenche
- L'URL renvoie une 404 — correction technique
- L'URL contient encore le nom en conflit — c'est un problème de marque, voir le motif 02
- L'URL pointe vers la page d'accueil de votre agence plutôt que vers cette extension précisément
Ce qui passe
- Vérifiez en ligne, pas dans le fichier : une URL corrigée dans vos sources mais jamais déployée reste un motif de refus
- Avant de répondre, ouvrez réellement chaque URL que contient votre soumission
Services externes non documentés
Ce qui le déclenche
- Un appel sortant non documenté dans une section External Services du readme : quoi est envoyé, quand, et à quel fournisseur
- Une description qui ne correspond plus au code soumis — pire que pas de description, car elle se lit comme une dissimulation et non comme un oubli
Ce qui passe
- Écrivez cette section en dernier, une fois que votre architecture a cessé de bouger
- Vérifiez que la politique de confidentialité que vous y liez dit la même chose
- Nommez chaque endpoint réellement appelé, sur le domaine réellement appelé
Celle qui a failli passer
Ma politique de confidentialité disait encore que l'extension envoyait l'URL d'une image, longtemps après que le code fut passé à l'envoi de l'image elle-même. Deux documents officiels qui se contredisent sur ce qui sort du serveur de l'utilisateur, c'est exactement le type d'écart que cette section existe pour attraper. Je l'ai trouvé une heure avant de resoumettre, sur une dernière passe, alors que tout le reste avait été déclaré propre.
Un secret livré dans le ZIP public
Ce qui le déclenche
- Certains SDK de licence écrivent un secret en clair dans votre fichier principal — le code généré le dit parfois lui-même, dans un commentaire
- Une archive assemblée à la main plutôt que par l'outil de build du SDK, qui retire le secret automatiquement
Ce qui passe
- Si vous fabriquez votre archive vous-même, dézippez-la et faites-y un grep avant de téléverser
- Dix secondes de vérification contre un mode de défaillance définitif une fois publié
« Cette catégorie est encombrée »
Ce qui le déclenche
- Une remarque sur la saturation de votre catégorie — ce n'est pas un point de conformité et cela ne bloque pas l'approbation en soi
Ce qui passe
- Répondez par une différence technique vérifiable, pas par un argument marketing
- Résistez au « meilleur que X » : c'est infalsifiable, et une équipe de review qui le lit fera moins confiance au reste de votre soumission
Comment répondre
Leur consigne mérite d'être suivie à la lettre : faites court, et ne listez pas vos changements. Ils réexaminent tout depuis zéro, un changelog n'est donc que du bruit.
- La confirmation de ce qui a changé, en une ou deux phrases — la position, pas le diff
- En cas de renommage, une demande explicite de réservation du nouveau slug — ils ne le font pas d'eux-mêmes
- Votre option de repli, s'il subsiste un doute
Téléversez la version corrigée via la page « Add your plugin », connecté au compte qui a soumis — pas en pièce jointe d'un email. Une page de make.wordpress.org datant de 2015 dit le contraire ; elle n'est plus à jour. L'avertissement « Text Domain » reçu au téléversement est normal tant qu'ils n'ont pas réservé votre slug.
La liste que je déroule avant de resoumettre
Chaque ligne vient d'un point que j'ai raté. Cochez-les — votre navigateur s'en souvient.
La dernière ligne est celle qui a le plus compté : treize passes de relecture sur mon propre code ont manqué trois bugs bloquants, et chacun est apparu dans les cinq premières minutes d'exécution réelle. On lit le code pour trouver ce qui est faux. On l'exécute pour trouver ce qui manque.
Ce que cela coûte réellement
Pour une correction de conformité simple — documentation, en-têtes, contributeurs, URLs — quelques heures est réaliste.
Pour la Guideline 5, soyez honnête avec vous-même : vous changez le modèle économique de votre produit et vous construisez probablement une infrastructure côté serveur que vous n'aviez pas. Entre mon premier refus et ma resoumission finale, il y a eu neuf jours, deux noms refusés, un Cloudflare Worker, une intégration de webhooks, et trois bugs qui ne sont apparus que lorsque j'ai arrêté de lire pour commencer à exécuter.
Les guidelines ne sont pas arbitraires, et une fois qu'on en voit le motif, elles sont cohérentes : le répertoire héberge du logiciel libre qui fonctionne, et tout est jugé à cette aune.
Je le fais pour d'autres auteurs d'extensions : chaque point de l'email de refus traité, les règles qu'ils n'ont pas encore soulevées vérifiées aussi, et la réponse rédigée pour que vous n'ayez qu'à l'envoyer.