DataOrganizer

La colonne « en attente de paiement » de l’interface de la boutique gonfle avant le pic de saison, et il est difficile de dire s’il s’agit d’une situation normale ou d’une fuite de trésorerie. Les commandes impayées d’une boutique en ligne entrent dans les rapports de chiffre d’affaires, souvent aussi dans les conversions des campagnes, sans jamais arriver sur le compte bancaire. Ce guide montre, à partir d’une boutique d’électroménager, comment calculer le taux et la valeur des commandes passées mais non payées (hors paiements à la livraison et nouvelles tentatives), fixer sa propre norme par moyen de paiement, mesurer de combien elles gonflent le MER et choisir le parcours de paiement à corriger en priorité. Les pannes de paiement soudaines relèvent du monitoring quotidien ; ici, on calcule la norme stable et sa valeur en euros.

L’ampleur, sur l’exemple de ce guide : sur 1 100 commandes prépayées, 88 n’ont jamais été payées, soit 8,0 % en nombre et 11,8 % en valeur. Une fois déduites les nouvelles tentatives des mêmes clients, 18 280 € ont réellement été perdus en un seul mois.

Bande des statuts

Combien de ventes bloquent entre commande et paiement

Dans l’interface de la boutique d’électroménager, septembre ressemble à un bon mois : 1 200 commandes passées pour 185 000 €. Le relevé bancaire et le rapport du prestataire de paiement affichent pourtant moins, et la comptabilité n’explique pas l’écart. Une partie des commandes est restée au statut « en attente de paiement » et n’en sortira plus.

Première étape : décomposer le total de l’interface. 100 commandes pour 9 500 € sont des paiements à la livraison : le client paie le livreur à la réception, le paiement ne se joue donc qu’à la livraison et elles forment une catégorie à part. Il reste 1 100 commandes prépayées pour 175 500 € ; seules celles-ci devraient être payées avant que le colis ne quitte l’entrepôt.

L’état ne se mesure qu’après la fenêtre de maturation. Les commandes des derniers jours du mois peuvent encore attendre l’encaissement d’un virement : l’évaluation a donc lieu le 8 octobre, 7 jours après la fin septembre. La bande ci-dessous montre ce qu’est devenu chaque euro des commandes prépayées (données illustratives).

Sur 1 100 commandes à prépaiement, 88 n’ont jamais été payées, soit 20 640 € au total. C’est de ce montant que le chiffre d’affaires calculé sur les commandes passées surestime septembre : le back-office affiche 185 000 €, alors que les prépaiements encaissés (154 860 €) et les paiements à la livraison (9 500 €) donnent 164 360 €. L’écart est exactement de 20 640 €.

Une partie de ce montant correspond à des ventes enregistrées sous un autre numéro. 18 commandes pour 2 360 € sont des renouvellements : le même client, reconnu par son identifiant client ou son adresse e-mail hachée, a passé et payé une seconde commande sous 2 jours. L’argent est bien arrivé : ces lignes ne sont pas une perte, seulement un doublon dans les statuts.

La perte réelle est de 70 commandes pour 18 280 €, soit 10,4 % de la valeur des prépaiements pour 6,4 % de leur nombre. La valeur s’échappe plus vite que les unités, car le paiement manque surtout sur les gros paniers ; la répartition par moyen de paiement, plus loin, montre lesquels.

Ce calcul exige le statut de chaque commande. L’événement d’achat dans GA4 et la conversion dans la plateforme publicitaire sont généralement enregistrés sur la page de remerciement, donc au moment où la commande est passée, sans rien savoir de la suite. C’est pourquoi, dans l’analytique e-commerce automatisée, les ventes sont calculées à partir des commandes de la boutique et de leur statut de paiement, tandis que GA4 et les plateformes publicitaires fournissent en parallèle une répartition estimée par canal.

Avant de vous demander si c’est beaucoup, isolez les paiements à la livraison, les renouvellements et les commandes encore dans le délai de paiement. Seul ce qui reste peut être comparé à la norme et chiffré en euros.

Définition

Taux de commandes impayées : définition et formule

Le calcul suppose de trancher trois points au préalable : ce qui entre au dénominateur, à partir de quand une commande est considérée comme perdue et comment traiter le client qui a payé à la seconde tentative. Sans cela, la même boutique peut afficher 7,3 %, 8,0 % ou 6,4 %, et chacun de ces chiffres sera formellement exact.

