Fauré Le Page : de la commande d’achat Cegid à l’attendu de réception ShippingBo

1. Fauré Le Page et une logistique qui doit préserver la précision du produit

Une Maison parisienne, des références détaillées et plusieurs acteurs autour d’une même commande

Fauré Le Page présente son histoire comme celle d’une première Maison fondée au début du XVIIIe siècle à Paris, puis d’une nouvelle Maison installée rue Cambon depuis 2009. Son univers actuel associe maroquinerie, matières, couleurs et savoir-faire. Dans le système construit, cette richesse produit se traduit par des références, EAN, désignations, couleurs, variantes et images qui doivent rester identifiables dans les opérations d’achat et de réception.

Le périmètre ne concerne donc pas une donnée abstraite. Une ligne de commande fournisseur désigne un article précis, porte une quantité commandée et un prix unitaire, puis accumule au fil du temps les quantités expédiées et reçues. Une commande peut être non livrée, partielle ou livrée ; une expédition peut rester en brouillon, être envoyée ou reçue ; sa réception peut être en attente, incomplète ou terminée. Ces états donnent une lecture progressive plutôt qu’un simple avant/après.

Trois groupes interviennent. Cegid Y2 reste le système ERP qui émet et reçoit les fichiers métier. ShippingBo porte les objets logistiques, notamment les attendus de réception. Entre eux, le middleware transforme les formats et conserve la traçabilité. Enfin, le portail donne au fournisseur une surface adaptée à son rôle : consulter ses commandes, annoncer ce qui part réellement et suivre ce qui a été réceptionné.

Cette séparation est importante. Donner un accès direct à l’ERP ou au back-office d’intégration aurait mêlé des responsabilités qui ne sont pas les mêmes. Le fournisseur n’a pas besoin de piloter un parser de fichier ; il doit reconnaître sa commande, indiquer les quantités qu’il expédie et vérifier son ASN. À l’inverse, l’équipe qui supervise les flux a besoin de voir la source, la cible, le nombre de ressources, les erreurs, la progression et le temps de traitement.

2. Une construction en deux temps : industrialiser les flux, puis ouvrir le portail fournisseur

Faire émerger la chaîne métier depuis les premiers connecteurs jusqu’au retour de réception

La construction documentée s’étend du 24 février au 14 août 2025. Les premières semaines posent le socle Symfony 7, l’authentification ShippingBo, l’accès Azure et les premières commandes de transformation. Le projet progresse rapidement vers les articles, les préparations, les transferts TR3 et DTR, les achats CF, les retours RET, les réceptions RCP et les états de stock. Un journal d’intégration apparaît en parallèle pour rendre ces traitements lisibles.

Le deuxième mouvement, particulièrement visible en juin, transforme le middleware en application métier. Les entités fournisseur, commande, ligne de commande, expédition et ligne d’expédition organisent la donnée localement. Des espaces administration et fournisseur sont séparés. Les écrans de commande affichent quantités commandées, expédiées et reçues ; les formulaires d’expédition demandent les quantités ligne par ligne ; les progressions sont recalculées du produit jusqu’au fournisseur.

La chronologie montre une livraison par chaînes verticales. L’import d’une commande ne s’arrête pas au stockage en base : il mène à la vue fournisseur, à la création d’une expédition, à l’envoi asynchrone dans ShippingBo, à la lecture des quantités reçues et à la génération du fichier RCP. Cette façon de construire permet de confronter chaque règle à l’étape suivante au lieu d’accumuler des briques isolées.

Des configurations distinctes existent pour la sandbox et la production. Le pipeline construit et publie les images PHP et Nginx propres à ces environnements. Le projet contient également des tests unitaires pour les outils d’export, de PDF et d’aplatissement d’objets, ainsi que des tests d’intégration des lectures ShippingBo sur produits, commandes et attendus. Dans la chaîne de 2025, ces tests n’étaient toutefois pas exécutés automatiquement avant la publication des images.

3. Le vrai point de rupture : une commande ne dit pas encore ce qui va arriver

Distinguer quantité commandée, quantité expédiée et quantité reçue

Dans un ERP, la commande d’achat fixe un engagement : un fournisseur, des références, des quantités et des conditions. Pour l’entrepôt, cette information reste insuffisante. Une commande de cent unités peut arriver en une fois, en trois expéditions ou seulement en partie. La date prévue, le transporteur, le suivi et les lots appartiennent à l’expédition, pas nécessairement à la commande initiale.

