Comment tester PrestaShop 9.2 RC1 dans un environnement de préproduction isolé

Un environnement de version candidate doit être suffisamment réaliste pour révéler les incompatibilités et suffisamment isolé pour qu’une erreur ne puisse pas devenir une vraie commande, une expédition ou une campagne. Copier une base de données de production vers un autre nom d’hôte ne suffit pas à assurer cette isolation.

L’annonce de RC1 demande aux testeurs d’utiliser une nouvelle installation et indique qu’Update Assistant ne propose pas de mise à niveau de bêta vers RC1 ni de RC1 vers la version finale. Au 26 septembre 2026, il s’agit d’une évaluation de préversion, et non d’une répétition de mise à niveau de production avec une suite garantie. Instructions officielles de test de RC1.

La procédure ci-dessous construit un environnement jetable et une piste de preuves. Elle n’explique pas comment migrer une boutique de la version 8 à la version 9.

Pour chaque dépendance introduite en préproduction, demandez des preuves de compatibilité du module avec PrestaShop 9.2 au lieu de vous fier uniquement à une version maximale déclarée.

Isoler les effets de bord avant d’introduire les données de la boutique

Listez tous les systèmes que la boutique peut contacter : envoi d’e-mails, prestataires de paiement, services d’expédition, plateformes marketing, services de recherche, analytique, connexions ERP et intégrations planifiées. Incluez les rappels et les processus d’arrière-plan, pas uniquement les paramètres visibles des modules.

Créez des identifiants distincts ou des configurations de bac à sable documentées lorsqu’elles existent. Redirigez les e-mails vers un réceptacle de test. Empêchez les opérations d’expédition et de marketing d’atteindre de vrais destinataires. Si une intégration ne dispose pas d’un bac à sable sûr, désactivez ses effets externes et documentez les comportements qui ne peuvent pas être testés.

Utilisez le contrôle d’accès pour garder l’environnement privé. Les seules directives destinées aux moteurs de recherche ne limitent pas l’accès et ne protègent pas les données clients. Limitez les personnes qui peuvent accéder à la boutique de test et celles qui peuvent l’administrer.

Vérifiez également les événements entrants. Une URL de rappel copiée ou un compte fournisseur partagé avec la production peut amener un environnement à consommer les événements destinés à un autre. Donnez une identité claire à chaque environnement et vérifiez la configuration du fournisseur avant d’activer une intégration.

Si vous utilisez ultérieurement des données issues de la production, réduisez-les au minimum et anonymisez-les selon votre processus approuvé. Un catalogue réaliste nécessite rarement de vrais e-mails clients, adresses ou identifiants. Préservez la cohérence relationnelle pour que l’anonymisation ne crée pas d’échecs artificiels.

Prouver que les éléments de récupération sont utilisables

Les sauvegardes restent pertinentes même si la version candidate part d’une installation neuve. Préservez les éléments de récupération de la boutique stable selon son processus d’exploitation normal et capturez séparément la base de référence de la candidate pour pouvoir réinitialiser les tests.

Une capture utilisable associe la base de données aux fichiers et à la configuration correspondants. Les versions des modules, les références des médias et l’état de la base de données peuvent devenir incohérents s’ils sont capturés à des moments sans rapport. Consignez ce que contient la capture et comment elle a été produite.

Restaurez la base de référence de la candidate dans une autre instance jetable ou un point de réinitialisation avant de vous y fier. Vérifiez que l’interface d’administration s’ouvre, que les produits de test existent et que les effets externes restent isolés. L’existence d’un fichier de sauvegarde ne prouve pas qu’il peut être restauré correctement.

N’utilisez pas l’installation candidate pour écraser une base de données de production afin d’« essayer le schéma ». Gardez les identifiants et les chemins de la base de l’expérience suffisamment distincts pour faciliter la détection des erreurs courantes des opérateurs.

