SLA informatique : comment bien les gérer ?

Qu’est-ce qu’un SLA en informatique ? Derrière cet acronyme barbare qui peut faire peur à plus d’un informaticien se cache un des principaux indicateurs de votre qualité de service et du respect de vos engagements auprès de vos clients.

Nombreux sont les prestataires de services informatiques qui n’indiquent pas de SLA dans leurs contrats de maintenance ou de manière très limitée… Lorsque les TPE et PME choisissent d’externaliser tout ou partie de leur informatique auprès d’un prestataire informatique ou MSP (Managed Service Provider), l’offre de services d’infogérance ou de services managés comprend en général la gestion de l’infrastructure systèmes et réseaux, le support technique et la maintenance informatique des équipements (postes de travail, imprimantes et périphériques). En tant que prestataire informatique, vous vous assurez de répondre aux besoins des utilisateurs, mais vous posez-vous les bonnes questions sur votre qualité de service ? Même si les SLA ne sont pas encore mentionnés dans vos contrats de prestations d’infogérance, cela ne doit pas vous freiner dans leur mise en place afin de vos aider à mieux piloter votre exploitation, identifier les dérapages et améliorer la valeur ajoutée de vos services auprès de vos clients.

Les SLA informatique pour les Nuls

Avant de rentrer dans le vif du sujet, qu’est ce qu’un SLA ?

SLA signifie Service Level Agreement, soit Accords de niveau de service. Il existe des SLA en informatique qui mesurent le taux de disponibilité d’un service ou d’une application (les fameux 99,99%), cela s’applique essentiellement aux éditeurs d’applications, aux hébergeurs et aux services cloud en général. S’il peut être intéressant de mesurer le taux de disponibilité d’un serveur ou d’un service chez un client, cela peut souvent être décorrélé de la qualité de service perçue par le client. Si vous étudiez cet indicateur a posteriori, vous n’aurez pas suffisamment d’indications sur les actions à mener pour vous améliorer. La proactivité étant un des piliers du MSP, il en est de même pour les SLA : passez du mode pompier (recours à l’informatique curative), en passant à un modèle de maintenance préventive.

La mise en place et le pilotage des SLA est une étape incontournable si vous souhaitez :

• améliorer votre qualité de services de manière générale
• montrer à vos clients que vous fournissez un service performant
• progresser dans la maturité de votre société de service informatique ou MSP

SLA informatique et temps de réponse

La mesure des SLA peut s’appliquer à plusieurs grands domaines. Celui qui va nous intéresser en priorité est la mesure de votre performance en termes de temps de réponse, de temps d’intervention (monitoring à distance ou intervention sur site) et de temps de résolution des incidents rencontrés chez vos clients. Le principe d’un SLA est de se fixer des objectifs en temps sur ces différents indicateurs et de s’assurer que vous les respectez. Ces objectifs vont différer en fonction de la priorité de l’incident et de sa typologie. Vous pouvez les inclure dans vos contrats ou simplement les mettre en place pour les piloter en interne. Il est aussi tout à fait possible de ne s’engager que sur certains indicateurs auprès de vos clients comme le temps de réponse par exemple mais de toujours mesurer le temps de résolution.

Mesure des SLA

Voyons maintenant les différents états possibles d’un incident sur lequel vous allez mesurer un SLA :

• À la création, le ticket est dans un état « Non-répondu », un chrono va se déclencher à ce moment-là jusqu’à la clôture du ticket. Cela va habituellement correspondre au status « nouveau » de vos tickets.
• La réponse à un ticket est le moment où vos services ont acquitté la demande qui se traduit habituellement par une notification ou un appel au client. La définition de la réponse peut différer d’une société à l’autre. Il est préférable de ne pas considérer un accusé automatique comme une réponse mais privilégier une action humaine réalisée par vos équipes pour qualifier la demande et l’orienter vers les bonnes personnes/équipes afin qu’elle soit traitée. Suivant vos process, le ticket va passer dans un status « Dispatché », « Qualifié », « Assigné » ou encore « Planifié ».
• Le délai d’intervention est souvent utilisé chez les prestataires traditionnels intervenant beaucoup sur site pour indiquer le délai au bout duquel un technicien sera présent ou envoyé chez le client. D’une manière plus générale, cet état que l’on voit souvent nommé « Resolution Plan » peut-être utilisé pour mesurer le délai entre la création du ticket et le moment où un technicien va commencer à travailler. Cela est habituellement le passage du ticket dans un status « En Cours » ou « Pris en charge ». Il est important d’avoir des process bien structurés pour bien effectuer le changement de status quand le technicien commence à travailler sur le ticket et non à la fin de son intervention, ce qui nécessite généralement une action de sa part.
• Dans certains cas, le ticket peut-être placé dans un état d’attente afin de mettre les chronos en pause, cela correspond habituellement à des états où vous attendez un retour du client ou d’un tiers dont vous n’avez pas le contrôle. Ce sont habituellement les status de type « Attente client », « Attente prestataire/fournisseur » sur lequel vous pouvez mettre en pause le SLA. Attention à ne pas le faire pour des status pour lesquels vous attendez une action
• Enfin, lorsque vous avez résolu l’incident, nous allons mesurer le temps de résolution. On parle souvent de GTR (Garantie de temps de résolution/rétablissement). Cela ne correspond pas systématiquement à la clôture de l’incident mais peut aussi être utilisé sur des status où les actions correctives doivent être validées avant de clôturer le ticket. Certaines sociétés ne laissent d’ailleurs pas les techniciens clôturer eux-mêmes les tickets. Le status de résolution peut être « Terminé », « En attente de vérification », « Complété », « Clôturé », etc.

