Que fait réellement un connecteur ERP e-commerce ?

Le mot connecteur laisse croire à un branchement, comme si deux systèmes pouvaient être reliés puis se comprendre. La réalité est moins simple : un connecteur est une série de flux indépendants, chacun avec son sens de circulation, sa fréquence, ses règles de résolution des conflits et ses cas d'échec. Un projet de connecteur ERP e-commerce échoue rarement pour des raisons techniques et presque toujours parce que ces règles n'ont pas été écrites avant de commencer. Savoir précisément ce que chaque flux transporte, dans quel sens et qui décide en cas de désaccord constitue l'essentiel du travail, et cette réflexion appartient au métier autant qu'à la technique.

Ce qu'un connecteur transporte réellement

Un connecteur se décompose en cinq à sept flux distincts, qu'il vaut mieux traiter séparément dès la conception. Les produits descendent de la gestion vers la boutique, les commandes remontent dans l'autre sens, les stocks descendent, les clients circulent parfois dans les deux sens, les factures remontent ou descendent selon l'organisation comptable. Chacun de ces flux possède son propre rythme, sa propre tolérance à la latence et ses propres conséquences en cas de panne. Les traiter comme un tout unique, en une synchronisation globale lancée chaque nuit, produit un dispositif qui échoue en bloc et dont le diagnostic devient pénible.

Cette décomposition a des conséquences pratiques immédiates. Un flux de stock peut échouer une heure sans grande conséquence si un seuil de sécurité a été prévu, alors qu'un flux de commandes bloqué une heure retarde toute la préparation logistique. Un flux produit peut tourner une fois par jour, un flux de prix doit tourner dès qu'une modification intervient. Ces différences justifient des traitements séparés, avec leurs propres journaux et leurs propres alertes, plutôt qu'un traitement monolithique dont l'échec ne dit rien de ce qui a réellement posé problème. La définition générale de ces outils est rappelée dans notre article sur le connecteur ERP et son utilité en e-commerce.

Il faut également distinguer ce qui relève de la synchronisation continue et ce qui relève de la reprise initiale. Charger dix mille produits pour la première fois n'a rien à voir avec la mise à jour quotidienne de quelques dizaines de fiches : la première opération se fait par lots, tolère plusieurs heures et demande un contrôle de qualité complet, la seconde doit être rapide et silencieuse. Concevoir un dispositif unique pour ces deux usages conduit soit à une reprise initiale interminable, soit à une synchronisation quotidienne inutilement lourde, deux situations que l'on rencontre régulièrement sur les projets menés dans l'urgence. La reprise initiale mérite d'ailleurs d'être répétée au moins une fois sur un environnement de test avant la bascule réelle, l'expérience montrant qu'elle révèle systématiquement des cas de données que personne n'avait envisagés.

Le sens des flux et les règles de priorité

La question qui règle tout est celle du système de référence pour chaque donnée. Pour un prix d'achat, la gestion commerciale fait autorité et la boutique ne doit jamais pouvoir la contredire. Pour une description commerciale enrichie, c'est l'inverse. Pour un stock, la gestion fait autorité mais la boutique doit pouvoir réserver. Pour une adresse de livraison saisie par le client, la boutique fait autorité au moment de la commande puis la gestion prend le relais. Chacune de ces décisions doit être écrite noir sur blanc, champ par champ, avant la moindre ligne de code.

Ce document, souvent réduit à un tableau de trois colonnes, est le livrable le plus important du projet. Il désigne pour chaque champ le système maître, la fréquence de synchronisation et le comportement en cas de modification des deux côtés. Sans lui, chaque cas particulier sera tranché au fil de l'eau par la personne qui développe, selon ce qui lui paraît logique sur le moment, et personne ne saura plus six mois plus tard pourquoi une description écrasée chaque nuit ne reste pas modifiée. Ce type d'arbitrage est indissociable de la réflexion sur l'intégration d'un ERP avec un site e-commerce B to B.

La règle la plus utile, quand elle est applicable, consiste à établir un maître unique par champ et à interdire techniquement la modification dans l'autre système, en verrouillant le champ dans l'interface. Une règle appliquée par la seule discipline des utilisateurs finit toujours par être contournée, généralement par la personne la plus pressée un vendredi soir. Quand le verrouillage technique n'est pas possible, il faut au moins que la synchronisation trace ce qu'elle écrase, afin qu'une modification perdue puisse être expliquée plutôt que constatée avec incompréhension. Un journal des écrasements, consultable par le métier et non seulement par la technique, désamorce en quelques minutes des discussions qui durent autrement des semaines.

Les produits et les prix

