Intégration e-commerce à Paris

ERP, CRM, PIM, WMS, outils comptables, transporteurs, passerelles de paiement, plateformes marketing et services internes disposant d’interfaces exploitables.

La question utile n’est pas le nom du logiciel mais ce qu’il expose. Un outil doté d’une interface documentée et d’un environnement d’essai se connecte en quelques jours. Un outil sans interface mais capable de déposer et de lire des fichiers se connecte aussi, par échange à intervalle régulier — c’est moins élégant et cela fonctionne depuis vingt ans. Un outil fermé, sans interface ni export programmable, ne se connecte pas : il faut alors passer par une intervention de son éditeur, et le calendrier ne nous appartient plus.

Nous vérifions donc trois choses avant de chiffrer : la documentation est-elle accessible, existe-t-il un environnement de test séparé de la production, et qui chez vous détient les droits d’y créer un accès.

C’est ce dernier point qui décale les projets. Obtenir un identifiant sur l’ERP demande parfois trois semaines de circuit interne, et nous le demandons au démarrage plutôt qu’à la veille de la recette.

Pas toujours. Le rythme dépend de la donnée : le stock demande plus de fraîcheur qu’un catalogue, et une synchronisation continue coûte davantage à exploiter.

Un découpage courant par flux : les stocks toutes les dix à quinze minutes, les prix une à quatre fois par jour, le catalogue une fois par nuit, les commandes immédiatement à la validation, les statuts d’expédition à réception de l’information transporteur.

Le temps réel intégral a deux coûts. Il expose votre ERP à la charge du site — un pic de trafic devient un pic de requêtes sur un système de gestion qui n’a pas été dimensionné pour cela. Et il complique le diagnostic : quand une donnée est fausse, un échange programmé laisse une trace horodatée qu’on relit, un flux continu laisse un journal à dérouler.

Le cas où le temps réel s’impose vraiment : un stock faible et une rotation rapide, où survendre coûte un remboursement et un client. Là, on interroge le stock au moment de la validation du panier, pas seulement à l’affichage.

Par des identifiants stables, des règles de correspondance, des contrôles d’unicité et une source de référence définie pour chaque donnée.

Le principe : chaque entité a une clé qui ne change jamais et qui vient du système de référence. Un produit s’identifie par sa référence interne, pas par son nom ; un client par son code dans l’ERP, pas par son courriel — qui change. Quand cette clé n’existe pas, il faut la créer avant la première synchronisation, et c’est un travail de données, pas de développement.

Les doublons naissent presque toujours du même endroit : un client qui commande en tant qu’invité puis crée un compte avec une autre adresse, ou un produit importé deux fois sous deux références fournisseur. Nous posons donc une règle de rapprochement explicite, avec un seuil, et surtout une file de cas ambigus traités à la main plutôt qu’une fusion automatique — une fusion erronée de deux clients est difficile à défaire.

Et un contrôle périodique compte les entités des deux côtés. Un écart qui grandit lentement est le signe d’une règle incomplète.

Les flux sont conçus avec files d’attente, reprises et alertes afin d’éviter la perte de données et de permettre un rattrapage contrôlé.

Concrètement : une commande validée sur la boutique est d’abord enregistrée localement, puis transmise. Si la transmission échoue, elle reste en file et sera réessayée selon un intervalle croissant. Le client, lui, a sa confirmation — il n’a pas à connaître l’état de votre ERP.

Trois garde-fous accompagnent ce dispositif. Une alerte nominative au bout de trois échecs, parce qu’une file qui grossit sans destinataire ne sert à rien. Une garantie d’idempotence : rejouer une commande déjà passée ne doit pas la créer deux fois, ce qui suppose une clé d’unicité côté ERP. Et une visibilité de la file dans le back-office, pour que vos équipes voient ce qui attend.

Dans l’autre sens, un stock qui ne se rafraîchit plus doit se comporter de manière définie : soit on garde la dernière valeur connue en l’indiquant, soit on bascule sur un affichage prudent. C’est une décision commerciale, et nous vous la posons.

