SLA informatique : ce que couvre vraiment votre accord de niveau de service
La plupart des dirigeants de PME signent un SLA sans savoir comment vérifier que les engagements tiennent dans leur contexte réel. Ce guide vous donne les outils pour lire, négocier et mesurer un SLA sans avoir un DSI à temps plein.
Donatien Lefranc
Fondateur & Président, Leando
L'essentiel en 4 points
- Un SLA sans processus documentés ne garantit rien : il redistribue la responsabilité en cas d'incident, sans garantir la capacité à le résoudre.
- La disponibilité 99,9% correspond à 8h44 d'interruption autorisée par an. La question n'est pas ce chiffre, mais quand ces 8h44 peuvent tomber.
- La plupart des SLA contiennent au moins un engagement que le prestataire ne peut pas honorer seul, parce que le périmètre de responsabilité n'est pas assez précis.
- Un SI dont les processus ne sont pas formalisés est structurellement incapable de tenir un SLA : les engagements reposent sur des individus, pas sur des systèmes.
- Négocier un SLA, c'est d'abord négocier la définition de chaque indicateur, avant de négocier les seuils.
Ce que la plupart des dirigeants croient savoir sur le SLA (et pourquoi c'est insuffisant)
Quand on demande à un dirigeant de PME s'il a un SLA avec son prestataire IT, la réponse est souvent « oui, on a négocié une disponibilité à 99,9% ». C'est une réponse correcte. C'est aussi une réponse insuffisante.
Le SLA ne s'arrête pas à un chiffre de disponibilité. Il couvre aussi les délais d'intervention, les délais de résolution, les plages horaires couvertes, les exclusions de responsabilité, les méthodes de mesure, et surtout le périmètre exact sur lequel le prestataire s'engage. Ce périmètre est souvent bien plus étroit que ce que le client imagine au moment de la signature.
Il y a une deuxième lacune, moins visible. Beaucoup d'entreprises signent un SLA avec leur prestataire externe sans avoir évalué si leur propre SI est organisé pour permettre de tenir ces engagements. Un SLA, c'est un contrat entre deux parties. Si l'une d'elles fonctionne sur des processus non formalisés, des dépendances à des individus-clés, ou des règles métier qui vivent dans les têtes plutôt que dans les documents, la capacité à tenir les engagements est compromise dès le départ, quel que soit le seuil inscrit dans le contrat.
Ce que le dirigeant comprend
"99,9% de disponibilité, mon système tourne presque toujours"
Ce que dit vraiment le contrat
"99,9% sur le périmètre de nos serveurs, hors maintenances programmées, hors défaillances tierces"
Ce que ça mesure en pratique
8h44 d'interruption autorisée par an, sur un périmètre réduit que vous n'avez pas encore cartographié
SLA informatique : définition concrète, ce que ça couvre, ce que ça ne couvre pas
Un SLA, Service Level Agreement ou accord de niveau de service, est un engagement contractuel entre un prestataire IT et son client sur des indicateurs de performance mesurables. L'idée est simple : plutôt que des formulations floues comme « nous assurons un service de qualité », le SLA pose des seuils précis. Si ces seuils ne sont pas tenus, des pénalités s'appliquent.
Les indicateurs les plus courants sont la disponibilité (uptime), le RTO (Recovery Time Objective, délai maximal pour rétablir le service après incident), le RPO (Recovery Point Objective, perte de données maximale acceptable), et le temps de réponse initial en cas d'incident critique.
Ce qu'un SLA couvre en général
Ce qu'un SLA ne couvre pas (et que peu de clients vérifient)
Opinion tranchée : un SLA n'est pas une assurance. C'est un outil de pilotage. Les pénalités contractuelles couvrent rarement le manque à gagner réel d'une interruption critique. Ce qui importe dans un SLA, c'est ce qu'il force à formaliser en amont : les engagements, les périmètres, les procédures. C'est cette préparation qui prévient les incidents, pas la perspective de pénalités.
Les 3 engagements SLA que personne ne peut honorer (et pourquoi votre contrat en contient probablement un)
Certains SLA sont bien rédigés, cohérents avec les capacités réelles du prestataire. D'autres contiennent des engagements structurellement impossibles à tenir, non par mauvaise foi, mais parce que le périmètre ou les prérequis n'ont pas été clarifiés au moment de la négociation.
Le SLA de disponibilité sans définition des plages critiques
Un engagement de disponibilité à 99,9% sur une année autorise 8h44 d'interruption. C'est acceptable si ces 8h44 tombent sur des nuits ou week-ends sans activité. C'est catastrophique si elles coïncident avec votre clôture de fin de mois, une livraison client, ou une campagne commerciale. Un SLA qui ne précise pas les fenêtres critiques pour votre activité n'engage que sur un pourcentage mathématique, pas sur un niveau de service réel. Beaucoup de contrats PME ne font pas cette distinction.
Le SLA de résolution quand les processus internes ne sont pas documentés
Un prestataire peut s'engager sur un délai de résolution de 4h pour les incidents P1. Mais si la résolution nécessite l'accès à des informations ou des validations de votre côté (accès administrateur, connexion à un système métier, validation d'un responsable), le délai ne dépend plus seulement du prestataire. Si ces processus côté client ne sont pas formalisés, si la personne qui gère les accès est en congé et n'a pas de remplaçant identifié, le SLA est respectable sur le papier et impossible à tenir dans les faits.
Le SLA sur un périmètre hybride sans cartographie des dépendances
Beaucoup de PME utilisent un ensemble d'outils : un ERP maison ou sur mesure, un CRM SaaS, une plateforme e-commerce, des intégrations API entre ces systèmes. Le prestataire IT s'engage sur sa partie, mais les flux entre ces systèmes traversent des responsabilités multiples. Si une panne survient dans une intégration, personne ne sait précisément dans quel périmètre elle se situe. Un SLA signé sans cartographie des dépendances applicatives est un accord sur une partie de la réalité.
« Ce qu'on a apporté, c'est la capacité à se structurer, à mettre des mots, mettre des définitions, mettre des process là où personne n'avait réussi à les formaliser en interne. »
— Donatien Lefranc, fondateur de Leando
Comment lire et négocier un SLA quand on n'est pas DSI
Diriger une PME ne signifie pas avoir les compétences d'un DSI, mais ça ne vous dispense pas de comprendre ce que vous signez. Un SLA se négocie sur 5 points. Négocier seulement les seuils de disponibilité sans toucher aux 4 autres, c'est optimiser l'accessoire.
Négocier la définition avant le seuil
Avant de discuter si la disponibilité doit être 99,9% ou 99,95%, demandez comment elle est calculée. Sur quelle période (mensuelle, annuelle) ? Les maintenances programmées sont-elles incluses ou exclues ? Quelle est la méthode de monitoring ? Deux SLA à 99,9% calculés différemment n'offrent pas la même garantie réelle. La définition de l'indicateur est plus importante que son seuil.
Cartographier les dépendances avant de signer
Listez tous les systèmes et services dont dépend votre activité. Pour chacun, identifiez qui en est responsable. Votre prestataire IT gère les serveurs, mais qui gère votre opérateur réseau ? Qui gère l'éditeur de votre ERP ? Chaque dépendance non couverte par le SLA est un angle mort. Ce n'est pas forcément un problème, mais c'est une décision consciente à prendre.
Vérifier les clauses d'exclusion avec le même soin que les engagements
Les clauses d'exclusion sont souvent rédigées dans un langage technique dense, en fin de document. C'est là que se joue une grande partie du contrat réel. « Force majeure », « défaillance imputable au client », « dépendances tierces » : chaque formulation peut invalider une pénalité en cas d'incident. Lisez ces clauses aussi attentivement que les SLO (objectifs de niveau de service).
Inclure une clause de révision annuelle
Votre activité évolue. Un SLA signé pour un SI de 20 utilisateurs peut être inadapté 18 mois plus tard quand vous en avez 80. Prévoyez contractuellement une révision annuelle. Ce n'est pas une méfiance envers votre prestataire, c'est une reconnaissance que le contexte change.
Pour aller plus loin sur le choix de votre prestataire IT, consultez notre guide agence, freelance ou cabinet conseil : comment choisir et notre comparatif ESN vs cabinet conseil en 2026.
La face cachée du SLA : indicateurs métier versus indicateurs techniques
Un SLA classique mesure la performance technique de l'infrastructure. Il ne mesure pas ce qui compte réellement pour votre activité. C'est la différence entre un indicateur technique (le serveur est disponible) et un indicateur métier (le processus de commande fonctionne de bout en bout).
Un serveur peut être disponible à 100% et votre processus métier critique être en panne parce qu'une intégration API a silencieusement cessé de fonctionner. Un SLA purement technique ne verra pas cet incident. Votre activité, elle, le subira.
Indicateurs techniques (SLA standard)
- Disponibilité serveur : 99,9%
- Temps de réponse réseau : < 50ms
- RTO : 4h pour P1
- RPO : 24h
- Espace disque disponible : > 20%
Indicateurs métier (ce qui compte vraiment)
- Le processus de commande fonctionne de bout en bout
- Les synchronisations ERP-CRM s'exécutent sans erreur
- Les rapports de fin de mois s'exportent dans les délais
- Les accès utilisateurs sont opérationnels en heure d'ouverture
- Les sauvegardes sont testées et restaurables
La bonne pratique est de compléter le SLA technique avec un ensemble de tests de smoke fonctionnels : des scénarios métier critiques qui s'exécutent automatiquement à intervalles réguliers et alertent si l'un d'eux échoue. Ce n'est pas du ressort exclusif du prestataire ; c'est une responsabilité partagée que peu de contrats formalisent.
Sur ce point, notre article sur les 7 erreurs classiques du développement sur mesure décrit comment l'absence de tests fonctionnels de référence crée des angles morts invisibles en production.
Ce que change un SI documenté sur la capacité à tenir ses engagements
Un SLA, du côté prestataire, ne se tient pas uniquement grâce à une bonne infrastructure. Il se tient grâce à des processus clairs : qui fait quoi en cas d'incident P1, comment l'escalade se déclenche, où sont les runbooks de résolution, comment les accès sont documentés pour éviter la dépendance à une personne-clé.
Du côté client, c'est symétrique. Si votre SI fonctionne sur des processus implicites, si les règles métier ne sont formalisées nulle part, si la connaissance critique est dans les têtes de deux ou trois personnes, votre capacité à participer à la résolution rapide d'un incident est limitée, quelles que soient les bonnes intentions des deux parties.
« Il fonctionnait énormément sur le fait que si un collaborateur était pas là, bah potentiellement on mettait certains aspects en pause. Et ça, je pense que c'est très révélateur de beaucoup d'entreprises. »
— Donatien Lefranc, fondateur de Leando
Ce n'est pas un problème de volonté. C'est un problème de structure. Une entreprise dont les processus reposent sur des individus non remplaçables ne peut pas tenir un SLA en dehors de la présence de ces individus. Elle peut l'avoir signé, mais la capacité opérationnelle n'est pas là.
La formalisation des processus, des règles métier et de la documentation technique n'est pas un luxe de grande entreprise. C'est un prérequis pour que les engagements contractuels aient une réalité opérationnelle. La dette technique et la dette de documentation sont les deux faces du même problème : des décisions prises sans être formalisées, qui deviennent des risques silencieux.
Cas réel : quand la documentation devient la preuve que les engagements tiennent
Voici un cas concret qui illustre le lien entre formalisation des processus et capacité à honorer des engagements de niveau de service, dans un contexte plus large que l'IT opérationnel.
Fournisseur d'énergie ETI, filiale d'un groupe suisse
Cette ETI française, filiale d'un groupe suisse, est soumise à des audits IT internes annuels menés par un cabinet mandaté par la maison mère. En 2024, l'audit avait été décevant. Les processus existaient dans les pratiques quotidiennes des équipes, mais pas dans les documents. Les règles métier n'étaient pas explicites. Les engagements de niveau de service vivaient dans les têtes, pas dans les contrats.
Après 4 à 5 mois de travail avec Leando (modélisation BPMN des processus clés, formalisation explicite des règles de validation, approche documentation first sur l'ensemble du SI), l'audit 2026 a donné un résultat radicalement différent. Le cabinet d'audit suisse a pu s'appuyer sur des documents concrets, des processus tracés, des décisions formalisées.
Le responsable technique a résumé la différence en deux mots : « jour et nuit ». Ce n'était pas un changement d'infrastructure. C'était un changement de maturité documentaire.
« Quand Olivier nous a expliqué que sur cet audit de 2026, ils avaient pu rassurer le cabinet d'audit du groupe en leur montrant le travail qu'on faisait, la documentation qu'on avait créée, vu qu'on a une approche de documentation first, et que ça avait vraiment permis de faire le jour et la nuit dans la manière de livrer cet audit. »
— Donatien Lefranc, fondateur de Leando
Ce cas illustre un principe que les SLA formulent mais n'enseignent pas : un engagement ne vaut que s'il est adossé à une organisation capable de le tenir. La disponibilité d'un système ne se gère pas uniquement au niveau de l'infrastructure. Elle se gère aussi au niveau des processus, de la documentation et de la capacité à intervenir sans dépendre d'une personne irremplaçable.
Sur les ETI et PME confrontées à des audits ou à des transformations SI, notre guide sur la modernisation du SI d'une PME détaille les étapes et les pièges à éviter.
Checklist pratique
Avant de signer ou renouveler un SLA
Pour aller plus loin
Les 7 erreurs classiques du développement sur mesure
Les pièges qui créent des angles morts invisibles en production.
Agence, freelance ou cabinet : comment choisir ?
Comparer les modèles de prestation avant de s'engager.
ESN vs cabinet conseil en 2026
Quel type de prestataire pour quel niveau d'engagement ?
Vibe coding et dette technique : le danger invisible
Comment la dette technique fragilise vos engagements de service.
Les questions qu'on nous pose le plus souvent
Questions fréquentes sur le SLA informatique
Un SLA (Service Level Agreement), ou accord de niveau de service, est un contrat qui formalise les engagements d'un prestataire IT sur des indicateurs mesurables : disponibilité, temps de réponse en cas d'incident, délai de résolution. Il détermine aussi les pénalités applicables si ces seuils ne sont pas tenus. Un SLA n'est utile que si les indicateurs sont mesurables, les périmètres de responsabilité clairement définis, et les processus internes suffisamment matures pour les honorer.
Passez à l'action
Votre SI est prêt à tenir un SLA ?
Leando audite vos processus, votre documentation et vos dépendances systèmes. Vous repartez avec un diagnostic clair sur votre capacité réelle à tenir vos engagements de niveau de service.
Demander un diagnostic gratuit