Qu’est-ce qu’un SLA en infogérance ?
Un SLA (Service Level Agreement) est un engagement contractuel qui définit le niveau de service qu’un prestataire d’infogérance s’engage à fournir. Ce n’est pas une promesse marketing. C’est un document juridique, mesurable, avec des conséquences financières en cas de non-respect.
Dans la pratique, beaucoup de PME signent des contrats d’infogérance sans regarder de près les SLA. Elles découvrent le problème quand un serveur tombe un vendredi soir et que personne ne répond avant le lundi matin. Ou quand une panne dure six heures alors qu’elles pensaient avoir droit à une intervention en deux heures.
Le SLA est le seul élément du contrat qui traduit les engagements en obligations mesurables. Sans SLA structuré, un contrat d’infogérance n’est qu’une déclaration d’intention. C’est pourquoi le choix d’un prestataire informatique ne peut pas se faire uniquement sur le prix mensuel.
67 %
des PME n’ont jamais lu intégralement les SLA de leur contrat d’infogérance
4,2 h
Durée moyenne d’indisponibilité avant qu’une PME ne contacte son prestataire
23 000 €
Coût moyen d’une heure d’arrêt IT pour une PME de 50 salariés
99,9 %
Taux de disponibilité standard — soit 8h45 d’arrêt autorisé par an
Les six indicateurs SLA à contrôler
Un bon contrat d’infogérance définit des indicateurs précis, mesurables et assortis de conséquences. Voici les six indicateurs incontournables.
1. La GTI — Garantie de Temps d’Intervention
La GTI définit le délai maximum entre la déclaration d’un incident et la première action du prestataire. Attention : intervenir ne signifie pas résoudre. La GTI mesure la réactivité, pas l’efficacité.
Un prestataire qui promet une GTI de 4 heures s’engage à ce qu’un technicien prenne en charge le ticket dans ce délai. Il ne s’engage pas à ce que le problème soit résolu. C’est une distinction fondamentale que beaucoup de PME découvrent trop tard.
Les GTI standards du marché :
- Incident critique (production arrêtée) — 30 minutes à 1 heure
- Incident majeur (dégradation significative) — 2 à 4 heures
- Incident mineur (gêne limitée) — 8 heures à 1 jour ouvré
- Demande standard (amélioration, configuration) — 2 à 5 jours ouvrés
2. La GTR — Garantie de Temps de Rétablissement
La GTR est l’indicateur le plus critique. Elle définit le délai maximum entre la déclaration de l’incident et le retour à un fonctionnement normal. C’est la GTR qui détermine combien de temps votre activité peut être interrompue.
Exiger une GTR courte coûte plus cher, car elle implique des ressources disponibles en permanence, du matériel de remplacement, et des procédures de basculement testées. Mais c’est aussi la GTR qui détermine votre capacité de résilience. Ce sujet rejoint directement la logique de plan de reprise d’activité (PRA/PCA).
| Niveau de criticité | GTI recommandée | GTR recommandée | Plage horaire |
|---|---|---|---|
| P1 — Critique | 30 min | 4 heures | 24/7 |
| P2 — Majeur | 2 heures | 8 heures | 24/7 ou HO |
| P3 — Mineur | 4 heures | 24 heures | Heures ouvrées |
| P4 — Standard | 1 jour ouvré | 5 jours ouvrés | Heures ouvrées |
3. Le taux de disponibilité
Le taux de disponibilité mesure le pourcentage de temps où le service est opérationnel sur une période donnée. C’est l’indicateur le plus cité dans les contrats d’infogérance, et aussi le plus mal compris.
La différence entre 99 % et 99,99 % semble minime. En réalité, elle représente un écart considérable en temps d’indisponibilité autorisé :
| Taux de disponibilité | Indisponibilité annuelle autorisée | Indisponibilité mensuelle | Niveau |
|---|---|---|---|
| 99 % | 3 jours 15 heures | 7 heures 18 min | Insuffisant pour production |
| 99,5 % | 1 jour 19 heures | 3 heures 39 min | Minimum acceptable |
| 99,9 % | 8 heures 45 min | 43 min | Standard marché |
| 99,95 % | 4 heures 22 min | 22 min | Exigeant |
| 99,99 % | 52 min | 4 min | Très élevé (coûteux) |
Vérifiez si le taux de disponibilité est calculé sur les heures ouvrées (HO) ou sur la totalité du temps (24/7) — c’est le piège le plus fréquent. Un prestataire qui annonce 99,9 % en HO (lundi-vendredi 8h-18h) ne s’engage sur rien le week-end. Si votre activité tourne en continu, exigez un engagement 24/7.
4. Les pénalités contractuelles
Un SLA sans pénalité est un engagement sans conséquence. Les pénalités sont le mécanisme qui donne une valeur réelle aux engagements de service. Elles doivent être automatiques, progressives et plafonnées.
Le modèle le plus courant :
- Dépassement GTR de 0 à 2 heures — 5 % de crédit sur la facture mensuelle
- Dépassement de 2 à 4 heures — 10 % de crédit
- Dépassement supérieur à 4 heures — 20 % de crédit
- Disponibilité mensuelle inférieure à 99 % — 15 % de crédit
- Plafond — généralement 30 % du montant mensuel
Attention aux contrats qui prévoient des pénalités « sur demande ». Si le client doit les réclamer, il ne les obtiendra presque jamais. Exigez l’application automatique, avec un reporting mensuel intégré au contrat.
5. Le périmètre d’intervention
Un SLA ne vaut que pour ce qu’il couvre. Le périmètre doit être défini avec précision :
- Équipements couverts — serveurs, postes, réseau, stockage, imprimantes, téléphonie
- Logiciels couverts — systèmes d’exploitation, applications métier, messagerie, sauvegarde
- Plages horaires — heures ouvrées (HO), heures non ouvrées (HNO), 24/7
- Canaux de déclaration — téléphone, email, portail, outil ITSM
- Exclusions explicites — développement, formation, matériel personnel, réseaux tiers
Un prestataire d’infogérance couvre généralement l’infrastructure et les systèmes. Mais pas les applications métier spécifiques. Si votre ERP ou votre logiciel de production est critique, vérifiez qu’il entre dans le périmètre du SLA ou qu’un contrat spécifique existe avec l’éditeur.
6. Le reporting et les revues de service
Ce qui ne se mesure pas ne s’améliore pas. Un bon SLA prévoit :
- Un rapport mensuel détaillant les incidents, les temps de résolution, le taux de disponibilité constaté, et les éventuelles pénalités appliquées
- Un comité de pilotage trimestriel pour analyser les tendances, les points d’amélioration et ajuster les priorités
- Un accès en temps réel aux tickets et à leur statut via un portail ou un outil ITSM
Sans ce suivi, le respect des SLA est invérifiable. Un prestataire sérieux fournit ces rapports sans qu’on les lui demande. Si les rapports doivent être réclamés, c’est un signal d’alerte. Ce point rejoint la question plus large de la nécessité d’un audit IT : l’absence de reporting est souvent le premier signe d’un partenariat qui dérive.
Les pièges classiques des SLA d’infogérance
L’expérience montre que certains pièges reviennent systématiquement dans les contrats d’infogérance. Les connaître, c’est les éviter.
Le SLA « best effort »
Certains contrats mentionnent des « objectifs de service » plutôt que des « engagements de service ». La différence est juridique et fondamentale : un objectif est une intention, un engagement est une obligation. Si le contrat parle de « meilleurs efforts » ou « best effort », le prestataire ne s’engage concrètement à rien.
Les exclusions cachées
Les cas d’exclusion du SLA méritent une lecture attentive. Les plus fréquents :
- « Force majeure » — légitime pour un tremblement de terre, abusive si elle couvre les pannes d’un hébergeur tiers
- « Maintenance programmée » — vérifiez que les fenêtres de maintenance ne sont pas comptabilisées comme du temps d’indisponibilité autorisé
- « Cause extérieure » — un prestataire qui s’exonère de toute responsabilité en cas de panne opérateur internet ou cloud ne fournit pas un service d’infogérance, il fournit un service partiel
Le piège de la GTI sans GTR
Certains contrats ne contiennent qu’une GTI, sans aucune GTR. Le prestataire s’engage à réagir vite mais pas à résoudre vite. Résultat : un technicien prend le ticket en 30 minutes, mais la résolution prend trois jours. Techniquement, le SLA est respecté. Fonctionnellement, l’entreprise est à l’arrêt.
Comment négocier ses SLA : la méthode
Négocier un SLA n’est pas un exercice d’achat classique. C’est un travail d’analyse préalable qui dépend de la criticité réelle de votre infrastructure IT.
Étape 1 : cartographier la criticité de vos systèmes
Tous vos systèmes ne méritent pas le même niveau de SLA. Un serveur de fichiers partagé n’a pas la même criticité qu’un ERP de production. Classez vos équipements et logiciels en trois catégories :
- Critique — arrêt = arrêt de production ou de facturation
- Important — arrêt = dégradation significative mais contournable
- Standard — arrêt = gêne limitée
Cette classification détermine les GTI et GTR à exiger pour chaque catégorie. Si votre infrastructure est vieillissante, commencez par un diagnostic de vos équipements avant de négocier les SLA.
Étape 2 : chiffrer le coût d’indisponibilité
Le calcul est simple mais rarement fait : combien coûte une heure d’arrêt de votre système d’information ? Prenez en compte :
- Le coût salarial des collaborateurs bloqués
- Le manque à gagner commercial (commandes non traitées, clients perdus)
- Les pénalités de retard éventuelles vis-à-vis de vos propres clients
- Le coût de restauration des données et de remédiation
Ce chiffre détermine le budget maximal à investir dans un SLA exigeant. Si une heure d’arrêt coûte 20 000 €, payer 500 €/mois de plus pour passer d’une GTR de 8 heures à 4 heures est un investissement rentable.
Étape 3 : comparer les offres sur les mêmes bases
Quand vous mettez en concurrence plusieurs prestataires, normalisez les critères de comparaison. Utilisez une grille identique :
- GTI par niveau de criticité (P1 à P4) et plage horaire (HO / 24/7)
- GTR par niveau de criticité avec précision sur le périmètre couvert
- Taux de disponibilité garanti avec mode de calcul explicite (HO ou 24/7)
- Pénalités automatiques en cas de dépassement GTI ou GTR
- Pénalités automatiques en cas de non-respect du taux de disponibilité
- Plafond des pénalités et conditions de résiliation anticipée
- Fréquence et contenu du reporting (mensuel, trimestriel, accès portail)
- Périmètre exact : équipements, logiciels, sites couverts
- Exclusions listées et justifiées
- Clause de révision annuelle des SLA
Cette démarche structurée est la même que celle recommandée pour toute décision d’externalisation IT. Les SLA ne sont qu’un volet du contrat global, mais c’est le volet qui détermine la qualité opérationnelle réelle.
SLA et cybersécurité : le lien souvent oublié
Les SLA d’infogérance couvrent traditionnellement la disponibilité et la performance. Mais en 2026, la dimension cybersécurité doit être intégrée dans les engagements contractuels.
Les indicateurs de sécurité à inclure dans un SLA moderne :
- Délai de déploiement des patchs critiques — 24 à 48 heures maximum après publication par l’éditeur
- Fréquence des tests de restauration — au minimum trimestriel, avec procès-verbal
- Délai de notification en cas d’incident de sécurité — cohérent avec les obligations RGPD (72 heures)
- RPO/RTO — objectifs de perte de données (Recovery Point Objective) et de temps de reprise (Recovery Time Objective) formalisés
Un prestataire d’infogérance qui ne peut pas formaliser ces engagements n’a pas la maturité sécurité nécessaire pour gérer une infrastructure critique.
Quand réviser ses SLA
Un SLA n’est pas un document figé. Il doit évoluer avec votre entreprise. Trois situations imposent une révision :
- Croissance de l’effectif — passer de 20 à 80 collaborateurs change la criticité de l’infrastructure
- Migration vers le cloud — l’adoption d’un cloud hybride modifie le périmètre et les responsabilités
- Nouvelles obligations réglementaires — la directive NIS2 ou les exigences sectorielles peuvent imposer des niveaux de service plus élevés
Prévoyez une clause de révision annuelle dans le contrat. C’est le moment de revalider la pertinence des GTI, GTR et taux de disponibilité au regard de l’évolution de votre activité.
Comparez les prestataires IT adaptés à votre besoin sur notre comparateur gratuit. Diagnostic IA et 3 à 5 devis vérifiés instantanément dès la qualification.