Résumé

  • Un SLA cloud ne transfère pas au fournisseur l’intégralité du risque économique d’une interruption. Il définit une mesure contractuelle et un recours calculé sur un périmètre précis. Chez Cloudflare, dans l’hypothèse illustrative ci-dessus, une heure d’interruption touchant 100 % des visiteurs conduit à un crédit d’environ 3,47 % de la redevance mensuelle récurrente du Service couvert, non à une indemnisation de la perte commerciale. (Cloudflare)
  • L’architecture fait partie du contrat économique. AWS réserve son engagement EC2 régional de 99,99 % aux déploiements dont les instances actives sont simultanément réparties sur au moins deux zones de disponibilité ; une instance isolée relève d’un engagement de 99,5 %. IBM, de son côté, distingue le SLO non contractuel du SLA ouvrant droit à crédit et montre qu’un objectif VPC à 99,999 % suppose, dans son exemple, trois serveurs répartis sur trois zones et un répartiteur de charge. (Amazon Web Services, Inc.)
  • La procédure est une composante du produit acheté. Cloudflare impose une notification rapide et des preuves détaillées ; AWS, Google et Oracle exigent eux aussi des identifiants, horaires ou journaux dans des fenêtres déterminées. Un incident techniquement réel peut donc ne produire aucun crédit si la configuration, le périmètre ou la réclamation ne satisfont pas les conditions publiées. (Cloudflare)

Le pourcentage n’est que la façade

Le « 100 % » de Cloudflare est utile précisément parce qu’il paraît absolu. Le texte Enterprise indique que le Service servira le contenu client 100 % du temps, mais le recours ne se déduit pas directement de cette phrase. Il passe par une formule. L’Affected Customer Ratio rapporte les visiteurs uniques affectés aux visiteurs uniques totaux ; la Scheduled Availability est le nombre de minutes du mois après retrait des interruptions planifiées par le client et des périodes relevant de la force majeure. Le crédit validé porte uniquement sur les redevances mensuelles récurrentes associées au Service. (Cloudflare)

Le mécanisme donne une première leçon : l’unité contractuelle n’est pas la perte d’activité du client. Elle est un sous-ensemble de la facture, modulé par une mesure de durée et, ici, par la part de visiteurs affectés. Une panne peut être grave pour une application sans que son coût économique soit proportionnel au montant du crédit ; inversement, le crédit peut être calculable même lorsqu’aucune estimation robuste de perte commerciale n’existe. Le SLA transforme donc un événement opérationnel en variable comptable selon des règles convenues d’avance.

Cette distinction est fondamentale pour comparer des offres. Une disponibilité nominale plus élevée n’implique pas automatiquement un transfert de risque plus élevé. Il faut demander : disponibilité de quoi, mesurée où, avec quelle granularité, sous quelle configuration, et contre quelle assiette de crédit ? Tant que ces questions ne sont pas résolues, deux pourcentages voisins peuvent désigner des protections économiques très différentes.

La frontière de mesure vient avant la disponibilité

Les fournisseurs illustrent plusieurs façons de tracer cette frontière. Cloudflare pondère l’interruption par la part de visiteurs uniques affectés. AWS distingue un SLA régional pour EC2 et un SLA d’instance. Google Compute Engine détermine son pourcentage de disponibilité et le crédit par projet et par région, ou par instance isolée ; une intermittence inférieure à une minute n’entre pas dans une période d’arrêt. Oracle rattache le crédit au service précis qui n’a pas respecté son engagement et à la quantité de ce service effectivement utilisée pendant la période mesurée.

Le document PaaS/IaaS d’Oracle montre en outre qu’un même cadre peut définir des engagements d’une nature différente — disponibilité, gestion ou performance — pour les services auxquels ils s’appliquent. Ce n’est pas une nuance de vocabulaire : la dimension mesurée détermine le manquement qui peut être invoqué. Et lorsqu’un même événement ouvrirait plusieurs voies de crédit sur un même service, Oracle retient en règle générale la voie donnant le montant le plus élevé, sans cumul. (甲骨文)

Ces différences ne disent pas quel fournisseur est « plus fiable ». Elles disent ce que chacun accepte de mesurer et de rembourser. Une charge de travail de bout en bout dépend presque toujours de plusieurs couches. Le SLA d’une couche ne devient pas, par simple addition, le SLA de l’application entière. Si le contrat mesure la disponibilité d’une instance, d’une région, d’un service réseau ou d’un service couvert, il ne mesure pas automatiquement la réussite de la transaction métier qui traverse ces dépendances.

C’est pourquoi une mesure utile doit rester mince et reproductible. Plus elle cherche à englober des causalités complexes, plus la discussion après incident risque de porter sur l’attribution plutôt que sur le résultat mesuré. Mais une mesure mince a son prix : elle laisse hors contrat une partie du risque réel. Cette part résiduelle ne disparaît pas ; elle reste chez l’acheteur, qui doit la traiter ailleurs.

