DORA : quand l’incident informatique devient un sujet “clients” (banque, assurance, gestion)

Pendant longtemps, l’incident IT dans les services financiers a été traité comme un problème “de coulisses” analyse l’expert en communication de crise Florian Silnicki, Président Fondateur de l’agence LaFrenchCom. Un incident de production, un bug applicatif, une indisponibilité de l’app mobile, une lenteur sur une plateforme de trading : on mobilisait l’IT, on activait un plan de continuité, on absorbait le pic d’appels, puis on revenait à la normale avec un commentaire parcimonieux, souvent calibré pour “ne pas inquiéter”.

DORA a changé la nature du contrat. Depuis le 17 janvier 2025, la résilience opérationnelle numérique n’est plus seulement un enjeu de robustesse interne : c’est un régime européen qui encadre la gestion des risques ICT, la classification et le reporting des incidents, la relation aux prestataires technologiques, et, surtout, l’information aux clients lorsque leurs intérêts financiers sont touchés.

Pour un COMEX, la conséquence est simple à formuler et complexe à exécuter : l’incident informatique n’est plus un “incident IT”. C’est un incident client potentiellement opposable, parce qu’il crée des obligations de notification, de preuve et de communication utile. Il ne s’agit plus de sauver une image ; il s’agit de protéger des intérêts financiers, d’assurer une continuité de service et de documenter une gouvernance.

La clause qui change tout : informer les clients “sans délai indu”

Le cœur du basculement tient dans une phrase du règlement. DORA prévoit que lorsqu’un incident majeur lié aux TIC survient et qu’il a un impact sur les intérêts financiers des clients, l’entité financière doit, sans délai indu dès qu’elle en a connaissance, informer ses clients de l’incident majeur et des mesures prises pour en atténuer les effets.

Ce n’est pas une option, ce n’est pas un principe général, et ce n’est pas un “bon réflexe” de communication : c’est une obligation structurante. Elle fait entrer la relation client au cœur de la gestion d’incident, au même titre que la cybersécurité et la conformité.

Cette obligation a deux implications pratiques souvent sous-estimées.

La première, c’est que DORA ne vise pas uniquement les fuites de données. Le texte parle d’intérêts financiers. Un incident peut donc déclencher une information client même s’il n’y a pas de compromission de données personnelles, dès lors qu’il perturbe la capacité du client à agir financièrement ou qu’il expose le client à un préjudice financier. En d’autres termes, une indisponibilité de canaux transactionnels, une dégradation de l’intégrité d’une information de prix, une incapacité à exécuter un ordre, un retard de paiement, un blocage de rachat sur un fonds, une rupture de service sur des parcours d’assurance ou de gestion, peuvent faire basculer l’incident dans la sphère “clients” au sens DORA, parce que la finance est une industrie où le temps, l’accès et l’exactitude sont déjà des composantes du risque.

La seconde implication, c’est que DORA vous demande d’informer les clients et de parler des mesures de mitigation. Ce point est déterminant : le message DORA n’est pas seulement déclaratif (“nous avons un incident”), il est protecteur (“voici ce que nous faisons pour limiter les effets”).

En pratique, cela force une entreprise à être capable, très vite, de répondre à deux questions que les clients posent toujours, même quand ils ne les formulent pas ainsi : “Qu’est-ce que je risque ?” et “Qu’est-ce que je dois faire maintenant ?”.

Le nouvel enjeu : qualifier l’incident au bon niveau, au bon moment

DORA ne se contente pas de dire “informez vos clients”. Il structure aussi un régime de classification et de reporting des incidents ICT majeurs, qui conditionne l’activation des obligations et la cadence de production d’information.

Les autorités européennes de supervision (EBA, EIOPA, ESMA) ont publié des projets finaux de standards techniques pour préciser, d’une part, les critères de classification des incidents majeurs et, d’autre part, le contenu, le format, les modèles et les délais de reporting des incidents majeurs et des cybermenaces significatives.

Ce travail de normalisation a un effet “COMEX” très concret : l’entreprise doit se doter d’une capacité de triage qui ne soit pas seulement technique, mais business, parce que la matérialité de l’incident se lit dans l’impact sur les services, sur les clients, et sur la stabilité opérationnelle. Cela vaut pour une banque de détail comme pour un assureur ou une société de gestion : la même panne peut être “supportable” un jour calme et devenir “majeure” un jour d’échéance, de stress de marché, ou de liquidation.

Reporting DORA : la vérité progressive devient une discipline industrielle

Les standards techniques sous DORA décrivent une logique de reporting en plusieurs temps. Le rapport final des ESAs sur le reporting rappelle explicitement que l’information sur un incident ICT majeur est fournie en trois étapes, avec une notification initiale, un rapport intermédiaire et un rapport final, soumis aux autorités compétentes selon des délais spécifiques.

