Préparer un module commercial à la compatibilité avec PrestaShop 9.2

L’affirmation de compatibilité d’un module commercial est une promesse faite à un marchand concernant une combinaison de logiciels et de comportements. « S’installe sur PrestaShop 9.2 » est une affirmation bien plus limitée que « prend en charge le passage en caisse natif, les pages d’administration migrées et le fonctionnement multiboutique ».

Pour la version 9.2 RC1 disponible le 26 septembre 2026, les éditeurs doivent décrire précisément les tests de la version candidate. Une évaluation RC réussie ne justifie pas de déclarer prise en charge une version stable encore non publiée. Cet article explique comment qualifier un module commercial existant, et non comment en créer le squelette.

Si le module intervient dans le paiement ou la livraison, incluez le plan de QA du One Page Checkout dans la matrice de compatibilité au lieu de tester uniquement l’installation.

Définissez l’engagement de prise en charge avant de concevoir la matrice

Consignez les capacités réellement proposées par le module et les combinaisons que les clients sont censés utiliser. Un module de paiement possède des parcours critiques différents de ceux d’un module d’enrichissement du catalogue. Une extension limitée au Back Office n’a peut-être pas besoin d’une matrice complète de thèmes de boutique, contrairement à une extension du passage en caisse.

Distinguez la prise en charge obligatoire de la compatibilité facultative. Si le module ne prend aujourd’hui en charge qu’un parcours précis du passage en caisse, indiquez-le explicitement. Si le multiboutique n’est pas pris en charge, ne laissez pas l’installation dans une boutique multiboutique suggérer le contraire.

Répertoriez les dépendances exactes derrière l’engagement : cœur, environnement d’exécution, modules natifs, thème le cas échéant et version d’intégration du service externe. Gardez les dépendances expérimentales visibles au lieu de les fondre dans une large plage de versions.

Une formulation utile à ce stade est « testé avec 9.2.0-rc.1 selon ces combinaisons et limitations nommées ». Elle indique aux premiers testeurs les éléments disponibles sans laisser entendre que la version candidate est prête pour la production.

Construisez la matrice autour des risques plutôt que de toutes les permutations possibles

Commencez par les effets métier du module. Quelle opération peut modifier l’argent, le stock, les données client ou le périmètre de boutique ? Quels points d’extension ont changé dans la version candidate ? Quelles dépendances externes peuvent produire des résultats tardifs ou en double ?

Utilisez une matrice reliant chaque risque à des éléments de preuve :

Sélectionnez ensuite des combinaisons représentatives. Testez les versions minimale et maximale de l’environnement d’exécution que vous déclarez prendre en charge, avec les combinaisons de dépendances les plus susceptibles de révéler des différences. Ajoutez des cas ciblés lorsque le code varie selon la version de la plateforme.

Ne prétendez pas qu’une matrice par paires prouve toutes les combinaisons. C’est une stratégie de couverture dont les limites doivent rester documentées.

Traitez le passage en caisse et les pages migrées comme des surfaces d’intégration distinctes

Pour un module de passage en caisse, vérifiez à la fois le parcours d’achat pris en charge et les interactions de paiement ou de transporteur dont il dépend. Testez le rafraîchissement, le changement d’adresse, l’échec d’envoi et les initialisations répétées. Un module réagissant uniquement au chargement initial de la page peut se comporter différemment dans le parcours natif sur une page.

Pour Hummingbird ou un thème enfant, consignez la révision du thème et les surcharges pertinentes. Le contrat des modèles et du DOM du passage en caisse est une dépendance d’intégration concrète, et non une simple préférence de style. Contrat officiel du thème pour le passage en caisse.

Pour les extensions d’administration, identifiez les pages migrées et les indicateurs actifs. Testez l’enregistrement prévu du formulaire, le filtre de grille et la limite des permissions des employés sur chaque parcours pris en charge. Ne présentez pas un test sommaire réservé au SuperAdmin comme preuve des processus du personnel ordinaire.

