Cloud souverain pour banques

Trois notions différentes sont regroupées sous un même terme général. La résidence indique un stockage dans un pays ou une région précis. La souveraineté opérationnelle implique des administrateurs situés dans l'UE et employés par une entité européenne, sans accès distant à la production depuis l'extérieur. La souveraineté juridictionnelle signifie qu'aucune loi hors UE ne peut imposer une divulgation, ce qu'une clause de résidence seule ne garantit pas, car un centre européen exploité par une société constituée aux États-Unis reste soumis au CLOUD Act, permettant aux autorités américaines de demander des données détenues par des sociétés américaines, partout dans le monde.

Cet écart explique les critères mesurables établis par la Commission européenne, au-delà des déclarations des fournisseurs. Son Cloud Sovereignty Framework transforme la souveraineté en critères d'achat selon huit objectifs: sécurité, conformité, transparence des chaînes d'approvisionnement et technologique, environnement, droit européen, stratégie européenne et opérations européennes. Pour ses institutions, la Commission a attribué l'accord-cadre à quatre fournisseurs européens, dont un consortium Post Telecom avec Clever Cloud et OVHcloud, ainsi que StackIT, Scaleway et Proximus. Le cadre introduit aussi les Sovereignty Effectiveness Assurance Levels, ou SEAL, évaluant les propriétés souveraines par niveaux plutôt que par oui ou non. Une banque peut utiliser ces critères pour son questionnaire et les niveaux SEAL pour structurer sa notation.

À côté du code de conduite se trouve une certification inachevée: European Cybersecurity Certification Scheme for Cloud Services, EUCS, élaborée sous le Cybersecurity Act. Les niveaux prévus vont de base à substantiel puis élevé, et le débat bloquant concerne une immunité au droit hors UE pour le niveau supérieur, excluant les prestataires soumis à des obligations étrangères de divulgation.

Le secteur n'a pas attendu la fin de ces travaux. European Sovereign Tech Industry Alliance, ESTIA, fondée par douze entreprises européennes dont Sopra Steria, Airbus, Deutsche Telekom, Orange, OVHcloud et Schwarz Digits, cite une norme EUCS High+ dans sa définition du cloud souverain, associant contrôle européen, localisation et protection contre les lois extraterritoriales. Pour une banque rédigeant un contrat, l'action pratique consiste à inscrire ces propriétés dans les clauses sans attendre un certificat potentiellement formulé autrement.

Deux instruments modifient ce cadre pendant la durée du contrat bancaire actuel. Le Data Act européen oblige les fournisseurs à permettre un changement, avec préavis, assistance transitoire et suppression progressive des frais de changement, donnant à la sortie un minimum légal nouveau. Un Cloud and AI Development Act est aussi en préparation, où figureraient une définition contraignante du cloud souverain et une préférence européenne dans les marchés publics.

Le rapport Draghi chiffre la pression politique: près de 90 pour cent des données européennes sont traitées hors UE. Sans prendre position sur ce chiffre, une banque peut anticiper sa conséquence, le durcissement des règles de localisation plutôt que leur assouplissement, nécessitant une renégociation des contrats limités aux minima actuels.

L'EU Cloud Code of Conduct relève de l'article 40 du RGPD pour les fournisseurs cloud sous-traitants. Un adhérent déclare qu'un service défini respecte les exigences du code mettant en œuvre l'article 28 du RGPD, et un organisme de contrôle accrédité selon l'article 41 vérifie cette déclaration. L'adhésion concerne le service, pas l'entreprise, donc l'inscription consultée doit nommer le service acheté.

L'adhésion répond uniquement à une question de protection des données. Elle ne remplace ni les clauses requises par DORA, ni l'analyse d'impact des transferts hors UE, et ne dit rien de la résilience ou de la sortie. La page EU Cloud Code of Conduct explique niveaux d'adhésion et registre public. Un instrument distinct au nom similaire, European Code of Conduct for Data Centre Energy Efficiency, traite de consommation électrique sans lien avec la protection des données.

Gaia-X n'exploite aucun serveur dans le cadre de son activité. C'est une association bruxelloise publiant un Trust Framework: règles d'autodescription des services lisible par machine et critères de conformité pour la vérifier. L'objectif est la comparabilité, permettant à une banque de lire les affirmations de résidence et de juridiction de deux fournisseurs dans le même format, plutôt que deux pages marketing. La page Gaia-X et finance présente le cadre et les espaces de données financières associés.

La presse présente parfois Gaia-X comme une réponse européenne aux hyperscalers. Gaia-X établit des spécifications, et la banque achète toujours son cloud auprès d'un fournisseur.

Acheter du cloud transforme le fournisseur en prestataire tiers TIC de la banque, déclenchant des obligations non délégables. DORA impose un registre de tous les accords contractuels TIC, précisant fournisseur, fonction soutenue et caractère critique ou important. Transmis au superviseur, ce registre révèle la concentration dans le secteur aux autorités européennes. Un prestataire désigné critique relève ensuite d'une supervision directe de l'UE, avec un superviseur principal pouvant l'examiner et formuler des recommandations.

Pour une banque supervisée en Allemagne, BaFin et la Bundesbank appliquent ces règles, et la page DORA en Allemagne couvre supervision nationale, registre et TIBER-DE. Le cadre européen figure dans la résilience opérationnelle numérique en Europe. Cette logique dépasse le cloud: une entreprise réglementée lisant une blockchain via un point d'accès hébergé unique a cette dépendance TIC, étudiée dans les fournisseurs RPC.

Une banque doit pouvoir quitter son prestataire lorsque cela devient nécessaire. DORA prévoit pour les fonctions critiques ou importantes des stratégies de sortie et des transitions où le fournisseur poursuit le service, permettant de déplacer une charge sans interruption. Le test est l'exercice réel de la clause: format des données récupérées, délai de reprise ailleurs et prise en charge des frais de sortie.

Deux facteurs architecturaux rendent la sortie coûteuse pour la banque. Les services gérés propres à un fournisseur n'ont pas d'équivalent ailleurs, imposant une réécriture. Un plan supposant une transition calme et négociée n'aide pas lorsque le déclencheur est la défaillance du fournisseur. Un plan utile nomme le second fournisseur, la copie déjà détenue et la dernière date de test.

Les questions prudentielles et politiques se sont posées en même temps. DORA a transformé la concentration TIC en fait déclaré et supervisé, tandis que les institutions européennes ont commencé à acheter leur cloud selon leurs critères souverains. Le prochain contrat bancaire répond donc au superviseur sur concentration et sortie, et au conseil d'administration sur la juridiction détenant les données.

Non, la localisation détermine uniquement la résidence des données concernées. Si l'exploitant est constitué hors UE, des lois étrangères de divulgation peuvent atteindre les données, et des administrateurs hors UE ayant accès à la production placent aussi le contrôle opérationnel à l'extérieur. Résidence, opérations et juridiction nécessitent trois clauses distinctes du contrat. Francfort concentre une grande part de l'hébergement européen, abordée dans les centres de données pour la finance à Francfort, mais la ville de l'adresse ne tranche pas le droit.

DORA fixe directement les règles de risque TIC et de tiers, et BaFin supervise leur application avec les exigences nationales d'externalisation. En pratique, une banque allemande inscrit l'accord au registre DORA, classe la fonction soutenue, obtient des droits d'audit et d'accès pour elle et le superviseur, et détient un plan de sortie. Pour les données personnelles, les exigences RGPD des sous-traitants s'appliquent parallèlement, et l'EU Cloud Code of Conduct fournit un élément de preuve utilisable.