ShippingBo matérialise cette étape à travers un attendu de réception, appelé supply capsule dans son API. Cet objet porte une référence source, un fournisseur, une date attendue et une collection de produits. Chaque produit possède sa référence source, une quantité prévue, une quantité reçue et éventuellement des numéros attendus. L’ERP Cegid, lui, attend un fichier RCP dont la structure et les références répondent à ses propres règles.

Le risque apparaît aux frontières. Si la commande est recopiée directement dans ShippingBo puis modifiée après le début de la réception, les quantités déjà enregistrées peuvent perdre leur sens. Si le retour ShippingBo ne retrouve pas l’expédition exacte, il peut être associé à la mauvaise commande. Si le fichier RCP omet l’établissement, le dépôt ou la référence externe, la réception est techniquement produite mais plus suffisamment contextualisée pour Cegid.

Dawap a donc choisi de conserver un modèle intermédiaire explicite. Une commande fournisseur contient ses lignes ; une expédition référence cette commande et contient ses propres lignes ; l’identifiant créé par ShippingBo est enregistré sur l’expédition. Cette chaîne d’identifiants rend possible le retour : l’objet reçu côté ShippingBo permet de retrouver l’expédition, puis la commande, le fournisseur et chaque ligne produit.

Cette modélisation donne également un sens aux expéditions partielles. La quantité déjà expédiée est cumulée par ligne de commande. Le formulaire calcule le restant disponible et permet de ne sélectionner que les articles qui partent dans l’ASN courante. Une deuxième expédition peut ensuite couvrir une autre partie de la même commande sans écraser la première.

4. 172 jours pour passer des connecteurs au portail fournisseur

Une trajectoire du 24 février au 14 août 2025

Le 24 février 2025, le projet démarre avec le socle applicatif, la gestion des utilisateurs et les premiers services ShippingBo. Dès le 26 février, les commandes d’échange avec ShippingBo, Cegid et Azure prennent forme. Les articles rejoignent ShippingBo avec leurs champs additionnels, les premières lectures API sont testées et les journaux de requêtes commencent à donner une trace exploitable des appels.

Du 27 février au 7 mars, le périmètre s’élargit rapidement. Les préparations de commande, les transferts magasin et entrepôt, les retours fournisseur, les stocks virtuels et les commandes d’achat apparaissent. Azure reçoit une gestion dédiée de l’authentification et des blobs. Des écrans donnent accès aux produits, commandes, fichiers, rejets et intégrations. Le rapport de stock peut être généré puis transmis par email.

Du 11 au 21 mars, la structure d’exploitation se consolide. RabbitMQ est raccordé pour les traitements asynchrones ; les flux transferts sont refactorés autour du journal d’intégration ; les réceptions fournisseur disposent de recherches et de vues dédiées. Cette phase transforme une collection de scripts en système où chaque exécution possède une identité, un service, un sens, un statut et des erreurs associées.

Mai apporte les configurations de production. Juin ouvre un nouveau chapitre avec le domaine fournisseur : fournisseurs, commandes d’achat, articles, expéditions, invitations et espaces dédiés. Entre le 24 et le 26 juin, les progressions de livraison et réception, le tableau de bord fournisseur, la création d’expédition et les vues de commande se rejoignent. Le dernier jalon du 14 août consolide le packaging de production et les exports.

Les 172 jours ne sont ni une durée contractuelle, ni une promesse standard. Ils délimitent la fenêtre visible entre le premier socle et la révision de production du 14 août. Les configurations ne permettent pas, à elles seules, de dater une recette ou une bascule client ; cette chronologie s’arrête donc au dernier jalon technique identifié.

5. Une architecture où chaque système garde une responsabilité claire

Cegid pour la vérité ERP, ShippingBo pour l’exécution logistique, Symfony pour la traduction

Cegid Y2 émet des fichiers métier dont les préfixes identifient la famille de flux : ARTICLE pour le catalogue, PRE pour les préparations, CF pour les commandes d’achat, RET pour les retours, TR3 et DTR pour les transferts. Le middleware télécharge ces fichiers depuis Azure Blob Storage, détecte leur structure, les parse puis construit les objets attendus par les API ShippingBo.

