Troy : le plan B des développeurs WordPress face à la centralisation de .org

D’où viennent vos plugins WordPress ?

Si vous avez répondu "de WordPress.org", vous avez raison. Plus de 60 000 extensions selon le répertoire officiel (avril 2026), des millions de téléchargements par jour, un système qui tourne depuis 2005. On n’y pense même plus, c’est comme l’eau du robinet…

Mais posez-vous une deuxième question : que se passe-t-il si ce répertoire décide, du jour au lendemain, de bloquer l’accès à un éditeur entier ?

En octobre 2024, on a eu la réponse. Et elle n’était pas rassurante.

Le jour où WordPress.org a montré ses limites

En octobre 2024, Matt Mullenweg a bloqué l’accès de WP Engine au répertoire WordPress.org. Du jour au lendemain, les clients WP Engine ne pouvaient plus mettre à jour leurs plugins ni leurs thèmes via le canal officiel. La raison ? Un conflit commercial entre Automattic (la société derrière WordPress.com) et WP Engine (l’un des plus gros hébergeurs WordPress au monde).

Le répertoire WordPress.org est géré par Automattic. Une seule entité contrôle le robinet. Et quand le robinet se ferme, tout le monde a soif en même temps.

Est-ce que ça peut arriver à n’importe quel développeur ? En théorie, oui. Sybre Waaijer, le créateur de The SEO Framework (un plugin SEO avec des centaines de milliers d’installations), raconte qu’en 2017, son extension a été retirée de WordPress.org sans explication. Pas d’email, pas de justification. Juste une suppression.

Between me and you stands a platform that can sever that connection at any moment, for any reason, with no accountability.

Sybre Waaijer, créateur de Troy (deploytroy.org)

Entre le développeur et l’utilisateur, il y a une plateforme qui peut couper le lien à tout moment. Ça résume bien le problème.

Je connais le processus de l’intérieur. J’ai 8 extensions sur WordPress.org, pour un total de plus de 2 millions d’installations actives (données WordPress.org, avril 2026). Récemment, j’ai soumis OGEEAT, mon dernier plugin GEO pour WordPress qui permet d’accroître la citabilité de votre site par les IA. C’est long. La file d’attente est dense, il suffit d’une coquille dans le code pour que le processus de validation double en temps… Et quand c’est votre première soumission ? Bon courage. Un vrai parcours du combattant.

Pour les développeurs français, il y a un bonus : la traduction. Il faut rejoindre le Slack WordPress FR, discuter avec l’équipe de traduction (qui fait un boulot remarquable, au passage), respecter un glossaire spécifique… On l’oublie trop souvent, mais si on ne sait pas que tout ça existe, on est vite perdu. Bref. Il faut vraiment avoir envie de publier sur le répertoire officiel. Et encore plus de motivation pour traduire intégralement son extension.

Troy, c’est quoi concrètement ?

Troy est un projet open source créé par Sybre Waaijer et lancé le 9 décembre 2025. L’idée a été rédigée le 14 octobre 2024, pile pendant le conflit WP Engine. Le premier code date du 12 janvier 2025. Neuf mois plus tard : 37 347 lignes de code et une version stable (v1.4.1184).

Le principe est simple. Troy se compose de deux briques :

Troy Server transforme n’importe quelle installation WordPress en dépôt de plugins. Vous uploadez un ZIP ou vous connectez votre dépôt GitHub, et vos utilisateurs peuvent installer et mettre à jour vos extensions depuis votre propre serveur. Pas besoin de passer par WordPress.org.

Troy Client s’installe côté utilisateur. Il détecte les plugins qui contiennent un en-tête Troy: dans leur fichier principal et récupère les mises à jour directement dans le tableau de bord WordPress natif. L’expérience est identique : même écran de mise à jour, même workflow.

Combien ça coûte ? Rien. Troy est gratuit, open source, hébergé sur GitHub. Le site officiel est deploytroy.org. D’après le développeur, un Troy Server peut gérer jusqu’à 1 million de sites sur un hébergement à moins de 50 $/mois.

