SLA, RTO, RPO : ces chiffres dans votre contrat qui transforment une obligation de moyens en garantie de résultat

La plupart des administrateurs de bases de données travaillent avec une intuition juridique rassurante : « j'exerce un métier d'expertise, je fais de mon mieux, donc on ne peut me reprocher que mes fautes ». Cette intuition correspond à un régime précis du droit français : l'obligation de moyens. Le prestataire s'engage à mettre en œuvre les diligences, le soin et les compétences qu'un professionnel raisonnable apporterait, sans promettre un résultat déterminé.

Dans ce régime, la charge de la preuve repose sur votre client. S'il vous reproche une indisponibilité ou une lenteur, c'est à lui de démontrer que vous avez commis une faute : une négligence, une erreur de configuration, un défaut de surveillance. Tant qu'il ne le prouve pas, vous n'êtes pas tenu.

L'obligation de résultat inverse complètement cette logique. Le prestataire ne promet plus un comportement diligent, mais un résultat précis. Si le résultat n'est pas atteint, le manquement est présumé : le client n'a rien à prouver d'autre que l'écart entre ce qui était promis et ce qui s'est produit. À vous, ensuite, de démontrer une cause étrangère (force majeure, faute du client) pour vous exonérer.

Pour un DBA, cette frontière n'est pas abstraite. Elle se matérialise dans une poignée de chiffres que vous signez parfois sans en mesurer la portée juridique.

Le Service Level Agreement (SLA) est le document, ou la clause, qui formalise les niveaux de service que vous vous engagez à tenir. Trois indicateurs y reviennent systématiquement, et chacun peut faire basculer votre régime de responsabilité.

• Le taux de disponibilité. Exprimé en pourcentage (99,9 %, 99,95 %, 99,99 %), il fixe la part du temps pendant laquelle la base doit être accessible. Derrière ces décimales se cachent des durées d'indisponibilité tolérée très différentes — et un engagement potentiellement chiffré.
• Le RTO (Recovery Time Objective). C'est le délai maximal pour remettre le service en route après un incident. « RTO de 4 heures » signifie que vous vous engagez à ce que, en cas de panne, la base soit de nouveau opérationnelle sous quatre heures.
• Le RPO (Recovery Point Objective). C'est la quantité maximale de données que le client accepte de perdre, exprimée en temps. « RPO de 15 minutes » signifie qu'après un incident, vous ne devez pas avoir perdu plus de quinze minutes de données — ce qui impose une fréquence de sauvegarde ou de réplication correspondante.

Ce que beaucoup de DBA ignorent, c'est que dès lors que ces valeurs sont chiffrées et contractualisées, le juge tend à y voir un engagement de résultat. Vous n'avez plus promis de « tout mettre en œuvre pour limiter les interruptions » : vous avez promis 99,9 %. Si vous tombez à 99,5 %, le manquement est constaté arithmétiquement.

Une formule de moyens dit « je m'efforcerai de maintenir le service disponible ». Une formule de résultat dit « le service sera disponible 99,9 % du temps ». Le passage de la première à la seconde tient parfois à une seule phrase glissée dans une annexe technique.

L'écart entre deux taux de disponibilité paraît dérisoire à l'œil nu. En durée réelle d'indisponibilité tolérée sur une année, il est considérable — et c'est cette durée qui fixe la difficulté de votre engagement.

Signer un SLA à 99,99 % revient à promettre que, sur une année entière, la base ne sera indisponible que 52 minutes au total — fenêtres de maintenance comprises si elles ne sont pas explicitement exclues. Un seul incident sérieux, une migration qui s'éternise, et le seuil est dépassé pour l'année.

Lorsque le seuil contractuel est franchi, deux mécanismes s'enclenchent souvent. D'abord, les pénalités contractuelles ou avoirs prévus au contrat, généralement adossés au montant de la prestation. Ensuite, et c'est le plus lourd, la réparation du préjudice subi par le client du fait de l'indisponibilité : chiffre d'affaires perdu, commandes non traitées, perte d'exploitation. Pour un client dont l'activité dépend entièrement de sa base de données, ce préjudice peut dépasser de très loin le montant de votre prestation.