Le taux en euros est plus élevé qu’en unités, car ce sont surtout les paniers chers qui ne sont pas payés. Dans la boutique d’électroménager, la commande moyenne à prépaiement est d’environ 160 €, contre environ 235 € pour une commande impayée. Le paiement en plusieurs fois, avec un panier de 370 €, représente à lui seul 30 des 88 commandes impayées (34 % des unités), mais 11 100 €, soit 54 % de la valeur impayée.

C’est pourquoi les décisions reposent sur la version nette en valeur. Les unités indiquent à quelle fréquence le processus de paiement échoue ; les euros indiquent combien cela coûte en trésorerie. L’écart entre les deux montre d’emblée que le problème se concentre sur les paniers élevés.

Correspondance entre les statuts de la boutique et les trois catégories du calcul (les noms de statuts varient selon les solutions e-commerce ; seul leur sens compte) :

Trois pièges faussent le résultat davantage que le processus de paiement lui-même :

1. Commandes des derniers jours comptées comme perdues

   Un virement bancaire classique est généralement crédité en 1–2 jours ouvrés : une commande du 30 septembre payée le 2 octobre semble perdue si le calcul est fait le 1er octobre. Une période de maturation de 7 jours et une évaluation de septembre le 8 octobre seulement suppriment cette fausse alerte.

2. Paiement à la livraison dans le dénominateur

   Le paiement à la livraison n’a pas de statut de prépaiement : 100 commandes de ce type pour 9 500 € diluent le résultat. 88 / 1 200 donne 7,3 % au lieu de 8,0 %, et 20 640 / 185 000 donne 11,2 % au lieu de 11,8 %. Les colis contre remboursement non retirés sont un autre problème, avec un calcul distinct.

3. Renouvellements comptés deux fois

   Le client dont le paiement a échoué passe souvent une seconde commande et la paie ; la première reste au statut impayé. Un renouvellement est une commande payée du même client (même order_customer_id ou email_hash) sous 2 jours : dans l’exemple, 18 commandes pour 2 360 €, qui ramènent la perte de 20 640 € à 18 280 €.

Ce calcul ne commence qu’après le clic sur « Commander ». Les abandons de panier et des étapes du tunnel de commande avant validation sont un autre problème, mesuré sur les sessions et les événements GA4 ; il est traité dans le guide sur le funnel de sessions et le tunnel de commande. Ici, le client a déjà saisi son adresse et choisi un moyen de paiement : chaque perte a donc dans la boutique un numéro de commande, un montant et un moyen de paiement.

Moyens de paiement

Taux normal d’impayés par moyen de paiement

La moyenne de 8,0 % pour l’ensemble de la boutique mélange des processus de nature totalement différente. BLIK se finalise en quelques secondes sur le téléphone du client, le virement classique attend la décision du client et la comptabilisation par la banque, le paiement en plusieurs fois attend la décision de crédit. Un taux commun indique seulement que, quelque part, des commandes n’aboutissent pas au paiement.

La norme par moyen de paiement correspond à la fourchette du taux d’impayés des trois derniers mois complets (ici juin–août), calculés avec la même définition : prépaiements uniquement, fenêtre de maturation de 7 jours, nouvelles tentatives déduites séparément. Le mois en cours se lit alors séparément pour chaque moyen : « dans la norme » ou « au-dessus de la norme ».

La moyenne de la boutique réagit aussi à la seule répartition des moyens de paiement. Quand la part du paiement en plusieurs fois augmente, le taux global de la boutique monte, alors qu’aucun processus de paiement n’est défaillant. La norme par moyen de paiement distingue un changement de mix d’une véritable panne.

Septembre dans une boutique d’électroménager, par moyen de paiement (données illustratives, évaluation au 8 octobre, fenêtre de 7 jours) :

Les mêmes chiffres présentés comme le choix de paiement que le client voit lors de la validation de sa commande : la bande grise sur l’échelle 0–30 % représente la norme propre au moyen de paiement, le repère indique septembre, et les vignettes signalées dépassent la norme.

