Le vrai enjeu d'une intégration API Cdiscount FBC n'est pas d'envoyer un ordre logistique de plus. La douleur apparaît quand un stock existe chez Octopia, qu'une commande doit partir, qu'un retour revient, puis que l'ERP, le WMS et le support ne savent plus si la quantité est réellement expédiable. Le problème devient alors une charge support, une reprise manuelle et une perte de confiance dans la disponibilité.
Cdiscount FBC doit être lu avec son contexte actuel: les flux de fulfillment sont documentés côté Octopia Fulfillment, avec des briques distinctes pour référencer les produits, créer des inbound shipments, lire les stocks, créer des outbound shipments et gérer les retours.
Le signal faible se voit quand une référence vendeur n'est pas alignée avec le canal de vente, quand une quantité
Available est confondue avec une quantité bloquée, ou quand un statut d'entrepôt ne remonte pas au support.
Le flux existe, mais la décision devient impossible à défendre.
Contrairement à ce que l'on croit, la difficulté ne vient pas seulement du transport ou du tracking. Le vrai sujet consiste à transformer le fulfillment en source de vérité exploitable: référencer, approvisionner, vendre, expédier, annuler, retourner, rapprocher et expliquer. Vous allez comprendre quoi vérifier, quoi bloquer, quoi rejouer et comment éviter qu'un stock physique devienne une dette opérationnelle.
Dawap traite ce périmètre comme une intégration API reliée aux flux logistique et shipping. Notre accompagnement intégrateur Cdiscount FBC aide à relier Octopia Fulfillment, ERP, WMS, OMS, canaux de vente et support avec une preuve de run lisible.
Pour qui Cdiscount FBC devient critique
Cdiscount FBC devient critique pour les vendeurs marketplace, marques D2C, distributeurs et opérateurs qui confient du stock à Octopia Fulfillment pour servir Cdiscount ou d'autres canaux. Le sujet dépasse le confort logistique dès que plusieurs outils doivent piloter la même disponibilité.
La priorité augmente lorsque le stock entrepôt doit alimenter un ERP, un OMS, Shopify, Prestashop, Magento ou une marketplace tierce. Si le stock fulfillment devient une promesse commerciale, chaque état bloqué, litigieux ou en retour doit être compris avant d'ouvrir la vente.
Le bon signal est simple: si une erreur de référence, de productCondition, de stock, d'outbound ou de retour
peut changer le délai client, la marge, le SAV ou la finance, alors le connecteur doit être conçu comme un outil de run,
pas comme une synchronisation de confort.
1. Relier Cdiscount FBC et Octopia Fulfillment
Nommer le périmètre avant de développer
Le premier piège consiste à parler d'API Cdiscount FBC comme si tout passait par un seul flux. Octopia Fulfillment sépare le référencement produit, les inbound shipments, les stocks, les outbound shipments et les retours. Cette séparation doit apparaître dans l'architecture.
Un flux inbound ne se corrige pas comme un stock Blocked, et un outbound shipment ne se pilote pas comme un
retour client. Le connecteur doit donc relier chaque famille à un owner, une source de vérité, un journal et une consigne
support.
Cette clarté évite les dérives de projet. Une équipe peut très bien réussir l'appel API et échouer le run parce qu'elle ne sait pas si l'incident concerne le référencement, la réception entrepôt, la disponibilité, l'expédition ou le retour.
La cartographie doit être validée avec les opérations, pas seulement avec l'équipe technique. Un flux peut être correct dans Postman et inutilisable en production si personne ne sait quelle action prendre quand un statut logistique ne correspond pas à la promesse affichée au client.
Distinguer sellers Octopia et héritage Cdiscount
La documentation Fulfillment précise que certains flux REST s'adressent aux vendeurs Octopia Fulfillment et pas à tous les contextes historiques Cdiscount. Ce point doit être vérifié avant de promettre un périmètre fonctionnel.
Le connecteur doit donc démarrer par l'éligibilité du compte: type de seller, pays activés, mode de stockage, droits API, accès aux entrepôts et contraintes de service. Sans cette vérification, l'erreur arrivera tard, au moment où les produits ou commandes devront réellement partir.
Cette étape protège la relation métier. Le support peut expliquer pourquoi un seller doit passer par le portail, pourquoi un pays exige une activation, ou pourquoi un flux REST n'est pas disponible pour un cas hérité.
Cette vérification doit être faite avant les ateliers de mapping détaillé. Si le compte n'a pas accès au bon flux, toute discussion sur les champs, les retries ou le monitoring devient théorique et crée une promesse que le run ne pourra pas tenir.
Relier fulfillment et canaux de vente
Octopia Fulfillment peut servir des commandes Cdiscount, mais aussi des scénarios de type 3PL selon le contexte. Le SI doit donc garder le canal de vente, le pays de livraison, le stock source et la règle de promesse dans la trace de décision.
Si le connecteur expose seulement "FBC expédie", il masque les responsabilités. Une commande Cdiscount, une commande externe et un ordre de retour n'ont pas les mêmes impacts sur SLA, finance, tracking et service client.
La bonne lecture consiste à garder une chronologie complète: produit référencé, stock reçu, quantité disponible, ordre outbound créé, statut logistique, tracking, retour éventuel et rapprochement. C'est cette chronologie qui rend le run défendable.
2. Référencer produits, GTIN et conditions
Ne pas créer d'inbound sans référencement
Le référencement logistique est une étape structurante. La documentation Octopia indique qu'un produit doit être déclaré avant certains flux inbound, avec des informations comme GTIN, condition produit, référence vendeur, dimensions emballées et données utiles à la logistique.
Si cette étape est négligée, l'inbound shipment peut être refusé, même si le produit existe commercialement. Le catalogue vente et le référencement fulfillment ne sont pas la même preuve, et le connecteur doit l'expliquer clairement.
Le SI doit donc séparer la fiche produit, la référence logistique et la promesse de stock. Un produit publiable sur un canal peut ne pas être prêt à entrer en entrepôt fulfillment si ses données emballées ou douanières sont incomplètes.
Le connecteur doit aussi conserver les refus de référencement. Une erreur sur le GTIN, la condition, la mesure ou une donnée réglementaire doit être visible dans l'ERP avec une action, au lieu de rester dans un journal technique que seul le projet sait relire.
Stabiliser sellerProductReference
La clé sellerProductReference sert à relier le produit du vendeur au stock fulfillment. La documentation insiste sur
son unicité, notamment par couple GTIN et productCondition. Cette clé ne doit pas être inventée au moment de
l'inbound.
Elle doit être alignée avec les canaux de vente pour réussir la synchronisation stock. Si la référence change entre ERP, marketplace et Octopia, une quantité peut être correcte en entrepôt et inutilisable dans le système marchand.
Cette règle devient critique sur les produits reconditionnés, les états d'usage, les lots et les variations. Le même GTIN peut porter plusieurs conditions, donc plusieurs références logistiques à ne jamais fusionner dans une disponibilité unique.
Une table de correspondance doit garder l'historique des références. Si une référence vendeur change dans l'ERP, l'équipe doit savoir quelle référence Octopia reste liée aux stocks déjà reçus, sinon la synchronisation mélange passé logistique et catalogue actuel.
Traiter mesures et contraintes comme des données de run
Les dimensions et informations du produit emballé ne sont pas des champs administratifs. Elles conditionnent la réception, le stockage, la préparation, les coûts logistiques et parfois l'éligibilité à certains pays ou flux.
Le connecteur doit conserver la version de ces données et tracer les enrichissements. Si l'entrepôt remesure le produit ou si une donnée manquante bloque une réception, l'équipe doit comprendre quelle valeur était connue au moment de l'envoi.
Cette discipline évite une erreur fréquente: croire que le référencement est terminé parce que l'API accepte le produit, alors que le run dépend encore d'informations opérationnelles, douanières ou qualité qui peuvent bloquer la suite.
3. Piloter inbound shipments et delivery notes
Créer l'inbound comme un engagement physique
Un inbound shipment n'est pas une simple intention. Il informe l'entrepôt que des produits arrivent, avec quantités, références, conditions et pays de stockage. Si la demande est acceptée, une delivery note peut être nécessaire pour la livraison physique.
Le connecteur doit relier cet inbound à l'ERP, au transport amont, à la référence produit et au stock attendu. Sans cette relation, la réception entrepôt devient une boîte noire entre approvisionnement, finance et disponibilité commerciale.
Le statut inbound doit être visible avant de vendre. Une marchandise annoncée n'est pas une marchandise disponible; elle devient utile seulement quand le stock est reçu et traité par l'entrepôt fulfillment.
La delivery note doit être traitée comme une pièce de preuve. Elle relie le flux numérique et la livraison physique; sans elle, l'équipe ne peut pas rapprocher correctement ce qui a été annoncé, ce qui a été envoyé et ce qui a été reçu.
Respecter pays, entrepôts et activations
Octopia documente des contraintes par pays et entrepôt, avec des activations possibles selon le contexte. Certains scénarios Cdiscount.com peuvent également nécessiter un passage par le Seller Portal plutôt qu'une création inbound API directe vers un entrepôt français.
Le connecteur doit donc vérifier storageCountry, droits vendeur, pays activés et règles de supply mode avant
de laisser l'ERP déclencher un flux. Le refus doit être métier, pas découvert dans un message technique tardif.
Cette vérification protège les opérations. Une équipe approvisionnement qui prépare une livraison vers le mauvais pays ou un pays non activé crée un coût physique, pas seulement une erreur dans une queue applicative.
Le middleware doit donc refuser tôt les combinaisons interdites. Un message métier clair évite qu'un opérateur prépare un transport amont, imprime une note ou réserve de la capacité entrepôt pour une destination qui ne sera pas acceptée.
Rapprocher réception et disponibilité
Le stock ne devient visible qu'après réception et traitement par l'entrepôt. Le connecteur doit donc rapprocher inbound, delivery note, réception, anomalies de qualité et quantités disponibles, sans transformer le stock attendu en stock vendable.
Cette nuance évite les surventes. Une commande peut être commercialement tentante dès que le camion est parti, mais le SI ne doit ouvrir la vente qu'après avoir une preuve de disponibilité suffisante et une règle de sécurité par canal.
Le tableau de bord doit afficher les écarts entre envoyé, reçu, disponible, bloqué et litigieux. C'est souvent là que les premières semaines révèlent les problèmes de mesure, de condition produit ou de référencement.
4. Lire les stocks Octopia sans se tromper
Distinguer Available, Allocated et Blocked
La Stock Management API expose des quantités de fulfillment en entrepôt Octopia. Available représente ce qui
est prêt à expédier, Allocated ce qui est réservé pour des commandes, et Blocked ce qui est
bloqué, par exemple pour qualité ou douane.
Ces états ne doivent pas être additionnés. Une quantité allouée rassure sur la présence physique, mais elle n'est pas disponible pour une nouvelle vente. Une quantité bloquée peut demander une action manuelle et ne doit pas alimenter le stock commercial.
La disponibilité publiée au canal doit donc être une décision, pas une copie brute. Elle doit tenir compte du pays, de la fraîcheur, des allocations, des blocages, des litiges et des règles de sécurité propres à la marge ou à la campagne.
Rendre Litigation, Return et LogisticOperations visibles
Litigation, Return et LogisticOperations sont des signaux opérationnels importants.
Ils indiquent des quantités qui existent, mais qui ne se traduisent pas forcément en stock vendable ou en promesse client.
Une intégration trop simple masque ces états dans un total générique. Le support découvre alors trop tard que le produit est en litige, en retour ou temporairement indisponible pour une opération interne.
La bonne lecture consiste à exposer ces quantités comme des alertes. Le produit, l'approvisionnement et le SAV peuvent décider si le stock doit être surveillé, exclu, rapproché ou traité manuellement avant d'être réouvert à la vente.
Ces états doivent aussi alimenter les prévisions. Un stock en retour ou en litige peut rassurer un acheteur interne, mais il ne doit pas déclencher une campagne commerciale tant que la qualité, la disponibilité et l'action attendue ne sont pas confirmées.
Respecter les filtres et la pagination
La documentation de stock indique des règles de filtres, notamment autour de deliveryCountry,
storageCountry, updatedAtMin, updatedAtMax, sort et
order. Ces contraintes doivent être intégrées au design.
Si le connecteur combine des filtres incompatibles ou ignore la pagination cursor, il peut produire une disponibilité partielle. Le problème paraît technique, mais il devient commercial quand une référence est vendue sur un stock incomplet.
Le run doit donc journaliser la requête, les filtres, le curseur, la date de lecture et la couverture. Un dashboard qui affiche une quantité sans dire comment elle a été obtenue ne suffit pas pour arbitrer une rupture.
La pagination doit être testée avec des volumes réalistes. Une première page correcte peut masquer des références absentes si le cursor n'est pas rejoué jusqu'au bout, et cette absence se transforme rapidement en erreur de stock sur les canaux à forte rotation.
5. Créer outbound shipments et suivre le run
Créer un outbound seulement sur stock prouvé
L'Outbound Shipments API permet d'instruire Octopia Fulfillment pour expédier des produits stockés vers des clients finaux. Avant cette création, le produit doit être correctement référencé et le stock doit être réellement disponible.
Le connecteur doit donc vérifier référence, condition, disponibilité, pays de livraison, mode d'expédition, adresse et canal de vente avant d'envoyer l'ordre. Une erreur peut être rejetée de manière asynchrone si le produit est inconnu ou mal identifié.
Cette étape doit rester idempotente. Un timeout après création ne doit pas déclencher un nouvel outbound aveuglément; il doit provoquer une rellecture, une mise en attente ou une reprise contrôlée.
Le connecteur doit garder une clé métier par outbound, avec le canal, la commande, l'adresse, les lignes et la tentative. Cette trace permet de relire Octopia avant tout retry et de prouver qu'une expédition n'a pas été demandée deux fois.
Suivre tracking, statut et annulation
L'Outbound Shipments API couvre aussi le suivi des statuts de colis et la gestion des annulations. Le support doit voir l'état normalisé, mais l'équipe technique doit conserver le statut brut, le payload, l'horodatage et la clé de corrélation.
Un outbound peut être créé, accepté, préparé, expédié, annulé ou rejeté selon le cas. Le connecteur doit traduire ces états en décisions: informer le client, attendre, relire, bloquer, escalader ou rapprocher une anomalie.
Cette gouvernance évite les messages contradictoires. Le compte client, le SAV et l'ERP ne doivent pas annoncer trois vérités différentes quand l'entrepôt traite un colis ou quand une annulation arrive trop tard.
Le tracking doit être rattaché à la ligne réellement expédiée. Si une commande externe contient plusieurs produits ou plusieurs colis, l'OMS doit afficher la progression par colis, sinon le support risque d'annoncer une livraison complète alors qu'une partie du panier reste en traitement.
Relier commandes externes et commandes marketplace
Octopia Fulfillment peut servir des commandes externes selon les cas. Le connecteur doit alors distinguer la commande Cdiscount, la commande issue d'un autre canal et l'ordre logistique transmis à l'entrepôt.
Cette séparation protège la finance et le SAV. Une vente Shopify expédiée par Octopia n'a pas le même circuit de relation client qu'une commande Cdiscount, même si la préparation physique se déroule dans le même réseau.
La preuve de run doit donc conserver canal, référence de commande, adresse, ligne produit, outbound shipment, tracking et retour éventuel. Sans cela, le fulfillment devient une boîte noire partagée entre plusieurs équipes.
6. Erreurs fréquentes, retours et restrictions
Oublier les restrictions de disponibilité API
Une erreur fréquente consiste à supposer que tout flux FBC a une sandbox et les mêmes possibilités de test. La documentation stock indique qu'aucune sandbox commune n'est disponible pour certains traitements, à cause de la nature physique et multi-entrepôts du fulfillment.
Cette contrainte doit changer la recette. L'équipe doit préparer des jeux de données contrôlés, des sellers éligibles, des tests non destructifs et une stratégie de lecture avant de lancer des opérations physiques coûteuses.
Le runbook doit aussi dire ce qui n'est pas testable de bout en bout sans stock réel. Cette franchise évite de confondre validation technique et qualification opérationnelle.
Les tests doivent donc être découpés: validation de payload, validation de mapping, validation de lecture stock, validation de reprise et validation physique sur un petit périmètre. Chaque palier doit avoir un owner, une preuve et un critère de passage.
Confondre retour, litige et stock revendable
Les retours et litiges ne doivent pas être traités comme une simple augmentation de stock. Une quantité Return
ou Litigation peut nécessiter une action manuelle, un contrôle qualité, une décision SAV ou un rapprochement
financier.
Le connecteur doit donc séparer retour demandé, retour reçu, stock revendable, stock non revendable et action de remboursement. Si ces étapes sont fusionnées, l'entreprise risque de revendre trop tôt ou de rembourser sans preuve.
Cette séparation évite les litiges longs. Le support peut expliquer ce qui est revenu, ce qui est bloqué, ce qui peut être remis en vente et ce qui reste en attente de décision entre logistique et finance.
Rejouer sans relire l'état Octopia
Un timeout ou une erreur réseau ne dit pas forcément que l'opération a échoué. Rejouer un inbound, un outbound ou une annulation sans relire peut créer une incohérence entre l'ERP et l'entrepôt.
La reprise doit d'abord vérifier la clé métier, la référence vendeur, le statut Octopia, le dernier payload et la dernière tentative. Ensuite seulement, le connecteur peut décider de rejouer, bloquer, corriger ou escalader.
Cette méthode coûte moins cher qu'une correction improvisée. Une expédition dupliquée, un stock rouvert trop tôt ou un retour rapproché deux fois pèsent directement sur la marge, le support et la confiance dans le SI.
Le runbook doit lister les actions interdites. Sans cette liste, un opérateur peut corriger localement un cas urgent et créer une incohérence plus coûteuse que l'incident initial entre Octopia, l'ERP et le canal de vente.
7. Scénario terrain: stock présent, vente bloquée
La quantité existe, mais elle n'est pas vendable
Imaginons un vendeur qui synchronise les stocks Octopia vers son ERP. Une référence apparaît avec des unités en entrepôt,
mais la quantité Available reste à zéro pendant que Litigation ou Blocked porte une
partie du volume.
Au départ, le dashboard semble rassurant parce que le produit existe physiquement. Le signal faible devient visible quand le support reçoit des questions sur des commandes bloquées alors que l'approvisionnement pense avoir livré le stock.
Le problème ne vient pas forcément de l'API. Il vient d'une traduction trop pauvre des états de stock, qui mélange présence physique, disponibilité commerciale et action manuelle attendue.
La correction consiste à qualifier la disponibilité
La première correction consiste à publier seulement une disponibilité calculée, pas un total générique. Available
peut alimenter la vente, tandis que Blocked, Litigation et Return doivent alimenter
des alertes séparées.
La deuxième correction consiste à relier l'inbound d'origine. Si les unités sont en litige parce qu'une réception a échoué ou qu'une mesure ne correspond pas, l'équipe doit savoir quelle livraison, quelle delivery note et quelle référence produit sont concernées.
La troisième correction consiste à donner au support une action. Il ne suffit pas de voir "stock non disponible"; il faut savoir si le cas est à attendre, à corriger, à escalader vers Octopia ou à bloquer côté vente.
Le résultat attendu se mesure au SAV
Après correction, le support n'ouvre plus une enquête pour chaque stock bloqué. Il lit la raison, la source, la date de mise à jour, l'action attendue et le owner. Le temps utile revient aux cas vraiment atypiques.
Les équipes commerciales gagnent aussi une promesse plus sûre. Elles savent quelle quantité peut être vendue, quelle quantité doit rester en surveillance et quel canal doit être ralenti pendant une anomalie de réception.
Ce scénario résume l'enjeu Cdiscount FBC: le fulfillment accélère la vente seulement si le stock Octopia est traduit en décision métier. Sinon, l'entreprise possède du stock sans savoir quand elle peut vraiment le promettre.
8. Plan d'action avant go-live Cdiscount FBC
Cadrer les objets et les owners
La première étape consiste à lister les objets du flux: GTIN, productCondition, sellerProductReference,
inbound shipment, delivery note, stock, outbound shipment, tracking, retour, litige, canal et écriture ERP.
La deuxième étape consiste à désigner la source de vérité. Octopia peut faire foi pour le stock fulfillment, l'ERP pour le produit interne, l'OMS pour la promesse client et la finance pour le remboursement. Ces frontières doivent être écrites.
La troisième étape consiste à vérifier les sellers, pays, entrepôts, modes de supply et droits disponibles. Si un pays ou un flux exige une activation, le connecteur doit le refuser proprement avant qu'un opérateur prépare une opération physique.
Installer les garde-fous techniques
Les garde-fous couvrent idempotence, queue, backoff, logs corrélés, gestion des filtres, pagination cursor, séparation des traitements inbound, stock, outbound et retours, ainsi qu'une politique claire de données sensibles.
Le connecteur doit aussi prévoir une file de quarantaine. Les objets incertains y restent avec leur payload, leur statut Octopia, leur décision métier attendue et leur owner, au lieu d'être rejoués automatiquement dans un batch risqué.
Les dashboards doivent afficher disponibilité calculée, stock bloqué, stock litigieux, retours, outbounds en attente, délais de réception, erreurs d'éligibilité, filtres utilisés et âge de chaque lecture stock.
Le lot technique doit définir les entrées, les sorties, les responsabilités, la journalisation, l'idempotence, la queue, les retries, le monitoring et le rollback par famille de flux. Ces éléments évitent de découvrir les dépendances au moment d'un incident réel.
Préparer la bascule et le mode contrôlé
Le lancement doit commencer sur un périmètre limité: quelques références, un pays, un canal, un type de condition produit ou une famille outbound. Cette limitation permet de tester la chaîne physique sans exposer toute la vente.
Le mode contrôlé doit être prêt avant le lancement. Il doit permettre de bloquer une référence, fermer un canal, suspendre des outbounds, continuer la lecture stock ou isoler les retours sans arrêter tout Cdiscount FBC.
Le runbook doit préciser le repli pour chaque famille: inbound à différer, stock à figer, outbound à suspendre, retour à isoler, ou canal à fermer temporairement. Cette granularité permet de corriger sans couper tout le fulfillment.
- D'abord, à valider: produit référencé, GTIN stable, condition correcte, inbound accepté, delivery note générée, stock Available visible et outbound corrélé.
- Ensuite, à bloquer: vente sur stock Blocked, inbound sans pays activé, outbound sans idempotence et retour rapproché sans preuve de réception.
- Puis, à corriger: sellerProductReference ambiguë, filtre deliveryCountry incompatible, cursor ignoré, statut stock trop ancien ou action support absente.
- Enfin, à différer: pays, entrepôts ou canaux dont la recette ne sait pas encore prouver les stocks, retours, litiges et annulations.
Un bon go-live Cdiscount FBC ne cherche pas à automatiser tout Octopia Fulfillment d'un coup. Il cherche à prouver que référencement, inbound, stock, outbound et retour restent lisibles quand les premiers cas réels sortent du flux nominal.
9. Recette, seuils et observabilité FBC
Tester les scénarios qui coûtent vraiment
La recette doit couvrir produit non référencé, condition différente, inbound refusé, delivery note manquante, stock
Available nul, stock Blocked, stock Litigation, outbound rejeté, tracking absent,
annulation tardive et retour non rapproché.
Chaque scénario doit préciser l'état attendu dans l'ERP, le WMS, l'OMS, le canal de vente et le support. Le test est réussi quand ces systèmes racontent la même décision, même si les détails viennent d'Octopia.
Cette recette doit tenir compte de l'absence de sandbox commune pour certains flux. Les tests doivent donc être planifiés avec des données contrôlées, des seuils de volume bas et une validation manuelle des opérations physiques sensibles.
Les preuves attendues doivent être conservées pendant la recette: payload d'entrée, réponse Octopia, statut normalisé, statut brut, décision métier, owner et capture du back-office. Sans ce dossier, l'équipe ne pourra pas comparer un incident réel avec le comportement validé.
Fixer des seuils actionnables
Les seuils doivent décider le mode de run. Par exemple, si pendant 2 jours une référence stratégique reste avec du stock
en Litigation sans owner identifié, alors la vente est à bloquer, car la marge et la charge support sont déjà
exposées.
Cas concret: si un délai de rapprochement retour dépasse 1 jour sur un canal prioritaire, alors les nouveaux outbounds sont à différer, car le SAV et la finance n'ont pas encore la preuve nécessaire pour absorber plus de volume.
Les seuils doivent différencier incident isolé et dérive. Un outbound rejeté peut se corriger; une famille complète de références avec filtres incohérents signale une rupture plus profonde du mapping ou de la recette.
Rendre la passation support autonome
Une intégration Cdiscount FBC devient durable quand le support peut comprendre un cas sans demander au développement. Il doit voir la donnée Octopia, la donnée normalisée, le système qui fait foi, l'action autorisée et l'interdit à respecter.
La fiche support doit couvrir les cas simples: produit non référencé, stock Available nul, stock Blocked, litige, retour, outbound en attente, tracking absent, pays non activé et filtre incompatible. Chaque cas doit avoir une consigne.
La passation doit aussi indiquer ce qu'il ne faut pas faire: vendre sur stock bloqué, rejouer un outbound sans relire, fusionner deux productCondition, ou rouvrir un retour en stock vendable sans preuve de qualité.
Les 30 premiers jours doivent être relus avec les opérations. Si les mêmes questions reviennent sur Available, Blocked, Litigation, delivery note ou retour, il faut enrichir la preuve visible avant d'ajouter des pays, des canaux ou des règles outbound plus ambitieuses.
Questions fréquentes sur Cdiscount FBC
Cdiscount FBC correspond-il à Octopia Fulfillment côté API ? Oui, les flux récents de fulfillment sont documentés côté Octopia Fulfillment, avec référencement produit, inbound shipments, stocks, outbound shipments et retours selon l'éligibilité du seller et du contexte.
Que faut-il référencer avant d'envoyer du stock FBC ?
Il faut stabiliser GTIN, productCondition, sellerProductReference, dimensions emballées et données
logistiques utiles, car un produit mal référencé peut bloquer la suite du flux inbound.
Dawap peut-il accompagner une intégration Cdiscount FBC API ? Oui. Dawap accompagne le cadrage Octopia Fulfillment, les mappings ERP/WMS, les restrictions seller, stocks, inbound, outbound, retours, reprises, recette et observabilité de production.
Guides complémentaires pour Cdiscount FBC
Une intégration Cdiscount FBC touche rarement un seul système. Les ressources suivantes aident à approfondir la chaîne shipping, les responsabilités WMS/TMS, les stratégies d'événements et la protection contre les doubles traitements.
Architecture shipping de bout en bout
La lecture API logistique et shipping replace Cdiscount FBC dans une chaîne complète: référencement, approvisionnement, entrepôt fulfillment, expédition, tracking, retour et preuve opérationnelle entre les canaux de vente.
Elle aide à décider ce qui appartient au canal de vente, au WMS, au middleware ou à Octopia. Cette frontière évite les débats tardifs quand un stock existe physiquement mais ne peut pas encore être promis.
Elle donne aussi une grille pour relire les exceptions: stock bloqué, litige, retour, outbound incertain, pays non activé ou promesse client plus ambitieuse que la capacité réelle du fulfillment.
Connexion OMS, WMS et TMS
Le dossier WMS, TMS et API logistique prolonge les questions de source de vérité, de transport management et de synchronisation lorsque Cdiscount FBC coexiste avec des stocks internes.
Il devient utile quand Octopia n'est qu'un nœud dans une organisation plus large. Un WMS peut préparer une partie des commandes, tandis qu'Octopia sert certains canaux ou certains pays.
Cette approche convient aux vendeurs qui veulent éviter une disponibilité globale trompeuse. Le connecteur doit expliquer quel stock sert quel canal, et quel système décide en cas de conflit.
Réception des événements et relances
La ressource webhook ou polling API permet de choisir une stratégie fiable pour les statuts, les relances, les lectures contrôlées et les reprises autour des flux Octopia.
Elle aide à décider quand attendre, quand relire, quand mettre en quarantaine et quand notifier le support. Cette décision devient centrale lorsque le stock ou le retour évolue après une correction manuelle.
Elle évite aussi de confondre fraîcheur technique et vérité métier. Une lecture récente peut être insuffisante si le stock n'a pas été qualifié ou si le statut client a déjà changé ailleurs.
Protection contre les doubles traitements
La ressource idempotence API et doublons métier donne le cadre nécessaire pour éviter les outbounds recréés, les retours rapprochés deux fois et les statuts rejoués sans trace fiable.
Elle devient prioritaire dès qu'un timeout peut masquer une opération réussie, qu'un opérateur peut relancer une commande ou qu'un batch peut réimporter un statut déjà appliqué. Le coût d'un doublon dépasse souvent celui d'une validation stricte.
Elle donne enfin une méthode pour relier clé métier, journalisation, queue, retry, rollback et preuve support. Cette méthode s'applique directement aux flux inbound, stock, outbound et retours Cdiscount FBC.
Conclusion: intégrer Cdiscount FBC sans boîte noire
Une intégration API Cdiscount FBC réussie ne se mesure pas au nombre d'appels Octopia effectués. Elle se mesure à la capacité d'expliquer un produit référencé, un inbound, un stock, un outbound ou un retour sans reconstruire toute la chaîne.
Le bon ordre reste stable: vérifier l'éligibilité seller, référencer correctement les produits, créer les inbound avec preuve, qualifier le stock, protéger les outbounds, séparer les retours et donner au support une lecture actionnable.
Cette discipline ne ralentit pas le projet. Elle évite de transformer Cdiscount FBC en boîte noire logistique, réduit les surventes, protège la marge et rend l'élargissement vers d'autres canaux beaucoup plus maîtrisable.
Si vous devez connecter Cdiscount FBC à un ERP, un WMS, un OMS, une marketplace ou une boutique avec une preuve de run solide, notre accompagnement en intégration API peut cadrer l'architecture, les mappings, les reprises et l'observabilité sans déplacer la dette vers le support.
