Comment publier une extension sur le dépôt officiel WordPress ?

Publier une extension sur le dépôt officiel place son travail devant des dizaines de milliers d'installations potentielles, avec un mécanisme de mise à jour automatique et une visibilité qu'aucun autre canal ne procure. Le parcours comporte en revanche des étapes précises, une revue humaine du code et des règles dont l'ignorance conduit à des allers retours de plusieurs semaines. La publication d'une extension WordPress se prépare donc avant la soumission, en respectant les conventions de nommage, les exigences de sécurité et le format des fichiers attendus. Rien de tout cela n'est difficile, tout est documenté, et pourtant la première soumission est refusée dans une proportion importante des cas.

Préparer le code avant de soumettre

La revue porte sur la sécurité, sur les bonnes pratiques et sur le respect des règles du dépôt. Anticiper ces trois dimensions évite l'essentiel des refus. Les contrôles de sécurité attendus sont exactement ceux que nous décrivons dans notre article sur la manière de sécuriser une extension WordPress.

Choisir un nom disponible et durable

Le nom détermine l'identifiant de l'extension, son adresse sur le dépôt et le nom du répertoire d'installation. Il ne pourra plus être changé après publication, ce qui en fait la décision la plus engageante du parcours. Il doit être unique, ne pas reprendre une marque déposée dont on n'est pas titulaire, et éviter de commencer par le nom d'un service tiers, règle appliquée strictement par le dépôt. Une recherche préalable dans le dépôt et dans les bases de marques évite un refus qui coûte plusieurs semaines et oblige à renommer l'ensemble du code. Il vaut mieux consacrer une heure à cette vérification que de découvrir le problème après trois semaines d'attente.

Préfixer tout ce qui est global

Fonctions, classes, constantes, options, tables et clés de métadonnées doivent porter un préfixe propre à l'extension. Une fonction déclarée sans préfixe entre en collision avec une autre extension et provoque une erreur fatale sur les sites où les deux cohabitent, ce que la revue vérifie systématiquement. Le préfixe doit être suffisamment distinctif pour ne pas être lui même repris ailleurs, ce qui écarte les abréviations de deux lettres et les mots courants. Sur une extension écrite en programmation orientée objet, un espace de noms remplit le même office de façon plus élégante. Il reste toutefois nécessaire de préfixer les options et les métadonnées, qui ne bénéficient d'aucun cloisonnement.

Le fichier principal et son en-tête

Le fichier principal doit comporter un bloc de commentaires déclarant le nom, la description, la version, l'auteur, la licence, la version minimale de WordPress et celle de PHP. Ces informations alimentent la fiche du dépôt et les contrôles de compatibilité côté site. La licence doit être compatible avec celle de WordPress, ce qui exclut toute licence propriétaire et impose de vérifier celle des bibliothèques embarquées. Une bibliothèque sous licence incompatible entraîne un refus immédiat, et ce point surprend régulièrement les auteurs qui ont intégré un composant sans en lire les conditions. La vérification des licences des dépendances est un contrôle de dix minutes qui évite une réécriture.

Le fichier de description

Un fichier de description au format texte structuré fournit le contenu de la fiche publique : description courte, description longue, capture d'écran, questions fréquentes, journal des modifications et versions testées. Sa syntaxe est stricte et un outil de validation officiel permet de la vérifier avant soumission. Ce fichier constitue la vitrine de l'extension et il détermine largement le taux d'installation, ce qui justifie d'y consacrer un vrai temps de rédaction plutôt que de le remplir à la hâte au dernier moment. Une description courte percutante et trois captures commentées font davantage pour l'adoption que n'importe quelle fonctionnalité supplémentaire.

Protéger l'accès direct

Chaque fichier doit commencer par un contrôle vérifiant que le contexte WordPress est chargé, ce qui empêche son exécution par un appel direct. Cette ligne est vérifiée par la revue et son absence figure parmi les motifs de refus les plus fréquents. Elle protège notamment des messages d'erreur révélant l'arborescence du serveur, information que l'on ne souhaite exposer sur aucune installation. Un fichier d'index vide dans chaque répertoire complète utilement cette protection sur les serveurs autorisant le listage. Ces deux protections se posent mécaniquement et devraient figurer dans le modèle de projet employé pour démarrer toute nouvelle extension.

Nettoyer à la désinstallation

Une extension doit prévoir la suppression de ses données lors de sa désinstallation, par un fichier dédié ou par un point d'entrée prévu à cet effet. Laisser des options et des tables derrière soi est mal vu et pénalise l'utilisateur qui essaie plusieurs solutions avant d'en retenir une. La distinction entre désactivation et désinstallation doit être respectée : la première ne supprime rien, la seconde nettoie. Proposer à l'utilisateur de conserver ses données malgré la désinstallation est une attention appréciée, à condition que le choix soit explicite. Un réglage proposant de conserver les données à la désinstallation répond bien à ce besoin et rassure les utilisateurs qui hésitent à tester.

