Connecter son site à son ERP : les quatre pièges.

Un projet de connexion entre un site et un logiciel de gestion échoue rarement sur la technique. Il échoue sur quatre questions qu’on croit secondaires et qu’on tranche trop tard. Qui détient la vérité sur une donnée, à quelle fréquence elle circule, ce qui se passe quand l’échange tombe, et qui répond quand les deux systèmes ne disent pas la même chose.

Cet article décrit ces quatre points, puis ce qu’il faut avoir écrit avant d’ouvrir un éditeur de code : le tableau des flux, la règle de rapprochement des identifiants et la procédure de reprise.

Point 1 — Qui détient la vérité sur chaque donnée

C’est la question fondatrice, et la plus souvent esquivée. Pour chaque donnée partagée, un seul système doit faire référence, et l’autre s’aligne.

La répartition qui fonctionne, dans la très grande majorité des cas :

• Le logiciel de gestion fait référence pour les stocks, les tarifs, les conditions commerciales, les fiches clients comptables et les statuts de commande après expédition.
• Le site fait référence pour les contenus marketing, les photos, les descriptions, les avis, les comptes créés en ligne et le panier avant validation.

Un projet où le prix peut être modifié des deux côtés produira des écarts, et personne ne saura lequel est juste. Le tableau des flux doit donc comporter une colonne « système de référence » remplie pour chaque ligne, sans exception. Quand cette colonne est vide, le développement s’arrête : ce n’est pas une question technique, c’est une décision d’organisation.

Point 2 — À quelle fréquence, et dans quel sens

Le temps réel est presque toujours une mauvaise idée, et presque toujours ce qu’on demande au départ.

La fréquence se décide donnée par donnée, en fonction du coût d’une information périmée :

• Les stocks : c’est le seul flux où un décalage se paie immédiatement, par une vente de produit indisponible. Un rafraîchissement toutes les cinq à quinze minutes suffit sur la plupart des catalogues ; en dessous, le gain est théorique et la charge serveur réelle.
• Les tarifs : une fois par jour, hors opération commerciale. Une mise à jour immédiate est utile en période de promotion, pas le reste de l’année.
• Les commandes : à l’événement, dès la validation du paiement. C’est le seul flux qui justifie un envoi immédiat, parce qu’il déclenche la préparation.
• Le catalogue : une fois par jour suffit, avec un déclenchement manuel disponible pour les nouveautés.
• Les clients : à l’événement dans un sens, par lot dans l’autre.

Le sens compte autant que la fréquence. Un flux bidirectionnel sur la même donnée est la principale source de boucles d’écrasement : le site écrit, le logiciel réécrit, le site réécrit. Sur chaque donnée, un sens unique — c’est la conséquence directe du point 1.

Point 3 — Ce qui se passe quand l’échange tombe

Le logiciel de gestion sera indisponible. Pendant sa sauvegarde nocturne, pendant sa mise à jour, pendant une coupure réseau. La question n’est pas de l’éviter, elle est de décider du comportement du site à ce moment-là.

Quatre décisions à écrire :

• Le site continue de vendre avec les dernières données connues, ou il bloque la commande ? Dans la quasi-totalité des cas, il continue : perdre des commandes est plus grave que de gérer quelques écarts de stock.
• Les échanges manqués sont-ils rejoués ? Une file d’attente qui conserve les messages non transmis et les renvoie à la reprise est la pièce la plus rentable de l’architecture. Sans elle, une coupure de trente minutes se traduit par des commandes qui n’arriveront jamais en préparation.
• Les tentatives sont-elles idempotentes ? Le même message envoyé deux fois doit produire un seul effet. C’est ce qui évite les commandes en double, le défaut le plus visible côté client.
• Qui est alerté, et après combien d’échecs ? Un flux en panne silencieuse pendant quatre jours coûte plus cher que la panne elle-même.

Sur les automatisations que nous mettons en place, c’est ce point qui distingue un montage qui tient d’un montage qui demande une surveillance humaine permanente.

Point 4 — Le rapprochement des identifiants

Deux systèmes, deux jeux de références. Un produit porte une référence interne dans le logiciel de gestion et un identifiant dans le site. Un client existe des deux côtés, parfois en double. La règle de rapprochement doit être écrite, unique et stable.

Trois pièges classiques :

• Le rapprochement sur un libellé. Le nom du produit change, et le lien est rompu. Le rapprochement se fait sur une référence immuable, jamais sur un texte affiché.
• Le rapprochement des clients sur le courriel. Deux contacts d’une même entreprise partagent parfois une adresse générique, et un client change d’adresse. En e-commerce entre professionnels, le rapprochement se fait sur un identifiant de compte, pas sur la personne.
• Les déclinaisons. Tailles, coloris, conditionnements : c’est là que se produisent les erreurs de stock les plus difficiles à diagnostiquer, parce qu’elles ne concernent qu’une variante sur douze.

Le livrable attendu est une table de correspondance, stockée, consultable, avec la date de création du lien. Quand un écart survient, elle permet de répondre en dix minutes au lieu de deux jours.

Ce qu’il faut avoir écrit avant de développer

Trois documents, une journée de travail, et la moitié des dérapages évités.

• Le tableau des flux : une ligne par donnée, avec le sens, la fréquence, le système de référence, le volume attendu et le comportement en cas d’erreur.
• La règle de rapprochement : sur quel champ, avec quelle règle de repli, et que fait-on d’un enregistrement non rapproché — rejeté, ou mis en attente de décision humaine.
• La procédure de reprise : comment on rejoue une journée d’échanges, qui déclenche l’opération, et comment on vérifie que le rattrapage est complet.

Deux vérifications préalables valent aussi la journée qu’elles coûtent : demander la documentation de l’interface du logiciel de gestion — beaucoup d’éditeurs facturent l’accès, et certains ne proposent qu’un export de fichiers — et demander qui, chez l’éditeur, répond en cas de problème. Un projet d’intégration avec un éditeur injoignable est un projet à deux inconnues.

En résumé

Une connexion entre un site et un logiciel de gestion se joue sur quatre décisions d’organisation : un système de référence par donnée, une fréquence et un sens uniques par flux, un comportement explicite en cas de panne avec file d’attente et idempotence, et une règle de rapprochement fondée sur des références immuables. Les trois livrables préalables — tableau des flux, règle de rapprochement, procédure de reprise — tiennent en une journée et déterminent le reste du projet. Le temps réel n’est utile que sur les stocks et les commandes ; partout ailleurs, il coûte cher et ne sert à personne.