Dans l’autre sens, les commandes expédiées, réceptions fournisseur, retours et transferts sont lus depuis ShippingBo ou depuis le modèle intermédiaire. Le middleware reconstruit alors les lignes au format attendu par Cegid, génère les fichiers de retour et les dépose dans Azure. Azure n’est pas présenté comme le moteur métier : il fournit la zone d’échange entre les fichiers ERP et les traitements applicatifs.

Cette preuve Azure reste strictement bornée : Azure Blob Storage (zone d’ingestion) transporte les fichiers de ce projet. Pour cadrer un workflow où le cloud porte aussi identités, contrôle, événements et état terminal, notre page d’intégration Azure REST API détaille ces responsabilités. Elle ne revendique ni automatisation ARM globale, ni déploiement Entra ID pour Fauré Le Page.

Symfony 7 porte les règles que ni le stockage de fichiers ni l’API logistique ne doivent décider seuls. Il regroupe les lignes de fichier par commande, retrouve les produits ShippingBo à partir des EAN, contrôle les états des attendus, calcule les progressions, protège les accès du portail et conserve les relations entre fournisseurs, commandes, expéditions et identifiants externes.

PostgreSQL conserve l’état applicatif et le journal des intégrations. RabbitMQ, via Symfony Messenger, reçoit dix types de messages asynchrones : articles, préparations, commandes d’achat, confirmations, retours, transferts et rapport de stock. Les consommateurs sont séparés par files afin qu’un lot d’articles ne partage pas nécessairement le même rythme qu’un transfert ou une ASN fournisseur.

Docker fournit les environnements d’exécution. Les configurations sandbox et production possèdent leurs images PHP et Nginx. La chaîne GitLab construit puis publie ces images selon la branche. Cette organisation maintient une frontière lisible entre construction applicative, serveur web et environnement cible.

6. Treize familles de flux rendues visibles dans la supervision

Huit départs vers ShippingBo et cinq retours vers Cegid

L’écran de recherche des intégrations ne mélange pas tous les échanges sous un libellé générique. Il distingue huit familles Cegid vers ShippingBo : articles complets, articles incrémentaux, préparations PRE, achats fournisseur CF, retours fournisseur RET, transferts magasin TR3, transferts entrepôt DTR et stocks virtuels. Chacune peut porter sa propre cible, son mode d’entrée, son nombre de ressources et ses erreurs.

Cinq familles structurent le chemin inverse : commandes expédiées RBL, réceptions fournisseur RCP, retours fournisseur RET, transferts croisés TRF et transferts émis TR3. Le sens du flux n’est pas une convention implicite. Chaque exécution enregistre sa source, sa cible et ses modes, par exemple fichier vers API, base vers fichier ou fichier vers base.

Cette nomenclature protège l’exploitation. Une anomalie sur la réception RCP ne doit pas faire croire que le catalogue ARTICLE est arrêté. Un traitement vide n’a pas le même sens qu’un traitement en erreur ou qu’un lot encore en cours. Les statuts prévus — mise en file, collecte, distribution, traitement, terminaison, erreur, expiration ou absence de donnée — donnent une première grille de diagnostic.

Le projet contient aussi trois commandes de purge pour les intégrations vides, anciennes ou en dépassement de temps. Elles empêchent l’historique opérationnel de devenir une accumulation indifférenciée. Le journal conserve ce qui aide à comprendre ; les règles de purge organisent sa durée de vie.

Ces treize familles ne possèdent pas toutes le même niveau de profondeur fonctionnelle. Elles mesurent la surface exposée à la supervision. Les flux CF et RCP se distinguent parce que leur liaison au portail fournisseur forme la chaîne la plus complète, de la commande d’achat jusqu’à la réception.

7. Importer la commande d’achat sans la réduire à un fichier plat

Regrouper les lignes CF, rattacher le fournisseur et conserver le contexte Cegid

Le flux CF arrive sous forme de lignes. Le parser extrait notamment la référence interne de la pièce, sa référence externe, sa date, l’établissement, le dépôt, le tiers fournisseur, ses coordonnées, l’EAN produit, la quantité et le prix moyen pondéré. Le traitement regroupe ces lignes par référence interne afin de reconstruire une commande et sa collection d’articles.

