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) consigne, en tant que clause contractuelle ou document distinct, les caractéristiques concrètes de prestation d'un service informatique, telles que la disponibilité, les délais de réaction ou les délais de résolution des incidents. Ces caractéristiques sont des indicateurs clés de performance (KPI) qui permettent de mesurer la qualité d'un service informatique. Les SLA sont répandus dans tous les domaines de l'informatique, des contrats d'exploitation aux solutions SaaS, en passant par les modèles classiques d'externalisation informatique. Ils se sont fait connaître dans le secteur informatique grâce à l'ITIL ; ils font partie intégrante du management des niveaux de service (SLM).

Dans les contrats SaaS, le SLA revêt une importance capitale, car deux facteurs se conjuguent : les produits SaaS supportent régulièrement des processus métier importants, voire critiques, et les clients paient en règle générale une redevance mensuelle. Il convient dès lors de définir les standards qualitatifs que le produit doit respecter, les plages horaires de disponibilité du support et les délais impartis pour la résolution des erreurs. Le SLA rend la prestation mesurable qualitativement : les parties acquièrent la certitude que le produit est conforme aux standards convenus – et partant, à partir de quand on est en présence d'un « défaut » ou d'une « lacune ». On peut ainsi estimer si, et dans quelle mesure, une rémunération reste due en cas de non-respect des standards convenus.

Souvent, un SLA est conclu précisément lorsque les règles légales de garantie s'avèrent insuffisantes ou inadaptées au cas d'espèce. 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 pose les bases pour définir précisément le contenu des prestations et évaluer objectivement les manquements contractuels.

Le revers de la médaille : dans la pratique, les clauses SLA sont souvent imprécises ou incomplètes et ne couvrent pas les besoins concrets. Ce n'est généralement que lorsque la prestation est fournie de manière défectueuse que l'on s'en aperçoit.

Avantages et risques des clauses SLA dans les contrats SaaS

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

Un engagement 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. Dans la pratique, ce sont précisément ces trois éléments qu'il faut clarifier en premier lieu. Une panne a des répercussions différentes selon la période de mesure – une 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 sont les conditions cadres applicables – par exemple, une communication préalable aux clients ou des plages horaires clairement définies durant lesquelles les travaux de maintenance peuvent avoir lieu. En l'absence de ces conditions cadres, il est impossible de déterminer ultérieurement si une interruption compte comme maintenance planifiée ou comme panne.

L'écart possible entre l'engagement et la mesure est illustré par un exemple suisse : le fournisseur BESA QSys indique pour sa plateforme SaaS RAI-System que l'exploitant garantit contractuellement une disponibilité de 99%, tandis que la disponibilité actuellement mesurée avoisine les 100%. Selon les mêmes indications, les données et l'infrastructure SaaS se trouvent dans un datacenter aux alentours de Zurich. La valeur garantie et la valeur mesurée sont ainsi deux grandeurs distinctes ; 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.

Comparaison des engagements de disponibilité et des méthodes de mesure dans les contrats SaaS suisses

Paramètres SLA importants dans les contrats SaaS suisses

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

Un SLA distingue typiquement trois notions de temps : le délai de réaction, le délai d'intervention et le délai de résolution. Ce ne sont pas seulement leurs définitions qui comptent, mais aussi d'éventuelles différenciations. Souvent, les délais sont fixés de manière échelonnée en fonction de la gravité d'un cas, dans un modèle d'incident échelonné avec des niveaux de sévérité. Le degré de gravité détermine alors les délais applicables – une perturbation qui paralyse l'exploitation déclenche d'autres délais qu'une demande sans interruption de l'activité.

La question centrale est de savoir quand le délai de réaction commence à courir : avec le signalement par le client, avec sa réception dans un système spécifique, avec la confirmation de réception ou seulement avec la classification du cas. Une définition simple dans le SLA répond à cette question – sans elle, il reste ouvert en cas de litige de savoir si un délai a été violé.

La disponibilité du support est liée à ces notions de temps : il convient de convenir quand le support est joignable et dans quel délai une erreur peut être résolue. Dans la pratique, on distingue les heures de bureau et un service assuré en continu ; la variante appropriée dépend du caractère critique du processus métier qui s'appuie sur le produit SaaS. Un modèle d'incident échelonné combine les deux : il lie le degré de gravité à la disponibilité et aux délais, au lieu de fixer le même temps pour tous les cas.

Définitions et exclusions : pour que le SLA ne reste pas lettre morte

Des définitions claires constituent le premier point de contrôle, même si cela paraît peu spectaculaire. Il faut répondre à des questions telles que : « À quoi s'applique la disponibilité ? » et « Quand le délai de réaction commence-t-il à courir ? ». Les réponses peuvent être consignées relativement simplement sous forme de définitions dans le SLA. Cela inclut également la manière dont les erreurs et les défauts sont décrits – c'est seulement par cette définition que l'on peut déterminer quand un écart par rapport au standard convenu se produit et quels droits en découlent.

