Migrer des données vers PrestaShop consiste à les représenter dans un modèle de catalogue qui distingue les variations achetables, les caractéristiques descriptives, la personnalisation saisie par le client, le périmètre des boutiques et les fonctions détenues par des modules. Des enregistrements familiers comme Products, Categories, Customers, Orders, Coupons, CMS Pages, images et URL changent de sens lorsqu’ils sont intégrés aux relations de combinaison, de caractéristiques, de groupes de clients, de multiboutique, de langue et de modules propres à PrestaShop.
La distinction principale tient au fait qu’une plateforme source peut utiliser une même couche générale d’« options » ou de champs personnalisés pour plusieurs fonctions différentes. Dans PrestaShop, une valeur peut devoir devenir un attribut utilisé par une combinaison, une caractéristique partagée par tout le Product, un champ de personnalisation rempli par le client, une association Product, une affectation à une Category, une relation avec un groupe de clients, une valeur propre à une boutique ou un enregistrement appartenant à un module. Faire correspondre les champs uniquement par leur nom, sans tenir compte de leur sens métier, peut produire un catalogue techniquement rempli mais commercialement incohérent.
Le sens du catalogue PrestaShop commence par la structure Product
Les Products PrestaShop peuvent être des Products standard, des Products avec combinaisons, des packs ou des Products virtuels. L’enregistrement Product porte aussi des associations avec les Categories, le contexte de marque et de fournisseur, les images, pièces jointes, Products liés, caractéristiques, champs de personnalisation, prix, stock, langues et périmètre de boutique. Ces relations déterminent comment le Product est sélectionné, affiché, gouverné et vendu.
| Sens côté source | Question à résoudre dans PrestaShop | Conséquence relationnelle |
|---|---|---|
| Un article vendable sans version sélectionnable | Doit-il rester un Product standard ? | L’identité Product, la référence, le prix, le stock, l’image, la taxe, la Category et l’URL restent au niveau Product. |
| Taille, couleur, capacité, finition ou autre version achetable | Des attributs doivent-ils créer des combinaisons ? | L’identité de combinaison peut porter sa propre référence, un impact de prix, une quantité, une image et les valeurs sélectionnées. |
| Spécification stable comme la matière ou le pays d’origine | Doit-elle devenir une caractéristique ? | La valeur décrit le Product dans son ensemble au lieu de créer une autre version achetable. |
| Texte ou fichier de personnalisation fourni par le client | Doit-il devenir un champ de personnalisation ou une autre structure cible ? | La saisie du client reste distincte des attributs et des caractéristiques descriptives. |
| Ensemble de Products existants vendus ensemble | Est-ce un pack, une association, une Category ou une relation de merchandising ? | La cible doit préserver l’identité des Products et l’intention de regroupement sans duplication. |
| Choix ou enregistrement créé par un module | Quel module ou processus cible en est propriétaire ? | Les champs Product principaux ne doivent pas absorber par erreur un fonctionnement actif d’extension. |
La représentation correcte dépend de ce que fait la valeur. Une valeur « Color » peut créer une combinaison, décrire une caractéristique Product, soutenir une expérience de Category ou de filtre, ou n’exister que comme sortie de module. Son libellé ne suffit pas à décider.
Combinaisons, attributs, caractéristiques et personnalisations ne sont pas interchangeables
Les combinaisons PrestaShop représentent des versions achetables d’un Product. Elles sont créées à partir de valeurs d’attribut et peuvent porter leur propre référence, impact de prix, quantité, association d’image, impact de poids, disponibilité et autres données au niveau de la variation. Les caractéristiques décrivent des propriétés partagées par le Product sans changer la version achetée. Les champs de personnalisation recueillent du texte ou des fichiers fournis par le client.
Cette séparation doit rester visible dans le modèle migré :
| Structure PrestaShop | Sens commercial | Erreur source → cible fréquente |
|---|---|---|
| Groupe et valeur d’attribut | Dimension sélectionnable comme la taille ou la couleur | Transformer des spécifications descriptives en choix obligatoires pour l’acheteur. |
| Combinaison | Combinaison d’attributs valide et achetable | Aplatir de vrais variants dans un seul Product et perdre le SKU enfant, le prix, l’image ou le stock. |
| Caractéristique et valeur de caractéristique | Propriété stable du Product | Transformer des spécifications filtrables ou comparatives en texte libre. |
| Champ de personnalisation | Texte ou fichier saisi par le client | Traiter la personnalisation comme une valeur d’attribut fixe ou une note d’Order. |
| Pack | Relation Product regroupant des Products existants | Dupliquer les données des composants ou confondre un bundle avec une variation. |
| Product virtuel | Product non physique avec un mode de livraison associé | Conserver une référence de fichier sans ses relations avec le Product et les droits d’accès. |
Une plateforme source peut stocker les variants enfants comme des Products séparés. PrestaShop peut les représenter comme des combinaisons sous un Product parent lorsqu’il s’agit réellement de versions d’un même article. À l’inverse, des Products indépendants ne doivent pas être fusionnés en combinaisons lorsqu’ils ont leurs propres identités de merchandising, contenu, cycle de vie ou reporting.
La génération des combinaisons dépend aussi du vocabulaire d’attributs. Des valeurs source incohérentes comme « Large », « L » et « large » doivent être examinées avant de devenir des valeurs d’attribut distinctes dans la cible. Cette normalisation ne doit toutefois pas fusionner des valeurs qui portent des SKU, prix, stocks ou significations visibles différents.
Categories, marques, fournisseurs et associations structurent la découverte
Les Categories PrestaShop forment des parcours hiérarchiques dans le catalogue et peuvent contenir des descriptions, images, métadonnées, URL simplifiées, associations Product et contexte de boutique. Un Product peut être associé à plusieurs Categories, dont l’une peut constituer sa Category principale. Les marques, fournisseurs, Products liés, accessoires et packs ajoutent d’autres relations de découverte ou d’exploitation.
Les plateformes source mélangent souvent ces rôles. Une collection peut être une véritable famille de Products, une campagne saisonnière, une archive de marque, un résultat de filtre, un raccourci de navigation ou une page d’entrée SEO. Reproduire chaque regroupement source sous forme de Category PrestaShop peut conserver du bruit et dupliquer les intentions.
| Structure source | Signification possible dans PrestaShop | Signal de décision |
|---|---|---|
| Famille hiérarchique permanente | Arborescence de Categories | Les clients et les équipes utilisent la hiérarchie comme chemin stable dans le catalogue. |
| Regroupement par marque ou fabricant | Relation de marque, Category, caractéristique ou page de contenu | La cible doit suivre les besoins de navigation, confiance, reporting et gouvernance Product. |
| Référence fournisseur | Relation fournisseur ou clé d’approvisionnement externe | La valeur sert l’approvisionnement ou l’administration plutôt que l’image de marque en boutique. |
| Collection saisonnière ou de campagne | Category temporaire, règle de merchandising ou page d’entrée de contenu | Cette structure ne mérite pas nécessairement une place permanente dans la hiérarchie. |
| Products liés ou accessoires | Association Product | La relation soutient la vente croisée sans modifier l’identité Product. |
| Ensemble de Products existants | Pack ou autre structure de bundle définie | Les composants restent identifiables et le bundle ne devient pas une fausse variation. |
La relation entre Category principale et URL simplifiée mérite une attention particulière, car le contexte de Category peut influencer la génération et l’interprétation des chemins Product. Un Product peut être correctement affecté à plusieurs Categories tout en recevant un chemin principal non voulu si cette relation n’est pas définie.
Il faut séparer l’identité Customer du traitement par groupe
Un enregistrement Customer PrestaShop porte l’identité, les coordonnées, adresses, l’état du compte, le contexte linguistique et les relations avec les Orders. Les groupes de clients peuvent modifier le traitement dans la boutique via des remises, l’affichage des prix, la visibilité ou d’autres règles configurées. Le groupe n’est donc pas un simple libellé.
| Modèle Customer source | Question pour le modèle cible | Résultat relationnel |
|---|---|---|
| Compte retail ordinaire | Quelles identité, adresses, langue et relations avec les Orders restent la référence ? | L’historique Customer reste attaché au bon compte. |
| Acheteur wholesale ou professionnel | Quel groupe, prix, traitement fiscal, règle de visibilité ou relation de compte externe définit son traitement ? | L’identité de l’acheteur reste distincte des règles commerciales. |
| Segment de fidélité ou d’adhésion | S’agit-il d’un groupe principal, d’un enregistrement de module, d’un segment CRM ou d’un libellé historique ? | La cible ne conserve que la relation qui continuera d’être utilisée. |
| Acheteur invité | L’Order doit-il conserver l’identité sans créer un compte normal ? | L’Order historique reste interprétable sans créer une fausse continuité de compte. |
| Customers en double | Quel enregistrement doit posséder l’e-mail, les adresses, les Orders et les identifiants externes ? | Les décisions de consolidation ne rompent pas les relations avec les Orders. |
Un groupe de clients source peut avoir influencé les prix, le traitement fiscal, l’accès au catalogue, une approbation ou la communication en dehors du cœur de la boutique. Migrer uniquement le nom du groupe ne préserve pas ces résultats. Le modèle cible doit préciser quels comportements appartiennent à la configuration PrestaShop, à un module ou à un CRM/ERP externe.
Le multiboutique ajoute une propriété par boutique aux enregistrements partagés
Le multiboutique PrestaShop permet à un même back-office de gérer plusieurs boutiques ou groupes de boutiques. En migration, cela signifie que Products, Categories, Customers, contenus, langues, devises, URL et fonctions de modules peuvent être partagés, hérités ou spécifiques à une boutique. Un simple nombre d’enregistrements ne permet pas de vérifier si cette propriété a été conservée.
| Domaine multiboutique | Décision de propriété |
|---|---|
| Products et combinaisons | Quelles boutiques reçoivent le Product, la variation, la visibilité, le contexte de prix et la quantité ? |
| Categories | Quelle arborescence racine et quelle association de boutique gouvernent leur emplacement dans la navigation ? |
| Customers et groupes | Quelles identités et quels traitements commerciaux sont partagés ou propres à une boutique ? |
| Langues et champs localisés | Quels noms, descriptions, slugs et métadonnées traduits appartiennent à chaque langue et boutique ? |
| CMS Pages et contenus | Quelle boutique, langue, route de navigation ou domaine possède le contenu ? |
| URL et domaines | Quelle boutique remplace chaque route source importante ? |
| Modules | Quels enregistrements ou paramètres de module s’appliquent globalement, au groupe de boutiques ou à une boutique précise ? |
Aplatir les affectations dans une boutique par défaut peut donner l’impression que les données partagées sont complètes tout en supprimant des frontières de marque, région, langue ou B2B/B2C. L’erreur inverse, qui consiste à dupliquer chaque enregistrement partagé dans chaque boutique, crée des divergences inutiles et complique la gouvernance future du catalogue.
Les Orders conservent la preuve de transaction, pas la future configuration de la boutique
Les Orders PrestaShop relient des Customers ou identités invitées à des instantanés de Products, combinaisons, quantités, prix, remises, taxes, transport, libellés de paiement, adresses, messages, historiques de statut et références de modules. Les Orders historiques doivent rester compréhensibles même si le processus source n’a aucun équivalent exact dans PrestaShop.
| Relation liée à l’Order | Sens dans l’enregistrement cible |
|---|---|
| Ligne Product et combinaison | Nom acheté, référence, attributs sélectionnés, quantité et prix au moment de la vente. |
| Customer ou identité invitée | Contexte de l’acheteur et relation avec les données historiques du compte. |
| Adresses | Instantanés de facturation et de livraison utilisés pour la transaction. |
| Remises et vouchers | Effet historique sur l’Order, et non recréation automatique de futures règles promotionnelles. |
| Libellés de paiement et de transporteur | Trace de la transaction d’origine, et non preuve que les modules correspondants sont actifs dans la cible. |
| Statuts et messages | Workflow historique et contexte de service pouvant nécessiter une mise en correspondance sémantique. |
| Référence de module ou externe | Clé inter-systèmes ou contexte détenu par une extension avec une finalité cible définie. |
Un module de paiement, un transporteur, une règle fiscale, un modèle d’e-mail ou une personnalisation du processus de commande relèvent de la configuration opérationnelle de la cible. Les libellés historiques peuvent être conservés sans laisser entendre que le futur processus a été déployé. Cette frontière maintient les Orders utiles au support et à la finance sans confondre historique transactionnel et configuration d’exploitation.
Modules, surcharges, thèmes et données personnalisées exigent une propriété explicite
L’écosystème de modules et de surcharges PrestaShop peut étendre Products, combinaisons, Customers, Orders, processus de commande, promotions, Reviews, fidélité, flux marketplace, SEO, transport, paiement, analyse des données et administration. Une valeur affichée dans le back-office ou la boutique peut donc provenir d’une table principale, d’une table de module, d’une surcharge, d’une logique de thème ou d’un système externe.
| Type de dépendance | Interprétation dans le modèle de données |
|---|---|
| Entité détenue par un module | Identifier son Product, Customer, Order, contenu ou enregistrement externe parent, ainsi que le module cible qui continuera à la consommer. |
| Champ personnalisé sur un enregistrement principal | Utiliser un champ natif ou un champ d’extension gouverné uniquement si son propriétaire cible est connu. |
| Surcharge ou code personnalisé | Déterminer si cela modifie le stockage, le calcul, la validation ou la présentation plutôt que de supposer qu’il s’agit de données transférables. |
| Champ de thème | Séparer le contenu durable de la mise en page ou du balisage propre au thème source. |
| Identifiant externe | Conserver les clés ERP, CRM, PIM, comptabilité, marketplace ou traitement logistique dans une relation d’intégration gouvernée. |
| Sortie mise en cache ou dérivée | La recréer à partir des données cibles faisant autorité plutôt que copier un résidu technique obsolète. |
Les résidus de modules ne doivent pas être copiés simplement parce qu’ils existent. À l’inverse, un champ détenu par un module qui contrôle l’identité Product, un droit Customer, l’interprétation d’un Order ou la continuité d’une intégration ne peut pas être écarté comme simple métadonnée facultative. Le modèle cible doit identifier son futur consommateur.
Les contenus, langues et URL portent un contexte de boutique
Les champs Product, Category, CMS Page et autres contenus PrestaShop peuvent être localisés. Les noms, descriptions, slugs, métadonnées et légendes d’images peuvent varier par langue et boutique. Une plateforme source peut au contraire utiliser des Stores séparés, des enregistrements dupliqués, des plugins de traduction ou des URL propres à chaque langue.
Le modèle cible doit distinguer l’identité partagée de son expression localisée. Un Product peut conserver une référence et une structure relationnelle communes tout en ayant un nom, une description, un slug et des métadonnées différents selon la langue. Un enregistrement traduit dans la source ne doit pas devenir un Product en double sauf s’il représente réellement un article commercial distinct.
Les URL doivent elles aussi être rattachées à un objet. Une route source peut identifier un Product, une Category, une page de marque, une CMS Page, un chemin linguistique ou un domaine de boutique. La route cible doit pointer vers l’objet PrestaShop et le contexte de boutique qui remplacent cette intention. Des chaînes d’URL simplifiées sans l’enregistrement, la langue et la relation de boutique corrects ne suffisent pas.
La propriété cible doit être définie avant la mise en correspondance des champs
Un modèle cible PrestaShop complet attribue chaque valeur source importante à l’un de ces résultats :
- un Product, une combinaison, un attribut, une caractéristique, une personnalisation, une Category, un Customer, un Order, un contenu ou une relation de boutique native ;
- un module gouverné ou un champ personnalisé avec un propriétaire cible durable ;
- une relation avec un système externe dont l’identifiant stable doit rester traçable ;
- une configuration ou présentation côté cible qui doit être reconstruite plutôt que migrée comme donnée ;
- un résidu historique qui doit être archivé ou exclu.
| Domaine de décision | Question forte sur la propriété |
|---|---|
| Variation Product | Quel Product et quelle combinaison d’attributs possèdent le SKU, le prix, la quantité, l’image et l’identité achetable ? |
| Informations Product | Quelles valeurs sont des caractéristiques, descriptions, pièces jointes ou contenus localisés plutôt que des combinaisons ? |
| Découverte du catalogue | Quelles Categories, marques, fournisseurs, associations et URL préservent l’intention du client ? |
| Traitement des Customers | Quel groupe ou quelle relation externe gouverne le prix, la visibilité, la fiscalité ou les droits ? |
| Multiboutique | Quelle boutique ou quel groupe de boutiques possède chaque affectation et valeur localisée ? |
| Données de module/personnalisées | Quel module cible, quelle équipe ou quel système externe continuera à utiliser l’enregistrement ? |
Cette lecture par propriété évite de transformer PrestaShop en simple conteneur de libellés copiés depuis la source. Le catalogue migré peut ainsi fonctionner comme un ensemble cohérent de relations entre Products, Customers, Orders, contenus, boutiques et modules.
Conclusion
Les différences du modèle de données PrestaShop se concentrent dans la séparation entre Products et combinaisons, attributs et caractéristiques, contenu fixe et personnalisation Customer, identité Customer et traitement par groupe, enregistrements partagés et propriété multiboutique, Orders historiques et future configuration, ainsi qu’entre enregistrements principaux et extensions détenues par des modules.
Une migration fiable préserve ces distinctions avant toute mise en correspondance de champs. Le résultat n’est pas seulement une base de données remplie : c’est une structure de catalogue et de comptes cible dont les enregistrements conservent un sens commercial clair entre boutiques, langues, modules et systèmes connectés.
Questions fréquentes
Pourquoi les combinaisons PrestaShop sont-elles différentes d’options Product générales ?
Les combinaisons sont des versions achetables d’un Product créées à partir de valeurs d’attribut. Elles peuvent porter leur propre référence, impact de prix, quantité, image, poids et disponibilité. Une caractéristique descriptive ou une personnalisation saisie par le client joue un rôle différent.
Les caractéristiques PrestaShop sont-elles identiques aux attributs ?
Non. Les attributs créent des dimensions sélectionnables pour les combinaisons, tandis que les caractéristiques décrivent des propriétés stables du Product. Les confondre peut transformer des spécifications en choix inutiles ou aplatir de vraies variations en texte descriptif.
Comment représenter des variants source stockés comme Products séparés ?
Il faut déterminer s’il s’agit réellement de versions d’un même Product ou d’articles commerciaux indépendants. L’identité partagée, le contenu commun, les différences sélectionnables, la propriété du SKU, le stock, le prix et le cycle de vie aident à décider si les combinaisons sont appropriées.
Pourquoi les groupes de clients exigent-ils plus qu’une simple correspondance de libellés ?
Un groupe peut être lié à des remises, à l’affichage des prix, à la visibilité, au traitement fiscal ou à des fonctions de modules. La relation Customer → groupe ne doit être conservée qu’avec une définition claire du traitement commercial qui continuera dans la boutique cible.
Comment le multiboutique modifie-t-il la mise en correspondance des données ?
Le multiboutique ajoute une propriété de boutique ou de groupe de boutiques aux Products, Categories, Customers, contenus, langues, URL et modules. Les enregistrements partagés doivent rester partagés lorsque c’est approprié, tandis que les affectations spécifiques à une boutique ne doivent pas être aplaties dans la boutique par défaut.
Comment gérer les données détenues par des modules ?
Chaque enregistrement de module doit être relié à son objet parent, à son sens métier et à son futur consommateur dans la cible. Conservez les entités durables et les clés d’intégration, reconstruisez les fonctions actives dans l’environnement cible et excluez les résidus mis en cache, dérivés ou obsolètes sans finalité durable.