Magento est une plateforme e-commerce Self-hosted et extensible destinée aux marchands et aux équipes d’implémentation qui souhaitent garder la maîtrise directe de l’application, de la base de données, de l’infrastructure, du code, des extensions, des thèmes, des intégrations et du processus de déploiement. Sa principale force réside dans sa souplesse structurelle : le catalogue peut combiner plusieurs types de Products, des attributs réutilisables, des jeux d’attributs, des arborescences de Categories, des websites, des stores et des store views, tandis que le code peut être étendu au moyen de modules et d’intégrations de services.
Cette souplesse distingue nettement Magento d’une plateforme Hosted reposant sur un modèle d’exploitation plus prescriptif. La boutique cible ne résulte pas uniquement des données transférées. Elle se construit à partir des enregistrements du catalogue, des paramètres appliqués à différents niveaux de portée, des thèmes, des modules, du moteur de recherche, des intégrations, de l’infrastructure, des pratiques de déploiement et de la gouvernance technique continue.
Il faut également distinguer clairement Magento d’Adobe Commerce. Les deux solutions partagent une même lignée technologique et de nombreux concepts fondamentaux, mais elles ne constituent pas des éditions interchangeables. Les fonctionnalités propres à Adobe Commerce ne doivent pas être supposées disponibles dans Magento simplement parce que la terminologie sous-jacente semble similaire.
Magento comme plateforme e-commerce Self-hosted
Magento confie au marchand ou à l’équipe d’implémentation la responsabilité de l’environnement applicatif. Cela comprend l’hébergement, les services de base de données, les services de recherche, le cache, le stockage des médias, les certificats, les sauvegardes, la supervision, le déploiement, l’application des correctifs, la compatibilité des extensions et la maintenance de la sécurité. La plateforme fournit l’application e-commerce ; elle ne remplace pas l’équipe chargée de l’exploiter.
Ce modèle de responsabilité influence l’orientation de la migration dès le départ. Une boutique cible peut contenir ses Products, Customers et Orders tout en restant incomplète sur le plan opérationnel si la recherche n’est pas prête, si l’indexation est en retard, si certaines extensions sont incompatibles, si le thème n’affiche pas les champs transférés ou si l’infrastructure est sous-dimensionnée.
| Couche d’architecture | Responsabilité habituelle | Importance pour la migration |
|---|---|---|
| Données e-commerce | Products, Categories, Customers, Orders, avis, CMS Pages et enregistrements associés | Les enregistrements pris en charge doivent conserver leurs relations et leur signification commerciale. |
| Configuration de la boutique | Websites, stores, store views, devises, taxes, inventaire, e-mails, statuts d’Orders et paramètres du catalogue | La portée de configuration et le fonctionnement futur doivent être établis dans la boutique cible. |
| Code applicatif | Cœur Magento, modules, personnalisations et API | Les données peuvent dépendre d’attributs, de tables ou de règles métier appartenant à des modules. |
| Présentation | Thèmes, layouts, blocks, templates, contenu et médias | Les données transférées doivent être affichées et accessibles dans l’implémentation de vitrine retenue. |
| Infrastructure | Web, base de données, recherche, cache, files d’attente, stockage, déploiement et supervision | Les performances et la fiabilité dépendent de la conception et de la maintenance de l’environnement. |
| Systèmes externes | ERP, PIM, WMS, CRM, fiscalité, paiement, expédition, outils d’analyse et marketplaces | Les identifiants et les flux de travail exigent un responsable d’intégration clairement défini. |
Magento récompense une implémentation rigoureuse. Son étendue fonctionnelle doit être gouvernée comme une architecture, et non utilisée comme prétexte pour reproduire chaque personnalisation héritée.
Magento s’appuie également sur des traitements en arrière-plan et sur des données de vitrine dérivées. Les modifications du catalogue peuvent nécessiter une nouvelle indexation avant d’apparaître correctement dans la recherche, la navigation, les prix ou les vues d’inventaire. Les caches et les artefacts de déploiement peuvent eux aussi influencer ce que voient les administrateurs et les clients après le chargement des données. Ces mécanismes appartiennent à l’environnement d’exploitation, et non aux enregistrements transférés eux-mêmes. Ils doivent fonctionner correctement pour que la boutique cible représente fidèlement les données migrées.
Il faut donc distinguer une anomalie de données d’une anomalie d’environnement. Un Product peut être correct en base alors qu’un index obsolète, un cache, un template de thème ou une réponse d’intégration donne l’impression inverse en vitrine. Cette distinction devient essentielle lors de la validation et du diagnostic des incidents.
Architecture du catalogue : Products, attributs et jeux d’attributs
Le catalogue Magento repose sur des Products structurés et des attributs réutilisables. Des informations telles que le nom, le SKU, le prix, le statut, la visibilité, le poids, les descriptions, la classe fiscale, les médias et les champs métier personnalisés peuvent être représentées par des attributs. Les jeux d’attributs regroupent les champs nécessaires à différentes familles de Products.
Ce modèle permet de gérer le catalogue comme un système cohérent plutôt que comme une suite d’enregistrements isolés. Un Product textile peut nécessiter la taille, la matière, les consignes d’entretien et la saison. Un Product industriel peut nécessiter la tension, des certifications, des dimensions et des informations de compatibilité. Ces champs peuvent être organisés dans l’administration puis utilisés de manière sélective dans les vitrines, les intégrations, la recherche ou les rapports.
L’enjeu de migration ne se limite donc pas à importer des attributs. La boutique cible doit disposer d’une architecture d’attributs cohérente :
- les codes d’attribut doivent rester stables et explicites ;
- les types de données des attributs doivent correspondre à leur usage opérationnel prévu ;
- les jeux d’attributs doivent refléter de véritables familles de Products ;
- les valeurs sélectionnables doivent être normalisées lorsqu’elles sont réutilisées ;
- les champs obligatoires ne doivent pas bloquer inutilement des enregistrements valides ;
- l’affichage en vitrine, la recherche, le filtrage, la comparaison et l’utilisation par les intégrations doivent être intentionnels ;
- les résidus d’anciennes extensions ne doivent pas devenir une structure permanente du catalogue.
Magento prend également en charge plusieurs structures de Products adaptées à différents modes de vente. Les Products simples, variantes, bundles, grouped, virtuels, téléchargeables ou reposant sur des options personnalisées dans la plateforme source doivent être interprétés selon la manière dont la boutique cible devra les vendre. Une relation parent-enfant issue d’une plateforme source peut ressembler à un Product configurable Magento, mais cette ressemblance ne suffit pas : la propriété du SKU, du prix, du stock, des images et du choix effectué par l’acheteur doit être cohérente.
| Enjeu catalogue | Signification dans Magento | Orientation initiale |
|---|---|---|
| Identité du Product | Enregistrement e-commerce centré sur le SKU et enrichi par des attributs | Conserver les identifiants stables et distinguer les données du Product parent de celles de l’enfant. |
| Famille de Products | Jeu d’attributs et type de Product | Organiser les champs et le mode de vente au lieu de recopier tout le schéma source. |
| Variantes | Relation parent-enfant ou autre structure Product prise en charge | Confirmer quel enregistrement porte le prix, le stock, les médias et les valeurs sélectionnables. |
| Informations personnalisées | Attributs Product ou données appartenant à un module | Ne conserver que les champs ayant un objectif et un propriétaire définis dans la boutique cible. |
| Inventaire | Structures de stock au niveau du Product et des sources selon l’implémentation | Distinguer les quantités historiques de la future organisation du traitement des commandes. |
Le système d’attributs est l’une des principales forces de Magento, mais aussi l’une des raisons pour lesquelles une mauvaise classification des données source devient coûteuse. Un catalogue source peu gouverné peut être techniquement structuré dans Magento tout en restant incohérent commercialement si les valeurs, la propriété des champs et les familles de Products ne sont pas normalisées.
Categories, navigation et découverte du catalogue
Les Categories Magento forment une hiérarchie pouvant structurer la navigation en vitrine. Les Products peuvent être affectés à aucune, une ou plusieurs Categories, et la structure de Category racine peut être associée à un niveau de store. L’arborescence des Categories est donc à la fois une structure de données et une structure de découverte.
Les taxonomies source mélangent souvent plusieurs fonctions : navigation client, marques, filtres, campagnes, départements internes, pages d’atterrissage ou chemins SEO. Magento propose des Categories, des attributs, la recherche, la navigation à facettes, du contenu CMS, des menus et des composants de thème qui peuvent répartir ces responsabilités de manière plus explicite.
Une Category ne doit pas être conservée uniquement parce qu’elle existe dans la plateforme source. Son rôle futur doit être défini :
- crée-t-elle une destination de navigation utile ?
- doit-elle apparaître dans la navigation principale ?
- représente-t-elle une classification de campagne temporaire ?
- le même concept serait-il mieux porté par un attribut ou un filtre ?
- nécessite-t-elle du contenu, des métadonnées, une image ou une mise en page particulière ?
- son ancienne URL a-t-elle suffisamment de valeur pour justifier une destination de redirection dédiée ?
Cette présentation ne remplace pas les articles ultérieurs consacrés au modèle de données ou à la préparation. Elle établit simplement que la découverte du catalogue Magento forme un système coordonné. Products, Categories, attributs, recherche, filtres, thème et contenu contribuent ensemble à la capacité du client à trouver le bon article.
Websites, stores et store views
Magento utilise une hiérarchie de websites, stores et store views. Ce modèle de portée peut séparer les domaines, catalogues, devises, contextes de commande, Categories racines, langues et valeurs de configuration. Il s’agit d’un élément fondamental de la plateforme, et non d’un simple réglage multilingue de présentation.
À haut niveau :
- un website peut définir une grande frontière commerciale ;
- un store peut organiser un catalogue autour d’une Category racine ;
- une store view peut proposer une variante de vitrine, souvent pour une langue ou un contenu localisé.
Les paramètres de configuration et les valeurs d’attributs peuvent avoir des niveaux de portée différents. Le nom d’un Product peut varier selon la store view alors que son SKU reste global. Le prix peut être gouverné à un niveau plus large qu’une description traduite. Les Categories et la navigation peuvent varier selon la structure de store retenue.
Cette hiérarchie est importante parce qu’une organisation multi-boutique source ne se transpose pas nécessairement à l’identique. Des domaines source distincts peuvent devenir des websites, des stores ou des store views Magento selon les exigences de catalogue, de Customers, de devises, de fiscalité, de commande et d’exploitation. À l’inverse, plusieurs vitrines source peuvent être regroupées si leurs différences n’ont plus de valeur.
Le point essentiel est le suivant : dans Magento, l’architecture de portée influence la signification et la visibilité des enregistrements transférés. Ce n’est pas seulement une préférence d’affichage côté cible.
Customers, Orders et historique transactionnel
Magento gère les comptes Customers, les adresses, les groupes de Customers, les Orders, factures, expéditions, avoirs, remises, contexte fiscal et autres enregistrements transactionnels. Ces structures servent à la fois à l’administration quotidienne et à la continuité du service historique.
Un Customer transféré doit rester reconnaissable et exploitable, mais la continuité d’un compte dépasse le nom et l’adresse e-mail. La structure des adresses, les groupes de Customers, le traitement fiscal, l’état d’inscription à la newsletter, les attributs personnalisés et les identifiants de systèmes externes peuvent avoir un impact opérationnel. La compatibilité des mots de passe dépend de la méthode de migration prise en charge et ne doit jamais être présumée.
Un Order transféré doit conserver suffisamment de contexte pour que les équipes puissent comprendre la transaction. Les lignes, SKU, noms de Products, quantités, options choisies, prix, remises, taxes, frais d’expédition, totaux, statut, adresses, références de paiement, factures, expéditions et remboursements peuvent tous participer à cette signification lorsqu’ils sont pris en charge.
Les données historiques ne configurent pas l’exploitation future. Le nom d’un ancien mode de livraison ne déploie pas une intégration transporteur. Une référence de paiement ne configure pas une passerelle. Les montants fiscaux historiques ne définissent pas les règles fiscales actuelles. Le futur processus de commande et de traitement des commandes de Magento dépend de la configuration cible, des modules, des identifiants d’accès et des intégrations.
Contenu, thèmes et présentation de la vitrine
Magento comprend des CMS Pages, des content blocks, des widgets, des médias, du contenu Product et Category ainsi qu’un rendu de vitrine piloté par le thème. Ces éléments permettent d’associer les données e-commerce à du contenu éditorial, promotionnel et de navigation.
La couche de présentation peut utiliser des layouts, templates, blocks, paramètres de thème et extensions. Un attribut transféré peut exister en base de données tout en restant invisible parce que le thème ne le rend pas. Une CMS Page peut être présente mais absente de la navigation. L’image d’un Product peut être transférée alors que le comportement responsive ou la galerie diffère de la source.
La continuité de la vitrine dépend donc des relations entre :
- les enregistrements et médias transférés ;
- la configuration Magento et ses niveaux de portée ;
- les templates de thème et les choix de layout ;
- les CMS Pages et content blocks ;
- la recherche, la navigation, le filtrage et les URL.
Les URL Magento, les réécritures, chemins de Categories, clés de Products et destinations de contenu peuvent différer de la plateforme source. La continuité SEO doit s’appuyer sur des destinations Magento valides et sur les chemins source à forte valeur, plutôt que sur l’hypothèse qu’il faut reproduire à l’identique chaque URL historique.
Modules, personnalisations et intégrations
Magento dispose d’un vaste écosystème de modules et d’intégrations. Les extensions peuvent ajouter des moyens de paiement, des modes d’expédition, de la recherche, du merchandising, des abonnements, des marketplaces, des configurateurs de Products, des champs Customers, des attributs d’Orders, des rapports, des fonctions de traitement des commandes ou des flux administratifs. Des modules personnalisés peuvent également modifier le fonctionnement du cœur de la plateforme ou créer de nouvelles structures de données.
Cette extensibilité est centrale, mais elle crée aussi de nombreuses dépendances difficiles à voir. Un champ peut être stocké sous forme d’attribut Magento, dans une table personnalisée, dans une entité appartenant à une extension ou dans un système externe. Un processus peut être imposé par le code sans être représenté directement dans les enregistrements transférés.
Une boutique cible propre distingue :
- les enregistrements du cœur de Magento ;
- la configuration standard de la cible ;
- les données appartenant aux extensions ;
- les données et règles des modules personnalisés ;
- la présentation propre au thème ;
- la responsabilité des systèmes externes.
Cette distinction est particulièrement importante pour les identifiants. Les enregistrements Product, Customer et Order peuvent conserver des identifiants ERP, des clés PIM, des références marketplace ou des codes de traitement des commandes. Ces identifiants n’ont de valeur que si l’intégration correspondante continue à les utiliser et à les maintenir après la mise en production.
Magento et Adobe Commerce
Magento et Adobe Commerce ont une histoire commune, mais leurs limites produit doivent rester explicites. Magento fournit le cœur Open Source et les capacités e-commerce de base. Adobe Commerce ajoute des fonctionnalités propriétaires et des services commerciaux qu’il ne faut pas attribuer automatiquement à Magento.
Cette frontière influence les attentes de migration. Une boutique source peut utiliser des fonctions B2B, de merchandising, de contenu, de segmentation, d’exploitation ou de cloud associées à Adobe Commerce ou à des extensions tierces. La plateforme cible doit être évaluée selon l’implémentation réelle de Magento et les modules effectivement sélectionnés, et non d’après une liste de fonctionnalités mélangée à celle de toute la famille Adobe Commerce.
La même discipline s’applique aux données source. Un champ provenant d’une fonctionnalité Adobe Commerce peut nécessiter une autre destination, une extension ou un traitement non standard dans Magento. Le partage de concepts de base de données ne garantit pas un fonctionnement métier équivalent.
Ce qui rend une migration vers Magento particulière
Magento se distingue par la combinaison d’un modèle de données e-commerce fortement structuré et d’une infrastructure et d’un code maîtrisés par le marchand. Quatre caractéristiques définissent son identité de migration :
- Les attributs et les types de Products déterminent le sens du catalogue. La boutique cible a besoin d’une architecture Product gouvernée, pas seulement de lignes importées.
- Les niveaux website, store et store view influencent la visibilité et la configuration. Les données multi-boutiques doivent être interprétées à travers la hiérarchie Magento.
- Les extensions et modules personnalisés peuvent posséder des données et des règles essentielles. Les enregistrements du cœur ne révèlent pas toutes les dépendances.
- L’infrastructure et le déploiement font partie du modèle d’exploitation. Recherche, indexation, cache, files d’attente, médias, performances, sécurité et gestion des releases influencent directement l’utilisabilité des données transférées.
Magento peut prendre en charge des boutiques sophistiquées, mais sa souplesse exige une gouvernance technique. La plateforme fonctionne au mieux lorsque la structure des données, les niveaux de configuration, les modules, les thèmes, les intégrations et l’infrastructure sont conçus comme une seule architecture de boutique cible.
Conclusion
Magento est une plateforme e-commerce Self-hosted et Open Source construite autour de Products structurés, d’attributs, de jeux d’attributs, de Categories, de niveaux de store, de Customers, d’Orders, de contenu, de modules, de thèmes et d’intégrations. Son modèle d’exploitation donne au marchand un contrôle direct, tout en lui confiant la responsabilité de l’infrastructure, du déploiement, de la sécurité, de la compatibilité des extensions et de la maintenance continue.
Une migration vers Magento doit conserver les données métier prises en charge sans les confondre avec la configuration de la boutique, le code, la présentation ou l’infrastructure. Cette présentation établit l’architecture nécessaire aux articles suivants du hub consacrés à l’adéquation de la plateforme, à la représentation du modèle de données, aux risques, à la préparation, au choix de l’approche de migration, à la validation et aux pièges récurrents.
Questions fréquentes
Magento est-il identique à Adobe Commerce ?
Non. Les deux solutions partagent une même lignée technologique et de nombreux concepts fondamentaux, mais Adobe Commerce comprend des fonctionnalités propriétaires et des services commerciaux qui ne font pas automatiquement partie de Magento.
Pourquoi les attributs sont-ils si importants dans Magento ?
Les attributs structurent l’information Product et peuvent alimenter l’administration, l’affichage en vitrine, la recherche, le filtrage, la comparaison et les intégrations. Une mauvaise gouvernance des attributs peut rendre un catalogue transféré difficile à maintenir, même si tous les Products sont présents.
Chaque catégorie source doit-elle devenir une Category Magento ?
Non. Les classifications source peuvent représenter la navigation, des filtres, des marques, des campagnes ou une organisation interne. Les Categories Magento doivent être utilisées lorsqu’elles créent une structure de navigation ou de contenu réellement utile.
Quelle est la différence entre websites, stores et store views ?
Il s’agit de niveaux de la hiérarchie de portée Magento. Les websites peuvent définir de grandes frontières commerciales, les stores peuvent organiser des catalogues autour de Categories racines et les store views peuvent fournir du contenu localisé ou une autre variante de vitrine.
L’historique d’Orders transféré configure-t-il les futurs paiements et expéditions ?
Non. Les Orders historiques peuvent conserver le contexte transactionnel, tandis que les passerelles actives, les intégrations d’expédition, les taxes, le processus de commande et le traitement des commandes nécessitent une configuration et des tests sur la cible.
Les données d’extensions et de modules personnalisés font-elles partie des données Magento standard ?
Pas automatiquement. Les extensions et modules personnalisés peuvent créer des attributs, tables, entités et flux de travail en dehors des structures du cœur. Leurs données doivent être identifiées selon leur objectif, leur destination et leur propriétaire à long terme.