L'ERP est tombé samedi : que deviennent les ventes arrivées entre-temps

En 1 minute

Un ERP qui tombe un moment n'a rien d'exceptionnel : il y a des maintenances, des mises à jour et des pannes. Ce qui coûte cher, c'est ce qui arrive aux ventes entrées entre-temps. Si chaque vente est enregistrée avant d'être promise, relancée avec patience, non dupliquée quand elle est répétée, et si ce qui ne passe pas est mis de côté avec son motif, la panne devient une simple formalité. Sinon, elle devient des jours de saisie manuelle, des commandes en double et une clôture qui ne tombe pas juste.

Imaginez une entreprise qui vend en ligne et au comptoir. Elle est fictive, mais elle ressemble à beaucoup d'autres. Un samedi, son ERP cesse de répondre. Ce peut être une mise à jour qui s'est prolongée, un serveur qui a redémarré ou une liaison coupée ; pour la suite, peu importe. La boutique en ligne reste ouverte. Les clients continuent d'acheter. Et chaque vente doit arriver à l'ERP pour décompter le stock, enregistrer la recette et, ensuite, être facturée.

Quelqu'un aux opérations s'en rend compte tard, parce qu'un client demande sa facture. À ce moment-là, l'entreprise a trois options, même si on les choisit rarement exprès :

1. Fermer la boutique jusqu'au retour de l'ERP. C'est sûr et c'est cher : on perd la vente et, parfois, le client.
2. Continuer à vendre et « saisir plus tard ». Quelqu'un exporte les commandes dans un tableur et les ressaisit ensuite à la main. C'est bon marché pendant la panne et cher le lendemain.
3. Continuer à vendre, avec chaque vente enregistrée dans une attente ordonnée, qui se met à jour au retour de l'ERP, conçue pour ne pas dupliquer et avec la liste de ce qui n'a pas pu passer.

Cet article s'adresse à ceux qui dirigent les opérations, la finance ou la technologie dans une entreprise dont les systèmes dépendent les uns des autres. Il défend une idée : la panne n'est pas le problème ; le problème, c'est de ne pas savoir ce qui est resté en attente. Et il explique, en langage d'affaires, les cinq pièces qui font de la troisième option la norme.

Ce n'est pas un article sur le choix entre un appel en ligne, une file d'attente ou un événement ; c'est l'objet de En ligne ou asynchrone ?. Ni sur la reconstitution de l'histoire d'une commande ; pour cela, il y a On ne perd pas la commande, on en perd la trace. Ici, l'objet est autre : conserver, doser et rapprocher ce qui est en attente pendant une panne et au retour.

Tout ce qui suit est volontairement générique. Cela vaut pour un ERP, un système de facturation, un transporteur ou le système d'un partenaire : toute destination qui, un jour, ne répond pas.

La panne n'est pas le problème : ne pas savoir ce qui est resté en attente

Aucun système ne répond en permanence. Les éditeurs publient des fenêtres de maintenance, les réseaux se coupent et les serveurs redémarrent. La norme du web elle-même réserve un code pour cela : le 503 indique que le serveur ne peut pas traiter la demande en raison d'une surcharge temporaire ou d'une maintenance programmée, ce qui se résoudra probablement après un certain délai (traduction libre) [7]. Autrement dit, l'industrie part du principe que la destination ne sera pas toujours là.

Ce qui change d'une entreprise à l'autre, c'est ce qui arrive à ce qui est entré pendant l'absence de la destination. Et c'est là qu'apparaissent trois questions que, le lendemain, quelqu'un posera à voix haute :

• Combien de ventes sont entrées pendant que l'ERP était en panne ?
• Combien sont déjà arrivées, combien attendent encore et combien ne passeront pas d'elles-mêmes ?
• L'une d'elles est-elle arrivée deux fois ?

Si la réponse à l'une d'elles est « il faut vérifier », une panne courte se transforme en jours de travail manuel et de rapprochement. Et le pire n'est pas le temps : c'est que personne ne peut affirmer avec certitude que la liste est complète.

Ce qui se passe à chaque moment d'une panne

Il est utile de découper la panne en trois moments, car à chacun quelque chose de différent se casse.

