Connecter son ERP à son site web : le code n'est pas le vrai chantier

Trois semaines de développement au devis. Six mois plus tard, toujours pas de mise en production, alors que le développeur n'a presque plus touché au code depuis des semaines. Quand une PME décide de connecter son ERP à son site web, ce décalage n'a rien de rare, et il surprend presque toujours la direction.

La raison tient en un constat : le connecteur est la partie la plus prévisible du projet. Ce qui consomme le calendrier, ce sont les données qu'il doit transporter et les décisions que personne n'a encore prises. Tant que ces deux points restent en suspens, le code attend, quelle que soit sa qualité.

Pourquoi connecter son ERP à son site web prend plus de temps que prévu

Sur le papier, la mécanique est simple. Le connecteur lit des données dans l'ERP, les transforme au format attendu par le site, les envoie, puis fait le chemin inverse pour les commandes. Les flux à couvrir sont connus et peu nombreux :

• le catalogue : références, désignations, attributs, poids, conditionnements ;
• les stocks, que le guide de CommandeB2B conseille de rafraîchir à un intervalle de 15 à 30 minutes, ou en continu quand les volumes l'exigent ;
• les tarifs, y compris les conditions propres à chaque client ;
• les comptes clients : adresses, conditions de paiement, encours autorisé ;
• les commandes et leurs statuts, du site vers l'ERP puis retour.

Chacun de ces flux se code avec des outils éprouvés : appels d'API, tâches planifiées, files de messages, gestion des erreurs et des reprises. Un développeur expérimenté sait estimer ce travail à quelques jours près.

Ce qu'il ne peut pas estimer, c'est l'état des données qu'il va trouver et la clarté des règles qu'on va lui transmettre. Dans la plupart des projets de ce type, le connecteur lui-même ne représente qu'une part minoritaire de l'effort total. Le reste part en allers-retours : comprendre l'ERP, corriger des fiches, faire valider des règles de prix, arbitrer entre services.

Ce temps-là n'apparaît dans aucun devis, parce que personne ne sait le mesurer avant de commencer. C'est pourtant lui qui décide de la date de mise en ligne.

Une API mal documentée coûte plus cher que le connecteur

Tous les ERP ne se valent pas face à l'intégration. Odoo expose une API externe documentée publiquement, mais elle évolue : depuis la version 19, les anciennes interfaces XML-RPC et JSON-RPC sont dépréciées au profit d'une nouvelle API JSON-2, et leur suppression est prévue avec Odoo 20. Un connecteur écrit sur l'ancienne interface est donc à reprendre. Autre point à vérifier en amont : selon la documentation d'Odoo, l'accès aux données par l'API externe est réservé aux formules Custom. SAP Business One propose son Service Layer, une interface REST basée sur OData. À l'inverse, sur les versions de Sage 100 installées sur site, l'accès passe généralement par le SDK Objets Métiers, par un connecteur tiers ou par une lecture directe de la base de données SQL Server.

Mais une API qui existe n'est pas forcément une API exploitable. Les blocages les plus fréquents :

• des champs nommés en codes internes, sans dictionnaire de données ;
• des champs personnalisés ajoutés par un intégrateur il y a dix ans, que personne ne sait plus interpréter ;
• aucun environnement de test, chaque essai se fait sur la base de production ;
• des limites d'appels ou des temps de réponse découverts en cours de route.

L'absence de base de test est celle qui coûte le plus de semaines. Le développeur avance avec prudence, et chaque vérification remonte vers la seule personne qui maîtrise l'ERP : souvent le comptable ou l'intégrateur historique, rarement disponible le jour même.

Mon conseil : avant de signer quoi que ce soit, exigez une copie de test de l'ERP et la documentation des champs utilisés. Si l'éditeur ou l'intégrateur ne peut pas les fournir, vous connaissez déjà le premier facteur de retard de votre projet.

Des fiches produits conçues pour le magasinier, pas pour l'acheteur

Un ERP gère des articles pour les acheter, les stocker et les facturer. Il n'a pas été pensé pour les vendre en ligne. Les fiches qu'on y trouve ressemblent souvent à ceci : une désignation tronquée du type « VIS TETE HEX INOX A2 M8X40 BTE100 », aucune photo, des caractéristiques noyées dans un champ commentaire, des unités de vente différentes pour deux articles de la même famille.

Le site, lui, a besoin d'un titre lisible, d'une description, d'attributs structurés pour alimenter les filtres et de visuels. Passer de l'un à l'autre relève du nettoyage de données, et ce travail reste en grande partie manuel. Les problèmes classiques :

• des doublons créés au fil des années pour un même produit acheté chez deux fournisseurs ;
• des références obsolètes jamais archivées, qui remonteraient telles quelles sur le site ;
• des familles organisées selon la comptabilité, pas selon la logique d'un client qui cherche un produit.

Un connecteur ne corrige rien de tout cela. Il transporte fidèlement ce qu'il trouve. Brancher un ERP désordonné sur une boutique en ligne revient à publier ce désordre, en temps réel.

Deux options existent. Enrichir les fiches directement dans l'ERP, si ses champs le permettent. Ou intercaler un PIM comme Akeneo, qui devient la source des contenus marketing. Sur un gros catalogue, la question dépasse d'ailleurs le connecteur : elle touche la capacité de la plateforme elle-même, comme le montre le cas des catalogues à 50 000 références.

