osCommerce couvre aujourd’hui deux générations de données sensiblement différentes. La version actuelle osCommerce v4 propose plusieurs front ends ou canaux de vente, des Products configurables, des groupes de clients, des attributs Products, des propriétés Products, des marques, une gestion CMS, des thèmes, des Apps et des fonctions de tarification avancées. Pourtant, de nombreuses boutiques source fonctionnent encore sur des bases dérivées de versions 2.x plus anciennes ou sur des installations fortement modifiées dont les extensions et les structures de tables ne correspondent pas au modèle v4.
Cette filiation constitue la première décision de modélisation. Un enregistrement products_attributesprovenant d’une ancienne boutique n’est pas automatiquement équivalent à un attribut, une propriété ou une relation de Product configurable dans la v4 actuelle. Une table ajoutée par une ancienne extension peut contenir du stock, des données fournisseur, des bons, du SEO ou des informations Orders qu’osCommerce v4 représente ailleurs. Un Product v4 actuel peut également être affecté à des canaux de vente et à des groupes de clients, relations qui n’existent pas de la même manière dans les anciennes installations.
La préparation de la migration doit donc identifier à quelle génération d’osCommerce appartient chaque enregistrement de la plateforme source, ce qu’il représente commercialement et quelles entités associées doivent rester reliées dans la boutique cible.
L’historique des versions constitue une frontière du modèle de données osCommerce
Une boutique osCommerce v4 actuelle et une ancienne boutique osCommerce ne doivent pas être traitées comme si elles partageaient un schéma uniforme. La v4 est une plateforme Open-Source actuelle avec plusieurs front ends, une gestion CMS, des Products configurables, des thèmes, des Apps et un modèle d’administration plus récent. Les anciennes boutiques 2.x utilisent fréquemment des extensions directes de tables, des modules installés manuellement, des fichiers PHP modifiés et des contributions communautaires.
La boutique source peut aussi avoir traversé plusieurs mises à niveau ou forks. Les noms de tables peuvent sembler familiers alors que les définitions de champs et les relations ont changé. L’historique des versions détermine donc si une option Product, un groupe de clients, un canal de vente, une page de contenu ou un enregistrement d’extension possède un équivalent natif dans la version cible actuelle.
| Élément observé dans la source | Interprétation osCommerce | Conséquence pour la migration |
|---|---|---|
| Enregistrements Products et affectations d’une v4 actuelle | Modèle de catalogue osCommerce moderne | Conserver les Products, Categories, marques, attributs, propriétés, canaux et liens avec les groupes de clients. |
| Tables principales d’une ancienne 2.x | Ancien modèle d’enregistrements osCommerce | Interpréter les relations selon le modèle historique plutôt qu’à travers les seuls libellés v4 actuels. |
| Tables ou colonnes ajoutées par une extension communautaire | Données appartenant à une extension | Identifier l’extension et l’enregistrement principal qu’elle modifie. |
| PHP et SQL modifiés | Règle métier ou schéma personnalisé | Transposer le sens métier plutôt que copier l’ancien mécanisme. |
| Boutique issue d’un fork | Filiation de plateforme proche mais non identique | Confirmer les définitions d’entités et les identifiants à partir de l’installation réelle. |
| Clé d’un système externe | Identifiant ERP, PIM, WMS, marketplace, comptabilité ou traitement logistique | Préserver l’identité durable utilisée entre systèmes. |
Cette distinction évite de construire le modèle cible moderne à partir d’hypothèses valables uniquement pour une ancienne installation source.
Products, Categories, marques et canaux de vente sont liés mais distincts
Dans osCommerce v4, un Product peut porter son identité principale, ses descriptions, identifiants, prix et coûts, sa fiscalité, son mode de stock, ses images, vidéos, paramètres d’emballage, options de Product virtuel ou téléchargeable, données SEO, fournisseurs, notes et relations marketing. Les Products peuvent être affectés ou limités à certains canaux de vente et groupes de clients. Les Categories peuvent elles aussi être affectées à des front ends et groupes de clients précis.
Il ne s’agit donc pas seulement d’une hiérarchie Product-vers-Category. Un même Product peut être partagé entre plusieurs front ends avec une visibilité, des contenus, une tarification ou un contexte commercial différents. Une installation source multiboutique qui duplique les Products peut parfois être mieux représentée par une seule identité Product associée à plusieurs canaux ; dans un autre cas, plusieurs Products restent nécessaires parce que leur identité commerciale diffère réellement.
| Structure de la source | Propriétaire dans osCommerce v4 | Relation à préserver |
|---|---|---|
| Article vendable de référence | Product | Identité, identifiants, prix, stock, médias, fiscalité et descriptions. |
| Hiérarchie de navigation | Category et affectation Product | Arborescence des Categories et placement plusieurs-à-plusieurs des Products. |
| Marque ou fabricant | Relation marque ou fournisseur | L’identité de marque reste distincte du classement par Category. |
| Boutique régionale ou de marque | Front end ou canal de vente | Disponibilité des Products et Categories par canal. |
| Catalogue réservé à certains acheteurs | Affectation Product/Category au groupe de clients | La visibilité et la disponibilité restent liées au groupe prévu. |
| Merchandising associé | XSell, UPSell, groupe de Products ou relation entre Products | Les liens commerciaux restent distincts de l’appartenance à une Category. |
Le nombre de Products migrés indique peu de choses si le bon front end, la bonne Category, le bon groupe de clients ou la bonne marque n’est plus relié au Product.
Les attributs, propriétés, Products configurables et groupes de Products remplissent des rôles différents
osCommerce v4 distingue les attributs des propriétés. Les attributs peuvent définir des valeurs sélectionnables, utiliser des modèles, modifier le prix ou le poids, gérer des fichiers virtuels ou téléchargeables et participer au stock du Product. Les propriétés décrivent les caractéristiques du Product et peuvent servir à l’affichage, au filtrage, à la recherche, à la comparaison, aux groupes de Products, aux icônes, aux nuanciers, aux plages de valeurs et aux données structurées.
Une option source doit donc être classée selon son fonctionnement. Si l’acheteur choisit une valeur qui modifie l’article acheté, cette valeur appartient à la couche des attributs ou du Product configurable. Si elle décrit le Product pour la recherche ou la comparaison, elle relève plutôt des propriétés. Si elle sert à regrouper des Products pour le merchandising ou pour des caractéristiques communes, une relation de groupe de Products peut être plus adaptée.
| Sens dans la source | Structure osCommerce à envisager | Frontière de relation |
|---|---|---|
| Choix de taille ou de couleur | Attribut et valeur affectée | Product, choix, effet sur prix/poids et valeur sélectionnée sur la ligne Order. |
| Combinaison avec stock indépendant | Product configurable ou relation attribut-stock | Identité enfant/combinaison, quantité, SKU et disponibilité. |
| Caractéristique technique | Catégorie de propriété, propriété et valeur | Le fait structuré reste distinct d’un choix d’achat. |
| Plage filtrable | Propriété affichée dans les filtres/recherche | Type, unité, plage et valeurs Product restent normalisés. |
| Jeu d’options réutilisable | Modèle d’attribut | Les définitions restent réutilisables entre les Products concernés. |
| Famille de Products ou ensemble de comparaison | Groupe de Products ou relation entre Products | Le sens du groupe reste distinct de la hiérarchie des Categories. |
| Fichier numérique | Product virtuel/téléchargeable et relation attribut/fichier | Fichier, expiration, limite de téléchargement, Product et contexte Order. |
Les attributs d’anciennes versions d’osCommerce peuvent devoir être réinterprétés selon ces rôles modernes. Conserver simplement l’ancien nom de champ sans comprendre son fonctionnement peut transformer une combinaison réellement vendable en valeur de filtre, ou une spécification descriptive en option porteuse de stock.
Stock, prix, fournisseurs, canaux et groupes de clients forment un réseau commercial
Les Products v4 actuels peuvent inclure un stock réel ou d’autres modes de stock, le coût fournisseur, des remises quantitatives, un prix conseillé, une classe fiscale, la disponibilité par canal, les affectations aux groupes de clients et des restrictions propres à ces groupes. D’autres Apps peuvent étendre les fonctions de gros, marketplace, retail ou entreprise.
Ces relations doivent être modélisées comme un réseau plutôt que réduites à de simples colonnes du Product. Un prix source peut appartenir à un groupe de clients, un seuil de quantité, un coût fournisseur, un canal, une devise ou une promotion. Une quantité de stock peut appartenir à un Product, une combinaison d’attributs, un emplacement ou un entrepôt externe. Un code fournisseur peut être un champ interne du Product ou une clé vers un enregistrement externe d’approvisionnement.
| Valeur commerciale | Propriétaire et relation | Sens à conserver |
|---|---|---|
| Prix de vente de base | Product et devise | Valeur commerciale par défaut. |
| Visibilité par groupe de clients | Affectation Product/Category au groupe | Accès de l’acheteur à l’objet du catalogue. |
| Prix par groupe ou prix de gros | Product, groupe de clients et règle tarifaire | Public visé et montant applicable. |
| Remise quantitative | Product et relation avec un seuil | Seuils de quantité et effet sur le prix. |
| Coût fournisseur | Relation Product-vers-fournisseur | Responsable de l’approvisionnement, coût, devise et clé fournisseur. |
| Disponibilité par canal | Relation Product/Category-vers-front end | Où l’article est proposé. |
| Quantité en stock | Product ou combinaison configurable et propriétaire du stock | Identité vendable et quantité faisant autorité. |
Les prix historiques des Orders doivent rester des instantanés de la transaction. Ils ne doivent pas être recalculés d’après le groupe de clients, le canal ou le prix Product actuel après la migration.
Customers, groupes de clients, adresses et autorisations ont des sens différents
Les groupes de clients d’osCommerce v4 peuvent contrôler la visibilité de Products et Categories, l’application de la fiscalité, des remises cumulées ainsi que le traitement par défaut des visiteurs ou des nouveaux acheteurs inscrits. Les enregistrements Customers sont aussi reliés aux adresses, aux Orders, aux données de communication et potentiellement à des Apps qui gèrent le commerce de gros, le crédit, la fidélité, les marketplaces ou des structures B2B.
Un segment source doit être interprété selon sa fonction. Un indicateur d’exonération fiscale, un segment marketing, un compte de gros, une relation d’entreprise et un niveau de fidélité ne constituent pas nécessairement un seul groupe de clients. Certains éléments appartiennent aux paramètres natifs de groupe, d’autres à une App et d’autres encore à un CRM ou ERP externe.
| Concept de compte source | Propriétaire osCommerce à envisager | Relation à préserver |
|---|---|---|
| Acheteur individuel | Compte Customer et carnet d’adresses | Identité, connexion, adresses et Orders. |
| Acheteur invité | Instantané Customer au niveau de l’Order | Identité historique sans créer artificiellement un compte persistant. |
| Niveau retail ou de gros | Groupe de clients et règles associées de catalogue/prix | Appartenance plus effets sur visibilité, remise et fiscalité. |
| Statut d’exonération fiscale | Paramètre de groupe ou champ dédié Customer/App | Le sens juridique ou commercial reste explicite. |
| Compte d’entreprise ou professionnel | App de gros/B2B ou entité de compte externe | Plusieurs utilisateurs et règles commerciales restent reliés. |
| Administrateur ou membre du personnel | Utilisateur back-office et autorisations | Les accès internes restent séparés de la segmentation Customers. |
| ID CRM/ERP | Identifiant externe | Clé stable de reconnexion. |
Le seul libellé d’un groupe ne suffit pas lorsque des Prices, Products, Categories, taxes ou conditions de paiement en dépendent.
Les Orders conservent l’instantané de la transaction à travers plusieurs enregistrements liés
Les Orders osCommerce peuvent inclure l’identité du Customer ou du visiteur, les adresses de facturation et de livraison, les instantanés Products et attributs, les quantités, prix, remises, taxes, frais de livraison, informations de paiement, statuts Orders, commentaires, transactions, expéditions, remboursements, retours, factures et enregistrements appartenant à des extensions. L’administration v4 actuelle peut aussi gérer les Orders créés manuellement et l’historique Customer associé.
La migration des Orders doit conserver la transaction historique, et non essayer de la reconstituer à partir de la configuration actuelle du Product ou du Customer. Un Product peut avoir changé de nom ou de prix. Un Customer peut avoir changé de groupe. Un module de paiement peut avoir été remplacé. L’Order reste exploitable si ses propres lignes, totaux, adresses, statuts et références expliquent ce qui s’est réellement produit.
| Élément de l’Order | Propriétaire historique | Sens à conserver |
|---|---|---|
| Ligne Product | Instantané Product de l’Order | Nom/SKU, quantité, attributs sélectionnés et prix au moment de l’achat. |
| Adresse de facturation/livraison | Instantané de l’Order | Adresse historique indépendante du carnet d’adresses Customer actuel. |
| Montant remise/taxe/livraison | Total ou ajustement de l’Order | Libellé, montant, ordre et contribution au total final. |
| Référence de paiement | Transaction ou enregistrement du module de paiement | Élément historique permettant le rapprochement. |
| Statut Order et commentaires | Historique de l’Order | Séquence des états, date, visibilité et explication. |
| Expédition/suivi | Enregistrement d’expédition ou de traitement logistique | Transporteur, méthode, suivi et articles expédiés lorsqu’ils sont représentés. |
| Remboursement/retour | Enregistrement après-vente associé | Montant, lignes concernées, motif et statut. |
La boutique cible peut utiliser de nouvelles configurations de paiement et de livraison tout en conservant les libellés et références rattachés aux Orders historiques.
CMS, front ends, thèmes, URL et contenus du catalogue ont des propriétaires distincts
osCommerce v4 comprend une gestion CMS, plusieurs front ends, des thèmes, un éditeur visuel de thèmes, des contenus Products et Categories, des paramètres SEO, des images, des vidéos et des valeurs propres aux langues. Les anciennes installations peuvent utiliser des extensions de pages d’information, des pages PHP statiques, des blocs de modèles, des fichiers de langue ou des contributions SEO.
Ces éléments visibles doivent être séparés entre contenus, routes, canaux et présentation. Une description Product appartient au Product. Une CMS Page possède sa propre identité et sa propre route. Une description de Category appartient à la Category. Un élément de menu ou un placement dans un front end contrôle la navigation. Un thème ou un modèle définit la présentation. Une redirection relie une ancienne route à une nouvelle destination.
| Élément source | Propriétaire cible | Conséquence sur le modèle de données |
|---|---|---|
| Description Product/Category | Entité du catalogue | Conserver le contenu avec la bonne entité et la bonne langue. |
| Page d’information ou de politique | CMS Page | Préserver l’identité de la page, sa route, sa hiérarchie et sa visibilité. |
| Contenu propre à un front end | Enregistrement CMS/contenu plus affectation au canal | Garder le contenu relié au bon contexte de canal. |
| Menu ou nœud de navigation | Configuration de navigation | La présence du contenu ne recrée pas automatiquement son emplacement. |
| Bloc de thème ou élément de modèle | Couche de présentation | Reconstruire la mise en page séparément du contenu sous-jacent. |
| Image/vidéo Product | Relation média du Product | Préserver l’identité du média, son ordre, sa langue et son lien avec le Product. |
| URL historique | Route de l’entité et redirection | Maintenir la relation entre l’ancien chemin et la nouvelle destination. |
Cette séparation est particulièrement importante lorsqu’une ancienne boutique 2.x, dont une partie du contenu est intégrée aux modèles ou aux extensions, migre vers les structures CMS et front ends actuelles de la v4.
Apps, anciennes extensions, tables personnalisées et systèmes externes étendent osCommerce
osCommerce v4 utilise App Shop et propose des Apps pour les paiements, la livraison, le marketing, le commerce de gros, les marketplaces, la comptabilité et d’autres fonctions. Les anciennes boutiques emploient souvent des extensions installées manuellement qui modifient les fichiers principaux et les tables de base de données. Dans les deux cas, des enregistrements peuvent exister en dehors du schéma natif du catalogue et des Orders.
| Propriétaire des données | Exemples d’enregistrements | Décision de transposition |
|---|---|---|
| Noyau osCommerce | Products, Categories, marques, attributs, propriétés, Customers, Orders, CMS | Mapper selon les relations natives entre données. |
| App v4 | Champs d’App, entités, transactions, offres de marketplace, règles de gros | Les conserver avec l’App ou avec un autre propriétaire cible explicitement défini. |
| Ancienne extension | Colonnes ajoutées, tables, statuts, bons, SEO, stock, rapports | Identifier l’extension et les enregistrements principaux qu’elle modifie. |
| Code personnalisé | Tables, workflows ou calculs spécifiques | Transposer le sens métier plutôt que l’ancienne structure de code. |
| Service externe | Taxes, paiement, livraison, recherche, marketplace, outils d’analyse | Conserver les références historiques et les clés de connexion actives. |
| ERP/PIM/WMS/CRM | Identifiants maîtres Products, Customers, stock, fournisseurs et Orders | Préserver les identifiants durables et la source faisant autorité. |
Un champ provenant d’une ancienne extension n’est pas automatiquement équivalent à un champ d’App v4. De même, le nom d’une App actuelle ne garantit pas que les données d’une ancienne extension utilisent le même schéma ou portent le même sens métier. La frontière de migration doit être définie en examinant les enregistrements concernés.
Les décisions de transposition osCommerce doivent suivre le sens métier
| Motif dans la source | Bonne question à poser pour la transposition | Conséquence d’une mauvaise hypothèse |
|---|---|---|
| Matrice d’options héritée | S’agit-il d’un attribut natif, d’une relation de Product configurable ou d’une combinaison de stock appartenant à une extension ? | Le SKU enfant, le stock, le prix ou les valeurs sélectionnées sont perdus. |
| Champ descriptif Product | Doit-il devenir une propriété v4, du contenu, une marque, un fournisseur ou appartenir à un PIM externe ? | La recherche et la comparaison deviennent incohérentes. |
| Product dupliqué entre plusieurs boutiques | S’agit-il d’un seul Product affecté à plusieurs canaux ou de plusieurs identités commerciales réellement distinctes ? | Le stock et le SEO sont inutilement fragmentés ou les différences régionales sont écrasées. |
| Groupe de clients | Quelles relations de visibilité, remise, fiscalité ou tarification en dépendent ? | Le libellé du segment subsiste mais son effet commercial disparaît. |
| Total Order issu d’un ancien module | Quel montant historique et quel libellé doivent rester rattachés à l’Order ? | Les totaux passés ne peuvent plus être expliqués. |
| Page statique héritée | S’agit-il de contenu CMS, de code de modèle, d’une route ou d’un enregistrement d’extension ? | Le contenu arrive sans bon propriétaire ni bonne navigation. |
| ID externe | Quel système et quelle entité cette clé identifie-t-elle ? | Le rapprochement et la synchronisation échouent. |
Une migration osCommerce réussie doit représenter la bonne génération de plateforme et préserver les relations entre les domaines du catalogue, des canaux, des Customers, des Orders, des contenus, des Apps et des systèmes externes.
Conclusion
La transposition du modèle de données osCommerce commence par la séparation entre les structures modernes de la v4 et les installations historiques. La v4 actuelle prend en charge les Products affectés à des canaux de vente et à des groupes de clients, les attributs, les propriétés, les relations de catalogue configurables, la gestion CMS, plusieurs front ends, les thèmes, les Apps et la tarification avancée. Les anciennes boutiques peuvent dépendre de tables, extensions et fichiers modifiés très différents.
La boutique cible doit préserver l’identité des Products et Categories, les attributs sélectionnables, les propriétés descriptives, les relations avec les canaux et groupes de clients, les instantanés historiques des Orders, la propriété des contenus CMS et des routes ainsi que les identifiants externes durables. Elle ne doit pas supposer qu’un enregistrement d’extension historique devient natif simplement parce qu’osCommerce v4 propose aujourd’hui une fonction portant un nom similaire.
Questions fréquentes
Pourquoi la version osCommerce de la source est-elle si importante ?
Les boutiques osCommerce v4 actuelles et les anciennes installations 2.x reposent sur des architectures et modèles d’extension sensiblement différents. Un même libellé peut désigner d’autres tables, relations ou fonctionnements ; la filiation de la source détermine donc la manière dont l’enregistrement doit être transposé.
Quelle est la différence entre les attributs et les propriétés dans osCommerce ?
Les attributs peuvent représenter des valeurs Product sélectionnables et modifier le prix, le poids, le stock ou les fichiers téléchargeables. Les propriétés décrivent des caractéristiques structurées utilisées pour l’affichage, les filtres, la recherche, la comparaison ou les groupes de Products.
Un Product osCommerce peut-il être affecté à plusieurs front ends ou groupes de clients ?
La v4 actuelle prend en charge l’affectation ou la restriction des Products et Categories par front end, canal de vente et groupe de clients. La migration doit préserver ces relations plutôt que dupliquer les Products sans nécessité.
Chaque ancienne option Product doit-elle devenir une relation de Product configurable moderne ?
Non. Certaines options modifient seulement le prix ou recueillent une saisie de l’acheteur, alors que d’autres identifient des combinaisons de stock indépendantes. La bonne destination dépend du SKU, du stock, du prix, des médias et du fonctionnement des lignes Orders.
Comment traiter les Orders historiques lorsque les modules de paiement ou de livraison changent ?
Il faut conserver les lignes Products au moment de la commande, les adresses, les totaux, les libellés de méthode, les références de transaction, les statuts, les expéditions et les enregistrements après-vente. La configuration active de la cible peut changer sans réécrire la transaction historique.
Que faire des données issues d’anciennes extensions osCommerce ou des Apps v4 actuelles ?
Il faut identifier l’extension ou l’App, l’entité principale qu’elle étend et les systèmes externes dont elle dépend. Les enregistrements encore utiles doivent avoir un propriétaire cible explicite ; les données techniques obsolètes peuvent être archivées ou exclues au lieu d’être forcées dans des champs natifs.