Le trafic a décroché il y a onze jours. Vous l'apprenez ce matin, parce qu'un client a regardé son tableau de bord avant vous. Entre les deux, personne n'a rien vu : le rapport mensuel n'était pas encore sorti, et le graphique existait pourtant, sur un écran que plus personne n'ouvre.
Les alertes automatiques de performance corrigent exactement ça. Le principe tient en une phrase : au lieu d'aller regarder les indicateurs, on se fait prévenir quand l'un d'eux sort de sa plage normale. Reste à savoir quelles métriques méritent ce traitement, comment fixer un seuil qui ne déclenche ni trop ni trop tard, et comment monter le workflow qui envoie le message à la bonne personne.
Une alerte n'est pas un tableau de bord
Trois objets se confondent en permanence, et ils ne servent pas au même moment.
Le tableau de bord répond à une question qu'on se pose. On l'ouvre parce qu'on veut savoir. Il suppose une intention, donc quelqu'un de disponible.
Le rapport arrive à date fixe et documente une période close. C'est l'outil du bilan, pas celui de la réaction — le sujet est traité en détail dans notre guide sur le reporting client automatisé.
L'alerte part sans qu'on ait rien demandé, parce qu'une condition est devenue vraie. C'est le seul des trois qui fonctionne quand personne ne regarde.
La conséquence est directe : une alerte qui se contente de répéter un chiffre à heure fixe est un rapport déguisé. Une vraie alerte affirme que quelque chose est anormal, et demande une décision.
Les trois formes de détection
Un seuil, c'est déjà trois mécaniques différentes. Choisir la mauvaise explique la plupart des systèmes d'alerte abandonnés au bout d'un mois.
Le seuil fixe. La valeur passe sous 95 %, au-dessus de deux secondes, sous quarante leads. Simple à écrire, adapté à tout ce qui a une valeur cible contractuelle ou technique.
L'écart relatif. La valeur du jour comparée à la même journée des semaines précédentes. Indispensable dès que la métrique a un rythme : un lundi ne se compare pas à un dimanche, et beaucoup de sites B2B font la moitié de leur trafic habituel en août.
L'absence de signal. Aucune commande depuis six heures, aucun formulaire depuis hier, plus aucune exécution du workflow. C'est la famille qu'on oublie, et c'est souvent celle qui détecte les vraies pannes. Un compteur tombé à zéro ne franchit aucun seuil vers le haut : il arrête simplement d'exister, et un système qui ne surveille que des dépassements ne verra jamais rien.
Les métriques qui valent une alerte
Une métrique mérite une alerte à trois conditions : on sait ce que serait une valeur anormale, quelqu'un peut agir dessus dans la journée, et ne rien faire coûte quelque chose. Si l'une des trois manque, laissez-la au tableau de bord.
Acquisition et conversion
Le trafic organique, le nombre de formulaires remplis, le taux de conversion, le coût par lead. Ce sont les métriques les plus lentes à se dégrader et les plus coûteuses à découvrir en retard : une balise de suivi cassée pendant trois semaines, ce sont trois semaines de décisions prises sur des données fausses.
Le piège ici est le volume. Sur une page qui reçoit quarante visites par jour, une variation de 30 % ne veut rien dire. Ajoutez toujours une condition de volume minimum avant de comparer des pourcentages, sinon vous alerterez sur du bruit statistique.
Disponibilité et temps de réponse
Le taux de disponibilité, le temps de réponse d'une page ou d'une API, le taux d'erreurs. Ce sont les métriques les plus faciles à alerter correctement, parce qu'elles ont une valeur normale stable et une valeur anormale évidente.
Un réflexe à prendre : surveillez le temps de réponse au percentile, pas à la moyenne. Une moyenne à 400 millisecondes peut cacher une part d'utilisateurs à huit secondes, et ce sont précisément ceux qui partent.
Engagement de service
Le délai de première réponse au support, le nombre de tickets ouverts depuis plus de N jours, le respect d'un engagement contractuel. Ici, le seuil n'est pas à inventer : il est écrit dans le contrat. La seule règle à retenir est que l'alerte doit partir avant l'échéance, pas au moment où elle est dépassée. Un SLA à quatre heures s'alerte à trois : passé le délai, l'information ne sert plus qu'à constater.
Coût
Le budget publicitaire consommé, la facture d'API, la consommation de tokens d'un agent. Cette famille a une particularité : elle ne dérive jamais lentement. Une boucle mal écrite ou une enchère mal plafonnée produit un écart d'un facteur dix en une nuit, pendant que tout le monde dort. C'est la seule famille où une vérification horaire se justifie dès le premier jour.
Livraison et charge d'équipe
La dérive de planning, le dépassement budgétaire d'un projet, la surcharge d'une personne, une tâche bloquée depuis deux jours. Ces alertes-là ne se lisent pas sur une métrique unique : elles se construisent en croisant deux chiffres.
Le principe est toujours le même — comparer une consommation à un avancement. Une tâche qui a consommé 80 % de son temps alloué pour 50 % du travail livré est en dérive, même si sa date d'échéance n'est pas encore passée. Un projet qui a brûlé 80 % de son enveloppe pour 60 % de ses livrables aussi. Une personne affectée au-delà de sa capacité deux semaines de suite également, à condition d'avoir déduit ses congés du calcul : sans ça, l'alerte partira tous les étés pour rien.
Ces croisements sont les plus utiles du lot et les plus longs à monter, parce que les deux chiffres vivent rarement dans le même outil. Une alerte de dépassement budgétaire doit aussi distinguer l'engagé du décaissé — une facture reçue mais pas encore payée compte déjà.
Fixer le seuil sans se faire spammer
C'est ici que les systèmes d'alerte meurent. Pas au montage : à la troisième semaine, le jour où le destinataire crée une règle de filtrage dans sa boîte mail.
Partez de l'historique, pas de l'intuition. Rejouez votre règle sur les trois derniers mois de données avant de l'activer. Si elle aurait déclenché quarante fois, elle est fausse. Si elle n'aurait jamais déclenché, elle est fausse aussi. Un bon seuil produit quelques déclenchements sur la période, et vous devez pouvoir dire, pour chacun, ce que vous auriez fait ce jour-là.
Exigez une durée, pas un instant. Une valeur qui franchit le seuil pendant une minute ne justifie rien. Demandez que la condition reste vraie sur une fenêtre : trois relevés consécutifs, ou une moyenne sur quinze minutes. La quasi-totalité des faux positifs disparaît avec cette seule règle.
Prévoyez la sortie d'alerte. Une règle qui se déclenche à 95 % ne doit pas se considérer résolue à 95,1 %, sinon vous recevrez le même message toute la journée pendant que la valeur oscille autour du seuil. Faites redescendre l'état à une valeur nettement en deçà du seuil de déclenchement.
Une alerte, un destinataire nommé. Pas un canal d'équipe où chacun suppose que quelqu'un d'autre s'en occupe. Si vous ne savez pas qui doit recevoir le message et sous quel délai il doit agir, la règle n'est pas prête à être activée.
Trois niveaux suffisent. Ce qui réveille quelqu'un la nuit, ce qui doit être vu dans la journée, ce qui se regarde le lundi matin. Une alerte de niveau bas n'a rien à faire dans le même canal qu'une alerte de niveau haut : le mélange détruit la valeur des deux.
Le test de survie est simple. Si vous n'avez rien fait des trois derniers déclenchements d'une règle, supprimez-la. Elle ne vous informe pas, elle vous entraîne à ignorer vos alertes.
Le montage n8n qui envoie l'alerte au bon endroit
Un système d'alerte tient en cinq étapes, et aucune n'est difficile. Ce qui coûte du temps, c'est la quatrième — et c'est celle qu'on saute.
1. Un déclencheur planifié. Toutes les cinq minutes pour de la disponibilité, toutes les heures pour du coût, une fois par jour pour de l'acquisition. Inutile d'interroger une API d'analytics toutes les cinq minutes : elle ne se met pas à jour à ce rythme, et vous payez l'appel.
2. La collecte. Un appel HTTP vers l'API de la source, ou le connecteur dédié quand il existe. Une seule source par workflow au début. Un workflow qui interroge six outils tombe dès que l'un des six change son format de réponse, et vous ne saurez pas lequel.
3. Le calcul. C'est là qu'on compare à la référence. Pour un seuil fixe, une condition suffit. Pour un écart relatif, il faut la valeur passée, donc une base : une table Postgres avec une ligne par relevé, ou une feuille de calcul si le volume est faible. Chaque exécution écrit sa mesure et lit les précédentes.
4. L'état. L'étape qui décide si le système sera adopté ou désactivé. Le workflow doit se souvenir qu'il a déjà envoyé cette alerte. Une table à trois colonnes suffit : identifiant de règle, état courant, date du dernier envoi. On n'envoie un message que sur un changement d'état — du normal vers l'anormal, puis du retour à la normale. Sans cette table, un incident de deux heures surveillé toutes les cinq minutes produit vingt-quatre messages identiques, et c'est ainsi qu'on perd un destinataire.
5. Le routage. Une condition qui oriente selon la gravité : le canal Slack de l'équipe, un message direct, un e-mail pour la trace, la création d'un ticket pour ce qui demande un suivi. Le même workflow porte les trois niveaux, ils ne diffèrent que par la branche de sortie.
Si vous découvrez l'outil, notre formation n8n couvre les briques utilisées ici. Le même montage s'écrit avec Make ou en code : la logique ne change pas, seule la syntaxe bouge.
Un détail qui n'en est pas un : surveillez le surveillant. Un workflow d'alerte qui plante cesse d'envoyer des alertes, et ce silence ressemble exactement au bon fonctionnement. Ajoutez une vérification qui contrôle que le workflow a bien tourné, et faites-la porter par un autre système que celui qu'elle surveille.
Ce que doit contenir le message
Une alerte utile tient en cinq lignes et répond à quatre questions.
- Quoi : la métrique, sa valeur, le seuil franchi. « Taux de conversion à 1,2 % contre 2,8 % attendus », et non « anomalie détectée ».
- Depuis quand : l'heure du franchissement, pas celle de l'envoi.
- Où : le système, le client, la campagne ou la page concernée.
- Et maintenant : un lien qui ouvre directement le graphique ou le journal correspondant.
Ajoutez-y ce que le workflow sait déjà : la valeur de la semaine précédente, la dernière fois que la règle s'est déclenchée. Chaque information qui évite au destinataire d'aller la chercher augmente la probabilité qu'il traite l'alerte au lieu de la reporter.
Ce qui n'a rien à faire dans le message : le nom du workflow, l'identifiant d'exécution, et la phrase « ceci est une alerte automatique ». Tout le monde l'a compris.
Les erreurs qui rendent le système inutile
Tout alerter dès le premier jour. Deux règles en production valent mieux que vingt en préparation. Ajoutez la suivante quand la précédente a déclenché au moins une fois à bon escient.
Alerter sur ce qu'on ne peut pas corriger. Une baisse du volume de recherche sur votre marché n'appelle aucune action dans l'heure. Elle appartient au rapport mensuel, pas à un canal Slack.
Confondre le seuil et l'objectif. Un objectif commercial à cent leads par mois ne fait pas un seuil d'alerte à cent. Le seuil se place là où la situation devient anormale, pas là où elle devient insuffisante — sinon l'alerte est allumée en permanence et ne signale plus rien.
Ne jamais relire ses règles. Un seuil calibré sur le trafic d'il y a un an est faux aujourd'hui. Une revue trimestrielle — combien de déclenchements, combien d'actions réelles derrière — suffit à garder le système vivant.
Oublier la fin de l'incident. Un destinataire qui reçoit l'alerte mais jamais le retour à la normale finit par aller vérifier à la main à chaque fois. Vous avez recréé le travail que vous vouliez supprimer.
Par où commencer cette semaine
Prenez la dernière fois où vous avez découvert un problème trop tard. Écrivez la métrique qui aurait dû vous prévenir, et la valeur qu'elle affichait ce jour-là. Vous tenez votre première règle, et son seuil.
Montez-la sur une seule source, puis laissez-la tourner deux semaines sans destinataire : le workflow écrit dans une table, personne ne reçoit rien. Comptez les déclenchements et regardez ce que vous auriez fait de chacun. S'ils sont exploitables, branchez l'envoi du message. Sinon, corrigez le seuil avant d'avoir grillé la patience de qui que ce soit.
La même discipline s'applique au reste de la chaîne : une alerte de conformité ou de sécurité obéit aux mêmes règles de seuil et de destinataire, comme détaillé dans notre article sur l'automatisation du reporting de conformité.
Cadrer ces règles avec vos équipes — quelles métriques, quels seuils, qui reçoit quoi — est le travail que fait notre agence d'automatisation avant d'ouvrir le moindre workflow.
