Adobe Commerce doit être envisagé comme un environnement d’exploitation e-commerce pour l’entreprise, et non comme une simple vitrine plus imposante issue de l’écosystème Magento. Une migration vers Adobe Commerce peut porter sur des enregistrements courants tels que les Products, Categories, Customers, Orders, Reviews, Coupons, CMS Pages et Blog Posts, mais la plateforme ajoute souvent une couche plus structurante de gouvernance métier : comptes d’entreprise, rôles d’acheteurs, catalogues partagés, processus de devis, règles de bons de commande, vitrines avec périmètres distincts, contenu planifié, modules personnalisés et dépendances à des systèmes externes.
Cette dimension d’entreprise change le point de départ de la planification. Il ne suffit pas de se demander si les enregistrements de la boutique source peuvent être transférés. La question déterminante est de savoir si les données migrées permettront de préserver les règles commerciales, les relations avec les acheteurs, le périmètre des vitrines, les règles de tarification, les opérations de contenu et les responsabilités d’intégration attendus après la mise en production.
Adobe Commerce partage un socle de la famille Magento avec Magento Open Source. Les types de produits, attributs, jeux d’attributs, niveaux website/store/store view, catégories, URL et personnalisations apportées par des extensions restent donc essentiels. La différence tient au fait qu’Adobe Commerce ajoute souvent des exigences d’exploitation de niveau entreprise à ces structures. La planification doit conserver la rigueur du modèle de données Magento tout en accordant une attention supplémentaire au B2B, à la gouvernance, à la planification du contenu, à l’échelle du projet et à la répartition des responsabilités.
Adobe Commerce comme plateforme cible pour l’entreprise
Adobe Commerce est généralement retenu lorsque la boutique cible exige davantage de contrôle opérationnel qu’une vitrine à petit catalogue. L’entreprise peut avoir besoin de structures de comptes B2B, d’une visibilité du catalogue comparable à des conditions contractuelles, de règles d’achat propres à chaque société, de plusieurs vitrines, de contenu localisé, d’un merchandising gouverné, de circuits d’approbation plus formels et d’intégrations avec un ERP, un PIM, un CRM, un moteur fiscal, un entrepôt, une marketplace, des outils d’analyse ou des systèmes marketing.
Ces exigences transforment la migration en travail sur la structure métier. Les produits, les clients, l’historique des commandes et le contenu restent importants, mais ils doivent être examinés à travers l’environnement Adobe Commerce qui devra réellement les exploiter.
| Domaine Adobe Commerce | Incidence sur la migration | Décision à prendre en amont |
|---|---|---|
| Niveaux website, store et store view | Les vitrines peuvent représenter des régions, des marques, des langues, des modèles économiques ou des contextes de catalogue différents. | Déterminer quelles valeurs sont globales et lesquelles relèvent d’un website, d’un store ou d’une store view. |
| Types de produits et attributs | La structure produit peut influer sur les variations, les filtres, la recherche, le merchandising et les intégrations. | Classer les types de produits, attributs et jeux d’attributs avant la migration. |
| Comptes d’entreprise B2B | Les clients professionnels peuvent disposer d’administrateurs, d’utilisateurs, de rôles, d’autorisations, de crédit, de devis et de processus de bons de commande. | Déterminer si les données clients de la source correspondent à des comptes individuels, à des données d’entreprise ou à des relations personnalisées. |
| Catalogues partagés et tarification | La visibilité des produits et les prix peuvent varier selon le contexte de l’acheteur. | Déterminer si les listes de prix, groupes de clients ou tarifs contractuels de la source nécessitent une mise en correspondance prise en charge, une configuration cible ou un examen hors périmètre standard. |
| Content Staging | Les changements de merchandising et de contenu peuvent être programmés. | Distinguer le contenu migré de la planification des campagnes et de leur gouvernance dans la cible. |
| Extensions et intégrations | Les boutiques d’entreprise dépendent souvent de modules et de systèmes externes. | Identifier tôt les données d’extension non prises en charge, les identifiants externes et les processus personnalisés. |
Adobe Commerce peut prendre en charge des opérations e-commerce complexes, mais la qualité de la migration dépend de la définition préalable des structures cibles. Sans ces décisions, les données peuvent être présentes dans Adobe Commerce tout en restant inadaptées au modèle commercial attendu.
Le socle de la famille Magento reste déterminant
Adobe Commerce appartient à l’architecture de la famille Magento. De nombreuses problématiques rencontrées avec Magento Open Source restent donc valables : types de produits, attributs, jeux d’attributs, catégories, hiérarchie des boutiques, réécritures d’URL, groupes de clients, historique des commandes, hypothèses liées au stock, modules et champs personnalisés.
L’erreur serait d’en conclure qu’il suffit de reprendre à l’identique la planification prévue pour Magento Open Source. Adobe Commerce ajoute des implications de niveau entreprise. Un produit source doit toujours être correctement représenté selon les types de produits de la famille Magento, mais il peut aussi devoir respecter une visibilité propre à certains acheteurs ou une tarification de catalogue partagé. Une fiche client doit conserver des données de profil exactes, mais elle peut également devoir être rattachée à une entreprise, à un rôle, à des autorisations d’achat ou à un contexte de représentant commercial. Une CMS Page peut être migrée, mais son calendrier de publication peut aussi dépendre de mises à jour planifiées ou de règles de gouvernance de campagne.
Cette relation doit donc servir de contrôle de périmètre :
| Préoccupation commune à la famille Magento | Extension propre à Adobe Commerce |
|---|---|
| Produits configurables et produits simples associés | Visibilité propre à l’acheteur, tarification B2B, commandes basées sur le compte et échantillons de validation de niveau entreprise. |
| Attributs et jeux d’attributs | Gouvernance du catalogue entre services et cohérence avec les systèmes PIM ou ERP. |
| Niveaux website/store/store view | Séparation des marques, régions, langues et canaux B2B/B2C. |
| Groupes de clients | Affectation aux catalogues partagés, fonctionnement des comptes d’entreprise, tarification, fiscalité et règles commerciales. |
| Réécritures d’URL et contenu CMS | Continuité SEO, calendrier des campagnes, contenu planifié et approbation éditoriale. |
| Extensions et données personnalisées | Examen d’un périmètre adapté lorsque des modules ou systèmes externes détiennent des données critiques pour l’activité. |
Cette distinction permet de conserver une description exacte d’Adobe Commerce. Il ne s’agit pas simplement de « Magento avec davantage de fonctionnalités », mais d’une destination de migration où le modèle de données Magento doit souvent soutenir une gouvernance d’entreprise.
Périmètre des vitrines et structure métier
Les décisions de périmètre doivent être prises tôt, car elles peuvent modifier le comportement des données migrées. Une entreprise peut utiliser des websites séparés pour des marques, des pays, des unités opérationnelles, des canaux B2B et B2C, des devises de base, des contextes fiscaux ou des comptes clients distincts. Les stores peuvent organiser la navigation du catalogue au moyen de catégories racines. Les store views servent souvent à gérer les langues et les variantes de présentation localisées.
Les plateformes sources ne séparent pas toujours ces concepts de la même manière. Une plateforme peut stocker les traductions dans un plugin, les marques dans des catégories, les prix régionaux dans des champs personnalisés, la visibilité client dans une application et les autorisations B2B dans un autre système. Si ces valeurs sont migrées sans plan de périmètre Adobe Commerce, le résultat peut sembler complet tout en étant commercialement incorrect.
La planification du périmètre doit répondre à des questions concrètes :
| Question de périmètre | Pourquoi elle compte |
|---|---|
| Quels websites seront disponibles au lancement ? | La structure des websites peut influer sur la séparation des comptes, le contexte commercial, les devises et la configuration. |
| Quels stores et quelles catégories racines alimenteront chaque vitrine ? | La navigation et l’organisation du catalogue peuvent varier selon l’activité ou la région. |
| Quelles store views nécessitent des valeurs localisées ? | Les noms et descriptions de produits, URL, métadonnées, CMS Pages et Blog Posts peuvent nécessiter un traitement propre à chaque langue. |
| Quelles valeurs sont globales et lesquelles ont un périmètre spécifique ? | Un mauvais héritage peut écraser des données localisées ou propres à une activité. |
| Quelles structures de la plateforme source ne correspondent pas réellement au périmètre d’Adobe Commerce ? | Des catégories, tags, groupes de clients ou champs personnalisés peuvent être interprétés à tort comme des websites ou store views. |
Un plan de migration ne doit pas envoyer tous les enregistrements vers un périmètre par défaut sauf si l’entreprise a explicitement choisi cette structure.
Gouvernance du catalogue et sens des données produit
La gouvernance du catalogue Adobe Commerce commence par la signification des produits. Les produits simple, configurable, grouped, bundle, virtual, downloadable et gift card peuvent chacun entraîner des implications différentes pour la migration. Les produits configurables demandent une attention particulière, car le produit parent visible et ses produits simples associés doivent préserver le sens des SKU, options, prix, images et stocks d’une manière exploitable par les acheteurs comme par les administrateurs.
Les attributs et jeux d’attributs nécessitent aussi une gouvernance explicite. Ils peuvent alimenter les fiches produit, la recherche, la navigation à facettes, la comparaison, les promotions, le reporting ou les intégrations. Dans un environnement d’entreprise, un attribut mal migré ne crée pas seulement un défaut d’affichage. Il peut dégrader la découverte des produits, l’alignement avec le PIM, les références ERP, l’exactitude des devis, les exports vers les marketplaces ou la maintenance interne.
La planification du catalogue doit distinguer les données d’affichage des données opérationnelles :
| Type de champ source | Question à poser pour Adobe Commerce |
|---|---|
| Spécifications produit | La valeur doit-elle être visible par le client, indexable, filtrable, comparable ou réservée à un usage interne ? |
| Options qui définissent les variantes | La valeur doit-elle alimenter un produit configurable ou une autre structure produit ? |
| Indicateurs B2B de prix ou de disponibilité | Relèvent-ils des catalogues partagés, des groupes de clients, d’une logique personnalisée ou de systèmes externes ? |
| Identifiants ERP/PIM/marketplace | Doivent-ils être mis en correspondance avec des champs pris en charge, conservés par une configuration compatible ou examinés hors périmètre standard ? |
| Attributs anciens ou en double | Faut-il les nettoyer, les fusionner, les exclure ou les conserver comme référence historique ? |
Une migration Adobe Commerce ne doit pas chercher à maximiser le nombre de champs transférés. Elle doit préserver ceux qui soutiennent réellement le modèle de gouvernance du catalogue cible.
Comptes d’entreprise B2B et relations entre acheteurs
Le B2B est souvent l’une des différences les plus visibles entre Adobe Commerce et Magento Open Source. Les comptes d’entreprise peuvent introduire des administrateurs de société, des utilisateurs, des rôles, des autorisations, du crédit, des règles de bons de commande, des droits de devis, des restrictions de paiement ou de livraison et des relations avec des catalogues partagés. Ces structures changent la signification de la migration des clients.
Un client de la source n’équivaut pas nécessairement à un compte d’entreprise. Un groupe de clients grossistes n’est pas nécessairement une hiérarchie d’acheteurs. Une liste de prix revendeur n’est pas nécessairement un catalogue partagé. Un champ de représentant commercial ne correspond pas automatiquement à une affectation d’entreprise native dans Adobe Commerce. Ces écarts doivent être examinés avant d’accepter le périmètre de migration.
Pour préparer la migration B2B vers Adobe Commerce, constituez des exemples représentatifs :
| Exemple B2B | Apport pour la migration |
|---|---|
| Entreprise avec un administrateur et plusieurs acheteurs | Vérifie la hiérarchie du compte et les relations entre utilisateurs. |
| Entreprise associée à une tarification ou une visibilité de produits propre à certains acheteurs | Vérifie les implications des catalogues partagés ou groupes de clients. |
| Client utilisant un processus de devis ou de bon de commande | Met en évidence les besoins de configuration et de validation côté cible. |
| Entreprise avec crédit ou restrictions sur les paiements/livraisons | Distingue les données historiques de la configuration commerciale active. |
| Données B2B sources contrôlées par des champs personnalisés ou un CRM/ERP externe | Identifie les besoins d’examen d’un périmètre adapté ou des intégrations. |
La réussite d’une migration B2B ne se prouve pas par le nombre de clients migrés. Elle se vérifie lorsque l’acheteur peut se connecter, voir le bon catalogue et les bons prix, utiliser les autorisations prévues et exécuter le processus d’achat attendu après le lancement.
Content Staging, merchandising et calendrier de lancement
Content Staging peut influencer la manière dont les équipes préparent le lancement. Les produits, catégories, règles de prix panier, règles de prix catalogue, CMS Pages, CMS Blocks et widgets peuvent participer à des campagnes de merchandising ou de contenu planifiées. Il ne faut pas supposer que le transfert du contenu recrée automatiquement la gouvernance de campagne.
La boutique source peut comporter des promotions planifiées, des pages saisonnières, des lancements futurs de produits, des bannières de campagne ou des révisions de contenu gérées par des applications ou des processus éditoriaux. La planification doit classer ces attentes. Certains contenus peuvent être migrés comme des enregistrements. D’autres doivent être reconstruits ou programmés dans Adobe Commerce. Certains nécessitent une vérification manuelle parce que le processus source n’a pas d’équivalent direct dans la cible.
Le plan de lancement doit donc distinguer :
| Contenu ou élément de merchandising | Traitement à prévoir |
|---|---|
| CMS Pages et Blog Posts ordinaires | Les migrer lorsqu’ils sont pris en charge, puis valider le contenu, les URL et les métadonnées. |
| Promotions planifiées | Déterminer si les règles migrent, doivent être configurées côté cible ou nécessitent une reconstruction manuelle de campagne. |
| Pages saisonnières | Vérifier la continuité des URL, les blocs de contenu, les médias et le calendrier de mise en ligne. |
| Contenu dépendant d’un page builder ou d’une application | Examiner le périmètre pris en charge, une reconstruction manuelle ou un traitement non standard. |
| Gouvernance de campagne | La traiter comme un processus cible à définir, et non comme un simple transfert de données. |
Content Staging apporte de la valeur lorsque l’entreprise l’utilise consciemment. Il devient un risque lorsque les équipes supposent que la logique de planification de la source a été transférée simplement parce que les enregistrements existent dans la cible.
Intégrations et responsabilités de niveau entreprise
Les projets Adobe Commerce dépendent souvent de systèmes extérieurs à la vitrine. L’ERP peut être propriétaire des identifiants produits, comptes clients, factures ou stocks. Le PIM peut détenir les attributs et contenus produit. Le CRM peut gérer les relations d’entreprise ou les affectations commerciales. Les systèmes fiscaux et logistiques peuvent prendre des décisions pendant le processus de commande. Les solutions de marketplace, analyse, fidélité, abonnement ou marketing peuvent posséder des données qui ressemblent à des données e-commerce sans être natives de la plateforme.
La planification doit identifier le propriétaire de chaque donnée avant de décider de son parcours de migration. Si la plateforme source ne fait qu’afficher une valeur détenue par un autre système, migrer ce champ d’affichage ne préservera pas nécessairement le processus métier. Si un module a créé les données, l’export standard peut ne pas les contenir. Si une intégration personnalisée écrit dans des champs privés, ces valeurs peuvent nécessiter un examen hors périmètre standard ou un travail d’implémentation séparé.
La distinction utile est la suivante :
| Besoin | Meilleure classification |
|---|---|
| Un enregistrement pris en charge nécessite un filtrage ou un ajustement de correspondance | Planifier explicitement le filtrage ou la mise en correspondance requis. |
| Un enregistrement pris en charge nécessite un traitement tenant compte de la configuration | Séparer le traitement de migration de la configuration de la plateforme cible. |
| Des enregistrements appartenant à une extension ou une application doivent être conservés | Nécessite un examen hors périmètre standard. |
| Des identifiants issus de systèmes externes doivent rester opérationnels | Nécessite un examen du périmètre adapté ou des intégrations. |
| Une intégration active doit être reconnectée après la migration | Relève de l’implémentation côté cible, pas des seules données migrées. |
Adobe Commerce donne aux entreprises la souplesse nécessaire pour prendre en charge des modèles d’exploitation complexes, mais cette souplesse ne devient utile que lorsque la propriété des données et les responsabilités d’intégration sont explicites.
Conclusion
La planification d’une migration vers Adobe Commerce doit commencer par le modèle d’exploitation que la plateforme cible devra soutenir. Les produits, profils clients, commandes, catégories, CMS Pages, Blog Posts et URL restent importants, mais ils ne représentent qu’une partie de l’enjeu. Le plan doit également tenir compte des comptes d’entreprise B2B, catalogues partagés, périmètres de vitrines, relations entre produits configurables, attributs et jeux d’attributs, Content Staging, intégrations, modules personnalisés et responsabilités de validation.
Une migration Adobe Commerce réussie n’est pas celle qui transfère le plus de données possible. C’est une transition maîtrisée vers un environnement e-commerce d’entreprise dans lequel les données migrées, la configuration cible, le périmètre accepté et la validation métier permettent de préserver le même modèle commercial après la mise en production.
Questions fréquentes
En quoi Adobe Commerce diffère-t-il de Magento Open Source pour la planification d’une migration ?
Adobe Commerce partage le socle de la famille Magento, mais la planification doit généralement accorder davantage d’attention aux fonctions d’entreprise : comptes B2B, catalogues partagés, devis et bons de commande, Content Staging, gouvernance et intégrations.
Toute migration vers Adobe Commerce nécessite-t-elle une préparation B2B ?
Non. Certaines boutiques Adobe Commerce sont principalement B2C ou orientées contenu. La préparation B2B devient importante lorsque la source utilise des comptes d’entreprise, des acheteurs grossistes, des tarifs revendeurs, des ventes assistées, des processus de devis ou un accès au catalogue propre à chaque compte.
Pourquoi le périmètre des vitrines est-il important lors d’une migration vers Adobe Commerce ?
Les niveaux website, store et store view peuvent influer sur l’affectation du catalogue, le contenu localisé, les URL, les devises, la configuration et le contexte de l’acheteur. Des données migrées vers un mauvais périmètre peuvent donner l’impression que la boutique cible est complète tout en produisant un fonctionnement incorrect.
Comment traiter les données personnalisées dans Adobe Commerce ?
Les ajustements de correspondance ou de configuration pris en charge peuvent couvrir des besoins délimités de filtrage, de mise en correspondance ou de configuration. Les données d’extension non prises en charge, champs personnalisés, identifiants de systèmes externes, transformations spécifiques et logiques B2B ou d’intégration complexes nécessitent un examen hors périmètre standard.
Que faut-il valider en premier après un test représentatif vers Adobe Commerce ?
Commencez par des exemples représentatifs du catalogue, des périmètres, des clients, des entreprises, des catalogues partagés, des URL et des intégrations sensibles. L’objectif est de démontrer que les enregistrements permettent à Adobe Commerce de fonctionner comme prévu, et pas seulement que les volumes correspondent.