Un vendeur peut expédier dans les temps et pourtant laisser le client sans suivi parce que le tracking n’a pas rejoint Fnac Darty. Il peut aussi posséder le stock dans l’ERP alors que l’offre reste fermée après un rejet. Le flux technique fonctionne par morceaux, mais la promesse de service est rompue.
En pratique, automatiser ne signifie pas supprimer tout geste humain. L’intégration absorbe la répétition, protège les effets et présente les exceptions au bon owner. Elle doit rendre visibles fiche, offre, commande, colis et SAV dans une chronologie partagée.
Ce dispositif s’inscrit dans une intégration API gouvernée. Vous allez comprendre comment décider les priorités, corriger les ruptures de preuve et préparer le run ; les choix d’assortiment, de marge et d’animation restent du ressort de l’agence Fnac Darty marketplace lorsque le besoin dépasse le connecteur.
Deux objectifs structurent l’architecture :
- Tenir le pic : les queues et garde-fous empêchent le volume d’amplifier un défaut.
- Prouver le service : support et logistique retrouvent le dernier fait confirmé et la prochaine action.
1. Automatiser la promesse de service
Mesurer le parcours plutôt que les seuls appels
La chaîne commence par une offre vendable et se termine lorsque commande, expédition, tracking, retour éventuel et remboursement sont cohérents. Chaque étape possède un délai, une preuve et une équipe responsable. La disponibilité de l’API n’est qu’une dépendance de ce service.
Le diagnostic cartographie les gestes manuels : export, correction, import, relance et consultation de plusieurs écrans. Leur fréquence et leur impact révèlent les priorités. Une opération rare mais critique peut passer avant une tâche quotidienne sans conséquence client.
Le premier périmètre retient quelques familles et scénarios de commande. Il vise la continuité complète, pas une couverture superficielle de tous les objets. Cette verticale fournit les contrats et le runbook qui serviront ensuite à l’extension.
2. Séparer fiche produit et offre
Distinguer description et décision de vente
La fiche porte identité, caractéristiques, catégorie et médias. L’offre associe vendeur, prix, stock, état et conditions. Un produit accepté peut ne pas avoir d’offre active ; une offre correcte peut rester impossible si la fiche est rejetée.
Le back-office montre cette dépendance sans fusionner les erreurs. Les rejets fiche sont classés par attribut, identifiant, média ou catégorie ; les rejets offre concernent plutôt prix, quantité ou règle commerciale. Chaque cause indique sa source de vérité et son correcteur.
Le mapping conserve produit, SKU, identifiant canal et version. Une correction sur une fiche commune ne doit pas republier aveuglément toutes les offres. La reprise sélectionne les objets affectés et contrôle leur état final après acceptation.
3. Publier le stock promettable
Protéger les références prioritaires
La quantité publiée part du stock ERP ou WMS puis retire réservations, commandes en attente, allocation aux autres canaux et tampon. La règle varie selon la vitesse de vente, le réassort et le coût d’une annulation. Elle reste datée et explicable.
Une donnée dépassant son seuil de fraîcheur déclenche un repli. Pour certaines familles, l’offre ferme ; pour d’autres, une quantité minimale prudente peut rester. Le choix est validé avant l’incident et non improvisé pendant un pic.
Le monitoring compare stock attendu, publié et vendu. Il repère une variante toujours positive malgré les commandes, une famille entièrement à zéro ou un écart croissant avec le WMS. Ces symptômes signalent parfois un mapping erroné sans provoquer d’erreur d’appel.
4. Protéger prix et promotions
Vérifier la marge avant la vitesse
Le calcul rassemble coût, frais, préparation, transport, promotion et marge cible. Une variation inhabituelle ou un prix sous plancher est isolé avant publication. Le payload de quarantaine présente les entrées et la règle franchie au commerce.
Une promotion possède une période, une population de SKU et un état de repli. Son expiration remet la valeur attendue sans écraser une nouvelle décision tarifaire. La concurrence entre deux campagnes est résolue dans la source, pas selon l’ordre aléatoire des messages.
Contrairement à ce que l’on croit, une offre temporairement suspendue peut coûter moins qu’une remise incohérente diffusée pendant un pic. Le garde-fou privilégie une perte d’opportunité bornée à une perte de marge multipliée par le volume.
5. Importer chaque commande une fois
Rendre la création idempotente
Le collecteur persiste la commande source, ses lignes, montants et horodatages avant d’écrire dans l’ERP ou l’OMS. Webhook, polling et retry partagent une clé d’idempotence. Une référence inconnue est mise en quarantaine sans rapprochement approximatif.
Un timeout après l’écriture produit un état incertain. Avant de réessayer, le worker recherche l’objet par référence métier et vérifie l’effet. Cette étape évite la double commande, la double réservation et les corrections comptables qui en découleraient.
Les statuts source restent disponibles à côté du modèle interne. Une transition hors ordre ne remplace pas une preuve plus récente. Le journal expose événement reçu, règle appliquée et action produite afin que l’ADV puisse suivre la commande.
6. Transmettre le tracking à temps
Corréler le colis jusqu’à son acquittement
Le tracking relie commande, colis, transporteur, numéro et date d’expédition. Le connecteur valide les champs et la transition, appelle l’endpoint puis conserve l’accusé ou le rejet. Le statut « envoyé » ne suffit pas à démontrer que la marketplace l’a compris.
Le délai entre sortie d’entrepôt et acceptation Fnac Darty devient un SLA. Une queue prioritaire traite les colis proches du seuil ; les erreurs fonctionnelles sont orientées vers l’équipe capable de corriger transporteur, format ou référence.
Les expéditions partielles gardent le niveau ligne ou colis nécessaire. Le support voit ce qui est parti et ce qui reste. Une correction rejoue uniquement la preuve refusée, sans modifier les lignes déjà reconnues.
7. Armer le support et le SAV
Présenter une chronologie lisible
Le support ne devrait pas ouvrir des logs pour répondre. La fiche commande rassemble événements, statuts, colis, messages, retour et remboursement. Elle distingue fait confirmé, action en attente et donnée absente, avec une date et un owner.
Les détails techniques restent accessibles avec masquage des secrets et données personnelles. Correlation id, endpoint, code et version de contrat accélèrent l’escalade. Le ticket référence cette preuve plutôt que de copier tout le payload.
Le SAV ajoute motif, réception, décision et montant. Une demande client n’équivaut pas encore à un retour reçu ; un remboursement lancé ne prouve pas son rapprochement. Le modèle garde ces étapes séparées pour éviter une réponse trop optimiste.
8. Reprendre sans élargir l’incident
Filtrer, simuler et contrôler
Le runbook permet de choisir objet, famille, commande, période, cause et état. Une simulation annonce les effets et le volume. Un seuil d’arrêt bloque une sélection excessive avant que le rejeu n’atteigne l’API ou le SI.
La queue applique rate limit, retry et backoff. Les erreurs fonctionnelles sortent du cycle automatique ; les erreurs transitoires restent bornées. Le contrat OpenAPI, le payload et la version du mapping accompagnent chaque tentative.
Le contrôle final vérifie l’objet cible, pas seulement le code de réponse. Fiche acceptée, offre active, commande présente ou tracking reconnu constituent les preuves de restauration. Les exceptions restantes forment un nouveau périmètre explicite.
9. Classer les alertes par impact
Donner la priorité au client et à la marge
Les métriques techniques suivent latence, timeout, token, pagination et profondeur de queue. Le run ajoute offres rejetées, stock périmé, commandes manquantes, tracking hors SLA, retours bloqués et corrections manuelles.
Chaque alerte possède un impact, un owner et une première action. Un tracking absent sur une commande expédiée passe devant un attribut secondaire. Une baisse de prix sous plancher passe devant une information enrichie, même si le second rejet touche davantage de SKU.
L’absence de messages est contrôlée. Pendant une période active, zéro commande peut signifier une collecte cassée. Une sonde synthétique et la comparaison avec le back-office empêchent ce silence de donner une fausse impression de santé.
10. Préparer les pics commerciaux
Tester débit, dépendances et organisation
La préparation estime volumes d’offres, commandes et trackings par fenêtre. Elle vérifie capacité des workers, taille des queues, quotas et temps de traitement. Les capacités exactes sont confirmées dans l’environnement et la documentation courants avant le test.
La charge n’est pas le seul risque. Les owners, astreintes, seuils et modes dégradés sont nommés. Si le stock devient périmé, la règle de fermeture est connue ; si le tracking prend du retard, une file prioritaire et un message support sont prêts.
La contre-intuition est de réduire certains flux avant le pic. Les corrections catalogue non urgentes peuvent attendre afin de réserver le débit aux commandes et preuves clients. Cette décision est temporaire, mesurée et réversible après retour au nominal.
Fixer des seuils avec des scénarios observables
Cas concret : si la file dépasse 500 commandes ou si son plus ancien message atteint 15 minutes, alors les enrichissements catalogue sont suspendus et la capacité est réservée aux commandes et trackings. Ce seuil déclenche une décision connue, un owner et un délai ; il ne sert pas seulement à colorer le dashboard.
Deuxième exemple concret : lorsque plus de 3 % des trackings dépassent le SLA de 2 heures sur une famille stratégique, la logistique vérifie le transporteur et le mapping avant toute hausse de parallélisme. En revanche, si le retard vient du quota, l’ordonnanceur protège cette file et diffère les tâches commerciales non urgentes.
11. Éviter les erreurs fréquentes
Écarter les faux raccourcis
Confondre fiche et offre conduit à corriger le mauvais système. Rejouer une période entière pour une commande crée des doublons potentiels. Considérer la présence du tracking comme suffisante masque son délai et son refus éventuel.
Une autre erreur consiste à automatiser toutes les catégories au même niveau. Les familles stratégiques, fragiles ou fortement retournées demandent des seuils distincts. La configuration doit rester lisible et versionnée pour éviter une forêt d’exceptions.
Les interventions dans le back-office sans journal commun finissent par contredire la source. Toute correction urgente garde auteur, motif, valeur avant/après et durée, puis alimente le backlog lorsque sa cause doit être traitée durablement.
- Ne pas publier sans vérifier l’état final.
- Ne pas répéter une écriture après timeout sans réconciliation.
- Ne pas exposer secrets et données personnelles dans les logs.
- Ne pas déclarer l’incident clos sans preuve client.
12. Plan d’action pour Fnac Darty
Mettre sous contrôle une verticale complète
La première phase sélectionne une famille et décrit fiche, offre, stock, prix, commande, colis et SAV. Elle attribue les sources et identifiants, puis nomme les responsables produit, commerce, ERP, logistique, support et technique.
La deuxième phase versionne schémas, mappings et règles. Une sandbox reçoit fiche rejetée, stock périmé, promotion incohérente, commande dupliquée et tracking refusé. Chaque résultat attendu est validé par l’équipe qui l’exploitera.
La troisième phase ouvre un lot borné avec queues séparées, monitoring, quarantaine et rollback. Les commandes sont rapprochées chaque jour ; les trackings hors SLA sont suivis jusqu’à acceptation. Les corrections manuelles restent visibles.
La quatrième phase mesure volume, marge, retards, retours et charge support. Elle décide quelles catégories étendre ou suspendre. Une anomalie structurante doit être corrigée avant que le débit ou l’assortiment n’augmente.
Homologuer une journée de pic
Le test injecte un lot d’offres, une rafale de commandes et des expéditions multi-colis. Il limite volontairement une dépendance pour observer le backpressure. Les commandes et trackings conservent la priorité, tandis que les enrichissements non urgents attendent dans une queue distincte.
Un token expire pendant l’exercice et un timeout survient après création ERP. La rotation rétablit l’accès, la réconciliation retrouve la commande et l’idempotence interdit sa duplication. Le monitoring distingue l’incident d’authentification du retard métier.
Le support suit un cas client de bout en bout, depuis la commande jusqu’au tracking corrigé. Il doit comprendre le dernier fait et l’échéance sans intervention du développeur. La logistique vérifie que les colis déjà acceptés ne sont pas rejoués.
Le bilan compare débit, latence, profondeur maximale, erreurs, temps de reprise et effets métier. Il ajuste capacité et seuils, puis documente le mode dégradé. Une réussite technique sans preuve de service ne valide pas la bascule.
Ordonner les décisions
D’abord, séparer fiche et offre. Ensuite, sécuriser commande et tracking. En priorité, traiter les exceptions qui affectent client ou marge. À différer : les enrichissements pendant un pic. À refuser : une ouverture sans simulation de reprise.
Le mois suivant conserve une revue rapprochée. Les incidents réels deviennent des tests de non-régression et les alertes inutiles sont révisées. L’équipe étend seulement lorsque le lot initial ne dépend plus de gestes invisibles.
- D’abord : cartographier toute la verticale métier.
- Ensuite : prouver commandes et colis.
- En priorité : protéger les meilleures ventes.
- À différer : les tâches sans effet client.
- À refuser : un run sans owner et rollback.
Installer un poste de contrôle vendeur
L’écran de run rassemble d’abord les files qui exigent une action, pas tous les événements. Une offre rejetée affiche la cause, la source à corriger et la valeur commerciale de la référence. Une commande bloquée montre l’étape atteinte, les lignes concernées et le délai restant. Un tracking absent indique l’heure d’expédition, le transporteur et le dernier appel. Cette organisation permet au responsable de commencer par le risque réel plutôt que par la dernière erreur technique arrivée.
Chaque file possède une sortie explicite : corriger la donnée, autoriser une exception, rejouer, attendre une dépendance ou escalader. L’opération conserve commentaire, auteur et échéance. Le statut ne passe à « résolu » qu’après vérification de l’effet dans Fnac Darty et dans le SI. Une action provisoire peut restaurer le service, mais elle reste liée à une dette tant que la cause source n’est pas supprimée.
Le support accède à une vue plus sobre. Il retrouve commande, colis, retour et dernières preuves sans voir token, payload complet ou détail d’infrastructure. Lorsque l’escalade devient nécessaire, un identifiant de corrélation transmet le contexte à la technique. Cette séparation accélère la réponse tout en limitant l’exposition de données personnelles et en évitant les copies de logs dans les outils de ticketing.
La direction commerciale consulte des agrégats différents : offres actives, valeur bloquée, commandes hors SLA, retours et coût des corrections. Ces données servent à arbitrer l’assortiment et les promotions ; elles ne remplacent pas la chronologie opérationnelle. Les deux vues partagent néanmoins les mêmes identifiants et définitions, afin qu’une hausse globale puisse être expliquée par les objets qui l’ont réellement produite.
Boucler chaque incident dans le produit
Une exception récurrente déclenche une analyse de cause. L’équipe décide si elle vient de la donnée, du mapping, du contrat, d’une limite du canal ou d’une procédure interne. Le correctif ajoute un scénario de test avec son payload anonymisé et sa sortie attendue. Lors du prochain déploiement, ce cas traverse à nouveau collecte, transformation, queue, preuve et écran support.
Le registre conserve aussi les incidents acceptés. Une différence peut être temporairement tolérée si son impact est faible et si son contournement est sûr, mais cette décision possède une date d’expiration. La revue évite ainsi que les exceptions provisoires deviennent la nouvelle norme et que le connecteur accumule une dette impossible à distinguer du fonctionnement nominal.
Une synthèse mensuelle rapproche enfin corrections, temps support et qualité vendeur. Elle identifie les catégories qui concentrent encore les gestes manuels et vérifie si l’automatisation a réellement réduit la charge. Quand un indicateur s’améliore seulement parce qu’une file n’est plus alimentée, le contrôle avec la source révèle le silence. Le prochain investissement vise la cause la plus coûteuse et mesurable, non la fonctionnalité la plus visible. La décision mentionne le bénéfice attendu, le propriétaire et le critère qui permettra de la fermer sans discussion subjective.
13. Approfondir offres et reprise
Réutiliser les invariants du hub marketplace
Pour approfondir statuts, idempotence et reprise, poursuivez avec la normalisation des API marketplace. Elle fournit le modèle transverse derrière la commande Fnac Darty.
Pour comparer un run où stock, prix et retours déterminent la contribution, relisez l’intégration Cdiscount. La comparaison sépare les garde-fous communs des règles propres à chaque canal.
Les composants partagés peuvent couvrir contrats, queues, observabilité et commandes de reprise. Les mappings et SLA restent spécifiques. Cette frontière permet de mutualiser sans fabriquer une uniformité qui masquerait le service attendu.
14. Conclusion : automatiser sans perdre la marge
Faire du flux une preuve de service
Fnac Darty API devient rentable lorsque fiche, offre, stock, commande et tracking restent cohérents pendant les périodes normales comme pendant les pics. L’automatisation absorbe le volume sans effacer les exceptions.
La qualité se lit dans la chronologie accessible au support : ce qui a été reçu, accepté, refusé et corrigé. Cette preuve protège le client, la charge opérationnelle et la marge vendeur.
Un premier périmètre complet vaut mieux qu’une couverture large encore dépendante d’exports et de corrections invisibles. Les tests de charge et de reprise doivent précéder l’extension.
Dawap peut vous accompagner pour structurer cette chaîne, ses preuves de service, son observabilité et son runbook de production durable, mesurable et auditable dans le temps : cadrez votre intégration API.
