1 minute de downtime = 10 000 EUR : et votre checkout crashe combien de fois par mois ?

Le downtime que tout le monde surveille — et celui que personne ne voit

Quand votre site tombe, Datadog sonne. StatusPage passe au rouge. L'équipe technique est sur le pont en minutes. Ce scénario est couvert.

Mais il existe un autre type de downtime, bien plus fréquent et bien plus coûteux sur la durée : le micro-downtime du checkout. Le serveur répond 200 OK. La page s'affiche. Mais le bouton "Payer" ne fait rien quand on clique dessus. Ou l'API Stripe timeout après 15 secondes. Ou une erreur JavaScript empêche le formulaire de carte bancaire de se charger.

Pour votre monitoring backend, tout va bien. Pour votre chiffre d'affaires, c'est une hémorragie silencieuse.

Le coût réel : 10 000 EUR par minute

L'industrie e-commerce estime le coût moyen d'un downtime à 10 000 EUR par minute pour un site mid-market. Ce chiffre inclut le manque à gagner direct, l'impact sur les campagnes paid en cours et le coût de récupération des paniers abandonnés.

Pour un site à 500 000 EUR/mois, le calcul est simple :

Pour un site plus gros, à 2 000 000 EUR/mois :

Et ce sont les coûts directs. Les coûts indirects — clients perdus définitivement, avis négatifs, impact SEO — ne sont pas comptés.

77 % ne reviendront pas

Le chiffre le plus important n'est pas le coût par minute. C'est celui-ci : 77 % des consommateurs abandonnent définitivement un site après avoir rencontré une erreur lors du checkout (étude Loqate/GBG 2024).

Pas "abandonnent leur panier". Abandonnent le site. Ils partent chez le concurrent et n'ont aucune raison de revenir. Pire : les clients qui rencontrent un bug de checkout sont 3 fois plus susceptibles de basculer vers un concurrent dans les 30 jours.

Un micro-downtime de checkout de 20 minutes un mardi après-midi ne fait pas la une. Mais les 150 clients qui ont vu un message d'erreur au moment de payer, eux, s'en souviennent.

Les micro-downtimes : fréquents et invisibles

Les downtimes complets — site inaccessible, erreur 500 — sont rares (1 à 2 fois par an pour un site bien géré). Les micro-downtimes du checkout sont une tout autre histoire :

• Fréquence moyenne : 2 à 5 fois par mois
• Durée moyenne : 5 à 30 minutes
• Causes principales : erreur JavaScript côté client, timeout API paiement, conflit de script tiers, mise à jour de composant qui casse le formulaire

Un site e-commerce moyen subit 60 à 150 minutes de micro-downtime checkout par mois. Sur un site à 500 000 EUR/mois, cela représente entre 7 000 et 17 000 EUR de pertes mensuelles — sans que personne ne le sache.

Pourquoi le monitoring classique ne les voit pas

Votre stack de monitoring est probablement configurée pour surveiller :

• Le serveur — temps de réponse, taux d'erreur HTTP (Datadog, New Relic)
• Les erreurs applicatives — exceptions Python/Node/PHP (Sentry, Bugsnag)
• La disponibilité — ping HTTP toutes les 60 secondes (UptimeRobot, Pingdom)

Aucun de ces outils ne surveille ce qui se passe dans le navigateur de l'utilisateur. Si le bouton "Payer" ne répond plus à cause d'un conflit JavaScript, le serveur continue de répondre 200 OK. Sentry ne voit pas l'erreur si elle est côté client et non capturée. UptimeRobot confirme que le site est en ligne.

Le résultat : le trafic continue d'arriver (vous payez les clics), les utilisateurs atteignent le checkout (ils ont navigué normalement), mais personne n'achète. Pendant 20 minutes. Et personne ne le sait.

Le signal d'alarme : les achats s'arrêtent

La méthode la plus fiable pour détecter un micro-downtime de checkout n'est pas de surveiller les erreurs techniques. C'est de surveiller le flux de conversions.

Un site qui fait 200 achats par jour en fait environ 8 par heure aux heures de pointe. Si ce chiffre tombe à zéro pendant 30 minutes alors que le trafic reste stable, quelque chose ne va pas.

C'est exactement le principe de l'alerte checkout_zero de Korvus : elle surveille en continu le ratio entre le trafic entrant et les événements d'achat. Quand les achats s'arrêtent brutalement alors que le trafic continue, l'alerte se déclenche en quelques minutes — avec l'estimation du CA perdu.

Le CMO ne reçoit pas un stack trace. Il reçoit : "Aucun achat détecté depuis 22 min malgré 340 sessions actives — perte estimée : 2 800 EUR. Checkout probablement bloqué."

Comment limiter l'impact

Trois mesures concrètes pour réduire le coût des micro-downtimes de checkout :

1. Surveiller les conversions, pas seulement le serveur

Le meilleur indicateur de santé du checkout n'est pas le temps de réponse du serveur. C'est le nombre d'achats par heure comparé aux baselines. Si ce ratio chute, quelque chose est cassé — peu importe ce que dit Datadog.

2. Automatiser la coupure des campagnes paid

Quand le checkout est en panne, chaque clic paid est un budget jeté. Les 15 minutes nécessaires à un humain pour voir l'alerte, comprendre le problème et mettre en pause les campagnes coûtent entre 1 500 et 5 000 EUR de clics inutiles.

3. Tester le checkout après chaque déploiement

Pas un test E2E complet. Un test synthétique simple : est-ce que le formulaire de paiement se charge ? Est-ce que le bouton "Payer" est cliquable ? Est-ce que l'API Stripe répond en moins de 3 secondes ? Si ces trois conditions sont remplies, le checkout fonctionne.

Points clés

• Le coût moyen d'un downtime e-commerce est de 10 000 EUR par minute — et les micro-downtimes du checkout sont 10 à 50 fois plus fréquents que les downtimes complets
• 77 % des clients partent définitivement après une erreur de paiement
• Un site e-commerce moyen subit 2 à 5 micro-downtimes de checkout par mois, pour un coût total de 7 000 à 17 000 EUR
• Le monitoring backend ne voit pas les pannes côté navigateur — seul le suivi du flux de conversions en temps réel permet de les détecter
• Chaque minute de checkout cassé pendant que les campagnes paid tournent est un double coût : CA perdu + budget gaspillé