PrestaShop 9.2 : ce qui change vraiment pour votre boutique

Introduction

PrestaShop 9.2 est entré en feature freeze le 9 juillet 2026, et sa bêta 1 est sortie le 22 juillet 2026. Trois nouveautés portent cette version : un One Page Checkout natif, un système d'Extra Properties pour étendre les entités du cœur, et un assistant Ask AI dans le back-office. Aucune date de version stable n'a été annoncée à ce jour.

Sur le papier, c'est une belle liste. Le contexte mérite d'être posé, parce qu'on entend deux histoires contradictoires sur PrestaShop et que les deux sont vraies.

La plateforme perd des boutiques. 218 906 en ligne fin 2021, 151 810 au 14 août 2026, soit 31 % de moins en moins de cinq ans. En France, elle ne capte plus que 5,4 % des créations de nouvelles boutiques, quand Shopify en prend 48,8 %.

Et elle reste la première plateforme de France en chiffre d'affaires. Devant Shopify, devant WooCommerce, avec moins de boutiques que l'un comme l'autre.

Une boutique PrestaShop pèse en moyenne 1,6 fois une boutique Shopify et 4 fois une boutique WooCommerce. La lecture s'impose d'elle-même : PrestaShop perd les petites boutiques et garde les grandes. Le nombre baisse, le poids monte.

C'est dans ce paysage que sort la 9.2. Notre propre base compte 818 boutiques PrestaShop enregistrées depuis 2018, dont 280 actives sur les douze derniers mois, à rapprocher de ces 24 211 boutiques françaises. Nous ne prétendons pas décrire tout le marché, nous décrivons ce qui passe entre nos mains.

La plateforme a changé de mains en février 2026

Impossible de parler du rythme de la 9.2 sans ce fait, et il explique une bonne partie du regain dont on entend parler.

Le 18 février 2026, le groupe polonais cyber_Folks a finalisé le rachat de 100 % de PrestaShop pour environ 53,7 millions d'euros, accord signé le 11 décembre 2025. L'opération passe par une holding, cyber_Pixel, détenue à 79 % par cyber_Folks, qui réunit désormais PrestaShop avec Sylius et BitBag, deux acteurs du même écosystème PHP. Les dirigeants de Sylius et de BitBag sont entrés au conseil d'administration.

La logique annoncée est une gamme : Shoper pour les très petites structures, PrestaShop pour les PME, Sylius pour les projets composables et les grands comptes. Autrement dit, PrestaShop reste sur son segment historique au lieu de courir après le haut du marché.

Ce que le calendrier laisse voir

Les dates parlent. Le rachat se clôt le 18 février. La 9.1 sort en stable le 23 mars, un mois plus tard. Le gel de la 9.2 tombe le 9 juillet, sa bêta le 22 juillet. Surtout, le cycle s'est raccourci : 120 jours entre bêta et stable pour la 9.0, 75 jours pour la 9.1.

Corrélation n'est pas causalité, et une partie de ce travail était engagée avant le rachat. Reste que la cadence s'est accélérée au moment où la propriété changeait, et que deux versions majeures sont sorties en dix-huit mois après des années plus lentes.

Une ombre au tableau, à mentionner pour rester honnête : un plan de sauvegarde de l'emploi a été annoncé le 10 avril 2026, huit semaines après la clôture, sur un effectif d'environ 347 personnes. Ni le nombre de postes ni les équipes concernées n'ont été communiqués, et la procédure reste soumise à validation. Pour qui planifie une migration, c'est un facteur de risque sur les délais au même titre que le nombre de tickets ouverts.

Cet article fait trois choses. Il détaille ce que 9.2 apporte réellement, fonctionnalité par fonctionnalité. Il dit, pour chacune, ce qu'elle va coûter à une boutique en production, à partir de ce que nous voyons casser sur les tunnels de commande, les modules de paiement et les transporteurs. Et il confronte les annonces à l'état réel du dépôt GitHub : avancement du jalon, rythme des cycles précédents, et maturité du module de checkout, qui réserve une surprise.

