PrestaShop 9.2 : les nouveautés de la version RC1

PrestaShop 9.2 offre aux marchands et aux développeurs plusieurs nouveautés à évaluer : un parcours d'achat natif sur une seule page, un système commun de champs supplémentaires pour les entités et un assistant IA dans l'interface d'administration. La question utile est de déterminer lesquels de ces changements touchent les tâches réellement effectuées par votre boutique.

Au 26 septembre 2026, le jalon disponible est 9.2.0-rc.1, publié le 21 septembre. Il s'agit toujours d'une préversion destinée à des tests isolés. Une version candidate n'est pas une recommandation de remplacer une installation de production opérationnelle. Annonce officielle de la RC1.

Cet article relie les nouveautés de la version 9.2 aux décisions métier. Pour les changements sous-jacents de la plateforme, commencez par notre présentation de PrestaShop 9. Les exemples pratiques ci-dessous sont des exercices d'évaluation proposés, et non des résultats observés.

Pour examiner plus en détail le parcours d'achat, consultez comment le One Page Checkout natif transforme l'achat avant de choisir vos scénarios d'acceptation du checkout.

Lire la version à trois niveaux différents

Un numéro de version ne décrit pas à lui seul tout ce qui est installé dans une boutique. Distinguez la version du cœur, les modules inclus et les fonctionnalités activées. Un marchand qui teste un package de distribution peut rencontrer des services absents d'une compilation personnalisée du cœur. Un autre testeur peut avoir le même cœur, mais une révision différente du module de checkout ou une sélection différente d'options expérimentales.

Consignez ces différences avant de comparer des captures d'écran ou de signaler un problème. Une note d'évaluation utile identifie l'archive, la version du cœur, la version du thème, les versions des modules concernés et les indicateurs de fonctionnalités activés. Cela évite qu'une discussion sur le « comportement de la version 9.2 » mélange plusieurs installations différentes.

Distinguez également la maturité de la version de celle des fonctionnalités. Une page peut avoir sa propre qualification de maturité alors que le package qui la contient reste une version candidate. Inversement, une future version stable du cœur ne rendrait pas automatiquement toutes les expérimentations facultatives prêtes à devenir des dépendances de production.

Pour une agence, le résultat doit être une petite cartographie des tâches affectées : checkout client, enrichissement du catalogue, assistance administrative, extensions du Back Office et intégrations. Désignez un responsable pour chaque domaine. C'est plus utile que de demander à un développeur de « tester la nouvelle version » sans définir les critères de réussite.

L'ajout du checkout modifie une frontière d'intégration importante

Le nouveau One Page Checkout natif rassemble le processus d'achat sur une seule page. Son importance dépasse la mise en page : le projet propose une implémentation commune que les développeurs de paiements, de transporteurs et de thèmes peuvent prendre en charge. La présentation officielle en fait une orientation facultative du checkout, et non une preuve que toutes les boutiques amélioreront leur conversion. Présentation du One Page Checkout.

Pour un marchand, évaluez ce qui se passe lorsqu'un client modifie des informations après avoir déjà effectué d'autres choix. Un changement d'adresse peut affecter les modes de livraison, les taxes et le montant final. Un changement de transporteur peut affecter un sélecteur de point de retrait. Un choix de paiement peut introduire une redirection ou un formulaire intégré. Regrouper ces interactions rend leur coordination particulièrement visible.

Prenons une boutique vendant à la fois de petits accessoires et des articles volumineux. Une démonstration convaincante ne consiste pas simplement à acheter un accessoire avec le transporteur par défaut. Ajoutez l'article volumineux après avoir choisi la livraison, puis vérifiez que le transporteur sélectionné et les frais affichés sont recalculés de manière cohérente. La commande finale doit refléter le panier le plus récent, et non un état antérieur de l'écran.

Une boutique utilisant déjà un checkout tiers doit inventorier ses règles métier supplémentaires avant de prévoir un remplacement. La sélection de date de livraison, les champs d'entreprise et les préférences de retrait peuvent relever du module actuel ou de ses extensions. L'existence d'une alternative native ne garantit pas une couverture équivalente.

Transformez ces préoccupations en scénarios d'acceptation avant de vous engager dans un remplacement du checkout. Consignez les combinaisons de paiements, transporteurs et thèmes testées, y compris les règles fournies par une extension distincte.

Extra Properties crée un emplacement commun pour les champs supplémentaires

