Prioriser les alertes quand plusieurs boutiques cassent

Priorisez d'abord ce qui empêche de vendre maintenant : checkout cassé, panier vidé, paiement absent ou confirmation impossible. Ensuite seulement viennent les lenteurs, signaux transitoires et anomalies qui demandent surveillance mais pas interruption immédiate.

Le même incident n'a pas le même poids sur tous les clients. Combinez trafic, panier moyen, saisonnalité, campagnes en cours et criticité contractuelle. Une boutique sous acquisition payante avec checkout cassé doit passer devant une page produit lente sur un site peu actif.

Un signal qui revient seul n'est pas forcément faux. Il peut être un incident bref. Le faux positif se prouve par une limite du test : sélecteur fragile, produit de test indisponible, attente trop courte ou règle métier volontaire. La panne persistante, elle, reste reproductible.

Une bonne alerte indique le site, l'étape, l'heure, le signal attendu, le signal observé et la première piste. Sans cette preuve, l'agence transforme une file d'incidents en bruit opérationnel.

Le développeur a besoin de l'étape et du signal technique. Le chef de projet a besoin de l'impact et de la prochaine action. Le client a besoin d'une synthèse claire et d'un statut de récupération. Les canaux email, Slack, Telegram, WhatsApp et escalade doivent suivre ces publics.

Si trois alertes arrivent ensemble, traitez d'abord le site avec paiement absent et trafic actif, puis le panier vidé intermittent, puis la page produit lente. Le rapport final doit montrer pourquoi cet ordre protège le plus de revenu.

Une alerte critique ne se ferme pas parce qu'elle a cessé de sonner. Elle se ferme quand le parcours qui a échoué repasse au vert avec le même monitor, une preuve de récupération et une action documentée si une intervention a été nécessaire.