Méthodologie — Les fonctionnalités décrites proviennent de l'annonce officielle de la bêta 1 du 22 juillet 2026 et des notes de feature freeze du 9 juillet 2026, publiées sur le blog des développeurs PrestaShop. Elles portent sur l'édition Classic. Les chiffres d'exploitation viennent de notre plateforme de support : 9 280 tickets clôturés ou en cours entre le 11 octobre 2018 et le 20 août 2026, dont 3 395 rattachés à une boutique PrestaShop identifiée. Notre base compte 818 boutiques PrestaShop enregistrées depuis l'origine, dont 697 nous ont confié au moins une demande et 280 sur les douze derniers mois : c'est ce dernier chiffre qui décrit le parc réellement actif. Les chiffres de marché viennent de trois sources distinctes : le rapport StoreLeads sur PrestaShop du 14 août 2026 pour le nombre mondial de boutiques et son évolution, le baromètre Friends of Presta du 26 mars 2026 pour la France, établi sur 125 512 sites e-commerce actifs et 110 661 entreprises identifiées au SIREN, et les communications publiques relatives au rachat. Les chiffres d'affaires moyens par boutique sont calculés par nos soins à partir du baromètre.

Où en est réellement PrestaShop 9.2

Le calendrier connu tient en trois dates. Le 9 juillet 2026, la branche 9.2.x est créée et le périmètre est gelé : plus aucune fonctionnalité n'entre. Le 22 juillet 2026, la bêta 1 est publiée en édition Classic, sous le nom de paquet prestashop_edition_classic_version_9.2.0-beta.1.zip. Ensuite, rien d'officiel.

Un détail de cette annonce mérite d'être lu deux fois : il n'existe aucun chemin de mise à jour depuis la bêta vers la RC ou la version stable. Une boutique installée sur la bêta est une impasse. Elle sert à tester, à remonter des anomalies, à préparer un module. Elle ne sert pas à démarrer un projet qu'on compte mettre en ligne.

Plus de cinquante contributeurs figurent sur cette bêta. C'est un bon signal sur la vitalité du projet, et un mauvais indicateur de maturité : une bêta à cinquante contributeurs est une bêta où beaucoup de code neuf se rencontre pour la première fois.

Feuille de route contre réalité : ce que dit le dépôt

Les annonces disent l'intention. Le dépôt GitHub dit l'état. Nous avons relevé les deux, au 21 août 2026, un mois jour pour jour après la bêta.

Ce que les cycles précédents permettent de prévoir

PrestaShop ne communique pas de date de sortie. En revanche, les deux cycles majeurs précédents sont datés au jour près par les publications du dépôt.

Au rythme de la 9.1, la stable tomberait début octobre 2026. Au rythme de la 9.0, plutôt mi-novembre. Ce sont des projections, pas des annonces, et elles supposent que le projet garde sa cadence.

Un repère utile : au trentième jour du cycle 9.1, la RC était encore à vingt-sept jours. La 9.2 n'est donc pas en retard, elle est à l'heure d'un calendrier que personne n'a publié.

L'état d'avancement, en chiffres du dépôt

• Le jalon 9.2.0 compte 211 tickets ouverts contre 459 clos, soit 69 % de traité. Un mois après une bêta, deux cent onze items restants dit qu'on n'est pas à la veille d'une RC.

• 209 pull requests ouvertes visent la branche 9.2.x. Sur les cent PR les plus récentes du dépôt, soixante-dix-huit la ciblent : c'est bien là que le travail se concentre.

• 98 commits ont atterri sur 9.2.x depuis la bêta, dont un le matin même de notre relevé. La branche est vivante, activement.

• Le jalon 9.3.0 est déjà ouvert, à 39 % (97 ouverts, 62 clos). Le projet travaille sur la version d'après avant d'avoir livré celle-ci, ce qui est normal, et bon à savoir quand on planifie.

Le One Page Checkout est en version 0.6

C'est la trouvaille qui devrait décider de votre calendrier, et elle n'apparaît dans aucune annonce.

Le module vit dans son propre dépôt, PrestaShop/ps_onepagecheckout, créé le 5 mars 2026. Sa dernière version publiée est la v0.6.5, du 27 juillet 2026, marquée préversion, comme les cinq précédentes. Aucune version 1.0 n'existe. Le dépôt porte 6 tickets ouverts et 15 pull requests en attente.

Le contenu de ces tickets vaut mieux que n'importe quel commentaire. Deux exemples, tels que déclarés :

#144, ouvert le 31 juillet 2026 : le transporteur sélectionné est perdu silencieusement après le nettoyage d'une adresse temporaire, et les options de paiement s'affichent de travers.