Côté technique, il faut WordPress 6.8+, PHP 8.4+ et MySQL 8.0.19+. Ce n’est pas un outil pour des serveurs vieillissants, clairement.

Ce que Troy fait mieux que WordPress.org (et ce qu’il ne fait pas)

La question que tout développeur se pose : pourquoi distribuer via Troy plutôt que via WordPress.org ? Voici le comparatif honnête.

Ce que Troy fait mieux :

• Zéro file d’attente. Pas de review, pas d’approbation. Vous uploadez, c’est en ligne. Sur WordPress.org, la file de validation peut prendre des jours, voire des semaines
• Zéro risque de suppression arbitraire. C’est votre serveur, personne ne peut retirer votre plugin sans votre accord
• Mises à jour instantanées. Vous poussez une version, vos utilisateurs la reçoivent immédiatement. Pas de délai de propagation
• Licence libre. MIT, pas GPL. Vos plugins gardent la licence que vous choisissez
• Vie privée. Troy ne traque pas les domaines où vos plugins sont installés. WordPress.org le fait

Ce que Troy ne fait PAS :

• Aucune vérification de sécurité. Pas de plugin check, pas de review manuelle, pas d’audit de code. Le développeur est seul responsable de la qualité de son extension. Sur WordPress.org, chaque plugin passe une review humaine avant publication
• Aucune découverte. Pas de marketplace, pas de moteur de recherche, pas de classement. Si personne ne connaît votre Troy Server, personne ne trouvera votre plugin. WordPress.org offre une visibilité immédiate à 60 000+ extensions
• Pas de notes ni d’avis. Pas de système de notation, pas de forum de support intégré. La confiance repose entièrement sur la réputation du développeur
• Statistiques limitées. Nombre de téléchargements, distribution des versions, locales. Pas de données détaillées sur les sites qui utilisent le plugin (c’est un choix de vie privée, pas un oubli)

Pourquoi Troy n’est PAS un fork de WordPress ?

On serait tenté de voir Troy comme "le fork qui va remplacer WordPress.org". Sauf que non. Et la nuance compte.

Troy n’est pas un fork de WordPress. Il ne touche pas au CMS, au core, à l’éditeur. Il ne modifie rien.

Troy n’est pas un remplacement de WordPress.org. Le même plugin peut vivre sur les deux plateformes simultanément. L’en-tête Troy: est une métadonnée inerte que WordPress.org ignore complètement.

Troy n’est pas un outil de protestation. Le site officiel le dit explicitement. C’est un canal de distribution parallèle, pas un acte militant.

Et les mises à jour, comment ça se passe si un plugin est sur les deux ? Point technique à comprendre : quand Troy Client est actif sur votre site, il filtre les plugins Troy hors des requêtes WordPress.org. Concrètement, si un plugin a un en-tête Troy:, ses mises à jour viennent exclusivement de Troy Server. WordPress.org ne le "voit" plus. Les plugins sans en-tête Troy continuent de se mettre à jour normalement via WordPress.org.

Autrement dit : un développeur peut publier son plugin sur les deux canaux (WordPress.org et Troy). Mais côté utilisateur, c’est l’un ou l’autre. Si Troy Client est installé et que le plugin contient l’en-tête Troy, les mises à jour passent par Troy. Sinon, elles passent par WordPress.org. Pas de conflit, pas de doublon.

Pourquoi une licence MIT et pas la GPL ?

WordPress est sous licence GPL. Tout ce qui s’y greffe hérite de cette licence. Vos plugins, vos thèmes : GPL. C’est le fondement philosophique du projet WordPress depuis le début.

Troy a choisi la licence MIT. Plus permissive. Pas de contamination de licence. Vos plugins distribués via Troy gardent la licence que VOUS avez choisie.

Use the code. Modify it. Ship it in commercial products.

Sybre Waaijer, licence MIT de Troy

