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

> L’intuition est raisonnable : un éditeur payé a les moyens de faire relire son code. Les chiffres publiés par les organismes qui recensent ces failles racontent une histoire nettement moins confortable.

- Source canonique : [https://allaux.fr/securite/extensions-payantes-sont-elles-plus-sures](https://allaux.fr/securite/extensions-payantes-sont-elles-plus-sures)
- Langue : FR
- Dernière mise à jour : 2026-09-30

## Réponse directe

> Le critère utile n’est pas le prix mais la fréquence des correctifs. Devant chaque extension installée, regardez la date de la dernière version publiée, le nombre de versions sorties sur douze mois et l’existence d’un canal où l’éditeur annonce ses correctifs de sécurité. Une extension payante ne se met souvent à jour qu’avec une licence active : vérifiez que la vôtre l’est toujours.

## 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.

| Valeur | Description |
|---|---|
| 76 % | des vulnérabilités signalées sur des composants premium étaient exploitables |
| 59 % | des signalements portant sur des composants premium étaient de haute priorité |
| 3 fois plus | de vulnérabilités effectivement exploitées côté premium que côté gratuit |

Source : Patchstack, State of WordPress Security in 2026 (chiffres portant sur 2025)

## 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.

## Comment évaluer un éditeur, autrement que sur son prix

1. **La fréquence des publications** — Regardez le journal des versions sur les deux dernières années. Un éditeur qui publie régulièrement, y compris de petites corrections, a un processus vivant. Un composant figé depuis dix-huit mois alors que le CMS a changé plusieurs fois est un pari, quel que soit son prix.
2. **L’existence d’une page de sécurité** — Une adresse pour signaler une faille, une procédure de divulgation, un historique d’avis publiés. Un éditeur qui n’a rien prévu pour recevoir un signalement ne le traitera pas plus vite parce que vous êtes client.
3. **La réactivité constatée sur les avis passés** — Cherchez les avis de sécurité déjà publiés sur ses composants et mesurez le délai entre le signalement et la version corrigée. C’est le seul indicateur qui porte sur des faits, pas sur des promesses commerciales.
4. **La question à poser avant de payer** — « Comment serai-je prévenu si une faille est publiée sur ce module ? » S’il n’existe pas de liste de diffusion de sécurité, pas de notification dans le back-office, pas d’engagement écrit, la réponse réelle est : vous ne le serez pas, et c’est à vous de surveiller.

## La liste qui manque à presque toutes les boutiques

> Je demande systématiquement la même chose avant d’intervenir : la liste des composants payants installés, avec pour chacun le nom de l’éditeur, la version en place, l’état de la licence et surtout la réponse à une question simple — est-ce que celui-là se met à jour tout seul, ou faut-il aller le chercher à la main ? Cette dernière colonne est celle qui compte. Ce sont ces composants-là qui restent en version vulnérable pendant des mois après la publication d’un correctif, non par négligence, mais parce que rien dans le tableau de bord ne signale qu’une nouvelle version existe. Tout ce qui ne se met pas à jour seul doit être suivi manuellement, ou remplacé par quelque chose qui l’est.

## Pour aller plus loin

- **Modules et extensions abandonnés** — Ce qui se passe quand l’éditeur, payant ou non, cesse de publier des correctifs. ([/securite/modules-et-extensions-abandonnes](/securite/modules-et-extensions-abandonnes))
- **Surveiller les failles qui concernent ma boutique** — Comment être prévenu pour les composants dont personne ne vous préviendra. ([/securite/surveiller-les-failles-qui-concernent-ma-boutique](/securite/surveiller-les-failles-qui-concernent-ma-boutique))
- **Vérifier ses extensions avant une mise à jour** — Faire l’inventaire des versions et des licences avant de toucher au site. ([/wordpress-woocommerce/mise-a-jour/verifier-extensions-avant-mise-a-jour](/wordpress-woocommerce/mise-a-jour/verifier-extensions-avant-mise-a-jour))
- **Modules PrestaShop** — Les problèmes que je rencontre le plus souvent sur les modules tiers d’une boutique. ([/prestashop/module-sur-mesure](/prestashop/module-sur-mesure))

## FAQ

### Faut-il en conclure que les extensions gratuites sont plus sûres ?

Non, et ce serait une mauvaise lecture des chiffres. Les composants gratuits représentent l’écrasante majorité des vulnérabilités recensées en volume. Ce que montrent les chiffres premium, c’est que le prix n’est pas un indicateur de sécurité : il faut évaluer l’éditeur, sa fréquence de publication et sa manière de traiter les signalements, pas le montant de la facture.

### Une licence expirée pose-t-elle un problème de sécurité ?

Oui, presque toujours. Sur la plupart des composants payants, c’est la licence qui autorise le téléchargement des mises à jour. Une licence expirée signifie que le module reste fonctionnel mais figé dans sa version du jour de l’expiration, y compris quand un correctif de sécurité sort ensuite. C’est l’une des causes les plus fréquentes de composants vulnérables que je trouve sur des boutiques par ailleurs bien tenues.

### Comment savoir si mes extensions payantes se mettent à jour automatiquement ?

Vérifiez, composant par composant, si une nouvelle version apparaît dans le back-office ou s’il faut se connecter au site de l’éditeur pour la récupérer. Le mécanisme intégré du CMS ne voit que le canal officiel ; tout le reste dépend d’un système de licence propre à l’éditeur, qui doit être actif et correctement configuré pour fonctionner.

### Que faire d’un module payant dont l’éditeur a disparu ?

Le supprimer, pas seulement le désactiver : sur beaucoup d’installations, les fichiers d’un module désactivé restent accessibles et exécutables. S’il assure une fonction indispensable, il faut planifier son remplacement, et en attendant restreindre au maximum l’accès à ses fichiers au niveau du serveur.

### Un module officiel de la plateforme est-il plus fiable qu’un module tiers ?

Il est en général mieux suivi, avec une procédure de signalement claire et des correctifs publiés rapidement, ce qui compte beaucoup. Mais il n’est pas à l’abri : un module officiel PrestaShop a été concerné par une faille de score 9,1 permettant la prise de contrôle de comptes clients, corrigée en octobre 2025. La différence porte sur la vitesse de correction, pas sur l’absence de failles.