Les cinq pièces qui suivent protègent ce qui entre pendant la panne ; la section suivante couvre le retour et la clôture.

Cinq pièces pour qu'une panne soit une simple formalité

1. Enregistrer la vente avant de la promettre

La première règle est simple à énoncer : la vente est enregistrée dans l'entreprise avant d'être envoyée où que ce soit. Pas dans la mémoire du programme qui l'envoie, qui se perd si ce programme redémarre, mais dans un endroit qui survit à une panne.

La façon la plus connue de le faire porte un nom dans l'industrie : la boîte d'envoi (en anglais, transactional outbox). Au moment d'enregistrer la vente, on note aussi, dans la même étape : « il faut prévenir l'ERP ». Un processus séparé lit cette boîte et fait l'envoi. Ainsi, la vente n'est pas enregistrée sans sa tâche en attente [3]. Attention : cela protège ce qui se passe à l'intérieur de l'entreprise ; cela ne confirme pas que l'ERP l'a reçue. Cette confirmation arrive ensuite, quand l'ERP répond.

S'il y a une messagerie entre les deux systèmes, il existe une idée complémentaire, la livraison assurée (en anglais, Guaranteed Delivery) : une fois qu'il a accepté un message, le système de messagerie le conserve dans son stockage et ne l'efface pas tant que l'étape suivante ne l'a pas reçu [6].

En langage de comité : si l'ERP ne répond pas, la vente attend en étant enregistrée, au lieu de se perdre.

2. Relancer avec patience et avec de l'espace

Quand l'envoi échoue, le réflexe naturel est de relancer. Et c'est bien, avec deux précautions.

Patience : chaque relance attend un peu plus que la précédente, jusqu'à un plafond, pour ne pas relancer à l'excès [1]. Si l'ERP va mettre du temps à revenir, il ne sert à rien de l'interroger chaque seconde. Et cela vaut pour les pannes passagères : si l'ERP rejette une vente à cause d'une donnée mal saisie, la relancer ne règle rien (cela relève de la pièce 5).

Espace : les relances de nombreuses ventes ne doivent pas tomber au même instant. Le guide d'Amazon sur les relances l'explique ainsi : si tous les appels qui ont échoué attendent le même temps, ils arrivent de nouveau ensemble en relançant et saturent de nouveau la destination ; la solution consiste à ajouter un peu de hasard à l'attente pour les répartir dans le temps [1]. Le même guide le résume d'une formule à rapporter au comité : les relances sont égoïstes (traduction libre) ; chaque relance exige de la destination qu'elle consacre plus de ressources à la traiter et, si la destination est déjà saturée, relancer aggrave la surcharge au lieu de la soulager [1].

Si la destination répond en suggérant combien de temps attendre —la norme du web prévoit un avis technique pour cela, appelé Retry-After [7]—, on en tient compte avec la règle de relance convenue.

3. Arrêter de frapper à la porte

Il y a un moment où relancer n'aide plus. Si l'ERP ne répond plus depuis un bon moment, lui envoyer chaque vente pour qu'elle échoue une à une ne fait que gaspiller des ressources des deux côtés et produit des échecs répétés qui n'aident personne à exploiter.

C'est à cela que sert le disjoncteur (circuit breaker). Martin Fowler le décrit ainsi : l'appel à l'autre système est enveloppé dans un objet qui compte les échecs ; quand ils atteignent un certain seuil, le disjoncteur « saute » et les appels suivants renvoient une erreur sans même que l'appel soit tenté ; et il est souhaitable qu'il prévienne quelqu'un quand il saute [2]. Toute erreur ne doit pas le déclencher, seulement les échecs définis à cet effet [2]. De temps en temps, il laisse passer un essai contrôlé ; si la destination répond de nouveau, le flux reprend.

En langage de comité : l'entreprise apprend la panne par une alerte, pas par un client qui demande sa facture.

4. Que la répétition ne duplique pas

