Une migration Magento peut sembler réussie avant d’être réellement cohérente sur le plan opérationnel. Products, Customers, Orders et Categories peuvent apparaître dans l’Admin alors que les enfants configurables, la portée des attributs, les affectations website, les relations d’inventaire, les URL rewrites, les données d’extensions ou les index restent incomplets.
Le schéma récurrent est le même : le transfert conserve les champs visibles mais perd les structures que Magento utilise pour assembler le catalogue, la vitrine et le sens historique. Chaque piège ci-dessous décrit le mode d’échec, les signaux qui permettent de le détecter et la condition prouvant que la relation a été correctement restaurée.
Piège 1 : convertir chaque Product en Product simple
Ce qui se passe mal
Magento prend en charge les Products simple, configurable, grouped, virtual, bundle et downloadable. Ces types reposent sur des relations différentes de parent/enfant, prix, stock, fichiers et panier. Les aplatir en Products simples duplique le contenu de merchandising, supprime des combinaisons sélectionnables et modifie la façon dont les Orders identifient l’article acheté.
Signaux d’alerte précoces
| Signal | Ce qu’il indique |
|---|---|
| Les SKU parent et enfants ne sont pas listés séparément. | L’identité des Products configurables ou composites est incomplète. |
| Les composants de bundles ou grouped n’apparaissent que dans les descriptions. | Les relations vendables ont été réduites à du contenu. |
| Les fichiers de téléchargement et limites d’accès sont hors export Product. | Le Product downloadable ne peut pas fonctionner à partir de l’enregistrement Product seul. |
| Les options configurables sont mélangées avec des options personnalisées. | Les variantes portant stock et les choix saisis par le Customer sont confondus. |
Prévention
Classez les Products source selon leur fonctionnement commercial avant de mapper les champs. Conservez les liens enfants configurables, associations grouped, options de bundle, sens virtual, fichiers downloadable et le SKU exact qui porte l’inventaire et apparaît dans les lignes d’Orders.
Exemple de recommandation
Utilisez un Product configurable, un grouped, un bundle dynamique et un downloadable comme structures de référence. Enregistrez l’entité qui possède prix, stock, poids, médias et traitement des commandes.
Condition de réussite
Chaque Product de référence conserve son type, ses relations parent/enfant ou composants, ses valeurs sélectionnables, son identité SKU, sa source de prix, son fonctionnement d’inventaire, ses fichiers et le sens historique de ses lignes d’Orders.
Piège 2 : recréer les attributs sans leurs jeux ni leur portée
Ce qui se passe mal
Les attributs Magento prennent leur sens via le type de saisie, le vocabulaire d’options, le jeu d’attributs, le groupe, les indicateurs de vitrine, les paramètres de recherche et filtrage, le caractère obligatoire et la portée. Copier uniquement codes et valeurs peut produire des options dupliquées, filtres vides, formulaires Admin incorrects ou des valeurs qui s’écrasent entre websites et store views.
Signaux d’alerte précoces
| Signal | Ce qu’il indique |
|---|---|
| Des champs similaires utilisent des codes ou libellés d’options incohérents. | L’identité des attributs va se fragmenter entre Products. |
| L’appartenance aux jeux d’attributs manque dans l’inventaire source. | Les champs ne peuvent pas être affectés aux bonnes familles Product. |
| Les valeurs globales, website et store view sont mélangées dans une colonne. | Le sens propre à chaque portée sera écrasé. |
| La source utilise des attributs créés par des extensions au fonctionnement inconnu. | Un champ peut dépendre de code, indexation ou logique de vitrine au-delà de sa valeur. |
Prévention
Préservez la définition de l’attribut avant d’importer ses valeurs. Mappez type de saisie, IDs/libellés d’options, jeu, groupe, portée, usage recherche/filtrage/comparaison, visibilité et caractère obligatoire. Fusionnez les synonymes uniquement lorsqu’ils représentent le même vocabulaire gouverné.
Exemple de recommandation
Utilisez la couleur comme attribut de variante, la matière comme spécification filtrable et les consignes d’entretien comme contenu par store view. Représentez chacun avec le bon jeu, groupe, portée et fonctionnement en vitrine.
Condition de réussite
Les attributs de référence apparaissent dans les jeux et groupes prévus, conservent des options normalisées et la bonne portée, et soutiennent correctement variantes, filtres, recherche, comparaison et édition administrative.
Piège 3 : confondre options personnalisées et variations configurables
Ce qui se passe mal
Les options personnalisées peuvent recueillir un choix ou une saisie acheteur sans créer un Product distinct. Les Products configurables utilisent des Products simples associés avec SKU et stock indépendants. Transformer des variantes portant du stock en options personnalisées supprime l’identité enfant ; transformer une personnalisation en enfants configurables crée de fausses unités de stock.
Signaux d’alerte précoces
- Un choix possède son propre stock ou SKU mais est proposé comme simple champ texte ou dropdown.
- Une gravure ou un upload de fichier est proposé comme attribut configurable.
- Les variantes source ont des images ou prix distincts qui ne sont rattachés qu’au parent.
- Les lignes d’Orders ne permettent plus d’identifier le SKU enfant acheté.
Prévention
Classez chaque choix selon qu’il crée ou non une unité vendable gérée indépendamment. Utilisez des enfants configurables pour les variantes portant SKU et stock ; conservez les options personnalisées pour les choix sans inventaire et les saisies de l’acheteur. Préservez la valeur sélectionnée dans les lignes d’Orders historiques.
Exemple de recommandation
Représentez taille et couleur d’une chemise comme attributs configurables, l’emballage cadeau comme option personnalisée payante et la gravure comme texte saisi par l’acheteur.
Condition de réussite
Les vraies variantes conservent SKU enfant, prix, stock, médias et identité de ligne d’Order, tandis que personnalisation et services optionnels restent attachés au parent et à la ligne achetée sans générer de fausses variantes.
Piège 4 : aplatir la hiérarchie Magento dans un seul contexte
Ce qui se passe mal
Magento utilise websites, stores et store views pour contrôler affectation catalogue, Categories racines, valeurs localisées, URL, devises et configuration. Un transfert global peut écraser des traductions, publier des Products sur le mauvais website ou affecter la mauvaise Category racine.
Signaux d’alerte précoces
| Signal | Ce qu’il indique |
|---|---|
| La source possède plusieurs domaines, langues, marques ou régions. | Une seule portée par défaut ne représente pas l’architecture. |
| Des descriptions Product et URL keys diffèrent par vitrine. | Contenu store view et sens SEO nécessitent une propriété séparée. |
| Les stores utilisent des Categories racines ou sélections Product différentes. | Navigation et assortiment dépendent de la portée. |
| Il existe des prix ou groupes Customers propres à un website. | Les règles commerciales sont liées au contexte website. |
Prévention
Créez une carte de portée pour chaque website, store et store view. Séparez l’identité globale Product de ses affectations website et de son texte par store view. Conservez les codes de portée source utilisés par les imports, API ou intégrations.
Exemple de recommandation
Utilisez un Product vendu sur deux websites avec des descriptions store view, URL keys et affectations Category différentes. Enregistrez explicitement chaque valeur de portée.
Condition de réussite
Le Product représentatif apparaît uniquement sur les websites et stores prévus, utilise les bonnes Categories racines et valeurs localisées, et n’hérite ni contenu ni route de la mauvaise store view.
Piège 5 : croire que les lignes Category recréent navigation et historique d’URL
Ce qui se passe mal
Les enregistrements Category seuls ne recréent pas le parcours de vitrine. Affectation de Category racine, hiérarchie parent/enfant, appartenance Product, visibilité, présence au menu, URL keys, métadonnées, contenu CMS et URL rewrites déterminent si une Category soutient réellement la découverte et la continuité.
Signaux d’alerte précoces
- Les Categories existent dans l’Admin mais pas dans le menu.
- Les Products sont affectés à des branches inattendues.
- Les Categories source disposent de plusieurs URL historiques.
- Le contenu de landing page ou les liens internes sont stockés séparément.
Prévention
Préservez la hiérarchie Category et l’appartenance Product séparément du fonctionnement du menu et des routes. Mappez les Categories racines par store, identifiez les Categories cachées ou de landing page, conservez métadonnées et descriptions et créez des relations de rewrite explicites pour les chemins métier critiques.
Exemple de recommandation
Utilisez une Category de menu principale, une Category de landing page cachée et une Category ayant changé de position. Conservez pour chacune l’appartenance Product, la route cible et les redirections source.
Condition de réussite
Les Categories de référence apparaissent dans la hiérarchie de store prévue, contiennent les bons Products et contenus et résolvent les chemins source importants vers la bonne destination sans routes dupliquées ou non voulues.
Piège 6 : copier le stock sans contexte source, stock et disponibilité vendable
Ce qui se passe mal
Magento peut utiliser des sources physiques, des stocks, des affectations aux websites, des quantités par source et une disponibilité vendable. Une quantité positive peut toujours produire un Product indisponible si l’affectation source, stock, statut, réservations ou disponibilité des enfants est incorrecte.
Signaux d’alerte précoces
- Plusieurs entrepôts sont additionnés en une seule quantité.
- Les Products importés restent affectés uniquement à Default Source.
- Parents configurables et enfants affichent des disponibilités contradictoires.
- Un ERP ou WMS reste autoritaire mais ses clés articles manquent.
Prévention
Conservez codes de sources, quantités, statuts, affectations stocks, relations websites et identifiants d’entrepôts externes. Définissez si Magento ou un autre système possède l’inventaire après migration. Séparez quantité physique et valeur disponible pour le canal de vente.
Exemple de recommandation
Utilisez un SKU stocké dans deux entrepôts et un Product configurable dont les enfants ont des disponibilités différentes. Mappez chaque source au stock qui dessert le bon website.
Condition de réussite
Les Products représentatifs conservent quantités par source, affectations stock/website, disponibilité des enfants et clés externes, avec l’état vendable prévu sans aplatir les emplacements.
Piège 7 : importer Customers et Orders sans leurs instantanés opérationnels
Ce qui se passe mal
Les enregistrements Customer et Order peuvent exister alors que les adresses, groupes, sélections Products, remises, taxes, livraison, références de paiement, factures, expéditions, remboursements et historique des statuts perdent leur sens d’origine. La mise à jour d’un Customer peut également écraser des informations qui doivent rester figées dans un ancien Order.
Signaux d’alerte précoces
- Les adresses d’Orders sont reconstruites depuis le carnet actuel du Customer.
- Les lignes configurable, bundle ou grouped perdent leurs détails enfants.
- Les remboursements ou expéditions sont exportés séparément sans lien vers l’Order.
- Les noms de groupes Customers existent sans leur contexte historique de tarification.
Prévention
Séparez les données maîtres Customer des instantanés au moment de l’Order. Conservez SKU et options sélectionnées des lignes, adresses, totaux, remises, taxes, libellés de méthode, historique de statuts, factures, expéditions, remboursements, commentaires et IDs de transaction externes.
Exemple de recommandation
Utilisez un Order invité, un Order d’un Customer enregistré, un Order partiellement expédié et un Order remboursé contenant un Product configurable.
Condition de réussite
Chaque Order représentatif reste compréhensible sans dépendre de la configuration Product, Customer, prix, paiement ou livraison actuelle, et chaque expédition, facture, remboursement et identifiant externe demeure lié.
Piège 8 : traiter contenu CMS, médias et SEO comme un export de page générique
Ce qui se passe mal
Le contenu Magento peut comprendre CMS Pages, CMS blocks, widgets, descriptions Product/Category, médias, métadonnées, liens internes et routes propres aux store views. Un import de pages générique peut conserver le texte tout en perdant les références de blocks, directives de widgets, chemins médias, portée ou URL rewrites.
Signaux d’alerte précoces
- Le contenu CMS contient des directives, widgets ou URL de médias source.
- Des blocks sont réutilisés sur plusieurs pages ou store views.
- Les descriptions Product/Category contiennent des liens internes codés en dur.
- Les champs meta et URL keys diffèrent selon la portée.
Prévention
Classez séparément CMS Pages, blocks, widgets, contenu catalogue, médias, métadonnées et historique des rewrites. Traduisez les références vers les entités et médias cibles, préservez la portée store view et évitez de transférer un markup de thème obsolète comme s’il s’agissait de contenu métier.
Exemple de recommandation
Utilisez une CMS Page contenant un block réutilisable et une image média, ainsi qu’une landing page Category avec métadonnées localisées et ancienne URL.
Condition de réussite
Le contenu de référence s’affiche à travers les bonnes relations Page/block/widget/média/store view et les liens internes ainsi que routes historiques importantes atteignent la destination prévue.
Piège 9 : copier les tables d’extensions sans reconstruire leur propriété métier
Ce qui se passe mal
Les boutiques Magento utilisent souvent des extensions ou modules pour ERP, PIM, fidélité, abonnements, marketplaces, fiscalité, expédition, recherche, processus de commande et reporting. Leurs tables et attributs peuvent dépendre de code, événements, cron jobs, API ou taxonomies externes. Déplacer les lignes seules crée des valeurs orphelines.
Signaux d’alerte précoces
- Des champs importants utilisent des préfixes de modules ou IDs d’entités personnalisés.
- Les équipes ne savent pas quel système met à jour un champ.
- Les systèmes externes utilisent des clés absentes des entités Magento standards.
- Les flux source dépendent de tâches planifiées ou observers.
Prévention
Créez un registre de propriété pour chaque entité et champ personnalisé. Nommez l’enregistrement parent Product, Customer, Order ou contenu, le module/système externe, la clé durable, le sens de mise à jour et le flux cible. Excluez les résidus techniques abandonnés.
Exemple de recommandation
Suivez un ID Product PIM, un compte de fidélité et une référence d’Order marketplace depuis la table source jusqu’au propriétaire cible et à l’intégration future.
Condition de réussite
Chaque enregistrement personnalisé conservé possède un propriétaire connu, une relation parent valide, un identifiant stable et un flux continu ; aucun processus métier critique ne dépend de données copiées que la cible ne sait pas interpréter.
Piège 10 : supposer les données prêtes pour la vitrine avant l’actualisation des index et caches
Ce qui se passe mal
Magento utilise des index pour préparer catalogue, prix, Categories, groupes Customers et recherche à un usage efficace en vitrine. Les caches servent la configuration, les layouts, blocks et pages traités. Des imports importants ou des modifications directes en base peuvent laisser des index invalides ou des traitements planifiés incomplets : l’Admin affiche alors des valeurs différentes de la recherche, des filtres, prix ou listes de Categories.
Signaux d’alerte précoces
| Signal | Ce qu’il indique |
|---|---|
| Products présents dans l’Admin mais absents de la recherche ou des Categories. | Les données existent mais la visibilité indexée est obsolète ou incomplète. |
| Changements de prix ou groupes Customers visibles de façon incohérente. | Les index de prix ne reflètent pas encore l’état importé. |
| Les indexers demandent une réindexation, sont suspendus ou retardés. | Le résultat de vitrine ne peut pas être considéré comme actuel. |
| Des notifications de cache restent après changements catalogue/extension. | Les clients peuvent encore recevoir un rendu ancien. |
Prévention
Incluez la responsabilité des index et caches dans le runbook de migration. Vérifiez la disponibilité de cron et des indexers planifiés, documentez quels imports déclenchent une réindexation partielle ou complète et séparez réindexation et rafraîchissement du cache. Les processus d’import personnalisés doivent utiliser des opérations d’entités prises en charge ou prendre explicitement en compte les effets sur l’indexation.
Exemple de recommandation
Après un import catalogue représentatif, suivez un Product dans l’Admin, une Category, la recherche, les filtres et la tarification par groupe Customer tout en observant l’état des index associés.
Condition de réussite
Tous les indexers requis atteignent un état actuel, les caches présentent le rendu courant et Products, Categories, prix et attributs recherchables apparaissent de façon cohérente dans l’Admin et la vitrine.
Priorités transverses de prévention
La prévention des pièges Magento dépend de quatre structures liées : relations Product, données catalogue par portée, instantanés commerciaux historiques et propriété des extensions. Indexation et cache déterminent ensuite si ces enregistrements corrects deviennent visibles dans la vitrine.
| Couche | Contrôle requis |
|---|---|
| Structure Product | Conserver les distinctions parent/enfant, grouped, bundle, downloadable et options personnalisées. |
| Gouvernance des attributs | Garder code, options, jeu, portée et utilisation en vitrine reliés. |
| Portée des stores | Maintenir les différences website/store/store view pour contenu, prix, Categories et URL. |
| Instantanés historiques | Conserver le contexte Customer, Product, adresse, état, expédition et remboursement au moment de l’Order. |
| Visibilité de vitrine | Traiter index et caches comme la couche de diffusion des enregistrements par ailleurs corrects. |
Conclusion
Les échecs d’une migration Magento s’expliquent rarement par de simples volumes manquants de Products ou Customers. Le problème le plus fréquent est que types de Products, attributs, portée, inventaire, Categories, contenu, Orders et données d’extensions ne fonctionnent plus ensemble.
Le modèle cible le plus sûr conserve chaque relation au bon niveau et sépare les éléments historiques de la configuration actuelle. Lorsque catalogue, portée, inventaire, Orders, routes, données personnalisées et index sont cohérents, la boutique migrée devient réellement exploitable plutôt que simplement remplie.
Questions fréquentes
Pourquoi faut-il conserver les types de Products Magento au lieu de les aplatir ?
Chaque type définit des relations différentes de parent/enfant, prix, stock, fichiers et panier. Les aplatir modifie ce que le client sélectionne et ce que les équipes peuvent gérer ou retracer dans les Orders.
Quelle différence pratique entre attributs configurables et options personnalisées ?
Les attributs configurables sélectionnent des Products enfants indépendants avec leurs propres SKU et stocks. Les options personnalisées modifient ou personnalisent le Product parent sans créer d’unités de stock gérées indépendamment.
Pourquoi la portée des attributs est-elle importante ?
Les portées global, website et store view déterminent si une valeur est partagée ou localisée. Une mauvaise portée peut écraser traductions, prix, métadonnées et autres valeurs propres à une vitrine.
Une quantité importée suffit-elle à prouver qu’un Product Magento est disponible ?
Non. La disponibilité peut dépendre de l’affectation source, du stock, du statut, du website, des réservations et de l’état des Products enfants en plus de la quantité.
Faut-il toujours copier d’anciennes données d’extensions dans des attributs personnalisés ?
Non. Les enregistrements d’extensions peuvent dépendre d’entités, flux, code, systèmes externes ou taxonomies séparés. Seules les données disposant d’un propriétaire cible et d’un usage futur explicites doivent être conservées.
Pourquoi des Products peuvent-ils apparaître dans l’Admin mais manquer dans la vitrine ?
Magento utilise des index et caches pour préparer les données de catalogue, prix, Categories et recherche. Des index invalides ou retardés, un cron incomplet ou des caches obsolètes peuvent rendre des enregistrements corrects absents ou incohérents en vitrine.