En tant que fournisseur de services gérés (MSP), vous devez être en mesure d’expliquer votre processus de traitement des alertes à vos clients de façon claire et efficace. Dans le cas contraire, ils risquent d’avoir l’impression de ne pas être suivis correctement, ou que vos efforts ne sont pas à la hauteur, même si vous appliquez les bonnes pratiques du secteur, avec une équipe compétente et dotée de tous les moyens nécessaires pour résoudre les problèmes dans les délais.
Ce guide propose un cadre pour présenter votre processus de traitement des alertes d’une manière compréhensible pour vos clients. Vous pourrez ainsi définir des attentes réalistes et préserver la confiance pendant les incidents.
Quelle est la différence entre une alerte et un incident ?
Un incident est une interruption des services informatiques que vous fournissez à vos clients ou que vous gérez pour eux. Les incidents sont généralement imprévus et peuvent aller d’une connexion internet dégradée à cause d’un lien défaillant jusqu’à la panne totale d’un serveur de fichiers provoquée par un plantage système. Les incidents de cybersécurité, comme les fuites de données, n’interrompent pas toujours le service de façon immédiate ou marquée, mais ils peuvent entraîner d’autres effets négatifs.
Une alerte est générée à la suite d’un incident et transmise à votre équipe technique pour l’en informer. Elle peut provenir de systèmes de surveillance ou de plateformes de cybersécurité, et être envoyée dès la première occurrence d’un incident (par exemple, un serveur qui cesse de répondre) ou lorsque certains seuils sont atteints (par exemple, un nombre défini de tentatives de connexion échouées pour un utilisateur). Les alertes peuvent aussi être d’origine humaine, sous la forme d’un ticket d’assistance, et révéler une activité inhabituelle ou un dysfonctionnement sur votre infrastructure que les systèmes automatisés ne détectent pas forcément.
En quoi consiste le processus de traitement des alertes ?
Le processus de traitement (ou de triage) des alertes correspond à la façon dont vous configurez les alertes et dont vous y répondez. Un processus efficace garantit que des seuils pertinents sont définis, et que les alertes sont priorisées et escaladées lorsque c’est nécessaire, afin que rien ne passe entre les mailles du filet et que les incidents critiques passent avant les désagréments mineurs.
Pour votre équipe MSP, l’objectif du processus de traitement des alertes est d’obtenir de la visibilité tout en évitant la fatigue liée aux alertes. Pour vos clients, tout cela doit rester compréhensible : vous devez pouvoir démystifier les raisons techniques qui expliquent la configuration de votre processus de triage. Ainsi, lorsqu’un incident grave finira inévitablement par survenir, ils seront rassurés de savoir qu’il est passé en priorité devant les autres tâches en cours et que votre équipe est déjà sur le coup.
Expliquer clairement le processus de traitement des alertes
La technologie vous aide à démontrer à vos clients que votre équipe est prête. Vous pouvez faire une démonstration de votre logiciel de surveillance, en montrant les tableaux de bord et les notifications en action. Les politiques de surveillance et d’alertes (y compris les niveaux d’escalade) peuvent être partagées via la plateforme de documentation de votre MSP, et votre logiciel de Helpdesk (service d’assistance) peut servir à communiquer clairement avec le client et à lui transmettre l’état d’avancement d’un incident.
Les bilans trimestriels d’activité (QBR) sont l’occasion de présenter des rapports issus des indicateurs de surveillance et du Helpdesk (service d’assistance), afin de démontrer l’efficacité de votre processus de traitement des alertes.
Lorsque vous expliquez ce processus, les questions suivantes doivent trouver une réponse claire pour vos clients :
- Que se passe-t-il quand quelque chose ne fonctionne pas ?
- En combien de temps allez-vous réagir ?
- Comment puis-je être sûr qu’aucun problème ne passera entre les mailles du filet ?
Aucune de ces réponses ne doit rester abstraite. Elles doivent être concrètes, fondées sur vos politiques, et se vérifier le jour où le besoin se présente réellement.
Exigence 1 : décomposer le cycle de vie d’une alerte en termes simples
Évitez le jargon technique quand vous présentez vos systèmes de surveillance et vos méthodes d’alerte. Abordez les technologies et notions suivantes, en expliquant comment vous les utilisez pour répondre aux problèmes de vos clients :
- Détection : présentez les outils de surveillance que vous utilisez pour identifier les problèmes
- Création de tickets : expliquez comment les tickets sont créés, à la fois automatiquement depuis les systèmes de surveillance et par les utilisateurs qui signalent un problème
- Triage : détaillez la façon dont votre technicien valide une alerte et en évalue la priorité
- Réponse : si l’alerte correspond à un incident avéré, décrivez le processus d’attribution et de résolution
- Escalade : assurez-vous que le client comprend que si un incident n’est pas résolu rapidement, l’alerte remonte vers un personnel de niveau supérieur ou vers un fournisseur tiers (il peut par exemple être nécessaire d’escalader vers le support Microsoft pour un problème Microsoft 365 qui ne peut pas être résolu en externe)
- Clôture et reporting : les détails et les délais de résolution documentés sont intégrés aux rapports et servent aux analyses et aux améliorations futures
Des schémas et des logigrammes montrant la progression des différentes alertes facilitent cette explication. Vous pouvez par exemple montrer comment une alerte initialement peu prioritaire est escaladée à mesure que les seuils sont atteints.
Exigence 2 : traduire les SLA en scénarios
Des scénarios concrets rassurent les clients en leur donnant un exemple qu’ils peuvent transposer à leurs propres processus métier pour évaluer l’impact de votre dispositif d’alerte.
Par exemple, plutôt que d’annoncer simplement un délai de réponse, remettez-le en contexte : « Si votre serveur tombe à 2 h du matin, notre système génère immédiatement une alerte et un technicien d’astreinte intervient dans les 15 minutes. Nous comptons généralement le remettre en ligne dans les 30 minutes qui suivent et, si nous n’y parvenons pas, nous escaladons vers un technicien sur site dans l’heure. »
Exigence 3 : clarifier les circuits d’escalade
Expliquez comment un incident ne peut pas rester bloqué dans une file d’attente ni entre les mains d’un technicien qui n’a pas réussi à le résoudre. Abordez les points suivants :
- Qui assure la première réponse (niveau 1)
- Qui prend en charge les problèmes complexes en escalade (niveau 2/3 ou fournisseur tiers)
- Comment les clients et les parties prenantes sont informés pendant l’escalade
Exigence 4 : montrer à vos clients ce qu’ils verront en cas de problème
Dans le cadre de l’onboarding de vos clients, montrez-leur des exemples de ce qu’ils verront pendant et après les incidents ayant déclenché des alertes. Il peut s’agir de rapports présentant les alertes résolues et les indicateurs de disponibilité, ou de tableaux de bord destinés aux clients avec des données en temps réel.
Mettez en avant les cas exceptionnels lors des QBR pour démontrer l’efficacité de votre processus de traitement des alertes.
Exigence 5 : distinguer les vraies alertes du bruit
Expliquez les technologies qui sous-tendent votre surveillance et vos alertes, et comment elles permettent à votre équipe de fournir des services efficaces qui privilégient la disponibilité. La fatigue liée aux alertes survient lorsque les techniciens sont submergés d’alertes pour des problèmes mineurs, au point de passer à côté d’incidents importants.
Montrez à vos clients comment vous évitez cette situation et comment les seuils, le filtrage et l’automatisation garantissent une priorisation intelligente des incidents selon leur gravité.
NinjaOne offre une solution unifiée de surveillance, d’alertes, de gestion des tickets et de documentation
NinjaOne met à la disposition des MSP une chaîne d’outils complète pour la surveillance, les alertes et la réponse aux incidents. Les seuils peuvent être définis client par client et, lorsqu’un événement survient, les notifications sont transmises par SMS, e-mail ou notification push, pour que les techniciens ne soient jamais pris de court.
Les tickets du Helpdesk (service d’assistance) NinjaOne peuvent être générés automatiquement à partir d’alertes provenant d’un large éventail de serveurs, d’outils et de plateformes, et des tableaux de bord peuvent afficher les indicateurs de disponibilité et de résolution. La documentation intégrée de NinjaOne permet de stocker les SLA, la documentation des processus, les schémas, les rapports, les exemples et tout autre document destiné aux clients, qui apportent un contexte précieux et rassurent sur votre processus de traitement des alertes.
