DORA et cloud : exigences pour les services externalisés

Le contrat cloud indique une disponibilité élevée, mais votre équipe sait-elle restaurer le service sans l’interface du fournisseur ? Sous DORA, l’analyse porte sur la continuité de la fonction financière, les dépendances et la capacité de sortie. La conformité d’un hébergeur ne remplace pas ces décisions propres à l’entité cliente.

Partir du service réellement utilisé

Les services cloud entrent dans la définition des services TIC de l’article 3(21) de DORA. Le prestataire tiers est défini au point 19 ; la fonction critique ou importante au point 22. Les trois notions répondent à des questions différentes.

Recensez le service acheté, ses composants, les entités utilisatrices et les fonctions soutenues. Un outil SaaS périphérique et la plateforme de paiement peuvent utiliser le même cloud sans présenter la même criticité. Les accords entrent dans le registre TIC ; les exigences contractuelles supplémentaires de l’article 30(3) dépendent de la fonction soutenue.

Conservez une fiche de qualification reliée au registre des accords TIC, avec le responsable métier et les raisons du classement. Actualisez-la lorsqu’un usage initialement secondaire devient indispensable.

Évaluer les dépendances avant la migration

Les articles 28(4) et 29 imposent l’évaluation préalable des risques et, pour les services concernés, de la concentration. Examinez la dépendance au prestataire et à ses composants communs, la substituabilité, les lieux de prestation, les sous-traitants et les contraintes de récupération des données en cas de défaillance.

Un schéma multicloud ne supprime pas nécessairement une concentration. Deux applications hébergées séparément peuvent dépendre du même fournisseur d’identité, du même réseau ou du même service de sauvegarde. Cette observation technique doit être vérifiée sur votre architecture ; ce n’est pas une présomption juridique contre un modèle donné.

Demandez aux équipes de répondre à quatre questions opérationnelles :

• Qu’est-ce qui reste utilisable si l’administration du cloud devient indisponible ?
• Qui détient les clés, les accès de secours et les sauvegardes nécessaires ?
• Quelle dépendance commune peut arrêter plusieurs services simultanément ?
• Quel délai de reprise est démontré, et quelles étapes restent seulement supposées ?

La diversification est une option à évaluer avec ses coûts et sa complexité. DORA n’impose pas à toute entité d’acheter deux clouds.

Vérifier le contrat et les responsabilités techniques

L’article 30(2) prévoit le socle applicable aux services TIC : description, lieux de traitement et de stockage, information préalable des changements, protection des données, récupération, niveaux de service, assistance aux incidents, coopération avec les autorités et résiliation.

Pour les fonctions critiques ou importantes, l’article 30(3) ajoute des objectifs de performance précis, des notifications d’évolutions significatives, des plans d’urgence testés, la coopération aux TLPT concernés, les droits d’audit et une transition adéquate à la sortie. Le détail de ces clauses contractuelles DORA doit être cohérent avec l’offre effectivement commandée.

Rendez également explicite la répartition des tâches : configuration des accès, chiffrement, correctifs, journaux, sauvegardes et restauration. Une prestation d’infrastructure ne transfère pas les mêmes opérations qu’un logiciel administré par son éditeur. Pour chaque tâche conservée par l’entité, identifiez le titulaire et la preuve de réalisation.

Obtenir des preuves adaptées au service

Un rapport d’audit peut contribuer à l’évaluation. Vérifiez sa période, les régions et services couverts, les exclusions et les contrôles restant à la charge du client. Une certification de l’organisation ne prouve pas que votre configuration respecte les exigences retenues.

Les tests de DORA relèvent des articles 24 et 25 pour le programme général ; l’article 26 organise les TLPT des entités sélectionnées. Il ne faut donc pas imposer indistinctement un TLPT à toute application cloud. Préparez des scénarios correspondant à vos dépendances : perte d’un composant, restauration, accès administrateur indisponible ou incident chez un sous-traitant.

Le fournisseur doit permettre la remontée d’informations nécessaire à la notification des incidents majeurs. Prévoyez des contacts et suppléants, les premières données attendues et les mises à jour. L’entité financière conserve la responsabilité de ses déclarations.

Construire une sortie réalisable

Pour les fonctions critiques ou importantes, l’article 28(8) prévoit des stratégies et plans de sortie documentés et suffisamment testés, avec des solutions alternatives et la continuité des activités. L’article 30(3)(f) les traduit dans la relation contractuelle.

Un export de fichiers n’est pas un plan complet. Vérifiez aussi les configurations, formats, dépendances applicatives, droits d’accès, capacité du repreneur et durée nécessaire à la transition. Le dossier doit distinguer un changement organisé d’une défaillance soudaine.

Les obligations de changement de fournisseur cloud du Data Act peuvent compléter ce dispositif. Elles n’effacent ni les contraintes de continuité de DORA, ni tous les coûts d’une transformation technique. Lorsque le service traite des données personnelles, appliquez également le contrat de sous-traitance et les règles de transfert du RGPD selon les opérations réelles.

Relier chaque engagement à une preuve utilisable