#149, ouvert le 19 août 2026 : cocher « utiliser cette adresse aussi pour la facture » remplace l'adresse enregistrée du client.

S'y ajoutent une pile de cases de consentement où les conditions sont acceptées deux fois (#102) et des identifiants HTML dupliqués entre la modale d'adresse et les formulaires en ligne (#94). Ce dernier point mérite l'attention des intégrateurs : un identifiant dupliqué casse l'accessibilité et tout script tiers qui s'y accroche.

Aucun de ces défauts n'est rédhibitoire pour un module de cet âge. Tous sont rédhibitoires sur un tunnel de commande en production. Un transporteur perdu en silence, ce sont des commandes perdues sans message d'erreur, donc sans réclamation, donc sans que vous le sachiez.

One Page Checkout natif : la nouveauté qui touchera le plus de monde

PrestaShop embarque enfin un tunnel de commande sur une seule page, en module natif de la distribution. La fonctionnalité avait été annoncée pour la 9.1, puis reportée. Elle est dans la bêta 9.2.

Le principe : plus d'étapes successives, plus de rechargement de page, et une expérience guest-first, c'est-à-dire orientée vers l'achat sans création de compte préalable. Les champs se mettent à jour dynamiquement au fil de la saisie.

Pourquoi cette nouveauté est aussi celle qui casse le plus

C'est la partie que les annonces passent vite. Le tunnel de commande est l'endroit du site où le plus de code tiers se rejoint : modules de paiement, modules de transport, calcul de frais de port, points relais, codes promo, TVA, cadeaux, assurances. Chacun a été écrit contre un tunnel en plusieurs étapes, avec des rechargements de page à des moments précis.

Nos chiffres donnent une idée du terrain concerné. Sur les tickets où PrestaShop est mentionné, 839 portent sur le tunnel, le panier ou la commande, 357 sur un moyen de paiement et 211 sur un transporteur ou la livraison. Ce sont les trois familles que le One Page Checkout traverse de part en part.

PrestaShop publie une documentation dédiée aux développeurs de modules de paiement et de livraison, ainsi qu'aux auteurs de thèmes. C'est nécessaire, et ça dit l'essentiel : un module de paiement non adapté ne fonctionnera pas correctement dans ce nouveau tunnel. La question à poser à vos prestataires n'est pas « êtes-vous compatible 9.2 », elle est « avez-vous adapté votre module au One Page Checkout ».

Ce que ça implique concrètement pour votre boutique

Le nouveau tunnel arrive en module. Vous gardez donc le choix de rester sur le tunnel historique. C'est la seule bonne nouvelle de cette section, et elle est importante : la bascule sera une décision, pas une conséquence de la mise à jour.

Si vous voulez l'activer, la séquence raisonnable ressemble à ceci. Inventorier les modules qui interviennent dans le tunnel, y compris ceux dont vous avez oublié l'existence. Demander à chaque éditeur son état de compatibilité, par écrit. Tester sur une copie, avec de vraies commandes en environnement de test chez chaque prestataire de paiement. Puis mesurer : un tunnel monopage n'augmente pas mécaniquement le taux de conversion, il change la façon dont les abandons se produisent.

Nous avons installé la bêta. Voici ce que la lecture des annonces ne dit pas

Tout ce qui précède vient de sources publiques. Cette section vient d'une machine. Nous avons monté la bêta 9.2 le 21 août 2026, à partir de l'image officielle prestashop/prestashop:9.2.0-6.0-beta.1-classic-8.5-apache, sur PHP 8.5.0, la version que la documentation recommande, avec MySQL 8.0.46. La boutique installée déclare bien PS_INSTALL_VERSION = 9.2.0.

Il a fallu quatre tentatives pour l'installer

Aucune n'a échoué pour la même raison, et les trois premières sont reproductibles par quiconque teste la bêta dans Docker, c'est-à-dire à peu près tout le monde.

1. Renommer le dossier d'administration casse l'installation. C'est pourtant la première mesure de sécurité que prend un intégrateur sérieux. Le programme d'installation s'arrête sur The target directory "/var/www/html/admin-dev" does not exist. En cause, Install::finalize() : la variable part avec la valeur codée en dur admin-dev, et n'est remplacée que si un dossier nommé /admin/ existe encore. Quand il a déjà été renommé, l'installateur va chercher un dossier qui n'a jamais existé. Le même code figure dans la 9.0 : ce n'est pas une régression de la 9.2, c'est un comportement installé dans la durée.

2. Sans volume, le renommage automatique échoue. Avec le dossier par défaut, l'installateur tente de le renommer aléatoirement, ce qui est une bonne pratique. L'opération rend Invalid cross-device link. La raison est technique et vaut d'être connue : overlayfs, le système de fichiers de Docker, ne sait pas renommer un dossier hérité d'une couche inférieure de l'image. Le remède est de monter la racine web sur un volume.

3. Une installation réussie tue quand même le conteneur. Le cœur journalise « Installation successful », supprime le dossier install/, puis l'entrypoint de l'image tente de le supprimer à son tour, échoue sur rm: cannot remove '/var/www/html/install/': No such file or directory et sort en erreur. Le conteneur s'arrête juste avant qu'Apache ne démarre.

4. Un simple redémarrage suffit ensuite. Seize secondes plus tard, la boutique répond en 0,23 s.

Rien de tout cela n'est dramatique sur un environnement de test. Tout cela coûte une demi-journée à qui découvre.

Ce que la bêta embarque réellement

81 modules sur le disque, 80 enregistrés en base. Les versions des nouveautés méritent d'être lues attentivement.

La version du One Page Checkout embarquée est la 0.6.2, alors que le dépôt du module publiait déjà la 0.6.5 le 27 juillet. La bêta transporte donc une build antérieure de sa propre fonctionnalité phare.

Bonne nouvelle en revanche, et vérifiable en base : PS_ONE_PAGE_CHECKOUT_ENABLED vaut 0. Le module est installé et actif, le tunnel monopage reste éteint. Personne ne basculera par accident en mettant à jour.

Le tunnel remet le pays du client sur États-Unis

Voici notre trouvaille principale, et elle n'est signalée nulle part.

Nous avons activé le tunnel monopage sur une boutique installée en français, pays par défaut France, puis rempli un panier en visiteur non identifié. Le serveur envoie un formulaire correct : les quatre sélecteurs de pays de la page portent bien France en valeur sélectionnée. Après exécution du JavaScript, le champ visible affiche États-Unis.

Mesure — HTML servi par le serveur : France sélectionné. DOM relevé après exécution des scripts : États-Unis sélectionné. Reproduit deux fois, avec un profil de navigateur et un panier neufs à chaque fois. Module ps_onepagecheckout 0.6.2, PrestaShop 9.2.0 bêta, PHP 8.5.

Sur une boutique française, cela change la TVA appliquée, les transporteurs proposés et les frais de port calculés. Le client qui ne regarde pas ce champ se voit proposer une livraison qui n'est pas la sienne. Le marchand qui teste vite fait ne le verra pas non plus, parce que le HTML, lui, est juste.

C'est exactement le type d'anomalie qu'aucune lecture de notes de version ne révèle, et que seule une exécution réelle attrape.

Les identifiants dupliqués, mesurés

Le dépôt du module signale des identifiants HTML en double entre la modale d'adresse et les formulaires en ligne. Nous avons compté sur une installation d'origine : 24 identifiants dupliqués dans la page de commande, dont field-alias, field-firstname et field-lastname. La page rend quatre sélecteurs de pays là où le client en voit un.

Pour un intégrateur, c'est une information opérationnelle : tout script tiers qui vise ces éléments par leur identifiant, ce que font beaucoup de modules de points relais et d'autocomplétion d'adresse, touchera le mauvais champ.

Le bloc de consentement, tel qu'il s'affiche

Avant même de saisir une adresse, le visiteur non identifié rencontre trois cases à cocher et un paragraphe juridique : offres des partenaires, conditions générales et politique de confidentialité, message sur la confidentialité des données, inscription à la lettre d'information. Le tout occupe le premier écran, au-dessus du formulaire d'adresse. Sur une installation française, ce paragraphe s'affiche encore en anglais, comme les mentions de réassurance de la colonne de droite.

Ask AI démarre tout seul, et s'adosse au compte PrestaShop

Le serveur MCP est actif dès l'installation : PS_MCP_SERVER_STARTED vaut 1. Deux modules le composent, ps_mcp_server pour le protocole et ps_mcp_tools pour les outils exposés. La configuration révèle un rattachement à PrestaShop Accounts et à CloudSync, ainsi qu'un réglage de suivi anonyme et une clé PS_MCP_SERVER_AUTH_DISABLED, laissée vide par défaut.

Deux points à retenir pour qui gère des données clients. L'assistant ne fonctionne qu'une fois un fournisseur configuré, donc rien ne part avant cette décision. Et l'existence d'un interrupteur capable de désactiver l'authentification du serveur MCP mérite d'être vérifiée avant toute mise en production, au même titre qu'on vérifie qu'un mode debug est éteint.

Extra Properties : le vrai changement structurel pour les développeurs

C'est la fonctionnalité la moins spectaculaire de la liste, et probablement la plus importante à cinq ans. Elle vient d'une collaboration entre Kiwik et PrestaShop SA.

Le problème qu'elle règle est vieux comme la plateforme. Ajouter un champ personnalisé sur un produit, un client ou une commande imposait jusqu'ici de créer sa propre table, d'écrire ses propres requêtes, de gérer soi-même le multiboutique et le multilingue, de brancher des hooks pour l'affichage en back-office, et de tout refaire à chaque montée de version. Chaque module maison réinventait la même plomberie, avec ses propres bugs.

Extra Properties fournit ce mécanisme nativement. Les entités du cœur (produit, déclinaison, client, commande, entre autres) acceptent des propriétés supplémentaires sans création de table, avec le multiboutique et le multilingue pris en charge, et une exposition dans les trois surfaces qui comptent : le back-office, l'Admin API et le front.

Pourquoi ça compte même si vous n'écrivez pas de code

Un champ personnalisé mal implémenté est une dette invisible. Il ne se voit pas tant que tout va bien, et il se rappelle à vous au moment de la migration : la table maison n'est pas migrée, les données restent, mais plus rien ne les lit. Nous ne comptons que 5 tickets qui mentionnent explicitement un champ personnalisé, et ce chiffre trompe. Ces champs ne cassent presque jamais tout seuls, ils cassent à l'occasion d'autre chose, et le ticket porte alors le nom de l'autre chose.

La conséquence pratique : sur un nouveau développement spécifique, exigez Extra Properties plutôt qu'une table maison. Sur l'existant, la question de la reprise se posera, et elle n'a rien d'automatique.

Ask AI : un assistant dans le back-office, adossé à un serveur MCP

PrestaShop 9.2 introduit un panneau conversationnel directement dans l'administration. Il repose sur le PrestaShop MCP Server, une implémentation du Model Context Protocol, et fonctionne avec plusieurs fournisseurs de modèles : ChatGPT, Claude, Gemini, et les autres compatibles. Il est inclus dans l'édition Classic.

Le point de conception qui rassure : l'assistant demande une approbation avant d'agir sur la boutique. Il propose, vous validez. C'est la bonne façon de faire, et c'est aussi la seule acceptable sur un système qui tient un catalogue, des commandes et des données clients.

Deux choses distinctes qu'on confond souvent

Ask AI s'adresse aux marchands, dans le back-office. À côté, PrestaShop fournit aussi de quoi outiller le développement assisté : un dossier .ai/ versionné dans le dépôt, un fichier CONTEXT.md qui décrit l'architecture et les conventions du projet, et des fichiers de redirection (CLAUDE.md, AGENTS.md, .cursorrules) qui pointent vers lui pour que chaque outil trouve le même contexte.

Ces fichiers sont du texte dans Git. Aucun modèle n'est embarqué dans PrestaShop, aucune donnée de boutique ne part vers un fournisseur du seul fait de leur présence. Le développeur reste libre de son outil.

La limite est celle de tous les assistants : le code produit reste à relire. Sur PrestaShop, deux points concentrent les erreurs, le multiboutique et les hooks. Un modèle génère volontiers du code qui fonctionne sur une boutique unique et se trompe silencieusement dès qu'il y en a deux.

Les pages Symfony qui se stabilisent

La migration du back-office de l'ancien socle vers Symfony continue, page par page, depuis plusieurs versions. En 9.2, six écrans passent en stable : Pays, Retours produits, Greffer un module, Accès rapide, Traductions du corps des e-mails et Règles fiscales.

« Stable » a ici un sens précis : ces pages restent accessibles derrière les feature flags de la section « Fonctionnalités nouvelles et expérimentales ». Elles ne s'imposent pas d'office.

L'intérêt pour un marchand est indirect et réel. Chaque écran migré est un écran qui cesse de dépendre de l'ancien code, donc un écran de moins à casser lors de la prochaine montée de version. L'intérêt pour un développeur est immédiat : un module qui greffe du contenu sur l'une de ces pages doit vérifier son comportement dans les deux modes, ancien et nouveau.

Expéditions multiples : le chantier discret

Presque aucun article ne le mentionne, et c'est pourtant la partie la plus travaillée de cette version côté commandes. La gestion des expéditions gagne un vrai mode multi-expéditions : création d'une expédition sur une commande existante, gestion par fenêtre modale, suppression douce, intégration aux factures, et prise en compte de la suppression de produits.

Pour toute boutique qui expédie en plusieurs fois, sur stock partiel ou depuis plusieurs entrepôts, c'est plus utile au quotidien qu'un assistant conversationnel. Nos 211 tickets livraison comportent leur part de commandes coupées en deux et de factures qui ne suivaient pas.

Klaviyo de retour dans la distribution Classic

PrestaShop Automation avec Klaviyo réintègre nativement l'édition Classic : e-mail, SMS, campagnes automatisées et segmentation d'audience sur les données de la boutique. À évaluer comme un module marketing, avec la question habituelle des données transmises à un tiers et de la base légale associée.

Le socle technique exigé

PrestaShop 9 repose sur Symfony 6.4 LTS. Voici les prérequis officiels, tels que publiés dans la documentation développeur.

Deux lignes de ce tableau causent l'essentiel des blocages que nous voyons.

La borne haute de PHP se lit aussi mal que la borne basse. Un hébergeur qui vient de basculer d'office ses serveurs en PHP 8.6 met la boutique hors des versions prises en charge, exactement comme un hébergeur resté en 7.4. Le problème n'est pas d'être vieux, il est d'être hors de la fenêtre.

allow_url_fopen est le genre de réglage désactivé par un hébergeur au nom de la sécurité, sans prévenir. La boutique fonctionne, le catalogue s'affiche, et seuls les paiements échouent. C'est un cas que nous voyons revenir régulièrement dans nos tickets de paiement, et il ne se diagnostique pas depuis le back-office.

Ce socle est la vraie porte d'entrée. Une boutique en PHP 7.4 chez un mutualisé ne se met pas à jour vers PrestaShop 9, elle change d'abord d'environnement. Dans nos tickets, c'est régulièrement à cette étape que le projet s'arrête, et pas au moment de la migration elle-même.

Faut-il migrer maintenant ?

Non, et il faut s'y préparer maintenant. Les deux affirmations tiennent ensemble.

Non, parce qu'aucune version stable n'est annoncée, parce que la bêta n'offre aucun chemin de mise à jour vers la suite, et parce que le module de checkout lui-même est en version 0.6 avec des anomalies ouvertes sur le transporteur et l'adresse de facturation. Une boutique qui vend n'a rien à gagner à être la première.

Préparez-vous, parce que le retard se paie. Le pic de nos demandes de migration PrestaShop date de 2022, avec 111 tickets. En 2026, nous en sommes à 36. La baisse ne signifie pas que le parc est à jour, elle signifie que beaucoup de boutiques ont cessé de bouger. Et une boutique qui saute deux versions majeures ne fait pas une migration, elle fait une refonte.

La séquence que nous recommandons

1. Vérifiez votre version PHP et votre base aujourd'hui. C'est gratuit, ça prend cinq minutes, et c'est ce qui détermine si le sujet est une mise à jour ou un déménagement.

2. Faites l'inventaire des modules du tunnel. Paiement, transport, points relais, promotions, TVA. Notez l'éditeur, la version installée et la date de dernière mise à jour. Les modules abandonnés se repèrent à ce moment-là, pas le jour de la bascule.

3. Interrogez les éditeurs par écrit sur la compatibilité 9.2 et, séparément, sur l'adaptation au One Page Checkout. Ce sont deux questions différentes.

4. Recensez vos champs personnalisés et vos tables maison. C'est le poste qui surprend le plus lors des migrations, parce que personne ne se souvient de les avoir créés.

5. Montez une copie de test dès la RC, pas avant. La bêta ne se met pas à jour.

6. Attendez une version corrective avant de passer la production. Les .1 et .2 existent pour une raison.

Questions fréquentes sur PrestaShop 9.2

Quand PrestaShop 9.2 sort-il en version stable ?

Aucune date n'est annoncée. La bêta 1 date du 22 juillet 2026 et le gel des fonctionnalités du 9 juillet 2026. Les deux cycles précédents donnent un ordre de grandeur : 75 jours entre bêta et stable pour la 9.1, 120 jours pour la 9.0. Reporté sur la 9.2, cela place la stable entre début octobre et mi-novembre 2026. Au 21 août, aucune release candidate n'est publiée et le jalon 9.2.0 reste à 69 % de traité.

Peut-on mettre à jour une boutique de 9.1 vers 9.2 ?

Pas aujourd'hui, puisque la 9.2 n'existe qu'en bêta. Et surtout, une installation faite sur la bêta ne pourra pas être mise à jour vers la RC ni vers la stable : c'est écrit dans l'annonce officielle. Une bêta se teste sur une copie jetable.

Le One Page Checkout va-t-il s'activer tout seul ?

Non. Il arrive sous forme de module. Le tunnel en plusieurs étapes reste disponible, et la bascule est une décision que vous prenez, module de paiement par module de paiement.

Mes modules PrestaShop 8 fonctionneront-ils en 9.2 ?

Ce sont deux questions distinctes, et il faut poser les deux à chaque éditeur. La compatibilité avec PrestaShop 9 relève de l'adaptation à Symfony 6.4 et aux API du cœur. L'adaptation au One Page Checkout est un travail supplémentaire, spécifique, qui ne concerne que les modules intervenant dans le tunnel. Un module peut très bien être compatible 9.2 et inutilisable dans le nouveau checkout.

Ask AI envoie-t-il mes données à OpenAI ou à Anthropic ?

Ask AI fonctionne avec le fournisseur que vous configurez, donc les échanges partent chez celui que vous avez choisi. C'est une décision à documenter dans votre registre de traitements, au même titre que n'importe quel sous-traitant. À distinguer du dossier .ai/ destiné aux développeurs, qui n'est que du texte versionné dans Git et n'émet rien par lui-même.

Faut-il passer par la 9.0 et la 9.1 avant la 9.2 ?

La question se pose surtout pour les boutiques en 1.7 ou en 8. Le saut de version se prépare par paliers, avec un test à chaque étape, parce que c'est à ces moments que les modules abandonnés se révèlent. Une boutique en 1.6 relève d'un projet de refonte plutôt que d'une mise à jour.

Extra Properties remplace-t-il mes champs personnalisés existants ?

Il offre la bonne façon de les créer désormais. La reprise de l'existant, qu'il s'agisse de tables maison ou de modules de champs personnalisés, n'a rien d'automatique et se traite au cas par cas.

Ce qu'il faut retenir

PrestaShop 9.2 est une version d'infrastructure déguisée en version de fonctionnalités. Le One Page Checkout fera parler, Extra Properties changera durablement la façon d'écrire du spécifique, et les migrations Symfony réduisent la dette version après version.

Le calendrier reste ouvert. La bêta du 22 juillet 2026 est une invitation à tester, pas à déployer. D'ici la stable, le travail utile porte sur votre socle serveur et sur l'inventaire de vos modules de tunnel, deux chantiers qui ne dépendent d'aucune date de sortie.

Si votre boutique tourne encore en 1.6 ou en 1.7, la question n'est plus de savoir quand passer en 9.2. Elle est de savoir combien de temps vous tiendrez sur une base que l'éditeur ne corrige plus.

Migrer prend des semaines, parfois des mois quand les modules du tunnel ne suivent pas. En attendant, une boutique sur une version sans correctif reste exposée aux failles connues, celles dont le code d'exploitation circule. C'est le trou que comble le correctif virtuel : plutôt que de modifier un cœur qui ne recevra plus de mise à jour, on bloque l'exploitation au niveau du pare-feu applicatif et on applique des correctifs maison sur les vulnérabilités publiées. Notre module PrestaSecure couvre PrestaShop 1.6 à 9 pour cette raison précise : le parc réel n'est pas à jour, et il faut bien le protéger tel qu'il est.

Ce n'est pas une alternative à la migration. C'est ce qui permet de la préparer sans la faire dans l'urgence, après un incident.