Utilisez le code. Modifiez-le. Intégrez-le dans des produits commerciaux. C’est aussi simple que ça.

Qu’est-ce que ça signifie en pratique ? Un développeur peut créer un plugin propriétaire, le distribuer via Troy, et ne jamais passer par WordPress.org ni se soumettre à la GPL. Pour les éditeurs de plugins premium, c’est un changement significatif. Pas révolutionnaire, mais significatif.

La communauté WordPress est très attachée à la GPL. Ce choix MIT va forcément créer des débats. Mais Troy ne s’impose pas : il offre un choix que le développeur n’avait pas avant.

ClassicPress, Retraceur : pourquoi les forks WordPress échouent-ils ?

Troy n’est pas le premier projet à vouloir "faire autrement" que WordPress.org. Mais les précédents n’ont pas vraiment décollé.

ClassicPress est un fork de WordPress 4.9, créé en 2018 par des développeurs qui refusaient Gutenberg. En 2024, le projet a voté pour se "re-forker" depuis WordPress 6.2.3. Résultat : ClassicPress 2.0 existe, avec 9 core committers et un budget annuel de moins de 2 000 $ (source : WP Tavern, 2024). Vivant, mais confidentiel.

Retraceur est un fork français créé par Mathieu Viet (imath), ancien lead developer de BuddyPress. Le projet supprime tous les liens vers les API WordPress.org et allège le code en retirant le multisite, les commentaires, l’éditeur classique et le Customizer. Un seul mainteneur, aucune visibilité internationale, mais une vision claire.

imath partage un constat que beaucoup de contributeurs WordPress partagent en privé : le web tissé par Mullenweg depuis 20 ans est devenu "untrustworthy" (peu fiable). Retraceur pousse la logique jusqu’au bout : supprimer toute dépendance à WordPress.org, remplacer Gravatar par Libravatar, substituer les emojis WordPress par des OpenMojis. C’est radical, mais c’est cohérent.

Quid de la viabilité de ces projets ? Leur point commun est qu’ils forkent WordPress lui-même. Ils doivent maintenir le core, suivre les mises à jour de sécurité, gérer la compatibilité des plugins… C’est un travail colossal pour des équipes minuscules.

Troy est malin sur ce point. Il ne forke rien du tout. Il ajoute un canal de distribution par-dessus WordPress, tel qu’il existe déjà. Pas de maintenance du core, pas de compatibilité à gérer. Juste un système de livraison de plugins. C’est beaucoup plus léger, et donc beaucoup plus viable à long terme. Et quand on sait que de plus en plus de plugins WordPress sont abandonnés, avoir un canal de distribution indépendant prend tout son sens.

Mon avis : plan B crédible ou feu de paille ?

Formateur WordPress certifié Qualiopi depuis 2012, fondateur de WPServeur en 2015 et développeur de 8 extensions sur WordPress.org, je vis dans cet écosystème au quotidien depuis plus de 13 ans. Voici ce que je retiens de Troy.

Ce qui me plaît : l’architecture. Ne pas forker WordPress, ne pas créer un répertoire concurrent, mais ajouter un canal parallèle, c’est la bonne approche. C’est pragmatique. Le fait que le même plugin puisse vivre sur WordPress.org ET sur un Troy Server sans conflit, c’est bien pensé.

Ce qui m’inquiète : c’est un projet solo. Sybre Waaijer a écrit 37 347 lignes de code seul. C’est impressionnant, mais le "bus factor" est de 1. Si le développeur arrête, le projet s’arrête. ClassicPress a au moins 9 committers, même avec un budget dérisoire.

Et après ? Est-ce que les gros éditeurs (Yoast, Elementor, WooCommerce…) vont adopter Troy ? Probablement pas à court terme. Ils n’ont aucun intérêt à fragiliser leur relation avec WordPress.org. Mais les développeurs indépendants, ceux qui ont un ou deux plugins, ceux qui en ont marre de la file d’attente du répertoire officiel… eux pourraient y trouver leur compte.