Les tarifs qui n'existent formellement nulle part

En vente aux particuliers, un produit a un prix. En B2B, le guide de CommandeB2B le rappelle, chaque client peut disposer de sa propre grille : remises selon la famille, prix nets négociés au cas par cas, remises par quantité, promotions limitées dans le temps, facturation en devise étrangère. L'ERP en contient une partie. Le reste vit ailleurs.

C'est un constat fréquent : une part des conditions tarifaires n'est écrite nulle part de façon exploitable. Elle dort dans un fichier Excel du directeur commercial, dans un mail de 2019, dans la mémoire d'un commercial qui accorde toujours un petit geste à tel client historique. Le comptoir applique ces règles à la main depuis des années sans que personne ne les ait formalisées.

Un site ne sait pas improviser. Il exige des règles métier explicites :

• quelle remise l'emporte quand un client a à la fois une remise famille et un prix net ;
• une promotion se cumule-t-elle avec une remise par quantité ;
• que se passe-t-il pour un article sans tarif défini pour ce client.

Chaque question paraît simple. Chacune demande pourtant une réunion, parfois deux, car la direction découvre que deux commerciaux appliquent deux logiques différentes. Les plannings glissent ici : pas sur le calcul du prix, qui reste un code modeste, mais sur l'attente d'une décision.

Mon conseil : faites rédiger ces règles par écrit, avec cinq ou six clients réels et le prix attendu pour chacun. Ce tableau devient le jeu de test du connecteur.

Quel système fait foi ? La question que personne ne tranche

Un client modifie son adresse de livraison sur le site. Le même jour, l'assistante commerciale la corrige dans l'ERP. Laquelle gagne ? Sans réponse écrite, la synchronisation écrase l'une ou l'autre, et quelqu'un s'en aperçoit au moment d'une livraison ratée.

Dans un échange bidirectionnel, chaque donnée doit avoir un propriétaire unique. Pas un système « principal » en général, mais un maître par type d'information :

• stocks et prix : l'ERP, dans la quasi-totalité des cas ;
• descriptions, photos, contenus optimisés pour le référencement : le site ou le PIM ;
• comptes clients : à décider, et c'est souvent là que les débats commencent ;
• commandes : créées sur le site, puis pilotées dans l'ERP dès leur intégration.

Le blocage est rarement technique. Il est organisationnel : chaque service tient ses propres données pour les bonnes. La logistique fait confiance à l'ERP, le marketing au back-office de la boutique, les commerciaux à leur CRM. Trois outils, trois versions de la vérité, et un développeur au milieu qui ne peut pas arbitrer à la place de la direction.

Cette cartographie des flux de données conditionne la cohérence de tout le système d'information. C'est un principe qui prend tout son sens dans le développement d'un outil métier sur mesure, où chaque donnée a un emplacement et un responsable définis avant la première ligne de code.

Préparer l'intégration avant d'écrire la première ligne de code

Les projets qui tiennent leurs délais ont un point commun : le travail sur les données commence avant le développement, pas pendant. Concrètement, quatre livrables sont à produire en interne :

• la liste des flux, avec leur sens et leur fréquence ;
• le système maître de chaque donnée, validé par la direction ;
• les règles tarifaires écrites, illustrées par des cas chiffrés ;
• un échantillon de 50 à 100 fiches produits nettoyées, qui sert de modèle pour le reste du catalogue.

Vient ensuite le choix technique. Un connecteur natif, quand il existe pour votre couple ERP et plateforme, reste la voie la plus rapide : il connaît les deux modèles de données et l'éditeur le maintient. Un outil d'automatisation comme Make ou n8n s'impose quand plusieurs systèmes doivent dialoguer, au prix d'une dépendance supplémentaire et d'un coût de maintenance. Un développement spécifique se justifie pour des règles qu'aucun produit ne couvre, avec une maintenance à votre charge à chaque mise à jour de l'ERP.

Aucune de ces options ne dispense du nettoyage. Un connecteur natif installé en deux jours sur des données en vrac produit un site faux en deux jours.

Et parfois, la bonne réponse est de ne pas connecter. Une entreprise qui traite une dizaine de commandes en ligne par semaine sur un catalogue stable peut fonctionner longtemps avec un export CSV quotidien et une saisie manuelle des commandes. L'intégration devient rentable quand la double saisie coûte plus cher que le projet et sa maintenance. Ce calcul se fait avant de lancer le chantier, pas après.

Un projet de données avant d'être un projet de code

Relier un ERP à une boutique en ligne oblige l'entreprise à mettre de l'ordre dans ce qu'elle sait d'elle-même : ses produits, ses prix, ses clients. Le connecteur ne fait que révéler cet état, avec une précision parfois gênante, et c'est ce travail de clarification qui fixe la vraie durée du projet.

Si un développeur vous demandait demain quel système fait foi pour les prix de vos clients, sauriez-vous lui répondre en une seule phrase ?

Sources : Comment connecter son ERP à un site e-commerce B2B (CommandeB2B) External RPC API, documentation développeur (Odoo)