Il existe une zone de bascule particulièrement traître pour le DBA : la maintenance planifiée. Vous avez besoin d'arrêter ou de dégrader le service pour appliquer un correctif, migrer un schéma, reconstruire un index volumineux ou changer une version de moteur. Ces opérations sont normales et nécessaires. Mais si votre SLA ne les exclut pas explicitement du calcul de disponibilité, chaque minute de maintenance vient grignoter votre budget d'indisponibilité.

Le scénario classique : un DBA freelance signe un engagement à 99,9 % sans clause de maintenance, planifie une migration de week-end qui dérape de quelques heures, et se retrouve mécaniquement sous le seuil annuel. Le client constate l'écart, active les pénalités et réclame le préjudice d'exploitation. Le DBA, lui, pensait simplement faire son travail.

Les protections contractuelles à verrouiller sont connues mais souvent oubliées :

1. Exclure les fenêtres de maintenance planifiée du calcul de disponibilité, avec un préavis défini (par exemple 48 h).
2. Distinguer les causes imputables au client ou à des tiers (hébergeur, fournisseur cloud, panne réseau) de celles qui vous incombent réellement.
3. Définir précisément le périmètre mesuré : disponibilité de l'instance, du service applicatif, ou de la donnée ? Ce n'est pas la même chose.
4. Plafonner les pénalités et exclure les dommages indirects, dans les limites permises par le droit, pour éviter que la perte d'exploitation du client ne devienne un gouffre sans fond.

La bonne nouvelle, c'est que le SLA n'est pas une fatalité imposée : c'est un objet de négociation. Trop de DBA acceptent des chiffres sortis d'un modèle de contrat client sans les confronter à la réalité technique de l'infrastructure dont ils ont la charge.

Avant de signer un taux de disponibilité, posez-vous une question simple : l'architecture me permet-elle réellement de le tenir ? Promettre 99,99 % sur une base mono-instance, sans réplication ni bascule automatique, c'est s'engager sur un résultat que l'infrastructure rend impossible. Si le client veut ce niveau, c'est l'occasion de proposer (et de facturer) la haute disponibilité qui le rend atteignable : réplication, cluster, mécanismes de failover.

Le bon réflexe consiste à aligner trois éléments : le niveau de service promis, l'architecture qui le permet, et la rémunération qui la finance. Un SLA à 99,99 % sur une infrastructure conçue pour 99,9 % est une promesse intenable doublée d'un risque juridique. Pour comprendre comment ce risque s'articule avec votre couverture, notre page assurance administrateur de bases de données détaille les garanties adaptées à ces engagements de service.

Même avec un SLA bien rédigé et une architecture cohérente, l'incident reste possible. Un bug du moteur, une corruption inattendue, une opération de maintenance qui dérape : le seuil est franchi, et le client réclame le préjudice lié à l'indisponibilité.

C'est là que la RC Professionnelle du DBA prend tout son sens. Elle couvre les préjudices financiers immatériels subis par votre client du fait d'une indisponibilité ou d'une défaillance de service imputable à votre prestation : perte d'exploitation, surcoûts, manque à gagner. C'est exactement le type de dommage que génère un dépassement de SLA, et c'est rarement bien couvert par un contrat d'assurance générique non pensé pour les métiers de l'IT.

Le volet défense et recours est tout aussi décisif. Un litige sur un SLA tourne souvent à la bataille d'experts : il faut reconstituer la durée exacte d'indisponibilité, déterminer ce qui relève de votre responsabilité, de l'hébergeur ou du client, et chiffrer le préjudice réel. Mener seul cette discussion face à un client et à son avocat vous expose à accepter une transaction défavorable. Adossé à un assureur, vous discutez l'imputabilité et le montant à armes égales — et vous restez concentré sur votre activité plutôt que sur la procédure.