Par Tanguy Duthion
·
30 mai 2026
Sous DORA, je dois classer un incident ICT sans attendre, sur la base de faits, puis vérifier s’il passe au niveau majeur. En pratique, je regarde 6 critères : clients et transactions touchés, durée, portée dans l’UE, impact sur les données, effet sur une fonction critique ou importante, et coût.
Si je veux éviter une décision floue, je fais simple :
Autrement dit : pas d’avis à l’instinct. Je pars de mesures, comme 2 h 15 min d’indisponibilité, 2 pays de l’UE touchés ou une perte estimée à 80 000 €. Puis je note, critère par critère, si je suis au-dessus, en dessous ou incertain.
Voici le point à retenir en un coup d’œil :
| Point à trancher | Ce que je vérifie |
|---|---|
| Impact client | Nombre de clients et volume de transactions touchés |
| Temps d’arrêt | Durée entre détection et retour complet |
| Portée UE | Nombre d’États membres concernés |
| Données | Disponibilité, intégrité, confidentialité, preuve d’origine |
| Service touché | Lien avec une fonction critique ou importante |
| Coût | Pertes directes, indirectes et clauses SLA |
| Dépendances | SaaS, prestataires ICT, outils hors inventaire |
Le plus simple est de traiter la classification comme une décision réglementaire, avec un dossier horodaté, des preuves, des hypothèses et les zones encore incertaines.
Mesurez chaque critère et conservez la preuve qui va avec. Ces éléments servent à trancher le classement de l’incident. Il ne s’agit pas d’un simple point technique.
Commencez par chiffrer le nombre de clients touchés, ainsi que le volume ou la valeur des transactions perturbées. Pour étayer cela, appuyez-vous sur les journaux de transactions, le CRM et les tickets support.
La durée se calcule entre la détection de l’incident et le retour complet du service. Comparez ensuite cette période à vos seuils internes d’indisponibilité. Pour la portée géographique, repérez dans combien d’États membres de l’UE le service a été interrompu. Les rapports de statut par région et les journaux de trafic réseau permettent de le vérifier.
Évaluez quatre dimensions liées aux données : disponibilité, intégrité, confidentialité et authenticité. Si des données personnelles sont en cause, consignez aussi tout risque d’atteinte à des données personnelles.
Ensuite, vérifiez si l’incident concerne une fonction critique ou importante et mesurez son effet direct sur l’activité métier. Le plus simple consiste à croiser le registre des actifs avec l’analyse d’impact métier, ou BIA, pour confirmer l’atteinte au regard des règles applicables.
Pour l’impact économique, séparez bien les coûts directs, indirects et contractuels. Ce point paraît simple sur le papier, mais en pratique, c’est souvent là que les dossiers deviennent flous.
| Type de coût | Exemples concrets | Source de preuve |
|---|---|---|
| Coûts directs | Pertes de revenus, coûts de remédiation | Factures, journaux d'heures de travail |
| Pénalités contractuelles | Clauses SLA déclenchées | Contrats, clauses de pénalité SLA |
| Coûts indirects | Perte de productivité, retard de facturation, impact commercial | Reporting financier, indicateurs métier |
Ces mesures servent ensuite à comparer l’incident à vos seuils DORA internes.
Dès qu’un incident est repéré, récupérez tout de suite les infos qui servent au classement. Le plus simple : un seul formulaire structuré par critère DORA.
Les champs à prévoir sont les suivants : horodatage au format JJ/MM/AAAA HH:MM (heure de Paris, estimée ou confirmée), identifiant, déclarant, systèmes touchés, FCI touchée oui/non, SaaS et tiers impliqués, clients et transactions affectés, pays concernés, impact sur les données - disponibilité, intégrité, confidentialité, authenticité - ainsi qu’une fourchette financière initiale en euros, par exemple « < 10 000 € », « 10 000–100 000 € » ou « > 100 000 € ».
Chaque champ sert directement à nourrir un critère de matérialité DORA.
Ces données servent ensuite à comparer la situation aux seuils internes.
Une fois le formulaire rempli, comparez chaque métrique à votre matrice de seuils interne alignée sur les RTS DORA. Les seuils internes de référence sont : plus de 10 % des transactions journalières ou plus de 100 000 clients touchés, une indisponibilité de plus de 2 heures sur des services supportant une FCI, un impact géographique couvrant au moins deux États membres de l’UE, et des pertes directes et indirectes susceptibles de dépasser 100 000 €. [1][7]
| Critère DORA | Métrique observée | Seuil interne | Statut |
|---|---|---|---|
| Clients affectés | 8 200 clients | ≥ 10 % de la base ou ≥ 100 000 | Incertain |
| Durée d'indisponibilité | 2 h 15 min | > 2 h sur services supportant une FCI | Au-dessus |
| Portée géographique | France, Allemagne | ≥ 2 États membres de l'UE | Au-dessus |
| Impact économique | ~80 000 € (fourchette initiale) | > 100 000 € | Incertain |
| Services critiques touchés | Non confirmé | FCI touchée | Incertain |
Pour chaque critère, donnez un statut simple et net :
Notez aussi qui a fait l’évaluation et à quelle heure.
À partir de là, la décision de classement cesse d’être floue. Elle devient concrète, presque mécanique.
La décision revient au responsable d’incident, avec le SOC, le métier et la conformité selon votre gouvernance. [2][4][5][6] L’incident est majeur si les seuils majeurs sont atteints, ou si plusieurs critères pointent dans le même sens. Sinon, il reste mineur ou significatif selon vos seuils internes. [8][3][7]
Si une nouvelle preuve change le franchissement d’un seuil, reclassez sans attendre. Consignez à chaque fois l’heure et le nom du décideur.
L’analyse doit ensuite tenir compte des dépendances SaaS dans l’impact global.
Une fois les critères DORA chiffrés, regardez si un SaaS ou un prestataire a aggravé l'impact réel. La classification ne doit pas s'arrêter au service visible en façade. Elle doit aussi tenir compte des dépendances qui le font tourner : SaaS, IAM, outils de collaboration, paiement, support et supervision externalisés. Si l'un de ces maillons tombe, les workflows, le reporting ou les opérations côté client peuvent se dégrader, même si l'incident semble limité au départ. [10]
Le Shadow IT ajoute un autre angle mort. Une application absente du catalogue peut malgré tout soutenir un processus métier bien concret. Son absence dans l'inventaire ne change rien à l'impact sur le terrain. Dit autrement, l'évaluation doit partir de ce qui s'est passé en pratique, pas du simple statut d'enregistrement. [9][11][12]
Pour chaque service SaaS en cause, appuyez-vous sur quatre questions simples :
Ajoutez aussi un point de contexte : le service est-il interne, externalisé ou intégré dans une chaîne tierce ? Et quel est son rôle exact : service critique, de support ou non critique ?
Quand la cartographie des dépendances est propre, la décision va souvent plus vite. Avanoo aide à repérer les usages non inventoriés, à cartographier les dépendances SaaS et à relier les flux de données touchés à l'incident, y compris quand certains outils n'apparaissent pas dans l'inventaire officiel.
La décision de classification doit être écrite, structurée et défendable en audit. En clair, il faut laisser une trace nette, pas une suite de notes éparses. Le dossier doit inclure un résumé de l'incident, une chronologie horodatée, les fonctions touchées, l'évaluation critère par critère, les sources de preuve, les hypothèses posées, les zones d'incertitude qui restent, puis la décision finale avec son raisonnement. Indiquez aussi qui a décidé, qui a validé, et à quelle heure. [13]
Vous pouvez formaliser tout cela dans un tableau de preuve.
Tableau 1 - métriques observées et preuves
| Critère DORA | Valeur observée | Seuil interne | Source de preuve | Évaluation |
|---|---|---|---|---|
| Durée d'indisponibilité | à renseigner | Seuil interne pour un service critique | Logs système | - |
| Clients affectés | à renseigner | Seuil interne de clients affectés | Logs SSO / IdP | - |
| Portée géographique | à renseigner | Impact sur plusieurs États membres de l'UE | Logs serveurs régionaux | - |
| Impact sur les données | à renseigner | Intégrité ou confidentialité affectée | Alertes DLP | - |
| Criticité du service SaaS | à renseigner | Fonction critique ou importante | Registre des actifs / BIA | - |
| Impact économique | à renseigner | Seuil interne en euros | Estimation financière initiale | - |
Tableau 2 - niveau interne et escalade
| Niveau de sévérité interne | Escalade requise |
|---|---|
| Faible | Équipe technique |
| Moyen | Responsable IT / RSSI |
| Élevé / Majeur | Cellule de crise + Direction |
Classer un incident ICT sous DORA demande une décision appuyée sur des faits mesurables. Chaque critère doit être examiné séparément, avec une preuve à l'appui.
La même logique vaut pour les dépendances SaaS et les prestataires tiers. Si un service SaaS ou tiers supporte un processus métier ou un service critique, il doit entrer dans l'analyse d'impact. En clair, si vous ne voyez pas bien ces dépendances, votre classement risque de partir de travers.
En pratique, la méthode repose sur quatre gestes simples.
Ce cadre aide à produire une décision homogène, traçable et défendable. Il met aussi l'IT, la sécurité, la conformité, la finance et les achats sur la même ligne.
::: faq
Sous DORA, un incident ICT est classé majeur s’il dépasse au moins deux critères. On parle ici, par exemple, du nombre de clients touchés, de la durée de l’indisponibilité, de la portée géographique, des pertes de données, de la criticité des services ou de l’impact économique.
Il peut aussi être classé majeur dans deux autres cas bien précis. D’abord, s’il y a un accès malveillant non autorisé à des systèmes critiques. Ensuite, si des incidents mineurs récurrents liés à une même cause se produisent au moins deux fois sur une période de six mois. :::
::: faq
Avec des informations incomplètes, classez l’incident DORA avec prudence, mais sans attendre. Dès la détection, désignez une équipe en charge pour lancer l’analyse tout de suite. Le point à surveiller est simple : le délai de notification initiale de 4 heures démarre au moment où l’incident est qualifié de majeur.
Pour avancer dans de bonnes conditions, appuyez-vous sur :
Si certains critères ne sont pas encore stabilisés, documentez chaque action menée et mettez à jour la classification dès que vous disposez de données plus précises. :::
::: faq
Inclure les SaaS et le Shadow IT est indispensable pour la conformité à DORA. Pourquoi ? Parce que ce sont souvent eux qui créent les plus gros angles morts dans le système d’information.
Sans vue d’ensemble, il devient difficile de tenir à jour le registre des fournisseurs TIC. Et, dans la foulée, d’évaluer les risques liés à la chaîne d’approvisionnement.
Le problème est simple : un outil non répertorié peut ouvrir la porte à des failles de sécurité, à des traitements de données mal encadrés, et à une gestion d’incident bien plus compliquée. Au moment de notifier un incident, chaque zone floue devient un frein.
Détecter ces outils, puis les documenter, permet de cartographier chaque service critique avec plus de précision. On ne travaille plus à l’aveugle. On s’appuie sur des données concrètes pour soutenir la résilience numérique. :::
Co-fondateur & CEO
Tanguy Duthion est co-fondateur et CEO d'Avanoo. Ancien de Google et d'Asana, il a fondé Avanoo pour aider les organisations à reprendre la main sur leurs usages SaaS et IA.
Découvrez comment Avanoo peut cartographier votre paysage SaaS et IA, réduire les risques et optimiser les coûts. Une plateforme fiable avec un accompagnement humain dédié.
