Si PrestaShop est retenu comme plateforme cible, la préparation doit documenter à la fois les enregistrements e-commerce et le contexte de boutique dans lequel ils fonctionnent. Les Products peuvent dépendre de combinaisons, attributs, caractéristiques, champs de personnalisation, fournisseurs, fabricants, Categories, images, stock, groupes de clients, langues, devises et affectations multiboutiques. Les Customers et Orders peuvent eux aussi varier selon la boutique, le groupe, le transporteur, le module, la devise, la fiscalité et le statut historique.
Chaque tâche de préparation doit identifier un responsable, un élément de vérification et une condition de préparation satisfaite. Le dossier doit aussi séparer les enregistrements source de la configuration cible : Orders historiques, combinaisons Product, groupes de clients, affectations aux boutiques, URL et données détenues par des modules relèvent de la préparation à la migration ; le fonctionnement en production des transporteurs, paiements, taxes, thèmes, e-mails et du processus de commande relève de la mise en œuvre côté cible.
Sécuriser le back-office, l’hébergement, la base de données, les fichiers et les sauvegardes
Confirmez l’accès au back-office PrestaShop, à l’hébergement, à la base de données, au système de fichiers, aux répertoires d’images, aux fichiers téléchargeables, aux tâches cron, aux paramètres Webservice, à la gestion des modules et aux services connectés. Documentez la version de PrestaShop, l’environnement PHP et base de données, le préfixe de base, le thème actif, les langues, devises, boutiques, modules, surcharges et code personnalisé.
| Action de préparation | Responsable | Élément de vérification | Condition prête |
|---|---|---|---|
| Confirmer les accès administratifs | Administrateur PrestaShop | Compte fonctionnel et résumé des autorisations | Products, combinaisons, Customers, Orders, boutiques, modules et configuration peuvent être inspectés. |
| Créer des sauvegardes restaurables | Responsable infrastructure | Dump de base, archive du système de fichiers/images, archive des fichiers téléchargeables et responsable de restauration | La boutique source peut être restaurée sans dépendre de l’environnement en production. |
| Documenter l’environnement technique | Responsable technique | Inventaire PrestaShop, PHP, base de données, thème, modules, surcharges et déploiement | Les données et personnalisations dépendantes des versions sont documentées. |
| Recenser les accès Webservice et intégrations | Responsables des intégrations | Clés Webservice, ressources autorisées, endpoints externes et correspondances d’identifiants | Les systèmes qui continueront et les interfaces source disponibles sont connus. |
| Conserver les identifiants source | Responsable des données | IDs des boutiques, Products, combinaisons, Customers, Orders, adresses, Categories, modules et systèmes externes | Les relations entre tables et entre systèmes peuvent être réconciliées. |
Ne supprimez pas les modules inactifs, surcharges ou anciens champs avant d’avoir vérifié la propriété de leurs données. Un composant inactif peut encore posséder des données historiques Product, Customer ou Order.
Définir le périmètre multiboutique, les groupes de boutiques, les langues et les devises
Le multiboutique PrestaShop peut appliquer données et paramètres à toutes les boutiques, à un groupe de boutiques ou à une boutique précise. Selon la configuration du groupe, des Customers ou Orders peuvent être partagés, tandis que Products, Categories, prix, langues, transporteurs, modules et URL peuvent varier selon le contexte.
| Domaine de périmètre | Éléments à préparer | Condition prête |
|---|---|---|
| Arborescence des boutiques | IDs des groupes et boutiques, noms, statut, boutique par défaut, domaines et URI physiques | Chaque contexte de boutique publique est listé une seule fois. |
| Paramètres de partage | Partage des Customers, Orders, quantités et règles au niveau du groupe | Les identités partagées sont distinguées des enregistrements dupliqués. |
| Affectations Product/boutique | Disponibilité Product/Category, statuts, prix, textes et images propres à la boutique | La présence d’un Product n’est pas déduite de la seule boutique par défaut. |
| Langues et devises | Affectations par boutique, traductions, langue par défaut, devise, contexte de change et fallback | Les enregistrements localisés restent rattachés à la bonne boutique. |
| Contexte d’URL | Domaine, sous-domaine ou chemin, domaine SSL, URI physique, URI virtuelle et URL principale | Chaque boutique publique possède une identité de route complète. |
Documentez quelles boutiques doivent rester séparées, lesquelles seront consolidées et quels identifiants historiques de boutique doivent rester associés aux Customers ou Orders. Cette décision doit précéder toute normalisation de Products ou Customers en double.
Préparer Products, combinaisons, attributs et caractéristiques
PrestaShop distingue les Products des combinaisons. Les attributs et valeurs d’attribut génèrent les combinaisons, tandis que les caractéristiques décrivent des propriétés qui ne créent pas de variation. Les enregistrements au niveau combinaison peuvent porter références, références fournisseur, codes-barres, impacts de prix et de poids, quantités, quantités minimales, dates de disponibilité, images et statut de combinaison par défaut.
| Modèle de catalogue | Éléments à préparer | Condition prête |
|---|---|---|
| Product simple | ID Product, référence, type, prix, groupe fiscal, stock, Category, fabricant, fournisseur, images et affectations aux boutiques | Le Product peut être interprété sans donnée de combinaison cachée. |
| Product avec combinaisons | ID Product, IDs de combinaisons, valeurs d’attribut, références, prix, poids, stock, images et combinaison par défaut | Chaque combinaison vendable est traçable indépendamment. |
| Caractéristique Product | Caractéristique, valeur, langue, affectation Product, usage pour filtre ou comparaison | Les informations descriptives sont séparées des choix achetables. |
| Pack ou Product virtuel | Relations entre composants/fichiers, quantités, règles d’accès et exemples d’Orders | Le fonctionnement des Products non simples dispose d’éléments source complets. |
| Relation fournisseur/fabricant | IDs, références, liens Product, contexte d’achat et clés externes | La propriété de marque et d’approvisionnement reste distincte. |
| Product multiboutique | Affectations, valeurs propres à la boutique, Categories, prix et statut | Le contexte de boutique est conservé et non aplati. |
Incluez des cas inactifs, exclusivement en ligne, indisponibles, arrêtés, en rupture, en précommande, avec quantité minimale ou date limitée. Chacun de ces états nécessite une décision explicite dans la destination au lieu d’une normalisation automatique.
Préparer les personnalisations, prix spécifiques, stocks et groupes de clients
Les champs de personnalisation peuvent recueillir du texte ou un fichier et rester rattachés à un Product puis à une ligne d’Order. Les prix spécifiques peuvent dépendre du Product, de la combinaison, de la boutique, devise, pays, groupe de clients, Customer, quantité et période. Le stock peut appartenir à un Product ou une combinaison et être partagé entre boutiques.
| Structure commerciale | Éléments | Condition prête |
|---|---|---|
| Champ de personnalisation | ID du champ, Product, type, caractère obligatoire, libellé, emplacement du fichier envoyé et exemple de ligne d’Order | Les données saisies par l’acheteur restent distinctes des attributs Product réutilisables. |
| Prix spécifique | Product/combinaison, boutique, devise, pays, groupe, Customer, quantité, dates, type de réduction et priorité | Chaque prix conditionnel conserve tout son contexte. |
| Groupe de clients | ID, membres, utilisation comme groupe par défaut, affichage des prix, réduction, accès aux Categories et affectation boutique | Le sens du groupe est documenté au-delà de son nom. |
| Stock | ID Product/combinaison, contexte de boutique ou quantité partagée, état réservé lorsque disponible et système faisant autorité | L’unité vendable et le contexte de boutique de chaque quantité sont connus. |
| Cart rule | Code, conditions, actions, restrictions, dates, utilisation et références d’Orders historiques | Les éléments historiques de remise sont séparés de la future configuration promotionnelle. |
Les prix et remises des Orders historiques doivent rester des instantanés. Ils ne doivent pas être recalculés à partir des prix spécifiques, groupes ou cart rules actuels.
Préparer Categories, CMS Pages, URL simplifiées et parcours de découverte
Les Categories PrestaShop peuvent comporter une hiérarchie parent-enfant, une affectation aux boutiques, des noms et descriptions localisés, des images, métadonnées, URL simplifiées, accès par groupe et appartenance Product. Les CMS Pages et Categories peuvent porter des contenus juridiques, de service ou éditoriaux. Des modules de navigation et structures de thème peuvent créer d’autres parcours de découverte.
| Domaine de la boutique | Éléments à préparer | Condition prête |
|---|---|---|
| Hiérarchie des Categories | IDs, parents, affectations aux boutiques, groupes d’accès, Products membres et traductions | La taxonomie et le périmètre d’accès sont complets. |
| URL Product et Category | URL simplifiée, boutique, langue, intention canonique, métadonnées et priorité | Les routes à forte valeur ont une décision de destination explicite. |
| Contenu CMS | IDs CMS Page/Category, langue, affectation boutique, statut, route et relation avec les menus | Le contenu CMS reste distinct de la présentation du thème. |
| Navigation | Module de menu, liens, hiérarchie, contexte boutique/langue et objet de destination | Les parcours Customer ne sont pas déduits des seules Categories. |
| Liens internes et redirections | Page source, objet lié, ancien chemin et intention de destination | Les liens peuvent être réécrits et les routes prioritaires conservées. |
Collectez les URL prioritaires à partir des données d’analyse, informations de recherche, backlinks, campagnes, e-mails Customer et de la navigation interne. Un sitemap ne révèle pas nécessairement toutes les routes ayant une valeur commerciale.
Préparer Customers, adresses, Orders et documents historiques
La préparation des Customers doit couvrir l’identité du compte, les groupes par défaut et supplémentaires, le contexte de boutique, la langue, les adresses, le consentement, les informations d’entreprise ou fiscales, les identifiants externes et les dépendances d’authentification. La préparation des Orders doit conserver le contexte Customer ou invité, le panier, la devise, la boutique, le transporteur, le module de paiement, les adresses, les lignes Product/combinaison, les personnalisations, totaux, statuts, factures, bons de livraison, messages, remboursements et références externes.
| Domaine d’enregistrement | Éléments | Condition prête |
|---|---|---|
| Compte Customer | ID Customer, e-mail, boutique, groupes par défaut/supplémentaires, langue, statut, adresses, consentement et ID externe | Les comptes en double ou partagés sont résolus de manière délibérée. |
| Authentification | Schéma de mot de passe, SSO/social login, parcours de réinitialisation et responsable des communications compte | L’accès au compte est préparé sans supposer la portabilité des identifiants. |
| Lignes d’Order | Références Product/combinaison, libellés instantanés, personnalisations, quantité, prix, taxe et remise | Les articles achetés restent compréhensibles indépendamment du catalogue actuel. |
| Totaux et état d’Order | Devise, sous-total, transport, remises, taxes, total final, état courant et historique | Le sens commercial historique peut être réconcilié. |
| Documents et service après-vente | Facture, bon de livraison, avoir, retour, message, paiement, transporteur et références de suivi | Les éléments utiles au support et à la finance sont récupérables. |
| Identifiants externes | Clés ERP, marketplace, comptabilité, paiement et traitement logistique | La traçabilité entre systèmes est conservée. |
Sélectionnez comme cas représentatifs des Orders d’invités et de Customers inscrits, multi-groupes, multiboutiques, avec combinaison, personnalisation, remise, remboursement, retour et expédition partielle.
Inventorier les modules, surcharges, thèmes et tables personnalisées
Créez un registre de propriété pour les modules, surcharges, thèmes, contrôleurs personnalisés, tables personnalisées, modifications directes de la base, intégrations Webservice, flux, marketplaces, recherche, fidélité, paiement, transport, abonnements et connexions ERP/PIM/WMS/CRM.
| Dépendance | Éléments à préparer | Condition prête |
|---|---|---|
| Module | Nom, version, statut, finalité, responsable de configuration, tables/champs, hooks et enregistrements concernés | Les données détenues par le module ont une destination ou un propriétaire conservé. |
| Surcharge ou code personnalisé | Classe/contrôleur surchargé, fonctionnement modifié, impact base de données et développeur responsable | La logique métier est documentée séparément de l’ancienne implémentation. |
| Thème | Version, templates, positions des modules, contenu intégré, scripts personnalisés et dépendances de routes | La présentation est séparée du contenu et des enregistrements portables. |
| Table ou colonne personnalisée | Schéma, clés, enregistrements principaux référencés et processus consommateur | Les enregistrements personnalisés peuvent être interprétés au lieu d’être copiés aveuglément. |
| Système externe | Endpoint, entités faisant autorité, sens de synchronisation, IDs et responsable de bascule | Les conflits entre systèmes de référence sont évités. |
| Données générées | Cache, index, logs, sessions, exports temporaires et tables abandonnées | Les données ne faisant pas autorité sont exclues volontairement. |
Si une même fonction existe dans plusieurs boutiques, indiquez si les données du module sont partagées, dupliquées ou propres à un contexte.
Sélectionner des échantillons représentatifs pour le test de migration
Choisissez des enregistrements source qui exposent la complexité réelle de la boutique. Documentez leurs IDs, contexte de boutique, langue, URL, références de combinaison, groupes Customer, dépendances de modules et la raison de leur sélection.
| Échantillon | Éléments à préparer | Objectif de préparation |
|---|---|---|
| Product simple | Prix, taxe, stock, Category, fabricant/fournisseur, images, boutique et Order | Établit le modèle Product ordinaire. |
| Product riche en combinaisons | Attributs, combinaisons, références, stock, images, impacts prix/poids et combinaison par défaut | Représente la structure des variations vendables. |
| Product avec caractéristique/personnalisation | Caractéristiques, champs/fichiers saisis par le Customer et lignes d’Order correspondantes | Sépare les données descriptives des valeurs fournies par l’acheteur. |
| Cas multiboutique | Product, Category, Customer ou prix avec contexte toutes boutiques/groupe/boutique | Représente les propriétés partagées et propres à une boutique. |
| Cas de groupe Customer | Customer, groupes, prix spécifique, accès Category et Order pertinent | Représente le commerce segmenté. |
| Order complexe | Combinaison, personnalisation, remise, taxe, transporteur, paiement, facture, retour et IDs externes | Représente les éléments historiques d’une transaction. |
| Enregistrement détenu par un module | Entité principale, tables/champs de module, hooks et clé externe | Expose le périmètre non principal avant l’exécution. |
Le dossier d’échantillons PrestaShop est prêt lorsque chaque enregistrement sélectionné possède une fiche d’attente source, un périmètre de boutique et de langue, les fichiers associés et un relecteur nommé.
Terminer la dernière vérification de préparation PrestaShop
| Domaine de préparation | Condition prête |
|---|---|
| Accès et récupération | Back-office, hébergement, base de données, fichiers, images, téléchargements, identifiants, sauvegardes et responsable de restauration sont confirmés. |
| Multiboutique | Boutiques, groupes, domaines, paramètres de partage, langues, devises et valeurs propres aux boutiques sont documentés. |
| Catalogue | Products, combinaisons, attributs, caractéristiques, personnalisations, Categories, fournisseurs, fabricants, stock, prix et identifiants sont traçables. |
| Customers et Orders | Comptes, groupes, adresses, paniers, Orders, lignes, totaux, statuts, documents, messages, retours et IDs externes disposent d’éléments de vérification. |
| Contenu et URL | Contenu CMS, navigation, URL simplifiées, métadonnées, liens internes et décisions de redirection sont documentés. |
| Dépendances | Modules, surcharges, thèmes, tables personnalisées, intégrations Webservice et systèmes externes ont des responsables nommés. |
| Échantillons | Les enregistrements représentatifs couvrent chaque modèle important de Product, boutique, Customer, Order, contenu et module. |
Le périmètre PrestaShop est prêt lorsque chaque enregistrement important peut être relié à son contexte de boutique, son propriétaire source, ses enregistrements associés, son élément de vérification et sa destination prévue ou au système qui continuera à le posséder.
Conclusion
Préparer PrestaShop exige des éléments coordonnés sur Products, combinaisons, attributs, caractéristiques, personnalisations, périmètre multiboutique, groupes de clients, Customers, Orders, contenus CMS, URL simplifiées, modules, surcharges et systèmes externes. La checklist doit rendre ces relations explicites avant l’exécution au lieu de s’appuyer sur des exports de la seule boutique par défaut.
Un dossier de préparation complet conserve des éléments source restaurables, résout les enregistrements partagés ou propres à une boutique, sépare l’historique commercial de la configuration en production et attribue un responsable à chaque dépendance de module ou personnalisée.
Questions fréquentes
Que faut-il préparer en premier pour une migration vers PrestaShop ?
Confirmez les accès au back-office, à l’hébergement, à la base de données, au système de fichiers, aux images et modules ; créez des sauvegardes restaurables ; puis documentez la version de PrestaShop et l’arborescence multiboutique. La préparation du catalogue ne doit pas commencer tant que la source ne peut pas être inspectée et restaurée de façon fiable.
Pourquoi Products et combinaisons doivent-ils être préparés séparément ?
Un Product contient les informations de catalogue partagées, tandis que les combinaisons peuvent posséder leurs propres références, codes-barres, impacts prix/poids, stocks, images, quantités minimales et valeurs d’option. Chaque combinaison réellement vendable doit être traçable indépendamment.
Quelle différence entre caractéristiques et attributs PrestaShop ?
Les attributs créent des combinaisons Product sélectionnables par les clients. Les caractéristiques décrivent des propriétés stables communes aux combinaisons. Les mélanger peut créer de faux variants ou supprimer des informations nécessaires au filtrage et à la comparaison.
Pourquoi le contexte multiboutique est-il essentiel ?
Products, Categories, Customers, prix, langues, modules et URL peuvent être partagés ou personnalisés pour toutes les boutiques, un groupe de boutiques ou une boutique précise. Un même ID source peut donc avoir un sens métier différent selon le contexte.
Quels Orders PrestaShop choisir comme échantillons représentatifs ?
Incluez des Customers invités et inscrits, des combinaisons, du texte ou des fichiers de personnalisation, des prix liés à des groupes Customer, des remises, plusieurs taxes, factures, retours, avoirs, références de paiement/transporteur et IDs de systèmes externes.
Que doit contenir le registre des modules et surcharges PrestaShop ?
Recensez chaque module, surcharge, table personnalisée, dépendance de thème, intégration Webservice et connecteur externe qui crée ou consomme des données métier. Chaque élément doit avoir un responsable, des enregistrements concernés, des éléments de vérification et une décision de destination ou de système conservé.