Le dossier d’achat peut comporter une matrice commune au métier, à la sécurité et au service juridique. Elle part de la fonction financière soutenue, puis décrit ce qui doit rester possible lorsque le service cloud est dégradé. Le niveau de disponibilité annoncé doit être rapproché des opérations concernées : consulter un dossier, valider un paiement ou retrouver une pièce ne mobilise pas nécessairement les mêmes composants.

Ce tableau constitue une méthode de préparation, pas un modèle réglementaire obligatoire. Pour chaque réponse, distinguez l’engagement signé, la documentation technique et l’observation effectivement disponible. Une procédure reçue peut être pertinente sans avoir encore été exécutée dans votre environnement. Inscrivez alors la vérification manquante et son responsable, au lieu de transformer le document en preuve de fonctionnement.

Les pièces doivent rester accessibles aux personnes chargées de gérer une crise. Si contrats, coordonnées et consignes de secours ne sont disponibles que dans le service indisponible, le dossier perd une partie de son utilité. Déterminez un mode d’accès de secours maîtrisé, avec des versions à jour et des habilitations appropriées.

Examiner un scénario de dépendance commune

Dans un exemple entièrement fictif, Anémone, entité financière soumise à DORA, utilise un SaaS pour traiter des opérations et un stockage distinct pour ses exports. Le métier a qualifié la fonction soutenue de critique ou importante. Le dossier mentionne deux fournisseurs, mais les connexions administrateur aux deux services passent par le même fournisseur d’identité.

Ce constat documentaire invite à examiner une hypothèse : si ce fournisseur d’identité est indisponible, les équipes peuvent-elles accéder aux éléments nécessaires à la reprise ? Il ne permet pas encore d’affirmer que les deux services tomberaient simultanément, ni qu’aucun accès de secours existe. Il faut obtenir les procédures, examiner leur indépendance et préparer une vérification autorisée.

Anémone doit également déterminer ce que contiennent ses exports. Une liste d’opérations peut manquer des pièces, des habilitations ou de la configuration indispensable à leur traitement. La présence des fichiers dans un autre stockage ne démontre donc pas que la fonction financière pourrait reprendre chez un autre prestataire.

Le compte rendu attendu sépare ces deux incertitudes : disponibilité des accès et suffisance des données récupérables. Une réponse positive sur l’une ne clôt pas l’autre. Cette séparation permet d’attribuer la correction à la bonne équipe, puis de réexaminer le risque résiduel avant d’étendre l’usage du service. Aucun résultat de restauration n’est supposé dans cet exemple.

Préparer la transition avec des critères de réception

Pour rendre la sortie exploitable, décrivez la situation d’arrivée attendue. Quelles opérations doivent reprendre, avec quelles données, quelle ancienneté d’historique et quels droits ? Définissez les critères de réception avec le métier et le repreneur pressenti, sans supposer que tous les réglages se transportent automatiquement.

Le plan peut ensuite répartir les étapes : extraire, transmettre, vérifier l’intégrité, interpréter les données, rétablir les accès et confirmer la reprise de la fonction. Attribuez un responsable à chaque étape et notez ses dépendances. Une estimation de durée qui omet la validation métier ou l’obtention des clés reste incomplète, même si le téléchargement paraît rapide.

Le contrat doit permettre de mobiliser l’assistance et la période de transition nécessaires. Clarifiez les prestations incluses, les coûts déterminés à l’avance lorsqu’ils sont prévus et les informations disponibles en cas de défaillance. Ne confondez pas un délai commercial de fermeture du compte avec la durée nécessaire pour migrer sans compromettre la continuité.

Après une vérification, consignez son périmètre et les limites restantes. Un export partiel réussi ne prouve pas une sortie complète. Les changements de fonction, de composant ou de sous-traitance doivent conduire à réexaminer les hypothèses concernées. Le suivi prévu par DORA se poursuit pendant la relation ; une acceptation initiale ne dispense pas d’actualiser le dossier.

Ce qu’il faut retenir

• Qualifiez le service et la fonction qu’il soutient avant de choisir les exigences renforcées.
• Vérifiez les dépendances communes, y compris dans une architecture multicloud.
• Affectez les responsabilités techniques conservées par l’entité.
• Éprouvez la reprise et la sortie sur les composants réellement nécessaires à l’activité.

FAQ

Un fournisseur désigné critique garantit-il notre conformité ?

Non. Le cadre européen de supervision complète la gestion des risques des entités financières sans la remplacer. Il ne valide pas chaque configuration ou contrat client.

Une certification suffit-elle pour accepter un cloud ?

Non. Elle peut constituer une pièce du dossier. Son périmètre et les contrôles restant à votre charge doivent être rapprochés de la prestation et de vos risques.

Faut-il forcément héberger toutes les données dans un seul pays européen ?

DORA impose de connaître les lieux et de maîtriser les risques, pas une règle générale d’hébergement dans un pays unique. Les obligations de données personnelles et d’éventuelles règles sectorielles doivent être examinées séparément.

Recevez nos analyses pratiques sur la conformité : inscrivez-vous à la newsletter.

Thiébaut Devergranne est docteur en droit et fondateur de donneespersonnelles.fr. Il travaille depuis plus de vingt ans sur le droit des technologies et la protection des données personnelles.