Par des accès restreints, des secrets gérés hors du code, des échanges chiffrés, des journaux et des contrôles sur les données personnelles échangées.

Les identifiants d’accès à votre ERP sont les clés de votre gestion : ils ne vivent jamais dans le dépôt de code ni dans un fichier de configuration versionné. Ils sont injectés par l’environnement, et leur rotation est une procédure écrite.

Le compte technique utilisé par l’intégration est dédié et limité : il peut lire les prix et écrire les commandes, il ne peut pas supprimer un client ni modifier un tarif. Ce cloisonnement demande une discussion avec votre administrateur et il vaut la demi-journée qu’il coûte — c’est ce qui limite les dégâts d’une erreur comme d’une compromission.

Côté données personnelles, seules celles nécessaires à la commande transitent : nom, adresse de livraison, coordonnées. Aucune donnée bancaire ne passe par ces flux. Les journaux consignent les échanges sans recopier leur contenu personnel, ce qui permet de diagnostiquer sans constituer un second fichier client dans les traces.

Oui après analyse des flux, des mappings, des erreurs passées et des dépendances, afin d’identifier ce qui peut être conservé ou repris.

L’analyse commence par ce que l’intégration fait réellement, qui diffère souvent de ce qu’elle était censée faire. On déroule les journaux des derniers mois : quels flux tournent, à quelle fréquence, avec quel taux d’échec, et lesquels sont en erreur depuis si longtemps que personne ne les regarde plus. Ce dernier cas est fréquent et instructif.

On cherche ensuite le mapping — la correspondance champ à champ entre les deux systèmes. Quand il n’est pas documenté, il faut le reconstituer depuis le code, et c’est le poste le plus lourd de la reprise : comptez de deux à cinq jours selon le nombre de flux.

La décision de conserver ou de refaire se prend flux par flux, pas globalement. Un flux de stock simple et stable se garde ; un flux de commandes sans reprise sur erreur se refait, parce qu’il perdra une commande tôt ou tard et que personne ne saura laquelle.

Sur un environnement de préparation, avec des jeux de données représentatifs, des cas d’erreur simulés et des vérifications de bout en bout.

Les jeux de données représentatifs sont le point décisif : une intégration testée sur trois produits propres passe, et échoue en production sur le produit à douze déclinaisons, celui dont le libellé contient un caractère spécial, et celui qui est présent dans l’ERP mais désactivé. Nous demandons donc un extrait réel plutôt qu’un échantillon construit.

Les cas d’erreur se simulent volontairement : couper l’accès à l’ERP pendant un envoi, renvoyer une réponse malformée, introduire un produit dont la référence n’existe pas, provoquer un dépassement du délai d’attente. Un flux qui n’a pas été testé en panne n’a pas été testé.

La vérification de bout en bout clôt la recette : une commande passée sur la boutique doit se retrouver dans l’ERP avec le bon montant, la bonne TVA, le bon client et le bon transporteur — puis revenir avec son numéro de suivi. C’est le seul test qui valide la chaîne entière, et nous le faisons avec une commande réelle.

Le suivi précise les responsabilités, les alertes, les délais et les procédures de reprise entre vos équipes, vos éditeurs et Novatis.

Une intégration fait intervenir au moins trois parties, et l’absence de partage écrit des responsabilités transforme chaque incident en discussion. Le document de suivi dit donc, par type d’erreur, qui regarde en premier : une commande non transmise, c’est nous ; un tarif faux dans l’ERP, c’est vous ; une interface qui change sans préavis, c’est l’éditeur.

Les alertes sont nominatives et différenciées : une erreur isolée part dans un journal, une file qui dépasse un seuil déclenche un message, une interruption de flux supérieure à une durée convenue déclenche un appel. Sans ces seuils, on reçoit trop d’alertes et plus personne ne les lit.

La procédure de reprise est écrite avant d’en avoir besoin : comment rejouer les échanges manqués, dans quel ordre, et comment vérifier qu’on n’a rien créé deux fois. C’est la partie qu’on improvise le jour de l’incident, et c’est celle qui coûte le plus.