PrestaShop & maintenance

Boutique PrestaShop : tester la version 9.2 sans risquer vos commandes

PrestaShop 9.2 introduit un paiement sur une page, un assistant IA et de nouveaux points d'extension. Au 18 août 2026, la version publique disponible reste une bêta : elle se teste sur une copie isolée, jamais directement sur la boutique qui encaisse.

Une développeuse teste le paiement d'une boutique PrestaShop sur un environnement de démonstration

La bonne décision n'est pas d'ignorer PrestaShop 9.2 jusqu'à sa sortie finale, ni d'installer la bêta sur une boutique active. C'est de profiter de cette période pour découvrir les incompatibilités pendant qu'elles n'ont encore aucun effet sur les clients.

Ne pas installer en production

PrestaShop indique explicitement que la bêta peut contenir des problèmes et que son passage vers la version candidate ou finale ne sera pas proposé par le canal standard de l'assistant de mise à jour.

01 — Statut

PrestaShop 9.2 est encore une version de test

Le projet est entré en gel fonctionnel le 9 juillet 2026 : les nouvelles fonctionnalités ont laissé place à la stabilisation. La première bêta publique a été annoncée le 22 juillet.

Au 18 août, aucune annonce officielle de version stable n'est publiée sur le blog du projet. Une boutique professionnelle doit donc rester sur une branche stable et maintenue. La bêta sert à construire un plan de migration, inventorier les modules sensibles et signaler les régressions.

Une bêta n'est pas seulement une version « presque terminée ». Son schéma de base de données, ses dépendances ou ses interfaces peuvent encore changer. PrestaShop prévient aussi que l'Assistant de mise à jour standard ne proposera pas le passage de cette bêta vers une version candidate ou finale. La copie utilisée pour l'essai doit donc être considérée comme jetable : on documente les constats, puis on recommence la migration depuis une base propre quand le chemin officiel est disponible.

02 — Évolutions

Trois nouveautés qui justifient un test métier

01

One Page Checkout

Le nouveau module natif réunit le paiement sur une seule page. Il faut vérifier le thème, les transporteurs, les moyens de paiement et les modules qui modifient le tunnel.

02

Extra Properties

Les développeurs peuvent ajouter des champs aux produits, clients ou commandes avec une intégration plus native au multiboutique, aux langues et à l'API d'administration.

03

Ask AI

L'assistant du back-office peut interroger les données et déclencher des actions après approbation. Son accès, ses données et son fournisseur d'IA doivent être cadrés.

D'autres pages du back-office sont proposées derrière des options expérimentales. Ce mécanisme permet de les activer volontairement pendant les tests sans les imposer immédiatement à tous les marchands.

Le paiement sur une page mérite une attention particulière parce qu'il concentre davantage d'interactions au même endroit. Un module de livraison qui recharge un bloc, un moyen de paiement qui injecte un composant ou un thème qui surcharge l'ancien tunnel peut fonctionner isolément et échouer lorsqu'ils sont combinés. Il faut donc tester les combinaisons réellement utilisées, y compris sur mobile et avec une connexion lente.

Les Extra Properties intéressent surtout les boutiques possédant des développements spécifiques. Elles peuvent simplifier une personnalisation future, mais ne transforment pas automatiquement un ancien override en extension compatible. L'inventaire doit distinguer modules du catalogue officiel, code spécifique, surcharge du thème et connecteurs développés pour l'ERP ou le transporteur.

03 — Préproduction

Créer une copie qui ne peut pas agir sur le réel

  1. Cloner fichiers et base de données

    La copie doit représenter le thème, les modules, les overrides, les langues, les boutiques et un échantillon réaliste du catalogue.

  2. Protéger l'accès et l'indexation

    Authentification, interdiction d'indexation et URL distincte évitent que la préproduction soit visitée ou référencée.

  3. Neutraliser les sorties

    Bloquer les e-mails réels, les webhooks de production, les exports comptables, les expéditions et les paiements autres que les environnements sandbox.

  4. Documenter les versions

    Noter PHP, base de données, serveur, thème, modules et personnalisations pour pouvoir reproduire une anomalie.

Une copie visuelle ne suffit pas

Le risque se trouve souvent dans les traitements invisibles : décrément de stock, création de facture, remboursement, tâche planifiée, synchronisation ERP ou appel d'API.

Les données personnelles copiées en préproduction doivent aussi être limitées et protégées. Selon le test, il peut être préférable d'anonymiser les clients, de remplacer les adresses électroniques et de conserver seulement quelques commandes représentatives. L'environnement de test ne doit pas devenir une deuxième base client moins surveillée que la production.

04 — Recette

Rejouer les commandes qui font réellement vivre la boutique

Une recette utile part des cas métier, pas seulement de la page d'accueil. Préparez plusieurs profils : visiteur, client existant, professionnel, commande avec réduction, panier multi-taux de TVA, livraison particulière ou produit sans stock.

  • création de compte, connexion et récupération de mot de passe ;
  • recherche, filtres, déclinaisons, prix et promotions ;
  • adresse, transporteur, point relais et frais de port ;
  • paiement réussi, refusé, abandonné puis repris ;
  • création de commande, facture, e-mails et décrément de stock ;
  • remboursement, retour produit et synchronisations externes ;
  • administration du catalogue, des clients et des commandes.

Pour chaque cas, notez le résultat attendu avant le test. « Le paiement fonctionne » est trop vague : la commande doit recevoir le bon statut, le stock doit baisser une seule fois, la facture doit reprendre les bons montants et l'ERP ne doit recevoir qu'un événement. Une anomalie reproductible avec captures, journaux et identifiants est beaucoup plus rapide à corriger qu'une impression générale.

Reprise et maintenance PrestaShop

Besoin d'un développeur PrestaShop freelance pour préparer la migration ?

Je peux créer la préproduction, inventorier les modules, adapter les développements spécifiques et tester le tunnel de commande avant toute mise en ligne. Basé à Toulouse, j'interviens dans le Grand Sud et à distance en France.

  • Audit de version et des dépendances
  • Préproduction isolée
  • Tests du tunnel et des connecteurs
  • Plan de migration et de retour arrière

La migration en production ne sera proposée qu'après la publication d'une version stable et la validation des composants indispensables à votre boutique.

Échanger sur ma boutique PrestaShop

Consultez aussi mes offres de maintenance PrestaShop à Toulouse et de reprise de site e-commerce existant.

05 — Checklist

Avant d'envisager la migration finale

  • La version stable a été officiellement publiée.
  • Le thème et les modules critiques annoncent une compatibilité vérifiée.
  • La préproduction ne peut envoyer ni paiement ni message réel.
  • Les parcours de commande et de remboursement ont été rejoués.
  • Les synchronisations de stock, ERP et transporteur ont été contrôlées.
  • Une sauvegarde restaurable et un plan de retour arrière existent.

Votre boutique existe déjà ?

Reprendre un e-commerce fragile sans repartir de zéro

Découvrir l'accompagnement →
Appeler Parler de votre projet