Migration Magento 1 → Magento 2 / Adobe Commerce — Modernisez votre E-commerce sans Perdre une Commande

#Magento 1 EOL depuis 2020 — Le Risque est Concret, pas Théorique

Magento 1 (Community Edition et Enterprise Edition) n'est plus maintenu depuis le 30 juin 2020. Adobe, qui a acquis Magento en 2018, a confirmé cette date d'End of Life et n'a publié aucun patch de sécurité depuis. Plusieurs années après cette date, en 2026, les boutiques Magento 1 encore en production ne sont pas simplement 'en retard' — elles sont en infraction avec les standards de sécurité du e-commerce.

#Vulnérabilités critiques non corrigées

La liste des CVEs affectant Magento 1 sans correctif disponible s'allonge chaque année. Les plus critiques sont des vulnérabilités d'injection de template dans le moteur d'email Magento (exécution de code PHP arbitraire côté serveur via un simple formulaire de commande), des injections XML dans les layouts du backend admin et des vulnérabilités XXE dans le parsing XML. Adobe patche ces failles sur Magento 2, mais pas sur Magento 1 (EOL).

Au-delà des CVEs individuelles, le malware Magecart (du nom de la plateforme ciblée) est un ensemble de scripts JavaScript malveillants injectés sur les pages de paiement Magento 1 pour capturer les données de carte bancaire en temps réel. Les groupes Magecart ciblent prioritairement les boutiques Magento 1 parce qu'elles ne reçoivent plus de patches et que les vulnérabilités d'injection sont connues et documentées.

#Conformité PCI-DSS impossible

Toute boutique e-commerce qui traite des paiements par carte bancaire doit être conforme PCI-DSS (Payment Card Industry Data Security Standard). L'exigence 6.2 de PCI-DSS impose que les logiciels soient protégés contre les vulnérabilités connues en installant les patches de sécurité du vendor dans un délai d'un mois après publication.

Avec Magento 1 EOL, il n'y a plus de patches — la conformité est donc techniquement impossible. Les audits PCI-DSS des boutiques Magento 1 sont très difficiles à réussir. Pour les marchands qui utilisent une passerelle de paiement externe (Stripe, Adyen, PayPal) avec redirection, le risque PCI-DSS direct est moindre — mais les vulnérabilités d'injection permettent tout de même de compromettre le serveur et d'intercepter les données avant la redirection.

#Écosystème d'extensions en abandon

Le Magento Marketplace pour Magento 1 est fermé depuis 2020. Les éditeurs d'extensions Magento 1 (Amasty, MageWorx, Mirasvit, Aheadworks, Fooman) ont cessé le support de leurs extensions M1 entre 2020 et 2022. Les extensions M1 encore installées ne reçoivent plus de mises à jour de sécurité, de correction de bugs, ni de compatibilité avec les versions récentes de PHP.

De plus, Magento 1 est bloqué sur PHP 7.2 à 7.4 maximum — or PHP 7.4 est lui-même en EOL depuis novembre 2022. La chaîne de dépendances EOL (Magento 1 + PHP 7.4 + extensions non maintenues) crée un empilement de vulnérabilités qui se renforce mutuellement.

#Magento 2 / Adobe Commerce — Ce qui change fondamentalement

Magento 2 n'est pas une évolution incrémentale de Magento 1. C'est une réécriture complète de la plateforme sur une architecture moderne. Comprendre les différences structurelles est indispensable pour planifier correctement la migration.

#Architecture et base de données

Magento 2 utilise un schéma de base de données restructuré. Les tables EAV (Entity-Attribute-Value) ont été optimisées, les tables de flat catalog simplifiées, et de nouvelles tables ajoutées (staging, versioning, message queues). La migration des données n'est pas un simple dump/import SQL — elle nécessite une transformation structurelle des données d'un schéma vers l'autre.

Le Magento Data Migration Tool officiel (outil CLI en ligne de commande) gère cette transformation pour les données standard (produits, catégories, clients, commandes), mais les données des extensions custom nécessitent des scripts de migration dédiés.

