Une migration vers Magento Open Source doit être pensée comme un travail d’interprétation des données, et pas uniquement comme un transfert. Magento peut recevoir des enregistrements e-commerce familiers tels que Products, Categories, Customers, Orders, images, Coupons, CMS Pages, Blog Posts et avis, mais ces enregistrements prennent leur sens à travers la structure du catalogue Magento, la gouvernance des attributs, la hiérarchie website/store/store view, la gestion de l’inventaire, le traitement des URL et l’écosystème d’extensions.
Une option Product de la plateforme source peut devoir devenir une relation de Product configurable, une option personnalisée, un choix de bundle, une relation grouped, un réglage de Product downloadable ou une valeur gérée en dehors du modèle de catalogue natif. Un champ source ne devrait devenir un attribut Magento que s’il a une finalité claire. Une valeur propre à une langue peut devoir être affectée à une store view au lieu d’écraser une valeur globale. Un tag Customer peut nécessiter une analyse des groupes de Customers ou un traitement personnalisé. Une URL historique peut demander une règle de réécriture ou de redirection plutôt qu’une simple copie de page.
La question principale n’est donc pas de savoir si Magento peut stocker ces données. La vraie question est de savoir si Magento peut les utiliser comme le marchand en a besoin pour vendre, organiser, filtrer, localiser, tarifer, traiter les commandes, assurer le support et maintenir la boutique après la mise en production.
Dans Magento, le sens des données dépend de leur structure
Magento Open Source est fortement configurable, mais cette configurabilité crée des responsabilités. Les types de Products, attributs, jeux d’attributs, websites, stores, store views, paramètres d’inventaire, chemins de Categories, URL keys, groupes de Customers, enregistrements Orders et extensions doivent être représentés explicitement dans le périmètre de migration.
Une boutique source offrant un export simple peut masquer une signification complexe. Des choix Product peuvent ressembler à de simples libellés alors qu’ils contrôlent en réalité l’identité du SKU, le prix, le stock, les images ou le traitement des commandes. Des tags Customers peuvent sembler informatifs alors qu’ils pilotent la tarification, la classe fiscale ou la segmentation. Des noms de Categories peuvent paraître être de simples regroupements alors qu’ils portent aussi une valeur de navigation et de SEO. Des champs issus de modules personnalisés peuvent être présents en base sans disposer d’une destination Magento standard.
| Structure source | Question d’interprétation dans Magento | Conséquence pour la migration |
|---|---|---|
| Variantes ou options Product | Les choix doivent-ils devenir des Products simples, des relations configurable, des options de bundle, des Products grouped, des options personnalisées ou des données traitées hors standard ? | Le comportement Product, les lignes d’Orders, l’inventaire et la maintenance dépendent de la structure choisie. |
| Champs Product personnalisés | Les valeurs doivent-elles devenir des champs natifs, des attributs Product, du contenu par store view, des références d’intégration ou des données gérées selon une portée particulière ? | La gouvernance des attributs influence le filtrage, la recherche, le merchandising, l’administration et les futurs imports. |
| Valeurs multilingues ou propres à un marché | Les valeurs doivent-elles être globales, propres à un website, à un store ou à une store view ? | Une mauvaise portée peut affecter les noms localisés, descriptions, affectations de Categories, métadonnées, URL keys et la visibilité. |
| Tags, rôles ou groupes de Customers | Les valeurs doivent-elles devenir des groupes de Customers, des métadonnées, des notes de segmentation ou des données personnalisées ? | La tarification, la fiscalité, les remises, le traitement du service et les rapports peuvent dépendre de la bonne interprétation. |
| Valeurs d’inventaire | Les quantités suffisent-elles ou faut-il aussi tenir compte des sources, statuts de stock, réservations, backorders et responsabilités de traitement des commandes ? | L’inventaire peut sembler complet alors que la disponibilité réelle à la vente reste incorrecte. |
| URL et routes historiques | Les routes doivent-elles devenir des URL keys, rewrites, redirections, CMS Pages, Blog Posts ou routes personnalisées ? | La continuité SEO et client dépend d’une planification au niveau des routes, pas uniquement de la présence du contenu. |
| Enregistrements appartenant à une extension | Magento représente-t-il ces données nativement ou faut-il un traitement spécifique ? | Les données d’extension non prises en charge ne doivent pas être aplaties dans des champs ordinaires. |
Cette approche centrée sur la structure évite une fausse impression de complétude. Les volumes d’enregistrements aident à vérifier que les données sont arrivées. Ils ne prouvent pas que Magento les interprète correctement.
Les types de Products modifient le fonctionnement du catalogue
La migration du catalogue Magento commence par le sens du type de Product. Un Product peut devoir devenir simple, configurable, grouped, bundle, virtual ou downloadable selon la façon dont le marchand le vend et selon la structure utilisée par la plateforme source. Les structures disponibles uniquement dans Adobe Commerce ou via une extension installée ne doivent pas être supposées présentes dans Magento Open Source.
Les Products simples sont souvent directs lorsqu’un article possède son propre SKU, son prix et ses propres attentes d’inventaire. Les Products configurables fonctionnent différemment : un Product visible en vitrine peut représenter plusieurs Products simples associés, chacun avec son propre SKU et son propre sens d’inventaire. Les bundles diffèrent encore, car l’acheteur peut sélectionner des composants ou configurations. Les grouped Products présentent ensemble des Products simples liés. Les Products virtuels et téléchargeables modifient les attentes de traitement des commandes et de lecture des Orders.
| Décision Product | Signification dans Magento | Conséquence de migration |
|---|---|---|
| Un Product, un SKU | Un Product simple peut suffire. | Le SKU porte son prix, sa visibilité, sa fiscalité, ses médias, ses Categories et son inventaire. |
| Un Product avec options taille/couleur et stock indépendant | Un Product configurable avec des Products simples associés peut être nécessaire. | Les SKU enfants, attributs de variante, stocks, images et l’identité des lignes d’Orders doivent rester reliés. |
| Kit ou package configurable | Une logique bundle ou une autre structure cible peut être nécessaire. | Le choix des composants, le calcul du prix, l’inventaire et le sens du traitement des commandes doivent être représentés délibérément. |
| Products associés vendus ensemble mais indépendants | Une structure grouped peut être pertinente. | La cible doit distinguer une relation de merchandising d’un package ou bundle obligatoire. |
| Service sans expédition | Un Product virtual peut être approprié. | L’enregistrement ne doit pas hériter d’une logique de livraison physique absente de la source. |
| Product numérique | Un Product downloadable peut être nécessaire. | Les fichiers, liens, droits après achat et la lecture des Orders historiques nécessitent une destination explicite. |
Le type de Product n’est pas qu’un choix de vitrine. Il influence la maintenance des imports, l’inventaire, les pages Products, les filtres, le processus de commande, les lignes d’Orders, les rapports et le support. Un Product peut sembler correct côté client tout en étant difficile à maintenir si son type Magento est mal choisi.
Les attributs et jeux d’attributs doivent être gouvernés
Les attributs représentent l’une des principales différences du modèle de données Magento. Ils décrivent les Products, alimentent les pages Products, contrôlent les types de saisie, servent la recherche et la navigation à facettes, peuvent être utilisés dans les comparaisons et influencer les promotions. Les jeux d’attributs servent de modèles aux familles de Products en déterminant quels attributs sont disponibles lors de leur création ou maintenance.
Cette puissance peut produire beaucoup de bruit après migration. De nombreuses plateformes source permettent des champs libres, tags, méta-valeurs, champs de plugins ou colonnes personnalisées. Tout transformer en attributs Magento peut entraîner des formulaires Product encombrés, des valeurs dupliquées, des filtres incohérents et des résultats de recherche de mauvaise qualité. À l’inverse, migrer trop peu peut supprimer des spécifications utiles, des valeurs de merchandising ou des identifiants d’intégration.
| Finalité du champ | Question de traitement dans Magento |
|---|---|
| Affichage sur la page Product | La valeur doit-elle être visible par le client et est-elle suffisamment propre pour être publiée ? |
| Recherche et navigation à facettes | La valeur est-elle assez cohérente pour servir au filtrage, au poids de recherche ou à la découverte ? |
| Comparaison de Products | La valeur aide-t-elle réellement l’acheteur à comparer les Products ? |
| Promotions ou merchandising | La valeur est-elle suffisamment fiable pour alimenter des règles ou des campagnes ? |
| Maintenance administrative | La valeur aide-t-elle les équipes ou ajoute-t-elle seulement du bruit ? |
| Continuité des intégrations | La valeur doit-elle devenir un attribut Magento, un champ appartenant à une extension, un identifiant inter-systèmes ou rester dans le système externe ? |
Les jeux d’attributs doivent eux aussi être délibérés. Un catalogue mêlant habillement, pièces détachées, fichiers téléchargeables, équipements, accessoires et services ne doit pas forcer automatiquement tous les Products dans un seul grand jeu d’attributs. Mais multiplier excessivement les jeux rend également la maintenance plus difficile. Le plan de migration doit conserver le sens des attributs sans transformer l’administration Magento en archive de champs.
Les niveaux website, store et store view modifient le placement des données
La hiérarchie website, store et store view de Magento peut modifier l’endroit où les valeurs transférées doivent être enregistrées. Une plateforme source peut utiliser des vitrines séparées, des sous-répertoires par langue, des marchés, domaines, groupes de Customers ou branches de catalogue. Magento peut représenter une partie de ces différences à travers ses niveaux de portée, mais la correspondance n’est jamais automatique.
Les store views servent fréquemment à gérer différentes langues, ce qui les rend particulièrement importantes pour les noms, descriptions, métadonnées, URL keys, CMS Pages et libellés de Categories localisés. Les websites et stores peuvent modifier la structure du catalogue, les Categories racines, le fonctionnement des comptes Customers, la configuration et l’organisation de la vitrine. Une même installation Magento peut contenir plusieurs websites, stores et store views : chaque valeur dépendant de la portée doit donc recevoir un niveau volontaire, et non hériter mécaniquement de l’organisation de la boutique source.
| Structure source | Question de portée Magento | Conséquence structurelle |
|---|---|---|
| Plusieurs langues | Quels champs doivent varier par store view ? | Des valeurs localisées peuvent écraser les valeurs globales ou apparaître dans la mauvaise vitrine. |
| Plusieurs marques ou domaines | Doivent-ils devenir des websites, stores, store views, Categories ou projets séparés ? | Les hypothèses sur le catalogue, les URL, les Customers et la configuration peuvent être mélangées. |
| Prix ou visibilité propres à un marché | Quel niveau cible peut représenter le fonctionnement attendu ? | Des Products peuvent apparaître dans le mauvais contexte commercial ou avec les mauvaises règles. |
| Categories racines distinctes | Quelle Category racine appartient à chaque store ? | La navigation peut être transférée sans correspondre à la vitrine prévue. |
| CMS Pages ou Blog Posts localisés | Quel contenu nécessite une affectation de store view ou une planification des routes ? | Le contenu peut exister tout en étant invisible, dupliqué ou mal affecté. |
La planification de la portée est l’une des raisons pour lesquelles une migration Magento ne peut pas être évaluée depuis une seule vue d’administration. Un même Product ou une même page peut nécessiter une validation dans plusieurs contextes de vitrine.
Categories, URL, CMS Pages et Blog Posts sont liés
La migration des Categories Magento ne doit pas être traitée comme un simple transfert de libellés. Les Categories peuvent structurer la navigation, la découverte des Products, les chemins d’URL, le merchandising et l’organisation des stores. Une arborescence source peut devoir être conservée, simplifiée, répartie entre plusieurs Categories racines, localisée, redirigée ou réorganisée selon le plan cible.
Les URL demandent la même attention. URL de Products, URL de Categories, routes de CMS Pages, Blog Posts, anciennes redirections et routes personnalisées peuvent toutes avoir une valeur SEO ou de continuité client. Une page Product peut exister après migration tout en nécessitant une décision spécifique pour son ancienne URL. Une CMS Page peut être présente alors que ses liens internes, métadonnées, menus et sa visibilité par store view nécessitent encore une vérification.
| Domaine | Question de migration Magento |
|---|---|
| Hiérarchie des Categories | Quelles Categories doivent servir à la navigation client, à l’organisation administrative ou aux deux ? |
| URL keys | Quelles valeurs URL pour Products, Categories, CMS Pages ou Blog Posts doivent être conservées ? |
| URL rewrites et redirections | Quels anciens chemins nécessitent une continuité de route ou une redirection ? |
| CMS Pages | Quelles pages de politique, d’atterrissage, de contenu ou de marque doivent exister dans Magento ? |
| Blog Posts | Les articles de blog font-ils partie du périmètre pris en charge, d’un blog externe ou d’un traitement propre à ce type de données ? |
| Liens internes | Les liens de contenu pointent-ils vers les bons chemins Magento après la mise en production ? |
| Routes par store view | Les routes localisées ou propres à un marché sont-elles correctement associées ? |
Ce domaine croise souvent migration des données, continuité SEO et configuration de la cible. L’article ne répète pas les principes SEO généraux, mais le plan de migration doit préserver le sens des routes lorsque leur continuité est importante.
Inventaire et traitement des commandes : la quantité ne suffit pas
Dans Magento, le sens de l’inventaire peut dépendre de la quantité, du statut de stock, du type de Product, de l’affectation aux sources, de la configuration des stocks, des backorders, des réservations, de la quantité vendable et du système qui reste propriétaire de l’inventaire. Dans Inventory Management, les sources représentent les emplacements physiques d’inventaire tandis que les stocks agrègent leur disponibilité pour les canaux de vente. Un export source contenant une seule colonne de quantité ne décrit donc pas nécessairement la manière dont Magento doit calculer la disponibilité réelle à la vente.
Les Products configurables renforcent cette exigence, car l’inventaire appartient généralement aux Products simples associés plutôt qu’au parent visible. Bundles et grouped Products peuvent ajouter d’autres dépendances. Les boutiques multi-sources ou pilotées par des entrepôts peuvent nécessiter une interprétation des sources/stocks, tandis qu’un inventaire contrôlé par l’ERP exige souvent une planification d’intégration au-delà des données migrées.
| Structure d’inventaire | Enjeu Magento | Relation cible nécessaire |
|---|---|---|
| SKU simple avec quantité | Un transfert de stock de base peut suffire. | Confirmer SKU, quantité, statut de stock et disponibilité en vitrine. |
| Product configurable | Le stock dépend des Products simples associés. | Stock des SKU enfants, options vendables, affichage parent et lignes d’Orders doivent rester reliés. |
| Bundle ou kit | La disponibilité des composants peut influencer la vente. | Les relations composant, prix, inventaire et traitement des commandes doivent disposer d’une structure cible explicite. |
| Stock par entrepôt ou multi-source | L’affectation source/stock peut être déterminante. | Confirmer le propriétaire des sources, la quantité vendable et les attentes de traitement des commandes. |
| Système d’inventaire externe | La migration peut ne transporter qu’un instantané. | Définir si Magento ou le système externe possède la relation continue de quantité et de disponibilité. |
L’inventaire doit être représenté comme une fonction opérationnelle. Une quantité peut être correctement transférée alors que la disponibilité vendable reste fausse si les relations Product, statuts de stock, affectations de sources, réservations ou responsabilités du système externe sont mal alignés.
Customers et Orders : conserver le sens historique et opérationnel
Les enregistrements Customers dans Magento peuvent comprendre l’identité du compte, les adresses, groupes de Customers, état de la newsletter, historique des Orders, contexte fiscal et champs personnalisés. Un champ Customer peut être purement informatif dans une plateforme et opérationnel dans une autre. Les groupes de Customers méritent une attention particulière, car ils peuvent influencer les remises, la classe fiscale, la segmentation, le traitement du service et parfois des attentes proches du B2B.
Les Orders doivent conserver suffisamment d’historique pour le service client, les références comptables, l’examen du compte, les retours et la continuité opérationnelle. Les anciens libellés de paiement et d’expédition doivent rester lisibles sans être confondus avec la configuration active des passerelles ou modes de livraison de la cible Magento.
| Zone de données | Question d’interprétation Magento |
|---|---|
| Groupes de Customers | Sont-ils informatifs, liés aux prix, aux taxes, à la segmentation ou à un traitement personnalisé ? |
| Adresses | Les adresses de facturation et d’expédition sont-elles suffisamment complètes pour le support et l’historique fiscal ? |
| Statuts d’Orders | Les statuts source doivent-ils surtout rester lisibles historiquement plutôt que reproduire exactement le flux source ? |
| Options Products dans les Orders | Les lignes transférées conservent-elles les attributs, options et personnalisations choisies ? |
| Libellés de paiement et d’expédition | S’agit-il de références historiques ou de paramètres actifs de la cible ? |
| Références externes | Les identifiants ERP, PIM, marketplace, CRM, abonnement ou comptabilité doivent-ils être conservés ? |
L’historique d’Orders Magento doit rester exploitable, mais il ne remplace pas la configuration cible du processus de commande, des paiements, taxes, expéditions ou processus de traitement des commandes en production.
Extensions, modules personnalisés et données source personnalisées ont besoin de limites
Les boutiques Magento Open Source reposent souvent sur des extensions, modules personnalisés, thèmes, intégrations et modifications de base de données. C’est l’une des différences les plus importantes avec des plateformes SaaS plus standardisées. Une valeur source peut n’avoir aucune place dans le modèle de données du cœur Magento, ou appartenir à une extension qui crée ses propres tables et son propre fonctionnement.
Les données de modules et extensions nécessitent une décision explicite sur leur destination. Certaines valeurs peuvent devenir des attributs Magento natifs ou des champs Customers. D’autres appartiennent à une extension installée, une table de module personnalisée, une intégration externe ou une structure historique qui ne doit pas être reproduite. Une simpla mise en correspondance de champs ne peut pas préserver un fonctionnement qui dépend du code d’un module, d’événements, d’observers, de tâches planifiées ou de relations personnalisées en base de données.
| Besoin | Orientation de traitement préférable |
|---|---|
| Filtrer les enregistrements Magento pris en charge | Définir quelles données natives et relations appartiennent au périmètre cible. |
| Faire correspondre différemment des champs pris en charge | Utiliser un attribut ou champ natif uniquement lorsque sa finalité cible est claire. |
| Configurer la sortie de données prise en charge | Garder la représentation cohérente avec la sémantique Magento des Products, Customers, Orders et niveaux de portée. |
| Conserver des tables de modules personnalisés | Identifier le module propriétaire et décider si une structure cible prise en charge existe. |
| Conserver des identifiants ERP, PIM, CRM, marketplace ou entrepôt | Les stocker comme clés inter-systèmes contrôlées uniquement si les intégrations futures les utilisent. |
| Interpréter des données source personnalisées | Classer leur sens métier avant de choisir un champ natif, un champ d’extension, un système externe ou une exclusion. |
| Recréer une règle métier issue d’une extension non prise en charge | Traiter cette règle comme une implémentation de la cible, pas comme une simple migration d’enregistrements. |
Cette frontière doit être claire avant l’approbation du périmètre. La flexibilité de Magento ne signifie pas que chaque fonctionnement personnalisé de la source possède une destination Magento standard.
Les relations Magento doivent produire des résultats cibles explicites
Un modèle cible Magento cohérent doit permettre la maintenance du catalogue, l’affichage en vitrine, la recherche et la navigation, le filtrage à facettes, l’interprétation de l’inventaire, la lecture de l’historique des Orders, le service client, la continuité des URL et les intégrations futures. Le résultat recherché est la clarté structurelle, et non la conservation maximale des champs.
| Domaine relationnel | Résultat attendu sur la cible |
|---|---|
| Types de Products | Chaque famille utilise une structure qui conserve le sens du SKU achetable, des options, de l’inventaire et des lignes d’Orders. |
| Attributs et jeux d’attributs | Les champs importants sont gouvernés, réutilisables et affectés uniquement aux familles de Products qui en ont besoin. |
| Portée | Les affectations website, store et store view conservent le contexte de marque, langue, domaine, contenu et catalogue. |
| Categories et URL | Categories racines, URL keys, rewrites et routes de contenu conservent l’intention de navigation et de route. |
| Inventaire | Sources, stocks, quantités, réservations et disponibilité vendable restent alignés sur les relations Product et la responsabilité du traitement des commandes. |
| Customers et Orders | Profils, groupes, adresses, lignes d’Orders, statuts et références historiques restent compréhensibles. |
| Extensions et données personnalisées | Champs natifs, données d’extensions, clés d’intégration et structures historiques exclues ont des responsables distincts. |
La migration Magento la plus propre n’est pas toujours celle qui transfère le plus de champs. C’est celle qui fournit à Magento suffisamment de données bien structurées pour fonctionner de manière fiable sans transporter le bruit inutile du système source.
Conclusion
Les différences du modèle de données de Magento Open Source sont importantes parce que Magento donne une signification structurelle aux enregistrements e-commerce. Types de Products, attributs, jeux d’attributs, websites, stores, store views, Categories, URL, inventaire, groupes de Customers, Orders, extensions et données personnalisées influencent tous le fonctionnement des données après la mise en production.
Un bon plan de migration vers Magento traduit volontairement les enregistrements source dans les structures Magento. Il conserve le sens métier utile, évite d’encombrer inutilement les attributs et sépare les relations natives de Magento du fonctionnement appartenant aux extensions et aux systèmes externes.
Questions fréquentes
Pourquoi les types de Products Magento sont-ils importants pendant la migration ?
Parce qu’ils déterminent la manière dont Magento interprète le catalogue. Products simple, configurable, grouped, bundle, virtual et downloadable peuvent modifier l’identité des SKU, le stock, l’affichage des prix, les lignes d’Orders, le traitement des commandes et la maintenance. Un Product peut sembler correct en vitrine tout en étant mal structuré si son type ne correspond pas au modèle métier.
Tous les champs personnalisés de la source doivent-ils devenir des attributs Magento ?
Non. Les attributs Magento doivent être créés ou transférés uniquement lorsqu’ils servent les pages Products, la recherche, le filtrage, la comparaison, le merchandising, l’administration, les rapports ou la continuité des intégrations. Transformer chaque champ source en attribut peut encombrer l’administration et produire des filtres incohérents côté client.
Pourquoi la portée des store views est-elle importante ?
Les store views peuvent contrôler des valeurs localisées comme les noms de Products, descriptions, métadonnées, libellés de Categories, CMS Pages et URL keys. Sans planification de la portée, des valeurs localisées peuvent écraser le contenu global ou apparaître dans la mauvaise vitrine.
Magento Open Source gère-t-il les données propres à Adobe Commerce de la même manière ?
Non. Magento Open Source et Adobe Commerce sont liés mais ne constituent pas des cibles de planification identiques. Les structures propres à Adobe Commerce ne doivent être supposées présentes que si la cible Magento Open Source représente le même sens métier via sa configuration native, une extension installée, un système externe ou une implémentation distincte.
Quand les données Magento nécessitent-elles un traitement cible séparé ?
Lorsqu’elles dépendent de tables d’extensions non prises en charge, de champs de modules personnalisés, de relations de base de données non standard, d’identifiants de systèmes externes ou d’un fonctionnement sans destination native dans Magento Open Source.
Comment traiter les champs appartenant à des extensions et les identifiants externes ?
Il faut identifier le propriétaire et l’usage métier futur de chaque valeur avant de choisir sa destination. Un attribut natif peut convenir à des données de catalogue réutilisables, tandis que des tables de modules, clés ERP, références marketplace ou métadonnées de workflow peuvent nécessiter une destination appartenant à une extension, une clé d’intégration ou une exclusion documentée. La présence de la valeur ne suffit pas à définir son sens cible.