SLA informatique : derrière ce terme que l’on retrouve dans tous les contrats IT se cache en réalité l’un des leviers les plus critiques et les plus mal compris de la relation entre une DSI et ses prestataires.
Trop souvent perçu comme une simple formalité juridique, le SLA structure pourtant la disponibilité réelle de vos services, la qualité de votre support et, in fine, la continuité de votre activité.
Cet article vous donne une vision complète et opérationnelle du SLA informatique :
- comment il fonctionne,
- comment l’interpréter correctement,
- où se cachent les pièges contractuels,
- et surtout comment en faire un véritable outil de contrôle plutôt qu’un simple document théorique.
Prenez la main sur vos engagements IT avant qu’ils ne dictent, eux-mêmes, la qualité de votre service.
Qu’est-ce qu’un SLA informatique ?
Un SLA informatique (Service Level Agreement ou accord de niveau de service) est un engagement contractuel qui définit précisément le niveau de service que votre prestataire doit vous fournir. Il fixe des objectifs chiffrés sur la performance, la disponibilité et la qualité du service, ainsi que les conditions de contrôle.
Quels sont les types de SLA en informatique ?
SLA basé client
Un SLA basé client vous permet de définir un niveau de service spécifique pour un client donné, interne ou externe. Il regroupe les engagements sur l’ensemble des services concernés : disponibilité, support, délais et performance. Ce format est utile si vous avez des exigences particulières ou des services critiques. Exemple : garantir une continuité de service renforcée sur une application stratégique. En interne, il sert aussi à cadrer clairement les obligations entre la DSI et les autres services de l’organisation.
SLA basé service
Un SLA basé service fixe un niveau de service unique pour un service informatique donné, appliqué à tous les clients ou utilisateurs. Vous standardisez ainsi les garanties de service opérationnel, performance et support sur un périmètre précis. Ce modèle est courant sur des services mutualisés comme un service desk ITSM ou une plateforme cloud. Les délais de prise en charge de ticket (incident, création de ressources…), règles d’escalade et objectifs restent identiques pour tous. C’est une approche efficace pour industrialiser la qualité de service.
SLA multi-niveaux
Un SLA multi-niveaux vous permet de regrouper plusieurs niveaux de service dans un même accord. Il est utile quand vous gérez plusieurs offres, plusieurs clients ou plusieurs parties prenantes (multi-cloud, multi-prestataires, équipes internes). Chaque niveau peut définir des engagements différents sur la disponibilité, le support ou les délais. Exemple classique : une offre SaaS avec des niveaux standard, premium et entreprise. C’est un format adapté aux environnements IT complexes.
SLA et KPI : quelles différences ?
Dans la gestion de votre service informatique, SLA et KPI sont souvent associés, mais ils ne jouent pas le même rôle. Les confondre peut fausser votre pilotage.
Le plus simple est de retenir ceci :
- SLA (Service Level Agreement) : engagement contractuel et mesurable sur un niveau de service à atteindre.
- KPI (Key Performance Indicator) : indicateur quantifiable utilisé pour suivre la performance réelle d'une organisation, d’un projet ou d’un processus.
Le SLA fixe un objectif technique à respecter, tandis que le KPI vous dit si un objectif est atteint ou non.
Par exemple, si vous gérez un service de support informatique avec un SLA sur les temps de traitement, vous pouvez suivre des KPI comme le temps moyen de prise en charge des tickets, le pourcentage de tickets résolus dans les délais contractuels, le nombre de réouvertures d’incidents.
Que doit contenir un SLA informatique efficace ?
Les clauses SLA indispensables
Voici les clauses SLA indispensables à formaliser pour encadrer clairement le niveau de service, les responsabilités et les engagements du prestataire :
- Périmètre du service : quels services sont couverts, pour quels utilisateurs, avec quelles exclusions
- Disponibilité et continuité de service : taux d’accessibilité garanti, plages horaires couvertes (heures ouvrées ou 24/7), règles de maintenance planifiée, continuité en cas d’incident majeur
- Support : horaires de support, canaux de contact autorisés (téléphone, email, site web/plateforme), niveaux de criticité et priorisation des demandes
- GTI (Garantie de Temps d’Intervention) et GTR (Garantie de Temps de Rétablissement) : délais maximum de prise en charge (intervention) et de rétablissement selon la criticité des incidents
- Gestion des incidents et escalade : processus de qualification, traitement, traçabilité, escalade N2/N3 ou éditeur en cas de blocage ou dépassement de délais
- Sécurité et obligations RSSI : gestion des accès, patching, vulnérabilités, logs, traçabilité, temps de traitement des incidents de sécurité, conformité (RGPD, politiques internes)
- Reporting et gouvernance : indicateurs suivis, fréquence des rapports, comités SLA, analyse des écarts et plan d’amélioration continue
- Pénalités et compensations : crédits de service ou pénalités financières selon des seuils définis en cas de non-respect des engagements
Les clauses SLA souvent oubliées
Certaines clauses sont régulièrement sous-estimées dans les SLA, alors qu’elles peuvent avoir un impact direct sur la continuité de service et la maîtrise du contrat :
- Réversibilité et fin de contrat : reprise des données, formats d’export, transfert vers un nouveau prestataire, accompagnement et délais de sortie
- Responsabilité du client : ce que le client doit fournir pour que le service fonctionne correctement
Les erreurs les plus courantes dans les SLA informatiques
Un SLA trop flou ou non mesurable
Un SLA sans indicateurs chiffrés, méthode de calcul opposable et seuils précis est inexploitable en pratique. Dans ce cas, le fournisseur conserve toujours l’avantage en cas de litige, car rien ne permet de prouver objectivement un manquement.
Une disponibilité affichée mais mal calculée
Les SLA annoncent fréquemment un taux de disponibilité de 99,9 % ou plus, mais cet indicateur dépend fortement de la manière dont il est calculé. Le prestataire peut exclure la maintenance planifiée, limiter la mesure à certaines plages horaires ou ne pas comptabiliser les dégradations partielles. Le service peut être fortement impacté pour les utilisateurs sans jamais déclencher de non-conformité contractuelle.
Un SLA trop ambitieux
Lors de la définition d'un SLA, il faut prendre en compte les capacités de l'infrastructure offrant le service. Il est important de vérifier que votre infrastructure peut réellement supporter les objectifs fixés par le SLA. Les niveaux de disponibilité, de performance ou de temps de rétablissement doivent être cohérents avec vos capacités techniques réelles.
Des pénalités faibles, plafonnées et peu dissuasives
Les compensations sont généralement limitées à des crédits de service et plafonnées à un faible pourcentage de la facture mensuelle. Cela signifie que même une dégradation majeure du service reste économiquement marginale pour le fournisseur. Surtout, ces compensations sont rarement proportionnelles aux pertes réelles subies côté client : arrêt d’activité, perte de chiffre d’affaires, retards opérationnels ou mobilisation des équipes en gestion de crise. Le SLA devient alors un mécanisme de “compensation symbolique” plutôt qu’un levier de pression.
Un exemple celui d’AWS, lors d’une panne majeure survenue le 20 octobre 2025, AWS appliquait son SLA sous forme de crédits de service (et non de remboursement) selon le niveau de service mensuel :
- Disponibilité ≥ 99,0 % et < 99,99 % : crédit de 10 %
- Disponibilité ≥ 95,0 % et < 99,0 % : crédit de 30 %
- Disponibilité < 95,0 % : crédit de 100 %
Cette panne d’environ 15 heures sur un mois de 31 jours correspond à un niveau de service proche de 98 %, ce qui rend la majorité des clients éligibles à seulement 30 % de crédit sur la facture mensuelle, malgré un impact potentiellement massif sur l’activité. Par exemple, pour les organismes de santé aux Etats-Unis, cet évènement a causé une perte estimée 62 500 $ par heure de chiffre d’affaires. (d'après Censinet)
Cela illustre parfaitement le décalage entre les pertes réelles côté client et les compensations contractuelles, souvent plafonnées et peu dissuasives.
RocketEdge, AWS Outage Refund: How AWS Service Credits Work, 24 octobre 2025
Un SLA centré sur la réponse plutôt que sur le rétablissement
Dans le cadre d’un SLA, certains supports mettent en avant des délais de prise en charge très courts (ex : 15 minutes), ce qui permet au fournisseur de respecter ses obligations contractuelles sans pour autant résoudre le problème. En réalité, le service peut rester indisponible plusieurs heures : seul le temps de rétablissement (GTR / MTTR) a un impact métier réel, pas l’accusé de réception.
Trop d’exclusions et de dépendances non couvertes
Les SLA incluent souvent des clauses d’exclusion très étendues : dépendances cloud, opérateurs télécom, API tierces, incidents de sécurité ou mauvaise configuration client. Ces exclusions permettent au fournisseur de sortir de sa responsabilité sur une grande part des incidents critiques.
Absence de gouvernance et de preuves
Sans outils de mesure partagés et sans règles de reporting opposables, la donnée de référence reste celle du prestataire. En cas de désaccord, c’est généralement sa mesure qui fait foi. Sans gouvernance formalisée (comités, rapports, logs accessibles), le SLA devient difficilement contestable même en cas de dérive réelle.
Niveaux de priorités mal définies
Les niveaux de priorités (P1/P2/P3) peuvent sembler clairs sur le papier, mais leur interprétation laisse souvent une marge au fournisseur. Un incident critique peut être requalifié en P2 si les critères ne sont pas strictement définis, notamment pour éviter d’entrer dans les seuils de pénalité.
Sans matrice de criticité extrêmement précise et partagée, le classement des incidents devient un levier de gestion contractuelle.
Construire un SLA informatique optimisé
Alignement métier / IT / juridique
Dans la majorité des organisations, le problème du SLA n’est pas technique mais organisationnel : chaque partie prenante travaille avec ses propres priorités. Le métier attend un service fluide et sans interruption visible, l’IT compose avec les limites de l’architecture et des coûts, tandis que le juridique cherche avant tout à réduire l’exposition contractuelle.
En cas de manque d’arbitrage entre ces trois logiques, vous vous retrouverez très vite avec un SLA incohérent : trop ambitieux pour être tenu par l’IT, trop flou pour être défendable juridiquement, et trop éloigné des usages réels pour satisfaire le métier. L’enjeu n’est donc pas de “faire converger les attentes”, mais de trancher clairement ce qui est réellement possible, mesurable et opposable.
Définition des exclusions
Les exclusions sont l’un des éléments les plus critiques d’un SLA, car elles définissent concrètement les limites de responsabilité du prestataire. Elles couvrent généralement :
• les incidents liés à des tiers (cloud, opérateurs, API externes),
• la maintenance planifiée,
• les erreurs de configuration côté client
• ou encore certains événements de sécurité.
Le risque pour vous apparaît lorsque ces exclusions sont trop larges ou insuffisamment précises. Elles permettent d’exclure une grande partie des incidents réels de production du périmètre contractuel. C’est pour cette raison que vous devez porter une attention particulière à leur rédaction : elles doivent être précise, limitée et sans ambiguïté, afin d’éviter qu’un incident critique soit requalifié en “hors SLA”.
Mesure indépendante ou contestable
Dans les faits, un SLA n’a de valeur pour vous que si ses indicateurs peuvent être vérifiés. Or, dans de nombreux contrats, la mesure est entièrement produite par le fournisseur, ce qui lui laisse le contrôle de la donnée de référence. Cela devient problématique dès qu’un désaccord survient, vous pouvez rapidement vous retrouver sans point de comparaison fiable. C’est pourquoi la vraie question n’est pas seulement “que faut-il mesurer”, mais “comment la mesure est produite et par qui elle est validée”. Il est vital pour vous de cadrer dès la négociation la méthode de calcul, les sources de données et, lorsque c’est possible, à introduire une supervision indépendante ou partagée. Sinon vos KPI resteront difficiles à opposer et perdront une grande portion de leur valeur en cas de litige.
Introduction d’une gouvernance
Un SLA sans gouvernance active perd rapidement toute valeur dès que vous passez en production. Une fois le contrat signé, c’est la gouvernance qui fait la différence entre un document théorique et un véritable outil de pilotage du service. Elle repose principalement sur :
• des comités réguliers entre le client et le prestataire,
• un suivi partagé des indicateurs de performance,
• et un processus clair d’escalade en cas de dérive.
L’objectif est double : vous assurer que les engagements sont réellement suivis dans le temps, et créer un espace de discussion structuré pour traiter les écarts avant qu’ils ne deviennent des incidents critiques ou des litiges contractuels. Sans ce dispositif, le SLA reste un document théorique, difficile à exploiter en situation réelle.
Révision périodique
Le SLA doit évoluer avec votre SI, vos volumes et vos usages. Sans révision périodique, il devient rapidement obsolète et déconnecté de la réalité opérationnelle. La révision périodique permet d’ajuster les niveaux de service, les indicateurs et parfois même les exclusions, en fonction des changements de votre SI ou de vos besoins métier. Elle doit être prévue contractuellement, avec une fréquence définie ou des seuils déclencheurs (hausse de charge, incidents répétés, évolution d’architecture). Vous éviterez donc qu’un SLA signé à un instant T devienne un cadre rigide déconnecté de vos enjeux actuels, voire inadapté à la criticité réelle du service.
SLA et incidents majeurs : ce que les contrats ne disent pas toujours
Que se passe-t-il en cas de panne majeure d’un fournisseur SaaS ?
Lorsqu’un service SaaS tombe à grande échelle, l’impact dépasse rapidement le cadre technique : c’est toute votre chaîne de production qui peut être affectée, même si votre propre SI est opérationnel.
Dans ce type de situation, vous entrez dans un cadre très spécifique où le SLA ne couvre pas toujours toute la réalité de l’incident.
Concrètement, vous allez généralement retrouver trois éléments clés :
• Qualification de l’incident : le prestataire détermine s’il s’agit d’une indisponibilité totale, d’une dégradation ou d’un incident tiers (cloud, API, infrastructure externe) ;
• Communication sous contrainte : le fournisseur diffuse des mises à jour régulières très standardisées (statut, rétablissement, contournement), avec peu d’informations sur l’origine réelle de la panne et des délais de rétablissement ;
• Application du SLA : la panne n’est prise en compte dans les garanties de service (disponibilité, crédits de service) que si elle entre explicitement dans le périmètre contractuel.
Pourquoi un SLA ne suffit pas à éviter les crises ?
Un SLA encadre un niveau de service, mais ne garantit pas à lui seul l’absence de panne. Vous pouvez respecter un SLA tout en subissant une dégradation significative du service, notamment si l’incident reste dans les seuils contractuels ou s’il est exclu du périmètre (tiers, maintenance, dépendances cloud).
Plusieurs limites apparaissent :
- le SLA mesure une conformité, pas la résilience globale du service ;
- certaines pannes critiques ne déclenchent pas automatiquement une violation ;
- la perception utilisateur peut être très différente du respect contractuel.
C’est pour cela que les entreprises complètent souvent le SLA avec des indicateurs internes (SLO, monitoring informatique temps réel, alerting avancé) afin de mieux piloter la réalité opérationnelle.
SLA non respecté : l’exemple critique de National Grid et de son projet SAP
Un exemple marquant de défaillance critique dans un projet IT concerne National Grid USA, l’un des plus grands fournisseurs d’électricité aux États-Unis, confronté en 2012 à la mise en production d’un vaste projet SAP.
Initialement conçu pour unifier les systèmes financiers et opérationnels après une acquisition majeure, le projet a accumulé retards, surcoûts et complexité excessive. Malgré plusieurs reports, la mise en production est maintenue dans un contexte déjà très tendu, notamment avec l’arrivée de l’ouragan Sandy qui mobilise fortement les équipes opérationnelles.
Après le go-live, les dysfonctionnements sont immédiats et massifs :
• erreurs de paie impactant des milliers d’employés
• factures fournisseurs impossibles à traiter à grande échelle
• clôtures comptables passant de quelques jours à plus d’un mois
• perte d’accès à certains mécanismes de financement à court terme
• recours massif à des centaines de consultants pour stabiliser le système
Le coût global de correction et de stabilisation est estimé à plusieurs centaines de millions de dollars, avec un retour à la normale prenant plus de deux ans.
Ce cas illustre un point souvent absent des SLA contractuels classiques : un service peut être techniquement “en ligne”, tout en étant totalement non opérationnel pour les métiers. Dans ce type de situation, les garanties de service formelles (disponibilité, support, délais) ne reflètent plus la réalité des impacts business, ni la gravité des dysfonctionnements.
Henrico Dolfing, Case Study 3: How a Screwed-Up SAP Implementation Almost Brought Down National Grid, henricodolfing.ch, 9 avril 2019.
Se faire accompagner sur la gestion de vos SLA informatiques
Un SLA efficace ne se résume pas à un contrat. Il doit être réaliste, mesurable et aligné avec vos enjeux métier. C’est exactement ce que nous vous aidons à construire chez Mixcom. Selon votre niveau de maturité, nos experts vous accompagnent pour vous aider à structurer, fiabiliser ou encore renforcer vos engagements de service.
Nous pouvons réaliser un état des lieux de vos services informatiques afin d’identifier les points de fragilité, les écarts entre engagements et réalité, ainsi que les besoins réels des utilisateurs et des métiers.
Nous vous accompagnons également dans la mise en place d’une organisation SLA réaliste, avec une attribution claire des rôles (DSI, support, prestataire, RSSI, utilisateurs) et une gouvernance adaptée aux enjeux de l’entreprise.
Mixcom peut aussi intervenir sur la rédaction ou la révision de vos contrats SLA, en intégrant les exclusions, les responsabilités, les indicateurs et les mécanismes de compensation de manière exploitable.
Enfin, nous vous aidons à mettre en place la surveillance de vos SLA via des outils de mesure (supervision, monitoring…) et de reporting sur mesure. Ces moyens proposés prendront en compte le niveau d’urgence, de criticité et de disponibilité spécifique à chaque service.
SLA informatique ce qu’il faut retenir pour garantir la disponibilité de votre SI
Derrière les engagements d’un SLA se jouent des enjeux bien plus structurants pour votre DSI, vos équipes IT et la continuité de vos services métiers.
Retenez l’essentiel :
- Le SLA informatique définit des engagements de service mesurables ;
- Il peut être structuré en modèle client, service ou multi-niveaux ;
- Il doit être distingué des KPI, qui mesurent la performance réelle ;
- Un SLA efficace repose sur des clauses clés (GTI, GTR, support, sécurité) ;
- Certaines clauses critiques sont souvent oubliées (réversibilité, responsabilités) ;
- Les erreurs fréquentes : SLA flou, pénalités faibles, exclusions excessives ;
- La disponibilité annoncée ne reflète pas toujours la réalité vécue ;
- La gouvernance et la mesure sont souvent sous contrôle du fournisseur ;
- En crise majeure, le SLA atteint rapidement ses limites ;
- Sans révision, il devient vite obsolète.
Pilotez vos services informatiques avec des engagements réalistes, mesurables et applicables, y compris dans des environnements multi-prestataires.
Avec Mixcom, sécurisez durablement vos SLA informatiques.
FAQ SLA informatique
Un SLA n’est pas obligatoire au sens légal, mais il est fortement recommandé. Il permet de structurer les engagements de service, de définir clairement les niveaux de performance attendus et de répartir les responsabilités entre les différentes parties prenantes.
Sans SLA, aucun délai d’intervention ni niveau de qualité n’est formellement garanti, ce qui rend la relation beaucoup plus incertaine en cas d’incident ou de dégradation du service.
Le SLA (Service Level Agreement) est un engagement contractuel entre un client et un fournisseur : il définit les niveaux de service garantis (disponibilité, délais, support) et les éventuelles pénalités en cas de non-respect.
Le KPI (Key Performance Indicator) est un indicateur de mesure utilisé pour suivre la performance réelle d’une organisation, d’un projet ou d’un processus. Il sert à observer ce qui se passe concrètement, sans être forcément contractuel.
Le SLO (Service Level Objective) est un objectif interne de qualité de service, souvent plus exigeant que le SLA. Il est utilisé par les équipes IT pour piloter et anticiper, sans forcément avoir de valeur contractuelle.
