Accords de niveau de service — SLA

Nos engagements, en chiffres

Nos engagements chiffrés : prise en charge en moins de 10 minutes en moyenne · intervention sur site à Paris en moins de 4 heures · 97 % de SLA respectés · satisfaction client 4,7/5. Indicateurs mesurés en continu et communiqués chaque mois à nos clients (démarche ISO 9001:2015).

Les différents états possibles d’un incident :

A la création, le ticket est dans un état « Non-répondu », un chronomètre va se déclencher jusqu’à la clôture du ticket. Il s’agit de l’état « Nouveau » chez ITAIA.

La première réponse à un ticket est le moment où ITAIA a acquitté la demande qui s’interprète habituellement par une notification ou un appel au client. C’est durant cette phase que va être qualifié le type de ticket, s’il s’agit d’un incident ou d’une demande de service. C’est durant cette étape crucial que va être appliqué le SLA.
Ensuite intervient le passage du ticket dans un status « En Cours » ou « Pris en charge ».

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ù nous attendons un retour du client ou d’un tiers dont nous n’avons pas le contrôle. Ce sont habituellement les status de type « Attente client », « Attente prestataire/fournisseur ».

Enfin, lorsque nous avons 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. Le status de résolution peut être « Terminé », « En attente de vérification », « Complété », « Clôturé », etc.

• 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…).
• 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.

Matrice de priorité et garanties de temps de rétablissement

La priorité d’un incident, de P1 à P4, résulte du croisement entre son impact (l’étendue de ce qui est touché) et son urgence (la gravité pour votre activité). Elle détermine la garantie de temps de rétablissement (GTR) applicable.

Ces délais s’entendent à l’intérieur de notre plage de service garantie (7j/7 de 8h à 20h) et portent sur notre périmètre d’administration :

Un incident planifié, sans impact utilisateur, est traité lors d’une action programmée ou d’une prochaine visite, hors chronomètre GTR.

Concrètement, qui répond, et quand ?

« Support 7j/7 » ne veut pas dire grand-chose tant qu’on n’a pas dit ce qui se passe un vendredi soir. Voici trois situations, à l’heure près.

Vendredi 19h : un poste refuse de démarrer avant le comité de lundi

Vous êtes dans la plage de service. Le support est ouvert de 8h à 20h, 7j/7, week-ends et jours fériés compris. Vous avez un ingénieur au téléphone, pas un répondeur ni un formulaire à remplir. La prise en charge démarre en moins de 10 minutes en moyenne, le ticket est qualifié, et la garantie de rétablissement court à partir de cet instant. Là où beaucoup de prestataires ferment à 18h, c’est-à-dire à peu près l’heure à laquelle on découvre qu’un poste ne redémarrera pas.

Mardi 23h40 : des fichiers commencent à être chiffrés sur un serveur

Personne n’appelle, et c’est précisément le principe. La surveillance de sécurité fonctionne 24h/24 et 7j/7, et elle ne se contente pas d’envoyer une alerte : la machine est isolée du réseau, le processus est arrêté, les fichiers suspects sont mis en quarantaine. Sans attendre qu’un humain valide, parce qu’à cette heure-là chaque minute d’attente est une minute de chiffrement supplémentaire. On contient d’abord, on analyse ensuite.

Un analyste reprend la main derrière pour mesurer l’étendue de l’incident et vérifier que rien n’a essaimé sur d’autres machines, puis vous êtes prévenu selon la procédure d’escalade définie dans votre contrat. Le point qui compte : le confinement ne dépend pas de la vitesse à laquelle quelqu’un décroche.

Samedi 22h : l’imprimante du plateau ne répond plus

Autant le dire franchement, c’est le genre de détail qu’on préfère connaître avant de signer plutôt qu’un samedi soir. En dehors de la plage 8h-20h, il n’y a pas d’astreinte humaine dans le contrat standard. Une panne sans enjeu de sécurité attendra l’ouverture, le lendemain à 8h. Une astreinte dédiée existe en option, dimensionnée avec vous selon vos exigences de résilience, plutôt que facturée à tout le monde pour l’usage de quelques-uns.

Notre périmètre : nous administrons, nous n’hébergeons pas

Nos engagements portent sur ce que nous maîtrisons directement : la réactivité, l’administration, la supervision et le pilotage des restaurations. ITAIA n’est ni votre hébergeur, ni votre opérateur télécom, ni votre fabricant de serveurs. Le temps de restauration (RTO) et la perte de données maximale (RPO) après un sinistre dépendent de votre solution, du volume de données concerné et de vos fournisseurs critiques (Microsoft, hébergeur…) ; ils se définissent conjointement et se vérifient par des tests de restauration. Cette clarté des responsabilités est au cœur d’une relation conforme DORA.

Qu’est ce que le SLA ? 

Le Service Level Agreement (SLA) est un accord contractuel entre un prestataire de services et son client qui définit les termes et conditions du contrat. Ce document est très important pour la réussite de la prestation de services car il établit les engagements, les performances et les mesures à respecter pour garantir la satisfaction du client. Le SLA est souvent utilisé dans les domaines de la technologie de l’information, de la communication, de l’externalisation et de l’infrastructure. Il assure également la sécurité des données et la disponibilité des services pour les deux parties impliquées.

La rédaction d’un SLA doit être bien planifiée pour garantir la qualité de la prestation de services. Il est important de prendre en compte les attentes du client et de définir clairement les services proposés. Les parties impliquées doivent également établir les mesures pour évaluer la performance du prestataire de services et s’assurer de la disponibilité des services. Les termes et conditions du SLA doivent être compréhensibles et simples à suivre pour les deux parties. En outre, le SLA doit être régulièrement mis à jour pour garantir que les engagements sont en phase avec les exigences actuelles du client.

En fin de compte, le SLA est un document essentiel pour garantir une bonne collaboration entre les deux parties impliquées. Il permet de clarifier les attentes et les responsabilités de chaque partie, et fournit un cadre pour mesurer les performances. En cas de litige ou de non-respect des termes du SLA, les parties peuvent se référer à ce document pour résoudre les problèmes. En résumé, la mise en place d’un SLA assure la qualité de la prestation de services et la satisfaction du client, tout en garantissant la sécurité des données et la disponibilité des services.

---

Pourquoi le support informatique à l’incident est un modèle dépassé

Support informatique : définition, niveaux et fonctionnement