Mise en place des SLA : les grandes étapes

1 – Votre premier travail dans la mise en place de SLA est donc d’assigner ces différents états sur vos status. Vous devrez peut-être rajouter des status si vous n’avez pas aujourd’hui tous ces états. Vous n’êtes pas obligé de tout mesurer dès le départ, mais nous vous recommandons de mesurer a minima le temps de réponse et de résolution.

2 – La deuxième étape est de se fixer des objectifs sur ces différents indicateurs. Si vous avez déjà des éléments contractuels, partez de ce point de départ pour votre modélisation. Un des points à valider sont les différents niveaux de priorité que vous allez utiliser et à quoi chaque priorité correspond en pratique. Cette priorité peut-être issue d’une matrice sévérité/impact. Pour simplifier, voici quelques exemples de priorité avec leur description :

• Critique : l’ensemble du client est impacté et les processus métiers sont interrompus sans solution de contournement (exemple : internet down, serveur important down, réseau down…), on lâche tout et on fait le pompier.
• Haute : un service de l’entreprise ou un processus métier est interrompu, bloquant une partie de l’activité sans contournement possible (application down, serveur non critique down, site secondaire offline…).
• Moyenne : un ou peu d’utilisateurs sont impactés, service non critique interrompu ou avec des solutions de contournement.
• Faible : incident non bloquant affectant un ou peu d’utilisateurs.
• Planifié : incident n’affectant pas les utilisateurs, qui sera résolu lors d’une prochaine visite ou d’une action programmée.

Les SLA en pratique

L’affection de la bonne priorité est importante pour que votre mesure soit cohérente, si vous mettez une priorité moyenne alors que votre client est complètement bloqué, vos stats seront flatteuses mais il y a peu de chances que votre client soit satisfait. Il est donc indispensable de bien former vos techniciens sur la signification de chaque priorité et leur interprétation. Il est préférable de se baser davantage sur l’impact en fonction du métier du client plutôt qu’uniquement sur l’aspect technique. Par exemple, si une comptable n’arrive pas à virer des salaires en fin de mois ou un PDG n’arrive pas à ouvrir un document important, la priorité doit être plus haute.

N’utilisez pas les SLA pour vous protéger systématiquement. Nous citons souvent l’exemple donné par Gary Pica, coach de MSP et fondateur de TruMethods : « si vous êtes à l’arrêt, que j’ai un SLA de 4h et que je vous rappelle au bout de 3h55, est-ce que vous serez satisfait ? »

A contrario, il est intéressant de pouvoir s’appuyer sur les SLA dans vos processus de vente. Si vous avez par exemple un temps de réponse inférieur à 15 minutes, c’est un excellent argument commercial et qui s’appuie sur des mesures réelles et justifiables.

Mais n’oubliez pas l’essentiel de l’ADN d’un MSP : réduire les incidents chez ses clients. Sans travail proactif pour diminuer les incidents chez vos clients, vous aurez du mal à assurer des niveaux de SLA pertinents. Si vous équipes croulent sous les tickets, l’effet sur les SLA est immédiat. Un MSP qui a fait un vrai travail de fond sur le bruit de ses clients n’aura aucune difficulté à assurer des SLA agressifs car il aura peu de tickets au quotidien.

Datto Autotask PSA permet de mettre en place facilement les SLA, n’hésitez pas à nous contacter pour vous aider dans leur mise en place ou avoir une présentation de la solution.