Automatisation des expéditions Amazon FBA : intégration MWS, Fnac API et Cdiscount API pour Pixminds

1. Présentation du client

Comprendre le contexte business avant la solution

Pixminds évoluait dans un contexte de croissance où la qualité du service client dépendait directement de la vitesse et de la cohérence des expéditions publiées sur plusieurs canaux.

Le client avait besoin d’un dispositif capable de mieux synchroniser les commandes, les règles de routage et les retours de tracking, sans multiplier les manipulations humaines ni les contournements techniques.

Le projet devait donc devenir une vraie couche d’orchestration opérationnelle, pensée pour la production et pas seulement pour une démonstration technique.

2. Méthode projet Dawap

Analyse, priorisation, delivery agile et sécurisation du run

Le chantier a commencé par une phase d’analyse des flux critiques : canaux sources, règles de routage FBA, cas de fallback transporteur, cohérence des statuts et besoins d’observabilité. Cette étape a permis d’identifier très tôt les points de rupture les plus coûteux pour les opérations.

Le backlog a ensuite été structuré dans Jira avec une logique de sprints itératifs. Les user stories ont été priorisées selon leur valeur métier : fiabiliser d’abord la normalisation des commandes, sécuriser ensuite les décisions de routage et renforcer progressivement la supervision et la rejouabilité.

Les lots ont été validés avec des tests, des environnements distincts, des scénarios de reprise et une mise en production progressive. L’objectif était de construire un run stable, capable de tenir les pics sans faire exploser la charge support.

3. Contexte du projet Pixminds

Un e-commerce en croissance avec une logistique sous pression

Pixminds gérait des volumes croissants sur plusieurs canaux, avec une forte exigence sur les délais d’expédition et la qualité de suivi. Les commandes provenant de Fnac et Cdiscount devaient être traitées avec des règles différentes, tout en tirant parti des stocks Amazon FBA pour accélérer certaines livraisons.

L’enjeu n’était pas uniquement de connecter des APIs, mais d’industrialiser un run logistique fiable. Chaque décalage de statut ou erreur de routage créait un effet direct sur le support client, la satisfaction acheteur et la charge des équipes internes.

Le projet a donc été pensé comme un chantier de stabilisation durable avant toute extension à de nouveaux canaux ou à de nouvelles règles métier.

4. Souffrances opérationnelles identifiées

Des traitements manuels trop coûteux pour tenir le rythme

Avant la mise en place du middleware, les équipes devaient rattraper manuellement des écarts de stock, des tracking incomplets et des statuts incohérents selon la marketplace source. Ces interventions récurrentes augmentaient la charge opérationnelle et réduisaient la capacité à se concentrer sur les arbitrages métier.

La dépendance aux manipulations humaines générait aussi un risque de non-qualité élevé en période de pic. Plus le volume montait, plus les erreurs de routage, les retards de publication et les corrections support devenaient coûteux.

Le besoin était donc de rendre les flux critiques observables, rejouables et gouvernés par des règles explicites plutôt que par des rattrapages permanents.

5. Besoins métier et objectifs de réussite

Fiabiliser le run et créer un socle extensible

Le cadrage a fixé des objectifs mesurables : automatiser le cycle commande-expédition, réduire les corrections manuelles, publier un tracking cohérent plus rapidement et améliorer la stabilité globale du service.

Le besoin principal était un moteur d’orchestration capable de décider automatiquement du bon canal d’expédition selon la disponibilité FBA, les contraintes transporteur et la qualité des données reçues.

En parallèle, Pixminds voulait un socle évolutif pour brancher de futurs connecteurs sans refondre le cœur du système.

6. Présentation client et périmètre traité

Un périmètre concentré sur les flux les plus critiques

Le périmètre initial a ciblé les commandes Fnac et Cdiscount, la logique d’exécution FBA Amazon et les transporteurs classiques pour les cas non FBA. Ce choix a permis de sécuriser rapidement les parcours les plus sensibles avant d’étendre la couverture.

Le projet incluait la normalisation des objets commande, la synchronisation des stocks, le mapping des statuts et la supervision des erreurs.

L’approche a été pensée pour soutenir les opérations au quotidien, pas seulement pour valider une preuve de concept.

