Une alerte utile n'est pas un bruit de plus dans Slack. Elle dit quelle boutique est touchée, quelle étape de vente est concernée, si le revenu est probablement bloqué et quoi vérifier maintenant. Elle garde une preuve partageable et elle évite les suppositions.
Pour une agence WooCommerce, ce cadrage change tout. Un client ne veut pas recevoir une suite de signaux techniques : il veut savoir si sa boutique vend encore, si le panier tient, si le checkout affiche les moyens de paiement, si la panne vient du cache, du thème, d'un plugin ou d'une passerelle, et surtout qui agit et quand.
Ce guide pose une méthode simple. Il part du principe qu'une agence gère plusieurs boutiques, que chacune a des contraintes différentes, et qu'il faut distinguer les alertes qui réveillent une équipe, celles qui nourrissent un rapport et celles qui doivent lancer une intervention IA sur plan payant. Il garde les données client hors du bruit opérationnel et il respecte une idée centrale : une alerte ne vaut rien si elle ne produit pas une décision.
1. Premier séparateur : disponibilité ou conversion
Un site peut être disponible et ne plus vendre. Un ping HTTP peut répondre 200, la page d'accueil peut charger, le catalogue peut rester visible, et pourtant le bouton « ajouter au panier » n'agit plus, le panier se vide, le checkout affiche une erreur JavaScript, un paiement carte disparaît, un portefeuille de paiement reste actif dans WooCommerce mais absent côté client, un champ obligatoire bloque la commande, une redirection 3DS échoue ou une confirmation n'apparaît jamais.
L'agence doit donc séparer deux familles d'alertes. La première concerne la disponibilité générale : elle dit si une page répond, si le serveur est lent, si une route retourne une erreur. La seconde concerne la conversion : elle dit si un utilisateur peut avancer vers l'achat, si les étapes critiques tiennent ensemble, si le revenu est menacé.
CashFlowCanary se place dans cette seconde famille. Le cockpit client doit répondre à une question courte : peut-on vendre maintenant ?
2. Ne pas alerter toutes les pages de la même façon
Une fiche produit importante mérite un signal rapide ; une page de catégorie secondaire peut attendre. Le panier mérite une priorité plus haute, le checkout la priorité maximale. La page de confirmation demande une lecture différente : elle prouve que la fin du parcours tient. Les pages « compte client » et « contact » n'ont pas le même impact direct ni la même urgence.
L'agence doit donc cartographier les pages par impact : faible, moyen, fort, critique. Le mot « critique » doit rester réservé ; utilisé partout, il ne signifie plus rien.
Une bonne alerte commence par un classement : quel monitor observe la rupture, quel chemin est touché, quel plan client couvre ce chemin, quelle fréquence est promise, quel canal doit être activé, quel rapport sera produit.
3. Choisir les canaux selon le type de décision
L'e-mail est utile pour tracer, archiver et transmettre au client ; il est moins bon pour réveiller une équipe en temps réel. Slack sert à coordonner une équipe : il donne un fil de discussion et permet de taguer un responsable, mais il devient bruyant si tout arrive au même endroit. Telegram est direct et efficace sur mobile pour les alertes rapides, à condition de le réserver aux signaux qui méritent l'attention. WhatsApp est utile quand le client ou l'équipe vit déjà dans ce canal ; il doit être configuré proprement et ne jamais servir à du démarchage sans opt-in.
Le bon choix n'est pas unique. Une agence peut utiliser l'e-mail pour la preuve, Slack pour l'équipe technique, Telegram pour l'astreinte et WhatsApp pour certains clients premium. Le même incident peut donc générer plusieurs notifications, mais chacune doit avoir une raison.
4. Définir une politique par plan
Le plan gratuit valide un signal. Il ne doit pas promettre une intervention complète, ni tous les canaux, ni l'intervention IA. Le plan payant change le niveau d'engagement : il peut ouvrir les alertes multi-canal, l'historique plus long, les rapports PDF avancés et l'intervention IA.
Cette distinction doit apparaître dans le produit, le site, le plugin, les rapports et les alertes. Un canal hors plan, non configuré, suspendu ou livré par le serveur mais non choisi ne doit jamais être présenté comme actif.
Les mots comptent. « Actif » veut dire qu'une alerte partira. « Non configuré » veut dire qu'il manque une destination. « Hors plan » veut dire que l'offre ne le permet pas. « Livraison non prête » veut dire que la destination existe mais que le serveur ne peut pas encore livrer. Cette précision évite les discussions inutiles.
5. Rédiger une fiche d'alerte lisible
Une alerte doit tenir en quelques champs : nom du site, chemin touché, type de monitor, statut observé, code d'erreur, heure d'ouverture, impact probable, preuve disponible, action recommandée, prochaine vérification.
Le message ne doit pas être un dump brut. Il ne doit pas contenir de données personnelles inutiles, ni exposer un panier, un e-mail client ou un jeton. Il doit orienter l'équipe.
Un bon message Slack peut tenir en six lignes : « Boutique A — checkout bloqué, moyen de paiement absent, priorité critique, preuve PDF disponible, recontrôle dans trois minutes, intervention IA lancée si le plan le permet. » Ce message suffit à agir ; le détail technique reste dans le rapport.
6. Relier l'alerte au rapport
Une alerte est instantanée, un rapport est durable. L'une déclenche l'action, l'autre garde la trace. L'agence doit relier les deux : chaque alerte critique pointe vers une preuve, chaque preuve rappelle le contexte, chaque rapport liste les monitors concernés et explique les incidents avec précision, sans descriptions copiées-collées. Chaque intervention IA détaille ce qui a été tenté, de façon spécifique au monitor.
Un rapport qui répète la même phrase partout n'est pas un rapport, c'est du bruit mis en PDF. Le rapport doit aider un développeur, un chef de projet et le client à comprendre. Il ne doit pas masquer les monitors en échec, afficher un health score parfait quand des monitors cassent, cacher les canaux non configurés ni remplacer une preuve par un slogan.
7. Prioriser sans dramatiser
Tout incident n'est pas une crise. Un timeout ponctuel peut être observé, une page lente peut être suivie. En revanche, un checkout qui ne charge plus, un panier qui se vide, une passerelle absente ou un bouton de paiement bloqué sont des urgences. Une confirmation manquante est une alerte forte, mais elle se lit après le contexte.
L'agence doit donc utiliser des niveaux : information, à surveiller, dégradé, critique, résolu. Chaque niveau a une conséquence. « Information » ne réveille personne. « À surveiller » nourrit le rapport. « Dégradé » va dans le canal équipe. « Critique » déclenche les canaux temps réel. « Résolu » ferme la boucle. Sans conséquence, un niveau ne sert à rien.
8. Éviter les faux positifs visibles côté client
Un faux positif coûte de la confiance, et il coûte plus cher quand il arrive chez le client final. Il faut donc filtrer avant l'escalade. Un incident se confirme en croisant plusieurs signaux : code HTTP, extrait de page, absence d'un élément attendu, temps de chargement anormal, état du dernier run, comparaison avec le run précédent, présence d'un incident déjà ouvert.
Le système ne doit pas ouvrir dix incidents identiques : il regroupe ce qui appartient au même symptôme, ferme proprement quand le recontrôle réussit, garde une chronologie et dit ce qui a changé. Le client ne doit pas recevoir une alerte verte qui contredit une alerte rouge ; le cockpit doit rester cohérent.
9. Configurer les alertes par site client
Une agence ne gère pas un seul canal global, elle gère des portefeuilles. Un client premium peut exiger WhatsApp, un client standard rester sur l'e-mail, une équipe interne travailler dans Slack, un prestataire externe suivre Telegram. Le canal doit donc vivre au niveau du site surveillé.
Chaque site doit afficher l'e-mail, Slack, Telegram, WhatsApp et l'escalade, avec pour chaque ligne un statut « actif » ou « non actif », et toute destination contenant une donnée sensible doit être masquée.
Le bouton de test doit être clair : il envoie un message de vérification, sans créer d'incident, sans relancer un monitoring et sans modifier la boutique. Le test de canal est un test de livraison, pas un test de panne.
10. Conclusion opérationnelle
Une alerte utile ne crie pas plus fort que les autres. Elle relie le bon site, le bon canal, le bon impact et la bonne preuve. Elle garde l'agence responsable de la décision plutôt que prisonnière du bruit. Elle ne lance l'intervention IA que lorsque le plan et les garde-fous le permettent, et elle confirme la résolution avant de rassurer le client, selon les limites visibles sur les tarifs.
Pour voir le niveau de preuve attendu côté client, consultez l'exemple de rapport PDF. C'est cette discipline qu'une agence peut cadrer avec un audit gratuit avant d'industrialiser ses alertes.