Rédigez la procédure de réinitialisation avant les tests destructifs. Une réinitialisation prévisible rend les preuves ultérieures reproductibles et évite que les données du test précédent contaminent progressivement tous les tests.

Établir une base de référence RC1 propre

Utilisez l’artefact de publication officiel adapté à la distribution que vous souhaitez évaluer. Consignez l’artefact téléchargé, la version et toute vérification disponible de la somme de contrôle. Distinguez un paquet d’installation d’une copie des sources qui nécessite son propre processus de compilation.

Installez dans une nouvelle base de données. Consignez les versions de l’environnement d’exécution et de la base de données sans transformer l’évaluation en exercice générique d’hébergement. L’objectif est de savoir ce qui a été testé et de le comparer à l’environnement pris en charge prévu.

Avant d’ajouter des personnalisations, effectuez une courte vérification de base : connexion au Back Office, affichage d’un produit, création d’un panier et commande simple en bac à sable si la configuration de paiement installée le permet. Enregistrez la capture obtenue et l’inventaire des versions.

Consignez explicitement les indicateurs de fonctionnalités. Leur état par défaut fait partie de l’environnement de test. Si un cas ultérieur active une page migrée ou une autre fonctionnalité expérimentale, le rapport doit l’indiquer plutôt que d’attribuer tout le comportement à la seule version du cœur.

Ne présumez jamais que l’installation réussie de la candidate crée un chemin de mise à niveau vers la version finale. Traitez sa base comme des données de test jetables, sauf si des instructions officielles ultérieures établissent explicitement un autre processus pris en charge.

Introduire les dépendances par groupes contrôlés

Ajoutez le thème et les modules en fonction des processus qu’ils affectent. Une séquence utile est la présentation de la boutique, les dépendances du passage de commande, les extensions du Back Office puis les intégrations d’arrière-plan. Cela facilite l’attribution d’un nouvel échec.

Tenez un registre des dépendances :

Si un composant n’a pas de déclaration de prise en charge de la version 9.2, signalez cette incertitude. Vous pouvez tout de même l’étudier en préproduction, mais l’absence d’échec dans un test court ne constitue pas un engagement de prise en charge de son mainteneur.

Les surcharges personnalisées méritent une attention particulière. Consignez ce qu’elles modifient et pourquoi. Une personnalisation qui ne s’active plus peut supprimer silencieusement une règle métier tout en laissant la page fonctionnelle.

Couvrir le cycle de vie de la boutique au-delà du passage de commande

Le passage de commande est critique, mais ne représente pas toute la boutique. Une candidate peut accepter une commande et échouer lors d’un import, d’une modification administrative ou d’un rapprochement planifié.

Pour les opérations de catalogue, créez et modifiez des produits, des déclinaisons et du contenu traduit pertinents pour la boutique. Utilisez des contraintes représentatives et des valeurs inhabituelles mais valides. Pour les imports, testez un petit lot, un échec de validation et un redémarrage plutôt que de charger immédiatement tout le catalogue.

Pour les tâches planifiées, confirmez le contexte de boutique prévu et assurez-vous que les agents de test ne peuvent pas appeler les services de production. Exécutez une tâche deux fois si le doublon constitue un risque significatif. Observez si la seconde exécution reconnaît correctement le travail déjà terminé.

Pour les API, conservez des exemples de schémas et de réponses pour les opérations réellement consommées par vos clients. Ne présumez pas que tous les points d’accès sont installés simplement parce que la version du cœur est nouvelle. Consignez les versions des modules de ressources avec celle du cœur.

Pour le multiboutique, utilisez des valeurs de test distinctes dans au moins deux boutiques et examinez les deux après une écriture. Pour les routes et le contenu traduits, testez les langues réellement publiées par l’entreprise. Incluez une langue employé autre que celle par défaut lorsque les extensions du Back Office utilisent des libellés ou des messages traduits.

