Niveaux de service dans les contrats SaaS : disponibilité, support et sanctions

Le SLA comme instrument de pilotage dans le contrat SaaS

Un accord de niveau de service (SLA) définit, en tant que partie intégrante du contrat ou dans un document contractuel distinct, des caractéristiques de performance concrètes d'un service informatique : la disponibilité, les délais de réaction et les délais de résolution des incidents. Ces indicateurs constituent des indicateurs clés de performance (KPI), permettant de mesurer la qualité d'un service informatique. Les SLAs sont répandus dans tous les domaines de l'informatique, des contrats d'exploitation aux solutions SaaS, en passant par l'infogérance classique. Ils se sont imposés dans le secteur IT grâce à ITIL et relèvent de la gestion des niveaux de service (SLM).

Les produits SaaS vont des outils de collaboration tels que Microsoft 365 et Google Workspace aux systèmes CRM, jusqu'à l'IA générative. Selon l'application, la criticité des processus métier varie, tout comme l'exigence de précision du SLA.

Dans les contrats SaaS, le SLA se concentre sur trois domaines : la disponibilité, le support et les sanctions. Chaque domaine requiert des spécifications propres : pourcentage, période de référence et méthode de mesure pour la disponibilité ; accessibilité ainsi que délais de réaction, d'intervention et de résolution pour le support ; conséquences juridiques, seuils et responsabilités pour les sanctions.

Le poids du SLA est plus important dans les contrats SaaS en raison de deux facteurs cumulés : les produits SaaS supportent régulièrement des processus métier importants ou critiques, et les clients paient généralement une redevance mensuelle. Il convient donc de définir quels standards qualitatifs le produit doit respecter, quand le support est joignable et dans quel délai une correction d'erreur doit être possible.

Le SLA rend la prestation qualitativement mesurable : les parties obtiennent la certitude que le produit correspond aux normes convenues – et savent ainsi quand il y a « défaut » ou « vice ». Cela permet d'estimer si, et à quelle hauteur, un paiement reste dû malgré le non-respect des standards convenus.

Souvent, un SLA est conclu lorsque les règles légales de garantie ne suffisent pas ou sont inadaptées au cas concret. En l'absence de clauses SLA claires, l'étendue des prestations, la responsabilité ou les mécanismes d'escalade restent flous, ce qui s'avère souvent coûteux en cas de litige. Un SLA crée la base nécessaire pour définir précisément le contenu des prestations et évaluer objectivement les violations contractuelles.

L'envers de la médaille : les clauses SLA sont souvent imprécises ou incomplètes dans la pratique et ne couvrent pas les besoins concrets. Ce constat n'intervient généralement qu'au moment où la prestation est fournie de manière défectueuse.

Un SLA établit des directives et des exigences claires : il offre aux parties une vue d'ensemble du contenu des prestations ainsi que des droits et obligations concrets, et permet d'évaluer à l'avance le risque en cas de panne. Pour les entreprises, cela signifie plus de sécurité juridique et moins de zones grises.

Pour les produits SaaS, un support rapide et une correction efficace des erreurs sont essentiels. Par conséquent, des dispositions spécifiques concernant les droits et obligations en cas de problèmes et de perturbations de service doivent figurer dans le contrat ; les obligations principales de prestation doivent être décrites aussi précisément que possible. À défaut de réglementation expresse, les dispositions légales s'appliquent, ce qui est souvent désavantageux dans le cas concret.

Avantages et risques des clauses SLA dans le contrat SaaS

Disponibilité : période de référence, méthode de mesure et fenêtres de maintenance

Une promesse de disponibilité se compose de trois éléments que le contrat doit définir individuellement : le pourcentage, la période de mesure ou de référence, et la méthode de mesure. En pratique, ces trois éléments doivent être clarifiés en premier lieu. Une panne a un impact différent selon la période de mesure : la même interruption pèse plus lourd dans une fenêtre courte que dans une longue.

Les fenêtres de maintenance sont généralement exclues de la disponibilité convenue. Le contrat doit donc définir quels aspects relèvent d'une fenêtre de maintenance et quelles conditions cadres s'appliquent – par exemple, une communication préalable aux clients ou des horaires clairement définis pour les travaux de maintenance. Sans ces conditions cadres, il est impossible de juger ultérieurement si une interruption compte comme une maintenance planifiée ou comme une panne.