Cette structure est cruciale pour la communication de crise, parce qu’elle impose une règle que beaucoup d’organisations appliquent mal : la “vérité progressive” ne doit pas être une improvisation, elle doit être une production maîtrisée.

Le même rapport des ESAs souligne aussi l’articulation avec NIS2 et rappelle deux principes qui intéressent directement une direction générale. D’abord, DORA est traité comme une législation sectorielle “lex specialis” par rapport à NIS2, et les exigences doivent être au moins équivalentes “en effet”, sans être identiques. Ensuite, le document mentionne que le calendrier proposé retient notamment une logique où le délai de 24 heures après prise de connaissance pour une notification initiale est aligné sur NIS2, tout en prévoyant, pour certains acteurs plus systémiques, des exigences plus strictes liées à la classification.

Cela a une conséquence directe sur la relation client : si votre reporting aux autorités s’organise en paliers, votre communication client doit pouvoir s’aligner sur ce rythme sans se contredire. Le client ne lit pas vos rapports, mais il perçoit vos variations de discours. Or, sous DORA, la cohérence est un actif réglementaire autant qu’un actif réputationnel.

DORA ne remplace pas le reste : l’incident “clients” se superpose à d’autres obligations

Un malentendu fréquent consiste à croire que DORA “couvre” la totalité du sujet. En réalité, DORA ajoute une couche, et cette couche se combine avec d’autres régimes, notamment ceux liés aux données personnelles. Une note d’acteurs de marché, citée par ESMA, rappelle que l’obligation d’informer les clients sous DORA lorsqu’un incident majeur affecte leurs intérêts financiers coexiste avec l’obligation d’information des personnes concernées en cas de violation de données personnelles susceptible d’engendrer un risque élevé, au titre du RGPD.

Le client, lui, ne distinguera jamais DORA, RGPD, règles de paiement, et obligations contractuelles. Il retiendra une seule chose : votre capacité à le protéger et à le guider. C’est pourquoi la communication “clients” en incident IT ne peut plus être traitée comme un appendice de la communication corporate. Elle doit être pensée comme une composante du service.

Ce que DORA impose vraiment à la communication client : utilité, preuve, et tempo

Dans le monde d’avant, un message de crise cherchait souvent à éviter le détail. Dans le monde DORA, le détail pertinent devient indispensable, parce que vous devez parler de mesures de mitigation.

La bonne doctrine n’est pas “transparence totale”. La bonne doctrine est “transparence utile”. Elle consiste à dire, dès que vous êtes en mesure de le faire, ce qui est affecté, ce qui ne l’est pas (si vous pouvez l’affirmer), ce qui est en cours de vérification, et surtout comment le client doit se comporter pendant l’incident. La forme compte autant que le fond : le message doit être exploitable sur les canaux réels des clients, c’est-à-dire l’application, le site, le centre d’appel, les emails transactionnels, les conseillers, et, pour les institutionnels, les canaux de relation commerciale.

L’autre pivot est le tempo. DORA parle de “sans délai indu dès que vous en avez connaissance”. La notion n’est pas définie comme un chronomètre public, mais elle impose un état d’esprit : vous ne pouvez plus attendre la fin des investigations techniques pour déclencher l’information client si l’impact financier est présent. Cela oblige à préparer des messages “stables mais incomplets”, qui disent clairement ce que vous savez, ce que vous ne savez pas encore, et quand vous reviendrez avec une mise à jour.

Enfin, DORA impose la preuve. Si l’information client devient une obligation, l’entreprise doit pouvoir démontrer qu’elle a informé au bon moment et qu’elle a communiqué des mesures de mitigation, donc qu’elle a produit un contenu, l’a diffusé, et qu’elle peut en tracer l’historique.

Le point aveugle des organisations : le centre d’appels est désormais un organe de conformité

Dans les banques, les assureurs et la gestion, la vérité opérationnelle d’une crise se joue rarement dans un communiqué de presse. Elle se joue dans le call center, dans les scripts de conseillers, dans les réponses au chat, dans les messages in‑app, et dans la capacité à absorber une demande massive sans inventer de réponses.

DORA fait du front client un organe de conformité, parce que l’obligation d’informer “les clients” ne se limite pas à “publier une note sur le site”. Elle implique une diffusion effective vers les clients concernés, et une capacité à expliquer les mesures de mitigation de manière compréhensible, sans sur‑promettre.

C’est la raison pour laquelle la communication client en incident IT doit être conçue avec la même rigueur que les process de paiement ou de gestion du risque : un langage pré‑validé, des déclencheurs clairs, une gouvernance de validation rapide, et une discipline de mise à jour.

Le facteur tiers : quand l’incident vient du cloud, DORA supprime l’excuse

L’un des apports majeurs de DORA est d’assumer le rôle systémique de certains prestataires technologiques et de créer un cadre de supervision au niveau de l’Union pour des prestataires ICT “critiques”. L’EBA rappelle que DORA met en place un cadre d’oversight EU‑wide pour les prestataires ICT critiques et que les ESAs sont responsables de leur désignation et de la conduite de l’oversight en tant que “Lead Overseers”.