Le flux produit descend en général de la gestion commerciale, qui détient les références, les libellés, les familles et les caractéristiques. La boutique y ajoute ce que la gestion ne sait pas porter : descriptions rédigées, images, contenus enrichis, éléments de référencement. Cette répartition paraît évidente et produit pourtant le conflit le plus fréquent de tous, lorsque le flux descendant écrase les libellés retravaillés pour la vente. La solution consiste à distinguer un libellé technique, piloté par la gestion, et un libellé commercial, piloté par la boutique, avec une valeur de repli de l'un vers l'autre. Le même raisonnement vaut pour les caractéristiques techniques, que la gestion connaît sous forme de codes et que la boutique doit présenter sous forme lisible, ce qui suppose une table de correspondance plutôt qu'un transfert direct.

Les prix méritent une attention particulière parce qu'ils cumulent plusieurs difficultés. Un prix de vente peut dépendre du client, de la quantité, d'une promotion en cours, d'un contrat négocié ou d'une devise. Les gestions commerciales expriment ces règles dans leurs propres structures tarifaires, que la boutique ne sait généralement pas reproduire. Deux stratégies existent : transférer un prix calculé, simple mais qui multiplie les lignes à transporter dès que les combinaisons sont nombreuses, ou interroger la gestion en temps réel au moment de l'affichage, plus juste mais qui rend la boutique dépendante de la disponibilité du système de gestion. Un montage intermédiaire consiste à transférer les prix publics et à n'interroger la gestion que pour les clients disposant de conditions particulières, ce qui limite la dépendance aux seuls parcours qui le justifient.

Pour un site professionnel où chaque client dispose de conditions propres, l'interrogation en temps réel devient souvent inévitable, et elle impose alors une mise en cache courte et un comportement de repli en cas d'indisponibilité. Pour un site grand public avec une grille unique, le transfert des prix calculés suffit largement. Le choix entre les deux approches détermine une part importante du budget, question que nous abordons dans notre article sur le budget à prévoir pour connecter un ERP à une boutique.

Les stocks, le flux le plus délicat

Le stock est la donnée qui pose le plus de problèmes parce qu'elle est partagée entre plusieurs canaux et qu'elle change en permanence. La gestion commerciale connaît le stock physique, la boutique connaît les commandes en cours de validation, et aucun des deux ne détient à lui seul la disponibilité réelle. Un décalage de quelques minutes suffit pour vendre un article déjà parti, et ce décalage est inhérent à toute synchronisation périodique. Il ne peut pas être supprimé, seulement rendu acceptable. La question n'est donc pas d'éviter la survente mais de décider quel niveau de survente est tolérable et comment la traiter quand elle survient, ce qui relève d'une décision commerciale.

Trois dispositifs coexistent dans la pratique. Le seuil de sécurité consiste à ne publier qu'une partie du stock réel, ce qui absorbe le décalage au prix de ventes manquées sur les fins de série. Le contingent réservé attribue une quantité fixe à la boutique, ce qui simplifie tout mais immobilise du stock. La vérification en temps réel au moment de la validation de commande est la seule solution réellement correcte, et elle suppose que la gestion réponde en quelques centaines de millisecondes, ce qui n'est pas toujours le cas.

Quel que soit le dispositif retenu, la fréquence de synchronisation doit être élevée et le flux léger. Transporter uniquement les stocks modifiés depuis le dernier envoi permet de passer à des synchronisations toutes les quelques minutes sans charger les systèmes. Il faut également prévoir un contrôle de vraisemblance : une remise à zéro générale des stocks est presque toujours le signe d'un flux défectueux ou d'un fichier tronqué, et un dispositif qui l'applique sans vérification peut fermer une boutique entière en une synchronisation. Un seuil bloquant, refusant toute mise à jour affectant plus d'une certaine proportion du catalogue sans validation humaine, coûte une heure de développement et évite une journée de chiffre d'affaires perdue.

Les commandes et les clients

Le flux de commandes remonte de la boutique vers la gestion et constitue le flux le plus critique, puisque son interruption arrête la préparation. Il doit être déclenché par événement plutôt que par intervalle, dès qu'une commande atteint le statut correspondant à un paiement encaissé. Il doit également être protégé contre le rejeu : une même commande transmise deux fois produit une double expédition, incident bien plus coûteux à réparer qu'à prévenir. Un identifiant unique porté par la commande et vérifié côté gestion suffit à écarter ce risque.

Le retour d'information vers la boutique est tout aussi important et souvent négligé. Le numéro de commande dans la gestion, l'état de préparation, le numéro de suivi d'expédition et la facture doivent redescendre pour être affichés au client. Sans ce retour, le service client doit consulter deux systèmes pour répondre à une question simple, ce qui annule une partie du bénéfice attendu du connecteur. Ce flux descendant est en outre celui qui alimente les courriels de suivi, dont l'absence génère un volume important de demandes. Sur une boutique de taille moyenne, la mise en place de ce seul retour d'information réduit sensiblement le nombre de sollicitations reçues par le service client.