C'est la pièce qui protège le plus d'argent. Une relance peut arriver deux fois : l'envoi est parti, l'ERP l'a enregistré, mais la réponse s'est perdue en chemin ; l'expéditeur ne sait pas si elle est arrivée et la renvoie. Le guide d'Amazon le dit sans détour : qu'un appel échoue ou expire ne signifie pas que son effet ne s'est pas produit, et une opération qui a des effets n'est pas sûre à relancer à moins d'être conçue pour cela [1]. La boîte d'envoi porte le même avertissement : le processus d'envoi peut envoyer un message plus d'une fois —par exemple, s'il tombe juste après l'avoir envoyé et avant de l'avoir noté—, si bien que celui qui le reçoit doit reconnaître ce qu'il a déjà traité [3].

Le moyen d'y parvenir est que chaque vente voyage avec un numéro de référence unique que la destination reconnaît et conserve : si elle arrive deux fois, la seconde ne crée pas de nouvelle commande, mais renvoie la même réponse que la première. Le numéro de référence ne fonctionne que si la destination le compare réellement, et on le teste avec chaque système concerné, y compris celui de l'encaissement. Les processeurs de paiement procèdent ainsi ; Stripe, par exemple, conserve la réponse à la première demande avec une clé et, si une autre arrive avec la même clé, renvoie la réponse conservée au lieu de répéter l'opération ; il compare aussi les données avec celles de la première et garde la clé pendant un temps, pas indéfiniment [5]. Cette propriété s'appelle l'idempotence : répéter ne change pas le résultat.

En langage de comité : la relance est conçue pour que le client ait une seule commande et un seul encaissement, et le rapprochement final le vérifie.

5. Mettre de côté ce qui ne passe pas, avec son motif

Tout ce qui échoue n'est pas dû à la panne. Certaines ventes ne passeront pas même si l'ERP fonctionne parfaitement : un produit qui n'existe pas dans le catalogue de l'ERP, une donnée fiscale mal saisie, un prix qui ne correspond pas. Si ces ventes sont relancées sans limite, elles bloquent les autres et personne ne s'en aperçoit.

La pratique habituelle consiste à fixer une limite de tentatives et, une fois celle-ci atteinte, à mettre la vente dans une file à part (en anglais, dead-letter queue). La file ne conserve pas le motif à elle seule : avec la vente, on note l'erreur, la tentative et qui décide de l'étape suivante. La documentation des files d'Amazon le décrit ainsi : on fixe combien de fois un message est tenté avant de le déplacer vers cette file, et les mettre de côté sert à isoler ce qui n'a pas été traité et à comprendre pourquoi [4].

L'important n'est pas la file : c'est qu'elle ait un responsable. Une vente mise de côté sans responsable est une vente perdue sous un meilleur nom.

Au retour de l'ERP : l'ordre et le rythme

Le moment le plus délicat n'est pas la panne : c'est le retour. Il y a deux erreurs fréquentes.

Tout envoyer d'un coup. Après une longue panne, des centaines de ventes peuvent être en attente. Si on les envoie toutes en même temps, l'ERP à peine relancé reçoit une avalanche et peut retomber. C'est la même leçon que le point 2, en grand : ce qui est en attente est envoyé à un rythme que l'ERP supporte, et ce rythme se décide et se teste à l'avance, pas en pleine urgence.

Envoyer dans le désordre. Si un client a acheté puis annulé, l'ERP doit recevoir d'abord l'achat, ensuite l'annulation. Dans l'autre sens, l'annulation ne trouve rien à annuler et l'achat reste actif. Pour chaque vente, on définit l'ordre de ce qui lui arrive —par exemple, avec son numéro de référence et un numéro d'étape— et la règle pour l'appliquer, de sorte que l'annulation ne soit pas traitée avant l'achat, même en cas de relances. Des ventes différentes peuvent avancer en parallèle. Et si une vente est passée par la file mise de côté, cet ordre est respecté quand on la réintroduit ; la documentation des files d'Amazon avertit qu'une file de messages en échec peut rompre l'ordre des messages [4].

Et à la fin, un rapprochement : ce qui a été envoyé face à ce que l'ERP a confirmé, avec la liste de ce qui manque. Ce n'est pas de la méfiance envers la conception ; c'est la preuve que la panne est vraiment terminée.

Ce que voit le client pendant ce temps

Pendant la panne, l'idéal est que le client ne remarque que ce qui dépend vraiment de l'ERP. La règle utile est que chaque avis au client parte une fois que ce qu'il annonce s'est produit :