Dans le modèle SaaS, l'exploitant assume les travaux de maintenance et les mises à jour logicielles. De telles interventions constituent le contenu typique d'une fenêtre de maintenance et doivent figurer au contrat avec un préavis, un canal de communication et des horaires clairement définis.

Il en découle que les travaux de maintenance planifiés ne doivent pas entrer dans le calcul de la disponibilité. Sinon, chaque maintenance correctement annoncée serait comptabilisée comme une panne et ferait baisser la valeur mesurée.

Un exemple suisse montre à quel point la promesse et la mesure peuvent diverger : le fournisseur BESA QSys indique pour sa plateforme SaaS RAI-System que l'exploitant garantit contractuellement une disponibilité de 99 %, tandis que la disponibilité mesurée actuelle avoisine les 100 %. Selon les mêmes indications, les données et l'infrastructure SaaS se trouvent dans un centre de données dans la région de Zurich.

La valeur garantie et la valeur mesurée sont donc deux grandeurs différentes. Celle qui fait foi en cas de litige ne découle pas du pourcentage, mais de la méthode de mesure convenue et de la période de référence.

Promesses de disponibilité SLA : Garanti vs Mesuré (Système RAI de BESA QSys)

Support : délais de réaction, d'intervention et de résolution

Un SLA distingue typiquement trois notions temporelles : le délai de réaction, le délai d'intervention et le délai de résolution. Ce qui compte, ce n'est pas seulement leur définition, mais aussi d'éventuelles différenciations.

Souvent, ces délais sont fixés par paliers selon la gravité d'un incident, dans un modèle d'incident gradué avec des niveaux de sévérité. Le degré de gravité détermine alors quels délais s'appliquent : une perturbation qui arrête l'activité commerciale déclenche d'autres délais qu'une demande n'entraînant aucune interruption de service.

Il est crucial de savoir quand commence à courir le délai de réaction : dès la notification par le client, dès sa réception dans un système spécifique, dès la confirmation de réception ou seulement après la classification de l'incident. Une définition simple dans le SLA répond à cette question. Sans elle, il reste incertain en cas de litige si un délai a effectivement été violé.

Liée à ces notions temporelles se trouve l'accessibilité du support : il faut convenir quand le support est joignable et dans quel délai une correction d'erreur peut intervenir. En pratique, on distingue entre les heures de bureau et une permanence continue. La variante appropriée dépend de la criticité du processus métier reposant sur le produit SaaS. Un modèle d'incident gradué combine les deux : il lie le degré de gravité à l'accessibilité et aux délais, au lieu d'imposer le même délai pour tous les cas.

Exemple de modèle basé sur les heures de bureau : WEKA indique pour son service clientèle téléphonique lu–ve 08h00–12h00 et 13h30–16h30 ; les demandes écrites sont traitées selon les disponibilités, même en dehors des heures téléphoniques. Qui promet un support uniquement aux heures de bureau doit indiquer ces horaires dans le SLA et préciser comment les notifications sont prises en compte en dehors de ces plages.

Les trois notions temporelles constituent également les références pour les sanctions. Un délai non respecté fournit la preuve mesurable à laquelle se rattachent un avoir ou un niveau d'escalade.

Définitions et exclusions : Pour éviter que le SLA ne reste sans dents

Des définitions claires constituent le premier point de contrôle, même si cela semble peu spectaculaire. Il faut répondre à des questions telles que : « À quoi se réfère la disponibilité ? » et « Quand commence à courir le délai de réaction ? ». Les réponses peuvent être relativement simplement consignées sous forme de définitions dans le SLA.

Cela inclut également la manière dont les erreurs et les vices sont décrits. C'est seulement via cette définition qu'il est possible de déterminer quand il y a écart par rapport au standard convenu et quels droits en découlent.

Les exclusions déterminent quels événements ne doivent pas être pertinents pour le SLA. Des exemples typiques sont les dépendances envers des tiers, les attaques DDoS et la force majeure. De telles exclusions sont légitimes, mais doivent être circonscrites de manière étroite : plus la formulation est ouverte, plus il est facile de classer une panne, que le fournisseur pourrait influencer, comme un cas exclu.

