Notifications par email : bonnes pratiques et exemple
Pourquoi les notifications par email restent indispensables
Les notifications par email restent un mécanisme fondamental dans la supervision et la gestion des infrastructures IT. Malgré la multiplication de solutions de messagerie instantanée, de plateformes collaboratives ou de systèmes d’alerting intégrés, l’email demeure un canal fiable, standardisé et universel. Dans un contexte de monitoring, il permet de transmettre des informations critiques ou contextuelles sans dépendre d’un outil tiers, tout en offrant une traçabilité complète.
Avec ServicePilot, la configuration des notifications par email s’intègre directement dans les workflows d’alerting, automatisant ainsi la diffusion d’informations pertinentes vers les équipes opérationnelles, les administrateurs ou les responsables applicatifs. Qu’il s’agisse d’alerter sur une panne ou d’informer d’un changement d’état, un email bien conçu peut faire gagner un temps précieux aux équipes opérationnelles.
En dépit de l'émergence de nombreux canaux de communication alternatifs, l’email conserve plusieurs avantages :
- Universalité : aucune dépendance à un outil tiers ou à une application spécifique
- Traçabilité : les emails peuvent être archivés, transférés, recherchés
- Fiabilité : les serveurs SMTP sont robustes et largement supportés
- Flexibilité : possibilité de modifier le contenu et la forme
Dans cet article, nous explorons les bonnes pratiques pour créer des notifications efficaces, ainsi qu'un exemple concret applicable dans ServicePilot.
Bonnes pratiques pour créer des notifications efficaces
Définir clairement l’objectif de la notification
Une notification n’a de valeur que si son destinataire comprend immédiatement ce qu’il doit en faire. Dans un contexte technique, cela implique de distinguer les alertes nécessitant une action immédiate des informations destinées à enrichir la compréhension globale du système.
Les meilleures notifications email ne se déclenchent que lorsqu'un humain doit réellement intervenir. Elles doivent être :
- Rares
- Urgentes
- Importantes
- Actionnables
Ainsi, lors de la mise en place de notifications par email, un point essentiel consiste à sélectionner avec précision les types d’alertes qui méritent réellement d’être diffusées. Toutes les informations disponibles ne nécessitent pas forcément une notification, il s’agit donc d’identifier les incidents critiques afin de ne pas noyer les destinataires sous un flot inutile.
ServicePilot propose une sélection granulaire des évènements sur lesquels générer une alerte : dépassements de seuils sur des métriques, changements d’états, ciblage d'un périmètre particulier (vues, ressources ou objets), messages syslog ou Traps SNMP, requête dans la base de données ServicePilot, etc.
Définir des périmètres spécifiques permet également de cibler les bonnes équipes, de réduire le volume global d’emails et de concentrer l’attention sur les incidents qui nécessitent une action. Cette sélection fine améliore non seulement la pertinence des alertes, mais aussi la réactivité opérationnelle tout en réduisant la fatigue d'alerte.
Utiliser un objet court et explicite
L’objet de l’email est souvent le seul élément lu dans un premier temps, surtout lorsqu’un technicien consulte ses alertes sur mobile. Il doit être court et précis. Il peut contenir les informations essentielles : la nature de l’événement, la ressource concernée et éventuellement le niveau de criticité. Dans ServicePilot, il est possible d’inclure des variables dynamiques dans l’objet pour insérer automatiquement le nom du service, la valeur de la métrique ou le statut détecté. Cette personnalisation améliore considérablement la lisibilité et réduit le temps nécessaire pour identifier la source du problème.
Structurer le contenu pour une lecture rapide
Même si l’email peut contenir beaucoup d’informations, il doit rester lisible en un coup d'oeil. Le message doit présenter l’événement déclencheur, la métrique concernée et l’heure exacte de détection. ServicePilot permet d’intégrer automatiquement ces données grâce aux variables d’alerte, ce qui garantit une cohérence entre le contenu de l’email et les informations visibles dans l’interface de supervision.
Quelques règles simples :
- Commencer par l’information critique
- Utiliser des sections courtes
- Mettre en avant les données clés (statuts, métriques, timestamps)
Ajouter du contexte pour faciliter le diagnostic
Une alerte isolée peut être difficile à interpréter. En ajoutant du contexte, on réduit le risque de faux positifs et on améliore la capacité de l’équipe à diagnostiquer rapidement la cause du problème.
Par exemple, une alerte sur une métrique d'un objet peut être accompagnée d’un lien vers l'interface ServicePilot avec le graphique correspondant, d'un lien vers le bac à évènements pour rapidement vérifier les événements survenus dans les dernières minutes ou d'un lien vers la cartographie pour vérifier les dépendances et les impacts que l'incident peut engendrer.
Soigner le design HTML pour améliorer la lisibilité et l’adoption
Un email bien structuré visuellement augmente significativement l’efficacité des notifications, car il facilite la lecture, réduit la charge cognitive et renforce la crédibilité de l’outil qui l’envoie. Dans un contexte de supervision, où les équipes reçoivent parfois des dizaines d’alertes par jour, un design HTML clair et cohérent permet de distinguer immédiatement les informations essentielles. L’utilisation d’un en-tête identifiable, de couleurs cohérentes avec la charte graphique de l’entreprise et d’un code couleur pour les niveaux de criticité (par exemple rouge pour les alertes critiques, orange pour les avertissements, etc.) améliore la compréhension instantanée du message.
Sur le plan technique, il est recommandé d’utiliser un HTML simple et compatible avec la majorité des clients email : tableaux pour la mise en page, styles inline pour éviter les problèmes de rendu et un fallback texte pour les environnements restrictifs. ServicePilot permet d’intégrer ce type de template directement dans les notifications, ce qui garantit une uniformité visuelle entre les différentes alertes. Un email bien présenté contribue également à l’adoption de l’outil car il donne une impression de professionnalisme tout en rendant les alertes plus agréables à consulter. À long terme, cela réduit le risque de “fatigue d’alerte” et encourage les équipes à rester attentives aux notifications reçues.
Exemple de notification email avec ServicePilot
Dans cet exemple, nous générons une notification email grâce à une Policy d'Alerte ciblant les ressources indisponibles. Nous choisissons le passage de n'importe quel statut vers un statut rouge (indisponibilité), sur une période d'heures ouvrées et pour toutes les ressources contenues dans 2 vues (Applications et Infrastructure).
Nous incluons un délai de 2 minutes permettant d'émettre l'alerte seulement si la condition est toujours vraie après 2 minutes d'indisponibilité. Cela permet d’éviter les faux positifs et de ne déclencher l’alerte que lorsqu’il s’agit d’une indisponibilité réelle et persistante.
Nous pouvons ensuite paramétrer l'envoi de l'email avec l'objet, le destinataire ainsi que le template HTML / CSS pour personnaliser la notification avec les bonnes variables.
Il est aussi possible d'utiliser les variables dans l'objet de l'email, par exemple : "[SP-Alerte] {RESOURCE} est dans l'état {STRSTATUS} depuis au moins {WINDOW} minutes"
Template HTML :
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
<meta name="viewport" content="width=device-width, initial-scale=1.0"/>
<title>ServicePilot Notification</title>
<style>
.OK {color:#00c855;}
.MINOR {color:#00e6ff;}
.MAJOR {color:#ffd900;}
.CRITICAL {color:#ff6600;}
.UNAVAILABLE {color:#d50000;}
</style>
</head>
<body style="background-color:#f4f4f4; margin:0; padding:20px; font-family:Arial, sans-serif;">
<table align="center" cellpadding="0" cellspacing="0" style="background:#ffffff; border-radius:8px; font-family:Arial, sans-serif;">
<tr>
<td style="background:#00214a; padding:20px; text-align:center; color:#ffffff;">
<h2 style="margin:0; font-size:24px;">Notification ServicePilot 🚨</h2>
</td>
</tr>
<tr>
<td style="padding:30px; color:#00214a; font-size:16px; line-height:1.6;">
<p>Bonjour,</p>
<p>Ceci est une notification automatique de <strong>ServicePilot</strong> vous informant que la ressource suivante est indisponible :</p>
<table style="color:#00214a; font-family:Arial, sans-serif;">
<tr>
<td>Ressource:</td>
<td><strong>{RESOURCE}</strong></td>
</tr>
<tr>
<td>Etat:</td>
<td>De <span class="{STROLDSTATUS}"><strong>{STROLDSTATUS}</strong></span> vers <span class="{STRSTATUS}"><strong>{STRSTATUS}</strong></span></td>
</tr>
<tr>
<td>Information:</td>
<td>{TEXT}</td>
</tr>
<tr>
<td>Accès direct: </td>
<td><a href="{BASEURL}/resourcelist.html?resource={RESOURCE}">Status page</a></td>
</tr>
</table>
</td>
</tr>
<tr>
<td style="background:#eeeeee; text-align:center; padding:15px; font-size:12px; color:#555555;">ServicePilot © 2026 - Notification d'alerte automatique</td>
</tr>
</table>
</body>
</html>
Résultat :
Amélioration de la notification pour aller plus loin
Il peut être pertinent de définir des règles d’alerte plus granulaires, par exemple pour distinguer une indisponibilité complète d’un serveur, un problème ciblé sur un composant (disque, interface réseau, alimentation) ou encore des événements issus de Traps SNMP et de Syslogs spécifiques.
En affinant le type d’alerte, on peut enrichir l’email envoyé avec des informations contextuelles utiles : procédure de vérification, message de log ou même un playbook guidant l’opérateur dans les premières étapes de diagnostic. Cette approche améliore la réactivité et réduit le temps nécessaire pour qualifier l’incident.
Exemples d’actions recommandées :
Pour un serveur hors ligne
- Confirmer l’indisponibilité réelle du serveur (ex. : avec un test d’un service applicatif via curl
http://serveur:port) - Vérifier l’état du serveur physiquement ou via la console distante (iDRAC, iLO, IPMI, etc.)
- Contrôler la connectivité réseau intermédiaire (switch, firewall, routage)
- Redémarrer les services réseau ou la machine si aucune anomalie matérielle n’est détectée
- Vérifier que le serveur soit de nouveau disponible pour confirmer la résolution
Pour un disque proche de la saturation
- Identifier les répertoires ou fichiers les plus volumineux (du -sh *, ncdu, etc.)
- Vérifier la présence de logs en croissance anormale ou de fichiers temporaires non purgés
- Contrôler les tâches planifiées susceptibles de générer des données (sauvegardes, exports, dumps)
- Libérer de l’espace ou étendre le volume si nécessaire
- Surveiller l’évolution de l’utilisation du disque après action pour confirmer la résolution
Conseils pour éviter le bruit dans les alertes email
Pour limiter le bruit et éviter de submerger les équipes d’exploitation, il est essentiel de maîtriser le volume des alertes envoyées par email. Même si la fonctionnalité de groupage n’est pas personnalisable avec du HTML et du CSS, son activation permet de regrouper automatiquement toutes les alertes déclenchées par une règle dans une fenêtre d’une minute. Ce mécanisme est particulièrement utile lorsque de nombreux éléments supervisés correspondent simultanément à une même règle d’alerting : au lieu d’une salve d’emails, un seul message consolidé est envoyé. Cette approche réduit la surcharge d’informations, facilite la lecture et les opérateurs priorisent mieux les incidents simultanés plutôt que de se concentrer sur la gestion du flux d’emails.
Optimiser ses notifications : une clé d'une supervision efficace
Les notifications par email restent un pilier essentiel de la supervision IT. En appliquant quelques bonnes pratiques (clarté, contexte, structuration et pertinence) vous améliorez non seulement la réactivité des équipes, mais aussi la qualité globale de votre monitoring.
Avec ServicePilot, la configuration et la personnalisation des alertes permettent d’adapter les notifications par email aux besoins de chaque organisation.
