Si Adobe Commerce est retenu comme plateforme cible, la préparation doit transformer le modèle d’exploitation de l’entreprise en un ensemble d’éléments contrôlés avant toute exécution de migration. L’équipe doit savoir comment les Customers B2C, entreprises B2B, utilisateurs d’entreprise, catalogues partagés, websites, stores, store views, types de Products, sources de stock, Orders historiques, contenus et systèmes externes doivent être représentés dans la boutique cible.
Pour chaque domaine important, un bon dossier de préparation répond à quatre questions : quelle action est requise, qui en est responsable, quels éléments justifient la décision et quelle condition permet de considérer ce domaine comme prêt. Cette discipline évite de découvrir les relations d’entreprise, prix propres aux acheteurs, vitrines régionales ou identifiants détenus par l’ERP seulement après la migration des premiers échantillons.
Définir les décisions d’exploitation d’Adobe Commerce
Commencez par un document concis décrivant le modèle d’exploitation. Il doit préciser quelles structures e-commerce doivent exister dans Adobe Commerce et quels systèmes resteront les sources faisant autorité en dehors de la plateforme.
| Domaine de préparation | Décision à consigner | Responsable | Élément attestant que le domaine est prêt |
|---|---|---|---|
| Modèle d’acheteurs | Customers B2C, entreprises B2B, implantations, utilisateurs, rôles, approbateurs et représentants commerciaux | Opérations B2B et clients | Schéma approuvé des relations de comptes avec enregistrements sources représentatifs |
| Modèle de catalogue | Types de Products, jeux d’attributs, Categories, catalogues partagés, visibilité par acheteur et assortiment régional | Responsables catalogue et merchandising | Matrice des familles de Products et des périmètres de catalogue |
| Périmètre des vitrines | Websites, stores, store views, langues, devises, marques, régions et domaines | Responsable de l’architecture e-commerce | Carte website/store/store view |
| Propriété de la tarification | Prix de base, prix par paliers, prix négociés, prix de catalogues partagés et tarifs contractuels externes | Responsables commerciaux et intégrations | Registre des sources de prix et scénarios d’acheteurs représentatifs |
| Propriété du stock | Sources, stocks, websites, entrepôts, dropshippers, points de retrait et systèmes de stock externes | Responsables stock et traitement logistique | Carte de propriété des sources et stocks |
| Modèle d’intégration | Dépendances ERP, PIM, CRM, WMS, achats, comptabilité, fiscalité, livraison, recherche et reporting | Responsable technique | Registre des dépendances avec identifiants durables |
Ce document doit être suffisamment précis pour guider la préparation sans devenir une spécification de configuration Adobe Commerce. Son rôle est d’établir le propriétaire cible de chaque relation métier.
Préparer les accès, éléments sources et sauvegardes récupérables
Rassemblez les accès et éléments nécessaires pour interpréter la boutique source sans dépendre de connaissances non documentées détenues par certains collaborateurs.
Préparez :
- un accès administrateur à la boutique source et à l’environnement Adobe Commerce avec les niveaux d’autorisation nécessaires ;
- des exports ou rapports datés pour Products, Categories, Customers, entreprises, utilisateurs d’entreprise, Orders, contenus, Reviews, promotions et autres enregistrements inclus dans le périmètre ;
- des sauvegardes de base de données et de médias lorsqu’elles sont disponibles ;
- des références sur les attributs, jeux d’attributs et types de Products ;
- l’inventaire des websites, stores, store views, langues, devises et domaines ;
- des exemples de données B2B : entreprises, rôles, catalogues partagés, tarification et crédit ;
- des rapports sur sources de stock, stocks, entrepôts et traitement logistique ;
- l’inventaire des extensions, modules personnalisés, API et systèmes externes ;
- les listes d’URL à forte valeur, redirections, CMS Pages, blocks et campagnes ;
- des captures ou rapports expliquant les comportements importants de la source.
| Élément | Pourquoi il est nécessaire | Condition de préparation |
|---|---|---|
| Registre des accès | Confirme que les zones sources et cibles requises peuvent être examinées | Les comptes nécessaires fonctionnent et les responsables des autorisations sont identifiés |
| Archive d’exports | Conserve un état de référence daté | Les fichiers s’ouvrent correctement et contiennent les familles d’enregistrements attendues |
| Sauvegarde base/médias | Protège les données absentes des exports ordinaires | Emplacement, date et responsable de restauration documentés |
| Dictionnaire de champs | Explique les libellés personnalisés, indicateurs et identifiants | Chaque champ important possède un objectif, un propriétaire et un exemple de valeur |
| Carte de périmètre | Empêche l’aplatissement des relations websites, store views, B2B et stock | Chaque unité métier et vitrine incluse possède une destination attribuée |
Si un export omet des enregistrements d’extension ou B2B, consignez l’écart et affectez un responsable. L’absence d’élément constitue un problème de préparation ; elle ne prouve pas que la donnée n’existe pas.
Préparer les entreprises B2B, utilisateurs, rôles et contexte d’achat
Les relations B2B d’Adobe Commerce exigent une préparation allant au-delà des profils Customer individuels. Une entreprise peut comporter utilisateurs, équipes, rôles, autorisations, affectations de catalogues partagés, crédit, règles de bons de commande, restrictions de paiement et livraison ainsi que des identifiants externes de compte.
Préparez des exemples représentatifs concernant :
- identité légale, statut, identifiants fiscaux et revendeurs, adresse légale de l’entreprise ;
- relations entre administrateur, entreprise et implantations ;
- acheteurs, approbateurs, utilisateurs de succursales, équipes d’achat et utilisateurs associés à plusieurs entreprises ;
- rôles et autorisations sur Orders, devis, bons de commande, utilisateurs, équipes et crédit d’entreprise ;
- limite de crédit, solde disponible, devise, paiement sur compte et historique de crédit lorsque pertinent ;
- attentes d’approbation des bons de commande et références d’achat ;
- moyens de paiement et modes de livraison autorisés ;
- identifiants du représentant commercial, compte ERP, revendeur, système d’approvisionnement et CRM.
| Élément de préparation | Responsable | Élément requis | Condition de préparation |
|---|---|---|---|
| Identité de l’entreprise | Opérations B2B | Liste principale des entreprises et IDs sources | Chaque entreprise possède un enregistrement Adobe Commerce cible prévu |
| Appartenance des utilisateurs | Opérations clients | Matrice utilisateur-entreprise et utilisateur-équipe | Chaque utilisateur d’entreprise possède une entreprise, un statut et un rôle définis |
| Modèle d’autorisations | Responsable du processus B2B | Exemples de rôles et autorisations | Les responsabilités d’achat requises sont documentées |
| Crédit et contexte PO | Finance et achats | Exemples représentatifs de crédit et bons de commande | Les relations financières et d’approbation ont un propriétaire cible |
| Clés externes de compte | Responsable intégration | IDs ERP, CRM, approvisionnement et revendeur | Chaque clé est reliée au bon niveau entreprise ou utilisateur |
Si le sens B2B est caché dans des groupes Customers, tags, champs personnalisés, feuilles de calcul ou systèmes externes, préparez un registre de représentation cible au lieu de forcer ces valeurs dans des champs Customer ordinaires.
Préparer les catalogues partagés, la tarification et la visibilité des Products
Les catalogues partagés peuvent contrôler la disponibilité des Products et la tarification personnalisée pour des comptes d’entreprise. La préparation doit identifier quels catalogues comptent, quelles entreprises y ont accès, quels Products y appartiennent et quel système fait autorité pour les prix.
| Enregistrement de catalogue ou de prix | Action de préparation | Élément requis |
|---|---|---|
| Catalogue public | Définir les Products et Categories disponibles pour les Customers ordinaires | Échantillon d’appartenance Products/Categories |
| Catalogue partagé personnalisé | Définir l’affectation des entreprises, les Products inclus et les prix personnalisés | Matrice entreprise-catalogue et Product-catalogue |
| Prix par groupe Customer | Identifier le groupe Customer et la relation au Product | Exemple Product/groupe Customer représentatif |
| Prix par palier ou quantité | Consigner Product, seuil, périmètre acheteur et montant | Exemple de palier avec propriétaire source |
| Prix contractuel ou négocié | Identifier l’autorité de prix interne ou externe | Exemple acheteur/Product et clé du système externe |
| Assortiment restreint | Définir quelles entreprises ou groupes peuvent voir ou acheter le Product | Exemple de visibilité et liste d’exceptions |
Normalisez les noms de catalogues en double, listes de prix obsolètes, exceptions expirées et identifiants Product incohérents avant de les transformer en structures Adobe Commerce. Le domaine est prêt lorsque chaque entreprise prioritaire peut être associée à un catalogue et à une source de prix prévus sans dépendre de la mémoire d’un membre de l’équipe.
Préparer les types de Products, attributs et gouvernance du catalogue
Sélectionnez des Products représentatifs selon leur structure, pas uniquement selon leur popularité. Adobe Commerce prend en charge plusieurs types de Products ; les enregistrements sources doivent donc être classés d’après la manière dont ils sont vendus et maintenus.
Incluez des exemples de :
- Products simples ;
- Products configurables avec SKU enfants stockés indépendamment ;
- Products grouped et bundle ;
- Products virtual et downloadable ;
- gift cards ou types de Products personnalisés lorsque pertinent ;
- Products comportant des options personnalisées ;
- Products avec valeurs localisées ou propres à un website ;
- Products avec attributs personnalisés, identifiants externes ou données détenues par une intégration ;
- Products affectés à plusieurs Categories ou catalogues restreints.
Préparez une feuille de gouvernance des attributs :
| Fonctionnement source | Décision de préparation Adobe Commerce | Élément attestant la préparation |
|---|---|---|
| La valeur définit une variation vendable | Définir le Product configurable, ses Products simples enfants et les attributs de variation | IDs parent/enfants, SKU, valeurs d’options, stock, prix et images |
| La valeur décrit le Product | Définir l’attribut Product, son type de données, son périmètre et son jeu d’attributs | Définition du champ et valeurs représentatives |
| L’acheteur saisit une valeur ponctuelle | Définir l’option personnalisée, l’extension ou le propriétaire de la ligne d’Order | Exemple de vitrine et d’Order historique |
| La valeur diffère selon website ou store view | Définir le périmètre de l’attribut et la responsabilité des valeurs localisées | Matrice de valeurs website/store view |
| Le Product est un bundle ou un groupe | Définir les Products composants et la relation commerciale | Liste des composants, quantités, tarification et propriétaire du stock |
| La valeur est une métadonnée de système externe | La préserver au niveau du Product ou SKU enfant utilisé par ce système | Clé externe et exemple de recherche |
Supprimez les attributs inutilisés, normalisez les valeurs contrôlées, identifiez les jeux d’attributs requis et documentez les champs à exclure. Le catalogue est prêt lorsque chaque grande famille de Products possède un type, un jeu d’attributs, des relations enfants, une responsabilité de Category et un plan d’identifiants externes clairement définis.
Préparer websites, store views, contenus, URL et campagnes
Cartographiez la structure des vitrines sources vers les websites, stores et store views Adobe Commerce. Consignez les valeurs qui diffèrent selon marque, région, langue, devise, domaine ou entité juridique.
Préparez :
- la hiérarchie website/store/store view ;
- l’affectation des langues et devises ;
- le contenu Product et Category selon le périmètre ;
- CMS Pages, CMS blocks, contenu Page Builder, formulaires, bannières et médias ;
- les campagnes planifiées ou staged encore pertinentes ;
- les URL Product, Category, CMS, campagne et localisées ;
- l’historique des redirections et chemins sources à forte valeur ;
- les liens internes intégrés aux descriptions Product et contenus CMS.
| Route ou contenu source | Question de préparation | Élément requis |
|---|---|---|
| URL Product ou Category | Quel website et quelle store view possèdent la route cible ? | Registre des routes source/cible |
| Contenu localisé | Quelles valeurs sont traduites ou propres à une région ? | Matrice de contenu par store view |
| CMS Page ou block | S’agit-il de contenu réutilisable, de contenu de page, de campagne ou seulement de présentation ? | Inventaire du contenu avec propriétaire cible |
| Campagne planifiée | Le contenu est-il encore requis, historique seulement ou volontairement retiré ? | Décision de campagne et responsable du contenu |
| Lien interne | Quelle route cible doit remplacer le chemin source ? | Liste de réécriture des liens prioritaires |
Le domaine est prêt lorsque chaque route publique prioritaire et chaque élément de contenu important possède une destination, un périmètre ou une décision de retrait.
Préparer le stock, les Customers et les Orders historiques
Les éléments relatifs au stock doivent définir la relation entre emplacements sources, sources Adobe Commerce, stocks, websites, quantité vendable et éventuelle autorité de stock externe. Préparez des exemples de Products mono-source et multisource, SKU enfants configurables, backorders, points de retrait, dropshippers et stocks contrôlés par ERP ou WMS.
Pour les Customers et Orders, choisissez des exemples qui rendent visibles les relations historiques que les équipes devront pouvoir comprendre :
- Customers B2C enregistrés, acheteurs invités, adresses multiples, groupes Customer, traitement fiscal et IDs externes ;
- Customers d’entreprise et utilisateurs d’entreprise ;
- Orders contenant des Products configurable, bundle, virtual, downloadable ou avec options personnalisées ;
- remises, taxes, livraison, libellés de paiement, factures, expéditions, avoirs, retours, commentaires et références externes ;
- Orders issus de chaque website, devise, région, entreprise ou parcours logistique important.
| Domaine | Responsable | Élément requis | Condition de préparation |
|---|---|---|---|
| Sources et stocks | Opérations stock | Carte source/stock/emplacement et exemples SKU | Chaque SKU prioritaire possède un propriétaire de stock déclaré et une relation au website |
| Identité Customer | Opérations clients | Exemples de doublons, invités, adresses, groupes et IDs externes | Les règles d’identité et de fusion sont documentées |
| Sens historique des Orders | Support et finance | Dossier d’Orders représentatifs | Lignes Product, totaux, statuts, traitement logistique, remboursements et références sont expliqués |
| Données sensibles | Juridique et responsable des données | Liste approuvée des champs | Les données personnelles ou financières inutiles sont exclues |
Les Orders historiques doivent être préparés comme éléments attestant du commerce passé. La configuration actuelle d’Adobe Commerce pour paiement, livraison, fiscalité, stock et traitement logistique reste une responsabilité d’implémentation séparée.
Inventorier extensions, modules personnalisés et systèmes externes
Créez un registre unique pour chaque extension, module personnalisé, intégration, tâche planifiée, table personnalisée, API et système externe qui crée ou modifie des enregistrements inclus dans le périmètre.
Pour chaque dépendance, consignez :
- objectif métier ;
- enregistrements principaux étendus ;
- tables, attributs, statuts ou identifiants créés ;
- responsable des données et responsable technique ;
- disponibilité d’un export ou d’une API ;
- propriétaire cible ou système de remplacement ;
- clés stables nécessaires à la reconnexion ;
- données pouvant être retirées ou archivées.
Les dépendances prioritaires comprennent couramment ERP, PIM, CRM, WMS, systèmes d’achat, recherche, abonnements, fidélité, Reviews, fiscalité, paiement, livraison, marketplaces, analyse et reporting et processus B2B personnalisés.
Le registre est prêt lorsque chaque dépendance importante possède un propriétaire qui continuera d’en être responsable et qu’aucun champ critique n’est simplement décrit comme « géré par l’extension ».
Sélectionner des échantillons représentatifs pour le test de migration
Choisissez un ensemble d’échantillons qui expose les décisions d’entreprise préparées ci-dessus. N’utilisez pas des Products aléatoires ni uniquement des Orders simples.
| Échantillon | Objectif de préparation |
|---|---|
| Famille de Products simple et configurable | Établir les règles de type, SKU enfants, attributs, médias et stock |
| Product bundle ou grouped | Exposer les relations de composants et de tarification |
| Entreprise B2B avec plusieurs utilisateurs | Exposer les relations entreprise, équipe, rôle et IDs externes |
| Product de catalogue partagé | Exposer l’affectation d’entreprise, la visibilité et les éléments de prix |
| SKU à stock multisource | Exposer source, stock, website et responsabilité du stock externe |
| Product ou CMS Page localisé | Exposer le périmètre de store view et la responsabilité de route |
| Order historique complexe | Exposer lignes Product, totaux, traitement logistique, avoirs et références externes |
| Enregistrement détenu par une extension | Exposer les champs/tables personnalisés et les décisions de responsabilité cible |
Pour chaque échantillon, fournissez l’ID source, l’URL source lorsque pertinent, la raison métier, le propriétaire Adobe Commerce attendu, les identifiants externes liés, exclusions connues et responsable de la revue. Chaque échantillon possède ainsi une attente source traçable et un examinateur identifié.
Valider la préparation d’Adobe Commerce
| Question de préparation | Élément requis | Condition de préparation |
|---|---|---|
| Les accès et sauvegardes sont-ils disponibles ? | Registre des accès et archive datée | Les systèmes requis et éléments sources peuvent être récupérés |
| Le modèle d’exploitation est-il documenté ? | Cartes acheteurs, vitrines, catalogues, prix et stock | Chaque relation majeure possède un propriétaire |
| Les structures B2B sont-elles préparées ? | Éléments entreprise, utilisateurs, rôles, catalogues, crédit et PO | Les relations d’entreprise représentatives sont complètes |
| Les familles de Products sont-elles classifiées ? | Matrice Products et attributs | Chaque grande structure de Product possède une représentation Adobe Commerce prévue |
| Les contenus et URL sont-ils affectés ? | Registre routes et contenus | Les routes prioritaires ont une destination ou une décision de retrait |
| Les intégrations sont-elles inventoriées ? | Registre des dépendances | Chaque dépendance critique possède un propriétaire continu et une clé |
| Les échantillons représentatifs sont-ils sélectionnés ? | Registre des échantillons | Cas ordinaires et exceptionnels sont couverts |
| Les éléments non résolus sont-ils maîtrisés ? | Journal de décisions | Chaque point ouvert possède un responsable et une échéance |
La préparation est complète lorsque les éléments peuvent être compris par une personne extérieure à l’équipe qui a configuré la boutique source et qu’aucune décision critique concernant le B2B, les Products, le stock, les Orders, URL ou intégrations ne dépend d’hypothèses non documentées.
Conclusion
La préparation d’une migration vers Adobe Commerce doit produire un dossier d’éléments de niveau entreprise, et non une simple liste d’exports. Entreprises, utilisateurs, rôles, catalogues partagés, types de Products, attributs, store views, sources de stock, Orders historiques, contenus et intégrations nécessitent tous des responsables explicites et des enregistrements représentatifs.
Lorsque ces décisions sont documentées avant le test représentatif, l’équipe peut évaluer la représentation Adobe Commerce attendue à partir d’éléments contrôlés plutôt que d’essayer de reconstruire le modèle d’exploitation à partir de quelques enregistrements déjà migrés.
Questions fréquentes
Quel document de préparation Adobe Commerce faut-il créer en premier ?
Commencez par la carte du modèle d’exploitation couvrant acheteurs, websites, store views, catalogues, prix, stock et systèmes externes. Elle détermine les éléments détaillés et responsables à préparer ensuite.
Comment préparer les entreprises B2B Adobe Commerce ?
Préparez identité de l’entreprise, administrateur, utilisateurs, équipes, rôles, autorisations, crédit, contexte de bons de commande, affectations de catalogues et IDs externes comme des enregistrements connectés. Ne réduisez pas l’entreprise à un groupe Customer ordinaire.
Quels éléments faut-il préparer pour les catalogues partagés ?
Fournissez appartenance au catalogue, affectation d’entreprise, visibilité des Products, source de prix, exceptions et exemples Product/acheteur représentatifs. Chaque catalogue doit avoir un responsable commercial clairement identifié.
Comment préparer les Products configurables ?
Documentez le Product parent, les Products simples enfants, attributs de variation, SKU, stocks, prix, images et identifiants externes. Identifiez aussi les valeurs sources qui ne sont que des descriptions ou saisies personnalisées plutôt que de véritables variations.
Quels enregistrements de stock nécessitent une préparation particulière ?
Priorisez les SKU multisources, SKU enfants configurables, points de retrait ou dropship, backorders et stocks synchronisés par un système externe. Chaque quantité doit avoir une relation déclarée avec une source, un stock, un website et un système faisant autorité.
Quand la préparation Adobe Commerce est-elle complète ?
Elle est complète lorsque les accès et sauvegardes sont récupérables, les structures B2B et catalogue ont des responsables, les routes prioritaires et intégrations sont documentées, les échantillons représentatifs sélectionnés et chaque décision non résolue affectée à un responsable identifiable.