Deux moyens de paiement dépassent leur propre norme : la carte et le virement classique. La carte affiche 5,0 % pour une norme de 3,0–4,0 %, mais cinq des neuf commandes impayées ont été réglées à nouveau par les mêmes clients dans les deux jours, d’où une perte nette de 600 €. Le virement classique affiche 26,3 % pour une norme de 18–22 % et aucune nouvelle tentative, soit 4 725 € de perte nette.

Le paiement en plusieurs fois reste dans la norme, mais représente 61 % de la valeur nette perdue (11 100 € sur 18 280 €). Un taux de 25,0 % avec un panier moyen de 370 € pèse plus en euros que les quatre autres moyens réunis (7 180 €). La norme indique que le processus fonctionne comme d’habitude ; le montant montre que cet « habituel » coûte le plus cher à la boutique.

Chaque moyen de paiement perd des paiements pour une raison différente, d’où des normes si éloignées :

• Paiement en plusieurs fois et paiement différé : la commande est créée avant la décision de crédit ; une partie des clients essuie un refus, d’autres abandonnent en cours de demande en découvrant le formulaire et les conditions.
• Virement classique : le client reçoit les coordonnées bancaires et remet le paiement à plus tard ; sans relance, la commande expire à l’échéance.
• Carte : l’autorisation échoue (plafond, vérification supplémentaire par la banque) et le client relance généralement l’achat aussitôt, d’où une part élevée de nouvelles tentatives.
• BLIK et virement instantané en ligne : le paiement se termine en quelques dizaines de secondes, les impayés sont donc surtout des abandons sur la page de la banque ou du prestataire de paiement.

La cause d’une transaction précise se trouve dans le tableau de bord du prestataire de paiement (motif du refus, étape d’interruption). Les données de commandes de la boutique montrent l’ampleur et l’endroit : quel moyen de paiement, combien de commandes, combien d’euros et si le résultat s’écarte de sa propre norme. L’ordre de travail est donc toujours le même : les données de la boutique désignent d’abord le moyen de paiement, puis le tableau de bord du prestataire en explique la cause.

Livraison et MER

Mode de livraison, commandes impayées et MER

Le taux d’impayés dépend aussi de ce que le client commande et de la façon dont il le fait. Le gros électroménager livré avec montée à l’étage n’a ni les mêmes paniers ni les mêmes moyens de paiement que le petit électroménager expédié en consigne automatique. La ventilation des 1 100 commandes prépayées par mode de livraison montre où les pertes dépassent la moyenne de la boutique.

La livraison avec montée à domicile s’écarte le plus parmi les grands groupes : 11,8 % contre une moyenne boutique de 8,0 %, soit près de 1,5× plus de commandes impayées. Il s’agit de commandes de gros électroménager aux paniers les plus élevés, et c’est justement pour elles que les clients choisissent le plus souvent le paiement en plusieurs fois et le virement bancaire classique, les moyens dont la norme d’impayés est la plus haute. La cause de chaque transaction se vérifie dans le back-office du prestataire de paiement ; les données de la boutique indiquent l’ampleur et le groupe de commandes où les pertes augmentent.

Les autres modes de livraison affichent 14,0 %, mais sur un échantillon de 50 commandes. Sept commandes impayées ne suffisent pas pour fixer une norme pour ce groupe : une telle ligne s’observe donc pendant plusieurs mois avant toute décision. Le transporteur (7,0 %), la consigne automatique (6,0 %) et le retrait en magasin (6,4 %) se situent au niveau de la moyenne de la boutique ou en dessous.

La même dépense donne deux résultats de budget différents :

L’écart de 12,6 % vient uniquement du moment où le chiffre d’affaires est comptabilisé. 88 commandes à paiement anticipé pour 20 640 € sont entrées dans le chiffre d’affaires avant le paiement, qui n’est jamais arrivé ; leur panier moyen est d’environ 235 € contre environ 160 € pour l’ensemble des prépaiements : ce sont donc surtout les commandes les plus chères qui restent impayées. Les campagnes n’ont pas changé d’un centime, seule la définition du chiffre d’affaires a changé.

Le même effet apparaît dans les plateformes publicitaires et dans GA4. Si l’événement d’achat se déclenche sur la page de remerciement avant que le client ait payé, la plateforme et GA4 comptent aussi une conversion pour une commande qui restera bloquée chez le prestataire de paiement. C’est pourquoi le résultat du budget global repose sur les commandes payées de la boutique (MER), le ROAS des canaux issu de GA4 et des plateformes se lit comme une estimation, et la couverture GA4 (nombre de transactions purchase dans GA4 divisé par le nombre de commandes de la boutique sur la même période) se calcule par rapport aux commandes de la boutique ; pour en savoir plus sur les pertes et les excédents de mesure, consultez le guide sur les conversions manquantes et le Consent Mode.

