DORA : confier l'hébergement et la maintenance de son site sans perdre sa conformité

Pendant longtemps, le site institutionnel d’un établissement financier relevait surtout de la communication. Son hébergement et sa maintenance se négociaient comme toute prestation web : un niveau de service, un forfait, une durée d’engagement.

Le règlement (UE) 2022/2554, dit DORA (Digital Operational Resilience Act), s’applique depuis le 17 janvier 2025 (EUR-Lex). Il impose aux entités financières de maîtriser le risque lié à leurs prestataires de services TIC (technologies de l’information et de la communication). Le contrat devient l’outil central de cette maîtrise.

Nous hébergeons et maintenons le site d’un établissement de crédit français qui a dû mettre ce contrat en conformité. Le chantier a duré quatre mois et mobilisé la DSI du client, sa direction juridique, ses avocats et nos équipes. Il s’est conclu par la signature de conditions générales DORA. Voici ce que nous en retenons, côté donneur d’ordre comme côté prestataire.

Un site vitrine peut devenir une fonction critique

DORA distingue deux catégories de services TIC. Ceux qui soutiennent des « fonctions critiques ou importantes » relèvent d’exigences renforcées, listées à l’article 30 du règlement. L’entité financière procède seule à cette qualification. Notre client a classé l’hébergement et le maintien en condition opérationnelle de son site institutionnel dans cette catégorie.

Un site « non transactionnel » n’échappe donc pas forcément aux règles les plus strictes. Si vous êtes prestataire, partez du principe que votre client peut faire ce choix, et préparez-vous en conséquence.

Le périmètre s’étend aussi à vos propres fournisseurs. La première demande de notre client a porté sur notre hébergeur cloud : il voulait son « paquet DORA ». Ce dossier rassemble les preuves de sa gestion des risques TIC, de sa continuité d’activité et de sa gestion des incidents.

Nous l’avons transmis en une semaine, car les grands hébergeurs européens tiennent cette documentation à disposition :

• la certification ISO/IEC 27001 et sa déclaration d’applicabilité ;
• l’accord de traitement des données au sens du RGPD, avec la liste des sous-traitants ultérieurs ;
• les procédures de gestion des incidents.

Les pièces les plus détaillées restent accessibles après signature d’un accord de confidentialité. Ce délai court suppose d’avoir choisi un hébergeur capable de produire ces éléments. Sans cela, l’exercice peut vite tourner au casse-tête.

Des clauses imposées, des annexes à négocier

L’article 30 de DORA fixe d’abord un socle pour tout contrat de services TIC. Il couvre la description des services, les lieux de traitement et la protection des données, les niveaux de service et l’assistance en cas d’incident. S’y ajoutent la coopération avec les autorités, les droits de résiliation et la participation aux programmes de sensibilisation de l’entité.

Pour une fonction critique ou importante, le contrat doit aussi prévoir :

• des niveaux de service assortis d’objectifs de performance quantitatifs et qualitatifs précis ;
• des délais de préavis et des obligations de notification envers l’entité ;
• des plans d’urgence testés et des mesures de sécurité TIC définies ;
• la participation aux tests de pénétration fondés sur la menace (TLPT, Threat-Led Penetration Testing) menés par l’entité ;
• des droits illimités d’accès, d’inspection et d’audit, pour l’entité comme pour les autorités ;
• une stratégie de sortie assortie d’une période de transition obligatoire.

Dans la pratique, l’entité financière rédige elle-même ces clauses. Notre client nous a adressé ses propres conditions générales DORA, chaque article annoté de sa référence au règlement. Des annexes restaient à compléter : description des services, localisation des données, niveaux de service, objectifs de reprise. Ces conditions servent désormais de standard pour tous ses prestataires critiques, et discuter leur formulation a peu de chances d’aboutir.

Les annexes concentrent donc la négociation. Elles transforment des principes généraux en engagements chiffrés, et permettent au prestataire de s’engager sur ce qu’il sait réellement tenir. Nous y avons consacré l’essentiel de notre travail, avec un objectif : borner chaque obligation en volume ou en délai.

Le site de secours, pièce maîtresse du dispositif

La DSI du client a porté le point le plus structurant du dossier. Jusqu’ici, la résilience du site reposait sur les mécanismes de redondance de l’hébergeur. Pour une fonction critique, ce filet ne suffit plus : si l’hébergeur lui-même défaille, le site tombe avec lui. Le client a donc exigé un site de secours, des objectifs de reprise contractualisés et un test de bascule annuel.

