Si J2Commerce est retenu comme plateforme cible, la préparation doit relier les enregistrements commerce aux structures Joomla qui les rendent visibles et exploitables. Les Products peuvent dépendre d’Articles Joomla, Categories, menus, Modules, Custom Fields, User Groups, applications, extensions de paiement et de livraison ainsi que de mises en page de templates. Des types de Products spécialisés peuvent ajouter variantes, téléchargements, abonnements, réservations, bundles, acomptes ou données saisies par le Customer qui ne peuvent pas être comprises à partir du seul nombre de Products.
Le dossier de préparation doit définir chaque action, son responsable, l’élément de preuve attendu et la condition permettant de considérer l’action comme prête avant le début de la migration. Il doit également séparer les enregistrements qui relèvent du périmètre de migration de la configuration active du processus de commande, des taxes, paiements, livraisons, notifications, cron et extensions qui relève de l’implémentation cible.
Cette préparation doit produire un échantillon J2Commerce représentatif, exposer tout besoin de mise en correspondance ou de traitement adapté et séparer clairement le périmètre de migration de l’implémentation Joomla et J2Commerce avant une exécution plus large.
Sécuriser les accès Joomla, J2Commerce, hébergement et base de données
Confirmez les accès à l’administration Joomla, à l’administration J2Commerce, à l’hébergement, à la base de données, au système de fichiers, aux médias, aux tâches planifiées et aux services externes. Consignez les versions Joomla et J2Commerce, les versions PHP et base de données, le template actif, les langues activées, les applications installées, les extensions de paiement et de livraison et tout code personnalisé.
| Action de préparation | Responsable | Preuve | Condition de préparation |
|---|---|---|---|
| Confirmer les accès administratifs | Administrateur Joomla/J2Commerce | Comptes fonctionnels et synthèse des rôles | Catalogue, Orders, Customers, applications, menus et configuration peuvent être inspectés. |
| Créer des sauvegardes restaurables | Responsable infrastructure | Export de base de données, archive du système de fichiers, notes sur médias externes et responsable de restauration | La source peut être restaurée sans dépendre de la boutique active. |
| Capturer l’environnement d’extensions | Responsable technique | Inventaire avec versions des composants, plugins, Modules, templates et applications | Chaque dépendance commerce est répertoriée avec un responsable. |
| Documenter les processus planifiés et externes | Responsable intégration | Tâches cron, endpoints webhook, connexions ERP/PIM/WMS/CRM/paiement/livraison et IDs externes | Les intégrations qui continuent et les autorités de données sont identifiées. |
| Préserver les identifiants source | Coordinateur de migration | IDs Product, Article, Category, User, Customer, Order, option, variante, abonnement et systèmes externes | Les relations entre enregistrements peuvent être retracées après extraction. |
Si la boutique provient de J2Store ou a traversé un changement de version majeur, consignez cette filiation. Des libellés similaires peuvent désigner des tables ou versions d’applications différentes et d’anciennes personnalisations peuvent toujours dépendre de champs historiques.
Préparer les Products selon leur comportement de vente
Ne classez pas les Products J2Commerce uniquement par nom ou quantité. Préparez-les selon le comportement qui doit rester compréhensible : vente simple, variantes, téléchargement, abonnement, réservation, bundle, service, acompte, personnalisation ou type de Product détenu par une application.
| Modèle Product | Preuves requises | Condition de préparation |
|---|---|---|
| Product physique simple | Article/Product ID, SKU, prix, profil fiscal, stock, poids, images, liens Category et exemple d’Order | Un enregistrement identifie clairement l’élément vendable et sa relation avec le contenu Joomla. |
| Product à variantes | Définitions d’options, valeurs, variantes générées, SKU/prix/stock/image par variante et Product ID parent | Chaque combinaison vendable peut être reliée à son parent et à ses valeurs sélectionnées. |
| Product téléchargeable | Enregistrements de fichiers, règles d’accès, limites, expiration, lien Product et exemple d’Order terminé | La propriété des fichiers et la preuve d’accès fondée sur l’Order sont complètes. |
| Product d’abonnement | Type de Product, plan/variante, intervalle de facturation, essai, statut, dépendance de paiement, dépendance cron, lien User Group Joomla et exemple d’abonnement | L’état récurrent et les relations d’accès ont un responsable et une décision cible nommés. |
| Product de réservation | Ressource, règles de date/heure, capacité, prix, saisie Customer et exemple de réservation | Les enregistrements de disponibilité et l’historique de réservation sont séparés des champs Product ordinaires. |
| Bundle ou Product groupé | Product parent, Products composants, quantités, logique de prix, relation de stock et exemple d’Order | L’identité et la propriété des composants sont documentées. |
| Product personnalisé | Définitions d’entrées, comportement d’options, fichiers fournis par l’acheteur, effets sur le prix et exemple de ligne d’Order | Les données saisies par l’acheteur restent distinctes des attributs Product réutilisables. |
Pour chaque type de Product, notez quelles valeurs contrôlent l’identité, le prix, le stock, la taxe, le poids, la livraison, l’accès, le renouvellement ou le traitement des commandes. Si une application ou un plugin personnalisé possède une partie de ce fonctionnement, ajoutez ses tables, clés et dépendances de configuration au dossier de preuves.
Préparer options, variantes, Custom Fields et relations avec les Articles
Les Products J2Commerce peuvent être reliés au contenu d’Articles Joomla et à des structures d’options ou variantes J2Commerce. La préparation doit distinguer le contenu Product partagé des données propres aux combinaisons vendables et des valeurs saisies par le Customer.
| Relation | Preuve | Condition de préparation |
|---|---|---|
| Article Joomla vers Product | Article ID, Product ID, alias, langue, niveau d’accès et champs de contenu | Le contenu Product ne se retrouve pas séparé accidentellement de l’enregistrement Product. |
| Option Product | Nom, type, valeurs, ordre, effet sur le prix et affectation Product | Les définitions de choix réutilisables sont documentées. |
| Variante | Product parent, valeurs d’options sélectionnées, SKU, stock, prix, image, statut et ID externe | Chaque unité réellement vendable possède un enregistrement unique et traçable. |
| Custom Field | Définition du champ, contexte, valeurs, finalité métier et mise en page/application consommatrice | Les données descriptives ne sont pas confondues avec un choix acheteur ou un état d’application. |
| Saisie Customer | Définition de l’entrée et exemple de valeur sur une ligne d’Order | La saisie ponctuelle de l’acheteur reste attachée au contexte d’achat. |
Normalisez les doublons évidents dans les libellés d’options uniquement après avoir conservé le vocabulaire et les relations d’origine. Si « Colour », « Color » et « Finish » ont des significations métier différentes dans la source, ne les fusionnez pas simplement parce qu’ils semblent proches.
Préparer Categories, menus, URL, médias et découverte en vitrine
La découverte du catalogue J2Commerce peut dépendre des Categories Joomla, de l’ordre des Articles, des Menu Items, Modules, filtres, recherche, mises en page de templates et médias Product. Un Product peut être complet dans l’administration sans être accessible par la route prévue.
Préparez une cartographie Product-Category, la hiérarchie des Categories, les preuves d’ordre des Articles, l’inventaire des Menu Items, les affectations de Modules, les valeurs de filtres, les URL prioritaires, les redirections, les références d’images et les affectations linguistiques. Incluez les routes des pages Product, vues Category, pages de compte, téléchargements, gestion des abonnements, panier, processus de commande et pages de campagne importantes.
| Zone de découverte | Preuves à préparer | Condition de préparation |
|---|---|---|
| Appartenance à une Category | IDs Product/Article et hiérarchie Category | Les Products dans le périmètre ont un emplacement de découverte volontaire. |
| Routage par menu | Type de Menu Item, parent, alias, langue, niveau d’accès et destination | Les parcours prioritaires de vitrine ont des routes cibles explicites. |
| Modules et filtres | Position du Module, affectation de menu, source du filtre et extension propriétaire | Le fonctionnement de découverte est séparé des données Product. |
| Médias Product | Chemins de fichiers, images principales/supplémentaires/de variantes, texte alternatif et notes sur stockage distant | Les relations média peuvent être reliées au bon Product ou à la bonne variante. |
| Redirections et métadonnées | URL source, intention cible, métadonnées, notes canoniques et preuves liées aux extensions de routage | Les chemins à forte valeur ont un traitement cible unique. |
Ne supposez pas que migrer les Products recrée les menus Joomla, positions de Modules, vues de templates ou comportements de recherche/filtrage. Il s’agit de responsabilités distinctes côté cible, mais leurs relations source doivent être documentées.
Préparer Customers, Users Joomla, groupes et adresses
L’identité Customer dans J2Commerce peut impliquer des Users Joomla, acheteurs invités, enregistrements d’adresses, groupes Customer, champs société, identifiants fiscaux, adhésions et clés CRM ou ERP externes. Préparez ces éléments séparément.
| Point relatif au compte | Preuve | Condition de préparation |
|---|---|---|
| Customer enregistré | User ID Joomla, Customer ID, e-mail, statut, groupes, adresses et IDs externes | Les doublons et cas multi-groupes ont un traitement cible défini. |
| Customer invité | Identité au niveau de l’Order et adresses | L’historique invité n’est pas forcé dans des comptes Users inventés. |
| Groupe Customer | Définition du groupe et comportement associé de prix, taxe, accès ou remise | Le sens du groupe est documenté au-delà de son libellé. |
| Identité société ou fiscale | Champs société, numéros fiscaux, état de validation et référence de compte externe | Les données de compte professionnel ont un propriétaire cible nommé. |
| Authentification | Mot de passe local, SSO, connexion sociale, MFA, procédure de réinitialisation et responsable de communication | L’accès aux comptes est planifié sans supposer la portabilité des mots de passe. |
Si une application d’abonnement ou d’adhésion modifie les User Groups Joomla après l’achat, incluez le statut déclencheur, le lien Product, le groupe cible, l’état de l’abonnement et des Orders représentatifs. L’affectation de groupe constitue alors une relation d’application, et non une simple métadonnée Customer.
Préparer Orders, paiements, livraison, taxes et historique après-vente
Les Orders historiques doivent expliquer ce qui a été acheté et ce qui s’est produit. Préparez les en-têtes d’Orders, lignes, références Product/variante, options sélectionnées, valeurs saisies par le Customer, adresses, prix, remises, taxes, libellés de paiement et de livraison, statuts, commentaires, transactions, factures, remboursements, téléchargements, abonnements et références de réservation lorsqu’ils existent.
| Preuve liée à l’Order | Responsable | Condition de préparation |
|---|---|---|
| En-tête et historique de statuts | Opérations commerce | La séquence des statuts et les horodatages sont compréhensibles. |
| Lignes d’Order | Catalogue et opérations | Product, variante, SKU, valeurs sélectionnées, quantité et prix sont conservés comme instantanés historiques. |
| Preuve de paiement | Finance ou responsable paiement | Le libellé de méthode et la référence de transaction sont documentés sans traiter les identifiants d’accès comme des données migrées. |
| Preuve de livraison | Responsable traitement des commandes | Le libellé de méthode, le montant, le suivi et le contexte d’expédition sont disponibles lorsqu’ils sont utilisés. |
| Preuve de taxe et remise | Finance ou responsable commerce | Les montants et libellés appliqués peuvent être rapprochés des totaux. |
| Enregistrements après-vente | Responsable service Customer | Remboursements, téléchargements, changements d’abonnement, annulations ou statuts de réservation sont reliés à l’Order. |
Créez un glossaire des statuts expliquant la signification opérationnelle de chaque statut source d’Order, paiement, livraison, abonnement et réservation. Des libellés similaires peuvent représenter des états différents selon les extensions.
Inventorier applications, plugins, tables personnalisées et intégrations
Les applications J2Commerce et extensions Joomla peuvent posséder des abonnements, réservations, bundles, acomptes, livraison, paiement, remises, synchronisation de stock, flux Product, factures, fidélité, avis et données personnalisées du processus de commande. Le dossier de préparation doit identifier le véritable propriétaire de chaque enregistrement.
Pour chaque extension importante, consignez le nom, la version, les tables, champs, clés primaires et étrangères, références Product/Customer/Order, dépendances de configuration, tâches planifiées, services externes et responsable métier actuel. Classez le besoin comme enregistrement natif, enregistrement détenu par une application, enregistrement de système externe, configuration cible, présentation ou candidat au retrait.
Les identifiants externes nécessitent une attention spécifique. Product IDs ERP, Customer IDs CRM, marketplace listing IDs, codes d’entrepôt, payment transaction IDs et références de passerelles d’abonnement peuvent être de petits champs mais constituer des clés relationnelles critiques.
La condition de préparation est atteinte lorsqu’aucun enregistrement commerce requis n’est décrit seulement comme « données personnalisées » ou « données d’app ». Chaque jeu de données actif doit avoir une entité nommée, un responsable, une preuve source et une décision de destination.
Séparer les enregistrements migrés de la configuration cible
Le fonctionnement actuel des taxes, paiements, livraisons, e-mails, devises, cron, processus de commande, cache, templates et sécurité relève de l’implémentation cible. Les enregistrements historiques peuvent préserver libellés et montants sans configurer le fonctionnement actif.
| Preuves source à préparer | Responsabilité cible maintenue séparément |
|---|---|
| Libellés historiques de paiement et transaction IDs | Compte passerelle, identifiants d’accès, callbacks, paramètres antifraude et tests de paiement actifs |
| Libellés historiques de livraison et suivi | Comptes transporteurs, tarifs, zones, emballage, retrait et configuration du traitement des commandes |
| Montants fiscaux historiques et références de profils de taxes | Enregistrements fiscaux actuels, taux, exemptions et paramètres de calcul |
| Relations Product et Customer Group | Configuration active de prix, accès et promotions |
| Historique d’abonnement et références de facturation | Prise en charge des tokens de passerelle actuels, tâches de renouvellement, e-mails et automatisation des accès |
| URL et métadonnées existantes | Menus cibles, rendu des templates, recherche et implémentation des redirections |
La préparation est complète lorsque les preuves source expliquent le sens historique et que le responsable de l’implémentation cible accepte la responsabilité de la configuration active. N’utilisez pas la réussite d’un export source comme preuve que le processus de commande ou la facturation récurrente est configuré.
Sélectionner des échantillons représentatifs pour tester la migration
Choisissez des échantillons qui exposent les relations difficiles de J2Commerce. Incluez :
- un Product simple relié à un Article Joomla et une Category ;
- un Product multi-options avec variantes générées et SKU ou stock par variante ;
- un Product téléchargeable avec preuve d’accès aux fichiers ;
- un abonnement, une réservation, un bundle ou autre type spécialisé lorsqu’il est utilisé ;
- un Customer avec plusieurs adresses ou groupes ;
- un Order invité et un Order associé à un Customer enregistré ;
- un Order avec remise, taxe, livraison et références de paiement ;
- un Product avec Custom Fields, saisie Customer ou données détenues par une application ;
- une route Product multilingue ou restreinte ;
- un Product ou Order relié à un identifiant externe.
Pour chaque échantillon, notez les IDs source, la raison de sa sélection, les relations qu’il exerce, les preuves nécessaires à son interprétation et toute configuration cible volontairement hors du périmètre de migration.
Établir la condition finale de préparation
| Question de préparation | Condition requise |
|---|---|
| La source est-elle restaurable ? | Base de données, système de fichiers, médias et preuves d’extensions sont sauvegardés avec un responsable de restauration. |
| Les types de Products sont-ils classifiés ? | Chaque famille Product du périmètre possède un type, un comportement de vente, un responsable et un échantillon représentatif. |
| Les relations Joomla sont-elles visibles ? | Articles, Categories, menus, Modules, langues, Access Levels et routes sont cartographiés pour les Products prioritaires. |
| Customers et Orders sont-ils interprétables ? | Liens Users, groupes, adresses, statuts, totaux et enregistrements après-vente sont documentés. |
| Les applications et données personnalisées ont-elles un propriétaire ? | Chaque jeu de données d’extension actif possède un schéma, un responsable, une clé source et une décision de destination. |
| La configuration est-elle séparée ? | Les responsabilités actives liées au processus de commande, taxes, paiement, livraison, cron et templates ont des propriétaires cibles nommés. |
| Les échantillons sont-ils suffisants ? | Les échantillons représentatifs couvrent variantes, Products spécialisés, états Customer/Order, URL et données d’extensions. |
Des sauvegardes inconnues, types de Products non classifiés, identités de variantes manquantes, données d’abonnement ou réservation non documentées ou tables d’extensions sans propriétaire doivent bloquer le périmètre concerné jusqu’à ce que les preuves soient complètes.
Conclusion
Préparer J2Commerce exige davantage qu’un export de Products et Orders. Il faut préserver les relations entre Articles Joomla, Categories, menus, Users, Products J2Commerce, options, variantes, Customers, Orders, applications de Products spécialisés, fichiers, routes et systèmes externes.
Un dossier de préparation robuste attribue chaque action à un responsable, consigne les preuves nécessaires pour comprendre chaque relation, sépare la configuration cible active des enregistrements historiques et sélectionne des échantillons représentatifs qui exposent la complexité réelle de la boutique avant le début de la migration.
Questions fréquentes
Que faut-il préparer en premier pour une migration vers J2Commerce ?
Sécurisez les accès Joomla, J2Commerce, hébergement, base de données, système de fichiers, tâches planifiées et systèmes externes. Créez ensuite des sauvegardes immuables et un inventaire daté de l’environnement et des extensions avant de nettoyer ou restructurer les enregistrements.
Pourquoi les Articles Joomla sont-ils importants dans la préparation J2Commerce ?
Les Products J2Commerce peuvent dépendre du contenu des Articles Joomla, Categories, menus, langues, Access Levels, Modules et routes. L’enregistrement Product seul peut ne pas contenir l’identité complète de vitrine ni le parcours de découverte.
Comment préparer les variantes J2Commerce ?
Consignez le Product parent, les définitions d’options, valeurs sélectionnées, SKU, stock, prix, images, statut et identifiants externes de chaque variante. Utilisez des variantes représentatives qui exposent les combinaisons les plus susceptibles de perdre leur identité pendant la migration.
Quelles preuves faut-il préparer pour les abonnements ou réservations J2Commerce ?
Préparez le type de Product, le plan ou la ressource, les plannings, statuts, liens Customer et Order, références de paiement, règles d’accès, dépendances de tâches planifiées et des enregistrements historiques représentatifs. La configuration active de renouvellement ou disponibilité reste une responsabilité cible séparée.
Les paramètres de paiement, livraison et taxes doivent-ils être inclus comme enregistrements migrés ?
Les Orders historiques doivent conserver les libellés de méthodes, montants et références de transaction ou suivi. Les passerelles actives, tarifs transporteurs, zones, identifiants d’accès et calculs fiscaux relèvent de la configuration cible et doivent avoir des responsables distincts.
Quels enregistrements choisir pour le test représentatif d’une migration J2Commerce ?
Choisissez des Products simples et à variantes, types de Products spécialisés, fichiers téléchargeables, Customers complexes, Orders invités et enregistrés, remises et taxes, routes multilingues ou restreintes, Custom Fields, données détenues par des applications et identifiants externes.