L’efficacité opérationnelle et économique du Cloud repose essentiellement sur les notions de standardisation, mutualisation et virtualisation. Ces traits distinctifs ont pour corollaire une plus grande rigidité du cadre contractuel proposé par les prestataires lequel doit refléter de manière uniforme une offre technique et commerciale ayant vocation s’appliquer à l’intégralité de la base client.

Ceci est particulièrement vrai dans le cadre d’un Cloud public tel celui d’Amazon Web Services reposant sur un très fort degré de standardisation et de mutualisation des ressources. Les choix en termes de niveaux de service et de sécurité ne se font en ce cas qu’à travers la sélection d’options prédéfinies.

Ce type de Cloud ne laissant qu’une place limitée à la négociation, il est nécessaire pour le client d’effectuer une analyse de risques en amont et de déterminer les catégories de données, d’application ou de fonctions qui pourront être traitées via le Cloud public en fonction de leur criticité sur le plan business et/ ou de la protection des données personnelles.

Ceci est particulièrement pertinent pour les offres IaaS (Infrastructure as a Service) et PaaS (Platform as a Service) mais également pour les offres SaaS (Software as a Service) dès lors que le service applicatif fourni est lui-même hébergé sur une infrastructure Cloud soumise à une politique de sécurité et de gestion des données prédéfinie.

Ces observations doivent être nuancées dans le cadre d’un Cloud privé ou hybride où la négociation sera plus ouverte en contrepartie d’un coût supérieur de souscription pour le client.

Cette aversion naturelle à la négociation des prestataires Cloud doit pourtant se concilier avec les contraintes grandissantes auxquelles sont exposés les utilisateurs. Le règlement européen sur la protection des données personnelles (RGPD) a ainsi imposé un cadre contractuel plus contraignant auquel les solutions Cloud doivent se conformer. Ce texte européen directement applicable en France prévoit à l’article 28 une liste de clauses contractuelles à insérer dans le contrat avec son prestataire, en charge de la mise en œuvre de traitements de données à caractère personnel pour son compte.

Les acteurs du Cloud se plient néanmoins avec plus ou moins de docilité aux nouvelles exigences européennes.

La loi sur la Sécurité des Réseaux et Systèmes d’Information du 26 février 2018 adoptée en application de la Directive Network and Information Security (NIS) exige également des « opérateurs de services essentiels » tels que définis par le décret du 25 mai 2018 et des fournisseurs de services numériques la mise en place de politiques et mesures de sécurité adéquates sous le contrôle de l’ANSSI.

Les fournisseurs Cloud devront donc être en mesure de permettre aux opérateurs de services essentiels d’être en conformité avec leurs obligations réglementaires.

La loi américaine dite « Cloud Act » (Clarifying Lawful Overseas Use of Data Act) visant à clarifier les règles relatives aux réquisitions des autorités américaines sur les données stockées a elle-même ravivé les craintes des entreprises européennes sur un possible accès indu à leurs données par les autorités gouvernementales américaines lorsque leur prestataire Cloud est établi aux Etats-Unis ou est une filiale d’un prestataire soumis à la compétence des autorités judiciaires et administratives américaines.

Compte tenu du nouveau contexte juridique du Cloud, le contrat avec le prestataire constitue un enjeu majeur. Une vigilance plus particulière doit être accordée aux clauses relatives à  l’adéquation des mesures de sécurité des données, au contrôle du recours par le prestataire à la sous-traitance, à l’encadrement des transferts des données hors Union Européenne, à l’exercice du droit d’audit et à la réversibilité/ portabilité.

L’adéquation des mesures de sécurité des données

Le RGPD met à la charge des clients des prestataires du Cloud l’obligation de ne faire appel qu’à des prestataires qui présentent des garanties suffisantes quant à la mise en œuvre de mesures techniques et organisationnelles appropriées de manière conforme à la règlementation applicable.

Par conséquent, le prestataire doit s’engager contractuellement à respecter le RGPD et justifier, dans la mesure du possible, de la mise en œuvre de mesures techniques et organisationnelles suffisantes dans une annexe « sécurité ». Le niveau de granularité de la description de ces mesures techniques et organisationnelles doit nécessairement se limiter à la non-divulgation des « secrets » permettant d’assurer la sécurité des données.

