Clause SLA et pénalités d'indisponibilité : avez-vous signé un contrat impossible à tenir ?
Trois neuf, quatre neuf, pénalités par minute d'indisponibilité : derrière le jargon des SLA se cachent des engagements qui peuvent vous exposer bien au-delà de votre rémunération. Décryptage clause par clause.
- Un SLA mal négocié transforme votre obligation de moyens en obligation de résultat, alourdissant considérablement votre responsabilité.
- Les pénalités forfaitaires d'indisponibilité peuvent dépasser le montant de votre mission et s'accumulent indépendamment du préjudice réel du client.
- Vous ne maîtrisez pas toute la chaîne : hébergeur, réseau, code applicatif tiers — pourtant le SLA vous tient souvent pour seul responsable.
- Une clause de répartition des responsabilités et une RC Pro adaptée sont vos deux leviers pour ne pas porter un risque que vous ne contrôlez pas.
Disponibilité à 99,99 % : ce que ce chiffre signifie vraiment
Un client vous demande de garantir une disponibilité de « quatre neuf », soit 99,99 %. Le chiffre paraît anodin. Traduit en temps d'interruption autorisé, il devient brutal :
| Niveau de SLA | Indisponibilité tolérée / an | Indisponibilité / mois |
|---|---|---|
| 99,9 % (trois neuf) | 8 h 46 min | 43 min |
| 99,95 % | 4 h 23 min | 21 min |
| 99,99 % (quatre neuf) | 52 min | 4 min 19 s |
| 99,999 % (cinq neuf) | 5 min | 26 s |
À 99,99 %, vous vous engagez à ce que la plateforme ne soit pas indisponible plus de 52 minutes sur une année entière. Une seule fenêtre de maintenance mal maîtrisée, un incident hébergeur, une mise à jour de sécurité urgente, et le quota est consommé. Avant de signer, demandez-vous : ai-je la maîtrise opérationnelle pour tenir ce chiffre ? Le plus souvent, la réponse honnête est « pas seul ».
Obligation de moyens ou de résultat : la bascule silencieuse
Le droit distingue deux régimes de responsabilité. L'obligation de moyens vous engage à mettre en œuvre votre compétence et votre diligence : si un dommage survient malgré tout, le client doit prouver votre faute. L'obligation de résultat vous engage à atteindre un objectif précis : si le résultat n'est pas là, votre responsabilité est présumée, sans que le client ait à démontrer quoi que ce soit.
Un engagement chiffré de disponibilité (« la plateforme sera disponible à 99,99 % ») est, par nature, une obligation de résultat. Vous ne promettez plus de faire de votre mieux : vous promettez un chiffre.
Cette bascule change tout. En obligation de résultat, vous êtes responsable même si vous avez parfaitement travaillé, dès que le seuil n'est pas atteint. C'est juridiquement beaucoup plus lourd qu'une prestation d'ingénierie classique, qui relève normalement de l'obligation de moyens. Le simple choix des mots dans le contrat peut donc multiplier votre exposition.
Pénalités forfaitaires : le découplage avec le préjudice réel
Les SLA prévoient souvent des pénalités : tant d'euros par tranche d'indisponibilité, ou un pourcentage de la facture par point de disponibilité manquant. Le piège est double.
D'abord, ces pénalités sont forfaitaires : elles s'appliquent que le client ait subi un préjudice ou non. Une indisponibilité nocturne sans aucun utilisateur connecté déclenche quand même la pénalité.
Ensuite, elles peuvent dépasser votre rémunération. Imaginez une pénalité de 500 € par heure d'indisponibilité au-delà du seuil, sur une mission facturée 4 000 €. Une panne d'un week-end (48 h, dont 40 h hors seuil) génère 20 000 € de pénalités — cinq fois le montant de votre contrat.
Quelques réflexes de négociation :
- Plafonner les pénalités à un pourcentage du montant de la mission (ex. 15 %) ;
- Exclure les fenêtres de maintenance planifiées du calcul de disponibilité ;
- Définir précisément le « début » d'une indisponibilité (à partir du ticket ? de la détection ? du dépassement d'un seuil de dégradation ?) ;
- Distinguer les causes externes (panne hébergeur, attaque DDoS) qui ne devraient pas vous être imputées.
Le maillon que vous ne contrôlez pas : la chaîne de responsabilité
La disponibilité d'une plateforme dépend d'une chaîne : datacenter, fournisseur cloud, réseau, orchestrateur, code applicatif, dépendances tierces. Vous n'opérez généralement que sur une partie de cette chaîne. Pourtant, un SLA mal rédigé vous désigne comme garant de l'ensemble.
Exemple typique : une panne régionale de votre fournisseur cloud rend le service indisponible six heures. Vous n'y êtes pour rien, mais le SLA signé avec votre client ne distingue pas les causes. Le client vous applique les pénalités, à charge pour vous de vous retourner contre l'hébergeur — dont les propres conditions limitent drastiquement sa responsabilité.
Pour éviter de porter seul un risque collectif :
- Insérez une clause de répartition des responsabilités excluant les défaillances des fournisseurs tiers ;
- Documentez l'architecture de résilience que vous recommandez, et faites acter par écrit les choix du client (s'il refuse une redondance multi-région pour des raisons de coût, ce refus doit être tracé) ;
- Conservez les preuves d'incidents externes (status pages, post-mortems fournisseurs) pour étayer vos recours.
Là encore, ces protections contractuelles se complètent d'une couverture financière. La RC Professionnelle intervient lorsque, malgré une rédaction soignée, votre responsabilité est retenue.
Comment l'assurance s'articule avec votre SLA
Une question revient souvent : « si je suis condamné à payer des pénalités contractuelles, mon assurance les prend-elle en charge ? » La réponse mérite des nuances.
Les RC Pro couvrent en principe la responsabilité civile pour les dommages causés à des tiers du fait de votre faute. Les pénalités purement contractuelles, déconnectées d'un dommage réel, ne sont pas toujours assimilées à un dommage indemnisable : certaines polices les excluent expressément.
En revanche, lorsque l'indisponibilité a causé un préjudice effectif au client (perte d'exploitation, perte de chiffre d'affaires) et que votre faute est établie, la garantie « préjudices immatériels » de la RC Pro a vocation à intervenir. D'où l'importance, pour un ingénieur DevOps, de :
- Préférer dans vos contrats l'indemnisation du préjudice réel plutôt que des pénalités forfaitaires « sèches » ;
- Vérifier que votre RC Pro inclut bien les préjudices financiers immatériels non consécutifs ;
- Compléter par une garantie cyber quand l'indisponibilité a une origine de sécurité.
Bien lue, votre police devient le pendant financier de vos clauses contractuelles : l'une encadre le risque, l'autre le finance.
Questions fréquentes
Vous pouvez proposer un niveau réaliste au regard de l'architecture financée par le client. Un SLA n'est pas un dogme : c'est une négociation. Mieux vaut un engagement tenable à 99,9 % qu'une promesse à 99,99 % que vous ne maîtrisez pas, qui vous exposera à des pénalités systématiques.
Pas automatiquement. Les pénalités purement contractuelles peuvent être exclues. En revanche, le préjudice réel subi par le client à la suite d'une faute de votre part relève de la garantie préjudices immatériels. Privilégiez donc les clauses d'indemnisation du dommage réel plutôt que les forfaits.
Oui si votre SLA ne distingue pas les causes d'indisponibilité. C'est pourquoi il faut une clause excluant les défaillances des fournisseurs tiers et tracer par écrit les choix d'architecture du client (notamment ses arbitrages de coût sur la redondance).
Un chiffre de disponibilité garanti est généralement interprété comme une obligation de résultat : votre responsabilité est présumée dès que le seuil n'est pas atteint, sans que le client ait à prouver votre faute. C'est un régime nettement plus sévère qu'une obligation de moyens.
Vivement recommandé. Sans plafond, des pénalités forfaitaires peuvent dépasser largement le montant de votre mission. Un plafonnement à un pourcentage de la rémunération aligne votre exposition sur votre gain et reste un argument de négociation acceptable pour la plupart des clients.
Souscrivez votre assurance pro en 2 minutes
Toutes nos protections pour votre activité de Ingénieur DevOps — attestation immédiate, sans engagement.
* Tarifs indicatifs « à partir de », selon votre profil, votre activité et les garanties choisies. · Voir la fiche Ingénieur DevOps →
Article rédigé et vérifié par l'équipe Insurio — Tutassûr, courtier en assurance immatriculé à l'ORIAS sous le n° 22001730. Information à caractère général ne se substituant pas aux conditions de votre contrat.