J’ai payé mes extensions : suis-je mieux protégé

Ce que le prix achète réellement

Le raisonnement se tient dans son principe : un éditeur qui vit de ses ventes peut employer quelqu’un, tenir un support, publier vite. C’est vrai, et je ne conseille jamais de choisir systématiquement la version gratuite d’un composant. Mais il faut être précis sur ce que la facture couvre réellement.

Elle couvre du support, c’est-à-dire quelqu’un qui répond quand ça ne marche pas. Elle couvre des fonctionnalités qui n’existent pas dans la version libre. Elle couvre parfois un engagement de maintenance sur une durée donnée, écrit noir sur blanc, qui garantit des mises à jour de compatibilité. Ce sont trois choses utiles et je les recommande.

Ce qu’elle ne couvre presque jamais, c’est une relecture de sécurité du code par quelqu’un dont c’est le métier. Rien, dans le prix d’un module, ne garantit qu’une paire d’yeux extérieurs ait cherché des défauts d’autorisation ou des entrées non filtrées avant la mise en vente. La qualité du support et la qualité sécurité du code sont deux dimensions distinctes, et payer améliore surtout la première.

Pourquoi le payant est structurellement moins bien surveillé

Je ne lis pas ces chiffres comme « le payant est pire ». Ce serait aussi faux que l’inverse, et le biais est facile à identifier : un composant payant est souvent plus complexe, plus proche des données de commande, et installé sur des boutiques qui ont de quoi payer, donc plus intéressantes. Mais trois mécanismes structurels pèsent réellement, et ils tiennent à la manière dont ces extensions circulent, pas au sérieux de leurs auteurs.

• Elles ne passent pas par le dépôt public. Un composant publié sur un dépôt officiel est visible par n’importe qui, relu par des bénévoles, passé au crible d’outils automatisés, et peut en être retiré le jour où une faille est confirmée. Un composant vendu depuis le site de son éditeur n’est examiné que par ceux qui l’ont acheté.
• Elles ne bénéficient pas des mises à jour automatiques du dépôt. Le mécanisme de mise à jour intégré au CMS ne voit que ce qui vient du canal officiel. Une extension payante se met à jour via son propre système de licence, qui doit être valide, correctement configuré, et qui cesse souvent de fonctionner à l’échéance de l’abonnement.
• Leurs failles sont moins souvent signalées publiquement. Il faut acheter une licence pour auditer le code, ce que peu de chercheurs font spontanément. Une faille peut donc exister longtemps sans être documentée nulle part, ce qui ne la rend pas inoffensive, seulement invisible pour vous.

Le contexte général reste par ailleurs sans ambiguïté : sur les 11 334 nouvelles vulnérabilités recensées dans l’écosystème WordPress en 2025, soit 42 % de plus que l’année précédente, 91 % concernaient des extensions et 9 % des thèmes. Le cœur du CMS n’en comptait que 6, toutes de faible gravité. Le risque ne vient pas de la plateforme, il vient de ce qu’on y ajoute, gratuit ou payant.

Trois cas qui déplacent le raisonnement

Payer peut même être le facteur d’exposition. En juin 2026, l’infrastructure de compilation et de distribution de l’éditeur ShapedPlugin a été compromise : plusieurs versions de ses extensions Pro ont été distribuées piégées, avec un code qui extrayait la configuration du site, les comptes administrateurs, des identifiants d’envoi d’e-mail et les commandes WooCommerce des trois derniers mois. La remédiation a commencé le 16 juin 2026, la publication est intervenue le 22 juin 2026, et la référence est CVE-2026-10735, score 9,8. Le point qui compte ici : seules les versions Pro, distribuées par le canal de l’éditeur, étaient concernées. Les versions gratuites publiées sur le dépôt WordPress.org ne l’étaient pas.

Un éditeur de premier plan n’est pas immunisé. Le module officiel ps_checkout, publié par PrestaShop, a été touché par CVE-2025-61922, score 9,1 : une validation manquante sur la fonctionnalité Express Checkout permettait la prise de contrôle d’un compte client à partir de son adresse e-mail, sans aucun privilège ni interaction. Les correctifs ont été publiés le 16 octobre 2025 en versions 4.4.1 et 5.0.5. Moyens et sérieux réduisent le risque, ils ne le suppriment pas.

Un contrat ne survit pas à son éditeur. En mai 2026, un avis a documenté CVE-2026-39079, score 8,6, sur un module de transport pour PrestaShop dont le dossier de journaux était accessible publiquement, exposant des identifiants d’API et des données personnelles de clients. Aucun correctif ne sera publié : l’éditeur n’est plus en activité. La seule remédiation possible est la suppression du module, la désactivation ne suffisant pas. C’est le point aveugle de l’achat : vous payez un logiciel, vous ne payez pas la permanence de celui qui le maintient.