Comment expliquer la conformité DORA de votre IA au conseil d'administration
Pour expliquer la conformité DORA de votre IA au conseil d'administration, recentrez le sujet sur ce que le conseil comprend : les risques pour l'activité, la continuité des opérations, et la dépendance à des tiers critiques. DORA ne demande pas de perfection technique — il demande que vous puissiez prouver que vous maîtrisez les risques liés à votre IA, que vous savez ce qui se passe si elle tombe en panne, et que vous n'êtes pas entièrement dépendant d'un seul fournisseur extérieur pour des fonctions critiques.
Il est 14h30. La séance du conseil d'administration vient d'aborder la politique de gestion des risques technologiques. Un administrateur — ancien directeur général d'un établissement financier concurrent — lève la main et pose la question que votre RSSI redoutait depuis janvier 2025 : « Notre système d'IA est-il conforme DORA ? »
Vous avez trois options. Vous pouvez noyer la salle dans les détails techniques. Vous pouvez répondre « oui » sans pouvoir le démontrer. Ou vous pouvez donner la réponse qui mérite d'être donnée : courte, honnête, et orientée risques.
Cet article vous prépare à ce moment. Il couvre ce que DORA exige vraiment, comment traduire ces exigences en langage de salle de conseil, et quelle documentation vous devez avoir en main avant d'entrer dans la pièce.
1. La scène : pourquoi le conseil pose cette question maintenant
Depuis le 17 janvier 2025, le Digital Operational Resilience Act (DORA) est en application dans l'ensemble de l'Union européenne. Il concerne les banques, les assureurs, les sociétés de gestion, les prestataires de services de paiement — et leurs fournisseurs ICT critiques.
Les administrateurs le savent. La Banque de France, l'ACPR, l'AMF ont publié des communications de supervision. Les cabinets d'audit ont intégré DORA dans leurs revues annuelles. Des journalistes spécialisés ont couvert le sujet. Le conseil n'est plus à l'étape « qu'est-ce que DORA ? » — il est à l'étape « est-ce que nous sommes en règle, et quelqu'un peut-il me le montrer ? »
La question sur l'IA spécifiquement vient du fait que les systèmes d'IA sont désormais des composants ICT à part entière. Ils traitent des données, ils s'appuient sur des prestataires tiers (souvent des fournisseurs cloud américains), et ils interviennent de plus en plus dans des processus opérationnels critiques : analyse des risques, traitement des demandes, aide à la décision. Pour un conseil d'administration, l'IA n'est plus une expérimentation — c'est une infrastructure.
2. La vraie question : ce que l'administrateur veut savoir
Quand un administrateur demande « Notre IA est-elle conforme DORA ? », la traduction réelle est la suivante :
- Si ce système IA tombe en panne, que se passe-t-il pour nos opérations ?
- Sommes-nous trop dépendants d'un seul fournisseur pour quelque chose d'important ?
- Si un régulateur nous audite, est-ce qu'on peut lui montrer qu'on maîtrise ce risque ?
- Avons-nous négocié les bons contrats avec nos prestataires IA ?
Ce n'est pas une question de cryptographie ou de pipelines de données. C'est une question de gouvernance du risque opérationnel. Et c'est une question à laquelle vous devez pouvoir répondre avec des faits, pas avec des projections.
Le conseil porte une responsabilité fiduciaire. Il est tenu d'approuver la politique de gestion des risques ICT exigée par DORA. S'il ne comprend pas les enjeux liés à l'IA, il ne peut pas s'acquitter de cette responsabilité. Votre rôle — en tant que RSSI ou DSI — n'est pas de protéger le conseil des détails techniques. C'est de lui donner les informations dont il a besoin pour exercer sa fonction de gouvernance.
3. La mauvaise réponse : quand le jargon ferme la conversation
Voici la réponse qu'il ne faut pas donner — et qui se donne pourtant souvent :
« Nous avons mis en place un pipeline RAG avec inférence on-premise, une architecture air-gap pour isoler les données, et nos embeddings sont hébergés dans notre VPC. Les contrats avec nos fournisseurs incluent des clauses DORA-compatibles sur les SLA et les droits d'audit. Notre RTO est de 4 heures et notre RPO de 24 heures. »
Dans cette réponse, tout est techniquement vrai. Et pourtant, elle perd la salle en trente secondes.
Un administrateur ne sait pas ce qu'est un « pipeline RAG ». Il ne sait pas ce qu'un « VPC » implique pour la conformité réglementaire. Ce qu'il entend, c'est : « Nous avons fait des choses techniques, faites-nous confiance. » Ce n'est pas de la gouvernance — c'est de la délégation sans visibilité. Et c'est précisément ce que DORA cherche à corriger.
La mauvaise réponse a aussi un effet collatéral : elle signale que l'équipe technique n'a pas traduit son travail en langage de risque. Ce qui amène souvent un administrateur aguerri à poser des questions plus pointues, jusqu'à ce qu'il trouve la limite — réelle ou perçue — de votre maîtrise du sujet.
4. La bonne réponse : trois risques, trois mesures, un engagement
La bonne réponse à « Notre IA est-elle conforme DORA ? » tient en trois points, chacun articulé autour d'un risque concret et de la mesure prise pour le gérer.
Premier point : le risque de concentration
DORA s'inquiète particulièrement du risque de concentration — la situation où une part significative de vos fonctions critiques dépend d'un seul prestataire ICT. Si ce prestataire subit une interruption ou un incident de sécurité, vous êtes exposé.
La réponse adaptée au conseil : « Notre système d'IA critique fonctionne sur notre propre infrastructure, sans dépendance à un fournisseur cloud unique pour les opérations en temps réel. Cela signifie que si un fournisseur externe a un problème, notre IA continue de fonctionner. Nous avons documenté cette configuration dans notre registre des risques ICT. »
Si votre IA dépend encore d'une API cloud externe pour des fonctions critiques, ne le cachez pas. Dites plutôt : « Nous utilisons actuellement un prestataire cloud pour cette fonction. Nous avons identifié ce point comme un risque de concentration prioritaire dans notre feuille de route DORA, et le plan de remédiation est en cours. »
Pour aller plus loin sur l'architecture qui répond à cette exigence, l'article DORA 2025 : pourquoi votre IA doit rester dans votre infrastructure détaille les implications concrètes pour les établissements financiers.
Deuxième point : la résilience opérationnelle
DORA exige que vous puissiez démontrer que vos systèmes ICT critiques — dont l'IA — peuvent résister à des interruptions et se rétablir dans des délais définis.
La réponse adaptée : « Notre système d'IA a fait l'objet d'un plan de continuité spécifique. En cas d'interruption, nous avons des procédures manuelles de substitution documentées pour les processus qu'il supporte. Nous avons testé ces procédures lors de notre dernier exercice de continuité. Les résultats sont disponibles dans le rapport de la direction des risques. »
Ce que le conseil veut entendre, ce n'est pas que l'IA ne tombe jamais en panne. C'est que vous savez quoi faire quand elle tombe en panne.
Troisième point : la traçabilité et l'auditabilité
DORA exige que les entités financières puissent auditer leurs prestataires ICT. Pour l'IA, cela s'étend aux sorties du système : pouvez-vous expliquer, a posteriori, sur quelle base l'IA a produit une recommandation ou une analyse ?
La réponse adaptée : « Notre IA produit des réponses avec des citations vers les documents sources. Chaque sortie est traçable. Si un auditeur demande pourquoi le système a produit un résultat particulier, nous pouvons lui montrer exactement les documents qui ont fondé cette réponse. Cette traçabilité satisfait aux exigences d'explicabilité que les superviseurs commencent à formaliser. »
Si votre IA actuelle ne produit pas de citations, c'est un écart à documenter — et à corriger. Pour comprendre pourquoi la traçabilité des sources est la fondation de la conformité IA, voir aussi la comparaison IA cloud vs IA on-premise pour les secteurs régulés.
5. L'intersection avec NIS2 : deux règlements, une seule architecture
Un point que les conseils soulèvent de plus en plus : la relation entre DORA et NIS2. La directive NIS2 (Network and Information Security) s'applique aux entités essentielles et importantes dans des secteurs critiques — dont la finance. Elle impose des exigences de cybersécurité, de gestion des risques tiers, et de notification d'incidents.
Pour les systèmes d'IA, DORA et NIS2 convergent vers les mêmes exigences architecturales :
- NIS2 et l'intelligence artificielle : NIS2 exige une gestion du risque dans la chaîne d'approvisionnement. Un système d'IA qui appelle des API externes lors de chaque inférence crée une dépendance de chaîne d'approvisionnement que NIS2 vous demande d'évaluer et de maîtriser.
- DORA et NIS2 partagent la même logique de preuve : les deux règlements exigent de la documentation, des tests, et des pistes d'audit. Une architecture IA qui satisfait DORA (traçabilité, résilience, absence de concentration) satisfait généralement aussi les exigences NIS2 correspondantes.
Pour le conseil, le message clé est simple : une seule architecture bien conçue répond aux deux règlements. Ce n'est pas deux projets de conformité distincts — c'est le même projet.
6. Le suivi : ce que vous devez avoir préparé avant d'entrer en salle de conseil
Une bonne réponse orale ne suffit pas. Le conseil attendra de la documentation. Voici ce que vous devez avoir en main — ou en préparation documentée.
Documentation indispensable
| Document | Contenu attendu | Fréquence de mise à jour |
|---|---|---|
| Registre des risques ICT | Liste des systèmes IA critiques, niveau de dépendance externe, classification du risque | Trimestrielle |
| Cartographie des prestataires ICT tiers | Pour chaque prestataire IA : type de données transmises, niveau de criticité, droits d'audit contractuels | Annuelle (ou à chaque nouveau contrat) |
| Plan de continuité IA | Procédures de substitution en cas d'interruption, RTO/RPO documentés, résultats des derniers tests | Annuelle + après chaque test |
| Rapport de tests de résilience | Scénarios testés, résultats, écarts identifiés, mesures correctives | Semestrielle |
| Clauses contractuelles DORA | Vérification que les contrats avec les prestataires ICT IA incluent les clauses minimales requises par DORA (article 30) | À la signature, puis annuelle |
Métriques à suivre et à présenter
Le conseil ne gère pas les systèmes — il surveille les risques. Les métriques que vous lui présentez doivent être orientées risques, pas techniques.
- Taux de disponibilité des systèmes IA critiques sur les 12 derniers mois, comparé au RTO contractuel.
- Nombre de prestataires ICT IA classifiés critiques, et pourcentage dont les contrats incluent les clauses DORA obligatoires.
- Score de concentration : quelle part de vos fonctions IA critiques dépend d'un prestataire unique ? Une dépendance supérieure à 50% sur un prestataire unique est un signal d'alerte que DORA vous demande de documenter.
- État d'avancement du plan de remédiation DORA : pourcentage d'actions complétées, délai prévu pour les actions en retard.
- Résultat du dernier test de continuité IA : les procédures manuelles de substitution ont-elles été activées avec succès ? Dans quel délai ?
7. Ce qu'il ne faut pas promettre
Un dernier point, souvent négligé : évitez les engagements impossibles à tenir devant un conseil d'administration.
« Notre IA est 100% conforme DORA » est une affirmation que personne ne peut soutenir aujourd'hui. DORA est un règlement vivant. Les standards techniques (RTS) publiés par les autorités européennes de surveillance continuent d'évoluer. Les pratiques de supervision se construisent. Ce que vous pouvez affirmer, c'est : « Nous avons une démarche de mise en conformité documentée, nous connaissons nos écarts, et nous avons un plan pour les résorber. »
La conformité DORA n'est pas un état binaire — c'est un programme continu. Un conseil qui comprend cela est un conseil qui peut exercer sa gouvernance correctement.
Questions fréquemment posées
DORA s'applique-t-il à tous les systèmes d'IA de notre organisation, ou seulement à certains ?
DORA s'applique aux systèmes ICT qui supportent des fonctions critiques ou importantes de votre activité réglementée. Un système d'IA utilisé pour l'analyse des risques de crédit, la surveillance de la conformité, ou le traitement des opérations est probablement dans le champ. Un outil d'IA pour rédiger des communications internes l'est moins. La première étape est d'identifier et de classifier vos systèmes IA au regard de la criticité des fonctions qu'ils supportent.
Que risque-t-on concrètement si notre IA n'est pas conforme DORA ?
Les superviseurs — ACPR en France, BCE pour les établissements importants — peuvent exiger des plans de remédiation, imposer des restrictions sur les activités concernées, ou prononcer des sanctions financières pour les manquements persistants. Au-delà des sanctions formelles, un incident IA qui révèle des lacunes dans la gestion des risques ICT dans un contexte de supervision DORA expose la direction et le conseil à des questions de gouvernance sérieuses.
Nos contrats avec les fournisseurs IA actuels respectent-ils les exigences DORA ?
Probablement pas tous. L'article 30 de DORA définit les clauses minimales que doivent contenir les contrats avec les prestataires ICT critiques : description des services, niveaux de service, droits d'audit, obligation de notification d'incidents, plan de sortie. Beaucoup de contrats SaaS cloud standard ne les incluent pas. Un audit contractuel est la première étape — et souvent la source de surprises.
La conformité DORA pour l'IA, c'est le même sujet que NIS2 pour l'intelligence artificielle ?
Ils se recoupent mais ne se substituent pas l'un à l'autre. DORA est sectoriel (finance) et très spécifique sur la résilience ICT et la gestion des tiers. NIS2 est transversal (tous les secteurs critiques) et couvre la cybersécurité au sens large, incluant les risques propres à l'IA comme l'empoisonnement de modèle et l'injection de prompts. Les organisations financières sont soumises aux deux. Une bonne architecture IA souveraine satisfait aux deux — c'est l'un des avantages du déploiement on-premise.
Combien de temps faut-il pour préparer une présentation DORA sur l'IA au conseil ?
Si la documentation de base existe (registre ICT, cartographie des prestataires, plan de continuité), une présentation de niveau conseil se prépare en une à deux semaines. Si ces documents n'existent pas encore, la préparation de la présentation est aussi l'occasion de les construire — ce qui prend plutôt quatre à six semaines pour un premier exercice sérieux.
Préparer une présentation DORA convaincante pour votre conseil est une question d'architecture autant que de communication. Si votre IA est déployée de façon souveraine — avec traçabilité des sorties, absence de dépendance critique à un prestataire unique, et plan de continuité documenté — la conversation avec le conseil est une démonstration, pas une justification.
Pour voir comment Scabera aborde le déploiement d'IA souveraine et traçable pour les établissements soumis à DORA, demandez une démonstration.