7. Durée, lotissement et cadence de delivery

Une trajectoire itérative orientée valeur run

Le delivery a été structuré en lots incrémentaux : cadrage des contrats d’échange, mise en place des connecteurs, routage logistique, puis observabilité et stabilisation.

Chaque lot livrait un périmètre exploitable en production, avec des validations métier courtes et des arbitrages alignés sur ce qui soulageait réellement le run.

Cette cadence a permis de réduire les risques de bascule globale et d’intégrer rapidement les retours des équipes opérationnelles.

8. Technologies et stack d’intégration

Un middleware robuste pour absorber les variations de charge

Le socle technique s’appuie sur Symfony pour le middleware d’orchestration, RabbitMQ pour le découplage des traitements asynchrones, Redis pour certains états techniques à faible latence, et une couche de persistance orientée traçabilité des événements.

Cette stack a été choisie pour sa capacité à gérer les pics de volume tout en conservant une excellente lisibilité opérationnelle.

Elle facilite aussi l’ajout progressif de nouveaux connecteurs et de nouvelles règles métier sans remettre en cause la base existante.

9. APIs intégrées et leviers d’automatisation

Connecter les bons services sans complexifier l’exploitation

10. Conception agile et décisions d’architecture

Des choix orientés résilience et exploitation

Les décisions structurantes ont porté sur l’idempotence, la gestion des quotas API, la reprise sur incident et la journalisation corrélée. Le but était d’éviter les blocages silencieux et de rendre chaque incident diagnosticable rapidement.

La gouvernance run a été pensée dès le départ : contrôles qualité des données, alerting, procédures de replay et boucle d’amélioration continue.

Cette discipline distingue un système réellement exploitable d’un simple connecteur fonctionnel.

11. Diagramme des flux commande à expédition

Visualiser la chaîne cible pour aligner équipes métier et technique

La représentation des flux a servi d’artefact central de pilotage. Elle a permis d’aligner les décisions de routage, les responsabilités de traitement et les points de reprise en cas d’erreur.

Fnac/Cdiscount Order
  -> Ingestion API
  -> Normalisation Pivot
  -> Moteur de routage
      -> FBA Amazon (si critères OK)
      -> Transporteur DPD/UPS (fallback)
  -> Retour tracking
  -> Publication statuts marketplace

Cette visualisation a aussi servi à rendre les arbitrages beaucoup plus concrets pour les profils métier comme pour les profils techniques.

12. KPI obtenus après mise en production

Des gains concrets sur la qualité de service

13. Extrait technique de routage API

Illustration simplifiée de la logique de décision

Le routage combine des règles métier explicites et des vérifications techniques de disponibilité. L’extrait ci-dessous illustre la logique d’arbitrage mise en place dans le middleware :

if (order.channel in ["fnac", "cdiscount"] and stock.fba_available) {
    route = "amazon_fba";
} elseif (carrier.dpdups_available and order.address_valid) {
    route = "carrier_standard";
} else {
    route = "manual_review";
    alert("routing_exception", order.id);
}

L’objectif n’était pas d’empiler des conditions, mais de rendre la décision suffisamment explicite pour être reprise, contrôlée et améliorée dans le temps.

14. Bilan, enseignements et prochaines étapes

Du projet réussi à la plateforme durable

Le projet Pixminds a abouti avec succès : les flux critiques sont industrialisés, les opérations sont plus stables et le pilotage repose sur des données fiables.

Les prochaines étapes portent sur l’extension à d’autres canaux, le renforcement de l’observabilité et l’enrichissement des règles métier.

Ce socle prépare naturellement des trajectoires connexes vers l’intégration API e-commerce et des briques authentification/sécurité pour sécuriser la montée en charge sans fragiliser l’existant.

15. Témoignage client et retour terrain

Statut du témoignage pour ce projet

Aucun témoignage client public n’est disponible à ce stade pour ce projet. Aucun verbatim n’est donc affiché volontairement.

Le retour terrain consolidé confirme néanmoins une meilleure stabilité des expéditions, une charge support réduite et une meilleure confiance dans les statuts publiés.

Pour des projets proches, le bon point d’entrée reste API Marketplace puis API logistique & shipping.