SLA infogérance : les critères à exiger dans votre contrat

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.

Les 6 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)

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 :

Cette démarche structurée est la même que celle recommandée pour toute décision d'externalisation IT. Pour un guide complet sur l'infogérance des PME, consultez notre guide infogérance PME. 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é.