Quand les commandes e-commerce ne redescendent plus dans Sage, la tentation est de relancer le connecteur, forcer un export ou corriger manuellement les lignes urgentes. C’est compréhensible, mais dangereux si le flux n’a pas de règle de reprise claire.
Une commande bloquée engage plus qu’un appel API. Elle peut toucher le stock, le paiement, la facture, la préparation, le support client et parfois une marketplace qui mesure les délais. Le plan de reprise doit donc traiter la chaîne complète, pas seulement le message d’erreur visible.
Le bon réflexe consiste à cadrer le flux comme une intégration Sage API de production : statut, preuve, clé de non-doublon, propriétaire métier et procédure de relance. Sans ces éléments, chaque correction crée le risque d’un second incident.
Ce sujet rejoint les grands principes d’intégration API : un système peut tomber, un webhook peut être rejoué, une donnée peut être refusée. La qualité se voit dans la reprise, pas seulement dans le succès nominal.
Le point de bascule
Si l’équipe ne sait pas dire quelles commandes ont été écrites, rejetées, rejouées ou corrigées à la main, il faut arrêter la relance automatique et reconstruire la preuve avant de remettre le flux sous volume.
Identifier le vrai symptôme côté commerce
Le symptôme visible peut être “les commandes ne descendent plus”. En réalité, plusieurs causes existent : client inconnu, prix refusé, article absent, stock incohérent, adresse invalide, paiement non rapproché, droit insuffisant ou indisponibilité technique.
Le diagnostic doit commencer par les commandes impactées et leur conséquence métier. Une commande payée et non créée n’a pas la même priorité qu’un devis B2B incomplet. Un flux marketplace en retard n’a pas le même risque qu’une commande interne en attente de validation.
Geler les écritures avant d’aggraver le stock
Quand l’état réel est incertain, il faut parfois geler les écritures automatiques. Ce gel évite que des retries non maîtrisés créent des doublons, consomment du stock ou déclenchent des préparations incohérentes.
Le gel doit être ciblé. On peut laisser passer les lectures de statut ou les mises à jour non sensibles, tout en bloquant les créations de commandes. Il ne s'agit pas d'arrêter tout le SI, mais de protéger les opérations irréversibles.
Séparer commandes, paiements, clients et factures
Une commande bloquée peut cacher plusieurs sous-flux. Le client peut déjà exister, le paiement peut être capturé, la facture peut être attendue, ou la commande peut être créée sans retour vers le site. Mélanger ces états rend la reprise floue.
Le plan doit séparer les objets : client, commande, lignes, paiement, facture, avoir, livraison. Chaque objet a sa source de vérité, ses statuts et ses règles de correction.
Reconstruire une table de statuts actionnables
Un statut “erreur” ne suffit pas. Il faut distinguer les erreurs corrigeables par le support, les erreurs métier qui demandent arbitrage, les erreurs temporaires qui méritent un retry et les blocages qui imposent une intervention technique.
Cette table de statuts doit être visible dans le canal d’origine. Le support e-commerce doit savoir si la commande est en attente, rejetée, créée dans Sage, à corriger ou à ne surtout pas relancer.
Rejouer sans créer de doublons dans Sage
La règle de reprise la plus importante est l’idempotence. Une même commande externe ne doit produire qu’une seule commande Sage, même si l’événement est rejoué, si un webhook arrive deux fois ou si un opérateur relance manuellement.
Cette règle repose sur une clé stable, un journal de tentative et une recherche avant écriture. Sans elle, la reprise peut résoudre un blocage tout en créant une dette de facturation ou de stock plus coûteuse.
Lire les logs comme preuves métier
Les logs utiles relient une commande, une tentative, une donnée source, une réponse Sage, un statut et une action attendue. Un log purement technique aide à déboguer, mais il ne suffit pas à piloter la relation client.
La preuve doit permettre de répondre vite : la commande existe-t-elle dans Sage ? A-t-elle été refusée ? Pourquoi ? Peut-on rejouer ? Qui doit corriger ? Quelle donnée a changé depuis la première tentative ?
Organiser le support de reprise
Le support ne doit pas dépendre d’un développeur pour chaque commande. Il lui faut des familles d’erreurs, des actions autorisées, des cas à escalader et une trace des corrections déjà réalisées.
Un bon plan de reprise décrit aussi les limites : ce que le support peut relancer, ce qui doit rester bloqué, ce qui demande validation finance et ce qui impose une correction de mapping.
Protéger facturation, avoirs et paiements
La reprise d’une commande ne doit pas inventer un état financier. Si le paiement est capturé mais que la commande n’est pas créée, la finance doit voir une preuve claire. Si une facture a déjà été émise, le flux ne doit pas recréer une opération divergente.
Les sujets de rapprochement sont approfondis dans l’article Sage API et finance, parce que les commandes bloquées finissent souvent par devenir des écarts de facture, d’avoir ou de paiement.
Relancer proprement le flux après correction
La relance doit être progressive. On traite d’abord un échantillon, on vérifie les statuts, on confirme l’absence de doublons, puis on remet le volume. Rebrancher tout le flux d’un coup peut masquer une seconde erreur.
- Exporter la liste des commandes impactées et leur dernier statut connu.
- Identifier les commandes déjà écrites dans Sage avant tout rejeu.
- Corriger les causes métier récurrentes plutôt que les lignes une par une.
- Relancer par lots contrôlés avec preuve de résultat.
- Documenter l’incident pour renforcer le contrat de flux.
Conclusion : une reprise est un produit d’exploitation
Un plan de reprise Sage n’est pas un document de secours rangé après le projet. C’est une partie du produit d’intégration. Il dit comment le flux vit quand la donnée est imparfaite, quand Sage refuse une écriture ou quand un canal renvoie un événement en double.
La robustesse se mesure à la capacité de reprendre sans inventer de doublons, sans perdre la preuve et sans immobiliser les équipes métier. Un connecteur qui réussit seulement les cas simples n’est pas prêt pour un commerce sous volume.
Si les commandes e-commerce ou marketplace bloquent déjà la préparation, la facturation ou le support, il faut sortir du diagnostic isolé et cadrer le flux avec un intégrateur API Sage. Le premier lot doit nommer les statuts, les clés de non-doublon, les rejets et le replay avant de relancer les volumes.
Pour construire ou reprendre un flux de ce type, l’accompagnement intégrateur Sage API permet de cadrer les statuts, les reprises, les logs et les responsabilités avant de remettre la production sous pression.
