La vague de préparation réunit les colis de plusieurs clients, et le middleware utilise la même clé Colissimo pour tous. Le problème apparaît quand le regroupement suit cette clé : une demande de bordereau contient des numéros rattachés à deux comptes clients, alors que sa cible documentaire n’en désigne qu’un. Le JSON peut être parfaitement préparé par le client HTTP. Le mélange se trouve dans la sélection des colis et du compte, avant toute réponse du transporteur.
Le regroupement doit commencer par le compte Colissimo délégué et par l’inventaire des colis préparés. Dans le parcours décrit par la documentation française vérifiée le 17 octobre 2026, l’utilisateur avancé transmet sa clé dans le header apiKey et renseigne le compte client avec ACCOUNT_NUMBER dans les champs complémentaires. Ces deux informations ont des rôles différents. La forme de la requête ne démontre ni les droits de délégation ni l’appartenance réelle d’un numéro de colis.
Notre accompagnement pour relier Colissimo à vos commandes et à vos colis peut reprendre ce mapping avec la logistique et les responsables du SI. La démarche s’inscrit dans notre expertise en intégration API : comprendre le compte attendu, conserver l’identité des colis et recetter les demandes produites. L’exercice proposé travaille cette frontière sur six références fictives, sans demander de bordereau à Colissimo.
Pour qui : un logisticien avec plusieurs comptes clients
Une vague d’entrepôt ne définit pas un compte transport
Le cas concerne notamment un logisticien qui prépare pour plusieurs donneurs d’ordre, un éditeur qui mutualise les appels transport ou une équipe e-commerce avec plusieurs comptes Colissimo. L’organisation du travail peut réunir des colis au même poste sans que leur contexte transport soit identique. Le signal faible est une liste exportée par vague, dans laquelle le client ou le compte n’est plus disponible lorsque le document est demandé.
Une référence de commande, un alias client dans l’ERP et un numéro de compte Colissimo peuvent désigner des périmètres différents. Il faut les rapprocher explicitement. Deux alias internes peuvent utiliser le même compte transport ; deux clients traités par le même utilisateur avancé peuvent avoir des comptes distincts. Le critère de partition doit donc être écrit dans le mapping, avec sa source, au lieu d’être déduit du login utilisé par le worker.
Retrouver la cible quand le symptôme apparaît au document
Pour diagnostiquer un dossier, rapprochez les numéros prévus pour la vague, le compte associé à leur création, le profil de délégation et la demande effectivement préparée. Une capture du bordereau ou une liste de commandes ne donne pas forcément ces quatre informations. Le coût caché vient du temps passé à reconstruire cette correspondance quand l’export a déjà réduit chaque colis à un simple numéro, sans conserver sa provenance.
Le diagnostic reste circonscrit aux flux pour lesquels vous éditez un bordereau avec cette opération. Il ne rend pas ce document obligatoire pour tous les envois et ne décide pas quels colis doivent partir physiquement. Le même compte constitue une contrainte à vérifier dans ce parcours ; les autres conditions de votre organisation, du site de préparation et du contrat restent à qualifier avant d’ouvrir un regroupement réel.
Lire la délégation dans le contrat Colissimo actuel
Conserver séparément l’utilisateur avancé et le compte client
La documentation française Colissimo SLS décrit l’authentification par clé dans les headers. Pour le cas d’un utilisateur avancé disposant d’une délégation, elle demande aussi de renseigner le compte Colissimo concerné dans les champs complémentaires avec la clé ACCOUNT_NUMBER. Une clé commune à plusieurs traitements ne constitue donc pas une règle suffisante pour réunir leurs colis dans le même document.
Le profil de l’exemple contient une clé entièrement factice et deux comptes cibles fictifs. Les droits réels ne sont pas interrogés. Dans votre intégration, le mapping des clients vers les comptes autorisés doit être qualifié avec les responsables de la délégation. Le programme ne découvre pas les comptes accessibles à partir d’une clé, ne crée aucune délégation et ne transforme pas une valeur fournie par l’ERP en autorisation du transporteur.
Relier le champ de compte à la liste de numéros
La méthode generateBordereauByParcelsNumbers documente une liste de colis générés par le même compte. Le parcours REST retenu place la collection parcelsNumbers dans generateBordereauParcelNumberList, avec un bloc fields contenant une liste field. Chaque champ complémentaire porte une clé et une valeur ; notre contrôle attend une seule valeur textuelle pour ACCOUNT_NUMBER. Les comptes sont conservés comme des chaînes, ce qui évite de perdre un zéro initial en les traitant comme des nombres de calcul.
Gardez la version du parcours et les propriétés exactes à côté du mapping. Un ancien exemple d’authentification ou une structure issue d’une autre opération ne doit pas décider silencieusement de la demande actuelle. La référence documentaire et l’exécution locale remplissent deux fonctions : l’une qualifie le contexte choisi, l’autre montre les octets préparés. Aucune ne remplace une recette autorisée des délégations et des documents sur le compte concerné.
Reproduction : six colis, une clé factice, deux comptes cibles
Observer le mélange après préparation HTTP
Le premier scénario fictif contient trois références associées au compte 000001 et trois autres au compte 000002. Le code naïf utilise le premier compte cible et place les six références dans une même requête. Requests prépare effectivement cet objet HTTP. Le contrôle local relit ensuite son corps sérialisé et compare chaque numéro à un inventaire indépendant : les trois références du second compte ne correspondent pas à la cible déclarée.
Le résultat ci-dessous provient de l’exercice Python complet. Il décrit une incohérence de préparation constatée localement. Il ne représente pas un message renvoyé par Colissimo et ne prédit pas la manière dont le service traiterait une telle demande. Les identifiants préfixés DEMO, les comptes et la clé sont des données de démonstration ; aucun de ces colis n’a été créé ou annoncé au transporteur.
{
"decision": "mixed_account_request_review",
"targetAccount": "000001",
"wrongAccountParcels": [
"DEMO-B-1",
"DEMO-B-2",
"DEMO-B-3"
]
}Rejouer les variantes sans envoyer de requête
Le programme original utilise Requests 2.32.5 et prépare des objets PreparedRequest en mémoire. Son exécution passe 35 contrôles sur 16 variantes de planification, avec dix tentatives de préparation native : neuf objets sont créés et un header volontairement invalide est refusé comme attendu. Le fichier n’appelle pas l’envoi HTTP. Il ne crée ni PDF, ni bordereau, ni écriture ERP ; la clé factice n’est pas affichée dans les résultats.
python3 -m venv .venv-colissimo-compte
.venv-colissimo-compte/bin/python -m pip install requests==2.32.5
.venv-colissimo-compte/bin/python colissimo_delegated_bordereau.py
checksPassed: 35
planCases: 16
nativePreparationAttempts: 10
nativePreparedRequests: 9
expectedInvalidHeaderFailures: 1
networkConnectionAttempts: 0
colissimoApiCalls: 0
pdfFilesCreated: 0
erpWrites: 0La préparation native vérifie une partie de la mécanique HTTP ; les règles d’inventaire et de compte appartiennent au démonstrateur. Le contrôle ne valide pas l’ensemble du contrat OpenAPI, le format commercial d’un numéro réel ou les permissions associées à une clé. Pour les essais sur votre environnement, établissez d’abord quelles références et quels comptes sont autorisés. La liste de l’exercice sert à observer une erreur de regroupement, pas à fabriquer des envois utilisables.
| Cas fictif | Observation locale |
|---|---|
| Six colis regroupés sous une cible | Trois références appartiennent à l’autre compte. |
| Partition par compte cible | Deux requêtes, avec la même clé factice. |
| Deux alias internes, un même compte | Un groupe dans le périmètre fictif retenu. |
| Mapping vers le mauvais compte | Revue avant préparation des requêtes. |
| Une requête de compte omise | Couverture incomplète de la vague détectée. |
| Header volontairement invalide | Refus natif de Requests, sans connexion. |
Construire la partition avant de préparer les requêtes
Utiliser une source indépendante pour l’appartenance des colis
L’inventaire de référence indique quels colis appartiennent à quel compte cible. Il est distinct des lignes à regrouper et du profil de clé utilisé pour les appels. Cette séparation permet de détecter un mapping erroné au lieu de comparer une donnée à sa propre copie. Sur un flux réel, identifiez la trace qui relie le numéro à son contexte de génération, puis conservez cette relation jusqu’à la préparation du bordereau.
Dans l’exercice, un compte cible numérique ou absent, un client inconnu et une référence non prévue interrompent la planification locale. Le programme ne complète pas ces informations en prenant le premier profil disponible. Ce choix rend visible une information manquante. La validation de forme d’une chaîne de caractères ne prouverait pas, à elle seule, que le compte appartient au bon client ou que la délégation correspondante existe encore.
Traiter les alias sans modifier le périmètre transport
Le deuxième scénario fictif donne deux alias internes à des colis rattachés au même compte Colissimo. La partition locale produit alors un seul groupe dans la vague étudiée. Le critère reste le compte transport, et non le nombre d’alias présents dans l’ERP. Cette observation ne décide pas d’un regroupement entre différents sites ou de nouvelles conditions commerciales : ces dimensions n’appartiennent pas au modèle minimal exécuté ici.
Le middleware peut conserver une partition plus fine si votre exploitation l’exige. L’important est de rendre cette règle explicite et de ne pas fusionner des comptes distincts au motif que la clé est commune. Le mapping doit indiquer le client interne, le compte Colissimo visé et le profil de délégation utilisé. Vous pourrez alors reprendre un cas sans changer les autres comptes traités par le même utilisateur avancé.
Contrôler la vague après sérialisation
Comparer le contenu préparé avec les colis attendus
Le contrôle relit le payload produit par Requests, au lieu de se limiter au dictionnaire construit avant l’appel au client HTTP. Il vérifie la méthode, l’URL du parcours retenu, le champ cible et les numéros présents. Pour la vague fictive, le seuil de recette est une égalité exacte : les six références attendues doivent apparaître une fois chacune, dans une requête dont le compte correspond à l’inventaire de préparation.
Un doublon de numéro ne doit pas disparaître simplement parce qu’un traitement convertit la liste en ensemble. Le programme le signale avant de préparer la vague. Il refuse aussi un inventaire incomplet ou une appartenance inconnue. Ces décisions sont locales et conservatrices. Elles donnent une cause à traiter dans les données amont ; elles ne décrivent pas les codes d’erreur qu’un serveur Colissimo retournerait pour les mêmes valeurs.
Vérifier que tous les groupes restent présents
Une requête peut être cohérente pour son compte et ne couvrir qu’une partie de la préparation. L’exercice retire volontairement le second objet préparé, puis constate que la vague n’est plus complète. C’est un contrôle utile à la frontière entre planification et distribution des travaux : retrouver trois colis corrects ne dit pas où sont passés les trois autres. La comparaison porte sur les références attendues, pas seulement sur un nombre de requêtes.
Si votre orchestration place ensuite un travail par compte dans une queue, gardez le lien avec la vague d’origine et son inventaire. La recette doit retrouver les groupes prévus et les éventuels groupes encore à reprendre. Le programme ne teste pas ce broker ni l’exécution des appels. Il matérialise la propriété à conserver avant cette étape, afin qu’une reprise d’un compte ne masque pas les références d’un autre.
Plan d’action : reprendre le mapping sans perdre les colis
Rattacher les entrées au bon propriétaire métier
Dans un SI où l’ERP identifie le donneur d’ordre, l’OMS affecte les commandes et le WMS prépare les colis, le connecteur doit conserver les correspondances utiles au compte transport. En entrée, retrouvez la demande de préparation, les numéros et leur contexte de génération. En sortie, gardez le compte cible et le groupe effectivement préparé. La responsabilité du middleware consiste à transmettre cette provenance, avec une règle de partition comprise par la logistique.
Commencez sur une vague dont les références sont retrouvables. Comparez le profil attendu à la demande sérialisée et classez la divergence : alias interne inconnu, cible absente, appartenance contradictoire ou groupe perdu dans l’orchestration. Ne corrigez pas seulement le libellé affiché dans le back-office. Le dossier doit permettre de vérifier quelle valeur a été utilisée pour préparer la requête et quel colis justifie cette cible.
- En priorité, identifier le compte cible et la preuve d’appartenance de chaque numéro de colis de la vague.
- Vérifier ensuite le mapping de délégation et la présence du champ attendu dans les requêtes préparées.
- Corriger la partition, puis comparer toutes les références sérialisées à l’inventaire avant distribution des travaux.
- Différer les cas sans compte ou sans appartenance qualifiée, avec un motif visible pour la préparation.
Donner au run une lecture par compte et par vague
L’observabilité doit distinguer une impossibilité de préparer la requête, une erreur d’authentification observée sur le service et un dossier documentaire à reprendre. Le monitoring peut rapprocher les groupes planifiés de ceux réellement pris en charge par votre orchestration. Ces observations ont des sources différentes. Dans les journaux utiles au support, une référence de profil et une cible de compte expliquent la sélection sans afficher la clé elle-même.
Un timeout après un appel réel demanderait une analyse des traces disponibles et du résultat éventuellement produit. Le runbook doit indiquer où retrouver la traçabilité du compte, les numéros concernés et les références documentaires connues avant de décider d’un retry. L’exercice reste entièrement antérieur à cet appel. Il ne prouve pas la sûreté d’un rejeu distant et ne reconstruit pas un bordereau à partir d’une réponse supposée ou d’un simple statut de worker.
Erreurs fréquentes dans un entrepôt multiclient
Confondre une clé commune avec un compte commun
Le premier exemple met précisément cette confusion à l’épreuve. Le même profil utilisateur peut intervenir pour les deux clients du jeu fictif, mais une requête ne doit pas réunir les deux comptes cibles. La clé renseigne le mode d’accès utilisé ; elle ne contient pas la liste des colis attendus pour chaque document. Cette liste doit garder sa propre source et sa propre correspondance avec le contexte du compte.
Contre-intuitivement, augmenter le nombre de clés n’est donc pas la correction démontrée. Le scénario corrigé prépare deux demandes avec la même clé factice et des champs de compte distincts. Les droits réels restent à qualifier à l’extérieur du programme. La décision de changer l’organisation des accès appartient à votre configuration et à vos responsables ; le défaut reproduit concerne ici le regroupement des références sous une cible documentaire.
Masquer une cible absente en complétant le JSON au hasard
Une valeur de compte prise dans la première ligne peut produire un JSON lisible tout en affectant les autres colis au mauvais périmètre. Notre contrôle refuse cette contradiction avec l’inventaire. Il met également en revue un champ cible absent ou ambigu. Le nom exact ACCOUNT_NUMBER sert de repère à ce profil local ; l’exemple ne prétend pas mesurer comment le serveur interpréterait toute variante de casse ou plusieurs valeurs concurrentes.
Une autre erreur consiste à transformer les comptes en entiers pendant un export. La fixture montre que la chaîne 000001 reste intacte dans la requête préparée ; une cible numérique est orientée vers une revue. Ce contrôle de type n’authentifie pas le compte et ne valide pas tous ses formats possibles. Il conserve simplement la donnée configurée, afin que la correction ne crée pas une divergence supplémentaire entre les logiciels.
Lectures complémentaires pour vos flux multicomptes
Préserver le contexte lorsqu’un worker sert plusieurs sociétés
Le diagnostic des sessions SAP Business One et de leur société cible examine une autre frontière de contexte dans un worker partagé. Il ne fournit pas une procédure d’authentification Colissimo. Son intérêt est de faire vérifier où le contexte est choisi et où il peut être perdu, avant qu’un logiciel aval ne reçoive une opération attribuée au mauvais périmètre.
Pour votre orchestration, documentez séparément la société ERP, le client métier, le profil d’accès et le compte transport. Un seul identifiant interne ne représente pas forcément ces quatre dimensions. Le rapprochement doit rester lisible dans le dossier de recette, avec les correspondances validées. Les cookies et paramètres de SAP Business One ne se transposent pas au header de clé et aux champs du parcours Colissimo étudié.
Conserver les références physiques avant de demander un document
L’analyse de la hiérarchie DESADV entre cartons et palettes aide à qualifier l’inventaire transmis à la logistique. Elle porte sur des identités d’emballage et une structure EDI, alors que la demande Colissimo utilise ses numéros de colis. Ces références doivent être rapprochées dans votre SI ; leur présence dans deux fichiers ne prouve pas automatiquement qu’elles désignent le même objet physique.
Faites conserver le lien entre la référence de préparation, l’emballage concerné et le numéro rattaché au compte transport. Vous pourrez alors examiner une vague incomplète sans réattribuer les colis d’un client à un autre pour faire correspondre les totaux. Le bon total ne remplace pas l’identité de chaque référence. La recette de partition et celle de l’inventaire se complètent sur cette relation précise.
Conclusion : conserver le compte de chaque colis jusqu’à la demande
Le mélange est visible avant l’appel réseau : six références sont préparées sous une seule cible, alors que l’inventaire fictif distingue deux comptes. Le client HTTP sait construire cette requête ; le contrôle de compte révèle les trois références mal rattachées. La partition corrigée prépare ensuite deux groupes avec la même clé de démonstration, sans produire de document chez le transporteur.
Pour le flux réel, qualifiez le compte délégué, les droits correspondants et la source qui rattache chaque numéro à son contexte. Gardez ensuite la couverture de la vague lorsque les groupes traversent votre orchestration. Les contrôles locaux réduisent une ambiguïté de préparation ; ils ne déclarent pas un colis remis, un document généré ou une délégation encore valide sur la seule base d’un JSON cohérent.
Notre accompagnement pour connecter Colissimo à votre préparation et à vos comptes clients peut reprendre ce dossier avec vos équipes métier et techniques. Le point de départ est une vague explicable : pour chaque référence, retrouver le compte choisi, la preuve utilisée et le groupe documentaire auquel elle a été affectée.
Pour organiser la correction entre vos logiciels, faites cadrer le flux d’intégration API et ses contrôles de restitution avec Dawap. La recette pourra suivre les colis attendus depuis l’inventaire jusqu’aux demandes préparées, puis qualifier le parcours autorisé sur le service sans effacer les correspondances déjà établies pour les autres comptes.
