Magento

Magento (désormais Adobe Commerce, avec une édition open source) est une plateforme e-commerce de niveau enterprise. Elle gère des catalogues volumineux, le multi-boutique, le B2B et des règles métier complexes, au prix d'une complexité technique et d'une infrastructure plus exigeantes que ses concurrentes.

Quand Magento se justifie

Magento est pertinent pour les marchands à gros catalogue, avec du B2B, du multi-boutique international ou des besoins de personnalisation poussés. En dessous, sa complexité et ses coûts d'exploitation se justifient rarement : en production, il demande un cache HTTP comme Varnish, Redis, un moteur de recherche et un serveur correctement dimensionné, et un développeur venant de PrestaShop ou WooCommerce met plusieurs semaines à devenir productif sur son architecture (modules, plugins, injection de dépendances compilée). Je compare les trois plateformes dans WooCommerce, PrestaShop ou Magento : quel CMS e-commerce choisir.

Intégrer Magento : ce que l'expérience apprend

J'ai conçu et maintenu le connecteur Magento d'une plateforme SaaS PIM/DAM, qui alimentait les catalogues de marchands et remontait leurs commandes. Plusieurs points reviennent sur chaque intégration :

• Les endpoints bulk changent l'échelle. Plutôt qu'un appel par produit, le connecteur envoie un lot, récupère un identifiant de tâche, puis vérifie le statut de traitement. Sur un gros catalogue, c'est la différence entre des heures et des minutes.
• Les attribute sets sont un piège silencieux. Si un attribut envoyé n'existe pas dans l'attribute set du produit, Magento ignore la valeur, sans erreur ni avertissement. Ce comportement m'a coûté des heures de débogage avant que j'ajoute une validation côté PIM, avant l'envoi.
• Les produits configurables (un parent et des produits simples enfants) ne correspondent pas directement à la façon dont un PIM ou un ERP modélise les variantes. Ce mapping se conçoit selon la structure réelle du catalogue du client.
• L'idempotence est obligatoire. Chaque produit est identifié par sa référence unique et mis à jour par une opération de création-ou-remplacement, pour qu'un export rejoué ne crée jamais de doublon.
• L'export différentiel fondé sur les dates de modification réduit la durée des synchronisations et la pression sur l'API.

Module du marché ou connecteur sur mesure

Les modules connecteurs du marché couvrent bien les cas standards : un ERP courant, un catalogue simple, des flux bien balisés. Ils atteignent leurs limites quand l'ERP est propriétaire, quand le catalogue a un schéma atypique, quand la volumétrie dépasse ce que le module sait traiter, ou quand chaque mise à jour du module casse quelque chose. Je travaille en approche API-first, indépendante des éditeurs : le connecteur est un service Symfony qui parle aux API officielles de Magento, supervisé, documenté, et dont le code appartient au client.

Les pièges d'un projet Magento

• Choisir Magento par prestige pour un catalogue que PrestaShop gérerait très bien, et subir ensuite ses coûts d'exploitation.
• Écrire directement en base pour aller plus vite : on contourne les règles de Magento, ses index et ses événements, et la prochaine montée de version devient risquée.
• Accumuler les modules tiers : chacun ajoute ses plugins et ses requêtes, et les conflits apparaissent à chaque mise à jour.
• Des flux sans supervision : un import qui échoue partiellement laisse des prix ou des stocks faux en ligne sans que personne ne le sache.

Magento offre une puissance considérable pour le e-commerce enterprise, mais cette puissance a un coût : complexité technique, infrastructure exigeante et besoin d'une intégration rigoureuse avec le reste du SI.

Je conçois des connecteurs Magento sur mesure vers les ERP, PIM et outils métier, ainsi que la connexion de Magento aux marketplaces. Pour les détails techniques, voir Connecter un PIM à PrestaShop et Magento : retour d'expérience.