Je viens du monde Drupal. Cela fait plus de quinze ans que j'installe, configure et maintiens des modules contrib — des modules parfois d'une complexité remarquable, qui gèrent des workflows métier élaborés, des intégrations bancaires, du multilingue, du multi-site — et qui sont distribués gratuitement, sous licence GPL, avec leur code source intégralement lisible, leur historique de commits public, et leur changelog accessible à n'importe qui.

Je n'ai jamais payé la moindre licence pour un module Drupal contrib.

Ce n'est pas parce que la communauté Drupal est naïve ou désintéressée. C'est parce qu'elle a collectivement décidé que la valeur se crée dans les services, pas dans les verrous.

WordPress a fait un autre choix.

Le plugin commercial : une réponse à la mauvaise question

L'idée de faire payer un plugin WordPress n'est pas absurde en soi. Maintenir du code prend du temps, répondre au support aussi. Mais la façon dont ce modèle s'est développé dans l'écosystème WP produit des effets pervers que je constate chaque semaine sur le terrain.

Premier effet : le plugin commercial n'a aucune obligation de transparence. Pas de changelog public, pas de dépôt git accessible, pas de liste de CVE, pas d'annonce de version. Si vous voulez savoir si un bug critique a été corrigé dans la dernière version, vous devez d'abord acheter la licence. Et si vous ne savez pas que le bug existe — parce que, justement, il n'est pas documenté publiquement — vous ne saurez jamais que vous êtes vulnérable.

C'est exactement la situation que j'ai rencontrée cette semaine. Un plugin de passerelle de paiement, commercial, 69 € par an, installé sur le site d'une cliente sans que la licence lui ait jamais été transmise par le prestataire initial. Impossible de savoir si la version installée — datant de 2022 — contient des correctifs de sécurité disponibles dans une version plus récente. Impossible, sans débourser 69 €, d'avoir accès à la moindre information.

La GPL comme paravent

WordPress est distribué sous licence GPL. En théorie, tout plugin distribué pour WordPress devrait l'être aussi. En pratique, le marché des plugins commerciaux a prospéré pendant vingt ans dans un angle mort juridique confortable, en exploitant l'ambiguïté entre le code et le service, entre la licence du plugin et celle de ses assets, entre la distribution et l'utilisation.

Le résultat concret : des plugins dont le code source est techniquement GPL mais dont l'accès aux mises à jour est conditionné à une licence payante annuelle. Ce n'est pas illégal. Ce n'est pas transparent non plus.

Et surtout : cela crée une asymétrie d'information structurelle entre l'éditeur du plugin — qui sait exactement quels bugs existent et quand ils ont été corrigés — et le propriétaire du site, qui ne sait rien de tout ça.

Ce que le code fermé cache

Je ne vais pas prétendre avoir audité tous les plugins commerciaux WP qui existent. Mais dans ma pratique, j'en ai ouvert suffisamment pour avoir une opinion.

La qualité de code d'un plugin WordPress commercial n'est pas garantie par son prix. Ni par son volume de ventes. Ni par le fait qu'il soit listé sur une marketplace reconnue. J'ai vu des plugins à 79 $ la licence avec des injections SQL patentes. Des plugins à 49 $ qui font des appels d'API externes non authentifiés. Des plugins de paiement qui stockent des données de transaction dans des options WordPress non chiffrées.

WordPress souffre d'une réputation de passoire sécuritaire. Cette réputation est méritée — non pas parce que le core WordPress est particulièrement mal conçu, mais parce que l'écosystème de plugins a été bâti sur une culture du ship fast, patch if noticed. Quand le plugin est commercial et le changelog privé, le patch if noticed devient patch si quelqu'un achète la mise à jour.

Dans l'écosystème Drupal, un module contrib avec une vulnérabilité critique déclenche une Security Advisory publique, une release estampillée SA-CONTRIB, une communication formelle de la Security Team. Tout le monde est informé. Tout le monde peut patcher. Même ceux qui n'ont pas de budget.

Dans l'écosystème WordPress commercial, rien de tel n'est obligatoire. L'éditeur peut corriger silencieusement, bumper la version, et laisser les sites non licenciés — ou les sites dont le propriétaire n'a pas pensé à mettre à jour — continuer à tourner sur le code vulnérable.

Le prestataire, maillon manquant

Il y a un troisième acteur dans cette chaîne, et il aggrave tout : le prestataire intermédiaire.

Dans beaucoup de cas que je rencontre, c'est le prestataire qui a acheté la licence — ou qui l'a utilisée depuis son propre compte, parce que c'est plus simple — et qui l'a installée sur le site du client. Quand le prestataire disparaît, la licence disparaît avec lui. Le site continue de fonctionner — jusqu'à ce qu'il ne fonctionne plus. Les mises à jour s'arrêtent. Le support devient inaccessible. Et le client, qui ne sait pas que le plugin est commercial ni qu'une licence est nécessaire, ne comprend pas pourquoi son site dérive progressivement vers l'obsolescence.

C'est une dépendance silencieuse. Pas malveillante, dans la plupart des cas — juste le résultat d'une chaîne où personne n'a pris la responsabilité de documenter ce qui a été installé, pourquoi, et à qui ça appartient.

Un prestataire sérieux documente chaque composant installé, son éditeur, son coût, sa licence, et le nom sous lequel cette licence doit être enregistrée : celui du client, pas le sien.

Ce que je recommande

À mes clients qui utilisent WordPress et WooCommerce, je recommande systématiquement :

Exiger un inventaire complet de chaque plugin installé, avec son éditeur, son modèle de licence, son coût annuel et le titulaire de la licence. Si le prestataire ne peut pas fournir cette liste, c'est un signal.

Préférer les plugins distribués sur le dépôt officiel WordPress.org. Pas parfait — des plugins wordpress.org ont aussi leurs problèmes — mais au moins le changelog est public, les security advisories sont centralisées, et les mises à jour ne dépendent pas d'une licence payante.

Se méfier des plugins de niche à éditeur unique, surtout dans des domaines sensibles : paiement, conformité RGPD, gestion de données personnelles. Dans ces domaines, la qualité du code n'est pas optionnelle — et elle doit être vérifiable.

Traiter une licence de plugin comme n'importe quel autre abonnement professionnel. Elle doit être au nom de l'entreprise cliente, avec une adresse email que la cliente contrôle, et intégrée dans le budget de maintenance annuel du site.

La vraie question

La vraie question n'est pas "est-ce que les plugins commerciaux WP valent leur prix". Certains, oui. Beaucoup, non.

La vraie question est : est-ce qu'un plugin qui touche à la sécurité, au paiement ou aux données personnelles peut se permettre de ne pas avoir de changelog public ?

Ma réponse est non. Et tant que cette norme ne sera pas imposée — par la communauté, par les marketplaces, ou par la réglementation — les propriétaires de sites WordPress continueront à naviguer à l'aveugle sur un sujet qui n'en a pas les moyens.