Troy pose surtout la bonne question. Pas "faut-il quitter WordPress.org ?", mais "est-il normal qu’une seule entité contrôle la distribution de plugins pour un CMS qui fait tourner 42,4 % du web (source : W3Techs, avril 2026) ?"

Et la réponse est non.

Qu’est-ce que ça change si vous gérez un site WordPress ?

Si vous êtes propriétaire d’un site : rien ne change dans l’immédiat. Vos plugins continuent de se mettre à jour via WordPress.org. Mais si un jour l’un de vos plugins passe sur Troy, vous installerez Troy Client (30 secondes, selon la doc) et vous continuerez à recevoir les mises à jour comme avant. Pas de panique. En attendant, pensez à vérifier régulièrement l’état de sécurité de vos extensions.

Si vous êtes développeur ou agence : Troy vaut un test. Mon conseil : installez Troy Server sur un serveur de staging, uploadez une extension, testez le workflow. Ça prend 5 minutes. Au minimum, vous saurez que le plan B existe le jour où WordPress.org fera des siennes.

Si vous êtes freelance WordPress : gardez un œil dessus. Vos clients ne vous poseront pas la question aujourd’hui. Mais quand le prochain drama éclatera (et il y en aura un, on est dans l’écosystème WordPress…), ils voudront savoir si leurs plugins sont "safe". Avoir une réponse prête, c’est ce qui fait la différence entre un prestataire et un expert.

Et c’est pas fini… Troy ne gère que les plugins pour le moment. Les thèmes sont dans la roadmap. L’intégration GitLab et Bitbucket aussi. Si le projet survit à sa première année, 2026 pourrait être l’année où la distribution WordPress se décentralise pour de bon.

Quoi qu’il arrive, Troy a déjà réussi quelque chose : prouver que c’est techniquement possible. Le répertoire WordPress.org n’est plus la seule option. De facto, c’est un changement. Et les changements, contrairement aux dramas, ne disparaissent pas avec la prochaine polémique.

Si le sujet de la gouvernance et de l’avenir de WordPress vous intéresse, j’ai décortiqué les objections de ceux qui prédisent la mort de WordPress dans un article dédié.

Questions fréquentes

Troy est-il gratuit ?

Oui. Troy Server et Troy Client sont gratuits et open source, distribués sous licence MIT. Le code est disponible sur GitHub. Aucun abonnement, aucun frais caché.

Mes plugins WordPress.org sont-ils compatibles avec Troy ?

Oui. Le même fichier plugin peut fonctionner sur WordPress.org et via un Troy Server. Il suffit d’ajouter un en-tête Troy: dans le fichier principal du plugin. WordPress.org ignore cette métadonnée. En revanche, si Troy Client est installé côté utilisateur, les mises à jour de ce plugin passent exclusivement par Troy Server.

Troy peut-il distribuer des thèmes WordPress ?

Pas encore. En avril 2026, Troy ne gère que les plugins. Le support des thèmes est prévu dans la roadmap, avec également l’intégration GitLab/Bitbucket et la distribution de packages de traduction.

Est-ce que Troy vérifie la qualité ou la sécurité des plugins ?

Non. Contrairement à WordPress.org qui impose une review manuelle avant publication, Troy ne vérifie rien. Le développeur est seul responsable de la qualité et de la sécurité de son extension. C’est le prix de la liberté : pas de gatekeeping, mais pas de filet de sécurité non plus.

Est-ce que Troy collecte des données sur mon site ?

Non. Troy ne collecte pas les noms de domaine ni les données personnelles. Le système utilise des identifiants anonymes à rotation hebdomadaire et ne communique qu’en HTTPS. Seules les statistiques agrégées (nombre de téléchargements, distribution des versions) sont enregistrées.

Qui est derrière Troy ?

Sybre Waaijer, développeur néerlandais et créateur de The SEO Framework. Il a développé Troy seul via sa société CyberWire B.V. Le projet est open source et la communauté peut contribuer via GitHub et Discord.