L'intégration ERP Magento permet de connecter Adobe Commerce ou Magento Open Source à un système backend tel qu'Epicor Prophet 21, NetSuite OneWorld ou SAP Business One, afin que les articles, les stocks, les clients, les tarifs, les commandes et les factures soient transférés entre les deux systèmes sans avoir à les saisir manuellement à nouveau. Il ne s'agit pas d'un produit prêt à l'emploi que l'on achète tel quel. Il s’agit d’un choix architectural, et le choix approprié dépend du volume des commandes, du nombre de comptes bénéficiant de tarifs contractuels, ainsi que du système qui détient l’autorité finale en matière de prix et de crédit.
Nous avons mis en place et remanié suffisamment de ces connexions pour savoir que les projets qui s’enlisent échouent rarement à cause du code. Ils échouent parce que personne n’a précisé dans quel sens chaque donnée devait circuler, ou parce qu’une équipe a choisi un modèle conçu pour un catalogue deux fois plus volumineux que le sien. Cet article présente les quatre méthodes reproductibles pour structurer une intégration ERP Magento, les objets de données que chacune d’entre elles doit gérer, ainsi que le coût réel du travail une fois la réunion de cadrage terminée.
Si l'on fait abstraction du jargon commercial, l'intégration d'un ERP à une solution de commerce électronique se résume à une seule question : quel système fournit les données exactes concernant une information donnée, et comment l'autre système peut-il le savoir ? Magento est très performant pour présenter un catalogue, enregistrer une commande et traiter un paiement. Il n'est toutefois pas conçu pour calculer une matrice tarifaire dans le cadre d'un contrat portant sur 1 200 comptes, ni pour gérer les stocks répartis entre quatre entrepôts de distribution. C'est là le rôle de l'ERP.
Une intégration ERP-Magento, au niveau des données, correspond à un ensemble défini de flux unidirectionnels ou bidirectionnels entre les deux systèmes. Les articles transitent généralement de l’ERP vers Magento. Les commandes transitent généralement de Magento vers l’ERP. Les données relatives aux stocks et aux prix peuvent circuler dans les deux sens selon le modèle retenu, et c’est précisément là que la plupart des discussions sur le périmètre du projet déraillent, car « tout synchroniser » ne constitue pas une spécification.
Avant de comparer les modèles architecturaux, il est utile de bien comprendre ce que l’intégration d’un ERP à un site e-commerce permet réellement de résoudre et ce qu’elle ne permet pas : elle ne remplace pas votre processus de gestion des informations produit, elle ne corrige pas une base de données articles désorganisée, et elle ne fera pas en sorte qu’un ERP installé il y a 12 ans expose soudainement des points de terminaison propres et bien documentés. Elle transfère des données qui sont déjà fiables. Si les données ne sont pas fiables dans l’ERP, l’intégration reproduira fidèlement ce problème dans Magento, mais plus rapidement.
Il existe quatre façons reproductibles de structurer ce travail. Chacune d'entre elles correspond à une plage de volume différente, à un responsable différent de la logique métier et à un mode de défaillance différent à terme.
| Motif | Fourchette de volume des ordres | Où réside la logique métier | Coût de construction type | Coût récurrent | En quoi cela échoue-t-il ? |
| De point à point | Moins de 50 commandes par jour | Répartis entre les deux systèmes, souvent en double | De 15 000 à 35 000 dollars | Faible, mais augmente à chaque mise à jour d'ERP ou de Magento | Le système cesse de fonctionner sans prévenir dès qu'une des deux API change ; personne ne s'en rend compte jusqu'à ce qu'un client se plaigne. |
| Middleware / iPaaS | 50 à 500 commandes par jour | Couche de transformation entre les deux systèmes | De 40 000 à 90 000 dollars | Entre 1 500 et 5 000 dollars par mois pour la plateforme et l'assistance | Accumulation de demandes en attente lors des pics de trafic si personne ne surveille le tableau de bord du middleware |
| Connecteur côté ERP | Quel que soit le volume, si le connecteur du fournisseur ERP prend déjà en charge vos objets | Au sein du progiciel de gestion intégré (ERP), selon les conditions du fournisseur | Configuration de 10 000 à 35 000 dollars | Licence de 500 à 2 000 dollars par mois | C'est la feuille de route du fournisseur de connecteurs qui détermine ce qui est possible ; les cas limites en matière de tarification contractuelle sortent souvent du champ d'application |
| Couche de service personnalisée | Plus de 500 commandes par jour, ou plusieurs canaux de vente en dehors de Magento | Un service dédié dont votre équipe a la responsabilité | De 80 000 $ à plus de 200 000 $ | Nécessite une ressource de développement interne ou sous contrat à long terme | Une ressource précieuse, mais qui devient un handicap dès le jour où la personne qui l’a mise en place quitte l’entreprise |
Les intégrations point à point relient directement l'API REST de Magento à l'API propre à l'ERP, sans couche intermédiaire. Elles sont rapides à mettre en place et conviennent parfaitement à un catalogue comptant moins de quelques milliers de références et générant un volume de commandes modeste, mais chaque mappage de champs est défini dans du code que seul un développeur comprend pleinement.
Les plateformes de middleware et d'iPaaS, telles qu'Alumio, MuleSoft et Boomi, se situent entre Magento et l'ERP et gèrent la logique de transformation.
Les connecteurs côté ERP sont préconfigurés par l'éditeur de l'ERP ou par un partenaire certifié. NetSuite OneWorld, par exemple, propose des options de connecteurs éprouvées pour Magento. Le compromis est réel : vous bénéficiez d'un délai de mise en service plus court, mais vous devez vous conformer aux hypothèses du connecteur concernant le fonctionnement des barèmes de prix et des commandes multidevises.
Le recours à des couches de services personnalisées s'avère pertinent lorsque le volume ou la complexité dépasse ce qu'un connecteur ou un outil iPaaS standard peut raisonnablement gérer. Les files d'attente de messages, telles que RabbitMQ, s'inscrivent souvent dans ce modèle pour traiter les événements asynchrones liés aux commandes et aux stocks sans perte d'enregistrements lors d'un pic de trafic. Ce modèle offre davantage de fonctionnalités que les autres, mais sa maintenance est plus coûteuse ; nous ne le recommandons donc pas par défaut.
Sur Adobe Commerce Cloud, l'intégration d'Adobe Commerce ERP fonctionne différemment. Les communications sortantes transitent par une couche d'infrastructure gérée, et Adobe App Builder vous offre un environnement sans serveur et piloté par les événements pour exécuter une logique personnalisée sans modifier le code source principal.
Cela modifie le calcul du coût du middleware, car vous ne comparez plus le coût d'une solution sur mesure lourde à celui d'un abonnement à un middleware coûteux. Avant de signer un contrat de middleware prévu pour un catalogue plus vaste que celui que vous exploitez, vérifiez quelle partie de votre intégration ERP Adobe Commerce peut être exécutée dans Adobe App Builder à la place.
Toute intégration entre Magento et un ERP, quel que soit le modèle retenu, doit traiter les six mêmes objets de données. Chacun d'entre eux soulève une question spécifique à laquelle il convient d'apporter une réponse par écrit avant le début du développement.
C'est en négligeant l'une de ces étapes lors de la phase d'analyse que l'on aboutit à une intégration ERP Magento techniquement aboutie, mais qui présente des dysfonctionnements.
C'est cette décision qui détermine pratiquement tous les autres aspects de la mise en place du système. Pour la plupart des fabricants, distributeurs et grossistes, l'ERP doit gérer les prix, les stocks et le crédit, un point c'est tout. Magento reflète ces valeurs. Il ne les calcule pas.
Epicor Prophet 21, Epicor BisTrack, SAP Business One et Infor M3 intègrent tous des moteurs de tarification conçus pour gérer les contrats à plusieurs niveaux, les paliers de volume et les conditions spécifiques à chaque compte, ce que Magento n’a jamais été conçu pour reproduire. Tenter de recréer cette logique dans Magento implique de la gérer en double, et les deux copies finiront par présenter des divergences. Notre guide stratégique sur l’intégration d’Epicor Prophet 21 et de Magento considère cela comme un principe de base non négociable : l’ERP fait autorité pour tout ce qui est lié à un accord négocié.
La gestion des stocks offre un peu plus de souplesse. Certains distributeurs conservent une quantité tampon dans Magento afin d’éviter toute survente en cas de retard de synchronisation, en affichant délibérément un stock légèrement inférieur à celui dont dispose réellement l’ERP. Il s’agit là d’un choix de conception légitime, et non d’un bug, à condition que cela soit documenté et non découvert par une équipe du service client amenée à traiter des réclamations.
Le crédit est l'élément que les équipes oublient le plus souvent de mettre en correspondance. Si le compte d'un client fait l'objet d'un blocage de crédit dans Sage Intacct ou NetSuite OneWorld, cela bloque-t-il sa prochaine commande dans Magento, ou cela se traduit-il simplement par le marquage de la commande pour un contrôle manuel une fois qu'elle a été enregistrée ? Les deux réponses sont valables. Aucune des deux ne devrait être le fruit du hasard.
La synchronisation en temps réel semble être la solution qui s'impose d'emblée, jusqu'à ce que l'on en évalue le coût. La gestion des stocks en temps réel pour un catalogue de 40 000 références, mise à jour à chaque mouvement de marchandise dans n'importe quel entrepôt, est coûteuse à mettre en place et à exploiter, et elle ne résout généralement qu'un problème qui n'existe pas encore.
Une question de départ plus pertinente consiste à déterminer quels objets nécessitent véritablement un traitement en temps réel et lesquels peuvent être traités selon un calendrier préétabli. Les commandes doivent être transmises à l’ERP aussi près du temps réel que le permet le système, car une commande retardée entraîne un retard dans l’exécution de la commande. Pour la plupart des catalogues recevant moins de 500 commandes par jour, la gestion des stocks fonctionne parfaitement avec une synchronisation programmée toutes les 15 à 30 minutes. En dehors des ventes flash, les prix ont rarement besoin d’être mis à jour plus d’une fois par jour.
Considérer chaque objet comme s'il nécessitait la même fréquence de synchronisation est l'une des raisons les plus courantes pour lesquelles le budget consacré au middleware dépasse largement ce que le volume de commandes justifie réellement.
Tout modèle d'intégration finit par connaître un dysfonctionnement. Une API atteint son délai d'expiration, le format d'un champ change lors d'une mise à jour de l'ERP, une file d'attente s'engorge pendant une promotion. Ce qui distingue un incident mineur d'un incident grave, c'est le fait qu'une personne désignée s'en aperçoive ou non dans la journée.
Nous concevons chaque intégration autour d'un rapport de rapprochement publié le lundi matin, qui comprend cinq vérifications spécifiques :
Une personne, généralement le responsable des opérations e-commerce ou le directeur informatique chargé de l'intégration, doit effectivement consulter ce rapport chaque semaine. Un tableau de bord que personne n'ouvre n'est pas un système de surveillance. C'est la trace d'une défaillance qui finira par être découverte par un client plutôt que par votre équipe.
Les discussions budgétaires se déroulent mieux lorsqu'on s'appuie sur des fourchettes de prix liées à une hypothèse précise plutôt que sur un simple « ça dépend ». Voici comment nous évaluons l'ampleur des travaux d'intégration ERP Magento, en partant du principe qu'il s'agit d'un catalogue B2B de taille moyenne avec un accès standard à l'API REST et à GraphQL des deux côtés.
Un point de comparaison utile consiste à comparer une solution de milieu de gamme à SAP Business One : nos missions d’intégration « » avec SAP Business One se situent généralement entre 40 000 et 70 000 dollars, car l’API de la couche de service de Business One est bien documentée, ce qui réduit la phase d’analyse sans pour autant restreindre l’étendue des fonctionnalités dont le magasin a réellement besoin.
Quand vaut-il mieux attendre plutôt que de mettre en place une intégration ? Nous avons déjà conseillé à certains clients de reporter la mise en place d’une intégration d’une année supplémentaire, et cette décision s’avère judicieuse à trois conditions précises : moins d’une vingtaine de commandes par jour, une grille tarifaire qui évolue tous les trimestres plutôt que quotidiennement, et l’absence de responsable interne chargé de surveiller la synchronisation une fois celle-ci lancée. Un processus d’exportation CSV manuel bien géré et effectué de manière cohérente est toujours préférable à une intégration mal entretenue.
Si vous êtes à la recherche de services d'intégration ERP Magento, quelques questions directes permettront de mettre en évidence le manque d'expérience bien plus rapidement que n'importe quelle analyse de portfolio.
Un associé senior saura répondre directement à ces cinq questions. Un revendeur qui se contente de réciter le texte de la page marketing d'un fabricant de connecteurs n'en sera généralement pas capable.
Si Magento et votre ERP fonctionnent actuellement comme deux systèmes déconnectés, le point de départ n’est pas une mise en place. Il s’agit d’une phase d’analyse de deux semaines. Nous mettons en correspondance les six objets de données avec les champs spécifiques de votre ERP, nous extrayons les chiffres réels relatifs aux commandes et aux volumes de références (SKU) plutôt que des estimations, et nous déterminons quel système doit gérer les prix, les stocks et le crédit pour votre entreprise en particulier. Cette phase de découverte aboutit à une recommandation d’architecture écrite précisant l’un des quatre modèles, une fourchette de coûts et un calendrier réaliste, afin que la personne chargée de défendre le budget en interne dispose d’éléments plus concrets qu’une simple estimation du fournisseur. Il s’agit de la suite logique une fois que vous savez approximativement dans quel modèle s’inscrivent votre volume de commandes et la structure de vos comptes.
Le coût dépend presque entièrement du degré d'intégration préalable déjà en place. Un commerçant disposant d'une API ERP moderne et d'une synchronisation des stocks en temps réel dépensera bien moins qu'un autre qui doit mettre en place cette connectivité à partir de zéro. La définition du périmètre commence par un audit des éléments déjà en place.
Le coût dépend de votre système ERP, de l'architecture d'intégration, du volume de commandes et de la complexité des données. À titre indicatif, une intégration simple de type « point à point » peut coûter entre 15 000 et 35 000 dollars, tandis qu'une intégration basée sur un middleware peut varier entre 40 000 et 90 000 dollars. Des couches de services personnalisées plus complexes peuvent coûter entre 80 000 et 200 000 dollars, voire davantage. Pour établir un devis précis, il est nécessaire d'évaluer vos systèmes spécifiques, vos flux de données et vos besoins métier.
Les délais varient de 3 à 6 semaines pour la configuration d'un connecteur côté ERP, et de 4 à 9 mois pour une couche de service personnalisée, en fonction du volume de commandes et du nombre d'objets de données à mapper.
Les risques les plus courants sont les écarts de prix entre les systèmes, les stocks surévalués et les blocages de crédit qui ne parviennent pas à empêcher la finalisation de la commande ; tous ces problèmes découlent du fait de ne pas avoir déterminé à l'avance quel système est responsable de chaque objet de données.
Un connecteur est adapté s'il prend déjà en charge vos niveaux tarifaires contractuels, la hiérarchie de vos comptes et la logique de crédit ; dans le cas contraire, vous aurez besoin d'un middleware ou d'une couche personnalisée pour combler les lacunes laissées par un connecteur générique.
Cette solution est destinée aux fabricants, distributeurs et grossistes dont le volume de commandes B2B est suffisamment important pour que la saisie manuelle entre les différents systèmes soit source d'erreurs, généralement dès que le nombre de commandes quotidiennes dépasse environ 20 à 50.