L'annonce du gel des fonctionnalités de la version 9.2 présente Extra Properties comme un système natif d'extension des entités, avec prise en charge des boutiques et des langues, et des connexions aux formulaires d'administration, aux grilles et à l'API. Annonce du gel des fonctionnalités de la version 9.2.

L'opportunité architecturale est la cohérence. Si un marchand a besoin d'une consigne de manutention propre à un produit, une agence peut évaluer un mécanisme d'extension partagé avant d'inventer une nouvelle convention privée de persistance. Cela peut clarifier la responsabilité et l'intégration, mais seulement si le champ lui-même est correctement modélisé.

Distinguez, par exemple, une consigne de manutention d'un historique d'événements d'entrepôt. La première est une valeur associée à une entité. Le second est une suite d'événements avec des horodatages, des acteurs et des relations. Un mécanisme pratique de champs personnalisés ne doit pas devenir un conteneur pour tous les enregistrements qui mentionnent un produit.

Il existe une distinction similaire entre un libellé traduit et des valeurs commerciales différentes. La traduction française d'une consigne et une consigne propre à une boutique sont deux dimensions distinctes. Déterminez quelle dimension varie réellement avant d'enregistrer un champ ; corriger un modèle ambigu après la saisie des données coûte plus cher que de choisir délibérément dès le départ.

Pour l'évaluation de la RC, commencez par un champ réversible et un petit jeu de données de test. Suivez sa valeur depuis la saisie jusqu'au rechargement et au consommateur prévu. Ne migrez pas tout le stockage d'un module de production simplement pour explorer la fonctionnalité. Les développeurs qui réalisent l'expérience peuvent utiliser notre guide de développement de modules PrestaShop 9 comme base pour la structure du module et sa préparation à la production.

Ask AI et les intégrations de distribution nécessitent leurs propres critères d'acceptation

L'annonce de la bêta décrit Ask AI dans le package Classic comme une interface conversationnelle du Back Office connectée au serveur MCP de PrestaShop. Elle présente également PrestaShop Automation avec Klaviyo comme une intégration de la distribution Classic. Ce sont des fonctionnalités de distribution dont la configuration et les dépendances externes méritent une évaluation distincte. Annonce de la bêta 9.2.

Pour Ask AI, commencez par une question dont le personnel peut vérifier la réponse de manière indépendante. « Afficher le nombre pour cette boutique nommée, cet intervalle de dates et cet ensemble de statuts de commande » est une meilleure évaluation qu'une demande ouverte d'amélioration de l'activité. Cela facilite la détection d'une portée incorrecte, de résultats incomplets ou d'une terminologie mal comprise.

Pour une action, définissez les enregistrements concernés et les valeurs attendues avant d'approuver quoi que ce soit. Un assistant qui interprète correctement une phrase a toujours besoin d'un chemin d'exécution approprié et d'autorisations suffisantes. Son message final doit être confronté à l'état modifié de la boutique.

Pour une intégration marketing, distinguez l'installation de la préparation du compte. Un connecteur inclus ne définit pas vos règles d'audience, le contenu des campagnes, la gestion des exclusions ou la configuration du compte. Utilisez une audience synthétique et un processus de test sans envoi lors de l'évaluation d'une version candidate. Vérifiez où les événements seraient envoyés avant d'activer la synchronisation sur une base de données copiée.

Ces vérifications sont des recommandations opérationnelles, et non l'affirmation qu'un fournisseur ou module particulier implémente tous les contrôles décrits ici. Considérez la documentation actuelle de chaque intégration et sa version installée comme le contrat.

Le travail sur le Back Office se poursuit au-delà des nouveautés phares

La version concerne aussi les personnes qui passent leurs journées à configurer et administrer des boutiques. Les notes de changements officielles pour développeurs décrivent une nouvelle série de migrations de pages vers Symfony, accessibles via des indicateurs de fonctionnalités. Elles documentent aussi le caractère expérimental des nouvelles interfaces Extra Properties. Changements de la version 9.2 pour les développeurs.

Une page migrée peut sembler familière tout en utilisant des points d'extension différents en profondeur. Cela concerne les agences qui personnalisent les formulaires, ajoutent des informations aux grilles ou modifient la navigation administrative. La bonne évaluation consiste à vérifier qu'une opération métier réussit toujours, et non qu'un bouton conserve la même apparence.

Prenons un formulaire d'administration personnalisé. Un champ peut s'afficher correctement sans être enregistré, ou être enregistré correctement tout en affichant le mauvais contexte boutique au rechargement. Capturez le cycle complet : valeur initiale, modification soumise, valeur enregistrée et formulaire rouvert. Incluez un compte employé disposant des autorisations normalement utilisées par le personnel.

