La validation d’une migration J2Store doit prouver le fonctionnement des relations entre le contenu Joomla et les enregistrements commerciaux. J2Store utilise des Articles Joomla comme Products, tandis que les Categories, menus, alias, Modules, templates, options, Customers, Orders, apps et autres extensions fournissent les relations qui rendent ces Products accessibles et achetables. Un nombre de Products identique ne prouve pas que l’Article Joomla attendu est bien traité comme un Product, qu’il apparaît dans le bon contexte de menu, que ses options conservent leur comportement ni qu’il reste relié aux Orders historiques.
Le projet J2Store d’origine a pris fin sous son ancienne identité, mais son code et son écosystème se poursuivent désormais avec J2Commerce. Les informations officielles actuelles distinguent une ligne de compatibilité J2Commerce 4 d’une reconstruction J2Commerce 6 native pour Joomla 6. Le dossier de validation doit donc identifier si l’environnement approuvé est un J2Store historique, J2Commerce 4 en mode compatibilité ou J2Commerce 6. Les preuves de migration restent nécessaires dans tous les cas, tandis que la compatibilité, la propriété des extensions, la sécurité, les sauvegardes, la restauration, la supervision et la récupération doivent correspondre à l’environnement réellement choisi, et non à une étiquette générique « J2Store ».
Définir le modèle de preuve et de responsabilité J2Store
La première décision de validation consiste à préciser l’environnement que le projet approuve réellement. Le dossier de preuves doit indiquer la version de Joomla, la ligne J2Store historique ou J2Commerce, le build exact, les apps et plugins requis, les surcharges de template, les extensions de paiement et de livraison, le code personnalisé, ainsi que les responsables de l’infrastructure, de la maintenance et de la récupération. Il doit aussi préciser si le projet conserve temporairement un environnement historique, poursuit avec la ligne de compatibilité J2Commerce 4 ou adopte J2Commerce 6 natif. Cette distinction modifie les preuves de compatibilité, de mise à niveau, d’extension, d’API et d’exploitation.
Utilisez quatre niveaux de preuve :
| Niveau de preuve | Éléments requis |
|---|---|
| Présence des enregistrements | Les Articles Joomla, Categories, utilisateurs, Customers, Orders, contenus et enregistrements personnalisés attendus existent. |
| Signification des relations | Les Articles sont traités comme les types de Product attendus ; options, menus, alias, utilisateurs, Orders et enregistrements d’extensions restent reliés. |
| Fonctionnement réel | Les processus nécessaires de vitrine, commande, e-mail, paiement, livraison, fiscalité, téléchargement, intégration et administration fonctionnent dans l’environnement choisi. |
| Responsabilité du cycle de vie | Les responsabilités de compatibilité, sécurité, sauvegarde, restauration, supervision et récupération sont acceptées. |
Le dossier de preuves doit relier chaque niveau à un exemple nommé et à un responsable identifié. Une simple étiquette d’environnement sans Products, Orders, routes, extensions et preuves de récupération effectivement testés ne suffit pas pour approuver l’environnement.
Classez les constats ainsi :
| Statut | Signification pour J2Store |
|---|---|
| Pass | La relation migrée ou l’opération requise fonctionne et possède un responsable identifié. |
| Watch | Une correction non bloquante, un point de compatibilité ou une décision de responsabilité reste ouvert avec une vérification planifiée. |
| Block | Le problème affecte le fonctionnement Product, la commande, l’historique Customer ou Order, le routage, les extensions requises, la sécurité, la récupération ou le périmètre personnalisé convenu. |
Utiliser des tests représentatifs pour exposer les cas difficiles
Les tests représentatifs doivent refléter le vrai modèle opérationnel J2Store, et non seulement des Products simples fondés sur des Articles. Incluez notamment :
- les types de Product simple, variable, configurable, téléchargeable, flexivariable, advanced-variable, réservation, abonnement ou tout autre type réellement inclus ;
- des Products dont les options influencent le SKU, le prix, le stock, le poids, la livraison, l’accès à un fichier ou une saisie de l’acheteur ;
- des Products accessibles par différents menus et contextes de Category Joomla ;
- des Articles multilingues, alias, Modules et associations de langue ;
- des Customers enregistrés et invités avec des Orders historiques ;
- des Orders contenant champs personnalisés, remises, taxes, livraison, états de paiement, téléchargements, remboursements ou références externes ;
- des champs détenus par des extensions, tables personnalisées et identifiants d’intégration ;
- du contenu et des URL prioritaires.
| Preuve représentative | Décision à obtenir avant une exécution plus large de la migration |
|---|---|
| Relation Product/Article | Déterminer si les Products source peuvent être représentés par l’Article Joomla et le type de Product J2Store prévus. |
| Options et variantes | Vérifier que les valeurs sélectionnables conservent la signification du prix, du stock, du fichier et de la ligne d’Order. |
| Utilisateurs et Customers | Vérifier que l’identité utilisateur Joomla, le contexte Customer J2Store, les adresses et les Orders restent reliés. |
| Routage | Vérifier que Categories, menus, alias, Modules et associations de langue conduisent aux bonnes vues Product et contenu. |
| Extensions | Vérifier que les enregistrements détenus par des apps ou personnalisés ont une destination définie et un propriétaire d’environnement compatible. |
| Cycle de vie | Vérifier que l’environnement choisi peut être maintenu, sécurisé, sauvegardé, restauré et récupéré. |
Une exécution plus large ne doit pas commencer lorsqu’un type de Product important, un enregistrement d’extension, une route, une relation Customer ou une dépendance de maintenance ne possède ni destination ni responsable approuvés.
Valider les Products fondés sur des Articles Joomla et le fonctionnement d’achat
Un Product J2Store est relié à un Article Joomla. La validation doit prouver les deux côtés de cette relation : le contenu de l’Article et son contexte Joomla, puis les données commerciales J2Store qui rendent le Product achetable.
Pour des Products représentatifs, vérifiez :
- que le bon Article Joomla est traité comme le Product attendu ;
- que le type de Product, SKU, statut, profil fiscal, contexte vendeur ou marque et prix sont corrects ;
- que les options et combinaisons conservent le choix prévu pour l’acheteur ;
- que le stock, le poids, la livraison et le prix appartiennent au bon Product ou à la bonne combinaison ;
- que les Products téléchargeables conservent les relations fichier, limite de téléchargement, expiration, statut d’Order et accès Customer ;
- que les images, filtres, Products associés, upsells, cross-sells et contenus détenus par des apps restent reliés au bon Product ;
- que la langue de l’Article, la Category, l’alias, l’auteur, la publication et l’état d’accès ne contredisent pas le résultat commercial.
| Résultat Product | Preuve de réussite | Preuve bloquante |
|---|---|---|
| Product simple | L’Article et les champs commerciaux décrivent un seul article vendable compréhensible. | L’Article existe mais n’est pas traité comme le Product attendu ou ne peut pas être acheté. |
| Product variable ou configurable | Les combinaisons d’options conservent le bon SKU, prix, stock et sens sur la ligne d’Order. | Des combinaisons manquent, sont dupliquées ou sont commercialement incorrectes. |
| Product téléchargeable | Un Customer ayant payé peut atteindre le fichier attendu selon les règles de téléchargement approuvées. | Le fichier, statut d’Order, droit, limite, expiration ou lien Customer est rompu. |
| Fonctionnement de réservation ou d’abonnement | Les enregistrements d’app requis et l’environnement cible prennent en charge le fonctionnement convenu. | L’app est absente, incompatible ou dissociée des Products et Orders. |
| Product avec personnalisation | La saisie de l’acheteur reste liée à la bonne ligne d’Order et visible dans le processus requis. | La saisie est perdue ou enregistrée sur le mauvais Product, Customer ou Order. |
La possibilité d’administrer les données fait partie de la preuve. Les équipes doivent pouvoir retrouver l’Article Product, comprendre quelles valeurs appartiennent à Joomla et lesquelles appartiennent à J2Store ou à une app, puis mettre à jour l’enregistrement prévu sans casser les routes ni les combinaisons.
Valider les Customers, utilisateurs Joomla et Orders historiques
Les données Customer de J2Store peuvent dépendre de l’identité utilisateur Joomla, des champs de profil, groupes, adresses, achats invités et enregistrements de compte détenus par des extensions. La validation doit prouver la continuité de l’identité sans fusionner des utilisateurs distincts ni séparer un Customer de ses Orders.
Les preuves Customer doivent couvrir :
- les acheteurs enregistrés et invités ;
- la relation entre l’ID utilisateur Joomla et le Customer J2Store ;
- les noms, e-mails, adresses, groupes, champs fiscaux ou métier et ID externes ;
- les identités dupliquées ou modifiées ;
- l’historique des Orders et les routes de compte visibles par le Customer ;
- les contextes d’adhésion, fidélité, abonnement, vendeur ou autre détenus par une extension lorsqu’ils sont inclus.
Les Orders historiques doivent préserver les instantanés Product et option, quantités, prix, remises, taxes, livraison, état de paiement, contexte de traitement, adresses, historique de statut, commentaires, droits de téléchargement, champs personnalisés et références externes lorsque cela s’applique.
| Constat | Orientation du statut |
|---|---|
| L’Order existe et les totaux concordent, tandis que la configuration actuelle de la passerelle reste gérée séparément | Pass |
| Un statut historique nécessite une interprétation documentée mais l’historique financier et de traitement reste clair | Watch |
| Le Customer est relié au mauvais utilisateur Joomla ou au mauvais Order | Block |
| Les options Product historiques ne permettent plus de comprendre ce qui a été acheté | Block |
| Un accès au téléchargement est requis mais le fichier, le statut, le droit ou la relation Customer est rompu | Block |
| La configuration active du paiement, de la livraison, de la taxe ou des e-mails est incomplète | Watch ou Block d’implémentation cible selon la dépendance au lancement |
Les Orders historiques ne prouvent pas que les nouveaux processus de commande, taxe, paiement, livraison, coupon, e-mail ou traitement sont prêts. Ces fonctions actives exigent des preuves de bout en bout distinctes.
Valider la navigation Joomla, les routes, le contenu et la localisation
La découverte des Products J2Store dans la vitrine dépend des Categories Joomla, éléments de menu, alias, Modules, templates, niveaux d’accès, associations de langue et vues Product. Les URL directes des Products ne suffisent pas comme preuve.
Utilisez un registre des parcours prioritaires couvrant la navigation principale, les listes de Category, pages de détail Product, routes de compte, panier et commande, historique d’Orders, contenu téléchargeable, pages de politique, campagnes et URL provenant de liens externes. Pour chaque chemin, confirmez le résultat direct prévu, la redirection pertinente ou le retrait approuvé.
La validation doit couvrir :
- les menus principaux et secondaires ;
- les vues de listes Category Joomla et Product J2Store ;
- les alias, URL canoniques, redirections, fils d’Ariane et liens internes ;
- le placement des Modules et la visibilité des Products dans le contexte de menu attendu ;
- la recherche, les filtres, Products mis en avant, Products associés et Modules de merchandising ;
- les CMS Pages et le contenu des Articles ;
- les Articles, Categories, menus, alias, Modules, métadonnées, e-mails et libellés de commande propres à chaque langue ;
- le comportement des devises, taxes, adresses, dates et formats numériques pour les principales régions d’exploitation.
Un Product peut fonctionner via une URL directe et échouer via un autre chemin de menu parce que le routage Joomla et le contexte des Modules diffèrent. Testez les routes réellement utilisées par les Customers, moteurs de recherche, campagnes et liens internes.
Valider les extensions, tables personnalisées et intégrations
Les apps J2Store, plugins Joomla, Modules, surcharges de template, tables personnalisées et services externes peuvent détenir des enregistrements Product, Customer, Order, commande, fiscalité, paiement, livraison, réservation, abonnement, téléchargement, fidélité, vendeur ou intégration. Leurs données doivent être validées à partir d’une spécification traçable.
| Champ de spécification | Preuve requise |
|---|---|
| Propriétaire source et ID d’exemple | Identifie précisément l’app, la table, le champ, le fichier, l’API ou le système externe. |
| Enregistrement parent | Nomme l’Article Joomla, Product, utilisateur, Customer, Order ou autre enregistrement que la valeur étend. |
| Destination et transformation | Explique où va la valeur et comment elle change. |
| Dépendance d’environnement | Identifie l’app, le plugin, le code personnalisé ou le service externe compatible requis pour utiliser la donnée. |
| Consommateur futur | Nomme le processus interne, la vitrine, l’intégration, le rapport ou le système externe qui lit le résultat. |
| Condition de réussite | Définit le résultat utilisable exact. |
Les sorties de migration approuvées doivent être validées par rapport à la demande achetée de filtrage, mise en correspondance ou configuration circonscrite. Les sorties non standard doivent être validées par rapport au périmètre personnalisé convenu. La validation ne doit pas s’étendre silencieusement à l’implémentation complète de Joomla, au développement d’extensions, à la reconstruction de templates ou au déploiement d’intégrations sauf si ces livrables sont expressément inclus.
Pour les intégrations nécessaires, testez l’authentification, les identifiants, la direction des données, le fonctionnement par événement ou planning, la responsabilité en cas d’erreur et le rapprochement. La présence d’une clé externe ne suffit pas si le système connecté ne peut plus identifier le bon Product, Customer ou Order.
Valider l’environnement J2Store ou J2Commerce exact
Les preuves liées au cycle de vie sont une condition de lancement, mais leur nature dépend de la ligne choisie. Un environnement J2Store historique nécessite l’acceptation explicite des dépendances non prises en charge ou maintenues de façon privée. J2Commerce 4 en mode compatibilité exige des preuves sur sa couche de compatibilité Joomla et le fonctionnement des extensions conservées. J2Commerce 6 natif exige des preuves que les Products, options, Orders, Customers, extensions, templates et intégrations fonctionnent dans l’architecture reconstruite pour Joomla 6. L’organisation doit approuver un environnement identifié, et non une hypothèse mélangeant les trois.
| Domaine du cycle de vie | Preuve de réussite | Signal bloquant |
|---|---|---|
| Identité de l’environnement | Les preuves nomment J2Store historique, J2Commerce 4 en compatibilité ou J2Commerce 6 natif et utilisent les bonnes attentes Product, extension et intégration. | Le projet mélange les comportements de différentes lignes ou ne peut pas identifier l’environnement réel. |
| Compatibilité | Joomla, PHP, la base de données, la ligne e-commerce choisie, les apps, plugins et surcharges de template requis fonctionnent ensemble. | Les composants nécessaires ne peuvent pas fonctionner ensemble ou aucun responsable ne peut résoudre l’incompatibilité. |
| Sécurité | Les responsabilités de correctifs, durcissement, accès, dépendances et incidents sont attribuées. | Aucun responsable sécurité n’est identifié ou une exposition non prise en charge est acceptée sans le savoir. |
| Sauvegarde et restauration | Des sauvegardes complètes du site et de la base existent et une restauration a été démontrée. | La sauvegarde n’existe que formellement ou la restauration n’est pas prouvée. |
| Supervision | La disponibilité, les erreurs, la commande, les intégrations et l’infrastructure sont surveillées par un responsable. | Des défaillances peuvent rester invisibles en exploitation. |
| Récupération | Procédure de rollback ou de récupération, artefacts, contacts et autorité de décision sont documentés. | La boutique ne peut pas être restaurée dans une fenêtre métier acceptable. |
| Continuité des extensions | Les apps et codes personnalisés requis ont un mainteneur ou un remplacement approuvé. | Un processus critique pour le lancement dépend d’un code abandonné ou incompatible sans plan. |
Ces preuves déterminent si le résultat validé peut être exploité après le lancement. Elles complètent la préparation avant migration et l’analyse des risques en enregistrant ce qui doit être démontré pour la décision finale.
Revalider l’exécution plus large et les actions de migration ultérieures
L’exécution plus large de la migration doit rapprocher le périmètre approuvé complet, les exclusions, décisions de transformation, exceptions de relation et éléments d’implémentation non résolus. Elle doit confirmer que les cas difficiles prouvés pendant le test représentatif fonctionnent toujours à plein volume et qu’aucun nouveau type de Product, extension, langue, route ou champ personnalisé n’introduit un fonctionnement non testé.
Les actions de migration ultérieures exigent une revalidation proportionnée :
| Action de migration | Priorité de revalidation J2Store |
|---|---|
| continuer avec la configuration acceptée | Confirmer que les nouveaux enregistrements éligibles suivent les relations approuvées entre Articles Joomla, types de Product, options, utilisateurs, Orders, routes et champs personnalisés. |
| continuer avec une configuration révisée | Revalider chaque filtre, correspondance, type de données sélectionné, relation Product, règle de langue, décision d’URL et champ détenu par une extension qui a changé. |
| produire un nouveau résultat de migration distinct | Traiter le nouveau résultat comme un ensemble de preuves séparé couvrant Products, Customers, Orders, contenus, routes, extensions, opérations actives et responsabilité du cycle de vie. |
Après toute action, revérifiez les Products, Customers, Orders, Blog Posts, URL, champs personnalisés, enregistrements d’apps et intégrations concernés. Confirmez aussi que l’environnement J2Store historique ou J2Commerce choisi, sa couche de compatibilité et son ensemble d’extensions n’ont pas changé depuis l’enregistrement des preuves précédentes. Un résultat antérieur réussi ne couvre pas automatiquement de nouvelles données ni un environnement modifié.
Décider si J2Store est prêt pour le lancement
L’approbation finale doit être signée par les responsables des données métier, de l’implémentation Joomla, de l’exploitation technique, de la sécurité et de la récupération, des intégrations et du périmètre de migration.
| Décision | Règle de lancement |
|---|---|
| Pass | La relation migrée ou l’opération requise est correcte, étayée par des preuves et possède un responsable. |
| Watch | Un problème non bloquant reste ouvert avec un responsable, une échéance et une nouvelle vérification qui ne fragilisent pas le dossier de lancement. |
| Block | Le problème affecte le fonctionnement Product, la continuité Customer ou Order, la commande, les routes, les extensions requises, la sécurité, la restauration, la récupération, l’intégration ou une sortie personnalisée convenue. |
L’environnement n’est prêt que lorsque tous les Blocks sont fermés et que les éléments Watch sont explicitement acceptés pour l’environnement nommé. Des nombres correspondants, une page d’accueil qui charge ou une commande simple qui fonctionne ne compensent pas des relations Article rompues, un fonctionnement des options perdu, des Orders dissociés, des extensions incompatibles ou un environnement de maintenance sans responsable. L’approbation doit également préciser si le résultat est un déploiement J2Store historique volontairement maintenu, un déploiement J2Commerce 4 en compatibilité ou J2Commerce 6 natif, car les décisions futures de mise à niveau et de support dépendent de cette information.
Conclusion
La validation J2Store doit prouver à la fois le fonctionnement connecté du commerce et une responsabilité claire sur le cycle de vie, tout en tenant compte du modèle actuel de succession par J2Commerce. Les Articles Joomla doivent conserver leur signification Product ; les options et types de Product doivent rester vendables ; les Customers et Orders historiques doivent rester reliés ; les menus, alias, Modules, langues et routes doivent conduire au contenu prévu ; et les extensions et intégrations requises doivent rester utilisables dans l’environnement spécifiquement approuvé, qu’il s’agisse de J2Store historique, J2Commerce 4 ou J2Commerce 6.
Les tests représentatifs doivent exposer les relations difficiles, l’exécution plus large doit rapprocher tout le périmètre et les actions de migration ultérieures doivent recevoir une revalidation ciblée. La décision de lancement n’est crédible que lorsque les données migrées, les opérations actives, la compatibilité, la sécurité, la sauvegarde, la restauration, la supervision et la récupération sont toutes classées Pass, Watch ou Block avec des responsables identifiés.
Questions fréquentes
La correspondance des nombres de Products, Customers et Orders suffit-elle pour approuver J2Store ?
Non. Les nombres ne prouvent ni les relations avec les Articles Joomla, ni le fonctionnement des options, ni les liens utilisateur, ni la signification des Orders historiques, ni les routes, ni la commande active, ni la compatibilité des extensions ou l’état de préparation du cycle de vie.
Pourquoi la validation J2Store doit-elle inclure les menus et alias Joomla ?
Le routage Joomla et le contexte des Modules peuvent déterminer la manière dont un Product apparaît. Un Product peut exister et fonctionner via une URL directe tout en étant absent, dupliqué ou présenté incorrectement par les routes réellement utilisées par les Customers.
Les Orders historiques prouvent-ils que la taxe, la livraison et le paiement sont prêts ?
Non. Les Orders historiques conservent les preuves des transactions passées. Le fonctionnement actuel de la taxe, livraison, paiement, devise, commande, notifications et fournisseurs nécessite des preuves actives distinctes.
Comment valider les données détenues par des extensions et les données personnalisées ?
Retracez chaque valeur depuis l’app ou la table source jusqu’au bon Product, Customer, Order ou enregistrement de contenu, puis démontrez que l’extension compatible ou le processus externe peut encore l’utiliser.
Que faut-il revalider après une action de migration J2Store ultérieure ?
Revalidez tous les enregistrements et relations concernés, en particulier les types de Product, options, utilisateurs Joomla, Orders, langues, routes, champs personnalisés, extensions et intégrations. Une nouvelle configuration exige des contrôles ciblés sur chaque règle modifiée.
Comment la relation actuelle entre J2Store et J2Commerce doit-elle influencer l’approbation ?
L’approbation doit nommer l’environnement réel. Un déploiement J2Store historique exige une responsabilité explicite de maintenance et de récupération ; J2Commerce 4 en compatibilité exige des preuves pour la couche de compatibilité et les extensions conservées ; J2Commerce 6 natif exige des preuves dans son architecture Joomla 6 reconstruite. L’exécution de la migration ne fournit pas ces responsabilités.