{"id":23092,"date":"2026-06-24T10:00:00","date_gmt":"2026-06-24T10:00:00","guid":{"rendered":"https:\/\/atiasavocats.com\/?p=23092"},"modified":"2026-06-16T09:19:11","modified_gmt":"2026-06-16T09:19:11","slug":"sla-saas-7-indicateurs-a-exiger-2026","status":"publish","type":"post","link":"https:\/\/atiasavocats.com\/en\/sla-saas-7-indicateurs-a-exiger-2026\/","title":{"rendered":"SLA SaaS : les 7 indicateurs \u00e0 exiger en 2026"},"content":{"rendered":"


Par\u00a0<\/em>David Joseph Atias<\/em><\/a>, avocat au Barreau de Paris \u00b7\u00a0<\/em>LinkedIn<\/em><\/a>\u00a0\u00b7 Juin 2026<\/em><\/em><\/p>\n\n\n\n

\n

Le SLA SaaS est probablement la clause la plus mal n\u00e9goci\u00e9e des contrats SaaS. Annexe souvent dense de chiffres et d’acronymes (uptime, MTTR, RTO, RPO), elle d\u00e9courage les directions juridiques et passe trop souvent en l’\u00e9tat. Pourtant, c’est pr\u00e9cis\u00e9ment le SLA qui transforme une promesse commerciale en obligation de r\u00e9sultat opposable. Une plateforme \u00e0 99,9 % de disponibilit\u00e9 signifie tout de m\u00eame 8 heures 46 minutes d’indisponibilit\u00e9 par an. En 2026, l’articulation avec la directive NIS2 et l’AI Act renforce encore l’enjeu. Cet article expose les 7 indicateurs cl\u00e9s \u00e0 n\u00e9gocier et leur cadre juridique.<\/p>\n<\/blockquote>\n\n\n\n

SOMMAIRE<\/p>\n\n\n\n

    \n
  1. Pourquoi le SLA SaaS est devenu strat\u00e9gique en 2026<\/a><\/li>\n\n\n\n
  2. Le cadre juridique applicable<\/a><\/li>\n\n\n\n
  3. Les 7 indicateurs \u00e0 exiger<\/a><\/li>\n\n\n\n
  4. Tableau de synth\u00e8se des seuils du march\u00e9<\/a><\/li>\n\n\n\n
  5. Les 5 pi\u00e8ges \u00e0 \u00e9viter<\/a><\/li>\n\n\n\n
  6. Pourquoi faire appel \u00e0 Atias Avocats<\/a><\/li>\n\n\n\n
  7. FAQ \u2014 Questions fr\u00e9quentes<\/a><\/li>\n<\/ol>\n\n\n\n

    1. Pourquoi le SLA SaaS est devenu strat\u00e9gique en 2026<\/h2>\n\n\n\n

    Le SLA SaaS n’est plus une annexe technique p\u00e9riph\u00e9rique. Il est devenu le c\u0153ur op\u00e9rationnel du contrat, sur lequel se joue la qualit\u00e9 de service et la s\u00e9curit\u00e9 juridique du client. Trois dynamiques expliquent cette mont\u00e9e en puissance en 2026.<\/p>\n\n\n\n

    1.1 La d\u00e9pendance critique aux SaaS<\/h3>\n\n\n\n

    Selon plusieurs \u00e9tudes sectorielles, une entreprise moyenne utilise d\u00e9sormais entre 80 et 130 applications SaaS distinctes. Certaines, comme la messagerie, le CRM, l’ERP ou les outils RH, sont devenues vitales pour l’exploitation quotidienne. Une indisponibilit\u00e9 de quelques heures peut co\u00fbter des centaines de milliers d’euros \u00e0 un acteur du e-commerce, des services financiers ou de la logistique. Sans engagement chiffr\u00e9 et opposable, le client subit ces pertes sans recours.<\/p>\n\n\n\n

    1.2 L’entr\u00e9e en application de NIS2<\/h3>\n\n\n\n

    La directive UE 2022\/2555 (NIS2) impose d\u00e9sormais aux entit\u00e9s essentielles et importantes une obligation de cybers\u00e9curit\u00e9 \u00e9tendue \u00e0 leurs fournisseurs critiques. Cela inclut les fournisseurs SaaS. La transposition fran\u00e7aise, effective en 2026, exige un encadrement contractuel pr\u00e9cis de la s\u00e9curit\u00e9, des incidents et de la continuit\u00e9 \u2014 exactement les sujets couverts par le SLA. Les contr\u00f4les de l’ANSSI ciblent prioritairement ces aspects.<\/p>\n\n\n\n

    1.3 L’articulation impos\u00e9e avec l’AI Act<\/h3>\n\n\n\n

    Le R\u00e8glement UE 2024\/1689 (AI Act), pleinement applicable au 2 ao\u00fbt 2026, impose aux d\u00e9ployeurs de syst\u00e8mes d’IA \u00e0 haut risque (article 26) une surveillance op\u00e9rationnelle continue et une supervision humaine effective (article 14). Quand un SaaS int\u00e8gre une IA \u00e0 haut risque, le SLA doit garantir la disponibilit\u00e9 de ces capacit\u00e9s, la fourniture des journaux et la notification rapide des incidents. Le SLA devient un outil de conformit\u00e9 AI Act. Pour aller plus loin, consultez nos services en mati\u00e8re de contrats commerciaux et IT<\/strong><\/a>.<\/p>\n\n\n\n

    2. Le cadre juridique applicable<\/h2>\n\n\n\n

    Le SLA SaaS s’inscrit dans un cadre juridique pluriel. Cinq corpus principaux se superposent et structurent la r\u00e9daction et l’opposabilit\u00e9 des engagements.<\/p>\n\n\n\n

    2.1 Le droit commun des contrats et l’obligation de r\u00e9sultat<\/h3>\n\n\n\n

    Les articles 1217 et 1231-1 du Code civil organisent le r\u00e9gime de la responsabilit\u00e9 contractuelle. Une obligation de r\u00e9sultat, par opposition \u00e0 une obligation de moyens, exige du d\u00e9biteur d’atteindre un r\u00e9sultat pr\u00e9cis. Le manquement engage automatiquement sa responsabilit\u00e9, sauf force majeure (article 1218). Un SLA chiffr\u00e9 transforme l’obligation de moyens classique de l’\u00e9diteur en obligation de r\u00e9sultat opposable, sanctionn\u00e9e par les p\u00e9nalit\u00e9s contractuelles.<\/p>\n\n\n\n

    2.2 L’article 1170 et les clauses qui privent de substance<\/h3>\n\n\n\n

    L’article 1170 du Code civil r\u00e9pute non \u00e9crite toute clause qui prive de sa substance l’obligation essentielle du d\u00e9biteur. Jurisprudence Chronopost et plusieurs arr\u00eats r\u00e9cents le confirment. Un SLA pr\u00e9voyant une disponibilit\u00e9 de 99,9 % mais plafonnant l’indemnit\u00e9 \u00e0 5 % de la redevance mensuelle fragilise ce principe. Cette articulation entre engagement et p\u00e9nalit\u00e9 doit donc \u00eatre \u00e9quilibr\u00e9e pour \u00e9viter la requalification ou la nullit\u00e9 partielle.<\/p>\n\n\n\n

    2.3 La directive NIS2 et l’arr\u00eat\u00e9 de transposition 2026<\/h3>\n\n\n\n

    La directive UE 2022\/2555 (NIS2) impose une vigilance contractuelle accrue sur la cybers\u00e9curit\u00e9 des fournisseurs. L’article 21 paragraphe 2 d) impose la s\u00e9curit\u00e9 de la cha\u00eene d’approvisionnement, ce qui inclut explicitement les \u00e9diteurs SaaS. Les entit\u00e9s essentielles (sant\u00e9, \u00e9nergie, transport, finance, infrastructures num\u00e9riques) doivent int\u00e9grer dans leurs SLA des engagements de cybers\u00e9curit\u00e9 opposables : chiffrement, gestion des vuln\u00e9rabilit\u00e9s, notification 24-72h des incidents, plan de continuit\u00e9.<\/p>\n\n\n\n

    2.4 Le RGPD et l’AI Act en filigrane<\/h3>\n\n\n\n

    L’article 32 du R\u00e8glement UE 2016\/679 (RGPD) impose des mesures techniques et organisationnelles de s\u00e9curit\u00e9 que le SLA doit refl\u00e9ter. Les articles 33 et 34 imposent la notification des violations dans des d\u00e9lais courts. Le R\u00e8glement UE 2024\/1689 (AI Act) ajoute, depuis le 2 ao\u00fbt 2026, des exigences sp\u00e9cifiques pour les SaaS int\u00e9grant des syst\u00e8mes \u00e0 haut risque : journalisation, supervision, disponibilit\u00e9 des fonctions de contr\u00f4le. Pour aller plus loin, consultez nos services en mati\u00e8re de protection des donn\u00e9es personnelles<\/strong><\/a>.<\/p>\n\n\n\n

    3. Les 7 indicateurs \u00e0 exiger<\/h2>\n\n\n\n

    Un SLA SaaS solide s’articule autour de sept indicateurs mesurables. Chacun mesure un aspect sp\u00e9cifique de la qualit\u00e9 de service et doit \u00eatre assorti d’un mode de mesure et d’une p\u00e9nalit\u00e9 claire.<\/p>\n\n\n\n

    3.1 La disponibilit\u00e9 (uptime)<\/h3>\n\n\n\n

    Le premier indicateur mesure le pourcentage de temps pendant lequel la plateforme est accessible. Le standard du march\u00e9 varie selon la criticit\u00e9 : 99,5 % pour un service non critique (21 heures d’indisponibilit\u00e9 par an), 99,9 % pour un service important (8h46 par an), 99,95 % ou 99,99 % pour un service vital. La n\u00e9gociation porte aussi sur la d\u00e9finition de l’indisponibilit\u00e9, la m\u00e9thode de mesure (continue, par fonctionnalit\u00e9, par fen\u00eatre de r\u00e9f\u00e9rence) et les exclusions (maintenance planifi\u00e9e, force majeure). Une d\u00e9finition floue rend l’indicateur inopposable.<\/p>\n\n\n\n

    3.2 Le MTTR (temps de r\u00e9solution des incidents)<\/h3>\n\n\n\n

    Le deuxi\u00e8me indicateur mesure le temps moyen de r\u00e9solution. Le MTTR (Mean Time To Repair) doit \u00eatre segment\u00e9 par niveau de gravit\u00e9 : critique (1 \u00e0 4 heures), majeur (8 heures), mineur (24 \u00e0 48 heures). Chaque niveau doit avoir sa propre matrice de qualification. Une d\u00e9finition op\u00e9rationnelle des niveaux est indispensable : la \u00ab criticit\u00e9 \u00bb ne se mesure pas \u00e0 la sensation du sous-traitant mais \u00e0 l’impact business du client. Le SLA doit pr\u00e9voir une proc\u00e9dure d’escalade chronom\u00e9tr\u00e9e si le MTTR n’est pas tenu.<\/p>\n\n\n\n

    3.3 Le RTO (objectif de temps de reprise)<\/h3>\n\n\n\n

    Le troisi\u00e8me indicateur, le RTO (Recovery Time Objective), mesure le temps maximal acceptable pour r\u00e9tablir le service apr\u00e8s un sinistre majeur (panne datacenter, attaque, sinistre). Pour un service standard, le RTO oscille entre 4 et 24 heures. Pour un service critique, il descend \u00e0 1 \u00e0 4 heures. Le SLA doit d\u00e9crire les m\u00e9canismes garantissant ce RTO : sites secondaires, redondance, basculement automatique, exercices de continuit\u00e9. Sans ces preuves op\u00e9rationnelles, l’engagement RTO reste th\u00e9orique.<\/p>\n\n\n\n

    3.4 Le RPO (objectif de point de reprise des donn\u00e9es)<\/h3>\n\n\n\n

    Le quatri\u00e8me indicateur, le RPO (Recovery Point Objective), mesure la perte maximale acceptable de donn\u00e9es en cas de sinistre. Un RPO de 4 heures signifie que le client peut perdre jusqu’\u00e0 4 heures de donn\u00e9es entre la derni\u00e8re sauvegarde et l’incident. Pour des donn\u00e9es critiques, viser 5 \u00e0 15 minutes (sauvegardes en continu) est n\u00e9cessaire. Pour des donn\u00e9es moins sensibles, 4 \u00e0 24 heures peuvent suffire. Le SLA doit articuler RPO, fr\u00e9quence des sauvegardes, lieu de stockage et dur\u00e9e de conservation.<\/p>\n\n\n\n

    3.5 La qualit\u00e9 du support client<\/h3>\n\n\n\n

    Le cinqui\u00e8me indicateur mesure la disponibilit\u00e9 et la r\u00e9activit\u00e9 du support. Plusieurs param\u00e8tres doivent \u00eatre chiffr\u00e9s : plage horaire (heures ouvr\u00e9es, 24\/7), canaux (ticket, t\u00e9l\u00e9phone, chat), d\u00e9lai de premi\u00e8re r\u00e9ponse par niveau de gravit\u00e9 (15 minutes \u00e0 4 heures), langue du support (fran\u00e7ais, anglais), \u00e9quipes (niveau 1, 2, 3 \/ experts). Un SLA s\u00e9rieux pr\u00e9voit aussi un point de contact d\u00e9di\u00e9 pour les grands comptes (Customer Success Manager) et un m\u00e9canisme d’escalade clair.<\/p>\n\n\n\n

    3.6 Le niveau de s\u00e9curit\u00e9 (TOMS)<\/h3>\n\n\n\n

    Le sixi\u00e8me indicateur engage l’\u00e9diteur sur des mesures techniques et organisationnelles de s\u00e9curit\u00e9, d\u00e9sign\u00e9es sous le terme TOMS (Technical and Organisational Measures). Le SLA doit faire r\u00e9f\u00e9rence \u00e0 des standards reconnus : ISO 27001 (s\u00e9curit\u00e9 de l’information), ISO 27017 et 27018 (s\u00e9curit\u00e9 cloud et donn\u00e9es personnelles), SOC 2 type II (contr\u00f4les audit\u00e9s), HDS pour les donn\u00e9es de sant\u00e9, PCI DSS pour les paiements. La fr\u00e9quence des tests d’intrusion, la gestion des vuln\u00e9rabilit\u00e9s et la notification des incidents s\u00e9curit\u00e9 doivent \u00eatre quantifi\u00e9es.<\/p>\n\n\n\n

    3.7 Les p\u00e9nalit\u00e9s et le droit de r\u00e9siliation<\/h3>\n\n\n\n

    Le septi\u00e8me indicateur, parfois le plus n\u00e9glig\u00e9, est le r\u00e9gime des p\u00e9nalit\u00e9s. Sans sanction quantifi\u00e9e, un SLA SaaS reste de la litt\u00e9rature commerciale. Les p\u00e9nalit\u00e9s prennent typiquement la forme d’avoirs (service credits) en pourcentage de la redevance mensuelle, calcul\u00e9s selon une grille progressive. Au-del\u00e0 d’un seuil de gravit\u00e9, le client doit pouvoir r\u00e9silier le contrat sans p\u00e9nalit\u00e9 ni pr\u00e9avis. Cette clause de sortie est l’arme ultime du client face \u00e0 un \u00e9diteur d\u00e9faillant et doit \u00eatre n\u00e9goci\u00e9e d\u00e8s la signature.<\/p>\n\n\n\n

    4. Tableau de synth\u00e8se des seuils du march\u00e9<\/h2>\n\n\n\n

    Le tableau ci-dessous synth\u00e9tise les seuils typiques du march\u00e9 en 2026 pour les 7 indicateurs, par niveau de service. C’est la grille de r\u00e9f\u00e9rence pour la n\u00e9gociation.<\/p>\n\n\n\n

    Indicateur<\/th>Seuil standard<\/th>Seuil critique<\/th>Criticit\u00e9<\/th><\/tr><\/thead>
    1. Uptime<\/td>99,5 %<\/td>99,95 % \u00e0 99,99 %<\/td>\ud83d\udd34 Critique<\/td><\/tr>
    2. MTTR critique<\/td>8 heures<\/td>1 \u00e0 4 heures<\/td>\ud83d\udd34 Critique<\/td><\/tr>
    3. RTO<\/td>24 heures<\/td>1 \u00e0 4 heures<\/td>\ud83d\udd34 Critique<\/td><\/tr>
    4. RPO<\/td>4 \u00e0 24 heures<\/td>5 \u00e0 15 minutes<\/td>\ud83d\udfe0 \u00c9lev\u00e9e<\/td><\/tr>
    5. Support<\/td>Heures ouvr\u00e9es<\/td>24\/7 multilingue<\/td>\ud83d\udfe0 \u00c9lev\u00e9e<\/td><\/tr>
    6. S\u00e9curit\u00e9 (TOMS)<\/td>ISO 27001<\/td>ISO 27001 + 27017\/27018 + SOC 2<\/td>\ud83d\udd34 Critique<\/td><\/tr>
    7. P\u00e9nalit\u00e9s<\/td>Avoirs 10-25 %<\/td>Avoirs progressifs + sortie sans pr\u00e9avis<\/td>\ud83d\udd34 Critique<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    5. Les 5 pi\u00e8ges \u00e0 \u00e9viter<\/h2>\n\n\n\n

    Au-del\u00e0 des chiffres, plusieurs pi\u00e8ges r\u00e9currents fragilisent les SLA SaaS en pratique. Les identifier permet d’\u00e9viter les contestations classiques quand un incident grave se produit.<\/p>\n\n\n\n

    5.1 Accepter une d\u00e9finition floue de l’indisponibilit\u00e9<\/h3>\n\n\n\n

    Le premier pi\u00e8ge est la d\u00e9finition de l’indisponibilit\u00e9. Les \u00e9diteurs limitent souvent la notion \u00e0 l’inaccessibilit\u00e9 totale du service, en excluant les d\u00e9gradations partielles, les lenteurs critiques ou l’indisponibilit\u00e9 d’une fonctionnalit\u00e9 majeure. Une plateforme inutilisable mais techniquement \u00ab disponible \u00bb n’ouvre alors aucun droit \u00e0 p\u00e9nalit\u00e9. La d\u00e9finition doit couvrir toutes les formes d’inutilit\u00e9 op\u00e9rationnelle, mesur\u00e9es du c\u00f4t\u00e9 du client final.<\/p>\n\n\n\n

    5.2 Sous-estimer les exclusions de l’uptime<\/h3>\n\n\n\n

    Le deuxi\u00e8me pi\u00e8ge concerne les exclusions. Maintenance planifi\u00e9e, force majeure, fait du client, attaques de tiers, d\u00e9pendance \u00e0 des sous-traitants : la liste peut couvrir 50 % du temps r\u00e9el. Un uptime affich\u00e9 \u00e0 99,9 % avec 200 heures d’exclusions annuelles offre en r\u00e9alit\u00e9 bien moins. Il faut n\u00e9gocier chaque exclusion : limiter la maintenance planifi\u00e9e \u00e0 4 heures par mois en plages creuses, \u00e9carter la responsabilit\u00e9 des sous-traitants choisis par l’\u00e9diteur, exclure les attaques \u00e9vitables par les mesures de s\u00e9curit\u00e9 contractualis\u00e9es.<\/p>\n\n\n\n

    5.3 Plafonner les p\u00e9nalit\u00e9s \u00e0 un niveau d\u00e9risoire<\/h3>\n\n\n\n

    Le troisi\u00e8me pi\u00e8ge est le plafonnement des p\u00e9nalit\u00e9s. Beaucoup d’\u00e9diteurs plafonnent les avoirs \u00e0 5 ou 10 % de la redevance mensuelle, ce qui rend la sanction symbolique au regard des pertes r\u00e9elles du client. L’article 1170 du Code civil permet d’\u00e9carter cette clause si elle prive de sa substance l’obligation essentielle. La n\u00e9gociation doit obtenir des avoirs progressifs, un seuil de r\u00e9siliation pour d\u00e9faillances cumul\u00e9es et une clause de r\u00e9servation du droit \u00e0 indemnisation compl\u00e9mentaire pour les pr\u00e9judices sup\u00e9rieurs.<\/p>\n\n\n\n

    5.4 Ne pas anticiper NIS2 et la cha\u00eene de fournisseurs<\/h3>\n\n\n\n

    Le quatri\u00e8me pi\u00e8ge, sp\u00e9cifique \u00e0 2026, concerne NIS2. Si le client rel\u00e8ve des entit\u00e9s essentielles ou importantes, il doit \u00e9tendre les exigences cybers\u00e9curit\u00e9 \u00e0 ses fournisseurs critiques, dont les \u00e9diteurs SaaS. Un SLA qui ne traite pas explicitement la cybers\u00e9curit\u00e9 (article 21 paragraphe 2 d) directive UE 2022\/2555) expose le client \u00e0 un manquement \u00e0 ses propres obligations. La n\u00e9gociation doit int\u00e9grer un volet cybers\u00e9curit\u00e9 opposable avec audit, plan de rem\u00e9diation et notification rapide.<\/p>\n\n\n\n

    5.5 Ignorer l’AI Act quand le SaaS int\u00e8gre une IA<\/h3>\n\n\n\n

    Le cinqui\u00e8me pi\u00e8ge, \u00e9galement sp\u00e9cifique \u00e0 2026, concerne l’AI Act. Si la plateforme SaaS int\u00e8gre un syst\u00e8me d’IA \u00e0 haut risque, le SLA doit garantir l’acc\u00e8s permanent aux journaux requis par l’article 12, la disponibilit\u00e9 des fonctions de supervision humaine de l’article 14 et la notification rapide des incidents graves (article 73). Un SLA SaaS muet sur ces obligations cr\u00e9e un risque de non-conformit\u00e9 du client d\u00e9ployeur, sanctionnable jusqu’\u00e0 15 millions d’euros ou 3 % du chiffre d’affaires mondial.<\/p>\n\n\n\n

    6. Pourquoi faire appel \u00e0 Atias Avocats<\/h2>\n\n\n\n

    N\u00e9gocier un SLA SaaS \u00e0 la hauteur des enjeux exige une combinaison rare de comp\u00e9tences : ma\u00eetrise du droit des contrats (articles 1170, 1217, 1218, 1231-1 du Code civil), expertise des architectures cloud et des standards techniques (ISO 27001\/27017\/27018, SOC 2), pratique des relations avec les \u00e9diteurs SaaS internationaux, articulation avec NIS2 (directive UE 2022\/2555), le RGPD (article 32) et l’AI Act lorsque la plateforme int\u00e8gre un syst\u00e8me d’IA. Cette pluridisciplinarit\u00e9 est pr\u00e9cis\u00e9ment la valeur ajout\u00e9e d’un cabinet sp\u00e9cialis\u00e9 en droit du num\u00e9rique avec une pratique active des contrats IT.<\/p>\n\n\n\n

    Atias Avocats accompagne acheteurs IT, DSI, RSSI, directions juridiques, fondateurs de scale-ups et grands groupes sur l’ensemble du sujet : r\u00e9daction de SLA sur mesure, audit du parc contractuel SaaS d’une entreprise, n\u00e9gociation avec un \u00e9diteur dominant, articulation NIS2 et AI Act dans le SLA, d\u00e9fense en cas de manquement (action en ex\u00e9cution forc\u00e9e ou r\u00e9siliation), r\u00e9clamation d’avoirs et indemnit\u00e9s, audit pr\u00e9-renouvellement. Pour aller plus loin, consultez nos services en mati\u00e8re de contrats commerciaux et IT<\/strong><\/a>.<\/p>\n\n\n\n

    Conclusion<\/h2>\n\n\n\n

    Le SLA est le contrat dans le contrat. Sans engagement chiffr\u00e9 et mesurable, le client ach\u00e8te une promesse. Avec un SLA pr\u00e9cis, il ach\u00e8te des obligations de r\u00e9sultat opposables, d\u00e9clenchant automatiquement des avoirs en cas de d\u00e9faillance et un droit de sortie en cas de manquements graves. Les sept indicateurs pr\u00e9sent\u00e9s ici, combin\u00e9s \u00e0 la vigilance sur les cinq pi\u00e8ges classiques, offrent un r\u00e9f\u00e9rentiel directement utilisable par DSI, directions achats, RSSI et directions juridiques.<\/p>\n\n\n\n

    L’investissement requis pour n\u00e9gocier s\u00e9rieusement un SLA est sans commune mesure avec les pertes op\u00e9rationnelles \u00e9vit\u00e9es en cas de sinistre majeur. Pour une entreprise d\u00e9pendante de 100 SaaS critiques, c’est l’assurance que les promesses commerciales deviennent des engagements opposables. Le r\u00e9flexe \u00e0 adopter est clair : matricer les indicateurs, chiffrer les seuils, contractualiser les p\u00e9nalit\u00e9s, anticiper NIS2 et l’AI Act, n\u00e9gocier la clause de sortie. C’est pr\u00e9cis\u00e9ment cette discipline qui transforme un SaaS subi en service ma\u00eetris\u00e9.<\/p>\n\n\n\n

    FAQ \u2014 Questions fr\u00e9quentes<\/h2>\n\n\n\n

    Qu’est-ce qu’un SLA SaaS exactement ?<\/h3>\n\n\n\n

    Un SLA SaaS (Service Level Agreement, ou accord de niveau de service en fran\u00e7ais) est l’annexe contractuelle d’un contrat SaaS qui fixe les engagements quantitatifs et mesurables de l’\u00e9diteur sur la qualit\u00e9 du service. Il transforme des promesses commerciales en obligations juridiques opposables. Le SLA mesure typiquement la disponibilit\u00e9 de la plateforme (uptime), les d\u00e9lais de r\u00e9solution des incidents (MTTR), les temps de reprise apr\u00e8s sinistre (RTO et RPO), la qualit\u00e9 du support client, le niveau de s\u00e9curit\u00e9, les sauvegardes et les p\u00e9nalit\u00e9s en cas de non-respect. Sans SLA chiffr\u00e9, l’\u00e9diteur n’est tenu qu’\u00e0 une vague obligation de moyens. Avec un SLA pr\u00e9cis, il est tenu \u00e0 de v\u00e9ritables obligations de r\u00e9sultat dont la violation d\u00e9clenche automatiquement des avoirs ou indemnit\u00e9s.<\/p>\n\n\n\n

    Quelle disponibilit\u00e9 (uptime) faut-il exiger ?<\/h3>\n\n\n\n

    Le niveau de disponibilit\u00e9 d\u00e9pend de la criticit\u00e9 de l’usage. Un SLA SaaS standard du march\u00e9 propose 99,5 % (soit environ 1h45 d’indisponibilit\u00e9 par mois, 21 heures par an). Un SLA renforc\u00e9 pour applications critiques offre 99,9 % (43 minutes par mois, 8h46 par an). Un SLA premium pour syst\u00e8mes vitaux atteint 99,95 % (22 minutes par mois, 4h23 par an) voire 99,99 % (4 minutes par mois, 52 minutes par an). La n\u00e9gociation porte aussi sur la d\u00e9finition de l’indisponibilit\u00e9 (intermittence, d\u00e9gradation, maintenance planifi\u00e9e), la m\u00e9thode de mesure (par fonctionnalit\u00e9, sur la base du temps total) et les exclusions (force majeure, fait du client). Une disponibilit\u00e9 affich\u00e9e \u00e0 99,9 % mais avec dix pages d’exclusions vaut en r\u00e9alit\u00e9 95 %.<\/p>\n\n\n\n

    Que signifient MTTR, RTO et RPO dans un SLA ?<\/h3>\n\n\n\n

    Trois indicateurs techniques fondamentaux. Le MTTR (Mean Time To Repair, temps moyen de r\u00e9solution) mesure la dur\u00e9e entre la d\u00e9tection d’un incident et son r\u00e9tablissement complet. Un SLA SaaS s\u00e9rieux fixe un MTTR par niveau de gravit\u00e9 : critique (1-4h), majeur (8h), mineur (24-48h). Le RTO (Recovery Time Objective, objectif de temps de reprise) mesure le temps maximum acceptable pour red\u00e9marrer le service apr\u00e8s un sinistre majeur. Il oscille typiquement entre 4 et 24 heures. Le RPO (Recovery Point Objective, objectif de point de reprise) mesure la perte maximale de donn\u00e9es acceptable. Il varie de quelques minutes (sauvegardes en continu) \u00e0 24 heures (sauvegarde quotidienne). Ces trois indicateurs sont indispensables dans tout SLA structurant.<\/p>\n\n\n\n

    Quelles p\u00e9nalit\u00e9s exiger en cas de non-respect du SLA ?<\/h3>\n\n\n\n

    Les p\u00e9nalit\u00e9s standard du march\u00e9 prennent la forme d’avoirs (service credits) calcul\u00e9s en pourcentage de la redevance mensuelle. Pour une disponibilit\u00e9 comprise entre 99 % et 99,9 %, l’avoir est typiquement de 10 % de la redevance. Entre 95 % et 99 %, il monte \u00e0 25 %. Sous 95 %, il atteint 50 %, voire 100 %. Pour les incidents critiques avec MTTR d\u00e9pass\u00e9, l’avoir varie de 5 % \u00e0 20 %. Au-del\u00e0 de l’avoir, un seuil de gravit\u00e9 (g\u00e9n\u00e9ralement trois manquements cons\u00e9cutifs ou une indisponibilit\u00e9 sup\u00e9rieure \u00e0 48 heures cumul\u00e9es par mois) doit ouvrir un droit de r\u00e9siliation pour le client, sans p\u00e9nalit\u00e9 ni pr\u00e9avis. Cette \u00ab clause sortie \u00bb est l’arme ultime du client face \u00e0 un \u00e9diteur d\u00e9faillant.<\/p>\n\n\n\n


    Contact :     david@atiasavocats.com<\/a> | LinkedIn: David Joseph Atias<\/em><\/a> | https:\/\/www.atiasavocats.com<\/a> | 42 rue de la Clef, 75005 Paris<\/p>\n\n\n\n

    Atias Avocats \u2014 Contrats IT, SaaS, Cybers\u00e9curit\u00e9 NIS2, AI Act<\/em><\/p>","protected":false},"excerpt":{"rendered":"

    Par\u00a0David Joseph Atias, avocat au Barreau de Paris \u00b7\u00a0LinkedIn\u00a0\u00b7 Juin 2026 Le SLA SaaS est probablement la clause la plus mal n\u00e9goci\u00e9e des contrats SaaS. Annexe souvent dense de chiffres…<\/p>","protected":false},"author":1,"featured_media":23093,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-23092","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/atiasavocats.com\/en\/wp-json\/wp\/v2\/posts\/23092","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/atiasavocats.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/atiasavocats.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/atiasavocats.com\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/atiasavocats.com\/en\/wp-json\/wp\/v2\/comments?post=23092"}],"version-history":[{"count":1,"href":"https:\/\/atiasavocats.com\/en\/wp-json\/wp\/v2\/posts\/23092\/revisions"}],"predecessor-version":[{"id":23094,"href":"https:\/\/atiasavocats.com\/en\/wp-json\/wp\/v2\/posts\/23092\/revisions\/23094"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/atiasavocats.com\/en\/wp-json\/wp\/v2\/media\/23093"}],"wp:attachment":[{"href":"https:\/\/atiasavocats.com\/en\/wp-json\/wp\/v2\/media?parent=23092"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/atiasavocats.com\/en\/wp-json\/wp\/v2\/categories?post=23092"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/atiasavocats.com\/en\/wp-json\/wp\/v2\/tags?post=23092"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}