N'activez pas toutes les expérimentations simultanément pour tenter ensuite de diagnostiquer les différences produites. Partez d'une référence explicite, modifiez une option pertinente à la fois et conservez assez d'éléments pour identifier le chemin actif. Notez l'état de l'option avec chaque résultat afin qu'un autre développeur puisse reproduire le même parcours d'administration.

Une première réunion d'évaluation pratique

Donnez à chaque responsable de workflow une question à résoudre avant la prochaine réunion. Le responsable du checkout identifie la dépendance de paiement ou de livraison la moins certaine. Le responsable du catalogue sélectionne un champ qui mérite d'être modélisé. L'administrateur nomme une question répétitive dont la réponse peut être vérifiée manuellement. Le développeur répertorie les pages personnalisées affectées par la version candidate.

Examinez ces réponses avant de planifier un vaste projet de tests. Si personne ne peut identifier un besoin actuel pour une fonctionnalité, laissez-la hors de l'expérimentation initiale. Cela relie l'examen de la version aux tâches que l'entreprise reconnaît et fournit une raison claire pour chaque investigation approfondie.

Choisir un parcours d'évaluation court pour votre boutique

Le meilleur premier essai dépend des contraintes de la boutique. Un checkout fortement personnalisé donne la priorité au comportement des paiements et des livraisons. Un module de catalogue doté de nombreux champs auxiliaires rend Extra Properties intéressant. Une agence qui maintient des extensions d'administration doit privilégier les contrats des pages migrées. Un marchand qui envisage Ask AI doit commencer par un petit ensemble de questions vérifiables et une action clairement délimitée.

Utilisez une fiche de décision simple :

Une expérience ratée reste utile si elle produit une incompatibilité reproductible et une prochaine action claire. Une démonstration réussie n'est utile que pour les combinaisons effectivement testées. Évitez de transformer l'un ou l'autre résultat en une affirmation universelle sur toutes les boutiques PrestaShop.

PrestaShop 9.2 mérite donc d'être évalué comme un ensemble de changements précis de workflows. Gardez visible son statut actuel de RC, sélectionnez les fonctionnalités qui résolvent un problème réel et documentez les éléments qui justifieraient l'étape suivante. Notre guide de mise à niveau sûre de PrestaShop présente les principes d'une mise à niveau maîtrisée ; gardez toute expérimentation de la RC 9.2 distincte d'une migration de production.

Questions fréquentes

Dois-je installer PrestaShop 9.2 RC1 sur ma boutique en production ?

Utilisez la version candidate dans un environnement de test isolé. Son objectif est de valider la prochaine version et d'identifier les régressions restantes. Gardez votre installation de production opérationnelle à part et désactivez l'encaissement réel des paiements, les messages aux clients et la synchronisation externe dans une copie de test de la boutique avant d'exécuter les scénarios d'évaluation.

Le One Page Checkout natif remplace-t-il automatiquement mon checkout actuel ?

Ne considérez pas la disponibilité d'un checkout natif comme un plan de remplacement. Identifiez d'abord les fonctions fournies par votre checkout actuel, les modules de paiement, les intégrations de livraison et le thème. Testez explicitement la configuration prévue, y compris les changements d'adresse, le recalcul de livraison et les parcours de retour du paiement. La disponibilité d'une fonctionnalité ne garantit pas à elle seule un comportement équivalent.

Quelle nouvelle fonctionnalité une agence doit-elle évaluer en premier ?

Commencez par la fonctionnalité qui recoupe la personnalisation la plus importante de la boutique. Il peut s'agir du comportement du checkout, de champs supplémentaires d'entités ou d'une page d'administration migrée. Choisissez une opération métier, notez son résultat attendu et reproduisez-la avec les autorisations employé, le contexte boutique et les paramètres de langue appropriés.

Conclusion : rendre l'examen de la version concret

Choisissez un workflow, désignez son responsable et définissez un résultat vérifiable de manière indépendante. Conservez l'archive et les versions des modules avec vos preuves de test, consignez les dépendances non résolues et décidez si les conclusions justifient un essai plus large. Cela transforme l'intérêt pour PrestaShop 9.2 en une évaluation pratique sans confondre une démonstration encourageante avec l'aptitude à la production.

Vous préparez votre prochaine extension ? Parcourez les modules PrestaShop 9 de PrestaSuite et vérifiez la compatibilité déclarée de chaque module avant de l'inclure dans un test de version candidate 9.2.