Des clauses floues ou incomplètes ont des conséquences concrètes. Les SLA sont souvent rudimentaires et formulés de manière imprécise dans la pratique, ce qui peut les rendre inefficaces. Les faiblesses n'apparaissent régulièrement qu'en cas de prestation défectueuse, et non lors de la signature du contrat. Un SLA qui ne définit pas ce qu'est une erreur, une fenêtre de maintenance ou une circonstance exclue n'offre aucune base pour une évaluation objective en cas de litige.

Les définitions agissent dans les trois domaines : elles décident quelle interruption compte comme une panne, quand un délai de support commence à courir et si une sanction est déclenchée. Erreur, vice, perturbation, début de la réaction, fenêtre de maintenance et exclusion doivent donc figurer explicitement dans le contrat.

Mesure, reporting et preuve

Les méthodes de mesure et les périodes de référence constituent le deuxième point de contrôle : qui mesure quoi, comment et pour quelles périodes ? Sans ces précisions, une promesse SLA est difficilement évaluable objectivement, car la période de référence modifie déjà le résultat. Qui ne réglemente pas la mesure laisse l'évaluation de facto à celui qui fournit les chiffres.

Le reporting soulève la question de la forme et de la périodicité avec lesquelles le fournisseur rapporte les valeurs mesurées, et si les points de mesure ou les données brutes sont fournis. Pour la preuve, il faut donc régler qui a accès aux données de mesure et comment traiter les lacunes de mesure. Le chiffre faisant foi en cas de litige ne découle pas de la promesse, mais des règles de mesure – méthode de mesure, période de référence et question de savoir quelle mesure est reconnue comme référence.

Le reporting est le pont vers les sanctions : sans valeurs de mesure attestées, il est impossible de prouver un dépassement. La forme, la périodicité et les droits d'accès doivent donc être réglés conjointement avec l'avoir.

Des vérifications régulières pour se protéger contre les accès non autorisés ne constituent pas une preuve de disponibilité. BESA QSys indique de telles vérifications pour le système RAI ; pour le SLA, ce sont les valeurs mesurées et leur documentation qui comptent.

Sanctions et conséquences en cas de violation du SLA

En l'absence de réglementation des conséquences en cas de violation, le SLA reste un « tigre de papier ». Les promesses de disponibilité et de délais de réaction restent sans engagement tant qu'aucune conséquence juridique n'y est attachée. Sans clauses claires, les mécanismes d'escalade restent également ouverts, ce qui s'avère coûteux en cas de litige.

Les sanctions se rattachent aux valeurs mesurées. Sans mesure réglementée, il manque la base pour constater une violation et déclencher un avoir.

En pratique, les conséquences discutées sont souvent des avoirs sur la redevance récurrente, ainsi que des niveaux d'escalade allant du premier interlocuteur jusqu'à la direction générale, et des droits de résiliation extraordinaire ou de retrait en cas de violations répétées ou graves. Quels mécanismes s'appliquent et à partir de quel seuil doit figurer dans la réglementation des conséquences. L'escalade devrait se rattacher aux mêmes niveaux de sévérité convenus pour les délais de support.

Quatre indications rendent une clause de sanction vérifiable : le seuil à partir duquel elle s'applique, le montant de l'avoir en proportion de la redevance récurrente, un éventuel plafond maximal et le nombre de répétitions à partir duquel un droit de résiliation extraordinaire s'applique. Ce n'est qu'avec ces indications qu'il est possible de calculer en cas de litige.

Les avoirs, les niveaux d'escalade et les droits de résiliation n'agissent que si les seuils et les responsabilités sont nommés. Sans ces indications, toute sanction reste une déclaration d'intention.

La question de la responsabilité borde les sanctions. Dans les contrats SaaS, les réglementations concernant la responsabilité, la garantie et les droits de propriété intellectuelle font partie du contenu habituel du contrat. Un SLA est justement conclu lorsque les règles légales de garantie ne suffisent pas ou sont inadaptées. Il faut donc clarifier comment les sanctions SLA et les règles générales de responsabilité interagissent – notamment si un avoir reste la conséquence finale ou si des prétentions plus étendues subsistent parallèlement.

Intégration dans le contrat SaaS, les CGV et la pratique suisse