Conformément aux dispositions de l’article 32 du RGPD, selon les besoins, les parties au contrat doivent mettre en place une procédure visant à tester, à analyser et à évaluer régulièrement l’efficacité des mesures techniques et organisationnelles pour assurer la sécurité du traitement.

La démonstration du respect des exigences en matière de sécurité des données peut être établie par l’application d’un code de conduite approuvé comme le prévoit l’article 40 du RGPD ou d’un mécanisme de certification approuvé comme le prévoit l’article 42 du même texte. Le cas échéant, le contrat devra faire référence à ces instruments de justification et de contrôle de l’adéquation des mesures de sécurité mises en place par le prestataire.

Par ailleurs, d’un point de vue plus opérationnel, il est à noter que l’obligation de notification de toute violation de données aux autorités de régulation compétentes dans les 72 heures de sa détection sous peine de sanction pécuniaire (allant jusqu’à 10 millions d’euros d’amende ou 2%) est à la charge des clients de prestataires Cloud en leur qualité de responsable de traitement.

Il convient donc d’anticiper l’hypothèse où la violation de données trouverait sa source chez le prestataire Cloud, et prévoir ainsi l’obligation pour le Prestataire Cloud d’informer sans délai son Client aussitôt qu’une violation est détectée par lui et de communiquer au client les informations nécessaires au respect de son obligation de notification.

De son côté, l’agence nationale de la sécurité des systèmes d’information, l’ANSSI, recommande aux organismes publics et privés de recourir à des solutions Cloud disposant d’un « Visa de sécurité » ANSSI, justifiant du respect par le prestataire Cloud du référentiel SecNumCloud établi à cet effet par l’agence.

Le référentiel est particulièrement détaillé et prévoit également un certain nombre de recommandations quant au cadre contractuel des solutions Cloud. Il précise notamment que le prestataire doit exiger des tiers, en ce compris les sous-traitants du prestataire participant à la mise en œuvre du service, un niveau de sécurité au moins équivalent à celui que le prestataire s’engage à maintenir dans sa propre politique de sécurité.

Le contrôle du recours à la sous-traitance par le prestataire

Les prestataires Cloud, et notamment les fournisseurs de solutions SaaS, recourent à de nombreux sous-traitants pour assurer la délivrance optimale de leur solution à un coût compétitif. Or, au regard du droit européen de la protection des données personnelles, le prestataire ne peut recruter un autre sous-traitant sans l’autorisation écrite préalable, spécifique ou générale, du responsable du traitement, à savoir le client du prestataire.

Les contrats Cloud doivent donc prévoir a minima une telle autorisation écrite générale. Toutefois, il doit être précisé que dans un tel scénario, le prestataire cloud devra informer son client de tout changement prévu concernant l’ajout ou le remplacement d’autres sous-traitants, afin de permettre à celui-ci d’émettre des objections à l’encontre de ces changements.

Le texte n’impose cependant pas au prestataire de suivre les objections ainsi émises par son client. En revanche, si l’objection est déterminante (comme par exemple l’insuffisance des mesures techniques et organisationnelles mises en œuvre afin d’assurer la sécurité des données), l’absence de suivi de cette objection par le prestataire pourra faire l’objet d’une contestation judiciaire et de la mise en jeu de la responsabilité de celui-ci.

Le recours à la sous-traitance par les prestataires Cloud pose nécessairement la question du transfert de données à caractère personnel hors Union européenne.

L’encadrement du transfert des données hors Union européenne

Qu’ils soient eux-mêmes situés hors Union européenne ou qu’ils recourent à des sous-traitants localisés en dehors de ce territoire, les prestataires Cloud sont susceptibles de transférer à l’extérieur des frontières de l’Union européenne les données à caractère personnel qui leurs ont été confiées par leurs clients.

