En bref
- PrestaShop 1.7 n’est plus maintenu depuis le 10 juin 2025, date de sortie de PrestaShop 9.0. Plus aucun correctif, y compris de sécurité. L’information a été publiée dans les canaux techniques du projet, sans provoquer la moindre rupture visible dans les back-offices.
- Le vrai trou est en dessous. La documentation officielle plafonne la 1.7.8 à PHP 7.4, dont la fin de vie remonte au 28 novembre 2022. Aucun module et aucun pare-feu ne corrige une faille dans l’interpréteur lui-même.
- PrestaShop 8 ne règle pas ce point : la même documentation plafonne toute la branche 8, 8.2 comprise, à PHP 8.1, en fin de vie depuis le 31 décembre 2025. La cible d’une migration est PrestaShop 9, pas PrestaShop 8.
- Migrer ne répond pas qu’à un problème de sécurité. Le thème livré par défaut avec PrestaShop 9.1 est conçu autour des exigences européennes d’accessibilité, opposables aux sites marchands depuis le 28 juin 2025. Une migration traite donc deux obligations à la fois.
- Depuis janvier et février 2026, l’écosystème de modules quitte la 1.7 : badge qualité retiré et mises à jour refusées si le module n’est pas compatible avec la dernière version de PrestaShop.
- Une exigence de conformité est déjà opposable : depuis le 31 mars 2025, la norme carte bancaire impose de vérifier chaque année que chaque technologie utilisée reçoit encore des correctifs de son éditeur.
- La découverte de failles accélère, et l’écart se creuse. Sur un logiciel maintenu, une faille trouvée devient un correctif. Sur un logiciel abandonné, elle devient une exposition définitive. Le stock de failles connues dans PrestaShop 1.7 ne peut plus que grossir.
- L’inventaire précède le devis. Le coût d’une migration ne se trouve pas dans la version de PrestaShop, il se trouve dans la liste de vos modules et de vos surcharges. Elle se fait sans outil, depuis votre back-office.
Ouvrez votre back-office, en bas de la page d’accueil, et lisez le numéro de version. S’il commence par 1.7, la suite vous concerne directement. Rien n’a cassé, aucun courrier n’est arrivé, la boutique prend des commandes comme hier. Trois choses se sont pourtant arrêtées, à trois dates différentes, et la dernière vient seulement de se produire.
Fin de support de PrestaShop 1.7 : ce qui s’est arrêté, et quand
1. Le cœur, le 10 juin 2025. En janvier 2023, le projet PrestaShop avait publié une phrase qui engageait l’avenir : la période de maintenance de la 1.7 prendrait fin à la sortie de PrestaShop 9.0, et ce jour-là, la 1.7 ne serait plus maintenue. PrestaShop 9.0 est sorti le 10 juin 2025. La phrase a donc pris effet sans que personne n’ait à la republier. Depuis cette date, aucun correctif n’est publié pour la 1.7, y compris pour une faille de sécurité.
2. Le langage, le 28 novembre 2022. Celui-là est plus ancien et plus profond, et c’est le point que les audits ratent le plus souvent parce qu’on regarde la version de la boutique sans regarder celle du langage qui l’exécute. La table de compatibilité officielle plafonne PrestaShop 1.7.8 à PHP 7.4. Or PHP 7.4 a cessé d’être maintenu le 28 novembre 2022. Une boutique en 1.7 tourne donc, au mieux, sur un interpréteur sans correctif depuis bientôt quatre ans. C’est une couche que ni un module, ni un pare-feu applicatif, ni la bonne volonté d’un hébergeur ne peuvent rattraper.
3. Le marché des modules, en janvier et février 2026. Depuis le 1er janvier 2026, le badge de qualité de la place de marché officielle est retiré à tout module non compatible avec la dernière version de PrestaShop. Depuis le 1er février 2026, une mise à jour de module non compatible avec la dernière version est refusée à la validation. Le socle attendu est désormais de fonctionner avec les deux dernières versions majeures.
Pourquoi un module encore compatible 1.7 ne garantit pas la sécurité
Il existe encore des modules vendus comme compatibles 1.7, et cette mention est spontanément lue comme une garantie. C’est l’inverse.
Un module encore présenté comme compatible 1.7 est, depuis le début de l’année, soit hors du circuit de validation officiel, soit maintenu pour une plateforme que son propre éditeur ne corrige plus. Et même parfaitement à jour, il ne protège pas une boutique dont le cœur et le langage sont figés. La compatibilité d’un module ne dit rien de la sécurité de la boutique qui l’accueille, exactement comme un site parfaitement accessible sur sa page d’accueil peut rester inutilisable dans son tunnel de commande.
Voilà pourquoi le sujet ne remonte jamais : pris isolément, chaque indicateur consulté est au vert.
Y compris le plus trompeur de tous. Une boutique vulnérable continue d’afficher ses produits, de prendre des commandes et d’encaisser normalement. Le bon fonctionnement n’est pas un indicateur de sécurité. Le seul qui en soit un, c’est la date du dernier correctif disponible pour votre socle.
Ces tables réservent une surprise qui change la cible d’une migration. La documentation officielle plafonne toute la branche PrestaShop 8, version 8.2 comprise, à PHP 8.1, dont la fin de vie est intervenue le 31 décembre 2025. S’arrêter à PrestaShop 8 fait donc sortir de la version non maintenue, mais laisse la boutique sur un langage qui ne reçoit déjà plus de correctif. Seul PrestaShop 9, qui accepte PHP 8.1 à 8.5, remet la pile entière sur des branches soutenues. La documentation le dit elle-même, en notant que les versions de PHP arrivées en fin de support sont compatibles mais déconseillées.
À retenir pour arbitrer un budget : passer de PrestaShop 1.7 à PrestaShop 8 est une étape technique du chemin, pas une destination. La destination est PrestaShop 9.
Pourquoi l’écart se creuse : la découverte de failles s’accélère
Depuis 2026, un argument circule chez les prestataires : les intelligences artificielles vont armer une génération d’attaquants et tout précipiter. Les chiffres publiés disent autre chose.
Des modèles d’intelligence artificielle sont désormais capables de chercher des failles dans du code existant, à grande échelle. Anthropic a annoncé le 7 avril 2026 un modèle nommé Mythos, qu’il a choisi de ne pas diffuser publiquement pour des raisons de sécurité, et a rapporté plus de 23 000 constats issus du programme associé. Sur ces 23 000 constats, 126 ont donné lieu à une faille publiée, et une seule a été confirmée exploitée dans la nature. Plus largement, sur les 1 061 vulnérabilités attribuées à une découverte assistée par intelligence artificielle au premier semestre 2026, l’éditeur de renseignement VulnCheck en a confirmé 14 exploitées, soit 1,3 %.
La déferlante n’a donc pas eu lieu, et VulnCheck conclut même que ces outils profitent pour l’instant davantage aux défenseurs qu’aux attaquants. Qui vous vend une migration en agitant ce spectre force le trait.
Ce qui est mesuré, en revanche, c’est la compression du temps. Le délai médian entre la publication d’une faille et le moment où son exploitation est constatée est passé de 120 jours en 2025 à 80 jours au premier semestre 2026, sur 495 vulnérabilités nouvellement exploitées.
Le point qui compte vraiment Quand la découverte de failles accélère, un logiciel maintenu transforme chaque découverte en correctif. Un logiciel abandonné transforme chaque découverte en exposition définitive. L’écart entre les deux ne dépend pas du nombre d’attaquants, il se creuse mécaniquement avec le rythme des découvertes.
C’est la raison pour laquelle le sujet est plus pressant en 2026 qu’en 2023. Non pas parce que les attaquants seraient devenus plus nombreux, ce que les données disponibles ne montrent pas, mais parce que le stock de failles connues dans une version figée ne peut plus que grossir, pendant que le délai pour réagir se raccourcit. Sur une version maintenue, ce stock se vide à chaque correctif. Sur PrestaShop 1.7, il ne se videra jamais.
PrestaShop 1.7, PCI DSS et réglementation : ce qui a changé en 2025 et 2026
Tant que rester en 1.7 relevait d’un arbitrage technique, la décision pouvait légitimement attendre. Deux textes ont sorti le sujet de ce registre, et chacun porte une date.
La norme de sécurité des données de l’industrie des cartes de paiement, dans sa version 4.0.1, s’applique à toute boutique qui traite de la carte bancaire. Ses exigences dites futures sont obligatoires depuis le 31 mars 2025. L’une d’elles impose de passer en revue, au moins une fois par an, l’ensemble des technologies matérielles et logicielles utilisées, pour confirmer que chacune reçoit encore des correctifs de sécurité de son éditeur. Une boutique reposant sur PrestaShop 1.7 fait immédiatement apparaître un problème lors de cette revue : l’une des technologies centrales qu’elle utilise ne reçoit plus de correctifs de son éditeur. Le socle porte d’ailleurs bien d’autres obligations que celle-là, et pas toujours celles qu’on croit, comme le montre notre matrice de conformité des socles e-commerce. La norme n’interdit pas d’utiliser une technologie en fin de support, elle impose de le constater et de documenter un plan pour y remédier. Une autre exigence demande d’appliquer les correctifs critiques sous trente jours, ce qui n’a plus d’objet quand il n’en sort plus.
Le règlement européen sur la cyber-résilience, lui, est entré en vigueur le 10 décembre 2024, ses obligations de signalement s’appliquent depuis le 11 septembre 2026 et il s’appliquera pleinement le 11 décembre 2027. Précision d’honnêteté, parce qu’elle est systématiquement escamotée dans les articles sur le sujet : ces obligations pèsent sur les éditeurs de logiciels, pas sur le marchand, et la façon dont le texte qualifiera un module e-commerce vendu séparément n’est pas encore stabilisée. Nous ne vous dirons donc pas ce que vos fournisseurs devront faire. Ce qu’on peut dire sans risque, c’est que le sens du texte est de rendre la maintenance des logiciels opposable à ceux qui les publient, et que cela pousse l’écosystème dans la même direction que les règles de la place de marché décrites plus haut.
Mettre à jour PrestaShop 1.7 : l’inventaire à faire avant tout devis
La question qu’on nous pose est toujours celle du budget. Or le budget d’une migration ne se trouve pas dans la version de PrestaShop, qui est la partie outillée et prévisible. Il se trouve dans vos modules et vos surcharges. Voici comment l’établir vous-même, en une heure, avant de demander le moindre chiffrage.
1. Relevez votre version exacte et votre version de PHP. La première est en bas de la page d’accueil du back-office, la seconde dans les informations de configuration. Notez les deux, elles conditionnent tout le reste.
2. Listez vos modules installés et actifs. Uniquement les actifs. Les modules désactivés depuis trois ans ne sont pas un sujet de migration, ce sont des fichiers à retirer.
3. Pour chaque module, remplissez trois colonnes : l’éditeur, la version installée, et l’existence d’une version compatible avec PrestaShop 9. Cette troisième colonne se remplit sur la fiche du module chez son éditeur, en quelques minutes par ligne.
4. Classez le résultat en trois piles. Une version 9 existe, c’est une simple ligne de mise à jour. Elle n’existe pas mais l’éditeur est actif, c’est une question à lui poser tout de suite, car sa réponse fixe votre calendrier. Elle n’existe pas et l’éditeur a disparu, c’est un remplacement à prévoir, et c’est cette pile qui fait déraper les budgets quand on ne l’a pas vue venir.
Ce dernier point rejoint un angle mort que nous décrivions à propos du suivi côté serveur : une chaîne de mesure ou de suivi se casse silencieusement, sans jamais produire d’erreur.
5. Recensez vos surcharges et votre thème. Un thème maintenu et documenté simplifie généralement la migration, sans la rendre gratuite pour autant : entre PrestaShop 1.7 et 9, des adaptations restent probables. Un thème acheté il y a plusieurs années puis modifié directement dans ses fichiers demande en revanche un audit spécifique, et il vaut mieux le poser maintenant que le découvrir en cours de route.
Le tableau à remplir tient en cinq colonnes, et il ressemble à ceci.
| Module | Éditeur, version | Version PrestaShop 9 | Action |
|---|---|---|---|
| Transporteur | Éditeur actif, 2.4 | Oui | Mise à jour |
| Fidélité | Éditeur actif, 1.8 | Non annoncée | Écrire à l’éditeur, la réponse fixe le calendrier |
| Import catalogue | Éditeur injoignable, 3.1 | Non | Remplacement à budgéter |
Pour ne pas le faire dans un tableur vide, nous publions ce modèle en accès libre dans nos ressources : l’inventaire de migration PrestaShop 1.7 vers 9. Il rend un verdict par module, compte les trois piles et exporte le tout en CSV. Le calcul se fait dans votre navigateur, rien n’est envoyé ni conservé.
À la fin de cet inventaire, vous savez ce que vous coûte votre situation. Pas avant. Et vous arrivez chez un prestataire avec votre liste, ce qui change la nature de la conversation.
PrestaShop 8 ou PrestaShop 9 : quatre postures possibles
| Posture | Ce que ça donne | Pour qui |
|---|---|---|
| Ne rien faire | Le risque ne se manifeste pas tant qu’il ne se manifeste pas. Mais la revue annuelle exigée par la norme carte bancaire, elle, échoue dès maintenant | Personne, sauf les cas de sursis ci-dessous |
| Réduire la surface sans migrer | Retrait des modules inutilisés, veille active sur les avis de sécurité, sauvegardes vérifiées. Gagne des mois, ne règle rien | Boutique dont la refonte est déjà décidée, ou en fin de vie commerciale |
| S’arrêter à PrestaShop 8 | Sort de la version non maintenue, mais la documentation officielle plafonne cette branche à PHP 8.1, dont la fin de vie est déjà passée. Le problème de fond n’est pas réglé | Contrainte technique forte sur un module bloquant, en sachant qu’on repassera |
| Migrer jusqu’à PrestaShop 9 | Pile soutenue pour plusieurs années, thème par défaut conçu pour l’accessibilité, remises et expédition repensées | La majorité des boutiques actives qui comptent durer |
Ces postures se combinent dans le temps. Réduire la surface en attendant une migration budgétée au trimestre suivant est une décision parfaitement défendable. Réduire la surface en attendant indéfiniment n’en est pas une. Le choix du socle et son entretien relèvent de notre expertise e-commerce et marketplaces, où cette question revient plus souvent que celle des fonctionnalités.
Ce que la migration vers PrestaShop 9 apporte, au-delà de la sécurité
Deux éléments méritent d’entrer dans l’arbitrage budgétaire, parce qu’ils fusionnent des lignes de dépense que vous portez déjà séparément.
Le premier est l’accessibilité. Depuis le 28 juin 2025, les sites marchands y sont tenus. Le thème par défaut livré avec la version courante de PrestaShop, arrivée en mars 2026, atteint selon le projet plus de 95 % de conformité aux exigences européennes, avec le HTML sémantique, les attributs ARIA, la navigation au clavier et les contrastes intégrés dès la conception. Une obligation que vous devez traiter de toute façon se trouve en grande partie réglée par une migration, au lieu de s’y ajouter.
Le second est la disparition de contournements que beaucoup de boutiques paient aujourd’hui en modules ou en développement spécifique : un système de remises repensé autour de quatre types clairs, et la levée de la contrainte historique d’un seul transporteur par commande. Vérifiez votre facture de modules avant de considérer la migration comme un pur coût.
Sur la crainte de casser une boutique qui marche, enfin : le module officiel de mise à jour gère la sauvegarde, la mise à jour et la restauration, et dispose d’une interface en ligne de commande utilisable depuis une chaîne d’intégration. Une migration correctement conduite se répète sur une copie jusqu’à devenir ennuyeuse, puis se rejoue en production. Ce n’est pas un saut sans filet.
L’outillage
La suite est technique et n’a pas sa place ici : ordre des opérations, reprise des données, redirections permanentes, modules à remplacer poste par poste. C’est le métier de Datafirefly Limited, la société sœur de notre agence, qui édite des modules PrestaShop et conduit ces migrations. Leur trajectoire est la même que celle décrite ici : deux marches, 1.7 vers 8 puis 8 vers 9, avec PrestaShop 9 comme destination et non comme option.
Vous avez fait l’inventaire ?
Si vous disposez maintenant de votre version de PrestaShop, de votre version de PHP et de votre tableau de modules, l’étape suivante est un audit. Datafirefly en propose un de trente minutes, en partage d’écran, qui débouche sur un rapport chiffré avant la moindre ligne de code.
Un mot d’honnêteté sur ce que ce genre d’accompagnement fait et ne fait pas. Il ne rend pas une migration indolore, et personne ne devrait vous le promettre. Ce qu’un travail sérieux garantit, c’est qu’aucune surprise n’est découverte en production, ce qui n’est pas la même promesse. La méthode prime sur le prestataire, et les exigences ci-dessus valent quel que soit celui que vous retenez : inventaire avant devis, migration jouée sur une copie, et vérification du tunnel de commande poste par poste avant remise en service.
Ce que ça dit de plus grand
Le logiciel de commerce en ligne est passé, en une décennie, du statut d’achat à celui d’abonnement à une maintenance. Le glissement s’est fait sans facture nouvelle, ce qui explique qu’il soit passé inaperçu chez beaucoup de marchands. Il s’est joué ailleurs : dans des dates de fin de support publiées sur des blogs techniques que personne n’a l’obligation de lire.
La conséquence est un décalage systématique entre le moment où un socle cesse d’être protégé et le moment où son propriétaire l’apprend. Ce décalage se mesure en années. La seule parade est de traiter la date de fin de support de chaque brique comme une donnée de gestion, au même titre qu’une échéance de bail ou de contrat, et de la faire figurer là où on regarde. Une ligne dans un tableau, révisée une fois par an. C’est peu de chose, et cela aurait suffi.
Sources
Les dates citées dans cet article renvoient au document qui les a produites. Nous ne citons pas de source que nous n’avons pas lue.
- PrestaShop Project, PrestaShop 1.7.8 is now in the extended support phase, 5 janvier 2023. Fin de maintenance conditionnée à la sortie de la 9.0.0. Consulter
- PrestaShop Project, PrestaShop 9 is available, 10 juin 2025. Consulter
- PrestaShop Project, PrestaShop 8.2.x is now in the extended support phase, 4 juillet 2025. Consulter
- PrestaShop Project, PrestaShop 9.1 is available, 23 mars 2026. Thème par défaut, accessibilité, remises, expédition, PHP 8.1 à 8.5. Consulter
- PrestaShop Developer Documentation, System requirements 1.7, table de compatibilité PHP. Consulter
- PrestaShop Developer Documentation, System requirements 9. Consulter
- PrestaShop Marketplace Guidelines, Quality standards and Verified +, règles applicables au 1er janvier 2026. Consulter
- PHP, Supported Versions et End of Life, dates de fin de vie des branches 7.4 à 8.5. Consulter
- Commission européenne, Cyber Resilience Act, obligations de signalement applicables au 11 septembre 2026. Consulter
- VulnCheck, State of Exploitation, premier semestre 2026. Délai médian entre publication d’une faille et exploitation constatée, passé de 120 à 80 jours, sur 495 vulnérabilités nouvellement exploitées. Consulter
- VulnCheck, analyse de Patrick Garrity relayée par Infosecurity Magazine, premier semestre 2026. 14 vulnérabilités exploitées sur 1 061 attribuées à une découverte assistée par intelligence artificielle, et 1 sur les 126 failles publiées issues des 23 000 constats du programme d’Anthropic. Consulter
- Friends of Presta, portail des avis de sécurité des modules PrestaShop. Consulter
Questions fréquentes
Ma boutique fonctionne très bien, pourquoi changer maintenant ?
Une boutique vulnérable continue d’afficher ses produits, de prendre des commandes et d’encaisser normalement. Le bon fonctionnement n’est donc pas un indicateur de sécurité. L’indicateur pertinent est la date du dernier correctif disponible pour votre socle, et pour PrestaShop 1.7 elle est passée depuis le 10 juin 2025.
Peut-on passer directement de PrestaShop 1.7 à PrestaShop 9 ?
Non, le chemin est séquentiel : il faut passer par PrestaShop 8 avant d’atteindre PrestaShop 9. C’est important pour le budget, car cela représente deux marches et non une. En revanche cela ne double pas le travail, la partie coûteuse restant la reprise des modules et des surcharges, qui se traite une seule fois. Et PrestaShop 8 reste une étape, pas une destination.
Un pare-feu applicatif ou un hébergeur sécurisé suffisent-ils en attendant ?
Ils réduisent la surface exposée, ils ne referment pas une faille. Et ils ne répondent pas à l’exigence annuelle de la norme carte bancaire, qui porte sur le fait de recevoir encore des correctifs de son éditeur, pas sur les protections posées devant. C’est une mesure d’atténuation utile, jamais une réponse.
Dotsland peut-il m’accompagner ?
Oui, et le plus utile est de commencer par l’inventaire décrit dans cet article, qui se fait sans outil et sans nous. Si votre liste comporte des modules dont l’éditeur a disparu, ou si vous voulez arbitrer entre migration et refonte, parlons-en avec votre liste en main.