Vérifiez que le code de compatibilité ne s’exécute pas deux fois lorsque les anciens et nouveaux hooks sont tous deux enregistrés. L’absence d’erreur fatale ne suffit pas si une action provoque des écritures ou notifications en double.

Un éditeur doit pouvoir relier chaque adaptation de compatibilité à un cas en échec ou à un changement de contrat documenté. Évitez les réécritures générales dont le bénéfice ne peut pas être démontré.

Examinez les hypothèses d’exécution et les services propres aux versions

La compatibilité d’exécution comprend le code exécuté uniquement lors d’étapes inhabituelles du cycle de vie : installation, désinstallation, tâches planifiées, gestion des erreurs et rappels des prestataires. Sollicitez ces parcours avec les versions d’exécution incluses dans la plage de prise en charge déclarée.

Les travaux de la version 9.2 ajoutent la prise en charge des définitions de services PHP et des fichiers de services YAML propres aux versions. Cela permet d’adapter le câblage des services tout en maintenant la prise en charge des anciennes versions, mais le comportement de chargement sélectionné doit être vérifié dans l’implémentation correspondante. Modification de la configuration des services propre aux versions.

Si vous adoptez ce mécanisme, testez le conteneur de services sur chaque branche de plateforme déclarée. Confirmez quel fichier est sélectionné et qu’aucun service n’existe uniquement parce que le cache local d’un développeur a conservé une ancienne définition. Ne supposez pas que plusieurs fichiers de services alternatifs seront tous fusionnés.

Pour déclarer la prise en charge de PHP 8.5, vérifiez la syntaxe et exécutez les tests concernés sur PHP 8.5 lui-même. La compatibilité du cœur ne valide pas automatiquement les dépendances d’un module. Les notes de version RC recensent des corrections liées à PHP 8.5, ce qui renforce la nécessité de tests propres à la version plutôt que d’une déduction générale. Journal des modifications de la version candidate.

Examinez aussi les hypothèses sur les ensembles de valeurs finis. Le changement de l’état des produits dans la version 9.2 ajoute des valeurs qu’un module doté d’une liste autorisée codée en dur peut rejeter ou mal libeller. Si votre module lit les états, comparez les valeurs qu’il prend en charge à l’énumération réelle de la version candidate et définissez son comportement face à une valeur inconnue. Modification de l’état des produits.

Testez la continuité des données client au cours des opérations du cycle de vie

Installez la version publiée du module dans un environnement de référence jetable, créez des données représentatives, puis appliquez la mise à jour candidate du module par le mécanisme pris en charge. Vérifiez que les valeurs existantes conservent leur sens et que les nouvelles valeurs par défaut n’écrasent pas des réglages délibérés.

Répétez la tentative de mise à jour lorsque le cycle de vie le permet. Une mise à jour partiellement terminée ne doit pas créer de définitions, index ou enregistrements métier en double. Consignez comment le module détecte une étape interrompue et en reprend l’exécution.

Testez séparément la désactivation et la réactivation, puis la désinstallation. Les marchands désactivent souvent un module pour diagnostiquer un autre problème ; cette action doit respecter la politique de conservation documentée. Si la désinstallation peut supprimer des données, explicitez cette politique et vérifiez-la avec des enregistrements fictifs.

Pour Extra Properties ou les tables personnalisées, incluez les variations de boutique et de langue. Une migration ne préservant que la boutique par défaut peut sembler réussie dans un jeu de données simple tout en perdant les informations importantes pour un client multiboutique.

N’utilisez pas un nettoyage destructif uniquement pour que le paquet se réinstalle proprement pendant le développement. Le comportement du cycle de vie commercial doit refléter les attentes des clients et la politique publiée du module.

Validez l’artefact distribuable