Dans le portail, le fournisseur est retrouvé par son identifiant. Si la commande existe déjà, le traitement ne duplique pas aveuglément l’objet : il indexe les anciennes et nouvelles lignes par référence produit, actualise prix, quantité, libellé et couleur, ajoute les références nouvelles et retire celles qui n’appartiennent plus à la commande lorsque cela reste possible. Sinon, il crée la commande et toutes ses lignes.

Cette mise à jour différentielle compte pour les opérations. Une commande fournisseur peut évoluer avant expédition. En conservant le même objet, le portail garde sa référence, ses relations et son historique d’expéditions. En comparant les lignes par produit, il évite qu’une correction de libellé ou de quantité produise une seconde commande visuellement identique.

Les informations affichées ne s’arrêtent pas à la quantité. Le produit peut montrer désignation, code couleur, libellé couleur, prix unitaire, montant total, quantité commandée, quantité expédiée, quantité reçue, progression de livraison et progression de réception. Le fournisseur voit ainsi ce qui reste à préparer sans ouvrir Cegid ni reconstruire le calcul dans un tableur.

L’import peut lire Azure dans le fonctionnement normal ou un fichier local explicitement fourni pour un traitement contrôlé. Cette seconde possibilité facilite les vérifications sur un jeu isolé ; elle n’est pas présentée comme un chemin de production automatique.

8. Créer une ASN fournisseur ligne par ligne

Faire de l’expédition annoncée un objet vérifiable avant son envoi

Depuis une commande, le fournisseur crée une expédition. Le formulaire demande une date de livraison prévue et peut recevoir un commentaire logistique, un transporteur et un numéro de suivi. Pour chaque article, il rappelle la quantité commandée, la quantité déjà livrée et le restant, puis laisse saisir la quantité qui part dans cette expédition ainsi qu’un numéro de lot ou chrono.

Les lignes dont la quantité vaut zéro ne sont pas ajoutées. L’ASN représente donc ce qui part réellement, pas une copie systématique de toute la commande. Son identifiant combine la référence de commande et le rang de l’expédition. Une même commande peut produire une première, une deuxième ou une troisième annonce sans perdre leur relation avec l’origine.

Une fois créée, l’expédition reste en brouillon. Sa vue récapitule le fournisseur, la commande, les articles, quantités, lots, transporteur, suivi, date attendue et commentaires. Tant qu’elle n’est pas envoyée, elle peut être modifiée ou supprimée. Cette étape de relecture sépare la saisie de l’engagement externe.

Au moment de l’envoi, le statut passe à “sent” et un message asynchrone est déposé dans la file dédiée. L’écran n’attend pas que toute la conversation ShippingBo se déroule dans la requête web. Le traitement vérifie ensuite que l’expédition existe, qu’elle n’a pas déjà reçu d’identifiant externe, qu’elle se trouve dans l’état attendu et qu’elle contient au moins une ligne.

Après envoi, l’interface n’offre plus les actions de modification. Ce verrou ne remplace pas une politique universelle d’idempotence, mais il matérialise une règle utile : une ASN qui a commencé sa vie dans ShippingBo ne doit plus être silencieusement remodelée depuis le portail fournisseur.

9. Transformer l’ASN en attendu de réception ShippingBo

Construire la supply capsule sans perdre les références de rapprochement

Le gestionnaire asynchrone charge l’expédition et ses lignes. Pour chaque ligne, il prépare une entrée ShippingBo où la quantité vient de l’ASN, la référence produit et la référence source reprennent l’EAN, et le numéro de lot alimente les numéros attendus lorsqu’il est présent. Le fournisseur et la date attendue complètent l’objet.

La référence source de l’attendu n’est pas un identifiant technique aléatoire détaché du métier. Elle reprend l’identifiant de l’expédition. Ce choix facilite la lecture dans ShippingBo et surtout le rapprochement au retour. Une fois la création acceptée par l’API, le middleware conserve l’identifiant ShippingBo et sa date de création sur l’expédition locale.

Le projet possède également un autre chemin historique où une commande d’achat CF crée directement un attendu ShippingBo. Avant de remplacer un attendu existant, ce traitement relit ses lignes. Dès qu’une quantité reçue est supérieure à zéro, l’objet est considéré comme verrouillé et sa suppression est refusée. Cette règle évite de reconstruire un attendu qui a déjà commencé à produire des variations de stock.

