Vérifier les disponibilités et délais de réaction dans les contrats d’hébergement

Ce qu’un SLA promet réellement dans les contrats d’hébergement

Un accord de niveau de service ne fait pas automatiquement partie intégrante du contrat. Timme Hosting précise dans son SLA que l’accord fait partie du contrat uniquement s’il a été expressément convenu lors de la commande ou de la passation de l’ordre. En l’absence de disposition contraire, c’est la version en vigueur au moment de la conclusion du contrat qui s’applique.

En cas de contradictions au sein du SLA, les dispositions les plus avantageuses pour le client prévalent selon la réglementation de Timme Hosting. Outre le SLA, seules les conditions générales de vente et les accords de service de Timme Hosting s’appliquent.

TechRadar décrit un SLA comme un contrat entre le client et le prestataire de services. Il définit le niveau de service attendu, les indicateurs de mesure et les sanctions en cas de non-respect. Les promesses typiques en matière d’hébergement incluent une disponibilité du réseau de 99,9 % par an, ainsi que des temps de réponse et de chargement spécifiques pour le site web.

La disponibilité et le temps de réaction sont des engagements distincts et mesurés séparément. Le cabinet d’avocats Herfurtner classe les SLA comme la partie des contrats IT, cloud et d’externalisation où la qualité de prestation peut être mesurée. Sont réglementés la disponibilité, les temps de réaction, les délais de rétablissement, les fenêtres de maintenance, les processus de support et les conséquences en cas de manquement. Selon le cabinet Herfurtner, les litiges naissent souvent non pas du contrat lui-même, mais de la question de savoir si un niveau de service a été respecté et quelles en sont les conséquences juridiques.

Avantages et risques des SLA dans les contrats d’hébergement

Étendue des services, base de mesure et lacunes définitionnelles

Le SLA de Timme Hosting divise les engagements en disponibilités des services serveur et disponibilités des services applicatifs. Vérifiez quel niveau est couvert : une panne des services serveur est différente d’une panne de l’application qui y tourne.

Le service y est défini comme la prestation technique convenue qui est fournie. En l’absence d’une telle définition, il reste flou de savoir si seule l’infrastructure, la base de données, l’envoi d’e-mails ou aussi l’application sont couvertes.

Chez Timme Hosting, la disponibilité planifiée correspond à un mois calendaire calculé de 30,5 jours, indépendamment du nombre réel de jours calendaires. Convertissez chaque pourcentage sur la période utilisée par le fournisseur lui-même.

Le temps d’indisponibilité y est déterminé par une formule : 100 × (disponibilité planifiée − pannes imprévues durant la disponibilité) ÷ disponibilité planifiée. Seules les pannes imprévues entrent dans ce calcul.

Selon akasolutions, un SLA devrait définir précisément quels services sont couverts – disponibilité du serveur, fenêtres de maintenance, sauvegardes de données et support. Chaque élément nécessite des métriques claires et mesurables, telles que les pourcentages de temps de fonctionnement (uptime), les temps de réaction du support ou la fréquence des sauvegardes.

Traduire les chiffres d’uptime en temps d’indisponibilité concret

Convertissez l’engagement en pourcentage en heures et minutes. Sur la base d’un mois de calcul de 30,5 jours, soit 732 heures : 99,9 % autorisent environ 44 minutes d’indisponibilité, 99,99 % environ 4,4 minutes.

Calculé sur une année de 8760 heures, le même chiffre permet davantage : 99,9 % correspondent à 8,76 heures, 99,99 % à environ 53 minutes. Il est décisif de savoir si le pourcentage se rapporte au mois ou à l’année.

TechRadar cite notamment une disponibilité du réseau de 99,9 % par an pour les packages d’hébergement web. mdoq donne un engagement de 99,9 % et exclut explicitement la maintenance planifiée.

Selon la définition de Timme Hosting, le temps d’indisponibilité ne comprend que les pannes imprévues survenant durant la disponibilité convenue. Que l’on considère comme temps d’arrêt (down time) uniquement l’inaccessibilité via HTTP ou aussi les réponses fortement retardées modifie considérablement la marge de manœuvre.

Le temps de réaction n’est pas le temps de rétablissement

Timme Hosting définit le temps de réaction comme la période entre la réception d’un signalement et la première réponse. Le délai jusqu’au rétablissement complet du service n’est donc pas garanti.

Les temps de réaction s’appliquent généralement uniquement pendant les heures ouvrables. Chez Timme Hosting, il s’agit du lundi au vendredi de 09h00 à 18h00, à l’exception des jours fériés légaux en Basse-Saxe.

