Migrer des données vers OpenCart revient à les représenter dans une plateforme qui sépare les choix proposés au client, les informations descriptives sur les Products, le filtrage du catalogue, la hiérarchie de navigation, le traitement commercial des Customers, l’identité des routes, le périmètre de chaque boutique et les fonctions détenues par des extensions. Une boutique source peut regrouper plusieurs de ces significations dans un même champ d’option, paramètre de thème, tableau de module ou colonne personnalisée. OpenCart attend au contraire qu’elles soient exprimées par des relations distinctes.
La question essentielle n’est donc pas de savoir si une valeur source peut être copiée dans un enregistrement Product. Il faut déterminer si elle doit devenir une option, un attribut, un filtre, une Category, une relation avec un Manufacturer, une affectation de groupe de Customers, une route SEO, une affectation propre à une boutique, un enregistrement d’extension ou un identifiant externe. Choisir la mauvaise destination peut préserver le texte tout en supprimant son rôle dans l’achat, la découverte du catalogue ou l’administration.
OpenCart sépare les choix d’achat, la connaissance Product et la découverte
L’administration des Products dans OpenCart distingue les données générales, les liens, les attributs, les options, les remises, les promotions spéciales, les images, les points de récompense, le SEO et l’affectation au design. Ces éléments sont reliés, mais ils ne remplissent pas la même fonction.
| Valeur côté source | Question à poser pour la destination OpenCart | Pourquoi la relation compte |
|---|---|---|
| Taille, couleur, finition, niveau de service ou add-on choisi avant l’achat | Doit-elle devenir une option affectée au Product ? | L’option peut modifier le caractère obligatoire de la sélection, le prix, les points, le poids ou la déduction du stock. |
| Matière, dimensions, compatibilité ou spécification technique | Doit-elle devenir un attribut organisé dans un groupe d’attributs ? | La valeur sert à comprendre le Product sans modifier la configuration achetée. |
| Type de Product, usage, famille de compatibilité ou autre critère d’affinement | Doit-elle devenir une relation de filtre ? | La valeur sert à découvrir les Products plutôt qu’à les décrire uniquement. |
| Famille de Products hiérarchique | Doit-elle devenir une Category et une relation Product-to-Category ? | La structure soutient les parcours de navigation, les pages d’entrée et le placement des Products. |
| Marque ou fabricant | Doit-elle devenir une relation Manufacturer, une Category, un attribut ou une structure personnalisée ? | La destination dépend des besoins de navigation, de confiance, de reporting et d’administration. |
| Valeur de module ou personnalisée | Quelle extension, quel champ personnalisé ou quel système externe en est propriétaire ? | Les données Product du cœur ne doivent pas absorber une fonction qui n’a pas de signification native dans OpenCart. |
La meilleure mise en correspondance garde ces fonctions séparées. Un Product peut conserver le bon nom, la bonne description et la bonne image tout en restant inutilisable commercialement si les choix proposés au client, les relations de filtres, les affectations aux Categories ou la propriété des routes ont été aplatis.
Les options Products représentent les choix du client
Les options OpenCart sont des sélections que le client peut effectuer sur une page Product avant de l’ajouter au panier. Selon le type et la configuration de l’option, ses valeurs peuvent porter une quantité, une règle de déduction de stock, un ajustement de prix, de points de récompense ou de poids, un ordre d’affichage, une image et un caractère obligatoire.
Cela rend les options structurellement différentes des champs descriptifs. Une variante source, un modificateur, un champ de personnalisation, une option de garantie, un fichier à transmettre, une sélection de date ou un add-on peut sembler être une « option », mais la relation cible doit être examinée plus précisément.
| Structure source | Interprétation possible dans les options OpenCart |
|---|---|
| Variante avec stock et prix propres | Une valeur d’option peut représenter le choix, mais les attentes concernant SKU parent/enfant et inventaire doivent être définies explicitement. |
| Choix ajoutant ou retranchant un montant | Préserver la relation avec la valeur d’option ainsi que le sens et le montant de l’impact tarifaire. |
| Choix modifiant le poids | Préserver la valeur et son effet sur le poids utilisé par les règles d’expédition en aval. |
| Sélection obligatoire | Préserver le caractère obligatoire et une expérience de sélection claire. |
| Saisie texte, zone de texte, date, heure ou fichier | Représenter la donnée saisie par le client séparément des valeurs d’options fixes. |
| Bundle ou choix dépendant généré par une extension | Garder la relation détenue par l’extension distincte des données d’options du cœur. |
La structure d’options native d’OpenCart n’est pas un modèle universel de Product enfant. Une plateforme source peut attribuer à chaque variante son propre SKU, image, inventaire, coût, code-barres ou identité de traitement des commandes. Le modèle cible doit déterminer quelles valeurs peuvent vivre sur les valeurs d’options, lesquelles restent au niveau du Product et lesquelles nécessitent une extension ou une autre structure de Product.
Attributs et filtres répondent à des besoins de découverte différents
Les attributs décrivent les Products et peuvent être organisés en groupes. Les filtres servent à réduire une liste de Products dans différents contextes de catalogue. Ils peuvent reprendre le même vocabulaire source, mais leurs relations avec les Products et la vitrine diffèrent.
| Couche OpenCart | Rôle principal | Question de représentation |
|---|---|---|
| Groupe d’attributs | Organise des spécifications Products liées | Quelles informations doivent être regroupées pour la comparaison ou l’administration ? |
| Attribut | Stocke une information descriptive sur le Product | La valeur est-elle informative plutôt qu’un choix effectué par le client ? |
| Groupe de filtres et filtre | Permet d’affiner une liste de Products | Le terme est-il assez normalisé et affecté de façon cohérente pour aider le client à réduire une liste ? |
| Description | Explique le Product sous forme narrative | Quelles informations structurées doivent sortir du texte long pour être représentées de façon cohérente ? |
| Option | Enregistre un choix avant achat | La valeur modifie-t-elle la configuration achetée ou le sens de la ligne d’Order ? |
Une boutique source peut contenir des spécifications en texte libre comme « Blue », « blue » et « Navy » sur des centaines de Products. Transformer chaque valeur en filtre peut créer des contrôles de vitrine bruyants et peu utiles. À l’inverse, conserver dans les descriptions un critère essentiel de compatibilité ou de taille empêche les clients de l’utiliser pour affiner leur recherche. Le modèle cible doit donc établir un vocabulaire gouverné avant de créer les relations Product-to-filter.
Categories, Manufacturers et liens Products définissent le contexte de navigation
Les Categories OpenCart construisent les parcours hiérarchiques et le placement des Products. Ceux-ci peuvent aussi être reliés à des Manufacturers, Downloads, Products associés, boutiques et autres structures de catalogue. Ces relations influencent la manière dont les clients et les équipes interprètent le catalogue.
| Structure source | Signification possible dans OpenCart | Décision de propriété |
|---|---|---|
| Famille de Products durable | Hiérarchie de Categories | Préserver les relations parent-enfant et les affectations Products intentionnelles. |
| Collection saisonnière ou campagne | Category temporaire, page de contenu ou relation de merchandising | Éviter de transformer une opération marketing temporaire en hiérarchie permanente. |
| Collection par marque ou fournisseur | Manufacturer, Category, attribut ou relation personnalisée | Choisir la structure qui répond au besoin réel de navigation et de reporting. |
| Products associés | Relation entre Products | Conserver l’intention de vente croisée sans dupliquer les Products. |
| Download associé à un Product | Relation Product-to-download | Préserver le bon Product, le bon fichier et le bon droit d’accès client. |
| Lien de navigation uniquement | Menu, mise en page ou configuration de contenu | Ne pas créer de fausse Category lorsqu’il n’existe pas de hiérarchie Product correspondante. |
Un Product affecté à la mauvaise Category ou à la mauvaise boutique peut être présent en base et absent du parcours client prévu. Un Manufacturer copié comme simple texte peut perdre sa relation de navigation. Une liste de Products associés intégrée au thème source peut devoir devenir une relation explicite entre Products ou une autre structure de merchandising.
Customers, groupes de Customers et adresses portent un contexte commercial
Les enregistrements Customer d’OpenCart relient identité, e-mail, statut, adresses, historique d’Orders, éventuels crédits ou récompenses, champs personnalisés et appartenance à un groupe de Customers. Selon la configuration de la boutique et ses extensions, un groupe peut représenter vente en gros, détail, adhésion, région, traitement fiscal, politique tarifaire, état d’approbation ou autre distinction commerciale.
| Relation Customer | Question pour le modèle cible |
|---|---|
| Customer vers groupe | Le groupe reste-t-il une étiquette administrative ou contrôle-t-il le traitement commercial ? |
| Customer vers adresses | Quelles identités de facturation et de livraison restent valides et correctement localisées ? |
| Customer vers Orders | Les Orders historiques restent-elles traçables vers le bon compte ou la bonne identité de guest ? |
| Customer vers champs personnalisés | Quels champs disposent d’une destination native ou détenue par une extension et gardent une utilité métier ? |
| Customer vers système externe | Quel identifiant CRM, ERP, fiscal ou de compte reste la référence ? |
Préserver le nom du groupe sans la règle associée peut donner une fausse impression de continuité. Un Customer de vente en gros placé dans un groupe « Wholesale » ne bénéficie pas réellement du traitement correspondant tant que les prix, remises, taxes, règles de visibilité ou extensions nécessaires ne sont pas également représentés dans la cible.
La représentation des adresses exige la même précision. Pays, zone, code postal, société, données fiscales et téléphone peuvent influencer le futur processus de commande ou l’administration. Les instantanés d’adresse historiques intégrés aux Orders doivent rester distincts du carnet d’adresses actuel du Customer.
Les Orders conservent des relations historiques et des lignes calculées
Une Order OpenCart relie un Customer ou une identité de guest à des lignes de Products, options sélectionnées, quantités, prix, taxes, remises, expédition, libellés de paiement, statuts, totaux, commentaires et références d’extensions ou de systèmes externes. Les totaux sont souvent représentés par plusieurs lignes calculées plutôt que par un montant global non structuré.
| Zone de l’Order | Signification à préserver |
|---|---|
| Lignes Products et options | Identité du Product acheté, options choisies, contexte modèle/SKU, quantité et prix de ligne. |
| Totaux | Sous-total, remises, Coupons, expédition, taxes, crédits, frais et interprétation du total général. |
| Historique des statuts | Libellés historiques du workflow et contexte utile au support. |
| Libellés de paiement et d’expédition | Trace de la transaction d’origine, et non configuration active de la cible. |
| Customer et adresses | Identité de l’acheteur et instantanés de facturation/livraison au moment de la transaction. |
| Références externes | Clés de marketplace, ERP, comptabilité, traitement des commandes ou passerelle ayant encore une utilité dans la cible. |
Les enregistrements de récurrence ou d’abonnement de la source peuvent appartenir à une extension et ne doivent pas être aplatis dans des Orders ordinaires. De même, importer un libellé de paiement n’active pas une passerelle de paiement, et une description d’expédition ne configure pas un transporteur. Les traces historiques et le futur fonctionnement opérationnel sont deux relations distinctes de la cible.
Les affectations multi-boutique et de mise en page ajoutent un périmètre de vitrine
OpenCart peut administrer plusieurs boutiques depuis une même installation. Products, Categories, pages Information, paramètres, mises en page et routes peuvent donc avoir une propriété ou une visibilité propre à chaque boutique. Un environnement source contenant plusieurs marques, domaines, régions ou audiences ne peut pas être représenté correctement en affectant tous les enregistrements à la boutique par défaut.
| Élément de périmètre | Question de propriété par boutique |
|---|---|
| Products | Dans quelles boutiques chaque Product doit-il être proposé, et quelle identité partagée reste commune ? |
| Categories | Quelle hiérarchie et quelles affectations Products appartiennent à chaque boutique ? |
| Pages Information | Quelle politique, quel guide ou quel contenu appartient à quel domaine ou audience ? |
| Customers et Orders | Les enregistrements sont-ils partagés opérationnellement ou l’entreprise attend-elle une interprétation propre à chaque boutique ? |
| Routes SEO | Quelle boutique et quel domaine remplacent chaque chemin source important ? |
| Mises en page et routes de design | Quels types de pages reçoivent quels emplacements de modules ou affectations de présentation ? |
Les mises en page et positions de modules ne sont pas des enregistrements de contenu. Un Product ou une page Information peut migrer correctement tandis que la position du module, la bannière, la barre latérale ou le traitement de thème de la source n’a pas d’équivalent direct dans la cible. La relation de données durable doit être conservée ; l’affectation de présentation doit être définie séparément.
Les routes SEO et pages Information ont besoin d’un propriétaire explicite
Les mots-clés et routes SEO d’OpenCart relient des chemins lisibles à des Products, Categories, Manufacturers et pages Information. Une URL source peut aussi représenter une page de campagne, un état de filtre, une archive de marque ou une route d’extension. La route cible doit renvoyer à l’objet ou à l’intention client qui la remplace réellement.
Les pages Information contiennent souvent politiques d’expédition et de retour, conditions de garantie, guides de taille, contenu de confidentialité ou conseils d’achat. Leur texte peut être transféré tandis que leur position de menu, leur affectation par boutique, leur route, leurs métadonnées ou leurs liens internes vers des Products restent non définis. Considérer le corps de la page comme la totalité du modèle de données fait perdre sa relation avec le parcours de vitrine.
Les collisions de slugs doivent aussi être examinées. Un même mot-clé peut avoir été utilisé par plusieurs types d’objets ou boutiques dans la source. Le plan de routage doit d’abord préserver l’identité de l’objet, puis la lisibilité du texte.
Extensions, modifications et données personnalisées ont besoin d’un propriétaire durable
Les boutiques OpenCart utilisent fréquemment des extensions, des modifications OCMOD ou vQmod, des champs et tables personnalisés, des thèmes, flux, modules de paiement et d’expédition, connecteurs de marketplace et intégrations externes. Ces ajouts peuvent modifier à la fois le stockage et le fonctionnement.
| Type de dépendance | Décision pour le modèle de données |
|---|---|
| Enregistrement détenu par une extension | Identifier le Product, Customer, Order, contenu ou enregistrement externe parent ainsi que l’extension cible qui le consommera. |
| Modification du fonctionnement du cœur | Déterminer si elle change le stockage, le calcul, la validation ou la présentation. |
| Champ personnalisé | Utiliser un champ natif ou gouverné par une extension uniquement lorsque sa propriété cible est explicite. |
| Table personnalisée | Distinguer les données métier durables des logs, caches, index et résidus techniques. |
| Champ de thème | Extraire le contenu réutilisable et éviter de copier le balisage propre à la mise en page source comme donnée permanente. |
| Identifiant externe | Préserver les clés inter-systèmes stables et les rattacher au bon objet OpenCart. |
Un champ ne doit pas être conservé uniquement parce qu’il apparaît dans l’administration source. Il doit l’être parce qu’un processus cible, une extension, une équipe ou un système connecté continuera à l’utiliser. Le même principe protège les données invisibles importantes : un identifiant Product ERP ou un identifiant Order de marketplace peut avoir davantage de valeur opérationnelle qu’un libellé visible sur la vitrine.
Les résultats attendus des relations doivent être explicites avant la mise en correspondance
Un modèle cible OpenCart cohérent affecte chaque valeur source importante à l’une des catégories suivantes :
- relation native de Product, option, attribut, filtre, Category, Manufacturer, Customer, Order, contenu, route ou boutique ;
- donnée personnalisée ou détenue par une extension, gouvernée et associée à un consommateur cible défini ;
- identité de système externe qui reste traçable entre les intégrations ;
- configuration cible ou élément de présentation à reconstruire plutôt qu’à migrer comme un enregistrement ;
- résidu obsolète ou dérivé à archiver ou exclure.
| Domaine de décision | Question utile pour construire le modèle cible |
|---|---|
| Choix Products | Quelle option et quelle valeur d’option représentent le choix du client, et quels prix, stock, poids ou caractère obligatoire y sont attachés ? |
| Connaissance Product | Quels attributs et groupes conservent des spécifications comparables ? |
| Découverte | Quels filtres, Categories, Manufacturers et liens Products soutiennent le parcours de navigation attendu ? |
| Traitement Customer | Quel groupe et quelles relations externes définissent le contexte commercial du Customer ? |
| Périmètre de boutique | Quelle boutique possède le Product, la Category, le contenu, la route et la relation de mise en page ? |
| Données personnalisées | Quelle extension, quel processus ou quel système externe continuera à consommer la valeur ? |
Cette approche centrée sur les relations empêche OpenCart de devenir une simple collection de champs copiés depuis la source. Elle produit une boutique cible dont le catalogue, les Customers, les Orders, les routes et les extensions restent compréhensibles en tant que structures OpenCart.
Conclusion
Les différences du modèle de données OpenCart viennent de la séparation entre options, attributs, filtres, Categories, Manufacturers, groupes de Customers, lignes et totaux d’Orders, affectations multi-boutique, routes, mises en page, extensions et données personnalisées. Une même valeur source peut donc avoir des significations différentes selon la couche dans laquelle elle doit être représentée.
Une migration fiable préserve d’abord ces significations avant de décider de la correspondance des champs. Les Products restent achetables, les données de découverte restent gouvernées, Customers et Orders conservent leurs relations historiques, le périmètre par boutique reste intentionnel et les données personnalisées gardent un propriétaire au lieu de devenir des résidus inexpliqués.
Questions fréquentes
Les options OpenCart sont-elles équivalentes aux attributs ?
Non. Les options enregistrent des choix du client avant achat et peuvent influencer le prix, le stock, les points, le poids ou le caractère obligatoire. Les attributs décrivent les caractéristiques des Products et facilitent leur compréhension ou leur comparaison.
En quoi les filtres OpenCart diffèrent-ils des attributs ?
Les attributs stockent des informations descriptives sur les Products. Les filtres relient des valeurs gouvernées aux Products afin que les clients puissent réduire une liste de catalogue. Une spécification peut exister comme attribut sans être pertinente comme filtre de vitrine.
Les variantes sources peuvent-elles toujours devenir des valeurs d’options OpenCart ?
Pas automatiquement. Une variante source peut posséder son propre SKU, code-barres, image, inventaire, coût ou identité de traitement des commandes au-delà de ce que représente l’option cible. Le modèle doit préserver ces relations enfant ou adopter une autre représentation du Product.
Pourquoi les groupes de Customers nécessitent-ils un examen sémantique ?
Parce qu’un groupe peut être lié au traitement de vente en gros, aux remises, taxes, approbations, règles de visibilité ou fonctions d’extensions. Copier le nom du groupe sans le sens commercial associé ne crée qu’une continuité superficielle.
Comment la propriété multi-boutique doit-elle influencer la mise en correspondance ?
Il faut définir quels Products, Categories, pages Information, routes, Customers et relations de mise en page appartiennent à chaque boutique. Les enregistrements partagés ne doivent le rester que lorsque leur visibilité et leur sens commercial sont réellement communs.
Comment classer les données d’extensions et de tables personnalisées ?
Chaque enregistrement doit être rattaché à son objet parent, sa finalité métier, son extension ou processus cible et son propriétaire durable. Les données métier et clés d’intégration doivent être conservées ; caches, logs, index et résidus obsolètes sans consommateur cible doivent être exclus.