Exécutez la suite d’acceptation sur l’archive que les clients téléchargeront. Une copie de développement peut contenir des ressources générées, des dépendances tierces ou des fichiers de configuration absents du module empaqueté.

Examinez la structure de l’archive et les fichiers requis. Confirmez qu’elle s’installe par le Back Office pris en charge ou le processus de déploiement et que ses ressources se chargent sans dépendre d’outils de développement. Ne conservez les tests et les artefacts de compilation qu’aux emplacements où le processus de distribution les exige volontairement.

Vérifiez qu’aucun identifiant secret, fichier d’environnement local ou extrait de production n’est inclus. C’est une vérification concrète de l’empaquetage, et non une raison d’ajouter des éléments de conformité sans rapport à l’interface utilisateur du produit.

Consignez la somme de contrôle de l’artefact ou l’identifiant de compilation avec les résultats des tests. Si un paquet est recompilé après qualification, déterminez si son contenu a changé et répétez les contrôles concernés. Une étiquette de version ne permet pas à elle seule de distinguer deux archives différentes portant le même numéro.

Donnez à une limitation de prise en charge une frontière vérifiable par un test

Une limitation doit identifier le comportement exclu, et pas simplement dire que certaines fonctions ne sont pas prises en charge. Si une extension prend en charge l’ancien parcours d’administration mais pas celui qui a migré, consignez la page concernée et le test démontrant l’écart. Si une intégration de paiement exclut une interaction particulière sur une page, nommez cette interaction et l’alternative prise en charge.

Évitez de présenter un contournement par indicateur comme une garantie permanente. Il peut être utile pendant l’évaluation de la version candidate, mais une version future peut retirer l’ancien parcours. Désignez un responsable de l’adaptation et suivez la condition qui permettra de supprimer la limitation.

Pour les dépendances externes, conservez la déclaration du fournisseur propre à la version avec vos résultats. Si le fournisseur retire ensuite sa prise en charge ou modifie un contrat, le dossier de preuves indique clairement quelles combinaisons client nécessitent une revue.

Cela améliore aussi le triage des demandes de support. Un incident dans la matrice déclarée est une régression potentielle. Un incident en dehors mérite toujours d’être étudié, mais ne doit pas être confondu avec une combinaison déjà qualifiée.

Expliquez la distinction dans des termes utiles aux marchands : opération, versions et effet pratique. Les noms internes des suites de tests sont utiles aux ingénieurs, mais ne doivent pas constituer la seule explication donnée au client.

Publiez des limitations qui aident les marchands à décider

Les notes de version doivent indiquer les comportements nouvellement pris en charge, les combinaisons testées et ce qui reste exclu. « Diverses améliorations de compatibilité » renseigne peu un marchand sur la couverture de son passage en caisse ou de son processus multiboutique.

Fournissez un court modèle de reproduction aux premiers testeurs : versions du cœur, du module et du thème, indicateurs actifs, contexte de boutique et séquence d’actions. Cela réduit les échanges de support consacrés à reconstruire l’environnement.

Lorsque la version stable 9.2 sera officiellement publiée, comparez ses changements finaux à la version candidate qualifiée et réexécutez la partie concernée de la matrice avant d’élargir la déclaration de prise en charge. Une validation de version candidate constitue une préparation utile, mais reste liée à cet artefact candidat.

Une affirmation de compatibilité solide est donc un dossier de preuves : contrat de prise en charge délimité, cas de régression ciblés, archive distribuable vérifiée et limitations sincères. Cela aide les marchands à décider d’un déploiement et donne à l’éditeur un périmètre de support gérable.

Pour le contexte de la plateforme sous-jacente, consultez notre guide de développement de modules PrestaShop 9 et appliquez les vérifications propres à la version décrites ci-dessus à l’installation que vous évaluez.

Lors du choix d’une extension, parcourez les modules PrestaShop 9 de PrestaSuite et comparez la prise en charge des versions et les exigences d’intégration documentées à vos propres résultats de tests.