# SLA d’hébergement WordPress : les clauses à négocier avec votre prestataire

> Une agence a longtemps signé ses contrats d'hébergement sans jamais lire les clauses de disponibilité. Voici les clauses concrètes à exiger, temps de rétablissement et pénalités compris.

- Auteur : Clément Hadrot
- Publié le : 2023-06-19
- Mis à jour le : 2023-06-19
- Catégorie : Hébergement & serveurs
- URL : https://wpmoderne.dev.wordpress-developpement.fr/hebergement/sla-hebergement-wordpress-clauses-negocier/

## L’essentiel

- Un taux de disponibilité affiché ne veut rien dire sans la fenêtre de mesure
- Le temps de rétablissement garanti compte plus que le taux d'uptime seul
- Les pénalités doivent être automatiques, jamais soumises à réclamation

Une agence a fait le point, un jour, sur l'ensemble des contrats d'hébergement signés pour ses clients au fil des années : aucun n'avait jamais lu en détail la clause de disponibilité au-delà du chiffre marketing en gras sur la page tarifaire, « 99,9 % de disponibilité garantie ». Ce chiffre, sorti de son contexte contractuel, ne protège en réalité de rien : c'est l'ensemble de la clause qui détermine si un client obtient une vraie compensation en cas d'incident, ou un geste commercial arbitraire.

Voici, dans l'ordre où nous les vérifions désormais avant toute signature, les clauses qui déterminent la valeur réelle d'un SLA (Service Level Agreement) d'hébergement WordPress.

## 1. La fenêtre de mesure de la disponibilité

Un taux de 99,9 % mesuré sur un mois ou sur une année ne représente pas la même tolérance réelle : 99,9 % sur un mois autorise environ 43 minutes d'indisponibilité, contre un cumul similaire réparti sur douze mois si la fenêtre est annuelle, ce qui laisse davantage de marge à l'hébergeur avant que la moindre pénalité ne se déclenche. Une clause qui ne précise pas explicitement la fenêtre de mesure doit systématiquement être clarifiée avant signature.

## 2. La définition exacte de « l'indisponibilité »

Certains contrats ne comptabilisent que l'indisponibilité totale du réseau de l'hébergeur, excluant explicitement les pannes applicatives (MySQL down alors que le serveur répond) ou les fenêtres de maintenance planifiées, parfois annoncées avec un préavis symbolique de quelques heures. Une clause solide définit précisément ce qui compte comme indisponibilité mesurée, avec une méthode de mesure indépendante (sonde tierce) plutôt qu'auto-déclarée par l'hébergeur lui-même.

## 3. Le RTO : temps de rétablissement garanti

Le taux de disponibilité seul ne dit rien du temps que prendra un rétablissement en cas d'incident grave. Un hébergeur peut afficher 99,99 % sur l'année tout en mettant six heures à résoudre un incident ponctuel, ce qui reste statistiquement compatible avec ce taux mais catastrophique pour un client en pleine activité commerciale ce jour-là. Le RTO (Recovery Time Objective) garanti par écrit — par exemple deux heures maximum pour un incident critique — mérite autant d'attention que le taux global.

> L'essentiel à retenir : Un taux de disponibilité affiché ne veut rien dire sans la fenêtre de mesure ; Le temps de rétablissement garanti compte plus que le taux d'uptime seul ; Les pénalités doivent être automatiques, jamais soumises à réclamation

## 4. Les pénalités : automatiques ou sur réclamation

La clause la plus souvent négligée concerne le déclenchement des pénalités en cas de dépassement du SLA : certains contrats prévoient un crédit automatique dès le franchissement du seuil, d'autres exigent une réclamation écrite du client dans un délai précis (parfois cinq jours ouvrés seulement), faute de quoi le droit à compensation s'éteint silencieusement. Une clause de pénalité automatique protège bien mieux un client qui, en pleine crise, n'a de toute façon pas le réflexe de lire les petites lignes de son contrat d'hébergement.

| Type de clause | Version faible | Version à exiger |
| --- | --- | --- |
| Fenêtre de mesure | Non précisée | Explicitement mensuelle |
| Définition de la panne | Réseau uniquement | Applicative incluse |
| Déclenchement pénalité | Sur réclamation, délai court | Automatique, sans démarche |
| Sauvegardes | Non garanties contractuellement | RPO chiffré et garanti |

## 5. La responsabilité sur les sauvegardes

Nombre de contrats mentionnent des sauvegardes « incluses » sans jamais préciser leur fréquence, leur rétention, ni surtout la responsabilité en cas d'échec silencieux de cette sauvegarde. Une clause solide chiffre un RPO (Recovery Point Objective) garanti — la perte de données maximale tolérée en cas d'incident — plutôt qu'une simple mention vague de « sauvegardes régulières ».

## 6. La portabilité en cas de résiliation

Une dernière clause, rarement lue avant signature et pourtant décisive en cas de désaccord ultérieur : les modalités d'export complet des données en cas de résiliation, avec un délai maximal de mise à disposition. Un hébergeur qui retient les données plusieurs semaines après une résiliation transforme un simple changement de prestataire en négociation de force.

1. Demander la fenêtre de mesure exacte du taux de disponibilité annoncé
2. Exiger une définition écrite de ce qui compte comme incident
3. Vérifier le RTO garanti pour un incident critique, pas seulement le taux annuel
4. Confirmer que les pénalités se déclenchent automatiquement
5. Faire préciser le RPO garanti sur les sauvegardes incluses
6. Vérifier les délais d'export des données en cas de résiliation

> Un SLA qui tient sur une phrase marketing n'engage à rien ; un SLA qui tient sur six clauses précises engage réellement l'hébergeur, et se négocie avant signature, jamais après un incident.

## En résumé

Le chiffre affiché en gras sur une page tarifaire ne constitue qu'une promesse commerciale tant qu'il n'est pas adossé à des clauses précises sur la mesure, le rétablissement et les pénalités. Une agence qui relit ces six points avant chaque signature protège autant ses clients que sa propre crédibilité en cas d'incident.