Fournisseurs cloud : comment le gouvernement veut réguler le marché

Dans le cadre de l’examen du projet de loi visant à sécuriser et réguler l’espace numérique, il faudra attendre l’article 7  pour légiférer au sujet de la règlementation du secteur du Cloud.

Dans la version initiale du projet de loi, cet  article limitait la durée pendant laquelle un CSP pouvait octroyer des avoirs aux utilisateurs. Il interdisait par ailleurs de facturer des frais de transfert de données, à l’exception des frais de migration liés au changement de fournisseur.

En première lecture, le Sénat avait précisé la notion d’avoir. Il en avait spécifié, d’une part, le caractère temporaire. Et de l’autre, la pluralité des formes potentielles, entre « crédits offerts » et « quantité de services offerts ».

Les sénateurs avaient en outre voté l’interdiction d’assortir l’octroi d’avoirs à une quelconque condition d’exclusivité. Tout en fixant à un an la durée limite. Ils avaient, en parallèle, supprimé l’exception des frais de migration, la plafonnant, dans les grandes lignes, aux coûts réels directs supportés par le fournisseur.

Une loi alignée sur le Data Act

L’article 7 a évolué encore plus nettement lors de son examen en commission à l’Assemblée. Plusieurs définitions, jusqu’à celle du « service informatique en nuage », ont fait l’objet d’un alignement sur le Data Act. Le caractère « temporaire » des avoirs a disparu, comme la durée maximale d’octroi d’un an. Motif sur ce dernier point : un décret en Conseil d’État est plus adapté à la diversité des réalités que recouvre la notion d’avoir cloud ; il importe d’identifier ces réalités et de définir, pour chacune, une durée de validité et des conditions de renouvellement spécifiques.

Toujours avec le Data Act en toile de fond, la commission a revu la question des frais de transfert et de migration. Elle propose un nouvel article 7 bis, hors du Code du commerce, qui confiera à l’Arcep la mise en œuvre des obligations en la matière.

Ce 7 bis reprend et généralise la notion de plafonnement aux coûts directs supportés par le fournisseur. Il impose plus globalement une tarification maximale à définir par arrêté. Ses dispositions ne s’appliquent pas aux services cloud « sur mesure » ou dont les composants ne sont pas proposés à grande échelle.

Interopérabilité, portabilité : à l’Arcep de jouer

L’article 8 aborde les exigences d’interopérabilité et de portabilité. Le texte initial en imposait le respect dès lors que les services du fournisseur recoupent le « même type de fonctionnalités » que ceux du client (ou d’autres fournisseurs). Cela impliquait notamment la mise à disposition d’API.

Le Sénat n’avait pas apporté de modifications substantielles. La commission spéciale de l’Assemblée a quant à elle aligné des définitions sur le Data Act. Et introduit, dans la même logique, la notion de « données exportables ». C’est-à-dire, pour résumer, celles que génère l’utilisation du service.

L’article 9 charge l’Arcep de préciser les règles et modalités de mise en œuvre de ces exigences. Véhicule privilégié : l’édiction de spécifications. En la matière, le Sénat avait imposé de tenir compte des spécificités propres aux infrastructures, aux plates-formes et aux logiciels. La commission spéciale de l’Assemblée a modifié cette disposition. Elle a préféré une rédaction faisant la différence entre les services d’infrastructure et le reste.

« Cloud de confiance » : où sont les offres ?

Du vote au Sénat étaient ressortis deux articles supplémentaires (10 bis A et 10 bis).
Le premier avait pour principal effet d’encadrer le recours aux offres cloud commerciales pour l’hébergement de certaines données stratégiques et sensibles. Les autorités publiques allaient devoir sélectionner des prestataires établis dans l’UE et respectant des seuils d’actionnariat.
Le second imposait la transparence des fournisseurs sur plusieurs sujets, dont l’emplacement physique de leurs infrastructures.

La commission à l’Assemblée a jugé qu’il était trop tôt pour adopter de telles mesures. Son constat : l’offre de « cloud de confiance » n’est pas assez structurée pour le moment. On ajouterait donc une contrainte forte sur les acteurs concernés. Et on créerait un risque d’émergence d’offres ne proposant pas les garanties de sécurité nécessaires.

C’est sans compter le risque de contradiction avec la réglementation EUCS, en cours d’élaboration. Aussi les députés recommandent-ils de s’appuyer, à ce stade, sur les référentiels existants. D’un côté, SecNumCloud. De l’autre, la doctrine « Cloud au centre ».

Données de santé : imposer SecNumCloud

Les députés du groupe Démocrate (MoDem et indépendants) sont parvenus à faire ajouter un article relatif à la protection des données de santé qu’hébergent des acteurs privés. Il définit une échéance : le 1er juillet 2024. À partir de là, tout archivage numérique devra se faire sur des services qualifiés SecNumCloud. Il s’agit donc d’imposer les mêmes contraintes que celles s’appliquant à l’État. Autant dans le contexte des attaques de ces derniers mois sur des établissements de santé que dans la perspective des JO 2024.

Quant à l’obligation de transparence des fournisseurs, la commission a décidé de la limiter aux services qualifiés par l’ANSSI ou bénéficiant d’un certificat de cybersécurité européen. Elle a ajouté une exigence de publication d’informations environnementales.

Illustration © jpgon – Adobe Stock