Les exclusions précisent quels événements ne doivent pas être pertinents pour le SLA. Les 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 étroitement : plus la formulation est ouverte, plus il est facile de qualifier de cas exclu une panne que le fournisseur aurait pu influencer.

Les clauses imprécises ou incomplètes ont des conséquences concrètes. Dans la pratique, les SLA ne sont que trop souvent rudimentaires et formulés de manière peu claire, ce qui peut les rendre inopérants ; les faiblesses ne se révèlent régulièrement qu'en cas de prestation défectueuse, et non lors de la conclusion 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, en cas de litige, aucune base pour une évaluation objective.

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, un engagement SLA est difficilement évaluable de manière objective, car la période de référence modifie déjà le résultat. Celui qui ne règle pas la mesure laisse de fait l'évaluation à celui qui fournit les chiffres.

Le reporting soulève la question de la forme et de la périodicité avec lesquelles le fournisseur fait rapport sur les valeurs mesurées, et si les points de mesure ou les données brutes sont fournis.

Pour la preuve, il convient dès lors de régler qui a accès aux données de mesure et comment les lacunes de mesure sont traitées. Le chiffre qui fait foi en cas de litige ne découle pas de l'engagement, mais des règles de mesure – de la méthode de mesure, de la période de référence et de la question de savoir quelle mesure est reconnue comme référence.

Sanctions et conséquences en cas de violation du SLA

En l'absence de réglementation sur les conséquences en cas de violation, le SLA reste un « tigre de papier ». Les engagements en matière de disponibilité et de délais de réaction restent dépourvus de force obligatoire 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.

Dans la pratique, les conséquences discutées sont souvent des crédits sur la redevance récurrente, ainsi que des niveaux d'escalade allant du premier interlocuteur à la direction générale, et des droits de résiliation ou de rétractation extraordinaires en cas de violations répétées ou graves. Les mécanismes qui s'appliquent et à partir de quel seuil relèvent de la réglementation des conséquences ; l'escalade devrait ici s'articuler autour des mêmes niveaux de sévérité que ceux convenus pour les délais de support.

Aux sanctions s'ajoute la question de la responsabilité. Dans les contrats SaaS, les règles relatives à la responsabilité, à la garantie et aux droits de propriété intellectuelle font partie du contenu contractuel usuel, et un SLA est justement conclu lorsque les règles légales de garantie ne suffisent pas ou sont inadaptées. Il convient dès lors de clarifier comment les sanctions du SLA et les règles générales de responsabilité interagissent – en particulier si un crédit constitue la conséquence définitive ou si des prétentions plus étendues subsistent à côté.

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

Dans les modèles SaaS standardisés, le contrat SaaS, les conditions générales, 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 en outre des règles claires concernant l'étendue des prestations, la disponibilité, les droits d'utilisation, les mises à jour, le support, la responsabilité et la résiliation (Lezzi Legal, Zurich). Si le SLA mentionne d'autres valeurs que les CG ou la documentation du produit, il en résulte une contradiction qui doit d'abord être résolue en cas de litige.

Les produits SaaS sont développés de manière itérative ; les fonctions, les modèles de prix, les intégrations et les dépendances techniques changent continuellement. La documentation juridique devrait dès lors pouvoir évoluer avec le produit et ne pas devoir être reconstruite à chaque adaptation technique (Lezzi Legal). Pour le SLA, il en découle 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 en Suisse peut être un élément contractuel judicieux. Le contrat type WEKA pour SaaS cite comme avantages : une disponibilité garantie avec des règles SLA clairement définies, un hébergement en Suisse avec sauvegardes, une transparence des coûts via des frais clairs et un modèle de facturation compréhensible, des règles relatives à la responsabilité, à la garantie et aux 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 standardisé par un géoblocage ou peut être limité à certains lieux d'accès lors de la configuration. De telles indications doivent être comparées avec le SLA, car un blocage d'accès peut déclencher les mêmes délais de disponibilité et de support.

Check-list pour la négociation du contrat

Définitions : Qu'est-ce qu'une erreur, qu'est-ce qu'un défaut, qu'est-ce qu'une perturbation ? À quoi s'applique la disponibilité ? Quand le délai de réaction commence-t-il à courir ? Les définitions dans le SLA répondent à ces questions et sont la condition sine qua non pour que le document ne reste pas inopérant.

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

Délais de support : Consigner séparément les délais de réaction, d'intervention et de résolution et les différencier selon le degré de gravité (modèle d'incident échelonné avec niveaux de sévérité) ; régler en outre la disponibilité 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, plages horaires clairement définies). 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 sur les conséquences des violations du SLA incluant des mécanismes d'escalade est impérative, sinon le SLA reste inopérant. Vérifier en conclusion si les niveaux de service, le contrat SaaS, les CG, le contrat de traitement des données (DPA) et la documentation sur la protection des données sont coordonnés.

Hiérarchie des critères SLA les plus importants pour les contrats SaaS suisses