La répartition du résultat par canal et par campagne provient des plateformes publicitaires et de GA4. Au niveau de la campagne, on conserve la dépense et les conversions de la plateforme, comptées au moment où la commande est passée ; la campagne est le niveau le plus fin auquel il est utile de les lire. Une campagne qui s’écarte de sa norme (la dépense augmente, les conversions dans la plateforme non) est examinée en priorité, et le résultat du budget global se vérifie avec le MER calculé sur les commandes payées de la boutique.

Avant d’augmenter le budget, recalculez le MER sur les commandes payées de la boutique et comparez-le au MER sur les commandes passées. Le ROAS des canaux issu de GA4 et des plateformes sert alors d’estimation de la répartition, et c’est l’argent effectivement encaissé qui détermine le niveau du budget.

Matrice des corrections

Ordre des corrections : écart à la norme et montant

La liste des moyens de paiement avec leurs taux ne dit pas encore par où commencer. L’ordre se fixe avec deux chiffres à la fois : l’écart par rapport à sa propre norme (quelque chose a-t-il changé dans le processus de paiement ?) et la perte nette (combien cela coûte chaque mois). Le premier signale un dysfonctionnement à corriger, le second indique s’il vaut la peine de commencer par là.

La procédure comporte cinq étapes et s’appuie à chaque fois sur la même définition que dans les sections précédentes :

1. Calculer la perte nette par moyen de paiement

   Commandes impayées après la fenêtre de 7 jours, moins les commandes repassées et payées par le même client dans les 2 jours. En septembre : paiement en plusieurs fois 11 100 €, virement bancaire classique 4 725 €, virement instantané 1 120 €, BLIK 735 €, carte 600 € ; total 18 280 €.

2. Comparer le taux à sa propre norme

   La norme provient des trois mois précédents, calculés de façon identique. Deux moyens de paiement dépassent la limite haute : le virement bancaire classique (26,3 % pour une norme de 18–22 %) et la carte (5,0 % pour une norme de 3,0–4,0 %).

3. Placer le moyen de paiement dans la matrice

   Axe horizontal : dans la norme ou au-dessus. Axe vertical : montant de la perte nette ; le seuil s’adapte à la taille de la boutique, ici la séparation se situe autour de 2 500 € par mois.

4. Attribuer un type d’action

   Chaque quadrant correspond à un type de travail différent : corriger un dysfonctionnement, concevoir une nouvelle étape du processus, surveiller dans le back-office du prestataire de paiement ou simplement passer en revue chaque mois.

5. Mesurer l’effet sur le mois complet suivant

   Même définition : fenêtre de 7 jours, paiements à la livraison exclus du dénominateur, commandes repassées déduites. Modifier ne serait-ce qu’une exclusion fera apparaître une amélioration qui n’a pas eu lieu dans le processus.

Matrice de l’ordre des corrections (boutique d’électroménager, septembre, perte nette, données illustratives) :

À corriger maintenant : virement classique. Un taux de 26,3 % pour une norme de 18–22 % et 4 725 € perdus en net. Un écart par rapport à sa propre norme signifie que quelque chose a changé dans le processus : le contenu de la confirmation de commande avec les coordonnées bancaires, le délai de paiement ou une relance qui n’est plus envoyée avant l’annulation.

Refonte du processus : paiement en plusieurs fois. Le taux de 25,0 % reste dans la norme de 22–28 %, et pourtant 11 100 € représentent 61 % de la valeur nette perdue. Rien ne s’est cassé ici, l’amélioration passe donc par une nouvelle étape, par exemple contacter le client après un refus de crédit et lui proposer un autre moyen de paiement pour le même panier.

À surveiller : carte. Le taux de 5,0 % dépasse la norme de 3,0–4,0 %, mais 5 clients sur 9 ont repassé commande et payé, il reste donc 600 € en net. Le back-office du prestataire de paiement montrera si les échecs d’autorisation persistent les semaines suivantes.