Dans ce cas, il convient de veiller à encadrer contractuellement cette opération tant en termes de transparence sur les éventuels transferts de données et leurs caractéristiques, qu’en termes de garanties juridiques permettant de rendre licite un tel transfert de données à caractère personnel hors Union européenne (exemple : consentement éclairé, libre, spécifique et non équivoque des personnes concernées, ou Privacy Shield pour les entreprises américaines ou clauses contractuelles types de la Commission européenne signées par le prestataire et son client mais aussi par le prestataire et ses sous-traitants ou BCR, Binding Corporate Rules, règles contraignantes d’entreprise ou Code de conduite, définissant la politique d’une entreprise en matière de transferts de données personnelles).

Il est cependant à noter que de nombreux pays ont bénéficié d’une décision d’adéquation de la Commission européenne avec lesquels les transferts de données peuvent s’opérer sans contraintes particulières. Tel est le cas par exemple de l’Argentine, d’Andorre, du Canada, de Guernesey, de l’Ile de Man, des Iles Féroé, d’Israël et dernièrement le Japon.

En toutes hypothèses, avec l’entrée en vigueur du RGPD, le prestataire doit désormais se soumettre, dans une certaine mesure, aux mesures d’audit mises en œuvre par ses clients.

Exercice du droit d’audit

Compte tenu des contraintes auxquelles il est susceptible d’être exposé (RGPD, Loi sur la Sécurité des Réseaux et Systèmes d’Information (loi SRSI), réglementation sectorielle, contrôle interne etc.), il est essentiel que le client conserve la possibilité de s’assurer du respect par le prestataire de ses obligations à travers des points de contrôle contractuellement organisés.

Les audits auront notamment pour vocation de vérifier la conformité aux obligations de sécurité, aux règles régissant le traitement des données personnelles, aux engagements de niveau de service ou aux exigences réglementaires sectorielles le cas échéant applicables en matière d’externalisation.

Les mesures d’audits peuvent ainsi prendre la forme de contrôles préventifs ou de routine par exemple dans le cadre d’un programme d’audit piloté par les services de contrôle interne, d’audits de diagnostic ou de remédiation (en cas de défaillances ou d’incidents constatés) ou d’audits réglementaires diligentés à la demande d’un régulateur ou autre instance de supervision et de contrôle (CNIL, ANSSI, Autorité de Contrôle Prudentiel et de Régulation etc.).

La fréquence, la durée, la définition du périmètre et des modalités, la répartition des coûts ainsi que l’encadrement et le suivi des mesures résultant des vérifications réalisées constituent les points d’attention contractuels classiques.

Le contrat peut spécifier que ces audits seront réalisés « sur pièces » mais également « sur site ». En pratique, la mise en œuvre de l’audit sur site se heurte à un certain nombre d’obstacles.
Ainsi, le prestataire, et plus spécifiquement le prestataire Cloud de type SaaS, aura le plus souvent recours à des sous-traitants de type AWS ou OVH pour l’hébergement de sa plateforme et ses services applicatifs.

Il sera donc nécessaire de s’assurer que le prestataire SaaS a bien négocié en amont la conduite de tels audits dès lors que ceux-ci peuvent nécessiter l’accès aux infrastructures techniques du sous-traitant. Ceci ne sera pas toujours possible, certains hébergeurs refusant ou restreignant de manière drastique l’accès à leurs data centers ou autres infrastructures pour des raisons de confidentialité et afin d’éviter les perturbations dans l’exploitation qu’occasionneraient des audits continuels de la part de leurs propres clients et des clients de ces derniers.

Dans le cas d’une impossibilité de cet ordre, des audits sur pièce pourront être effectués à travers les rapports d’activité fournis par les prestataires. Il est également d’usage de solliciter les rapports ayant pu être émis par des auditeurs externes dans le cadre de programmes de certification de type ISO ou en application des procédures SOC (Service Organisation Control) dérivées de la réglementation Sarbanes-Oxley en matière de contrôle interne (ex : rapports ISAE 3402, SAS 70 ou SSAE 16 de type II). Ces rapports de type II établissent que les procédures et systèmes de contrôle fournissent une assurance raisonnable en matière de gestion de risques et peuvent donc se substituer à un audit de sécurité qui serait effectué à l’initiative et aux frais du client.

Il n’en demeure pas moins que l’audit sur site s’imposera lorsque sollicité par un régulateur et que cette éventualité devra ainsi figurer au contrat sans possibilité pour le prestataire de s’y soustraire. Toute impossibilité pour un organisme comme la CNIL de procéder aux contrôles requis peut en effet déboucher sur de lourdes sanctions (jusqu’à 4% du chiffres d’affaires au titre de l’obstacle aux opérations de contrôle).