Sa demande initiale portait sur une réplication dans un second centre de données du même hébergeur. Nous avons proposé de répliquer chez un second hébergeur français. Cette option couvre la panne d’un centre de données comme la défaillance d’un fournisseur entier. Elle répond directement à la préoccupation de DORA sur le risque de concentration. Le client l’a retenue, et le dispositif fonctionne ainsi :

1. Chaque jour, un instantané de la machine de production (base de données et fichiers compris) part vers un espace de sauvegarde chiffré chez le second hébergeur, en France.
2. Une instance de secours y reste préprovisionnée et maintenue en veille.
3. En cas de sinistre, la bascule s’opère au niveau du CDN (réseau de diffusion de contenu) placé devant le site : il change d’origine sans attendre la propagation DNS.
4. Une fois par an, un test de bascule complet donne lieu à un procès-verbal partagé avec le client.

Côté objectifs, nous avons retenu un RPO (Recovery Point Objective, perte de données maximale admissible) de 24 heures, cohérent avec une réplication quotidienne. Le RTO (Recovery Time Objective, délai de remise en service) est fixé à 12 heures ouvrées. Pour un site institutionnel dont les contenus évoluent peu dans la journée, ces valeurs ont été jugées suffisantes. Un site transactionnel exigerait une réplication bien plus fréquente, avec un coût en proportion.

Attention à un piège de rédaction. Sans précision sur leur champ d’application, ces objectifs peuvent se lire comme un engagement valable pour n’importe quelle panne. Nous avons fait inscrire que le RPO et le RTO s’appliquent à l’activation du site de secours en cas de sinistre majeur. Les incidents courants restent régis par les niveaux de service habituels du contrat.

Borner chaque obligation, préparer la sortie dès l’entrée

Formulées en termes généraux, plusieurs exigences de DORA créent des charges difficiles à anticiper, pour le client comme pour le prestataire. Elles concernent les audits étendus aux autorités, la participation aux TLPT, l’assistance sur incident, la sensibilisation et la restitution des données. Le texte laisse pourtant une marge : l’assistance sur incident peut être fournie sans frais supplémentaires ou à un coût déterminé à l’avance.

Nous avons choisi de tout intégrer dans un forfait unique : un seul prix, sans facturation complémentaire à anticiper. Ce forfait s’adosse à des volumes de référence inscrits en annexe :

• un audit par an ;
• une session de sensibilisation par an ;
• une participation aux TLPT au rythme triennal prévu par le règlement ;
• l’assistance en cas d’incident TIC majeur, par nature imprévisible, incluse sans plafond.

Tout audit supplémentaire est facturé au temps passé, et un dépassement durable des volumes ouvre une révision du forfait. Le client dispose ainsi d’un prix prévisible, et le prestataire d’une charge maîtrisée.

La sortie mérite la même attention, car les angles morts s’y cachent souvent. Le délai de restitution des données est fixé à dix jours ouvrés. Nous maintenons la documentation d’exploitation à jour pendant toute la durée du contrat : le jour venu, la réversibilité se résume à un export et à une remise. La période de transition dure six mois, avec un périmètre de passation précisé : transmission de la documentation et atelier de passation.

Enfin, une annexe financière fait partie intégrante des conditions générales et prévaut sur elles en cas de contradiction. Elle évite qu’un article prévoyant une prestation « sans contrepartie » contredise le tarif convenu.

Par où commencer

Si vous êtes une entité financière, commencez par qualifier vos services TIC. Demandez ensuite à chaque prestataire critique les preuves de conformité de ses propres fournisseurs.

Si vous êtes prestataire, préparez ce dossier avant qu’on vous le réclame :

• le paquet DORA de votre hébergeur ;
• la description de vos mesures de sécurité (chez nous : accès des équipes par SSO et VPN, secrets dans un coffre-fort dédié, scan automatisé des vulnérabilités) ;
• un plan de reprise documenté et testé.

Comptez plusieurs mois entre la première demande et la signature. Gardez aussi en tête que le premier procès-verbal de test de bascule prouvera votre conformité mieux que le contrat signé.

Ces engagements s’intègrent à nos contrats de maintenance applicative. Les clauses essentielles d’un contrat TMA détaillent le socle à négocier hors DORA, de la réversibilité aux SLA. Notre dispositif de correctifs de sécurité par agents IA complète le volet sécurité.

Votre site entre dans le périmètre DORA, ou votre prestataire doit se mettre en conformité ? Parlons-en.