Un SLA affiché n'est pas une garantie
Un SLA est un texte contractuel, pas un argument commercial : il dit ce que l'hébergeur mesure, ce qu'il exclut, et ce qu'il verse lorsqu'il n'y parvient pas. Pour une agence, le point sensible est l'écart entre deux contrats. Vers le client, elle signe souvent une clause large : site disponible, incident traité vite, données restituables. Vers l'hébergeur, elle dépend de clauses plus étroites, parfois sans engagement de résultat. Si l'hébergeur plafonne sa compensation à un crédit de service alors que l'agence promet de réparer le préjudice du client, la différence reste à la charge de l'agence.
Cet article est une checklist de questions, pas un conseil juridique. La portée d'une clause dépend de son texte exact, du droit applicable et de votre situation : faites relire vos contrats par un juriste. Il traite le cas général de l'agence ; les obligations propres aux entités financières font l'objet de l'article sur DORA et les contrats TIC.
Disponibilité : ce qui est mesuré, par qui, sur quelle période
Commencez par la définition, car tout le reste en dépend. Que signifie « disponible » : le serveur répond à un test réseau, ou le site client s'affiche réellement ? Un hébergeur peut mesurer la disponibilité de sa plateforme sans jamais regarder votre application. Demandez ensuite qui mesure, avec quel outil, depuis quel point, et si les relevés sont accessibles à l'agence ou seulement sur demande.
La période de calcul compte autant que le taux. Un taux apprécié sur un mois ou sur une année ne se traduit pas par la même interruption tolérée, et une coupure répartie en micro-incidents peut ne jamais franchir le seuil. Vérifiez aussi si le SLA porte sur le service entier ou sur un composant : réseau, stockage, hyperviseur, panneau de contrôle. Enfin, repérez ce qui est exclu de la mesure, car c'est là que la promesse se réduit.
Les exclusions à chercher dans le texte
- Maintenance programmée — les fenêtres annoncées sont-elles décomptées ? Avec quel préavis, et avec quelle limite de durée ou de fréquence ?
- Force majeure — la liste est-elle fermée, ou assez large pour couvrir une panne de fournisseur du fournisseur ?
- Pannes d'un tiers — réseau amont, centre de données, DNS ou CDN : sont-ils exclus, alors que le client ne voit qu'un site hors ligne ?
- Cause côté client — une configuration, un plugin ou une charge anormale suffisent-ils à écarter le SLA, et qui en établit la preuve ?
- Attaques et abus — une attaque par déni de service est-elle exclue, et à partir de quel seuil de protection ?
- Suspension pour impayé ou abus — un compte suspendu sort-il du calcul sans condition ?
- Seuil de déclenchement — faut-il une interruption continue d'une durée minimale, ou les coupures cumulées comptent-elles ?
Compensation : plafond, crédit et procédure de réclamation
Un SLA se juge à ce qu'il coûte à l'hébergeur de le rater. Cherchez la forme de la compensation : crédit sur la facture suivante, remboursement, ou indemnisation. Un crédit de service ne répare pas la perte de chiffre d'affaires d'un client e-commerce, et il n'est souvent utilisable que chez l'hébergeur. Cherchez ensuite le plafond : pourcentage de la redevance, montant maximal, exclusion de certains préjudices.
La procédure compte autant que le montant. Le crédit est-il automatique ou conditionné à une réclamation écrite ? Dans quel délai faut-il la déposer, et par quel canal ? Beaucoup de crédits ne sont jamais perçus parce que la fenêtre de réclamation est passée. Relevez enfin si le SLA est la seule réparation possible ou si d'autres recours restent ouverts : c'est une question de rédaction que votre juriste doit trancher, pas vous.
Support : un délai de réponse n'est pas un délai de résolution
Lisez les engagements de support avec la même grille. Distinguez l'accusé de réception, la première réponse utile et la résolution : un hébergeur peut s'engager sur la première et rester muet sur la dernière. Vérifiez la définition de la gravité d'un incident, et qui la décide. Si c'est l'hébergeur seul, un site client en panne peut être classé en gravité basse.
Demandez les canaux disponibles (ticket, e-mail, téléphone), les horaires, les langues, et ce qui se passe hors heures ouvrées. Un week-end ou un jour férié sans astreinte suffit à rendre une promesse d'agence intenable. Demandez enfin comment l'agence escalade : existe-t-il un interlocuteur désigné pour les comptes revendeurs, et un canal distinct pour les incidents majeurs ? C'est cette chaîne que vous décrirez à votre client, autant la connaître avant.
Sauvegardes : incluses, conservées, restaurables ?
Le mot « sauvegarde » dans un contrat ne dit presque rien. Posez des questions précises. Est-elle incluse dans l'offre ou optionnelle ? Quelle est sa fréquence et sa durée de conservation ? Où est-elle stockée : sur la même machine ou ailleurs ? Une copie sur le serveur qu'elle protège tombe avec lui.
Le point que les agences découvrent trop tard est la restauration. Qui la déclenche, dans quel délai, à quel coût, et sur quel périmètre : site entier, base de données, un seul fichier ? Le contrat garantit-il la restaurabilité, ou seulement l'existence d'une copie ? Une sauvegarde jamais testée reste une hypothèse. Prévoyez donc un test de restauration régulier sur un site client, comme le décrit notre procédure dédiée, et conservez une copie indépendante de celle de l'hébergeur pour les sites qui comptent.
Back-to-back : ce que vous promettez contre ce que l'hébergeur garantit
Faites défiler le tableau
| Engagement vers le client | Ce que l'hébergeur doit garantir | Écart à combler |
|---|---|---|
| Site disponible selon un seuil | Un SLA mesuré sur le même périmètre, avec la même période | Définition différente : adapter la promesse ou le périmètre |
| Indemnisation d'une interruption | Une compensation au moins équivalente, sans plafond inférieur | Plafond plus bas : la différence reste à l'agence |
| Réponse rapide à un incident | Un délai de première réponse et une gravité définie | Délai de résolution non garanti : ne pas le promettre |
| Intervention hors heures ouvrées | Une astreinte ou un support étendu | Pas d'astreinte : prévoir la vôtre ou l'exclure |
| Sauvegarde et restauration | Fréquence, conservation, délai et coût de restauration | Restauration payante ou lente : prévoir une copie propre |
| Restitution des données en fin de contrat | Export dans un format exploitable, avec un délai | Pas de clause de sortie : négocier avant de signer |
| Information en cas d'incident | Un engagement de notification et de communication | Pas de notification : communiquer au client sans preuve |
Sortie et réversibilité : le jour où le client part
La clause de sortie est celle que l'on lit en dernier et dont on a besoin en premier le jour d'un conflit. Un client peut partir, l'agence peut changer d'hébergeur, l'hébergeur peut cesser son activité. Dans chaque cas, vous devez pouvoir récupérer le site, la base de données, les e-mails et les paramètres DNS dans un format exploitable.
Demandez donc : sous quel délai les données sont-elles restituées après résiliation ? Dans quel format ? À quel prix ? Combien de temps l'hébergeur les conserve-t-il avant suppression, et la suppression est-elle confirmée ? Vérifiez le préavis de résiliation, qui détermine si vous pouvez changer d'hébergeur sans interruption, et les frais éventuels. Enfin, regardez qui est propriétaire des noms de domaine et des certificats : un domaine enregistré au nom de l'hébergeur complique toute sortie.
Sous-traitance, localisation des données et maintenance
- Sous-traitance — l'hébergeur peut-il confier l'exploitation à un tiers, doit-il vous le dire, et reste-t-il responsable de ses sous-traitants ?
- Localisation des données — dans quels pays sont stockées les données et les sauvegardes, et un changement de localisation est-il notifié ?
- Préavis de maintenance — quel délai minimal, par quel canal, et que se passe-t-il pour une intervention urgente ?
- Sécurité — quelles mesures sont décrites, et l'hébergeur s'engage-t-il à vous prévenir en cas d'incident touchant vos données ?
- Évolution du contrat — l'hébergeur peut-il modifier les conditions unilatéralement, et avec quel préavis de votre côté ?
- Responsabilité — que dit le texte sur les dommages indirects, les pertes de données et la limite globale de responsabilité ?
- Droit applicable — quel droit et quelle juridiction régissent le contrat, et sont-ils compatibles avec ceux que vous signez avec le client ?
Aligner le contrat client sur celui de l'hébergeur
Rassembler les textes
Réunissez le contrat, le SLA, les conditions générales, la politique de sauvegarde et la politique de support de l'hébergeur. Les engagements se trouvent souvent dans plusieurs documents.
Remplir le tableau back-to-back
Pour chaque engagement que le client demande, notez la clause correspondante chez l'hébergeur. Une ligne sans clause est un écart, pas un détail.
Classer les écarts
Pour chacun, choisissez : combler (obtenir un engagement de l'hébergeur), réduire (promettre moins), ou assumer (le risque reste à l'agence, en connaissance de cause).
Reformuler la promesse au client
Écrivez des engagements de moyens et de procédure plutôt que de résultat chiffré, tant que l'hébergeur ne vous donne pas l'équivalent en amont.
Soumettre au juriste
Transmettez le tableau et les deux jeux de clauses. Un juriste valide l'ensemble ; cette checklist ne remplace pas cette étape.
Revoir à chaque renouvellement
Un hébergeur modifie ses conditions, l'agence change de périmètre. Replanifiez la relecture à chaque échéance, et à chaque changement d'hébergeur.
Une règle pour la rédaction client
Ne reprenez jamais dans votre contrat un chiffre du SLA de l'hébergeur sans avoir lu sa définition, ses exclusions et son plafond. Un taux recopié sans son contexte devient votre engagement, sans la protection qui l'entourait chez l'hébergeur.
Ce que cette checklist ne couvre pas
La checklist ne dit rien du droit applicable à votre situation, de la validité d'une clause de limitation, ni des obligations sectorielles de vos clients. Elle ne remplace ni un avis juridique ni la lecture intégrale des textes. Elle sert à arriver chez le juriste avec les bonnes questions, plutôt qu'avec un SLA dont personne n'a lu les exclusions.
Pour la plateforme ServOrbit, la disponibilité mentionnée sur le site est un objectif, pas un engagement contractuel : elle se lit avec cette même grille, à confronter aux conditions de service, et ne se reprend pas telle quelle dans vos contrats. Notre rôle est de tenir l'infrastructure ; le vôtre reste la relation avec le client, et la base contractuelle qui la porte.