Terminez par les opérations après commande : génération de documents, changements de statut, gestion des expéditions et transfert vers les intégrations externes. Chaque cas doit avoir un résultat métier attendu, et pas seulement un écran attendu.

Signaler les régressions pour permettre leur reproduction

Un rapport utile contient un jeu de test minimal, les versions exactes, les indicateurs actifs, la séquence d’actions, le résultat attendu et le résultat réel. Joignez des journaux expurgés ou des captures d’écran uniquement lorsqu’ils éclairent le problème.

Essayez de reproduire l’échec depuis la base de référence propre avec le plus petit ensemble de dépendances nécessaire. Cela ne signifie pas retirer le module concerné s’il est essentiel au problème. Cela signifie supprimer la configuration sans rapport qui masque le déclencheur.

Distinguez une régression d’une hypothèse non prise en charge. Si une intégration privée repose sur un sélecteur non documenté, le rapport doit préciser cette dépendance. Si une opération documentée renvoie un résultat incorrect sur une installation propre, montrez-le directement.

Gardez les informations sensibles pour la sécurité hors des rapports publics. Un exemple synthétique minimal est souvent plus utile qu’un extrait de base de données de production. Pour les problèmes de sécurité, suivez le canal de signalement approprié du projet plutôt que de publier des détails d’exploitation dans un rapport ordinaire de compatibilité.

Conserver une fiche des données de test

Pour chaque ensemble de données de test importé, consignez son origine, sa date de préparation et son objectif. Notez quelles données ont été synthétisées, quelles relations ont été préservées et quels identifiants externes ont été remplacés. Cela aide à expliquer les échecs dus à un jeu de test irréaliste plutôt qu’à la candidate.

Un catalogue où tous les produits sont en stock ne peut pas tester le comportement des articles indisponibles. Un ensemble de clients d’un seul pays ne peut pas révéler les règles de livraison dépendant de la destination. Une copie multiboutique contenant uniquement des valeurs partagées ne peut pas établir l’isolation. Choisissez délibérément des différences représentatives au lieu de copier du volume pour lui-même.

Conservez la fiche du jeu de test à côté de l’inventaire de l’environnement. Lorsqu’un testeur reconstruit ultérieurement l’environnement, il doit pouvoir recréer les conditions importantes sans recevoir une base de données de production. Cela facilite également la réduction des rapports de bogues en amont à un exemple minimal sûr.

Si un jeu de test change pendant l’enquête, donnez un nouvel identifiant à l’ensemble révisé. Sinon, deux rapports prétendant utiliser la même base de référence peuvent contenir des conditions initiales différentes et produire des comparaisons trompeuses.

Clore l’évaluation de manière réfléchie

Le résultat doit indiquer ce qui a réussi, ce qui a échoué, ce qui n’a pas été testé et ce qui reste non pris en charge. Attribuez à chaque problème bloquant un responsable et une référence de reproduction.

Avant de mettre fin à l’environnement, préservez les preuves nécessaires aux nouveaux tests. Exportez les définitions des jeux de test, l’inventaire des versions et les résultats expurgés. Révoquez les identifiants d’intégration temporaires et désactivez l’activité planifiée afin qu’une installation de test abandonnée ne continue pas à contacter des services externes.

Lorsqu’une candidate ultérieure ou une version stable arrive, créez une nouvelle base d’évaluation selon ses instructions officielles et rejouez les cas affectés par les changements. Ne reconduisez pas silencieusement un résultat positif provenant d’une configuration différente de modules ou d’indicateurs.

La valeur des tests RC est d’obtenir tôt des connaissances reproductibles. Une installation soigneusement isolée peut révéler précisément ce qui nécessite du travail tout en gardant la boutique de production et ses clients hors de l’expérience.

Pour le contexte de la plateforme sous-jacente, consultez notre guide de mise à niveau sécurisée de PrestaShop 8 vers 9 et appliquez les vérifications propres à chaque version ci-dessus à l’installation que vous évaluez.