Tout éditeur dit aujourd'hui que son produit s'intègre. C'est à peu près aussi informatif que de dire qu'un bâtiment a des portes.
Une API logistique utile ne se résume pas à l'existence d'une interface de programmation, et l'interopérabilité encore moins. C'est la capacité de deux systèmes à se transmettre une information et à en tirer la même conclusion. Le premier point est technique, il se règle en quelques jours. Le second ne l'est pas, et c'est lui qui fait échouer les projets : si votre gestion commerciale et votre magasin ne donnent pas le même sens au mot « disponible », l'échange fonctionnera parfaitement et le résultat sera faux.
Ce texte propose quatre questions qui distinguent une vraie interopérabilité d'une liste de connecteurs, et six messages qui portent l'essentiel. La question de départ — construire en pensant l'interface d'abord — est traitée séparément sur api first.
Faites défiler latéralement pour voir toute la figure.
Les quatre questions qui décident
1. Qui détient chaque donnée ?
La question fondatrice, et celle qu'on saute le plus souvent. Une donnée doit avoir un propriétaire, et un seul — un système qui la crée, la modifie et dont la version fait foi.
Le partage habituel, dans un parc logistique :
- La boutique en ligne possède le prix, la fiche commerciale, le compte client.
- L'ERP possède le code article, le fournisseur, la commande d'achat, la commande client, la facture.
- Le magasin possède l'emplacement, la quantité physique, le numéro de lot, ce qui est réellement parti.
Quand deux systèmes se croient propriétaires de la même donnée, vous n'avez pas une intégration mais un conflit permanent, résolu chaque nuit par celui qui écrit en dernier. C'est l'origine de la moitié des divergences de stock qu'on attribue ensuite à « un problème d'interface ».
2. À quel rythme la donnée circule-t-elle ?
Toutes les données n'ont pas besoin du même rythme, et vouloir tout en continu coûte cher pour rien.
Ce qui doit être immédiat : la disponibilité envoyée vers la boutique, parce que l'écart se paie en survente. La commande qui descend vers le magasin, parce que l'heure limite n'attend pas.
Ce qui peut attendre l'heure : les réceptions attendues, les corrections de stock, les fiches article.
Ce qui peut attendre la nuit : les données de référence, les tarifs, les clôtures.
Un outil d'optimisation des stocks travaille sur un rythme planifié, parce qu'un conseil d'achat ne se recalcule pas à chaque mouvement de carton. Un lien d'expédition, lui, est événementiel. Ce ne sont pas deux qualités d'intégration, ce sont deux objets.
3. Qui gagne en cas de divergence ?
Il y aura des divergences. La question n'est pas de les éviter mais de savoir, à l'avance et par écrit, ce qui se passe quand elles arrivent.
La règle qui tient : sur une quantité physique, le magasin gagne. C'est le seul système dont la donnée vient d'un geste confirmé à un emplacement, et non d'un calcul. Si l'ERP écrase la position comptée du magasin pendant la nuit, vous avez une comptabilité propre et une préparation fausse.
Ce qui demande une décision explicite, à prendre avant le démarrage et non pendant le premier incident :
- Une correction de stock saisie dans l'ERP alors que le magasin a compté autre chose.
- Une commande annulée côté boutique alors qu'elle est déjà prélevée.
- Une fiche article modifiée dans l'ERP alors que des lignes sont en cours de préparation.
Le détail de l'affectation du stock entre canaux, qui est le cas le plus sensible, est sur logiciel de gestion des commandes.
4. Que se passe-t-il quand le lien tombe ?
C'est la question qui sépare une intégration de démonstration d'une intégration d'exploitation. Le lien tombera : maintenance chez l'un, coupure réseau chez l'autre, montée de version un vendredi soir.
Trois comportements à exiger :
L'entrepôt continue. Un magasin qui s'arrête parce que l'ERP ne répond pas est une architecture dangereuse. Le prélèvement et l'emballage doivent pouvoir continuer sur ce qui est déjà descendu.
Les messages s'accumulent et se rejouent. À la reprise, ce qui n'est pas passé doit repartir, dans l'ordre, sans qu'un humain ait à retrouver lesquels manquaient.
Un message envoyé deux fois ne compte qu'une fois. C'est la propriété appelée idempotence, et c'est celle dont l'absence se découvre toujours de la même façon : une expédition comptabilisée en double, un stock négatif, et deux heures de recherche.
Les six messages qui portent tout
Comparer des listes de connecteurs n'apprend rien. Comparer ce qui circule, oui. Un échange entre une gestion commerciale et un magasin tient en six messages, et un éditeur incapable de les décrire ne les a probablement pas stabilisés. Les sept symptômes qui trahissent un écosystème mal relié, et l'ordre dans lequel on branche, sont sur intégration des systèmes.
- L'article — code, libellé, unités, gestion par lot ou par numéro de série. Descend de l'ERP.
- La réception attendue — ce qui va arriver, de qui, quand. Descend de l'ERP.
- La réception réalisée — ce qui est arrivé, en quelles quantités, avec quels lots. Remonte du magasin.
- La commande à préparer — lignes, priorité, destinataire, transporteur. Descend de l'ERP ou de la boutique.
- L'expédition réalisée — ce qui est parti, sur quel support, avec quel numéro de suivi. Remonte du magasin.
- La correction de stock — l'écart constaté, avec son code motif. Remonte du magasin.
Le reste — retours, transferts inter-sites, réservations, facturation à l'activité — s'ajoute à mesure, et aucun de ces ajouts ne compense l'absence d'un des six. Les connexions disponibles sont listées sur connecteur ERP, et la façon dont la position se tient côté magasin sur système de gestion des stocks.
API logistique et architecture modulaire : ce que la modularité déplace
Une architecture faite de briques qui se parlent par interface n'est pas une mode : c'est ce qui permet de remplacer une pièce sans toucher aux autres. Vous changez de transporteur sans refaire votre gestion commerciale. Vous ajoutez une place de marché sans toucher à votre magasin. Vous changez d'outil de prévision sans réécrire vos interfaces d'entrepôt.
Mais la modularité déplace le travail, elle ne le supprime pas. Un parc monolithique a un fournisseur et un point de responsabilité ; un parc modulaire a six fournisseurs et un contrat de responsabilité à écrire. Ce qu'on gagne en souplesse, on le paie en coordination — et c'est généralement un bon échange, à condition de savoir qu'on le fait.
C'est précisément le rôle d'un partenaire d'intégration, dont le cadre est sur intégrateur logiciel.
Le voisinage, qui n'est pas le produit
Trois sujets reviennent dans presque toutes les conversations sur l'architecture logistique : l'intelligence artificielle, la blockchain et l'optimisation de tournées. Aucun des trois n'est ce que nous faisons, et il faut remettre les choses à leur place.
La prévision et le conseil d'achat sont le métier de partenaires de planification. Nous leur envoyons la position réelle et les corrections comptées, ils renvoient un conseil. La frontière est nette et elle est décrite sur la page de chaque partenaire.
Le transport et les tournées appartiennent à des outils dédiés, parmi lesquels RouteLogic. Nous disons ce qui est prêt à partir ; nous ne construisons pas la tournée, et nous ne prétendons rien sur l'empreinte carbone de celle-ci.
Les données produit enrichies relèvent d'un référentiel comme Akeneo, pas du magasin.
La blockchain ne fait pas partie de ce que nous faisons, et elle n'a rien à faire dans une page qui décrit nos échanges.
Ce qui reste au magasin est étroit et solide : exécuter le mouvement, le confirmer au scan, et dire la vérité sur ce qui s'est passé. Le détail est sur logiciel WMS.
Les quatre questions à poser à tout éditeur
Reprenez-les telles quelles dans votre grille d'évaluation, nous y compris.
Publiez-vous une documentation d'intégration consultable sans contrat ? Une documentation accessible sans rien signer est le meilleur indicateur de maturité d'une interface. Une documentation envoyée en PDF par courriel en est un autre, dans l'autre sens. Posez la question.
Existe-t-il un environnement d'essai accessible sans accompagnement ? Posez la question.
Qu'arrive-t-il si le même message est reçu deux fois ? Posez la question, et demandez à voir.
Comment les versions d'interface évoluent-elles, et quel préavis avant une rupture ? Posez la question, et faites-la écrire au contrat.
Un éditeur qui répond aux quatre par écrit vous a déjà dit l'essentiel sur sa manière de travailler.
Pour aller plus loin
BizBloqs s'intègre par des messages documentés, garde le magasin autonome quand le lien tombe, et laisse la planification, le transport et le référentiel produit à ceux qui en font leur métier. Pour poser vos quatre questions sur votre propre parc, réserver une démo. Si vous n'avez qu'un système et pas de boutique, l'interopérabilité n'est pas encore votre sujet.