La veille de Noël et le jour de l’an, les horaires sont de 09h00 à 13h00, si ces jours tombent du lundi au vendredi. L’heure usuelle en Allemagne s’applique : heure normale d’Europe centrale (HNEC) en hiver, heure d’été d’Europe centrale (HEEC) en été.

Une journée ouvrable de 09h00 à 18h00 y compte comme neuf heures ouvrables, un jour la veille de Noël ou le jour de l’an comme quatre. Un engagement de 24 heures peut ainsi signifier plusieurs jours calendaires.

De plus, les temps de revue des tickets chez Timme Hosting sont limités au lundi au vendredi de 09h00 à 17h00. Vérifiez par quels canaux un signalement doit impérativement parvenir pour que le délai commence à courir.

Différences entre temps de réaction et temps de rétablissement

Fenêtres de maintenance, exceptions et délimitations

Les travaux de maintenance figurent dans une section propre dans de nombreux SLA. Timme Hosting les sépare des engagements de disponibilité et ajoute une section concernant l’exclusion de responsabilité et les délimitations.

mdoq lie explicitement l’engagement de 99,9 % à l’exclusion des travaux de maintenance planifiés. Clarifiez si les fenêtres de maintenance doivent être annoncées et si elles sont comptabilisées ou non dans le temps d’indisponibilité.

Clarifiez également les délimitations : les perturbations dues aux systèmes du client, à des services tiers ou à des attaques peuvent être exclues de l’engagement. L’article sur Proton Mail de 2018 décrit la redondance et la protection DDoS comme un complément à l’engagement d’uptime ; l’article renvoie aux conditions d’utilisation pour les indications actuelles. De telles affirmations ne remplacent pas une garantie de disponibilité chiffrée.

Vérifier les crédits et les limites de responsabilité

Un article de Proton Mail de 2018 mentionne un remboursement partiel si le temps d’indisponibilité dépasse 0,05 % dans un mois calendaire ; pour les indications actuelles, l’article renvoie aux conditions d’utilisation. Converti, ce seuil correspond à une disponibilité de 99,95 % par mois.

TechRadar cite les indemnités ou sanctions comme élément typique d’un SLA. Timme Hosting présente les règles de compensation, les crédits en cas de violation de la disponibilité ainsi qu’une exclusion de responsabilité dans des sections distinctes.

Vérifiez comment le crédit est calculé – par exemple en proportion du tarif mensuel ou selon un barème –, jusqu’à quand il doit être réclamé et si un plafond de responsabilité s’applique. L’exclusion de responsabilité et les délimitations peuvent limiter le montant.

Engagements de sauvegarde et de restauration en complément

Les engagements de sauvegarde complètent l’engagement d’uptime, car ils déterminent la rapidité avec laquelle on peut retravailler après une perte de données. mdoq liste le monitoring des sauvegardes comme composante de son SLA d’hébergement web.

Selon akasolutions, les sauvegardes de données font partie des prestations qu’un SLA devrait décrire précisément, avec des métriques mesurables comme la fréquence des sauvegardes.

Clarifiez également qui déclenche une restauration, combien de temps elle peut durer et si des délais de rétablissement sont garantis pour celle-ci.

Monitoring, rapports et escalade

Timme Hosting surveille automatiquement tous les services serveur dans le cadre d’un monitoring continu. Demandez où ces valeurs de mesure sont consultables et si elles reflètent le même indicateur que celui garanti dans le SLA.

akasolutions recommande de stipuler dans le SLA que le fournisseur surveille régulièrement les prestations convenues et transmet des rapports à ce sujet au client. De même, une procédure d’escalade devrait définir la marche à suivre en cas de problèmes ou de violations.

Étant donné que la technologie et les exigences évoluent, le SLA devrait, selon la même source, contenir des mécanismes de révision et d’adaptation régulières. Fixez la périodicité de réception des rapports et identifiez qui les examine.

Pas à pas à travers le contrat

Lisez le SLA ligne par ligne et marquez chaque pourcentage, chaque délai et chaque définition. Traduisez les engagements d’uptime en minutes d’indisponibilité par période de calcul et les temps de réaction en jours calendaires, en tenant compte des heures ouvrables, du fuseau horaire et des jours fériés.

Signalez les contradictions et vérifiez quelle disposition vous est plus favorable.

Clarifiez les points ouverts avant la conclusion du contrat : base de mesure, services couverts, exceptions, seuils de crédit et délais. Déposez ensuite la version en vigueur au moment de la conclusion du contrat, car en l’absence d’accord contraire, elle fait foi.

Vérifiez enfin quels services ne sont pas du tout couverts – par exemple seulement les services serveur sans service applicatif, sans sauvegarde ou sans support. Les services non couverts échappent à tout engagement de disponibilité et de temps de réaction.