Dans ce chemin direct, chaque EAN Cegid doit retrouver un produit ShippingBo. Une référence absente devient une erreur rattachée à l’intégration et à la commande concernée ; elle n’est pas simplement ignorée. Le fichier source ne peut être supprimé d’Azure qu’après la finalisation du lot et seulement si le mode de suppression est explicitement activé.

Ces deux chemins reflètent l’évolution du produit. Le premier automatise la création depuis le flux ERP. Le portail ajoute une décision fournisseur intermédiaire et une ASN plus fidèle à ce qui part réellement. La solution gagne ainsi une couche métier sans abandonner les connecteurs industriels déjà constitués.

10. Lire l’attendu de réception ShippingBo et rapprocher chaque ligne

Paginer, temporiser, filtrer puis retrouver l’expédition d’origine

Le traitement de réception interroge les supply capsules ShippingBo par pages de cinquante objets. Il avance l’offset jusqu’à ce qu’une page soit vide et ne retient que les attendus dont l’état vaut “received”. Cette pagination évite de supposer que tous les objets tiendront dans une seule réponse.

Une limite API HTTP 429 déclenche une temporisation progressive. Le traitement peut effectuer jusqu’à cinq tentatives pour la page concernée, en commençant par deux secondes puis en doublant le délai. Une autre erreur ShippingBo interrompt la collecte, rattache le message à l’intégration et place celle-ci dans l’état d’erreur. Ce mécanisme traite spécifiquement la limitation de débit sans masquer les autres anomalies.

Pour chaque attendu reçu, le middleware recherche l’expédition locale à partir de l’identifiant ShippingBo conservé lors de l’envoi. Si aucune expédition ne correspond, l’objet est signalé et ignoré. Si l’expédition a déjà été marquée reçue, elle est également ignorée. Ces deux gardes protègent le rapprochement et évitent de produire à nouveau le même retour.

Le rapprochement descend ensuite au niveau de la ligne. La référence source de l’article ShippingBo est comparée à l’EAN de la ligne d’expédition. Lorsqu’elles correspondent, la quantité reçue est enregistrée et la progression est recalculée. Une expédition à zéro pour cent reste en attente ; en dessous de cent pour cent, sa réception signale un écart ; à cent pour cent, son état peut être terminé.

La même information remonte vers la commande. Pour chaque article commandé, la quantité reçue est la somme des quantités reçues dans ses différentes expéditions. La progression de réception compare ce cumul aux quantités expédiées, tandis que la progression de livraison compare les quantités expédiées aux quantités commandées. Ces deux ratios répondent à deux questions distinctes : avons-nous expédié toute la commande, et avons-nous reçu tout ce qui a été expédié ?

11. Restituer à Cegid un fichier RCP suffisamment contextualisé

Transformer la réception ShippingBo en lignes que l’ERP peut reconnaître

Après rapprochement, le middleware génère un fichier de réception séparé par des points-virgules. Chaque ligne commence par le marqueur RCP, puis reprend la référence de commande fournisseur, une référence de réception dérivée de l’attendu ShippingBo, la référence externe de la commande, la date du jour et la date attendue lorsque ShippingBo la fournit.

La ligne conserve ensuite l’établissement et le dépôt Cegid, l’identifiant du fournisseur, l’EAN, la quantité effectivement reçue et le prix unitaire hors taxes. Ce contexte est essentiel : un nombre reçu sans commande, site, fournisseur ni produit serait impossible à réintégrer proprement dans l’ERP.

Le fichier est construit dans un espace propre à l’intégration, reçoit un nom horodaté avec le préfixe rcp, puis est envoyé vers Azure Blob Storage. L’expédition passe à l’état reçu. Son statut de réception distingue une correspondance attendue d’un écart de quantité entre l’expédition annoncée et l’objet logistique.

L’intégration enregistre le nombre d’attendus traités, sa date de fin et son temps d’exécution. La production du RCP n’est donc pas une écriture opaque dans un répertoire partagé : elle appartient à une exécution identifiée, consultable dans le même back-office que les autres familles de flux.

Ce retour ferme la boucle. Cegid a émis la commande d’achat ; le fournisseur a décrit l’expédition réelle ; ShippingBo a enregistré la réception ; le middleware restitue les lignes reçues au format ERP. Chaque système reste responsable de son étape, mais aucun ne perd le fil nécessaire au suivant.

12. Superviser une exécution sans ouvrir les conteneurs de production

