Depuis le 17 janvier 2025, le règlement européen DORA (Digital Operational Resilience Act) s’applique pleinement aux entités financières, y compris aux compagnies d’assurance, mutuelles et institutions de prévoyance. Cette réglementation, adoptée le 14 décembre 2022, transforme en profondeur la manière dont les assureurs doivent gérer leurs services numériques, qu’il s’agisse de sites web institutionnels, de parcours de souscription en ligne ou d’espaces clients. Pour les responsables marketing et digital, comprendre ces nouvelles exigences n’est plus une option mais une nécessité stratégique.
Au-delà de la simple conformité réglementaire, DORA représente une opportunité de professionnaliser la gestion des actifs digitaux et de renforcer la confiance des assurés. Cet article vous guide à travers les implications concrètes de cette réglementation sur vos outils numériques et vous propose une méthodologie pragmatique pour y répondre.
Le règlement DORA établit un cadre harmonisé pour la résilience opérationnelle numérique du secteur financier européen. Son objectif principal est de garantir que les entités financières puissent résister, répondre et se remettre de tout type de perturbation ou de menace liée aux technologies de l’information et de la communication (TIC). Concrètement, cela signifie que chaque service numérique utilisé par une compagnie d’assurance doit faire l’objet d’une analyse de risque, d’un encadrement contractuel spécifique et de mesures de continuité adaptées.
La définition des « Services TIC » selon DORA est particulièrement large : elle englobe tous les services numériques et de données fournis de manière permanente par l’intermédiaire de systèmes informatiques, incluant le matériel en tant que service et les services d’assistance technique. Sont exclus uniquement les services de téléphonie analogique traditionnels. Cette définition implique que votre site web de marque, votre plateforme de devis en ligne, votre espace client sécurisé et même votre extranet partenaires entrent dans le champ d’application de la réglementation.
L’enjeu pour les équipes marketing et digital est de collaborer étroitement avec les directions des systèmes d’information et les fonctions conformité pour cartographier l’ensemble des services TIC, évaluer leur criticité et mettre en place les mesures appropriées. Cette transversalité est au cœur de la philosophie DORA.
La distinction entre services TIC critiques et non critiques constitue la pierre angulaire de l’approche DORA. Cette classification détermine le niveau d’exigences contractuelles et opérationnelles applicables à chaque prestation. Une fonction est considérée comme « critique » lorsque sa perturbation est susceptible de nuire sérieusement à la performance financière, à la solidité ou à la continuité des services de l’entité financière.
Pour déterminer cette criticité, les compagnies d’assurance doivent réaliser une analyse d’impact d’activité (Business Impact Analysis ou BIA). Cette analyse évalue les conséquences d’une interruption de chaque fonction et détermine les priorités de reprise ainsi que les ressources nécessaires pour assurer la continuité. Prenons un exemple concret : un site web institutionnel présentant uniquement l’offre de l’assureur sera généralement classé comme non critique, tandis qu’un parcours de souscription connecté au système d’information métier et permettant la signature électronique de contrats pourra être considéré comme soutenant une fonction critique.
Cette distinction n’est pas anodine. Pour les services TIC soutenant des fonctions critiques, DORA impose des exigences renforcées : description quantitative et qualitative exhaustive des niveaux de service, délais de préavis stricts pour toute modification, plans d’urgence formalisés, tests d’intrusion réguliers, et procédures de réversibilité documentées. Les services non critiques font l’objet d’exigences proportionnées mais restent soumis à un socle commun d’obligations.
Un site de marque hébergé sous CMS WordPress avec des connexions API vers des systèmes métier pour afficher des informations tarifaires sera typiquement classé comme service TIC non critique. La perturbation de ce site, bien que dommageable pour l’image de l’entreprise, n’impacte pas directement la capacité de l’assureur à honorer ses engagements envers les assurés. En revanche, un espace client permettant la déclaration de sinistres, la consultation de garanties et le téléchargement d’attestations soutient des fonctions directement liées à l’exécution des contrats d’assurance et mérite une analyse approfondie de sa criticité.
Les parcours de devis-souscription en ligne représentent un cas intermédiaire. Si ces parcours se limitent à générer des devis indicatifs sans engagement, ils peuvent être considérés comme non critiques. Dès lors qu’ils permettent une souscription effective avec collecte de données personnelles, paiement et génération contractuelle, leur criticité augmente significativement. La responsabilité du prestataire digital s’arrête généralement à la bonne transmission des requêtes API vers les systèmes métier du client, mais cette interface doit être sécurisée et documentée.
Les espaces clients constituent un cas particulièrement sensible qui mérite une attention spécifique. Pour une mutuelle santé, l’espace adhérent permet généralement de consulter les remboursements, télécharger des décomptes, accéder à la carte de tiers payant dématérialisée et effectuer des demandes de prise en charge. L’indisponibilité prolongée de ces fonctionnalités peut empêcher un assuré de justifier sa couverture auprès d’un professionnel de santé ou de suivre le traitement de ses remboursements. Dans ce contexte, l’espace client soutient une fonction critique car sa perturbation nuit directement à la continuité du service rendu aux assurés. Le même raisonnement s’applique aux espaces clients des institutions de prévoyance lorsqu’ils permettent la déclaration d’arrêts de travail ou le suivi des indemnités journalières, fonctions essentielles pour les bénéficiaires en situation de vulnérabilité.
Le site de secours, parfois appelé site « dégradé » ou « page de maintenance enrichie », représente un autre cas intermédiaire intéressant.
Ce dispositif consiste à préparer un site public simplifié, hébergé sur une infrastructure distincte, qui peut être activé rapidement en cas d’indisponibilité prolongée du site vitrine principal. Ce site de repli affiche généralement les informations essentielles : coordonnées de contact, numéros d’urgence, messages d’information sur la situation. Sa classification dépend du rôle qu’il joue dans la stratégie de continuité : s’il constitue le seul canal de communication digitale de l’assureur en situation de crise, il peut être considéré comme soutenant une fonction critique de communication avec les assurés. En revanche, s’il s’agit d’un simple palliatif temporaire dans l’attente du rétablissement du site principal, il relèvera plutôt de la catégorie des services non critiques. L’essentiel est de formaliser ce positionnement dans l’analyse BIA et d’adapter les exigences contractuelles en conséquence.
La continuité de service constitue un pilier fondamental de DORA. Pour chaque service TIC, qu’il soit critique ou non, des dispositifs de continuité et de reprise d’activité doivent être formalisés. Le Plan de Continuité d’Activité (PCA) définit les mesures préventives et les procédures permettant de maintenir les services essentiels en cas de perturbation. Le Plan de Reprise d’Activité (PRA) détaille les actions à entreprendre pour restaurer les services après un incident majeur.
Dans le contexte d’un hébergement web, une architecture robuste repose sur plusieurs principes : la séparation des environnements (production, développement, préproduction), la redondance géographique des infrastructures au sein du territoire national, et une stratégie de sauvegarde externalisée. L’objectif est de garantir qu’un incident physique (incendie, panne électrique) ou logique (cyberattaque, corruption de données) n’impacte pas simultanément l’ensemble des ressources.
Une architecture conforme aux exigences DORA peut s’articuler autour de deux environnements distincts hébergés sur des datacenters géographiquement séparés. Le serveur de production héberge le site accessible au public avec son application et sa base de données. Le serveur de développement/préproduction sert au quotidien pour les tests et validations, mais joue également le rôle de serveur de secours (failover) en cas de défaillance de la production. Le code source est versionné sur un dépôt Git sécurisé et sauvegardé, permettant de déployer une version identique de l’application en quelques minutes.
Les sauvegardes doivent être totalement isolées de l’infrastructure de production. Une bonne pratique consiste à utiliser un hébergeur différent pour les backups, avec une fréquence quotidienne et une rétention d’au moins vingt jours glissants. Le périmètre de sauvegarde inclut la base de données et les fichiers médias (uploads). Cette architecture permet de définir des indicateurs de performance clairs : un RPO (Recovery Point Objective) de 24 heures correspondant à la sauvegarde de la veille, et un RTO (Recovery Time Objective) cible de 4 heures en heures ouvrées, avec une garantie maximale de 8 heures.
Différents types d’incidents appellent des réponses graduées. Un crash de service web rendant le site inaccessible nécessite un redémarrage des services sur le serveur de production, généralement résolu en moins de 4 heures. Un piratage ou une intrusion compromettant le site implique soit un nettoyage approfondi avec audit de sécurité, soit une bascule sur le serveur de préproduction, avec un délai de résolution de l’ordre de 8 heures. La perte totale du serveur de production suite à un incident matériel grave déclenche l’activation complète du PRA : récupération de la dernière sauvegarde, restauration sur le serveur de secours et bascule DNS, le tout en moins de 24 heures.
Pour les sites connectés à des API métier (tarificateurs, systèmes de gestion), une panne de ces interfaces externes ne relève pas de la responsabilité du prestataire d’hébergement. Le site reste en ligne et une solution de repli peut être activée, par exemple un formulaire de contact simplifié avec affichage d’un message informatif invitant l’utilisateur à renouveler sa demande ultérieurement.
DORA transforme en profondeur la relation entre les entités financières et leurs prestataires de services TIC. Chaque contrat d’infogérance doit désormais inclure une annexe spécifique détaillant les mesures de conformité à la réglementation. Cette annexe constitue un document structurant qui engage le prestataire sur des obligations précises en matière de gouvernance des risques numériques. Les principes généraux de gouvernance imposent au prestataire de collaborer activement avec l’entité financière pour respecter les obligations réglementaires, gérer les risques de manière proportionnée à la criticité des services, documenter exhaustivement les prestations et communiquer régulièrement avec les autorités compétentes.
En cas de non-conformité persistante après épuisement des mesures correctives, l’entité financière dispose d’un droit de résiliation du contrat.
Pour les mutuelles santé et les organismes traitant des données de santé, le choix d’un hébergement certifié HDS (Hébergeur de Données de Santé) présente un double avantage. D’une part, cette certification répond aux exigences spécifiques du Code de la santé publique pour l’hébergement des données de santé à caractère personnel. D’autre part, elle s’inscrit naturellement dans le cadre des exigences DORA en matière de résilience opérationnelle.
La certification HDS impose en effet des standards élevés en termes de sécurité physique des datacenters, de redondance des infrastructures, de gestion des accès, de traçabilité des opérations et de plans de continuité d’activité. Un hébergeur HDS est par définition plus résilient qu’un hébergeur standard : il doit démontrer sa capacité à maintenir la disponibilité, l’intégrité et la confidentialité des données hébergées, y compris en situation de crise. Ces garanties correspondent précisément aux objectifs de DORA.
Pour un espace adhérent de mutuelle ou un portail de gestion des arrêts de travail, opter pour un hébergement HDS permet donc de répondre simultanément aux contraintes sectorielles (données de santé) et réglementaires (DORA). Le surcoût éventuel de cette certification se justifie par la simplification de la conformité et par le niveau de garantie offert. Il convient toutefois de vérifier que l’ensemble de la chaîne d’hébergement est couverte par la certification, y compris les éventuels sous-traitants.
Quelle que soit la criticité du service, plusieurs obligations s’imposent. La description des services TIC doit être claire et exhaustive, et toute modification ultérieure nécessite une information écrite ou une autorisation de l’entité financière. Les informations de localisation des serveurs d’hébergement et des données doivent être précisées contractuellement, avec une préférence pour un hébergement sur le territoire national. Les niveaux de service (SLA) doivent être formellement définis avec des engagements de performance et de disponibilité mesurables.
Le dispositif de réponse aux incidents représente un volet essentiel. Le prestataire doit garantir la mise à disposition de personnel qualifié pour l’analyse et la résolution rapide des dysfonctionnements, fournir les ressources matérielles et logicielles nécessaires, assurer une communication proactive sur l’état d’avancement et coopérer avec les autorités compétentes. L’entité financière, de son côté, doit informer immédiatement le prestataire des incidents pour faciliter leur classification et notification conformément aux exigences DORA.
La coopération avec les organismes de supervision, notamment l’ACPR (Autorité de Contrôle Prudentiel et de Résolution), fait l’objet d’engagements spécifiques. Le prestataire accepte de fournir toute l’assistance nécessaire, incluant la mise à disposition de documents, de personnel qualifié et la facilitation d’audits. Cette obligation survit cinq ans après l’expiration du contrat. Un programme de sensibilisation à la cybersécurité doit également être mis en place pour les collaborateurs du prestataire, avec une formation initiale et annuelle obligatoire.
L’un des apports majeurs de DORA concerne la portabilité des données. Le prestataire doit mettre en place une procédure de test de réversibilité permettant de vérifier que les données hébergées sont accessibles, récupérables et réutilisables. Un test complet doit être réalisé au minimum un an avant la fin ou le renouvellement du contrat, ou sur demande en cas de changement majeur dans l’infrastructure. La restitution des données doit s’effectuer dans un format standard exploitable sans compétences techniques complexes. L’entité financière dispose de trente jours pour valider les données récupérées, et le prestataire s’engage à remédier à toute anomalie dans un délai équivalent.
La mise en conformité DORA de vos actifs digitaux s’articule autour de plusieurs étapes structurantes. La première consiste à réaliser un inventaire exhaustif de vos services TIC : sites web, applications mobiles, espaces clients, extranets, outils de devis en ligne, plateformes de signature électronique. Pour chaque service, identifiez le prestataire concerné, la nature des données traitées et les interconnexions avec vos systèmes métier.
La deuxième étape porte sur l’analyse de criticité. En collaboration avec vos équipes métier et votre fonction conformité, évaluez pour chaque service les conséquences d’une indisponibilité prolongée. Les critères à considérer incluent l’impact sur la continuité de service aux assurés, les implications réglementaires, les risques réputationnels et les conséquences financières. Cette analyse aboutit à une classification en services critiques et non critiques.
La troisième étape concerne la revue contractuelle. Vérifiez que vos contrats d’hébergement et de maintenance intègrent une annexe DORA conforme. Cette annexe doit couvrir les définitions réglementaires, les principes de gouvernance, les obligations communes (description des services, localisation, niveaux de service, gestion des incidents, coopération avec les autorités, formation, réversibilité) et, le cas échéant, les obligations spécifiques aux services critiques.
Enfin, formalisez vos dispositifs de continuité. Chaque service doit disposer d’un PCA/PRA documenté, avec des indicateurs de performance (RPO/RTO) adaptés à sa criticité. Prévoyez des tests réguliers de ces dispositifs et des procédures d’escalade clairement définies.
La désignation de points de contact pour la gestion des incidents, tant côté prestataire que côté entité financière, est indispensable pour une réaction rapide et coordonnée.
Le règlement DORA impose aux compagnies d’assurance une rigueur nouvelle dans la gestion de leurs services numériques. Pour les responsables marketing et digital, cette évolution réglementaire constitue une opportunité de structurer leurs pratiques, de renforcer la qualité de leurs prestations et de sécuriser leurs relations avec les prestataires. La distinction entre services critiques et non critiques permet d’adapter le niveau d’exigence à la réalité des risques, dans une logique de proportionnalité.
En travaillant dès maintenant à la mise en conformité de vos contrats et de vos dispositifs de continuité, vous anticipez les attentes des régulateurs et vous offrez à vos assurés la garantie d’une disponibilité maîtrisée de vos services digitaux. Dans un secteur où la confiance est essentielle, cette démarche proactive renforce votre positionnement et votre crédibilité sur le marché.
Eficiens accompagne depuis plus de 15 ans les acteurs de l’assurance dans leur transformation digitale. Notre expertise conjugue maîtrise technique et connaissance approfondie des enjeux réglementaires du secteur. Contactez-nous pour auditer vos dispositifs actuels et vous accompagner dans votre mise en conformité DORA.
Tous les détails sur notre page contact ou en visio ci-dessous