Les clients posent une question d'identité plus délicate qu'il n'y paraît. La gestion identifie un client par un code, la boutique par une adresse électronique, et le rapprochement échoue dès qu'une personne commande avec deux adresses différentes ou qu'une entreprise a plusieurs contacts. La règle la plus robuste consiste à créer le client dans la gestion à la première commande, à conserver le code retourné dans la fiche de la boutique, et à ne plus jamais rapprocher sur autre chose que ce code. Toute tentative de rapprochement sur le nom ou l'adresse produit des fusions abusives. Le cas des professionnels ajoute une difficulté supplémentaire, l'entité facturée et l'entité qui commande n'étant pas la même, ce qui impose de modéliser explicitement la relation entre compte et contacts.

Ce qu'un connecteur ne fait jamais

Un connecteur ne corrige pas les données. Si le catalogue de la gestion contient des libellés incohérents, des familles mal renseignées ou des produits obsolètes, tout cela se retrouvera sur la boutique. Beaucoup de projets découvrent à cette occasion l'état réel de leurs données, et le chantier de nettoyage devient alors la partie la plus longue du projet, souvent la plus utile. Le connecteur agit en réalité comme un révélateur, ce qui explique que beaucoup d'entreprises datent leur mise en ordre du catalogue de ce moment précis. Il vaut mieux l'anticiper explicitement que de le découvrir au moment de la recette, quand la mise en ligne est déjà annoncée.

Un connecteur ne remplace pas non plus une organisation. Si deux services modifient les mêmes informations sans s'être répartis les rôles, le connecteur ne fera que rendre le conflit visible et permanent. De la même façon, il ne compense pas l'absence de processus : une commande dont personne ne sait qui doit la valider ne sera pas mieux traitée parce qu'elle arrive automatiquement dans la gestion. Ces questions relèvent de l'organisation du travail et se règlent en réunion, pas en développement. Les repousser au motif que le connecteur va tout résoudre garantit simplement qu'elles se poseront plus tard, dans de plus mauvaises conditions.

Enfin, un connecteur ne rend pas une boutique indépendante de la gestion. Il crée au contraire une dépendance nouvelle, qu'il faut assumer et surveiller. Une indisponibilité du système de gestion pendant une opération commerciale importante devient un incident boutique, ce qu'elle n'était pas auparavant. Ce point doit être posé dès le départ, avec les comportements de repli associés : que se passe t il si la gestion ne répond plus, la boutique continue t elle de vendre, avec quelles données et pendant combien de temps. Répondre à ces questions avant la mise en production évite d'avoir à les trancher dans l'urgence un jour de forte activité.

Ce qui fait échouer un projet de connecteur

Le premier facteur d'échec est l'absence de décision sur les systèmes de référence, déjà évoquée, qui se manifeste tardivement sous forme de comportements incompréhensibles. Le deuxième est la sous estimation du travail de correspondance : les familles, les unités, les taux de taxe, les modes de paiement et les transporteurs n'ont pas les mêmes codes des deux côtés, et ces tables de correspondance représentent souvent plus de travail que le transport lui même. Elles doivent être maintenables par le métier, faute de quoi chaque nouveau transporteur demandera une intervention technique. Une interface simple, même rudimentaire, permettant d'ajouter une correspondance sans redéploiement, se rentabilise dès la deuxième modification.

Le troisième facteur tient à l'absence de supervision. Un flux qui échoue silencieusement pendant trois jours produit des dégâts considérables, et les détecter suppose une alerte sur l'échec comme sur l'absence anormale d'activité. Un flux de commandes qui ne transporte rien pendant une journée ouvrée est aussi suspect qu'un flux en erreur, et seul un contrôle explicite du volume attendu permet de s'en apercevoir. Un tableau de bord affichant simplement le nombre d'enregistrements traités par flux et par jour suffit à rendre ces anomalies évidentes pour quiconque y jette un œil. Cette supervision doit être conçue en même temps que les flux et non ajoutée après le premier incident.

Le dernier facteur est l'absence de rejouabilité. Un dispositif capable de retransmettre les données d'une période donnée, sans doublon, transforme un incident en incident mineur. Un dispositif incapable de rejouer impose une reprise manuelle, avec les erreurs que cela suppose. Cette capacité se conçoit dès le départ et coûte peu, elle devient très difficile à ajouter ensuite, et c'est pourtant la question qu'on ne pense jamais à poser au moment de choisir une solution. Elle mérite pourtant d'être posée en premier, avant même les questions de couverture fonctionnelle, car elle détermine le coût de tous les incidents à venir.