Cette exigence de contrôle sur « site » est également expressément prévue par la loi SRSI intimant aux entreprises qualifiées d’opérateurs de services essentiels » : « de communiquer à l’autorité ou au prestataire de service chargé du contrôle prévu au premier alinéa du présent article les informations et éléments nécessaires pour réaliser le contrôle, y compris les documents relatifs à leur politique de sécurité et, le cas échéant, les résultats d’audit de sécurité, et leur permettre d’accéder aux réseaux et systèmes d’information faisant l’objet du contrôle afin d’effectuer des analyses et des relevés d’informations techniques » (article 8).

Il est donc essentiel de distinguer ce type de contrôle des audits purement contractuels et de les soumettre à un régime d’exception en termes notamment de fréquence et de modalités d’exécution sauf à risquer de se mettre en porte à faux vis-à-vis de la réglementation applicable.

De la réversibilité à la portabilité

Bien que couramment usité, le terme « réversibilité » est inadapté à l’environnement Cloud.

La réversibilité consiste en effet à reprendre en interne, à l’issue du contrat, des activités externalisées en vue de les exploiter directement ou de les confier à un tiers via une autre opération d’outsourcing. A ce titre, la réversibilité met généralement l’accent sur le transfert de compétences et de connaissances, la formation aux procédures d’exploitation, le sort des équipements voire la question du transfert des salariés rattachés à l’activité transférée.

Rien de tout cela n’a cours dans l’univers du Cloud dès lors que la fin du contrat implique uniquement la cessation de l’accès à la plateforme ou aux infrastructures virtuelles. Le changement de prestataire n’implique donc, en temps normal, aucun transfert de connaissances ou reprise d’éléments logiciels ou matériels.

Reste la question de la reprise des données. Le client devra, en effet, s’assurer qu’il sera en mesure de récupérer l’intégralité de ses données hébergées sur l’environnement du prestataire selon des conditions de nature à permettre, lorsque cela est nécessaire, leur exploitation ou leur transfert sous un autre environnement. C’est pourquoi il est plus exact de parler de « portabilité » ou de « portage » des données pour qualifier cette phase d’assistance contractuelle que de réversibilité.

Conscients que la question de la portabilité des données était susceptible de constituer un frein au changement de fournisseurs Cloud et, partant, à l’essor de la concurrence dans le secteur, l’Union Européenne a récemment posé certaines règles à cet égard dans le cadre du règlement 2018/1807 du Parlement européen et du Conseil du 14 novembre 2018 « établissant un cadre applicable au libre flux des données à caractère non personnel dans l’Union européenne ».

Il résulte de l’article 6 dudit règlement que les fournisseurs de service de traitement de données devront élaborer sous l’égide de la Commission européenne des codes de conduite qui devront notamment viser à définir les bonnes pratiques facilitant « le changement de fournisseurs de services et le portage des données dans des formats structurés, usuels et lisibles par machine, notamment dans des formats standard ouverts, lorsque le fournisseur de services obtenant les données le demande ou l’exige » ainsi que les exigences minimales d’information concernant « les exigences techniques, les délais et les frais qui s’appliquent dans le cas où un utilisateur professionnel souhaite changer de fournisseur de services ou transférer ses données pour les rapatrier vers ses propres systèmes informatiques ».

Il est bien évidemment conseillé de ne pas attendre l’adoption des codes de conduite précités pour refléter de telles exigences au sein du contrat conclu avec un prestataire Cloud.

De même, il est généralement conseillé d’anticiper tout problème potentiel de migration et d’éviter les dates « couperets » de fin de contrat qui auraient pour conséquence l’interruption du service Cloud auquel il est mis fin avant que la mise en production sur la plateforme du nouveau prestataire ne soit effective.

A cet égard, il apparaît donc essentiel de ménager une période de transition contractuelle au cours de laquelle le prestataire sortant maintiendra le service selon les niveaux d’engagement stipulés contre rémunération adéquate jusqu’à la migration complète des données du client.