Par Tanguy Duthion
·
23 mai 2026
Si je devais résumer l’article en une idée : pour DORA, former les équipes SaaS ne suffit pas ; il faut aussi prouver qui a été formé, sur quoi, quand et après quels incidents.
Je retiens 5 points simples :
Un fait ressort nettement : 63 % des incidents de sécurité cités dans l’article viennent d’erreurs de configuration SaaS. Donc, si je forme sans travailler les accès, les droits, les intégrations et les usages hors circuit, je passe à côté du risque.
Voici le point de départ le plus simple :
| Sujet | Ce que je dois faire |
|---|---|
| Portée | Cartographier les apps SaaS, y compris le Shadow IT |
| Publics | Séparer les contenus selon les rôles |
| Fréquence | À l’intégration, chaque année, puis après incident |
| Mesure | Suivre complétion, scores, simulations, effets sur les contrôles |
| Preuves | Archiver registres, résultats, versions, revues et exceptions |
En clair, cet article montre comment passer du texte DORA à un programme de sensibilisation court, ciblé et traçable.
DORA ne demande pas seulement des règles sur le papier. Le texte impose des comportements, des choix et des preuves. Sur le terrain, la bonne question n’est donc pas « que dit le règlement ? », mais plutôt : qui forme qui, sur quel sujet, et avec quelle trace ? L’idée est simple : convertir ces obligations en modules de formation liés à chaque rôle.
Le premier niveau de formation vise les décideurs. C’est logique : si la gouvernance vacille, tout le reste suit.
L’article 5 de DORA place la résilience numérique sous la responsabilité directe de l’organe de direction. En clair, les dirigeants doivent valider le cadre de gestion des risques ICT. Ils doivent aussi assumer la supervision et la validation de ce cadre de risque ICT.
À ce niveau, la formation porte sur la cartographie du Shadow IT, l’identification des fonctions critiques et les dépendances vis-à-vis des prestataires SaaS. Et là, il ne suffit pas d’avoir “sensibilisé” les équipes. Il faut garder des éléments concrets : attestations, politiques approuvées et comptes rendus de direction.
La sensibilisation doit rester très concrète. Le but n’est pas de dérouler un support générique une fois par an. Il faut apprendre à reconnaître un phishing, repérer du Shadow IT, savoir quand escalader un incident, puis réutiliser chaque incident dans la session suivante. Autrement dit, la formation doit vivre avec le terrain.
Elle doit aussi traduire les exigences de l’article 13(6) en consignes claires pour les utilisateurs et les prestataires.
Dans un cadre SaaS, le périmètre tiers est souvent sous-évalué. C’est un angle mort classique. Pourtant, DORA impose d’intégrer les prestataires SaaS critiques dans la démarche de sensibilisation, en particulier sur les clauses contractuelles DORA et les exigences de coopération en cas d’incident.
Pour passer de l’obligation au programme, le plus simple consiste à relier chaque pilier DORA à un objectif de formation et à une preuve conservée :
| Pilier DORA | Objectif de formation | Preuve / Artefact attendu |
|---|---|---|
| Gestion des risques ICT | Ateliers de cartographie des actifs et scénarios de décision | Registre des actifs mis à jour |
| Reporting d'incidents et tests de résilience | Triage et classification des incidents ; simulations par scénarios | Journaux d'incidents, rapports de tests et plans de remédiation |
| Risque tiers | Clauses DORA et coopération tiers | Avenants DORA aux contrats |
| Partage d'information | Utilisation du protocole TLP pour le renseignement sur les menaces | Participation aux réseaux de partage (ISAC) |
Cette base sert ensuite à ajuster le contenu selon chaque public.
DORA impose une formation par rôle, avec des éléments documentés et traçables. Une fois les obligations DORA posées, il faut les convertir en contenus séparés selon le public visé. L’idée est simple : chaque groupe doit recevoir la formation qui correspond à ses tâches, et l’organisation doit pouvoir le prouver. Si le programme est examiné, il doit montrer que chacun a bien reçu ce qu’il lui fallait pour assumer ses obligations de contrôle.
Les dirigeants doivent pouvoir justifier les risques SaaS acceptés, les choix budgétaires et les décisions de remédiation. On n’est pas dans le flou. Les preuves attendues sont très concrètes : ordres du jour de sessions dédiées, politiques signées, comptes rendus de comité.
Pour les équipes IT, sécurité et conformité, il faut aller plus loin sur le plan technique. Elles doivent maîtriser la qualification, la classification et la notification des incidents dans les délais DORA - 4 h puis 72 h - mais aussi la journalisation, la conservation des journaux et la surveillance des prestataires tiers. La théorie ne suffit pas. Il faut des cas proches du terrain : un compte administrateur partagé qui contourne le MFA, des logs gardés seulement 7 jours, ou une panne fournisseur qui touche un service métier critique.
Les utilisateurs métiers ont besoin de consignes claires, simples et actionnables. Quels outils sont autorisés ? Comment manipuler des données sensibles ? Comment repérer un phishing ? Et à quel moment faut-il escalader ? Par exemple, dès qu’un outil traite des données réglementées, n’a pas de contrôles d’identité clairs, ou a été acheté hors circuit.
Les responsables d'applications doivent, eux, bien comprendre leur rôle de gardien. Ils doivent maintenir un inventaire à jour des SaaS utilisés, qualifier la criticité métier, valider les flux de données et déclarer toute nouvelle intégration. En pratique, ce sont souvent eux qui voient arriver une dépendance avant tout le monde.
Les équipes achats doivent être formées sur les points de contrôle contractuels DORA : obligations de sécurité, notification d'incident, sous-traitance, localisation des données, droits d'audit et continuité de service. Cette formation doit être intégrée au processus, pas traitée à part. Autrement dit : quoi vérifier avant d’acheter, de connecter, de partager ou d’approuver.
Le tableau ci-dessous résume le niveau de formation, les risques et les preuves attendues par public.
| Public | Risques principaux | Profondeur requise | Format de délivrance | Preuves à conserver |
|---|---|---|---|---|
| Dirigeants (board, C-level) | Responsabilité personnelle, sanctions réglementaires, interruption de service | Stratégique : appétit au risque, gouvernance, approbation des priorités | Briefings courts, simulations de gouvernance | Ordres du jour, politiques signées, comptes rendus de comité |
| IT, sécurité, conformité | Défaillance de détection, mauvaise gestion des preuves, délais de reporting manqués | Technique : triage d'incidents, journalisation, surveillance des tiers, gestion des preuves | Ateliers, exercices sur table, revues guidées d'incidents | Rapports d'incidents, résultats de tests, configurations de logs |
| Utilisateurs métiers | Shadow IT, fuite de données, phishing, mauvaise gestion des accès | Opérationnel : outils autorisés, manipulation des données, chemins d'escalade | Microlearning, simulations de phishing, nudges en contexte | Taux de complétion, résultats d'évaluations |
| Responsables d'applications | Dépendances non cartographiées, non-respect des RTO/RPO, intégrations non déclarées | Fonctionnel : inventaire SaaS, criticité métier, flux de données | Ateliers individuels, revues d'inventaire | Registre des actifs mis à jour, classification de criticité |
| Achats | Lacunes contractuelles, risque de concentration, absence de droits d'audit | Juridique/commercial : clauses contractuelles clés, plans de sortie, sous-traitance | Formation processus, revue de contrats | Contrats conformes DORA, évaluations de risque fournisseur |
Il reste ensuite à caler le calendrier, les indicateurs de suivi et les preuves à archiver.
Une fois les contenus définis par public, il faut fixer quand ils sont diffusés et comment vous en gardez la preuve.
À l'intégration, tout collaborateur dont le rôle touche à un outil SaaS doit suivre sa formation avant d'accéder aux systèmes de production. En pratique, cela veut dire une complétion pendant le premier mois, avec un module adapté au rôle - utilisateur métier, responsable d'application ou équipe IT - et une trace horodatée dans le système de gestion des apprentissages. Ici, on parle d'un prérequis, pas d'une simple case à cocher.
Les remises à niveau sont annuelles pour tous, avec un rythme plus soutenu pour l'IT, la sécurité, la conformité, la gouvernance SaaS et les achats.
Après un incident ou un échec de contrôle, DORA impose d'intégrer les leçons tirées dans les programmes de sensibilisation.[1][2][3][4] Concrètement, prévoyez une session ciblée pour les équipes concernées dans un délai de 4 à 6 semaines après la revue post-incident. Puis, mettez à jour les modules et imposez une nouvelle complétion aux rôles visés.[1][2][3]
Les dirigeants doivent, eux aussi, être formés. Un briefing annuel sur les obligations DORA, les risques SaaS et les incidents marquants doit être calé sur les cycles de gouvernance, comme l'approbation du cadre de gestion des risques ICT ou la revue de l'appétit au risque. Les ordres du jour, les supports et les listes de présence servent alors de preuves attendues.
Suivez trois familles de métriques : couverture, performance et amélioration des contrôles.
La couverture répond à une question simple : qui a bien suivi la formation, et dans les temps ? Il faut donc mesurer le taux de complétion par rôle, par département et par statut - salarié ou prestataire - ainsi que le délai moyen de complétion à l'intégration et le taux de complétion dans les délais définis.
La performance va un cran plus loin. Elle regarde les scores moyens aux évaluations par public, le taux d'échec initial et les actions de remédiation associées. Elle inclut aussi les résultats des simulations de phishing : taux de clic, taux de signalement et évolution d'une année sur l'autre. Dit autrement, il ne suffit pas que les gens aient vu le module. Il faut vérifier ce qu'ils ont retenu et comment ils réagissent.
L'amélioration des contrôles relie la formation au terrain. Suivez le nombre d'actions issues des revues post-incident intégrées aux modules mis à jour, la baisse des incidents SaaS récurrents liés à des erreurs humaines, et les décisions de gouvernance influencées par les résultats de formation. Ces métriques doivent montrer une baisse nette du Shadow IT, des erreurs humaines et des incidents liés aux tiers. Sinon, vous n'avez qu'un tableau de bord de plus.
Les indicateurs ne servent à rien s'ils ne sont pas archivés correctement.
En audit, conservez six artefacts.[6][7][8][9]
Un dépôt centralisé exportable fait gagner un temps fou en cas de contrôle. Quand l'auditeur demande une preuve, mieux vaut pouvoir la sortir en quelques minutes que partir à la chasse aux fichiers.
Avanoo peut croiser ces métriques avec l'inventaire SaaS pour relier formation, incidents et criticité applicative.
Pour relier la formation aux exigences DORA, utilisez la table ci-dessous.
| Obligation DORA | Résultat attendu de la formation | Artefact de preuve (audit) |
|---|---|---|
| Art. 5 – Gouvernance et responsabilité managériale | Les dirigeants comprennent leurs obligations non délégables et approuvent le cadre ICT | Comptes rendus de comité signés, politique ICT approuvée, registre de présence aux briefings |
| Art. 6 – Cadre de gestion des risques ICT | Les collaborateurs identifient et signalent le Shadow IT et les risques de concentration SaaS | Logs de découverte automatisée, rapports d'évaluation des risques par outil SaaS, attestations de complétion |
| Art. 13 – Sensibilisation et apprentissage continu | Les modules intègrent les leçons des incidents | Historique des versions des contenus, rapports post-incident, preuves de recomplétion |
| Art. 17-20 – Notification des incidents | Les équipes classifient les incidents majeurs et respectent les délais 4 h / 72 h[1][5] | Rapports de simulation, registre des incidents horodaté, comptes rendus de revues post-incident |
| Art. 24-27 – Tests de résilience opérationnelle | Les équipes techniques exécutent les plans de reprise (RTO/RPO) | Résultats des exercices annuels, plans de remédiation avec échéances, rapports TLPT |
| Art. 28-30 – Risque lié aux tiers | Les achats et l'IT identifient les prestataires SaaS critiques et vérifient les clauses contractuelles | Registre des informations (RoI) mis à jour, avenants contractuels conformes DORA, évaluations de risque fournisseur |
Une fois les rôles, les contenus et les preuves posés, il reste un dernier point à relier : la formation et la gouvernance SaaS. La sensibilisation DORA ne sert à rien si elle ne part pas de votre portefeuille SaaS réel.
Chaque application SaaS doit figurer dans un inventaire clair, avec :
C'est ce lien - inventaire → propriétaire → formation ciblée → preuve - qui transforme l'inventaire en point central de la gouvernance. Sans cette base, on forme un peu à l'aveugle. Et c'est là que le Shadow IT devient un vrai problème. Sa détection doit donc faire partie du programme de sensibilisation, pas rester à côté.
Cette visibilité sur le terrain aide ensuite à suivre les complétions de formation et à repérer les écarts. Avanoo permet de croiser la découverte des applications, l'attribution des propriétaires, la classification des risques et le suivi des complétions par application et par équipe.
Le minimum viable tient en cinq actions simples.
Un programme minimal, bien mené, peut suffire. Des modules ciblés, des remises à niveau annuelles, des mises à jour après incident et une traçabilité solide permettent déjà de montrer une conformité crédible. Le but n'est pas d'être parfait dès le premier jour. Le but, c'est d'avancer de façon suivie, documentée, et reliée directement aux risques SaaS de votre organisation.
::: faq
Sans visibilité, répondre aux exigences DORA sur la cartographie et la gestion des risques devient vite compliqué. Le bon point de départ, c’est une analyse des lacunes. Elle permet de voir ce qui manque, ce qui échappe aux équipes, et où se situent les zones à risque.
Ensuite, passez à une découverte automatisée pour recenser l’ensemble du parc. L’idée est simple : obtenir une vue nette de tout ce qui est utilisé, y compris le Shadow IT et le Shadow AI. Sans ça, une partie du terrain reste hors radar.
Avanoo peut aider à construire cet inventaire en croisant plusieurs sources de données, comme le SSO, les données financières, les proxys et les extensions de navigateur. Ce croisement donne une image bien plus juste des usages réels que ne le ferait une seule source prise isolément.
Une fois les actifs identifiés, il faut les classer selon trois axes :
C’est ce tri qui permet ensuite de savoir où agir d’abord, plutôt que d’avancer à l’aveugle. :::
::: faq
Conservez une documentation claire, rangée et mise à jour pour prouver votre conformité à DORA. Cela comprend un registre des fournisseurs TIC classés par criticité, les évaluations des risques pour les prestataires SaaS et IA, les politiques de sécurité, les rapports d’incidents et les preuves de tests.
Archivez aussi les contrats qui contiennent les clauses obligatoires. Gardez également une trace nette des actions de gouvernance, des changements effectués, des résultats obtenus, des recommandations formulées et des plans de remédiation.
En bref, votre dossier doit permettre de montrer, sans flou, qui fait quoi, quels risques ont été évalués, ce qui a été décidé et ce qui a été corrigé. :::
::: faq
Après un incident majeur, revoyez le cadre de gestion des risques TIC pour y intégrer les leçons tirées et tenir compte des nouvelles menaces.
Mettez aussi à jour la formation avec des simulations basées sur les incidents vécus. Appuyez-vous sur les données d’usage de votre plateforme de gouvernance pour adapter la sensibilisation au terrain et renforcer les bons réflexes, afin d’éviter qu’un incident du même type ne se reproduise. :::
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é.
