Planifier une migration vers Adobe Commerce ne consiste pas seulement à vérifier si les produits, clients, commandes, catégories, CMS Pages, Blog Posts et Reviews peuvent être transférés. La question la plus importante est de savoir si ces enregistrements peuvent soutenir le modèle d’exploitation d’entreprise qu’Adobe Commerce devra faire fonctionner après le lancement. Structure produit, périmètre des vitrines, relations B2B entre entreprises, catalogues partagés, groupes de clients, Content Staging, responsabilité du stock, URL et intégrations changent tous la manière d’interpréter les données de la boutique source.
Une boutique source peut présenter des enregistrements propres tout en ne disposant pas de la structure requise pour Adobe Commerce. Un client peut exister sans l’autorité liée à son entreprise. Un produit peut être présent sans le bon jeu d’attributs, la bonne affectation au website, la relation correcte avec ses SKU enfants ou la visibilité attendue dans un catalogue partagé. Une page peut être migrée tout en perdant son calendrier de campagne, sa localisation ou le sens de son itinéraire URL. L’examen du modèle de données doit donc porter sur le fonctionnement métier, et non sur la seule présence des champs.
Le sens des données Adobe Commerce commence par le modèle d’exploitation d’entreprise
Adobe Commerce reprend une grande partie du socle de données de la famille Magento, mais l’interprétation de la migration change parce que la plateforme est souvent choisie pour des opérations e-commerce davantage gouvernées. Un même produit, client, ordre ou page peut devoir participer à une structure multivitrine, à des achats B2B, à des règles d’approbation, à une tarification par groupe de clients, à une visibilité de catalogue partagé, à des intégrations d’entreprise ou à des activités de contenu planifiées.
| Domaine de données | Interprétation dans Adobe Commerce | Conséquence pour la planification |
|---|---|---|
| Produits | Types de produits, SKU enfants, attributs, jeux d’attributs, websites, catégories, prix, visibilité et relations de stock. | Les données catalogue doivent soutenir le fonctionnement commercial de niveau entreprise, pas seulement l’affichage. |
| Clients | Acheteurs individuels, groupes de clients, utilisateurs d’entreprise, adresses, historique des commandes et autorité du compte. | Les données clients peuvent devoir préserver à la fois l’identité et le contexte d’achat. |
| Entreprises | Administrateurs, utilisateurs, rôles, autorisations, crédit, devis, bons de commande et statut d’approbation. | Les données B2B doivent être cadrées avant de traiter les clients comme des comptes ordinaires. |
| Catalogues partagés | Visibilité et tarification propres à certains acheteurs via des groupes de clients ou l’affectation à une entreprise. | L’existence d’un produit ne garantit pas qu’il soit visible par tous les acheteurs. |
| Périmètre des vitrines | Websites, stores, store views, langue, devise, contenu, configuration et affectation catalogue. | Les données multimarques, régionales ou multilingues ne doivent pas être aplaties. |
| Contenu et campagnes | CMS Pages, CMS blocks, mises à jour planifiées, calendrier des promotions, landing pages et éléments de campagne. | Une migration de contenu statique peut perdre une intention commerciale liée au calendrier. |
| Stock | Sources, stocks, disponibilité à la vente, affectation aux canaux et propriété du stock par des systèmes externes. | La quantité doit être examinée selon la structure de traitement logistique, pas seulement selon le nombre de SKU. |
| URL | Clés d’URL, réécritures, redirections, chemins localisés, routes personnalisées et pages d’atterrissage à forte valeur. | La continuité SEO dépend du sens et du périmètre des routes, pas seulement du transfert des pages. |
La question pratique est de savoir si chaque enregistrement dispose d’une structure suffisante pour continuer à fonctionner dans Adobe Commerce. Même un enregistrement pris en charge peut nécessiter une relation cible différente, une affectation de périmètre, une décision de propriété ou une limite d’implémentation lorsqu’il porte des règles métier de niveau entreprise.
Les données produit dépendent du type, des attributs et de la gouvernance
La migration des produits vers Adobe Commerce demande une interprétation attentive, car les données produit peuvent influer sur le fonctionnement de la vitrine, le merchandising, les filtres, la recherche, les prix, le stock et les intégrations. Le type de produit constitue la première couche de sens. Les produits simple, configurable, grouped, virtual, bundle et downloadable ne se comportent pas de la même manière. Un article source comportant des options peut devoir devenir un produit configurable associé à des produits simples enfants. Un kit ou lot source doit être examiné avant d’être considéré comme bundle, grouped, géré de manière personnalisée ou exclu du comportement standard.
Les produits configurables sont particulièrement sensibles. Le produit parent offre à l’acheteur une expérience produit unique, tandis que les produits simples enfants portent le sens commercial au niveau du SKU. Taille, couleur, matière, format de colis ou spécification technique peuvent influer sur l’identité du SKU, le prix, l’image, le stock et les références d’intégration. Si ces relations sont aplaties, le catalogue peut sembler complet alors que l’achat, le traitement logistique, le reporting ou la synchronisation ERP ne fonctionnent plus correctement.
Les attributs et jeux d’attributs ajoutent une autre couche de gouvernance. Les attributs peuvent contrôler les champs visibles, la recherche, la navigation à facettes, la comparaison, les imports/exports, les conditions promotionnelles, la maintenance dans l’interface d’administration et la logique des intégrations. Les jeux d’attributs regroupent les familles de produits dans des modèles structurés. Un champ personnalisé de la source ne doit pas être converti automatiquement en texte descriptif s’il alimente le filtrage, la tarification, la synchronisation PIM, la recherche, le reporting ou des opérations en aval.
| Structure produit | Ce qu’il faut interpréter | Pourquoi cela compte dans Adobe Commerce |
|---|---|---|
| Type de produit | Structure simple, configurable, grouped, bundle, virtual, downloadable ou traitée de façon personnalisée. | Le type de produit détermine la manière dont l’acheteur sélectionne et achète l’article. |
| Relation des SKU enfants | Affectation parent-enfant, libellés d’options, images, écarts de prix, stock et identifiants. | Des relations rompues peuvent rendre les produits visibles sans les rendre commercialement utilisables. |
| Attributs | Champs d’affichage, champs recherchables, filtrables, entrées de règles, identifiants d’intégration et champs administratifs. | Les décisions d’attributs influent sur la gouvernance du catalogue et la découverte des produits. |
| Jeux d’attributs | Modèles par famille de produits et champs requis. | Une mauvaise conception rend la maintenance du catalogue difficile après la migration. |
| Affectation aux catégories | Navigation, merchandising, périmètre, visibilité et comportement des URL. | Un sens de catégorie incorrect peut dégrader la découverte, le SEO et la confiance des acheteurs. |
| Relations produit | Produits associés, upsells, cross-sells, accessoires, remplacements et références de compatibilité. | La perte de relations peut affaiblir la conversion et les processus commerciaux. |
L’objectif n’est pas de recréer exactement chaque champ source. Il faut préserver le sens commercial du catalogue dans une structure qu’Adobe Commerce peut exploiter et gouverner, sans transformer le catalogue cible en archive des champs de l’ancien système.
Le périmètre des vitrines change le sens des enregistrements
Le périmètre des vitrines Adobe Commerce peut modifier la signification de presque tous les enregistrements migrés. Une plateforme source peut représenter marques, régions, langues, portails B2B, canaux retail, espaces grossistes ou vitrines internationales au moyen de catégories, domaines, tags clients, marchés, plugins ou champs personnalisés. Adobe Commerce peut exiger que ces distinctions deviennent des websites, stores, store views, arborescences de catégories, groupes de clients, catalogues partagés, règles de configuration ou variantes de contenu.
Le périmètre doit être défini avant la mise en correspondance détaillée. Un nom de produit peut être global alors que les descriptions varient selon la store view. Une CMS Page peut nécessiter plusieurs versions localisées. Un produit peut appartenir à un website et pas à un autre. Un chemin de catégorie adapté à une vitrine retail peut être inapproprié pour un catalogue B2B privé. Un prix peut dépendre du groupe de clients ou de l’accès à un catalogue partagé plutôt que du seul produit.
Les erreurs de périmètre sont souvent invisibles dans les comptages. Le nombre attendu de produits, catégories, clients ou pages peut être transféré alors qu’une vitrine reçoit la mauvaise langue, le mauvais prix, la mauvaise catégorie, la mauvaise visibilité ou le mauvais contexte URL. Le modèle cible doit donc prévoir une affectation explicite pour chaque marque, région, langue, website, store, store view, segment B2B et contexte de catalogue privé important.
Les données clients peuvent combiner identité individuelle et autorité d’entreprise
Dans Adobe Commerce, les données clients peuvent représenter bien plus que l’identité d’un compte individuel. Elles peuvent inclure groupes de clients, relations à des comptes d’entreprise, administrateurs, utilisateurs, autorisations, devis, bons de commande, crédit d’entreprise, moyens de paiement, règles de livraison, adresses légales et affectation à des catalogues partagés. Une fiche client peut être transférée correctement comme compte individuel tout en échouant si l’acheteur perd son autorité dans l’entreprise ou son accès au catalogue.
La planification B2B doit distinguer l’identité client du contrôle des achats. Adobe Commerce associe des comptes clients standards à des comptes Company. Une Company peut contenir un administrateur, des équipes, utilisateurs, rôles, autorisations et relations d’approbation. Une adresse e-mail, une adresse postale et un historique de commandes peuvent suffire pour un compte B2C, mais la continuité B2B peut exiger l’identité de l’entreprise, son adresse légale, l’affectation de l’administrateur, la hiérarchie organisationnelle, le statut du compte, les références fiscales, le contexte de crédit et les identifiants externes du compte.
| Couche client | Ce qu’il faut examiner | Conséquence pour la migration |
|---|---|---|
| Compte individuel | E-mail, nom, adresse, statut, stratégie de mot de passe et association aux commandes. | Les acheteurs doivent retrouver une continuité de compte reconnaissable. |
| Groupe de clients | Remise, fiscalité, catalogue, tarification ou traitement de vitrine. | L’affectation au groupe peut modifier l’expérience de l’acheteur et l’exactitude des commandes. |
| Compte d’entreprise | Administrateur, adresse légale, utilisateurs, hiérarchie et statut du compte. | Les achats B2B peuvent échouer si la structure de l’entreprise n’est pas planifiée. |
| Contrôles d’achat | Devis, bons de commande, crédit, moyens de paiement, modes de livraison et autorisations. | Les processus B2B peuvent nécessiter une configuration ou une implémentation cible séparée au-delà des Customers migrés. |
| Identifiants externes | ID ERP, ID CRM, ID revendeur, référence de chargé de compte, ID de contrat ou référence fiscale. | Des systèmes externes peuvent dépendre d’identifiants invisibles lors d’une simple revue de la vitrine. |
Les données d’entreprise Adobe Commerce ne doivent pas être traitées comme une simple liste de champs client. Elles forment une structure d’achat. Le périmètre doit distinguer les identités et relations transférables des autorisations d’entreprise, contrôles d’achat, règles de crédit et intégrations externes qui nécessitent une implémentation cible séparée.
Les catalogues partagés rendent l’accès produit spécifique à l’acheteur
Les catalogues partagés rendent la visibilité des produits et leur tarification spécifiques à l’acheteur. Adobe Commerce peut maintenir un catalogue partagé public ainsi que des catalogues partagés personnalisés affectés à des comptes Company. Un produit peut exister dans le catalogue principal sans appartenir à tous les catalogues partagés. Un prix personnalisé peut être correct pour une Company et inadapté pour une autre. Les autorisations de catégories peuvent aussi changer lorsque Shared Catalog est activé.
Les plateformes sources représentent souvent ces règles autrement : listes de prix grossistes, tags clients, groupes de revendeurs, catégories masquées, listes de produits privées, tarification contractuelle, règles pilotées par ERP ou champs personnalisés. Lors de la migration, ces structures doivent être interprétées et représentées dans le modèle cible plutôt que transférées mécaniquement.
Cette représentation doit répondre à quatre questions : quelles entreprises doivent avoir accès au catalogue, quels produits appartiennent à chaque catalogue, quels prix personnalisés s’appliquent et quelles autorisations de catégories ou règles de visibilité doivent être représentées dans Adobe Commerce ? Les listes de prix, catégories masquées, tags revendeurs et références contractuelles ERP de la source constituent des indices sur la relation attendue ; ils ne sont pas automatiquement équivalents à un catalogue partagé.
Les Orders portent un contexte commercial, B2B et d’intégration
La migration des Orders vers Adobe Commerce doit préserver un historique utile, sans laisser entendre que chaque comportement du processus de commande source devient un comportement actif d’Adobe Commerce. Les commandes historiques peuvent inclure lignes de commande, produits, quantités, remises, taxes, livraison, facturation, références clients, statuts, références de paiement, remboursements, factures, expéditions, avoirs, bons de commande, références de devis, contexte d’entreprise et identifiants externes.
Pour les boutiques B2B et d’entreprise, cet historique demande souvent une interprétation supplémentaire. Une commande source peut appartenir à une entreprise et pas seulement à un client individuel. Une remise historique peut refléter un prix contractuel ou un prix de catalogue partagé. Un mode de paiement peut dépendre de règles d’entreprise. Un bon de commande peut porter une signification d’approbation. Pour les équipes support, un numéro de commande ERP peut être plus important que le numéro de commande de la vitrine.
| Contexte de commande | Ce qu’il faut préserver ou classifier | Pourquoi cela compte |
|---|---|---|
| Relation client-entreprise | Compte acheteur, compte d’entreprise, relation administrateur/utilisateur et contexte de groupe. | Les équipes support doivent comprendre qui a passé la commande et sous quel compte. |
| Détail financier | Sous-total, remises, taxes, livraison, remboursements, avoirs, factures et références de paiement. | L’historique doit rester lisible pour le service client et la réconciliation. |
| Contexte de processus B2B | Devis, bon de commande, crédit de compte, approbation ou référence contractuelle. | Le sens historique B2B peut dépasser les données de commande ordinaires. |
| État de traitement logistique | Expédition, traitement partiel, annulation, retour, référence d’entrepôt ou statut ERP. | Les opérations doivent pouvoir comprendre ce qui s’est produit après l’achat. |
| Identifiants externes | ID de commande ERP, ID comptable, ID marketplace, opportunité CRM ou référence d’entrepôt. | La continuité des intégrations peut dépendre d’identifiants situés hors des champs standards de commande. |
Le modèle de commande cible doit tenir compte des relations distinctes portées par les commandes B2C, B2B, remboursées ou créditées, sensibles aux remises ou à la fiscalité, ainsi que des références externes et du contexte d’entreprise ou de groupe de clients. Ces relations déterminent si les Orders historiques restent compréhensibles après la migration.
Le contenu, les campagnes et les URL nécessitent des interprétations distinctes
La migration de contenu Adobe Commerce peut inclure CMS Pages, CMS blocks, contenu de catégories, descriptions produit, landing pages, Blog Posts lorsque pertinent, médias, métadonnées et éléments promotionnels. Dans une boutique d’entreprise, ce contenu peut aussi dépendre du calendrier des campagnes, des vitrines régionales, du calendrier de merchandising, de la gouvernance de marque, de la revue juridique ou de circuits d’approbation.
Content Staging change l’interprétation du contenu lorsque la temporalité compte. Adobe Commerce peut programmer des mises à jour pour les Products, Categories, règles de prix catalogue et panier, CMS Pages et CMS blocks dans le cadre de campagnes. Une landing page, une bannière de catégorie, une promotion ou un changement de prix planifié peut exister comme contenu tout en perdant son intention commerciale s’il est réduit à un enregistrement statique. Le périmètre doit donc distinguer le contenu permanent, les campagnes futures, les changements planifiés actifs et les éléments de campagnes expirées.
Les URL demandent la même séparation. Les clés d’URL produit, clés d’URL de catégorie, chemins CMS, réécritures, chemins localisés, redirections et routes de landing pages personnalisées doivent être examinés selon leur valeur métier. Un comptage de pages peut être correct alors que des pages produit à forte valeur, des points d’entrée B2B, des portails revendeurs, des URL régionales ou des pages de campagne perdent leur continuité.
Identifier les données détenues par les intégrations avant toute mise en correspondance
Les projets Adobe Commerce dépendent souvent d’un ERP, PIM, CRM, OMS, WMS, système fiscal, de paiement, livraison, marketplace, fidélité, abonnement, analyse, recherche, personnalisation ou marketing. Ces systèmes peuvent détenir des champs et identifiants qui ne sont pas évidents lors d’une revue de la vitrine.
Exemples : identifiants produits ERP ou PIM, identifiants de comptes d’entreprise, identifiants revendeurs, contrats, références de listes de prix, codes de stock d’entrepôt, identifiants d’exonération fiscale, références de comptes CRM, identifiants d’articles marketplace, identifiants d’abonnement ou numéros de commandes externes. Si ces valeurs sont supprimées, renommées ou placées dans des champs non pris en charge, la boutique migrée peut sembler correcte alors que les processus en aval échouent.
Les données détenues par des intégrations doivent être classifiées avant de définir la mise en correspondance finale entre la source et la cible. Une valeur peut appartenir à un attribut natif, un champ détenu par une extension, une clé intersystème, une charge utile d’intégration séparée ou une structure historique à exclure. La décision doit suivre le système qui reste propriétaire de la valeur, et non l’endroit où elle se trouvait par hasard dans la source.
Les relations Adobe Commerce nécessitent une responsabilité explicitement définie
Un modèle cible Adobe Commerce complet attribue clairement la responsabilité et le sens tout au long de la chaîne de relations. Les Products soutiennent la gouvernance du catalogue ; les clients et entreprises préservent l’autorité d’achat ; les Orders conservent un historique exploitable par le support ; le contenu garde le bon contexte de vitrine et de campagne ; les URL préservent l’intention des routes ; et les champs d’intégration restent traçables jusqu’aux systèmes qui continueront à les utiliser.
Une revue utile des données doit demander :
- Les produits peuvent-ils être maintenus par famille, jeu d’attributs, website et périmètre de vitrine ?
- Les acheteurs B2B peuvent-ils accéder au bon catalogue, au bon prix, au bon compte, aux devis, bons de commande et contexte de crédit appropriés ?
- Les équipes support peuvent-elles lire les commandes historiques sans revenir au système source pour en comprendre le sens de base ?
- Le contenu et les URL peuvent-ils soutenir le lancement, la continuité SEO et les besoins de campagne ?
- Les systèmes externes peuvent-ils encore reconnaître les enregistrements migrés dont ils dépendent ?
Si le périmètre ne permet pas de répondre à ces questions, les relations cibles restent indéfinies même lorsque les enregistrements sources sont disponibles.
Conclusion
Adobe Commerce change la planification de la migration parce que les données portent souvent une logique d’exploitation d’entreprise. Les Products ne sont pas seulement des articles : ils sont liés à des types de produits, attributs, jeux d’attributs, websites, store views, catégories, relations de stock et références d’intégration. Les Customers ne sont pas seulement des profils : ils peuvent être des entreprises, utilisateurs, administrateurs, groupes de clients, acheteurs de catalogues partagés et participants à des approbations. Le contenu, les URL, les Orders et le stock peuvent dépendre du périmètre, du calendrier et de systèmes externes.
Une migration Adobe Commerce robuste traite le travail sur le modèle de données comme une représentation du sens métier. L’objectif est de placer les enregistrements dans une structure qui soutient la gouvernance du catalogue, les achats B2B, les périmètres de vitrines, la continuité du contenu et la responsabilité des intégrations.
Questions fréquentes
Pourquoi la migration des données Adobe Commerce exige-t-elle plus qu’une simpla mise en correspondance de champs ?
Parce que de nombreux enregistrements Adobe Commerce portent un sens opérationnel. Products, Customers, Orders, contenu, URL et stock peuvent influer sur les achats B2B, les catalogues partagés, les périmètres de vitrines, la gouvernance des attributs et la responsabilité des intégrations.
En quoi les catalogues partagés Adobe Commerce diffèrent-ils de catégories ordinaires ?
Les catégories organisent la navigation et le merchandising du catalogue. Les catalogues partagés peuvent contrôler une visibilité des produits et une tarification propres à certains acheteurs, généralement en relation avec des entreprises ou groupes de clients. Ils doivent être planifiés comme des règles d’accès et de prix, et non comme une simple structure de catalogue.
Qu’est-ce qui rend les données clients plus complexes dans Adobe Commerce ?
Elles peuvent inclure comptes individuels, groupes de clients, comptes d’entreprise, utilisateurs, administrateurs, rôles, crédit, autorisations de devis, autorisations de bons de commande et affectations à des catalogues partagés. Un client peut migrer comme compte tout en perdant son sens d’achat B2B.
Les données de Content Staging doivent-elles être traitées comme du contenu CMS ordinaire ?
Non. Les mises à jour de campagnes sensibles au temps, le contenu planifié, les pages promotionnelles et les changements propres au lancement doivent être examinés séparément. Certains contenus peuvent migrer comme contenu CMS stable, tandis que le calendrier et les règles d’approbation peuvent nécessiter une configuration Adobe Commerce ou une reconstruction manuelle.
Quand des données Adobe Commerce nécessitent-elles un traitement cible séparé ?
Un traitement de migration ou une implémentation cible séparée est nécessaire lorsque le périmètre comprend des données d’extension non prises en charge, des structures de base de données personnalisées, des relations d’entreprise ou de catalogue non standard, des identifiants de systèmes externes ou un fonctionnement sans destination native dans Adobe Commerce.
Comment représenter les identifiants externes dans Adobe Commerce ?
Conservez un identifiant externe uniquement lorsqu’un ERP, CRM, PIM, système logistique, fiscal ou de reporting encore actif en dépend. Déterminez si la valeur appartient à un champ natif, un champ détenu par une extension, une référence d’intégration ou une clé intersystème documentée. Le résultat attendu est que les équipes et systèmes connectés puissent retracer l’enregistrement migré sans exposer cet identifiant comme contenu de vitrine ni le confondre avec l’ID d’entité Adobe Commerce.