La granularité temporelle compte aussi. Chez Google, une intermittence inférieure à une minute ne constitue pas une période d’arrêt. Chez Cloudflare, le dénominateur de disponibilité planifiée change avec la longueur du mois et avec certaines déductions. Ces règles paraissent secondaires jusqu’au moment où une équipe cherche à convertir une chronologie d’incident en droit à crédit. Ce qui était une panne dans le langage d’exploitation doit encore devenir une panne au sens du contrat.

L’architecture est une condition d’éligibilité

Le SLA n’est pas toujours une qualité attachée au service indépendamment de la façon dont il est consommé. AWS le rend explicite. L’engagement régional EC2 de 99,99 % suppose que toutes les instances actives soient déployées simultanément sur au moins deux zones de disponibilité dans la même région ; une instance seule relève d’un engagement de 99,5 %. Les mêmes paliers de crédit — 10 %, 30 % et 100 % — s’appliquent ensuite à des assiettes différentes selon que la réclamation est régionale ou porte sur une instance. (Amazon Web Services, Inc.)

Autrement dit, le chiffre de disponibilité et le coût d’architecture sont liés. Acheter l’infrastructure minimale pour exécuter une charge n’est pas nécessairement acheter la configuration requise pour bénéficier de l’engagement le plus élevé. La redondance, les zones supplémentaires et le répartiteur de charge peuvent être simultanément des choix de résilience et des préconditions pour que le contrat fonctionne comme prévu.

IBM formule cette séparation autrement. Son guide distingue les SLO, qui sont des objectifs et non des garanties contractuelles, des SLA qui peuvent ouvrir droit à des crédits. Pour tirer pleinement parti de l’exemple de SLO VPC à 99,999 %, IBM indique qu’il faut au minimum trois serveurs, un dans chacune des trois zones d’une région multizone, et un répartiteur de charge. Le même guide résume la responsabilité partagée : IBM répond de la résilience et du rétablissement du cloud ; le client reste responsable de la résilience et du rétablissement de sa charge. (IBM Cloud)

La conséquence économique est nette. Il faut comparer le prix de la topologie qui rend l’engagement pertinent, et non le prix d’une unité de calcul isolée. Un SLA peut être généreux sur le papier tout en exigeant une architecture plus coûteuse ; il peut aussi être plus modeste mais appliqué à une configuration que le client déploierait de toute façon. Le bon objet de comparaison n’est donc pas le nombre de « neuf » seul, mais le couple architecture-recours.

Une réclamation est un processus, pas une conséquence automatique

Cloudflare exige que l’incident soit d’abord signalé au support dans les cinq jours ouvrés. La réclamation doit fournir des détails raisonnables, notamment la durée, des traceroutes, les URL touchées et les tentatives de résolution ; les éléments suffisants doivent parvenir avant la fin du mois de facturation suivant celui de l’incident. Le fournisseur précise aussi que la surveillance complète du contenu client incombe au client, qu’il examinera une mesure indépendante commercialement raisonnable et qu’il calculera le ratio affecté à partir des informations raisonnablement disponibles. (Cloudflare)

AWS impose une autre mécanique. La demande doit être reçue avant la fin du deuxième cycle de facturation suivant l’incident et comporter, selon le type de réclamation, la région ou la zone concernée, les identifiants de ressources, les horaires et les journaux corroborant l’indisponibilité. Une même instance ne peut donner lieu simultanément à une réclamation régionale et à une réclamation d’instance. (Amazon Web Services, Inc.)

Google exige une notification au support dans les 60 jours à compter du moment où le client devient éligible au crédit, ainsi que des journaux montrant les périodes d’arrêt et leurs dates et heures. Oracle demande, lui aussi dans une fenêtre de 60 jours à compter de l’incident, le service concerné, la région, les OCID pertinents, les tentatives de résolution et la documentation ou les journaux permettant d’étayer le manquement. (Google Cloud)

Ces obligations déplacent une partie du contrôle vers l’acheteur. Une organisation qui ne conserve pas les bons journaux, ne sait pas identifier précisément les ressources touchées ou ne déclenche pas une procédure de réclamation à temps détient un droit théorique qu’elle peut être incapable d’exercer. L’observabilité n’est donc pas seulement un outil SRE ; dans ce contexte, elle devient une infrastructure de preuve.

Le pourcentage de crédit peut masquer une assiette étroite

Les paliers spectaculaires de 100 % doivent être lus avec leur dénominateur économique. Chez AWS, les crédits régionaux ou d’instance sont de 10 %, 30 % ou 100 %, mais ils s’appliquent à la facture EC2 mensuelle pertinente pour la région affectée ou pour l’instance, à l’exclusion notamment des paiements initiaux ponctuels des Reserved Instances ; ils sont en principe appliqués à des paiements futurs. (Amazon Web Services, Inc.)

