Un SLA cloud pour applications critiques ne doit pas se limiter à un pourcentage de disponibilité affiché dans une plaquette commerciale. Pour être utile, il doit préciser ce qui est mesuré, depuis quel point, sur quelle période, avec quelles exclusions, quels délais d’intervention, quels objectifs de reprise et quelles preuves seront fournies en cas d’incident.
Pour une entreprise ou une collectivité en Martinique, Guadeloupe ou Guyane, l’enjeu est concret : un ERP indisponible, une application métier bloquée ou une plateforme de relation usagers inaccessible peut interrompre l’activité, retarder la facturation, dégrader le service rendu et mobiliser les équipes dans l’urgence. Le SLA doit donc être lu comme un outil de maîtrise du risque, pas comme une simple clause contractuelle.
Qu’est-ce qu’un SLA cloud ?
Un SLA, pour Service Level Agreement, est un engagement de niveau de service entre un fournisseur cloud, un prestataire informatique ou un infogérant et son client. Il décrit les niveaux attendus pour un service donné : disponibilité, temps de prise en charge, délai de rétablissement, performance, sauvegarde, sécurité, reporting et modalités d’escalade.
Dans le cloud, le SLA est souvent plus complexe que dans une infrastructure locale classique, car plusieurs acteurs peuvent intervenir : hébergeur, opérateur télécom, fournisseur SaaS, prestataire d’infogérance, éditeur métier et équipe interne. Une indisponibilité ressentie par les utilisateurs peut venir d’une panne cloud, d’un problème réseau, d’une mauvaise configuration, d’un pare-feu, d’un lien internet ou d’une dépendance applicative.
C’est pourquoi un bon SLA cloud doit distinguer clairement :
- Le périmètre couvert par le contrat
- Les composants inclus et exclus
- Les horaires de support
- Les engagements de disponibilité
- Les engagements de reprise d’activité
- Les responsabilités du client, du prestataire et des fournisseurs tiers
- Les preuves de supervision et les rapports fournis
L’ANSSI rappelle dans ses recommandations sur l’externalisation et la sécurité des systèmes d’information l’importance de formaliser les responsabilités, les exigences de sécurité, la réversibilité et le contrôle des prestations externalisées. Ces principes s’appliquent pleinement aux environnements cloud.
Commencez par classer vos applications critiques
Avant d’exiger un niveau de SLA, il faut définir ce qui est réellement critique. Toutes les applications ne nécessitent pas le même niveau d’engagement, car chaque niveau supérieur de disponibilité ou de reprise entraîne généralement plus de complexité, plus de supervision et plus de coûts.
Une application critique est une application dont l’indisponibilité provoque rapidement un impact métier important : arrêt de production, impossibilité de facturer, rupture de service public, perte de chiffre d’affaires, atteinte à l’image, risque de non-conformité ou blocage d’un site distant.
Pour un décideur, la question n’est pas seulement technique. Elle doit être formulée en termes métier : combien de temps l’organisation peut-elle fonctionner sans cette application, combien de données peut-elle accepter de perdre et quelles équipes sont touchées en cas d’arrêt ?
Une cartographie de criticité peut distinguer trois niveaux simples.
| Niveau de criticité | Exemples d’applications | Impact d’une panne | Niveau de SLA attendu |
|---|---|---|---|
| Critique | ERP, gestion de production, dossiers patients, services aux usagers, applications financières | Activité fortement perturbée ou arrêtée | Disponibilité élevée, support étendu, RTO/RPO formalisés, supervision proactive |
| Important | Messagerie, outils collaboratifs, applications RH, portail interne | Perte de productivité, retards opérationnels | Engagements clairs, reprise organisée, reporting régulier |
| Standard | Archivage, applications secondaires, outils non urgents | Impact limité à court terme | SLA plus simple, support sur horaires ouvrés possible |
Cette classification est indispensable avant un contrat cloud. Elle évite de payer un niveau très élevé pour des services peu sensibles et, à l’inverse, de sous-protéger une application qui conditionne la continuité d’activité.
Disponibilité cloud : ne vous arrêtez pas au pourcentage
La disponibilité est le SLA le plus visible. Un fournisseur peut annoncer 99,9 %, 99,95 % ou 99,99 %. Ces chiffres semblent proches, mais leur impact métier est très différent.
| Disponibilité annoncée | Indisponibilité maximale sur 30 jours | Indisponibilité maximale sur 1 an | Lecture métier |
|---|---|---|---|
| 99,5 % | 3 h 36 min | 1 j 19 h 48 min | Acceptable seulement pour des services peu critiques |
| 99,9 % | 43 min 12 s | 8 h 45 min 36 s | Courant, mais à analyser pour les applications sensibles |
| 99,95 % | 21 min 36 s | 4 h 22 min 48 s | Plus adapté à des services importants |
| 99,99 % | 4 min 19 s | 52 min 34 s | Exige une architecture plus robuste |
| 99,999 % | 26 s | 5 min 15 s | Très exigeant, rarement nécessaire sans justification métier forte |
Le point clé : il faut savoir comment ce pourcentage est calculé. Une disponibilité mesurée au niveau de l’infrastructure cloud ne garantit pas forcément que l’application métier est accessible pour les utilisateurs de Fort-de-France, Baie-Mahault ou Cayenne.
Vérifiez notamment :
- La période de mesure, mensuelle ou annuelle
- Le périmètre mesuré, serveur, plateforme, application ou service complet
- Les fenêtres de maintenance exclues du calcul
- Les incidents exclus, par exemple réseau client, mauvaise configuration ou panne d’un tiers
- Le point de mesure, depuis le datacenter, internet public ou un site utilisateur
- La procédure de déclaration d’incident et de contestation
Pour une application critique, privilégiez un SLA qui mesure le service rendu de bout en bout, ou qui précise au minimum les dépendances techniques nécessaires au fonctionnement réel de l’application.
RTO et RPO : les deux indicateurs à exiger absolument
La disponibilité ne répond pas à deux questions essentielles : combien de temps faudra-t-il pour redémarrer après un incident majeur et combien de données peut-on perdre ? C’est le rôle du RTO et du RPO.
Le RTO, Recovery Time Objective, correspond à la durée maximale cible pour rétablir un service après incident. Si le RTO est de 4 heures, l’organisation accepte en principe que l’application soit indisponible jusqu’à 4 heures dans un scénario couvert.
Le RPO, Recovery Point Objective, correspond à la perte de données maximale acceptable. Si le RPO est de 1 heure, les sauvegardes ou réplications doivent permettre de revenir à un état datant d’une heure au maximum avant l’incident.
Ces deux indicateurs doivent être définis par application, pas uniquement pour l’environnement cloud global. Une application de gestion commerciale et un outil d’archivage n’ont pas les mêmes exigences.
| Question métier | Indicateur correspondant | Exemple d’exigence à formaliser |
|---|---|---|
| Combien de temps pouvons-nous rester arrêtés ? | RTO | L’application doit être restaurée sous un délai cible défini selon sa criticité |
| Combien de données pouvons-nous perdre ? | RPO | Les sauvegardes ou réplications doivent limiter la perte de données à un seuil accepté |
| Qui déclenche la reprise ? | Procédure PRA | Les rôles, contacts et validations doivent être documentés |
| Comment vérifier que cela fonctionne ? | Test de restauration | Des tests réguliers doivent être planifiés et tracés |
Pour les applications critiques, un SLA sans RTO ni RPO est incomplet. Il indique éventuellement que la plateforme est disponible en temps normal, mais il ne dit pas comment l’activité reprend après panne majeure, erreur humaine, cyberattaque ou incident sur une zone d’hébergement.
Support cloud : exigez des délais de prise en charge et d’escalade
Un SLA cloud utile doit distinguer le temps de prise en compte, le temps de diagnostic, le temps de contournement et le temps de résolution. Un engagement qui promet seulement une réponse rapide ne suffit pas si aucune escalade n’est prévue lorsque l’incident bloque l’activité.
Pour une application critique, le contrat doit préciser les niveaux de priorité. Par exemple, un incident bloquant tous les utilisateurs ne doit pas être traité comme une demande de changement mineure. Les critères de gravité doivent être partagés entre les métiers, la DSI et le prestataire.
Les points à vérifier sont les suivants :
- Horaires de support, notamment soir, week-end et jours fériés si l’activité l’exige
- Canal de déclaration, portail, téléphone, supervision automatique ou astreinte
- Délai de prise en charge selon la criticité
- Délai d’escalade vers un niveau technique supérieur
- Communication pendant l’incident, avec fréquence des points de situation
- Compte rendu post-incident pour les événements majeurs
Dans les Antilles-Guyane, la disponibilité du support doit aussi être pensée avec le contexte local : décalages avec certains fournisseurs, sites multisites, dépendance à la connectivité, contraintes d’intervention et besoin d’un interlocuteur capable de comprendre la réalité opérationnelle locale. Pour approfondir ce sujet, l’article sur l’assistance cloud à prévoir après la mise en production détaille les volets de support à anticiper une fois l’environnement en exploitation.
Performance, latence et connectivité : le SLA ne doit pas couvrir seulement les pannes
Une application peut être techniquement disponible mais trop lente pour être utilisable. Pour des équipes réparties entre Martinique, Guadeloupe et Guyane, ou entre plusieurs sites administratifs, la performance réseau devient une condition de continuité.
Le SLA doit donc inclure, lorsque c’est pertinent, des indicateurs de performance : temps de réponse applicatif, latence réseau, débit, disponibilité des liens, performance du stockage, capacité de montée en charge et surveillance des ressources. Ces indicateurs doivent être adaptés à l’usage. Une application comptable n’a pas les mêmes besoins qu’une plateforme transactionnelle ou qu’un système de fichiers partagé entre plusieurs agences.
Lorsque vos utilisateurs accèdent à des applications hébergées hors du territoire, la latence peut devenir sensible. À l’inverse, un hébergement plus proche des usages peut améliorer certains scénarios, mais il doit être évalué avec les mêmes exigences de disponibilité, de sauvegarde, de sécurité et de réversibilité. Le choix entre cloud local, cloud public ou architecture hybride doit donc être relié à vos contraintes métier. Vous pouvez compléter cette analyse avec ce guide sur le choix d’un datacenter cloud pour des applications critiques.
Sécurité : quels engagements intégrer dans un SLA cloud ?
La sécurité n’est pas toujours rédigée dans le même document que le SLA, mais elle doit être contractualisée. Pour une application critique, il faut savoir qui surveille, qui alerte, qui corrige et qui prend les décisions en cas de menace.
Le SLA doit couvrir au minimum la gestion des accès, la journalisation, la supervision, la gestion des vulnérabilités, les sauvegardes, la restauration et les procédures d’incident. Il doit aussi rappeler le modèle de responsabilité partagée : le fournisseur cloud sécurise certains composants, mais le client ou son prestataire reste responsable de la configuration, des comptes, des droits, des applications, des données et des usages selon le modèle retenu.
Pour les données personnelles, la CNIL recommande des mesures de sécurité adaptées, notamment la gestion des habilitations, la sauvegarde, la traçabilité et la protection contre les accès non autorisés. Dans un contrat cloud, ces exigences doivent être traduites en mesures opérationnelles vérifiables.
Les engagements de sécurité à discuter peuvent inclure :
- Délai de notification en cas d’incident de sécurité détecté
- Conservation et accès aux journaux techniques
- Suivi des correctifs de sécurité
- Protection contre les malwares et ransomwares selon le périmètre confié
- Fréquence des tests de restauration
- Gestion des comptes à privilèges
- Procédure d’isolement d’un système compromis
Aucun SLA ne garantit l’absence d’attaque. En revanche, il peut réduire les zones floues, accélérer la réaction et clarifier les responsabilités quand chaque minute compte.
Sauvegarde et restauration : exigez des preuves, pas seulement une promesse
Beaucoup d’organisations disposent de sauvegardes, mais découvrent trop tard qu’elles sont incomplètes, trop anciennes ou difficiles à restaurer. Pour une application critique, le SLA doit préciser non seulement la fréquence de sauvegarde, mais aussi les conditions de restauration.
Les points à formaliser sont simples : quelles données sont sauvegardées, à quelle fréquence, avec quelle rétention, où elles sont stockées, comment elles sont protégées, qui peut demander une restauration et sous quel délai cible. Les sauvegardes doivent être alignées avec le RPO. Si le RPO attendu est court, une sauvegarde quotidienne ne suffit pas.
Un bon contrat prévoit aussi des tests. Sans test de restauration, le dispositif reste théorique. Ces tests doivent être documentés, avec un compte rendu, les éventuels écarts constatés et les actions correctives.
Maintenance, changements et mises à jour : évitez les interruptions mal maîtrisées
Les fenêtres de maintenance sont souvent exclues du calcul de disponibilité. C’est normal, mais elles doivent être encadrées. Pour des applications critiques, une maintenance planifiée au mauvais moment peut avoir autant d’impact qu’une panne.
Le contrat doit préciser les délais de préavis, les horaires possibles, les modalités de validation, les tests avant changement, les plans de retour arrière et la communication aux utilisateurs. Les changements applicatifs, réseau, sécurité ou infrastructure doivent être suivis dans un processus clair.
Pour les environnements sensibles, il est préférable de séparer les changements standards, les changements urgents et les changements majeurs. Cette distinction limite les décisions improvisées et permet de mieux protéger les périodes d’activité forte, par exemple clôture comptable, campagne administrative, inventaire, saison touristique ou période de paie.
Réversibilité : un SLA cloud doit prévoir la sortie
La réversibilité est parfois négligée au moment de signer, alors qu’elle devient essentielle en cas de changement de prestataire, de migration, d’insatisfaction ou d’évolution stratégique. Un SLA cloud doit expliquer comment récupérer les données, les configurations, les journaux et les éléments nécessaires à la continuité.
À vérifier avant signature : format d’export, délais, coûts éventuels, accompagnement, suppression des données après restitution, documentation fournie et dépendances propriétaires. Pour une collectivité ou une PME fortement dépendante d’un outil métier, la réversibilité est une protection contre l’enfermement technique.
Elle doit être testable. Un engagement général du type restitution des données sur demande est insuffisant si les formats, délais et responsabilités ne sont pas précisés.
Pénalités, avoirs de service et gouvernance : utiles, mais insuffisants
Les pénalités associées aux SLA prennent souvent la forme d’avoirs de service. Elles peuvent inciter le fournisseur à respecter ses engagements, mais elles ne compensent généralement pas les pertes métier liées à une panne critique : chiffre d’affaires perdu, agents immobilisés, retard de production ou atteinte à la réputation.
Il faut donc voir les pénalités comme un mécanisme de gouvernance, pas comme une stratégie de continuité. Le plus important reste la prévention, la supervision, les architectures redondantes, les procédures de reprise et les tests.
Le contrat doit aussi prévoir un pilotage régulier : comité de service, revue des incidents, suivi des indicateurs, analyse des tendances, plan d’amélioration et arbitrage des risques. Sans gouvernance, même un SLA bien rédigé peut rester inutilisé.
Checklist des SLA cloud à demander pour une application critique
Avant de valider un contrat cloud, demandez une réponse écrite sur les points suivants.
| Domaine | Questions à poser | Pourquoi c’est important |
|---|---|---|
| Disponibilité | Quel service est mesuré, sur quelle période et avec quelles exclusions ? | Éviter un pourcentage trompeur ou trop limité |
| RTO | Sous quel délai cible l’application peut-elle être rétablie ? | Mesurer l’impact maximal d’un arrêt |
| RPO | Quelle perte de données maximale est acceptable et techniquement couverte ? | Aligner sauvegarde, réplication et métier |
| Support | Quels délais de prise en charge selon la gravité ? | Accélérer la réaction en cas d’incident |
| Escalade | Qui intervient si le premier niveau ne résout pas ? | Éviter le blocage opérationnel |
| Sécurité | Quels journaux, alertes, correctifs et notifications sont prévus ? | Clarifier les responsabilités cyber |
| Sauvegarde | Les restaurations sont-elles testées et tracées ? | Prouver que la reprise est possible |
| Maintenance | Les changements sont-ils planifiés, validés et réversibles ? | Réduire les interruptions évitables |
| Réversibilité | Comment récupérer données et configurations ? | Garder la maîtrise du système d’information |
| Reporting | Quels indicateurs sont fournis et à quelle fréquence ? | Piloter le contrat dans la durée |
Cette checklist peut aussi servir de base à un audit contractuel ou technique. Si votre environnement est déjà en production, un audit cloud avant validation de l’environnement permet d’identifier les écarts entre les engagements annoncés et la réalité opérationnelle.
Quels SLA cloud exiger selon votre profil d’organisation ?
Une TPE avec une application de gestion hébergée n’a pas les mêmes besoins qu’une collectivité multisite, qu’une PME industrielle ou qu’un groupe présent sur plusieurs territoires. La bonne démarche consiste à partir des processus métier, puis à traduire leur criticité en exigences techniques.
Pour une PME, les priorités sont souvent la continuité de facturation, la messagerie, l’accès aux fichiers, la protection contre les ransomwares et la disponibilité des applications de gestion. Pour une collectivité, il faut ajouter la continuité de service aux administrés, la protection des données, la traçabilité et la gestion des accès. Pour une organisation multisite, la connectivité, la redondance réseau et la supervision deviennent centrales.
En Antilles-Guyane, la conception du SLA doit aussi intégrer l’éloignement géographique, la dépendance à certains liens télécoms, les contraintes d’intervention, les risques climatiques et la nécessité d’un support réactif. Un engagement pertinent sur le papier doit rester applicable dans les conditions réelles d’exploitation.
FAQ
Un SLA cloud à 99,9 % suffit-il pour une application critique ? Pas toujours. 99,9 % peut représenter jusqu’à 43 minutes d’indisponibilité sur 30 jours ou plus de 8 heures sur un an. Pour une application critique, il faut surtout vérifier le périmètre mesuré, les exclusions, le RTO, le RPO et les procédures d’incident.
Quelle est la différence entre SLA, RTO et RPO ? Le SLA définit les engagements de service. Le RTO précise le délai cible de rétablissement après incident. Le RPO précise la perte de données maximale acceptable. Une application peut avoir un bon taux de disponibilité mais un RTO ou un RPO inadapté.
Le fournisseur cloud est-il responsable de toute indisponibilité ? Non. La responsabilité dépend du contrat et de l’architecture. Une panne peut venir du fournisseur cloud, du réseau, de la configuration, de l’application, d’un compte compromis ou d’un équipement local. Le SLA doit clarifier ces responsabilités.
Faut-il un support 24/7 pour toutes les applications cloud ? Non. Le support 24/7 doit être réservé aux services dont l’indisponibilité hors horaires ouvrés crée un impact réel. Pour les applications moins critiques, un support sur horaires étendus ou ouvrés peut suffire.
Comment vérifier qu’un SLA cloud est réellement respecté ? Il faut disposer de rapports de disponibilité, de tickets horodatés, de journaux d’incidents, de comptes rendus de maintenance, de tests de restauration et de comités de suivi. Sans mesure partagée, le SLA reste difficile à piloter.
Quand faut-il revoir ses SLA cloud ? Les SLA doivent être revus lors d’une migration, d’un changement d’application, d’une croissance d’activité, d’un incident majeur, d’une évolution réglementaire ou d’une modification importante de l’architecture réseau et sécurité.
Faites auditer vos SLA cloud avant qu’un incident ne les mette à l’épreuve
Un SLA cloud efficace se construit à partir de vos risques métier, de vos contraintes locales et de votre architecture réelle. Il doit couvrir la disponibilité, le support, la sécurité, la sauvegarde, la reprise d’activité, la maintenance et la réversibilité.
AITEC accompagne les entreprises et collectivités de Martinique, Guadeloupe et Guyane dans l’audit, la conception, la sécurisation et l’exploitation de leurs environnements cloud. L’objectif : aligner les engagements techniques avec la continuité de vos applications critiques, sans surdimensionner inutilement vos coûts.
Pour vérifier si vos contrats et votre architecture couvrent réellement vos besoins, vous pouvez échanger avec une équipe locale AITEC et faire auditer vos SLA cloud, vos sauvegardes et vos objectifs de reprise.