Donner au run une vue sur le sens du flux, sa progression et ses erreurs

Chaque commande d’intégration crée un objet de suivi doté d’un identifiant public. Cet objet enregistre le service, son alias, le mode et la cible d’entrée, le mode et la cible de sortie, le statut, les dates de début et de fin, le nombre total de ressources, le compteur courant, la progression, les erreurs et la durée.

La liste du back-office peut être filtrée par texte, service, statut, année et mois. Elle montre immédiatement la direction de l’échange : Azure RFE vers ShippingBo, middleware vers Cegid ou une autre combinaison. Le nombre de ressources et la progression donnent un contexte qu’un simple voyant rouge ou vert ne fournirait pas.

La fiche d’une intégration détaille les fichiers sources, les erreurs et les journaux API. Pour ShippingBo, le journal distingue la requête, sa méthode, son URL, la réponse et son code HTTP. Les événements sont regroupés sous un identifiant métier, par exemple la référence de commande en cours de traitement. Cette corrélation rapproche l’incident technique de l’objet que l’équipe cherche réellement.

Les fichiers Azure disposent en parallèle de vues de consultation, téléchargement, suppression, journaux et rejets. La surface est volontairement orientée flux : quel objet a circulé, dans quel sens et avec quel résultat ? Les métriques système, traces distribuées et alertes d’infrastructure relèvent d’un autre niveau d’observabilité.

Le monitoring livré correspond donc à une historisation structurée et consultable des exécutions, enrichie par les requêtes et réponses ShippingBo lorsque les traitements utilisent le logger dédié. Les engagements de service et la reprise universelle demanderaient des mécanismes complémentaires.

13. Protéger les échanges aux endroits où un doublon ou un effacement ferait mal

Garder des règles locales plutôt que promettre une résilience abstraite

La première protection apparaît avant l’écriture ShippingBo. Une expédition déjà associée à un identifiant externe n’est pas renvoyée. Une expédition qui n’est pas dans l’état “sent” ne peut pas être publiée. Une ASN vide est refusée. Ces gardes ne couvrent pas toutes les pannes distribuées possibles, mais elles empêchent plusieurs répétitions évidentes depuis le portail.

Le deuxième contrôle concerne les attendus déjà commencés. Dans le flux direct CF, un attendu existant peut être remplacé tant qu’aucune ligne ne possède de quantité reçue. Dès que ShippingBo expose une quantité supérieure à zéro, la suppression est bloquée. La réception réelle prend ainsi le pas sur une nouvelle version du fichier source.

Le troisième concerne les fichiers. Après un lot entrant réussi, le blob d’origine peut être supprimé seulement lorsque le paramètre prévu à cet effet est actif. Une erreur de suppression est journalisée sans effacer le résultat du traitement. Les zones de sortie sont séparées par identifiant d’intégration afin que deux exécutions ne partagent pas le même chemin temporaire.

Le quatrième concerne les limites de l’API ShippingBo. La collecte des réceptions traite explicitement les réponses 429 avec temporisation exponentielle et nombre de tentatives borné. Les autres erreurs ne sont pas requalifiées en limitation de débit ; elles placent l’intégration en erreur avec leur message.

Enfin, Messenger sépare les traitements longs des requêtes de l’interface. Les messages utilisent des files dédiées par famille et des workers supervisés, relancés après une durée d’exécution bornée. Le projet configure également un transport de messages échoués. La reprise fonctionnelle doit cependant rester propre à chaque flux tant qu’aucune console universelle ne gère ses effets distants.

14. Des gains fonctionnels observables sans inventer un pourcentage de performance

Mesurer ce que le produit permet de faire, pas ce que personne n’a chronométré

Le premier gain est la continuité de parcours. Une commande importée depuis Cegid peut être consultée par le bon fournisseur, fractionnée en expéditions, envoyée dans ShippingBo puis enrichie des quantités reçues avant retour vers l’ERP. Les objets et interfaces nécessaires à chacune de ces étapes existent dans le même produit.

Le deuxième est la lisibilité des quantités. Commandé, expédié et reçu ne sont plus trois mots interchangeables. Le fournisseur voit le restant avant de créer son ASN ; l’équipe voit la progression de l’expédition et de la commande ; la ligne RCP utilise la quantité réellement remontée par ShippingBo.