Google prévoit des paliers de 10 %, 25 % et 100 %. Le crédit est plafonné au montant dû pour les services couverts concernés dans les régions qui n’ont pas respecté l’objectif, et il est appliqué à l’usage futur. Une instance ne peut cumuler un crédit au titre d’une instance isolée et d’un déploiement multizone pour le même temps d’arrêt. (Google Cloud)

Oracle suit une logique encore plus explicitement rattachée à l’unité économique du service : le crédit ne porte que sur le service non conforme et est calculé comme un pourcentage des frais nets correspondant à la quantité pertinente effectivement utilisée pendant la période mesurée. Si plusieurs SLA couvrent le même événement pour un même service, le client reçoit généralement le crédit applicable le plus élevé plutôt qu’un empilement de crédits.

Le crédit ne peut dépasser les frais payés pour la quantité du service non conforme effectivement utilisée pendant la période mesurée, et le document en fait le recours exclusif ainsi que l’intégralité de la responsabilité d’Oracle pour l’engagement concerné. (甲骨文)

Cloudflare suit la même logique de bornage sous une forme différente : le crédit est le recours exclusif du SLA, il ne se calcule que sur les redevances mensuelles récurrentes du Service et le total des crédits accordés sur une période annuelle de facturation est plafonné à six mois de redevances mensuelles cumulées. (Cloudflare)

La règle de non-cumul est importante parce qu’une même panne peut apparaître simultanément dans plusieurs vues techniques. Sans elle, un incident pourrait ouvrir plusieurs voies de récupération sur la même ressource ou le même événement. Avec elle, le contrat choisit une voie de recours. Cela rend le coût maximal plus prévisible pour le fournisseur et rappelle à l’acheteur que le SLA n’est pas une police d’assurance couvrant chaque conséquence de la panne.

Ce que l’acheteur acquiert réellement

Le moyen le plus utile de lire un SLA est de séparer trois choses : l’étiquette nominale, la dépendance réellement couverte et le recours réellement acheté. L’étiquette est le pourcentage. La dépendance est l’objet mesuré — service, région, instance, visiteurs affectés, période d’arrêt. Le recours est la formule qui transforme un manquement validé en crédit sur une assiette déterminée.

Cette lecture change la diligence d’achat. Au lieu de demander seulement « quel est votre SLA ? », il faut reconstruire un incident plausible avec les paramètres du contrat : quelle topologie était en place, quelle ressource a échoué, quelle métrique compte, quelles minutes sont admissibles, quelle part des utilisateurs ou services est considérée affectée, quel montant de facture entre dans l’assiette, et quelles preuves restent disponibles dans le délai de réclamation. Le résultat est un montant de crédit possible, pas une mesure de dommage.

Le risque qui n’entre pas dans ce calcul doit être financé autrement. Une partie peut être réduite par l’architecture ; une partie transférée par l’assurance ou par des clauses commerciales négociées ; une partie absorbée dans le budget de continuité ; une partie encore traitée par des options de sortie. Cette séparation est plus austère qu’un tableau de « neuf », mais elle est plus fidèle à ce que les contrats décrivent.

L’écart peut être estimé avant l’incident. Il suffit de rapprocher, pour quelques scénarios sévères mais plausibles, le crédit maximal calculable de l’exposition opérationnelle que l’entreprise attribue à la charge. Ce n’est pas une prévision de sinistre ; c’est une cartographie de la part de risque qui reste hors du contrat.

Le point essentiel n’est donc pas que les SLA seraient faibles ou trompeurs. Ils font exactement ce que fait un bon instrument borné : ils définissent une frontière, une métrique, une procédure et un paiement maximal. Le problème apparaît lorsque l’acheteur traite cette frontière comme si elle coïncidait avec l’exposition de sa charge de travail entière. Entre les deux se trouvent l’architecture, la preuve et le risque résiduel.

Sources

Cloudflare — Enterprise Subscription Agreement / Enterprise SLA : https://www.cloudflare.com/__esa/

Cloudflare — Affected Customer Ratio : https://cf-assets.www.cloudflare.com/slt3lc6tev37/3JCTPcRmyFI8da4CGg6oh9/b51d2247a56b839661f2279a2eef59fc/affected_customer_ratio.png

Cloudflare — Service Credit Ratio : https://cf-assets.www.cloudflare.com/slt3lc6tev37/Eg51h7yYURjkFxzam0M0y/631a17a4a4db6cbce9de1c410a45c955/service_credit_ratio.png

AWS — Amazon Compute Service Level Agreement : https://aws.amazon.com/compute/sla/

Google Cloud — Compute Engine Service Level Agreement : https://cloud.google.com/compute/sla

Oracle — PaaS and IaaS Public Cloud Services Pillar Document : https://www.oracle.com/africa/contracts/docs/paas_iaas_pub_cld_srvs_pillar_4021422.pdf

IBM Cloud — Resiliency overview : https://cloud.ibm.com/docs/resiliency?topic=resiliency-resiliency-overview