Le parcours de soumission

La procédure est simple mais séquentielle, et chaque étape conditionne la suivante. Il faut compter entre deux et huit semaines entre la soumission et la première publication, selon la charge de l'équipe de revue et la qualité du code envoyé.

Créer un compte et soumettre

Un compte sur le site officiel est nécessaire, et c'est lui qui sera propriétaire de l'extension. Le formulaire de soumission demande le nom, une description et une archive du code. Il vaut mieux soumettre une version fonctionnelle et complète plutôt qu'une ébauche, la revue portant sur le code envoyé et non sur des intentions. Une soumission prématurée conduit à un refus et il faut alors recommencer la procédure depuis le début, avec un nouveau délai d'attente. Prendre le temps de relire le code une dernière fois avant d'envoyer coûte une heure et peut faire gagner un mois.

La revue humaine

Une personne lit le code et signale les problèmes rencontrés dans un message détaillé. Les remarques portent typiquement sur des sorties non échappées, des entrées non validées, l'absence de préfixe, l'usage de fonctions dépréciées ou le chargement de ressources depuis un service distant. La réponse attendue consiste à corriger l'ensemble des points signalés puis à renvoyer une archive corrigée, en répondant au message plutôt qu'en soumettant à nouveau. La qualité de cet échange influe directement sur le délai. Une réponse traitant tous les points signalés en une fois vaut nettement mieux que plusieurs allers retours partiels.

Ce que la revue refuse systématiquement

Le chargement de code depuis un serveur distant, l'obfuscation, l'envoi de données sans consentement explicite, la modification du site en dehors du périmètre annoncé et les liens d'affiliation non déclarés entraînent un refus sans discussion. Les bandeaux publicitaires envahissants dans l'administration sont également très mal vus et font l'objet de règles précises. Ces interdictions protègent l'écosystème et elles sont appliquées sans exception, quel que soit l'argument avancé. Elles figurent dans les règles publiées et méritent d'être lues intégralement avant la première soumission.

L'accès au dépôt de code

Une fois l'extension approuvée, un dépôt de code est ouvert avec une structure imposée comportant un répertoire de développement, un répertoire d'étiquettes de version et un répertoire d'éléments graphiques. La publication d'une version consiste à déposer le code dans le répertoire de développement puis à créer une étiquette correspondant au numéro de version. Ce fonctionnement déroute les développeurs habitués aux forges modernes, et il se maîtrise en une heure de pratique. Un script de publication automatisant le dépôt et l'étiquetage supprime ensuite toute friction.

Les visuels de la fiche

La bannière, l'icône et les captures d'écran se déposent dans le répertoire dédié, avec des noms et des dimensions imposés. Ces éléments déterminent une grande partie de l'impression produite sur la page du dépôt et ils sont souvent négligés, ce qui donne des fiches austères à côté d'extensions concurrentes soignées. Une bannière correcte et trois captures commentées demandent une demi journée et améliorent nettement le taux d'installation. Ces fichiers ne sont pas distribués avec l'extension et n'alourdissent donc pas son téléchargement.

La première publication

La création de la première étiquette de version déclenche la mise en ligne de la fiche, généralement dans les quinze minutes. L'extension devient alors installable depuis n'importe quel site WordPress. Il faut vérifier immédiatement que la fiche s'affiche correctement, que l'installation fonctionne depuis un site tiers et que la version affichée correspond bien à celle déposée, trois contrôles qui prennent cinq minutes et évitent de découvrir un problème par un premier utilisateur mécontent. Il vaut mieux installer soi même l'extension depuis le dépôt, sur un site de test vierge, plutôt que de supposer que tout va bien.

Gérer les versions

La publication n'est que le début. La façon dont les versions se succèdent détermine la confiance des utilisateurs et la charge d'entretien.

Numéroter sérieusement

Un numéro de version doit refléter la nature du changement : correction, ajout compatible, ou rupture de compatibilité. Cette convention est comprise par tout le monde et permet aux utilisateurs de décider s'ils peuvent mettre à jour sans précaution. Elle est développée dans notre article sur le versioning logiciel et la gestion des évolutions. Sur une extension distribuée, cette rigueur compte davantage que sur un projet interne, puisque les utilisateurs ne peuvent pas vous demander ce qui a changé.

Synchroniser les numéros

Le numéro figure à trois endroits : l'en-tête du fichier principal, le fichier de description et l'étiquette du dépôt. Une divergence entre ces trois valeurs produit des comportements imprévisibles, l'extension pouvant ne pas proposer la mise à jour ou proposer une version qui n'existe pas. Un script de publication mettant à jour les trois simultanément supprime définitivement cette source d'erreur, et il s'écrit en dix lignes. Ce script doit également refuser de publier si les trois valeurs ne concordent pas, ce qui rend l'erreur impossible.

