VirtueMart est une plateforme e-commerce Open-Source conçue comme une extension de Joomla. Elle associe une couche structurée d’administration de boutique aux contenus, utilisateurs, menus, modules, templates, langues, permissions et mécanismes d’extension de Joomla. Le marchand contrôle l’environnement d’hébergement et peut faire évoluer la boutique au moyen de plugins, modules, templates, champs personnalisés, surcharges et développements sur mesure.
Ce modèle d’exploitation fait de VirtueMart bien plus qu’une destination pour des enregistrements Product, Customer et Order. Une boutique migrée ne devient réellement exploitable que lorsque le catalogue VirtueMart, les structures d’acheteurs, les règles de calcul, les plugins de paiement et d’expédition ainsi que la couche de présentation Joomla fonctionnent ensemble. Un Product peut être complet dans l’interface d’administration alors que la boutique publique présente encore des routes cassées, des champs personnalisés qui ne fonctionnent plus comme prévu, des prix erronés pour certains groupes d’acheteurs ou des moyens de paiement et d’expédition indisponibles.
VirtueMart comme plateforme e-commerce native de Joomla
VirtueMart fonctionne à l’intérieur d’un site Joomla. Joomla fournit la base CMS et applicative, tandis que VirtueMart ajoute les enregistrements commerciaux et les structures de checkout nécessaires à l’exploitation d’une boutique en ligne.
| Couche opérationnelle | Rôle dans une boutique VirtueMart |
|---|---|
| Cœur Joomla | Gère les utilisateurs, groupes, permissions, menus, modules, templates, médias, langues, e-mails et l’administration des extensions. |
| Composant VirtueMart | Gère les Products, catégories, fabricants, stocks, acheteurs, Orders, coupons, champs personnalisés, taxes, devises, moyens de paiement et méthodes d’expédition. |
| Plugins | Étendent le paiement, l’expédition, les champs personnalisés, les calculs, la recherche, les intégrations et d’autres fonctions spécialisées. |
| Modules et menus | Exposent les catégories, Products, la recherche, les devises, la connexion, le panier et d’autres fonctions de la vitrine. |
| Templates et surcharges | Contrôlent le rendu de la vitrine et peuvent personnaliser le fonctionnement des vues VirtueMart. |
| Hébergement et exploitation | Déterminent les performances, la compatibilité, les mises à jour, la sécurité, les sauvegardes, la supervision et la récupération. |
Cette séparation est essentielle pour planifier une migration. Certaines informations sont des données migrables. D’autres fonctions relèvent de la configuration de la cible. Certains enregistrements provenant de champs personnalisés ou de plugins peuvent nécessiter un périmètre supplémentaire. Certaines personnalisations héritées gagneront parfois à être reconstruites plutôt qu’à être transférées.
Structure des produits, variantes et champs personnalisés
VirtueMart prend en charge les Products, catégories, fabricants, stocks, médias, avis, Products associés, Products enfants et un système très extensible de champs personnalisés. Ces champs peuvent décrire les Products, proposer des choix sélectionnables, produire un fonctionnement proche des variantes, modifier les prix ou relier un Product à un plugin.
Cette souplesse est l’une des caractéristiques principales de VirtueMart. Elle crée également une frontière importante pour la migration, car une plateforme source peut représenter le même besoin métier au moyen de variantes, options, modificateurs, attributs, add-ons, bundles ou enregistrements personnalisés.
| Concept produit | Importance pour une migration vers VirtueMart |
|---|---|
| Products parents et enfants | Peuvent représenter des relations de variantes ou de familles qui doivent conserver identifiants, prix, stocks et fonctionnement d’affichage. |
| Champs personnalisés | Peuvent être descriptifs, sélectionnables, tarifés, pilotés par un plugin ou utilisés pour construire des relations entre Products. |
| Stock | Peut inclure la quantité disponible, la disponibilité, les règles de stock faible, les règles de commande et des relations au niveau du Product. |
| Médias Product | Exigent les fichiers, les associations, l’ordre, les miniatures et la validation de l’affichage. |
| Catégories et fabricants | Influencent l’organisation, la navigation, les filtres, les relations Product et les parcours SEO. |
| Avis et notes | Nécessitent de valider les relations et l’état de publication, pas seulement le nombre d’enregistrements. |
Une migration réussie doit donc préserver le modèle d’achat prévu. La cible doit reproduire les choix effectués par les Customers, les prix et stocks déclenchés par ces choix ainsi que le sens des lignes enregistré dans les nouveaux Orders.
Identité des acheteurs, groupes d’acheteurs et accès
VirtueMart utilise les notions d’acheteur et de groupe d’acheteurs. Les enregistrements d’acheteurs sont reliés aux utilisateurs Joomla, mais peuvent également contenir des champs propres à la boutique, des adresses, des préférences, des droits tarifaires, des règles fiscales, des restrictions sur les moyens de paiement ou les méthodes d’expédition, ainsi que d’autres éléments de contexte commercial.
Les groupes d’acheteurs peuvent influencer davantage que la segmentation. Ils peuvent modifier les prix, la visibilité des Products, les règles fiscales, les remises, les moyens de paiement, les méthodes d’expédition et les conditions du checkout.
Une migration doit donc distinguer :
- l’identité utilisateur dans Joomla ;
- les informations d’acheteur propres à VirtueMart ;
- les adresses de facturation et d’expédition ;
- les champs d’acheteur ;
- l’appartenance aux groupes d’acheteurs ;
- les prix propres à ces groupes ;
- la propriété des Orders historiques ;
- les règles d’accès et d’autorisation de la cible.
Ces relations sont importantes parce qu’un compte Customer peut être techniquement présent tout en étant commercialement incorrect. Un acheteur B2B affecté au mauvais groupe peut voir les prix de détail. Un acheteur exonéré de taxe peut être taxé. Un moyen de paiement réservé à un groupe peut disparaître de façon inattendue.
Orders et historique commercial
Les Orders VirtueMart peuvent contenir les informations sur l’acheteur, les adresses, les lignes de commande, taxes, remises, valeurs de coupons, références de paiement et d’expédition, changements de statut, notes, devises et totaux. La plateforme prend également en charge des statuts Order configurables et la gestion administrative des Orders.
La migration des Orders historiques et le fonctionnement du checkout en production doivent être évalués séparément.
Les Orders historiques restent utiles lorsqu’ils demeurent lisibles et reliés au bon acheteur, aux bons Products, adresses, totaux, statuts et contextes de devise. Le checkout en production dépend des règles et plugins actuellement configurés dans la cible, notamment :
- les règles fiscales et de calcul ;
- les pays et régions ;
- les groupes d’acheteurs ;
- les moyens de paiement ;
- les méthodes d’expédition ;
- les coupons et remises ;
- les devises et règles de conversion ;
- la configuration des e-mails et notifications.
Cette distinction évite de considérer la cible comme prête simplement parce que les anciens Orders sont visibles.
Règles de calcul, taxes, remises et tarification
VirtueMart comprend des règles de calcul pouvant agir sur les taxes, remises, prix et autres mécanismes commerciaux. Selon l’implémentation, ces règles peuvent être conditionnées par les Products, catégories, groupes d’acheteurs, pays, régions, fabricants, périodes ou d’autres critères.
Une plateforme source peut enregistrer une taxe ou une remise comme un simple champ, alors que VirtueMart calcule le résultat au moyen de plusieurs couches de configuration reliées. À l’inverse, la source peut disposer d’une logique tarifaire gérée par une application qui ne correspond pas directement au modèle de règles natif de VirtueMart.
Pour la migration, cela signifie que les montants historiques et le comportement des calculs en production ne constituent pas le même actif. Les Orders historiques doivent conserver les totaux enregistrés. Le nouveau fonctionnement du checkout doit être configuré et testé dans la cible.
À l’échelle de cette présentation, VirtueMart doit donc être compris comme un environnement e-commerce piloté par des règles, et non comme un simple ensemble de tables Product et Order.
Plugins de paiement et d’expédition
VirtueMart utilise des plugins et des configurations de méthode pour le paiement et l’expédition. Une méthode peut dépendre de la devise, du pays, du groupe d’acheteurs, du montant de l’Order, de caractéristiques Product, du poids d’expédition, de l’adresse, d’identifiants d’accès ou d’exigences propres à une passerelle externe.
Une migration peut préserver les noms de moyens de paiement ou d’expédition dans les Orders historiques tout en nécessitant une nouvelle configuration côté cible pour les transactions futures. Les identifiants, endpoints de webhook, comptes marchands, intégrations transporteur, étiquettes, interactions fiscales et compatibilité des extensions relèvent de l’exploitation de la cible.
Cette distinction devient particulièrement importante lorsque la source utilise une extension de paiement ou de traitement logistique sans équivalent dans la cible. Le marchand peut devoir choisir une autre méthode, revoir le processus ou demander un traitement non standard pour les enregistrements qui doivent être transformés.
Exploitation multilingue et multidevise
VirtueMart fonctionne dans le cadre multilingue de Joomla et prend en charge la configuration des devises. Les boutiques internationales peuvent dépendre de contenus Product et de catégories traduits, de routes propres aux langues, de structures de menus, de modules, devises, affichages de prix, taxes, pays, régions et disponibilités des moyens de paiement.
Une migration multilingue doit préserver les relations, pas seulement les chaînes traduites. Un Product traduit mais mal relié à la langue, au menu, à la catégorie ou à la route appropriée peut devenir inaccessible. Une structure de catégories multilingue peut également affecter les métadonnées et les redirections.
Le fonctionnement multidevise peut inclure la devise de base, la devise de l’acheteur, les paramètres d’affichage, la conversion, les arrondis, la présentation des taxes et les restrictions de certaines passerelles. Ces relations doivent être distinguées de la migration des montants historiques déjà enregistrés.
Menus Joomla, modules, templates et routes
Les pages de la vitrine VirtueMart sont assemblées à l’intérieur de Joomla. Les menus créent le contexte de routage et les points d’entrée. Les modules peuvent afficher des Products, catégories, fonctions de recherche, contenu du panier, connexion, sélection de devise ou zones promotionnelles. Les templates et surcharges contrôlent le rendu visuel et peuvent modifier le fonctionnement des vues VirtueMart.
Un Product migré peut donc exister sans être découvrable ni correctement présenté.
Les dépendances courantes de la vitrine comprennent :
- les éléments de menu pour les catégories et Products ;
- les alias et routes SEF ;
- les menus propres aux différentes langues ;
- les modules Product et catégorie ;
- les modules de panier et de connexion ;
- les positions de template ;
- les surcharges des vues VirtueMart ;
- les extensions de recherche et de filtrage ;
- les métadonnées, règles canoniques et redirections.
Ces dépendances ne sont pas de simples champs Product. Elles appartiennent à la couche d’implémentation Joomla et doivent être gouvernées séparément du jeu de données migré.
Extensions, champs personnalisés et développements sur mesure
VirtueMart dispose d’un vaste écosystème d’extensions. Une boutique peut utiliser des plugins de paiement ou d’expédition tiers, des extensions de checkout en une page, des constructeurs de Products, des plugins de champs personnalisés, des fonctions marketplace, abonnements, facturation, flux produits, outils d’analyse, intégrations ERP ou composants sur mesure.
Cette diversité crée de fortes différences entre installations. Le nom de la plateforme ne suffit pas à révéler le modèle de données complet.
Le projet doit identifier :
- quels enregistrements appartiennent au cœur de VirtueMart ;
- quels enregistrements appartiennent au cœur de Joomla ;
- quels champs personnalisés relèvent des données natives et lesquels dépendent de plugins ;
- quelles extensions créent des tables distinctes ou des enregistrements externes ;
- quelles fonctions doivent être recréées dans la cible ;
- quelles intégrations doivent être reconnectées ou repensées.
Les mises en correspondance prises en charge ou les ajustements de configuration peuvent couvrir des besoins bornés de filtrage, de correspondance ou de configuration. Un traitement non standard peut devenir nécessaire pour les données d’extensions non prises en charge, les tables personnalisées, la logique Product sur mesure, les identifiants de systèmes externes ou les besoins de transformation personnalisée.
API, import, export et contexte d’accès
VirtueMart fournit des contextes administratifs, d’extension et d’API pouvant servir aux intégrations et aux échanges de données. Certaines boutiques reposent également sur des extensions d’import/export tierces ou sur un accès personnalisé à la base de données.
La méthode d’accès utilisable dépend de la plateforme source, de la plateforme cible et de la configuration exacte des boutiques. La source et la cible peuvent nécessiter des méthodes différentes, et une connexion réussie ne prouve pas que les champs appartenant à des extensions ou les tables personnalisées sont inclus.
La méthode d’accès et l’exhaustivité des données doivent être évaluées séparément. Une connexion API réussie ne prouve pas que les champs gérés par des plugins ou les tables personnalisées sont inclus. Un fichier d’export ne prouve pas que toutes les relations entre acheteurs, Orders, champs personnalisés ou extensions sont présentes.
Version, compatibilité Joomla et responsabilité de maintenance
VirtueMart reste activement développé, et le choix de version est lié à la compatibilité avec Joomla. Les informations officielles du projet indiquent VirtueMart 4 comme branche stable pour Joomla 3.10, Joomla 4 et Joomla 5, tandis que VirtueMart 5 est en phase de test bêta et fonctionne déjà avec Joomla 6.
La version cible exacte est importante, car la version de Joomla, la version de PHP, la compatibilité de la base de données, les extensions, templates, plugins, surcharges et développements personnalisés doivent fonctionner ensemble. Un marchand ne doit pas considérer « VirtueMart » comme un environnement unique et immuable.
Une cible VirtueMart gérée par le marchand exige également une responsabilité claire pour :
- les mises à jour de Joomla et VirtueMart ;
- la compatibilité des plugins et templates ;
- les correctifs de sécurité ;
- l’hébergement et les performances ;
- les sauvegardes et tests de restauration ;
- la supervision et la gestion des incidents ;
- le staging et le contrôle des mises en production ;
- les licences d’extensions et le support des fournisseurs.
Ces responsabilités influencent la capacité des données migrées à rester opérationnelles après le lancement.
Comment VirtueMart réoriente la migration
VirtueMart modifie l’orientation de la migration dans cinq domaines :
| Domaine | Question centrale |
|---|---|
| Sens des Products | Comment les variantes, options, attributs, bundles et données personnalisées de la source deviendront-ils des Products, Products enfants et champs personnalisés VirtueMart ? |
| Sens des acheteurs | Comment les Customers seront-ils reliés aux utilisateurs Joomla, champs d’acheteurs, groupes d’acheteurs, prix, taxes et règles d’accès ? |
| Règles commerciales | Quels prix, règles fiscales, remises, moyens de paiement et méthodes d’expédition sont des données, et lesquels relèvent de la configuration de la cible ? |
| Vitrine Joomla | Quels menus, modules, templates, surcharges, langues, routes et contrôles SEO rendent la boutique utilisable ? |
| Propriété des extensions | Quels plugins, champs personnalisés, tables personnalisées et intégrations se situent hors des enregistrements Standard pris en charge ? |
Une migration solide commence par ces frontières. Les autres articles du hub peuvent ensuite évaluer l’adéquation du marchand, les différences de modèle de données, les risques structurels, la préparation, le choix du service, la validation et les pièges sans transformer cette présentation en checklist procédurale.
Carte des relations avec d’autres plateformes
VirtueMart appartient à l’écosystème e-commerce Joomla, tout en conservant son propre schéma commercial et son propre modèle d’extensions.
| Type de plateforme associée | Relation pertinente |
|---|---|
| Joomla | Fournit le CMS, les utilisateurs, permissions, langues, menus, modules, templates, médias et le cadre d’extension. |
| Phoca Cart | Partage la base Joomla mais utilise un autre modèle de Products, options, tarification, Customers, Orders et plugins. |
| J2Commerce | Partage l’environnement Joomla mais repose sur des relations Product centrées sur les Articles et une architecture de versions distincte. |
| WooCommerce | Propose un autre modèle e-commerce relié à un CMS, sur WordPress, avec des structures Product, utilisateur, plugin, URL et contenu différentes. |
| Commerce Open-Source autonome | Partage l’auto-hébergement et l’extensibilité, mais place le commerce au cœur de la plateforme. |
| Commerce SaaS hébergé | Réduit la responsabilité d’infrastructure tout en imposant davantage de frontières de données et de checkout définies par la plateforme. |
La base Joomla commune peut faciliter certaines habitudes au niveau du site, mais elle ne transforme pas une migration entre extensions e-commerce Joomla en transfert direct de schéma.
Conclusion
VirtueMart est une plateforme e-commerce native de Joomla dont le modèle d’exploitation associe Products, champs personnalisés, acheteurs, groupes d’acheteurs, Orders, règles de calcul, plugins de paiement et d’expédition, devises, langues et une vitrine contrôlée par Joomla. Sa flexibilité vient du contrôle Open-Source et de son extensibilité, mais cette même flexibilité crée des frontières de données et de configuration propres à chaque implémentation.
Une migration réussit uniquement lorsque la cible préserve le sens commercial et met en place l’environnement opérationnel qui l’entoure. Les enregistrements Product doivent conserver les choix et relations que les Customers achètent. Les enregistrements d’acheteurs doivent conserver le contexte de groupe et de compte qui détermine les prix ou l’accès. Les Orders historiques doivent rester lisibles, tandis que le nouveau checkout doit être configuré et testé séparément. Les menus, modules, templates, routes et extensions Joomla doivent rendre le catalogue migré réellement utilisable.
Cette compréhension de la plateforme fournit une base claire aux autres articles du hub, consacrés à l’adéquation, au modèle de données, aux contraintes, à la préparation, au choix de l’approche de migration, à la validation et à la prévention des pièges.
Questions fréquentes
VirtueMart est-il une plateforme e-commerce autonome ?
VirtueMart est une extension e-commerce Open-Source pour Joomla. La boutique fonctionne dans un site Joomla et dépend de Joomla pour les utilisateurs, menus, modules, templates, langues, permissions, médias et gestion des extensions.
Pourquoi les champs personnalisés VirtueMart sont-ils importants pour la migration ?
Ils peuvent décrire les Products, créer des choix sélectionnables, modifier les prix, prendre en charge des relations proches des variantes ou dépendre de plugins. Leur rôle doit être compris avant de pouvoir les mettre en correspondance correctement.
Les groupes d’acheteurs influencent-ils autre chose que la segmentation des Customers ?
Oui. Ils peuvent affecter les prix, taxes, remises, visibilité des Products, moyens de paiement, méthodes d’expédition et conditions de checkout. Il faut valider ensemble l’appartenance au groupe et les règles commerciales qui en dépendent.
Migrer les Orders historiques prouve-t-il que le checkout est prêt ?
Non. Les Orders historiques peuvent préserver les données enregistrées, tandis que le checkout en production dépend encore des plugins de paiement et d’expédition, règles fiscales, coupons, devises, identifiants et configurations actuelles de la cible.
Les menus et templates Joomla sont-ils migrés avec les Products VirtueMart ?
Pas automatiquement dans le cadre d’une migration Product standard. Les menus, modules, templates, surcharges, routes et affectations de langue appartiennent à la couche d’implémentation Joomla et peuvent nécessiter une configuration ou une reconstruction séparée.
Quand un traitement non standard peut-il être nécessaire pour VirtueMart ?
Il peut être nécessaire pour des données d’extensions non prises en charge, des champs personnalisés pilotés par plugin, des tables sur mesure, une logique Product spécifique, des identifiants de systèmes externes, des transformations particulières ou un comportement de migration personnalisé hors du périmètre Standard pris en charge.