Dans la norme : BLIK et virement rapide. Au total 1 855 € nets (735 € + 1 120 €) avec des taux dans les fourchettes de la norme. Ces moyens de paiement ne demandent qu’une revue mensuelle sur la même définition.

Le calcul des scénarios montre ce que vaut la première action :

• Virement classique de 26,3 % à 10 % : 10 % de 80 commandes, c’est 8 impayées au lieu de 21, soit 13 × 225 € = 2 925 € par mois.
• Paiement en plusieurs fois, récupération d’un tiers des commandes perdues : 10 × 370 € = 3 700 € par mois.
• Au total 6 625 € par mois, soit 36 % de la perte nette actuelle (6 625 € / 18 280 €).

En haute saison, l’enjeu augmente avec le volume. Avec un volume multiplié par 1,8, la perte nette atteint environ 32 900 € (18 280 € × 1,8) et le potentiel des corrections environ 11 925 € (6 625 € × 1,8). Il est donc rentable de corriger le virement classique avant le pic, et de lancer la refonte du paiement en plusieurs fois assez tôt pour mesurer l’effet sur un mois complet.

Des seuils de décision distinguent un défaut de processus d’une panne. Un moyen de paiement au-dessus de la limite haute de sa propre norme pendant deux semaines complètes consécutives passe au diagnostic selon la matrice. Une hausse soudaine des commandes en attente sur une seule journée, par exemple après une panne de paiement chez le prestataire, est une panne à repérer le lendemain matin dans le suivi quotidien des anomalies ; son heure et sa cause sont visibles dans le back-office du prestataire de paiement.

L’ordre des corrections dépend de deux chiffres : l’écart du moyen de paiement par rapport à sa propre norme et le montant net perdu. Le moyen au-dessus de la norme avec un montant élevé passe en premier, car quelque chose a changé dans son processus et ce changement peut être annulé.

DataOrganizer

Les commandes impayées dans le chat DataOrganizer

Tout le calcul des sections précédentes repose sur une seule table : les commandes de la boutique avec leur statut. DataOrganizer les récupère via les API officielles de la boutique, avec les champs nécessaires à la norme : order_status, order_payment_method, order_grand_total_amount, order_date_created ainsi que order_customer_id et email_hash pour repérer les commandes repassées. Les coûts des plateformes publicitaires sont au même endroit, ce qui permet de calculer le MER sur les commandes payées (chiffre d’affaires payé de la boutique / dépense totale), la répartition par canal selon GA4 ou les interfaces publicitaires servant d’estimation.

Les données sont actualisées une fois par jour et contiennent le matin l’intégralité de la veille. Le taux d’impayés peut ainsi se lire à deux niveaux : la journée comparée au profil du même jour de la semaine (mardi contre les mardis précédents) et le mois complet, après la fenêtre de maturation, comparé à sa propre norme par moyen de paiement. La cause d’une transaction isolée (refus bancaire, demande de crédit interrompue) reste dans le back-office du prestataire de paiement ; les données de la boutique montrent l’ampleur du problème et l’endroit où il s’aggrave.

La revue mensuelle après clôture de la fenêtre de 7 jours se présente ainsi (boutique d’électroménager, septembre, données indicatives) :

Au fil du mois, la même conversation devient plus courte. Le matin, on peut demander si le taux d’impayés de la veille pour un moyen de paiement donné correspond au profil habituel de ce jour de la semaine. Un pic soudain signale une panne, que confirme le back-office du prestataire de paiement ; un écart modéré ne se confirme qu’au deuxième jour. Le verdict complet par rapport à la norme tombe après la clôture de la fenêtre de maturation, lorsque les virements classiques ont eu le temps d’être crédités.

La connexion de la boutique, des plateformes publicitaires et de GA4 se fait en autonomie, sans développeur. Vous payez les sources connectées ; les tarifs en vigueur figurent sur la page des prix. Dès la première actualisation, les statuts des commandes, les moyens de paiement et les coûts des campagnes sont réunis au même endroit : le tableau des normes sur les trois mois précédents se calcule à partir de l’historique, et non d’exports manuels depuis l’administration de la boutique.

