Comment la France envisage d’encadrer les fournisseurs cloud

À quand le volet des services cloud ? On n’en est pas encore là dans le cadre de l’examen, en plénière à l’Assemblée nationale, du projet de loi visant à sécuriser et réguler l’espace numérique.

En deux séances (après-midi du 4 octobre et matin du 5 octobre), les députés n’auront traité que les deux premiers articles, relatifs à la protection des mineurs. Il faudra attendre l’article 7 en arriver au cloud.

Limiter les crédits cloud et les frais de transfert

Dans la version initiale du projet de loi, ledit 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.

Alignement 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.

Trop tôt pour imposer le « cloud de confiance » ?

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é : SecNumCloud pour tous ?

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 1^er 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.

À consulter pour davantage de contexte :

Les données sensibles (enfin) explicitées dans la doctrine cloud de l’État
IT souveraine : le cloud de confiance cherche sa voie
Cloud public : des crédits aux frais de sortie, ce qui inquiète l’Autorité de la concurrence
Data Act : derrière l’accord politique, les désaccords stratégiques
L’issue approche pour le « SecNumCloud européen »
À quelle météo cyber s’attendre pour les JO 2024 ?

Illustration © jpgon – Adobe Stock