Le troisième est la séparation des responsabilités. Le fournisseur travaille dans son espace sans accéder au pilotage technique. L’administration peut gérer fournisseurs, utilisateurs, commandes et expéditions. L’exploitation consulte les intégrations, fichiers, erreurs et journaux API. Cette séparation réduit la nécessité de détourner un outil conçu pour un autre rôle.

Le quatrième est la localisation des écarts. Une absence de produit lors de la création d’un attendu, une limitation API, une expédition introuvable, une ASN déjà envoyée ou une quantité différente dispose d’un point de contrôle identifiable. La solution ne promet pas que l’anomalie disparaît ; elle donne suffisamment de contexte pour savoir quelle étape examiner.

Le cinquième est l’extensibilité par famille de flux. Le même socle accueille articles, préparations, achats, transferts, retours, stocks et réceptions, mais chaque flux garde sa commande, son parser, ses messages et son libellé de supervision. Ajouter une règle à RCP n’oblige pas à la disperser dans le traitement ARTICLE.

Aucun taux de succès, baisse d’erreur, économie de temps, volume de lignes ou amélioration de stock n’est publié ici. Ces indicateurs exigeraient des mesures d’exploitation et une validation client. L’absence de ce chiffre ne retire rien aux capacités livrées ; elle évite seulement de transformer une architecture vérifiable en promesse marketing invérifiable.

15. Ce que couvre précisément le système livré

Des capacités bornées pour guider les décisions d’évolution

La fenêtre de 172 jours décrit une période de construction, pas un délai garanti pour un autre projet. Les treize flux correspondent aux familles proposées dans la supervision, pas à treize SLA indépendants. Les neuf routes du portail composent un seul parcours fournisseur cohérent.

La chaîne sandbox–production construit et publie des images Docker. Elle ne contient pas, à cette date, de contrôle automatisé exécutant les tests avant publication. Le renforcement naturel consiste donc à placer les tests existants et les futurs scénarios de flux sur le chemin obligatoire de livraison.

Les journaux d’intégration couvrent états, compteurs, erreurs, fichiers et appels API. Une étape supplémentaire peut enrichir ce socle avec alertes, métriques d’infrastructure et procédure de reprise assistée. Le transport Messenger des messages échoués fournit un point d’appui, mais l’interface de reprise métier reste à concevoir selon les risques de chaque flux.

Le portail protège l’accès d’un fournisseur aux commandes qui lui appartiennent et verrouille l’ASN après son envoi. La saisie du restant disponible dispose aussi d’un contrôle dans l’interface. Pour durcir le dispositif, la même borne doit être imposée côté serveur afin qu’une requête construite hors navigateur ne puisse pas dépasser la quantité disponible.

Ces limites n’annulent pas la chaîne livrée. Elles indiquent où investir ensuite : tests bloquants, validation serveur des quantités, alertes et reprise contrôlée. Le modèle actuel — commande, expédition, ligne, identifiant externe et journal d’intégration — offre déjà les points d’ancrage nécessaires à ces évolutions.

16. Prolonger la preuve selon le problème à résoudre

ERP, logistique, application métier ou architecture API

Si le point de départ est Cegid Y2 — fichiers d’échange, référentiels, commandes ou retours — la page intégrateur Cegid détaille la manière de cadrer les objets, les responsabilités et les scénarios d’erreur avant de connecter l’ERP.

Si la difficulté se situe dans les attendus, stocks, commandes ou objets logistiques, la page intégration API logistique et shipping cadre le corridor complet. La page intégration API ShippingBo prolonge ensuite le sujet sur les contrats API, l’idempotence, la pagination, les limitations de débit et le suivi des écritures distantes.

Lorsque le connecteur doit devenir un outil utilisé par des fournisseurs ou des équipes internes, l’enjeu dépasse l’API. La page développement d’application métier aborde les rôles, parcours, tableaux, validations et écrans de décision qui transforment un échange technique en opération exploitable.

Pour concevoir une couche de traduction dédiée, documenter les formats et exposer des points d’entrée stables, la page création d’API sur mesure présente le travail de contrat, sécurité, versionnement et supervision qui accompagne le développement.

Enfin, le projet 1UP Distribution : hub ShippingBo, Odoo et Wix montre une autre architecture logistique multi-systèmes, tandis que le cas CHL Logistics et son middleware transport déplace la même exigence vers l’étiquette, le colis et le choix du transporteur.