EShop by Ossolution Team est une extension e-commerce native de Joomla qui inscrit la boutique dans un site Joomla plus large. Ses fonctions de catalogue, Customers, Orders, commande et merchandising coexistent avec les menus, modules, templates, paramètres linguistiques, médias, routes et autres extensions Joomla. Ce modèle combiné constitue la caractéristique fondamentale de la plateforme.
Pour une migration, EShop ne doit donc pas être considéré comme une base de catalogue isolée. Une boutique cible exploitable dépend de trois couches liées : les enregistrements commerciaux migrés, la configuration EShop et l’environnement Joomla qui présente et soutient ces enregistrements. Les Products peuvent être présents alors que la découverte dans la vitrine reste incomplète. Les Orders peuvent être disponibles alors que le paiement et l’expédition exigent encore une configuration côté cible. Les Customers peuvent exister alors que l’accès aux comptes, les groupes et les relations avec les utilisateurs Joomla nécessitent un traitement distinct.
Cette vue d’ensemble établit où EShop conserve le sens métier, comment Joomla et EShop se partagent les responsabilités et pourquoi une migration vers EShop doit séparer clairement continuité des données et mise en œuvre de la cible.
EShop comme plateforme e-commerce native de Joomla
EShop est installé et exploité comme une extension Joomla. Il suit l’environnement de composants, modules, plugins, menus, templates et langues de Joomla au lieu de fournir une pile d’administration et de vitrine hébergée séparément. Le marchand conserve ainsi un contrôle direct sur l’hébergement, la structure du site, le choix des extensions, le fonctionnement des templates et la maintenance opérationnelle.
Ce contrôle crée aussi une responsabilité partagée. EShop gère les principaux domaines commerciaux, mais Joomla détermine une grande partie du contexte du site dans lequel ils apparaissent. Une Category peut exister dans EShop tandis que sa visibilité dépend de Menu Items, modules, positions de template, aliases et associations linguistiques. Un Product peut porter images, options, attributs et stock, tandis que sa présentation dépend des layouts EShop, des overrides de template Joomla et des modules publiés.
| Couche de plateforme | Responsabilité principale | Importance pour la migration |
|---|---|---|
| Enregistrements e-commerce EShop | Products, Categories, Manufacturers, Customers, Orders, reviews, coupons, vouchers et relations du catalogue | Constituent le principal périmètre de données et doivent conserver des relations utiles. |
| Configuration EShop | Taxes, devises, champs de la commande, expédition, paiement, statuts Orders, e-mails, layouts et paramètres de boutique | Détermine le fonctionnement futur et n’est pas équivalente aux données historiques. |
| Structure du site Joomla | Menus, modules, aliases, templates, contenu, associations de langue, médias et accès | Détermine comment la boutique cible est atteinte, affichée et administrée. |
| Extensions et intégrations | Plugins de paiement/expédition, extensions complémentaires, systèmes externes, champs personnalisés et code sur mesure | Leurs données et comportements nécessitent des décisions distinctes de responsabilité et de prise en charge. |
Ce modèle par couches est plus important qu’une simple liste de fonctions. Il explique pourquoi un transfert techniquement complet peut encore produire une expérience client incomplète lorsque la présentation Joomla ou la configuration EShop ne sont pas prêtes.
Structure du catalogue et merchandising
EShop propose une structure de catalogue étendue fondée sur Products, Categories, Manufacturers, images, tarification, stock, options, attributs, champs personnalisés, reviews, Related Products, comparaison, wish lists, téléchargements, remises et tarification par groupe Customer. Ces fonctions peuvent servir aussi bien des catalogues standards que des boutiques ayant des exigences de merchandising plus détaillées.
La plateforme distingue les choix proposés à l’acheteur des informations descriptives. Les options Product peuvent représenter des sélections telles que taille ou couleur. Attributs et champs personnalisés peuvent contenir des spécifications ou informations complémentaires. Les onglets Product peuvent présenter documentation, pièces jointes ou vidéos. Cette distinction est importante car les données source utilisent souvent un même système de champs personnalisés pour plusieurs fonctions différentes.
Un Product EShop peut donc porter plusieurs types de sens :
- identité commerciale, notamment nom, SKU, Manufacturer, statut et affectation Category ;
- choix vendables, notamment options et valeurs d’option ;
- informations descriptives, notamment attributs, champs personnalisés, onglets et pièces jointes ;
- logique de prix, notamment prix normal, prix spécial, remises par quantité, classe fiscale ou prix par groupe Customer ;
- contexte de stock, notamment quantité, disponibilité, poids, dimensions et statut de stock ;
- signaux de découverte, notamment images, métadonnées, reviews, Related Products et comparaison.
Ces couches doivent rester distinguables dans la boutique cible. Une variante source ne signifie pas automatiquement une option EShop. Une spécification ne doit pas automatiquement aller dans une description. Une marque peut devenir une relation Manufacturer plutôt qu’un texte non structuré. L’orientation de migration est donc sémantique : préserver ce que l’information permet pour la vente, la découverte, l’administration et le choix client.
EShop prend également en charge des Categories imbriquées et des enregistrements Manufacturer. La profondeur Category peut influencer menus, filtrage, landing pages et parcours SEO. Les données Manufacturer peuvent soutenir la navigation et l’identité Product. La boutique cible doit exploiter ces structures volontairement plutôt que reproduire chaque classification de la source sans examiner sa finalité.
Customers, Orders et historique commercial
Les enregistrements Customer et Order constituent la couche historique de la boutique EShop. Ils aident les équipes à reconnaître les acheteurs, consulter des achats antérieurs, répondre aux demandes de service et comprendre le contexte des transactions. Leur valeur dépend des relations et d’une signification commerciale lisible, pas seulement du nombre d’enregistrements.
Les données Customer peuvent contenir noms, e-mails, adresses de facturation et d’expédition, groupes et informations personnalisées de la commande. Les comptes utilisateurs Joomla peuvent aussi influencer l’authentification et l’accès. La relation entre un Customer migré et un compte Joomla fonctionnel est donc une question opérationnelle distincte de la simple présence de l’enregistrement Customer.
Les Orders peuvent contenir Products, options sélectionnées, quantités, prix, remises, taxes, expédition, références de paiement, vouchers, coupons, commentaires, statut et informations d’adresse. Un Order historique utile doit permettre aux équipes de comprendre ce qui a été acheté et comment le total a été constitué. Des références source non prises en charge ou des champs détenus par une extension ne doivent pas être supposés compatibles avec le stockage Order standard.
| Couche historique | Ce que signifie la continuité | Ce qu’elle ne configure pas |
|---|---|---|
| Customers | Profils acheteurs reconnaissables, adresses, groupes et contexte de support | Comportement des mots de passe, règles d’accès Joomla ou tous les champs détenus par des extensions |
| Orders | Lignes lisibles, totaux, statuts, taxes, expédition, remises et contexte de paiement | Calcul futur des taxes, passerelles actives, plugins d’expédition ou processus e-mail |
| Reviews | Retours clients reliés aux Products lorsqu’ils sont pris en charge | Politique de modération, mise en page d’affichage ou services d’avis tiers |
| Coupons et vouchers | Enregistrements promotionnels pertinents et contexte historique lorsqu’ils sont pris en charge | Stratégie future de campagne ou toutes les règles promotionnelles héritées |
Cette frontière évite de prendre les données historiques pour le fonctionnement futur de la boutique. La boutique cible peut préserver un Order utilisant une méthode de paiement donnée sans installer ni configurer automatiquement cette passerelle pour les nouveaux Orders.
Checkout, fiscalité, expédition et paiements
EShop comprend un modèle de commande en une page, le guest commande, des champs de commande configurables, des champs personnalisés, des paramètres fiscaux, devises, méthodes d’expédition, plugins de paiement, notifications, factures et traitement des statuts Orders. Ces domaines forment la couche opérationnelle de la boutique.
Cette couche dépend avant tout de la configuration. Les enregistrements source peuvent informer les choix nécessaires, mais le fonctionnement futur appartient à EShop et aux plugins activés. Les taux de taxe peuvent dépendre de zones géographiques. L’expédition peut dépendre du prix, de l’article, du poids, de la quantité, du code postal, des services transporteur ou d’une logique personnalisée. Le paiement dépend des plugins installés et pris en charge, des identifiants, de la disponibilité régionale et des tests. Les champs de commande peuvent devoir être recréés selon les besoins actuels de collecte de données de la boutique cible.
Cette distinction est particulièrement importante pour les boutiques avec règles fiscales régionales, plusieurs devises, tarification par groupe Customer, questions de livraison personnalisées, calculs d’expédition spécifiques ou statuts Orders dépendant d’une passerelle. Ces exigences façonnent la boutique cible même lorsque Products, Customers et Orders sous-jacents migrent correctement.
La flexibilité opérationnelle d’EShop vient de la configuration et des plugins, pas du transfert des données à lui seul. Cette vue d’ensemble doit donc être comprise comme une cartographie des responsabilités : la migration préserve les enregistrements et relations pris en charge, tandis que la boutique cible doit établir les règles actives qui traiteront les transactions futures.
Storefront, contenu Joomla et découverte
Les pages de la vitrine EShop fonctionnent à l’intérieur du système de présentation Joomla. Products et Categories peuvent être affichés via des vues de composant, Menu Items, modules, recherche, filtres, articles Joomla ou layouts de template. EShop prend en charge différents modes de navigation et les overrides de template Joomla, ce qui rend la présentation très adaptable.
La continuité de la vitrine dépend donc de plus que la présence du catalogue. Les menus Joomla déterminent les points d’entrée. Les modules peuvent exposer recherche, filtres, Products, Manufacturers, accès à la commande ou contenu promotionnel. Templates et overrides déterminent hiérarchie visuelle et comportement responsive. Les aliases et le routage influencent les URL. Les associations linguistiques structurent la navigation multilingue. Les articles Joomla peuvent servir de guides d’achat, pages de marque, contenus de campagne ou informations complémentaires autour de la boutique.
Une boutique cible utile relie ainsi quatre systèmes de découverte :
- les structures EShop Categories et Manufacturer ;
- les menus et modules Joomla ;
- la recherche, les filtres, la comparaison et les Related Products ;
- les contenus et parcours SEO qui amènent les clients vers le catalogue.
Le multilingue et le multidevise ajoutent encore une couche. EShop peut contenir des contenus multilingues lorsque l’environnement de langues Joomla est configuré, tandis que le changement de devise influence l’affichage et les attentes transactionnelles. Les noms Product traduits, noms Category, métadonnées et routes doivent s’aligner sur la structure linguistique Joomla. Les enregistrements de devise et les règles de conversion appartiennent à la configuration cible et ne doivent pas être déduits des seuls prix source.
Extensions, intégrations et responsabilité personnalisée
EShop peut être étendu par des plugins de paiement et d’expédition, modules, fonctions d’import, overrides de template, intégrations et développement personnalisé. Cet écosystème permet d’adapter la boutique aux paiements locaux, règles transporteur, systèmes métier et besoins de vitrine spécialisés.
Le même écosystème crée des questions de responsabilité des données. Un plugin tiers peut écrire des champs supplémentaires dans Products ou Orders. Une intégration personnalisée peut dépendre d’identifiants internes. Une extension d’import peut créer des structures différentes des enregistrements créés manuellement. Un override de template peut attendre un champ qui n’existe que grâce à du code personnalisé.
Ces dépendances doivent être classées par fonction :
| Type de dépendance | Responsabilité habituelle |
|---|---|
| Données cœur EShop | Enregistrements e-commerce pris en charge et relations standard |
| Configuration EShop | Paramètres côté cible et fonctionnement cœur activé |
| Mise en œuvre Joomla | Menus, modules, templates, accès, contenus et configuration linguistique |
| Données d’extensions tierces | Enregistrements et relations propres à une extension |
| Données d’intégrations externes | Identifiants ERP, comptabilité, traitement logistique, marketing ou reporting |
| Comportement de code personnalisé | Logique métier à examiner indépendamment |
Un champ ne doit pas être préservé simplement parce qu’il existe. Il doit avoir une finalité définie dans la boutique cible, une destination de stockage, un responsable et un moyen de rester maintenable après lancement. Ce principe empêche la flexibilité d’EShop de devenir une réplication incontrôlée de l’héritage de la source.
Ce qui distingue une migration vers EShop
EShop se distingue parce qu’il associe un composant e-commerce complet à l’environnement Joomla plus large. Son identité de migration n’est ni celle d’une plateforme SaaS hébergée ni celle d’une application e-commerce autonome. La boutique cible résulte de l’assemblage entre enregistrements EShop, paramètres EShop, structure Joomla, extensions et infrastructure sous le contrôle du marchand.
Trois implications définissent la plateforme :
- Commerce et structure du site sont interdépendants. Les enregistrements Product et Order ne remplacent pas menus, modules, templates, contenus ou routage Joomla.
- Données historiques et fonctionnement actif appartiennent à des couches distinctes. Les anciens Orders et références de paiement ne configurent pas la commande, la fiscalité, l’expédition ou les passerelles futures.
- La responsabilité des extensions doit rester visible. Les champs créés par plugin, tables personnalisées et identifiants d’intégration ne peuvent pas être traités comme des données cœur ordinaires sans revue.
Pour les marchands qui souhaitent conserver Joomla comme fondation de leur site, EShop fournit une plateforme cible flexible avec contrôle direct du catalogue, de la configuration de la commande, du multilingue et de la présentation de la vitrine. Son utilisation réussie dépend du fait de reconnaître que la boutique est une mise en œuvre Joomla coordonnée, et non un simple jeu de données importé.
Conclusion
EShop by Ossolution Team est une plateforme e-commerce native de Joomla dont la valeur vient de la connexion entre des enregistrements de boutique structurés et le site Joomla qui les entoure. Products, Customers, Orders, Manufacturers, options, attributs, remises et reviews forment la couche de données ; taxes, expédition, paiement, commande, devises et e-mails forment la couche opérationnelle ; menus, modules, templates, structure linguistique, contenu et routage forment la couche vitrine.
Une migration vers EShop doit préserver le sens des données commerciales prises en charge tout en gardant ces couches distinctes. Cette orientation rend les étapes suivantes du hub plus précises : évaluation de l’adéquation, transposition du modèle de données, préparation, choix de l’approche de migration, validation et prévention des erreurs.
Questions fréquentes
EShop est-il une plateforme e-commerce hébergée autonome ?
Non. EShop s’installe comme extension Joomla et fonctionne à l’intérieur d’un site Joomla. Hébergement, maintenance Joomla, templates, modules, menus, plugins et responsabilités associées restent dans l’environnement du marchand.
Les options Product et les attributs sont-ils identiques dans EShop ?
Non. Les options représentent généralement des choix de l’acheteur, tandis que les attributs et champs personnalisés peuvent contenir des informations descriptives ou des spécifications. Les champs source doivent être classés selon leur fonction métier avant d’être affectés à une structure EShop.
Les Orders migrés configurent-ils le futur fonctionnement de la commande ?
Non. Les Orders historiques peuvent préserver le contexte des transactions, mais fiscalité, paiement, expédition, devises, statuts et notifications actifs dépendent de la configuration de la boutique cible et des plugins activés.
Le contenu Joomla appartient-il au catalogue EShop ?
Pas automatiquement. Les articles Joomla, menus, modules et autres contenus peuvent soutenir la découverte Product et l’éducation des clients, mais restent distincts des enregistrements Product et Category cœur d’EShop.
EShop peut-il prendre en charge des boutiques multilingues et multidevises ?
Oui. EShop prend en charge contenus multilingues et plusieurs devises, mais la boutique cible doit encore disposer d’une configuration linguistique Joomla cohérente, de contenus e-commerce traduits, d’une configuration de devises, d’un routage et d’une validation appropriés.
Les champs créés par des plugins font-ils automatiquement partie du périmètre standard de migration ?
Non. Les données tierces ou personnalisées doivent être identifiées par responsable et finalité. Les champs pris en charge peuvent être mis en correspondance ; les structures non standard peuvent nécessiter une revue et un traitement non standard distincts.