Pour les modèles SaaS standardisés, le contrat SaaS, les conditions générales de vente (CGV), les niveaux de service, le contrat de traitement des données (DPA) et la documentation sur la protection des données doivent être coordonnés. Les questions relatives à l'utilisation des données, à l'exportation des données et à la sortie sont tout aussi importantes. Les modèles SaaS et logiciels nécessitent également des règles claires concernant l'étendue des prestations, la disponibilité, les droits d'utilisation, les mises à jour, le support, la responsabilité et la fin du contrat (Lezzi Legal, Zurich). Si le SLA mentionne des valeurs différentes des CGV ou de la documentation produit, une contradiction apparaît qui doit d'abord être résolue en cas de litige.

Les produits SaaS sont développés de manière itérative ; les fonctionnalités, les modèles de prix, les intégrations et les dépendances techniques changent continuellement. La documentation juridique devrait donc pouvoir évoluer avec le produit et ne pas devoir être reconstruite à chaque ajustement technique (Lezzi Legal).

Il en découle pour le SLA que les adaptations de la méthode de mesure, des fenêtres de maintenance et des horaires de support nécessitent une procédure ordonnée dans le contrat. Pour les contrats SaaS en Suisse, l'hébergement dans le pays peut être un élément contractuel judicieux. Le contrat type SaaS de WEKA cite comme avantages une disponibilité garantie avec des règles SLA clairement définies, un hébergement en Suisse avec sauvegardes, ainsi qu'une transparence des coûts grâce à des frais clairs et un modèle de facturation compréhensible.

S'y ajoutent des réglementations concernant la responsabilité, la garantie et les droits de propriété intellectuelle, ainsi que le contrôle sur ses propres données, y compris leur restitution sans droit de rétention. L'accès peut être concrétisé contractuellement : le fournisseur BESA QSys indique que l'accès à la solution SaaS est limité par défaut via un géoblocage ou peut être restreint à certains lieux d'accès lors de la configuration. De telles indications doivent être alignées avec le SLA, car un blocage d'accès peut déclencher les mêmes délais de disponibilité et de support.

La coordination comprend d'autres points : réglementations sur le droit d'auteur et la propriété intellectuelle, sur la responsabilité et la garantie, ainsi que sur le sort des données après la fin du contrat. Pour les contrats soumis au droit allemand, les CGV préformulées doivent être examinées au regard des §§ 305 à 310 du BGB. Pour les contrats à dimension internationale, notamment pour les services cloud, un besoin de vérification supplémentaire est indiqué.

Liste de contrôle pour la négociation contractuelle

La liste de contrôle examine les trois domaines du SLA dans cet ordre : disponibilité, support, sanctions. Chaque point n'est rempli que si le contrat contient une indication vérifiable – une valeur, une période, un délai ou un seuil.

Définitions : Qu'est-ce qu'une erreur, qu'est-ce qu'un vice, qu'est-ce qu'une perturbation ? À quoi se réfère la disponibilité ? Quand commence à courir un délai de réaction ? Les définitions dans le SLA répondent à ces questions et sont la condition préalable pour que le document ne reste pas sans effet.

Mesure et périodes de référence : Qui mesure quoi, comment et pour quelles périodes ? Quelle période de mesure s'applique à la disponibilité, et quelle valeur mesurée fait foi en cas de litige ?

Horaires de support : Noter séparément les délais de réaction, d'intervention et de résolution et différencier selon le degré de gravité (modèle d'incident gradué avec niveaux de sévérité). Régler en outre l'accessibilité du support.

Fenêtres de maintenance et exclusions : Définir quels aspects relèvent d'une fenêtre de maintenance et quelles conditions cadres s'appliquent (communication préalable, horaires clairement définis). Circonscrire étroitement les exclusions – les candidats typiques sont les dépendances envers des tiers, les attaques DDoS et la force majeure.

Conséquences et coordination : Une réglementation des conséquences des violations du SLA incluant des mécanismes d'escalade est impérative, sinon le SLA reste sans dents. Vérifier enfin si les niveaux de service, le contrat SaaS, les CGV, le contrat de traitement des données (DPA) et la documentation sur la protection des données sont coordonnés.

Preuve : Fixer la forme et la périodicité du reporting, régler les droits d'accès aux données de mesure, clarifier la gestion des lacunes de mesure et déterminer quelle mesure est reconnue comme référence.

Responsabilité : Examiner comment les sanctions SLA et les règles générales de responsabilité interagissent – notamment si un avoir reste la conséquence finale ou si des prétentions plus étendues subsistent parallèlement.

Fin du contrat : Régler le sort des données après la fin du contrat et clarifier la situation en matière de propriété intellectuelle et de droit d'auteur.