En novembre 2025, les ESAs ont publié la première liste de prestataires ICT tiers désignés comme critiques. Reuters a rapporté cette désignation, en citant notamment des acteurs de cloud et de services technologiques largement utilisés par le secteur financier, dans une logique de réduction du risque systémique lié à des dépendances partagées.

Ce point change profondément la communication en crise. Quand l’incident vient d’un prestataire, l’entreprise avait tendance à se retrancher derrière une formule : “c’est un incident chez notre fournisseur”. DORA n’interdit pas de le dire, mais elle rend cette posture insuffisante, parce qu’elle n’apporte aucune mitigation au client. La question client n’est pas “qui est fautif ?”, c’est “quand puis-je agir ?” et “comment protégez-vous mes intérêts ?”. La communication doit donc s’ancrer dans votre plan de contournement, votre stratégie de redondance, votre capacité à basculer, et vos alternatives de service.

Ce que le COMEX doit décider avant la crise, sinon la crise décidera à sa place

DORA a une vertu : elle oblige les organisations à sortir du flou. La communication client en incident IT ne peut pas dépendre d’un arbitrage improvisé entre le juridique, l’IT et le marketing, parce que l’exigence d’informer sans délai indu dès connaissance, avec des mesures de mitigation, impose une mécanique de décision “prête”.

Le COMEX doit donc trancher en amont la doctrine suivante : à quel moment estime‑t‑on qu’un incident a un impact sur les intérêts financiers des clients, qui a autorité pour déclencher l’information, quels canaux sont considérés comme “preuve de diffusion”, et quel niveau de détail est jugé suffisant pour être utile sans fragiliser la remédiation.

Il doit également imposer un principe d’industrialisation : un seul dossier de vérité, alimenté par l’incident management, qui nourrit à la fois le reporting aux autorités et la communication client. DORA structure le reporting, mais la cohérence globale reste votre responsabilité.

Deux exemples de messages “DORA‑compatibles” pour clients, sans sur‑promesse

Voici à quoi ressemble, dans l’esprit DORA, un message client qui assume l’incertitude tout en répondant à l’obligation de mitigation.

“Nous rencontrons actuellement un incident informatique majeur affectant l’accès à certains services. Vous pouvez constater des difficultés pour consulter vos comptes et réaliser certaines opérations. Nos équipes techniques sont mobilisées pour rétablir le service et limiter les impacts. À ce stade, nous vous invitons à reporter toute opération non urgente et à vérifier, après rétablissement, l’historique de vos transactions ; si vous observez une opération non reconnue, contactez immédiatement notre assistance. Nous publierons une mise à jour à [heure] et vous tiendrons informés des mesures mises en œuvre pour atténuer les effets de l’incident.”

Ce message respecte l’esprit de l’obligation : il informe rapidement, il décrit l’impact, et il décrit des mesures de mitigation et des comportements de protection, sans spéculer sur l’origine.

Pour une clientèle institutionnelle, l’attente est différente : on demande plus de précision sur le périmètre, les alternatives et la gouvernance. Le message peut être plus structuré, sans pour autant livrer des détails exploitables.

“Nous faisons face à un incident informatique majeur affectant [périmètre fonctionnel]. L’incident a un impact sur la capacité à [exécuter/valider/consulter] certaines opérations, ce qui peut affecter vos intérêts financiers. Des mesures de mitigation sont en cours, incluant [bascule vers une procédure de secours / activation de canaux alternatifs / restriction préventive de certaines fonctions]. Nous vous communiquerons un point de situation à [heure] et vous indiquerons toute mesure opérationnelle temporaire à adopter. Notre objectif est de rétablir un fonctionnement normal dans les meilleurs délais tout en sécurisant l’intégrité des opérations.”

Là encore, on retrouve la logique DORA : information sans délai indu dès connaissance, articulation avec l’intérêt financier, et mesures de mitigation explicites.

Avec DORA, la résilience devient une promesse client, et la communication devient une fonction de protection

DORA ne demande pas aux banques, assureurs et gérants d’actifs d’être invulnérables. DORA demande qu’ils soient résilients, qu’ils sachent classifier, rapporter et maîtriser les incidents ICT, et qu’ils traitent les clients comme ce qu’ils sont dans une crise numérique : des parties prenantes exposées à un risque financier qui mérite une information rapide et utile.

En 2026, le différenciateur n’est plus seulement la sécurité. C’est la capacité à transformer un incident en séquence de protection client : informer sans délai indu, expliquer ce qui est affecté, dire ce qui est fait, indiquer les gestes de mitigation, tenir un tempo de mises à jour, et démontrer, preuves à l’appui, que l’organisation a piloté. C’est cela, désormais, le standard “haut de gamme” en crise opérationnelle numérique.