Tenir le journal des modifications

La section dédiée du fichier de description doit lister ce qui change à chaque version, en termes compréhensibles par un utilisateur et non par un développeur. Ce journal est lu avant chaque mise à jour par les administrateurs prudents, et sa qualité influence directement la vitesse d'adoption des nouvelles versions. Une ligne par changement suffit, à condition qu'elle décrive l'effet plutôt que l'implémentation. Mentionner explicitement les corrections de sécurité, sans détailler la faille, fait partie des usages attendus.

Déclarer la compatibilité

Le champ indiquant la version de WordPress avec laquelle l'extension a été testée doit être mis à jour à chaque version majeure du cœur. Une extension déclarant une compatibilité ancienne affiche un avertissement sur sa fiche et voit son taux d'installation chuter, même si elle fonctionne parfaitement. Cette mise à jour prend trente secondes et se fait après avoir réellement testé, ce qui suppose un environnement de test à jour.

Prévenir des ruptures

Un changement modifiant le comportement existant doit être annoncé dans le journal et, lorsque c'est possible, précédé d'une version de transition affichant un avertissement. Casser silencieusement le site de milliers d'utilisateurs lors d'une mise à jour automatique produit une vague d'avis négatifs dont on ne se remet pas facilement. La prudence impose de considérer que la majorité des installations se mettent à jour automatiquement, sans que personne ne lise quoi que ce soit.

Tester avant de publier

Une extension publiée s'installe automatiquement sur des milliers de sites en quelques heures. Un test sur plusieurs versions de WordPress et de PHP, avec les extensions les plus répandues activées, est le minimum avant toute publication. Les outils d'intégration continue rendent ce contrôle automatique et gratuit, et leur absence explique l'essentiel des mises à jour catastrophiques que l'écosystème connaît régulièrement.

Entretenir la publication

Une extension publiée engage sur la durée, et cet engagement est plus lourd que la plupart des auteurs ne l'imaginent au moment de la première soumission.

Répondre au forum de support

Chaque extension dispose d'un forum où les utilisateurs posent leurs questions. Le taux de réponse est affiché publiquement sur la fiche et il constitue un signal fort pour les visiteurs. Répondre, même brièvement, même pour indiquer qu'un point ne sera pas traité, vaut infiniment mieux que le silence. Un rythme d'une visite hebdomadaire suffit sur une extension de taille modeste et se tient sans difficulté.

Traiter les signalements de sécurité

Une faille signalée doit être corrigée rapidement et la version corrigée publiée sans attendre. Le dépôt peut fermer une extension présentant une vulnérabilité non traitée, ce qui la rend indisponible et coupe les mises à jour pour tous les utilisateurs. Prévoir une adresse de contact dédiée et la mentionner sur la fiche permet à un chercheur de signaler discrètement plutôt que de publier, différence considérable en pratique.

Suivre les statistiques

Le dépôt fournit le nombre d'installations actives et la répartition par version. Une proportion importante d'installations restées sur une ancienne version signale soit un problème de mise à jour, soit une régression qui a fait revenir les utilisateurs en arrière. Ce chiffre est le meilleur indicateur de santé dont on dispose, bien plus fiable que le nombre de téléchargements, qui compte aussi les essais abandonnés.

Gérer les avis

La note moyenne détermine largement le taux d'installation. Un avis négatif motivé par un malentendu se traite par une réponse courtoise et factuelle, souvent suivie d'une révision de la note. Ignorer les avis laisse une impression d'abandon, et il vaut mieux répondre à un avis désagréable que de le laisser seul en tête de fiche. Ce travail relève de la relation client autant que du développement.

Prévoir la transmission

Une extension que l'on ne souhaite plus maintenir doit être transmise à quelqu'un ou fermée explicitement, plutôt que laissée à l'abandon. Le dépôt prévoit une procédure de transfert de propriété. Une extension abandonnée finit par présenter des incompatibilités et parfois des failles, ce qui pénalise les utilisateurs qui lui avaient fait confiance, considération dont on ne se soucie pas assez au moment de passer à autre chose.

Ce que la publication apporte vraiment

Au delà de la visibilité, la publication apporte un retour d'usage impossible à obtenir autrement : des configurations que l'on n'aurait jamais testées, des besoins que l'on n'avait pas envisagés, des bogues révélés par des combinaisons improbables. Ce retour améliore considérablement la qualité du code, et il constitue probablement le bénéfice le plus concret de la démarche, comme nous l'évoquons dans notre article sur la manière de bien choisir une extension pour WordPress. Ce retour arrive parfois plusieurs semaines après le dépôt, délai qu'il vaut mieux anticiper dans le calendrier.