• « Nous avons reçu votre commande » peut partir tout de suite, car la vente est déjà enregistrée dans l'entreprise.
• « Votre facture est prête » ne part qu'une fois la facture émise, pas avant.
• Si le stock est tenu dans l'ERP, il est utile que la boutique réserve de son côté ce qui a été vendu pendant ce temps, pour ne pas vendre deux fois la dernière pièce.

Un avis qui part trop tôt dit quelque chose qui n'est pas encore vrai, et le client s'en souvient davantage que du retard.

Les risques, en langage d'affaires

Cinq questions pour votre prochain comité

1. La dernière fois que l'ERP —ou le système de facturation, ou le transporteur— n'a pas répondu, combien de ventes sont entrées pendant ce temps, et combien de temps a-t-il fallu à votre entreprise pour le savoir ?
2. Où ces ventes sont-elles enregistrées pendant que la destination ne répond pas ? Si la réponse est « dans le programme qui les envoie », elles se perdent quand ce programme redémarre.
3. Si une vente est envoyée deux fois, l'ERP crée-t-il deux commandes ? Demandez à la technologie de le démontrer en test, pas de l'affirmer.
4. Qui est responsable des ventes qui ne sont pas passées d'elles-mêmes, et comment l'apprend-il ?
5. Au retour de l'ERP, qui décide à quel rythme il rattrape le retard ? Si personne ne l'a décidé avant, c'est la personne d'astreinte qui le décide en pleine urgence.

Si plusieurs réponses sont « je ne sais pas », prenez-le comme un signal pour mesurer le flux avant la prochaine fenêtre de maintenance.

Par où commencer cette semaine

Faites un exercice. Dans un environnement de test, coupez volontairement la destination —l'ERP, la facturation ou celle qui vous inquiète le plus— pendant une période et avec un volume de ventes de test que votre équipe définit. Incluez trois cas difficiles : une vente dont la réponse se perd alors que la destination l'a bien enregistrée, une vente que la destination rejette à cause d'une donnée mal saisie, et une vente achetée puis annulée pendant la panne. Ensuite, répondez par écrit :

• Combien de ventes sont entrées pendant l'exercice, et combien sont arrivées à la destination à son retour ?
• L'une d'elles est-elle arrivée deux fois ?
• Lesquelles ne sont pas passées, et quelqu'un l'a-t-il su sans les chercher ?
• Combien de temps la destination a-t-elle mis à rattraper le retard, et a-t-elle supporté le rythme ?
• Quelqu'un a-t-il reçu l'alerte de la panne, et le rapprochement final identifie-t-il chaque numéro de référence comme confirmé ou en attente ?

La fiche qui en résulte est une spécification très concrète de ce dont votre exploitation a besoin.

Ce que fait Hábil

Chez Hábil, nous construisons sur mesure l'espace entre vos systèmes : la boutique, l'ERP, la facturation, les transporteurs et les partenaires. C'est précisément là que se décide ce qui arrive à une vente quand la destination ne répond pas.

Si votre diagnostic confirme qu'une panne se transforme en jours de saisie manuelle, la proposition est dans Hábil MDW : la couche qui se place entre les systèmes que vous avez déjà, sans les remplacer. Chaque envoi reste avec sa réponse ou son motif d'échec, et les relances sont conçues pour ne pas répéter l'effet. Pour chaque opération, on garde ce qui a été envoyé, ce que chaque système a répondu, à quelle heure et, en cas d'échec, pourquoi. Le périmètre, les systèmes connectés et le rythme de reprise sont examinés avec votre cas.

La conversation peut commencer par la dernière panne dont vous vous souvenez : combien de temps elle a duré, ce qui a été fait des ventes et ce qu'a coûté le rattrapage. Avec cela, nous examinons ensemble où se situe le risque dans votre exploitation. Écrivez-nous sur WhatsApp ; pour protéger vos clients, ne partagez pas par ce canal de numéros de commande ni de données personnelles : nous conviendrons dans la conversation du canal pour le cas.

Demandez votre première conversation, sans frais.

Consultées le 12 novembre 2026. Chaque référence porte son niveau de confiance : élevé (source primaire lue).