Partnerblog
L’accord de niveau de service, ou Service Level Agreement (« SLA »), a longtemps été principalement un instrument commercial et opérationnel : un accord entre un prestataire de services informatiques et un client concernant la qualité, la disponibilité et la continuité d’un service. Cette fonction demeure pleinement valable, mais le paysage réglementaire a profondément évolué ces dernières années. Avec DORA et la législation NIS2, le SLA n’est plus, pour de nombreuses entreprises, un simple document de qualité librement négociable, mais devient également un instrument permettant de satisfaire à des obligations légales contraignantes.
Pour le juriste d’entreprise, cela signifie que la rédaction et la révision des SLA s’inscrivent aujourd’hui dans une double logique : la logique contractuelle classique et la logique de conformité.
Le SLA reste, par essence, un instrument sur mesure
Un SLA est un accord, le plus souvent annexé à un contrat principal, qui détermine les niveaux de service auxquels le prestataire doit satisfaire. Ces niveaux sont exprimés au moyen d’objectifs de niveau de service, ou Service Level Objectives, opérationnalisés par des indicateurs de performance clés concrets et mesurables, les Key Performance Indicators. Les pourcentages de disponibilité, les délais de rétablissement, les délais de réaction et les fenêtres de maintenance en sont les exemples classiques.
Un bon SLA définit avec précision le périmètre des services, la méthode de mesure et les modalités de reporting, les conséquences d’un manquement contractuel, les service credits ou autres sanctions, à distinguer d’une indemnisation du dommage, une procédure de modification qui fait du SLA un « document vivant », ainsi qu’un mécanisme de règlement des différends, éventuellement assorti d’une procédure d’escalade.
Il n’existe pas de SLA standard : il s’agit toujours d’un instrument sur mesure, qui dépend de la nature du service et de son importance pour le client. Cela n’a pas changé. Ce qui est nouveau, en revanche, c’est que certains de ces éléments ne sont plus, pour certains secteurs, librement négociables, mais sont désormais prescrits par la loi.
DORA : le SLA comme composante centrale du contrat ICT
Depuis le 17 janvier 2025, le règlement sur la résilience opérationnelle numérique du secteur financier, ou Digital Operational Resilience Act (règlement (UE) 2022/2554, « DORA »), est applicable. DORA vise le secteur financier au sens large, notamment les banques, les entreprises d’assurance, les établissements de paiement, les entreprises d’investissement, les institutions de retraite professionnelle, ainsi que leurs prestataires tiers de services ICT.
L’objectif est d’assurer la résilience opérationnelle numérique du secteur financier, y compris lorsque des fonctions critiques ou importantes sont externalisées.
Une fonction est considérée comme critique ou importante au sens de l’article 3, point 22 de DORA, lorsque l’exécution défectueuse ou l’absence d’exécution de cette fonction serait susceptible de nuire sensiblement aux performances financières, à la solidité ou à la continuité des services de l’entité financière, ou encore à sa capacité continue de respecter les conditions d’agrément ou d’autres obligations légales.
Pour la pratique des SLA, les articles 28 et 30 de DORA sont particulièrement importants. Ils sont complétés par des normes techniques de réglementation, les regulatory technical standards (« RTS »). DORA impose que les accords conclus avec des prestataires tiers de services ICT soient consignés dans un document écrit, dans lequel le SLA joue un rôle central.
Le contrat doit contenir une série de clauses obligatoires énumérées à l’article 30 de DORA, lesquelles touchent directement au contenu traditionnel du SLA. Il s’agit notamment d’une description complète et claire de tous les services ICT, de niveaux de service détaillés définis de manière qualitative et quantitative, de dispositions relatives aux lieux où les données sont traitées, de droits d’accès, d’inspection et d’audit pour l’entité financière et l’autorité de contrôle, d’obligations de coopération dans le cadre de la surveillance, de règles relatives à la sous-traitance de fonctions critiques ou importantes, ainsi que de stratégies de sortie garantissant la continuité et le transfert des données en cas de résiliation.
Une attention particulière doit être portée aux motifs de résiliation. DORA impose que le contrat puisse être résilié dans certaines circonstances déterminées, sans préjudice de la continuité des activités de l’entité financière.
La distinction entre les fonctions ordinaires et les fonctions « critiques ou importantes » est déterminante pour l’intensité du régime applicable. Lorsque le service externalisé soutient une telle fonction, les exigences renforcées de l’article 30, paragraphe 3, s’appliquent. La responsabilité du respect des obligations demeure toutefois celle de l’institution financière, même lorsque l’exécution matérielle est externalisée.
Pour les prestataires, le message est clair : des conditions générales standard ne suffisent plus, et les contrats existants devaient en principe déjà avoir été renégociés début 2025.
NIS2 : la cybersécurité tout au long de la chaîne d’approvisionnement
Là où DORA est sectoriel, la loi NIS2 a une portée beaucoup plus horizontale, et donc plus large. La loi belge du 26 avril 2024 a transposé la directive NIS2 et est entrée en vigueur le 18 octobre 2024. Elle distingue les entités « essentielles » et les entités « importantes », et élargit considérablement le champ d’application par rapport à l’ancien régime NIS, notamment au moyen d’un critère de taille, qui vise en règle générale les moyennes et grandes entreprises actives dans les secteurs concernés.
Certaines catégories d’entités relèvent toutefois automatiquement de la loi, quelle que soit leur taille, comme notamment les fournisseurs de réseaux publics de communications électroniques, les fournisseurs de services DNS¹ et les prestataires de services de confiance qualifiés.
L’obligation la plus pertinente pour les SLA concerne la sécurité de la chaîne d’approvisionnement, ou supply chain. Une entité soumise à NIS2 doit évaluer et maîtriser les risques de cybersécurité dans sa chaîne de fournisseurs, et fixer contractuellement des exigences de sécurité avec ses prestataires.
La portée de cette obligation dépasse les entités qui relèvent directement de la loi. Une entreprise qui n’entre pas elle-même dans le champ d’application de NIS2, mais qui se trouve dans la chaîne d’approvisionnement d’une entité NIS2, peut néanmoins être tenue, par voie contractuelle, de respecter certaines mesures de cybersécurité. Pour les prestataires, il s’agit d’un point d’attention essentiel : les obligations NIS2 se répercutent contractuellement dans la chaîne, même lorsqu’elles ne s’appliquent pas directement au prestataire.
Concrètement, cela signifie que les clauses de sécurité dans les SLA gagnent en importance. L’article 30 de la loi belge NIS2 impose une série de mesures minimales : analyse des risques, gestion des incidents, sécurité lors de l’acquisition, du développement et de la maintenance des systèmes, contrôle d’accès, chiffrement, etc. Ces obligations doivent être traduites en engagements concrets relatifs aux niveaux de sécurité, aux délais de notification des incidents et aux obligations de coopération.
Pour les entreprises qui ne savent pas avec certitude si elles se trouvent dans la chaîne d’approvisionnement d’une entité NIS2, le Centre pour la Cybersécurité Belgique recommande d’appliquer au minimum le CyberFundamentals Framework (CyFun®) au niveau « Basic »².
En outre, NIS2 introduit une responsabilité accrue des organes de direction : le contrôle du respect des obligations relève de la responsabilité de l’organe d’administration, ce qui renforce encore l’importance d’une traduction contractuelle correcte.
Ce que cela signifie pour votre pratique des SLA
Le fil conducteur est clair : le SLA conserve sa fonction contractuelle classique, mais une couche de conformité s’y ajoute.
Toute entreprise qui rédige ou révise aujourd’hui un SLA a intérêt à répondre, dès le départ, à plusieurs questions essentielles. L’une des parties relève-t-elle de DORA, de NIS2, ou d’aucun des deux régimes ? Le service soutient-il une fonction critique ou importante ? S’agit-il d’un service dont la sécurité doit être encadrée contractuellement au titre de NIS2, dans le cadre de la chaîne d’approvisionnement ? Le prestataire se trouve-t-il dans la chaîne d’approvisionnement d’une entité réglementée, même s’il n’est pas lui-même directement visé ?
Les réponses à ces questions déterminent quelles clauses ne sont plus librement négociables et où une marge de manœuvre contractuelle subsiste.
Authors
[1] Domain Name System.