Note méthodologique : les chiffres des exemples sont illustratifs. Septembre est évalué le 8 octobre (fenêtre de maturation de 7 jours), les paiements à la livraison sont exclus du dénominateur et traités comme une catégorie à part, et une nouvelle tentative désigne une commande payée par le même client dans les 2 jours. DataOrganizer ne dispose pas des données sur les retours ni sur les refus de colis, le calcul s’arrête donc au paiement. Après un changement de prestataire de paiement ou l’ajout d’un nouveau moyen de paiement, les normes sont recalculées à partir de la date du changement.

Note méthodologique : les chiffres des exemples (boutique d’électroménager, septembre, évaluation le 8 octobre) sont illustratifs et servent uniquement à montrer le calcul. Le taux se calcule après une fenêtre de maturation de 7 jours, sans les paiements à la livraison au dénominateur et après déduction des nouvelles tentatives du même client. Les données de la boutique n’incluent ni les retours ni les refus de colis, et après un changement de prestataire de paiement, la norme est recalculée.

FAQ

Questions fréquentes sur les commandes impayées

Quel taux de commandes impayées est normal pour une boutique en ligne ?

Il n’existe pas de valeur unique pour toutes les boutiques, car chaque moyen de paiement a sa propre nature : dans la boutique d’électroménager de l’exemple, la norme du paiement mobile instantané est de 2,5–3,5 %, celle du paiement en plusieurs fois de 22–28 %. Votre propre norme se détermine par moyen de paiement sur les trois derniers mois complets, en ne comptant que les prépaiements plus anciens que la fenêtre de maturation et en déduisant les nouvelles tentatives du même client. La moyenne de la boutique (ici 8,0 % en nombre et 11,8 % en valeur) varie avec le mix des moyens de paiement : à elle seule, elle ne dit pas si quelque chose s’est cassé.

Pourquoi des clients passent-ils commande sans payer ?

Le mécanisme dépend du moyen de paiement : pour le paiement en plusieurs fois, le client abandonne pendant la demande ou essuie un refus ; pour le virement classique, il reporte le paiement ; pour la carte, l’autorisation échoue et se solde souvent par une nouvelle tentative rapide. Les gros paniers restent plus souvent impayés, comme le montre le taux plus élevé pour la livraison avec installation du gros électroménager (11,8 % pour une moyenne de 8,0 %). Les données de la boutique montrent l’ampleur et la localisation du problème ; la cause d’une transaction précise se trouve dans le back-office du prestataire de paiement.

Au bout de combien de jours annuler une commande impayée ?

Le délai d’annulation découle des conditions générales de la boutique et du moyen de paiement. Un virement classique est généralement crédité en 1–2 jours ouvrés : un délai trop court annule donc des commandes qui auraient encore été payées. Pour l’analyse, on retient une fenêtre de maturation calée sur le moyen de paiement le plus lent (7 jours dans l’exemple), et ce n’est qu’après celle-ci qu’une commande sans paiement est comptée comme impayée. Avant d’annuler, mieux vaut envoyer une relance avec les informations de paiement : c’est le moyen le moins coûteux de récupérer une partie du montant.

Faut-il compter les commandes impayées dans le chiffre d’affaires et le ROAS ?

Non : le chiffre d’affaires et le MER se calculent à partir des commandes payées de la boutique, les commandes passées pouvant être suivies à part comme signal de demande. Dans l’exemple, le MER s’établit à 9,25 sur les commandes passées et à 8,22 sur les commandes payées : compter avant le paiement surestime le résultat de 12,6 %. Si l’événement d’achat se déclenche sur la page de remerciement avant le paiement, les plateformes publicitaires et GA4 comptent aussi les commandes impayées, et leur ROAS doit alors être lu comme une estimation (plus de détails dans le guide sur les conversions manquantes).

Comment suivre les commandes impayées par moyen de paiement dans DataOrganizer ?

DataOrganizer récupère les commandes de la boutique avec leur statut, leur moyen de paiement, leur montant, leur date et l’identifiant client haché, et actualise les données une fois par jour avec l’intégralité de la veille. Dans le chat, il suffit de demander les prépaiements impayés par moyen de paiement par rapport à la norme des trois derniers mois, hors paiements à la livraison et après déduction des nouvelles tentatives : l’assistant renvoie un tableau avec le taux, le montant perdu net et le MER calculé sur les commandes payées. Un pic soudain de commandes en attente sur une journée ressort dans le récapitulatif du matin par rapport au profil du jour de la semaine, comme le décrit le guide sur le monitoring et les anomalies.