Le système de modules Magento 2 est basé sur Composer : chaque module est un paquet Composer installable indépendamment, avec déclaration de dépendances, versioning sémantique, et autoloading PSR-4. C'est un changement radical par rapport au système Magento 1 où les modules étaient copiés dans les dossiers app/code/community ou app/code/local sans gestion de dépendances.

#Frontend : PWA Studio vs Hyvä

Le frontend Magento 2 par défaut (thème Luma basé sur LESS + Knockout.js + RequireJS) est notoirement lent et complexe à personnaliser. En 2026, deux alternatives dominent. PWA Studio (Adobe officiel) : framework PWA React pour Magento 2 avec GraphQL comme couche API. Adapté aux projets qui veulent une expérience mobile native-like, mais courbe d'apprentissage élevée.

Hyvä Themes : thème Magento 2 alternatif basé sur Alpine.js + Tailwind CSS, qui remplace complètement la stack frontend par défaut. Performances nettement améliorées par rapport à Luma, développement frontend beaucoup plus rapide. Chez Nehos, on recommande Hyvä pour la majorité des projets migration M1 → M2 en raison de ses performances et de sa simplicité de développement.

#APIs REST et GraphQL

Magento 2 expose des APIs REST et GraphQL natives couvrant l'intégralité du catalogue, du panier, du checkout, des clients, et de l'administration. Ces APIs sont absentes de Magento 1 (qui ne disposait que d'une API SOAP vieillissante et limitée). La disponibilité d'APIs modernes facilite les intégrations avec les ERP (SAP, Sage, Cegid, Odoo), PIM (Akeneo, Pimcore), CRM (Salesforce, HubSpot), et les outils d'analytics.

#Stratégies de Migration — Trois Approches selon la Complexité

#Approche A — Migration standard avec Data Migration Tool

L'approche standard convient aux boutiques Magento 1 de taille modérée (moins de 10 000 SKUs) avec des extensions standard du marketplace et peu de personnalisations du core. Le Magento Data Migration Tool (fourni par Adobe) migre les données en trois passes : Settings (configuration magasin, taxes, méthodes de livraison et paiement), Data (produits, catégories, clients, commandes, avis, newsletters), et Delta (changements survenus entre le début de la migration et la bascule).

Le thème est recréé en Magento 2 (pas de portage possible — les thèmes M1 et M2 sont architecturalement incompatibles). Les extensions sont remplacées par leurs équivalents M2 ou développées en custom si pas d'équivalent.

#Approche B — Migration ETL custom avec transformation

Pour les boutiques complexes (multi-store, multi-langue, catalogue 50 000+ SKUs, attributs produits très personnalisés, règles promotionnelles complexes), l'outil standard de migration ne suffit pas. On construit un pipeline ETL (Extract-Transform-Load) custom qui extrait les données de la base M1, les transforme selon les règles métier spécifiques (nettoyage de données, fusion de doublons, normalisation des attributs), et les charge dans le schéma M2.

Ce pipeline est scriptable, rejouable, et testable — on peut exécuter la migration à blanc autant de fois que nécessaire avant la bascule réelle.

#Approche C — Migration progressive avec double-run

Pour les boutiques à très fort trafic ou avec des contraintes de disponibilité extrêmes (0 downtime contractuel), la migration progressive fait coexister M1 et M2 pendant une période de transition. Un reverse proxy (nginx, Varnish, ou CDN) route le trafic : les nouvelles pages (CMS, catégories migrées) sont servies par M2, les pages non encore migrées restent sur M1.

Les deux instances partagent la même base de données via un système de synchronisation bidirectionnelle. Cette approche est la plus complexe et la plus coûteuse mais élimine le downtime de bascule.

#Migration SEO — Préserver le Référencement Acquis

Une migration e-commerce mal gérée sur le plan SEO peut provoquer une forte chute de trafic organique, qui met des mois à se rétablir. La préservation SEO est une composante critique de toute migration Magento 1 → 2.

#Redirections 301 exhaustives

Magento 1 et Magento 2 ne génèrent pas les mêmes structures d'URL. Les URL rewrites M1 (table core_url_rewrite) doivent être mappées vers les URL rewrites M2 (table url_rewrite). Toutes les anciennes URLs M1 qui n'ont pas d'équivalent direct en M2 reçoivent une redirection 301 vers la page M2 la plus pertinente.

Cela inclut les URLs de produits, catégories, pages CMS, et les URLs de recherche. Un plan de redirection complet est généré automatiquement depuis la base M1, vérifié manuellement pour les cas ambigus, et implémenté via la configuration M2 native ou un module de redirection dédié.

#Preservation des données structurées

Les données structurées Schema.org (Product, Offer, BreadcrumbList, Organization) déjà en place sur M1 doivent être recréées sur M2 — idéalement enrichies avec les types supplémentaires (FAQ, AggregateRating, Review). Le sitemap XML est régénéré automatiquement par M2 et soumis à Google Search Console dès la bascule.

#Suivi post-migration

Durant les 4 semaines suivant la bascule, un monitoring quotidien des métriques SEO est en place : positions Google (Semrush, Ahrefs), trafic organique (Google Analytics 4 / Search Console), taux d'erreurs 404 (logs serveur + Search Console), Core Web Vitals (PageSpeed Insights, CrUX). Tout décrochage est traité en priorité critique.

#Migration des Extensions — Le Point le Plus Chronophage

Sur une boutique Magento 1 typique, 20 à 40 extensions sont installées. Chaque extension doit être analysée individuellement : existe-t-il un équivalent Magento 2 du même éditeur ? Un équivalent d'un éditeur différent ? Faut-il développer la fonctionnalité en custom ? Peut-on simplement supprimer l'extension (fonctionnalité non utilisée ou redondante) ?

Catégories d'extensions courantes et stratégie de migration. Extensions SEO (Mirasvit SEO Suite, Amasty SEO Toolkit) : équivalents M2 disponibles chez les mêmes éditeurs — migration directe avec reconfiguration. Extensions de navigation (Amasty Improved Layered Navigation, Manadev Layered Navigation) : équivalents M2 disponibles — attention à la migration des configurations de filtres custom.

Extensions ERP/PIM (connecteurs SAP, Akeneo, custom) : généralement à redévelopper en custom M2 en utilisant les APIs REST/GraphQL natives. Extensions de paiement (Stripe, Adyen, PayPal, custom) : modules M2 officiels disponibles chez les PSP — reconfiguration plutôt que développement.

Extensions checkout custom : souvent les plus complexes à migrer, car le checkout M2 est architecturalement très différent (JavaScript Knockout/React vs PHP côté serveur M1).

Chaque extension custom (code maison dans app/code/local) est un cas particulier qui nécessite une réécriture en respectant les patterns M2 : injection de dépendances, plugins (interceptors), observers, API contracts.

#Migration des Intégrations — ERP, PIM, CRM, Transporteurs

Les intégrations entre Magento 1 et les systèmes tiers (ERP, PIM, CRM, WMS, transporteurs) sont souvent construites avec des connecteurs custom ou des modules spécifiques M1. Ces intégrations doivent être reconstruites sur M2 en tirant parti des APIs REST/GraphQL natives.

ERP (SAP, Sage X3, Cegid, Odoo) : les flux de synchronisation (produits, stocks, prix, commandes) sont reconstruits via les APIs M2 REST ou via des message queues (RabbitMQ, natif dans M2). PIM (Akeneo, Pimcore) : le connecteur officiel Akeneo pour Magento 2 est disponible et mature — migration directe si le PIM est déjà Akeneo.

CRM (Salesforce, HubSpot) : modules M2 officiels ou redéveloppement API custom. Transporteurs (Colissimo, Chronopost, DPD, UPS, custom) : modules M2 des transporteurs disponibles dans la majorité des cas.

#Performance — Gains Mesurables après Migration

Les gains de performance entre Magento 1 et Magento 2 bien configuré sont significatifs. Magento 2 avec Varnish full-page cache, Redis pour le session storage et le cache backend, Elasticsearch/OpenSearch pour la recherche catalogue, et un thème Hyvä optimisé délivre des performances mesurables nettement supérieures.

Ce que nous mesurons avant et après chaque migration : TTFB (Time to First Byte), score Lighthouse Performance mobile, débit sous charge, temps de chargement des pages catalogue. Ces gains ont un impact direct sur le taux de conversion e-commerce, que nous suivons également.

#Méthodologie Nehos — Phases et Calendrier

Phase 0 — Audit boutique Magento 1 (5 à 10 jours). Inventaire complet : extensions installées, personnalisations core, taille catalogue, intégrations tiers, état du thème, couverture de tests, performances actuelles. Output : document de spécification migration, mapping extensions M1 → M2, plan de migration données, chiffrage définitif.

Phase 1 — Socle Magento 2 (3 à 5 semaines). Installation et configuration Magento 2 / Adobe Commerce sur infrastructure cible. Configuration des services (Varnish, Redis, Elasticsearch, RabbitMQ). Installation du thème cible (Hyvä recommandé). Configuration CI/CD (GitHub Actions ou GitLab CI). Mise en place de l'environnement de staging.

Phase 2 — Migration données et extensions (6 à 16 semaines selon complexité). Migration données via Data Migration Tool ou ETL custom. Installation et configuration des extensions M2. Développement des extensions custom M2 (réécriture des extensions M1 custom). Migration des intégrations ERP/PIM/CRM. Configuration des règles promotionnelles, taxes, méthodes de livraison et paiement.

Phase 3 — Thème et personnalisation frontend (4 à 8 semaines). Développement du thème M2 (Hyvä ou PWA Studio). Adaptation des pages CMS. Tests cross-browser et responsive. Optimisation Lighthouse.

Phase 4 — Tests, UAT, bascule (2 à 4 semaines). Tests de non-régression fonctionnels (parcours achat complet, gestion catalogue, back-office). UAT (User Acceptance Testing) avec l'équipe e-commerce client. Migration delta (données créées pendant la migration). Bascule DNS + redirections 301 + monitoring SEO.

#Exemple de situation — distributeur industriel B2B sur Magento 1

Ce n'est pas une référence client : c'est une situation type que nous rencontrons.

Un distributeur industriel B2B avec un catalogue de plusieurs dizaines de milliers de SKUs et des milliers de comptes clients professionnels, sur une boutique Magento 1 Enterprise en production depuis des années, intégrée à SAP pour les stocks et les commandes. Symptômes : audit PCI-DSS échoué (vulnérabilités critiques non patchables), performance dégradée (plaintes des commerciaux terrain utilisant la boutique sur tablette), extensions M1 cassées après une tentative de passage PHP 7.4, impossibilité d'intégrer un nouveau PIM Akeneo.

La mission type : migration complète M1 → M2 avec thème Hyvä, en cinq étapes -- audit Phase 0, socle M2 et migration des données par ETL custom, extensions et intégrations (connecteurs SAP et Akeneo), thème Hyvä, tests et bascule. On mesure ensuite la conformité PCI-DSS, le score Lighthouse mobile, les commandes mobiles, le temps de traitement d'une commande et la vitesse d'enrichissement produit.

#Tarification

Le prix dépend de la complexité de la boutique Magento 1. Nous chiffrons sur devis en 48 h après un premier échange. Repères :

Boutique M1 simple (moins de 5 000 SKUs, 5 à 10 extensions standard, pas d'intégration ERP lourde) : à partir de 15 000 € HT, tarif d'un premier logiciel ou module sur mesure. Migration Data Migration Tool standard, thème Hyvä, extensions M2 équivalentes.

Boutique M1 intermédiaire (5 000 à 30 000 SKUs, 15 à 25 extensions dont quelques custom, intégration ERP basique) : à partir de 30 000 € HT, tarif d'un projet plus large. Migration ETL custom, thème Hyvä personnalisé, redéveloppement des extensions custom.

Boutique M1 complexe (30 000+ SKUs, multi-store/multi-langue, intégrations ERP/PIM/CRM lourdes, extensions custom nombreuses) : à partir de 50 000 € HT, tarif d'une plateforme B2B complexe. Migration ETL custom multi-pass, thème Hyvä avancé, redéveloppement complet des intégrations, migration progressive possible.

Le chiffrage inclut l'audit initial Phase 0. Estimation précise en 30 minutes via RDV : Calendly migration Magento.