Support technique
Documentation
Connexion
Nous contacter
Accédez directement au résumé généré par l'IA de cet article de blog 
Principaux enseignements
- Le registre d'informations de DORA répertorie les contrats relatifs à des services technologiques fournis de manière continue ; par conséquent, une bibliothèque que vous téléchargez sans contrat n'y figure généralement pas.
- Des normes techniques contraignantes imposent de recenser les bibliothèques open source utilisées par les services assurant des fonctions critiques ou importantes.
- Les logiciels intégrés aux systèmes d'une entité financière sont soumis aux règles de gestion des risques, qu'il existe ou non un contrat avec un fournisseur.
Les exigences de conformité à la loi DORA s'appliquent aux bibliothèques open source, même si celles-ci ne figurent pas dans votre registre des informations. La loi européenne sur la résilience opérationnelle numérique (DORA) les mentionne dans ses normes techniques relatives à la gestion des risques liés aux technologies de l'information et de la communication (TIC), qui sont distinctes des règles applicables aux contrats avec les fournisseurs.
Le registre des informations est la liste que tient une entité financière de ses contrats relatifs à des services TIC en cours. La présence d’une bibliothèque dans ce registre dépend de l’existence d’un contrat sous-jacent, tel qu’un contrat d’assistance payante. Les règles de gestion des risques s’appliquent à la bibliothèque dans tous les cas, dès lors qu’elle fonctionne sur vos systèmes. Elle doit donc figurer dans l’inventaire des logiciels que vous utilisez, même si le registre ne la mentionne pas. L’absence d’une bibliothèque dans cet inventaire constitue une lacune dans le registre exigé par le règlement DORA. Vos supérieurs hiérarchiques peuvent vous ordonner de y remédier, et chaque État membre fixe des sanctions en cas de non-respect du règlement DORA. Les autorités publient les décisions définitives relatives aux sanctions.
À quelles organisations s'appliquent les exigences de conformité DORA ?
La directive DORA s'applique à vingt catégories d'entités financières, parmi lesquelles figurent les établissements de crédit, les établissements de paiement et de monnaie électronique, les entreprises d'investissement, les assureurs, les prestataires de services liés aux crypto-actifs, les contreparties centrales et les plateformes de négociation. Les prestataires de services informatiques tiers, c'est-à-dire les entreprises qui fournissent des services technologiques à ces entités, sont répertoriés séparément et ne relèvent de la surveillance directe de l'UE que s'ils sont désignés comme critiques.
Certaines entités ne relèvent pas du champ d'application de la présente directive, notamment certains petits gestionnaires de fonds d'investissement alternatifs et assureurs, les institutions de retraite comptant jusqu'à 15 affiliés, ainsi que les institutions de virement postal (banques postales gérant des comptes de paiement). Les États membres peuvent également exclure certaines entités que la directive bancaire de l'UE exempte de ses propres règles.
Les entreprises d’investissement de petite taille et non interconnectées, les établissements de paiement et de monnaie électronique bénéficiant d’une dérogation, les petits organismes de retraite (moins de 100 affiliés) et les établissements relevant de la directive bancaire bénéficiant d’une dérogation que les États membres maintiennent dans le champ d’application bénéficient d’un cadre simplifié de gestion des risques liés aux TIC, assorti de règles distinctes définies dans les normes techniques. Si vous êtes concerné, commencez par là. Tous les autres doivent suivre le cadre complet, adapté à leur taille et à leur profil de risque, tout comme le reste de cet article.
Le registre repose sur des contrats
Le texte de référence de la DORA est le règlement (UE) 2022/2554, ci-après dénommé « le règlement ». L’article 3 du règlement définit un prestataire tiers de services TIC comme une entreprise fournissant des services TIC, et les services TIC comme des services numériques et des services de données fournis de manière continue par le biais de systèmes TIC. Le registre, les clauses contractuelles et les règles de sortie s’appliquent tous à un prestataire fournissant ce type de service.
En vertu de l’article 28, paragraphe 3, vous tenez un registre contenant des informations sur l’ensemble des accords contractuels relatifs à ces services, en distinguant ceux qui soutiennent des fonctions critiques ou importantes des autres. Les fonctions critiques ou importantes sont celles dont la perturbation porterait gravement atteinte aux finances de l’entité, à ses services ou à sa capacité à respecter les conditions de son autorisation. Au moins une fois par an, vous déclarez vos nouveaux contrats à votre autorité compétente, en précisant notamment qui les fournit et quels services et fonctions ils couvrent. Vous devez également transmettre l’intégralité du registre sur simple demande. Les modèles standard du registre sont issus du règlement d’exécution (UE) n° 2024/2956 de la Commission.
L’article 30 fixe les conditions contractuelles minimales, et l’article 28, paragraphe 8, impose la mise en place de stratégies de sortie pour les services qui assurent des fonctions critiques ou importantes. Lorsqu’un contrat portant sur un tel service autorise la sous-traitance, l’article 29 vous oblige à évaluer les risques, y compris ceux liés à des chaînes longues ou complexes. Une norme technique de réglementation (NTR), le règlement délégué (UE) n° 2025/532 de la Commission, précise les éléments que vous devez déterminer et évaluer lorsque ces services font l’objet d’une sous-traitance. Les modèles du registre permettent également de recenser chaque sous-traitant qui contribue effectivement à la fourniture d’un tel service.
Remarque : les Autorités européennes de surveillance (AES) publient une FAQ rédigée par leurs services concernant la déclaration au registre, disponible sur le site de l’Autorité bancaire européenne (ABE). Il y est indiqué qu’un achat ponctuel d’une solution statique, ne donnant lieu à aucune maintenance, assistance ou mise à jour régulière, ne constitue pas un service informatique. Il s’agit d’une orientation fournie par les services, et non de la position officielle des AES.
Les prestataires critiques relèvent d’un régime de surveillance distinct géré par les AES : l’ABE, l’Autorité européenne des assurances et des pensions professionnelles et l’Autorité européenne des marchés financiers. Celles-ci ont publié la première liste des prestataires de services tiers TIC désignés comme critiques le 18 novembre 2025 et doivent la mettre à jour chaque année. Cette désignation s’applique aux entreprises qui fournissent des services TIC ; une bibliothèque open source en tant que telle n’est donc pas concernée. Une bibliothèque que vous téléchargez sans contrat n’est pas soumise au registre, aux règles contractuelles ni à la surveillance des prestataires critiques, car aucun prestataire ne vous la fournit sous la forme d’un service continu. Elle reste toutefois soumise aux règles de gestion des risques TIC de la DORA, qui la traitent comme un logiciel utilisé par l’entité.
Où les bibliothèques open source figurent-elles dans le règlement ?
Les exigences de conformité au règlement DORA qui concernent les logiciels libres relèvent des normes de gestion des risques liés aux TIC. Le règlement définit un actif TIC comme un élément logiciel ou matériel faisant partie des réseaux et des systèmes d'information utilisés par l'entité. L'article 6 impose la protection des actifs TIC, y compris les logiciels, et l'article 8 vous oblige à les identifier, à les classer et à les documenter, à cartographier leurs interdépendances et à tenir des inventaires.
Le tableau présente les exigences réglementaires ayant la plus grande incidence directe sur les bibliothèques. Dans ce tableau, « RTS 2024/1774 » désigne le règlement délégué (UE) 2024/1774 de la Commission, relatif aux normes techniques de réglementation (RTS) en matière de gestion des risques liés aux technologies de l'information et de la communication (TIC).
| Sujet | Ce qu'il faut | Source |
|---|---|---|
| Inventaire des équipements informatiques | Identifier, classer et répertorier les actifs logiciels et leurs interdépendances, et tenir à jour les inventaires | Règlement, article 8 |
| Suivi des emprunts à la bibliothèque | Recenser les bibliothèques tierces et open source utilisées par les services assurant des fonctions critiques ou importantes, et surveiller leurs versions et mises à jour, en collaboration avec le fournisseur le cas échéant | RTS 2024/1774, article 10 |
| Essais de pré-production | Analyser et tester le code open source, dans la mesure du possible, avant sa mise en production, et soumettre les progiciels à des tests de sécurité au plus tard lors de la phase d'intégration | RTS 2024/1774, article 16 |
| Code malveillant | Mettez en place des mesures de sécurité contre les codes malveillants et assurez-vous que seuls les logiciels autorisés soient installés | RTS 2024/1774, article 11 |
| Politiques de mise à jour | Conservez des procédures documentées concernant les correctifs et les mises à jour, en précisant les délais à respecter et la procédure d'escalade en cas de non-respect de ces délais. | Règlement, article 9 ; RTS 2024/1774, article 10 |
| Systèmes hérités | Réaliser au moins une fois par an une évaluation spécifique des risques liés aux systèmes informatiques hérités | Règlement, articles 3 et 8 |
Extrait du règlement : l'article 25, paragraphe 1, cite les « analyses open source » comme un exemple de tests appropriés dans le cadre du programme de tests de résilience d'une entité financière, aux côtés des analyses de vulnérabilité, des examens du code source lorsque cela est possible et des tests d'intrusion.
En ce qui concerne les composants prêts à l'emploi utilisés dans des services qui ne prennent pas en charge des fonctions critiques ou importantes, l'article 10 de la norme RTS 2024/1774 vous impose néanmoins de recenser, dans la mesure du possible, les bibliothèques tierces et open source qu'ils utilisent.
Le règlement définit un système TIC « hérité » comme un système qui est toujours en service et qui soutient les fonctions de l’entité, mais qui a atteint sa fin de vie, ne se prête pas à des mises à niveau ou à des corrections pour des raisons technologiques ou commerciales, ou n’est plus pris en charge par son fournisseur ou un prestataire de services TIC tiers. Cette définition couvre l’ensemble des systèmes TIC. Chaque entité doit déterminer et consigner si une bibliothèque non prise en charge fait du système qui l’exécute un système « hérité ». Les micro-entreprises, c'est-à-dire les petites entités financières comptant moins de 10 salariés et dont le chiffre d'affaires ou le total du bilan ne dépasse pas 2 millions d'euros, sont exemptées de l'examen annuel des systèmes hérités.
Le fait qu'une bibliothèque figure ou non dans le registre dépend de la manière dont elle vous est présentée
Toute bibliothèque exécutée sur vos systèmes est considérée comme un logiciel utilisé par l'entité ; elle est donc soumise aux règles de gestion des risques. L'application des règles relatives aux tiers et à l'enregistrement dépend quant à elle du fait que cette bibliothèque vous soit fournie ou non par le biais d'un service informatique.
C'est à l'entité concernée qu'il revient de déterminer ce qui relève d'un service TIC. La question-réponse n° 2999, une réponse de la Commission européenne publiée par l'intermédiaire des AES, qualifie cette définition de « délibérément large » et laisse le soin à l'entité financière d'en apprécier la portée. Pour une bibliothèque, cela signifie que c'est à vous de décider si un accord d'assistance ou de distribution relève d'un service TIC et doit donc figurer dans le registre.
| Comment la bibliothèque s'installe | actif informatique | Dans le registre des informations | Base |
|---|---|---|---|
| Téléchargement du registre public, sans assistance technique | Oui, en tant que logiciel, l'entité utilise | En général, non, puisqu'il n'existe aucun contrat portant sur un service continu | Règlement, articles 3 et 28 ; FAQ à l'intention du personnel (conseils) |
| Accord de distribution commerciale ou d'assistance | Oui | Oui, si l'entité le considère comme un service TIC continu | Règlement, articles 3 et 28 ; Questions-réponses n° 2999 (orientations) |
| Intégré au produit ou au service hébergé d'un fournisseur | Oui, s'il fonctionne au sein du réseau et des systèmes d'information utilisés par l'entité financière | L'organisation du fournisseur, ainsi que les sous-traitants qui assurent concrètement les services nécessaires au bon fonctionnement des fonctions critiques ou importantes | Règlement, articles 28 et 29 ; règlement d'exécution n° 2024/2956, article 3 |
Lorsqu'une bibliothèque est intégrée au produit ou au service hébergé d'un fournisseur, ce dernier, qui la distribue, répond généralement à la définition d'une entreprise fournissant des services TIC, ce qui n'est que rarement le cas du responsable de la maintenance de cette bibliothèque. Les dispositions contractuelles s'appliquent alors au fournisseur, mais une bibliothèque qui s'exécute sur les systèmes que vous utilisez reste soumise à vos règles de gestion des risques.
Une petite liste de contrôle pour les bibliothèques faisant partie de vos fonctions essentielles
Chaque élément de cette liste de contrôle de conformité DORA fait référence au texte de référence qui s'y rapporte et part du principe que vous relevez de l'ensemble du cadre réglementaire.
- Inventaire. Votre inventaire recense les logiciels qui prennent en charge des fonctions critiques ou importantes, ainsi que leurs interconnexions (règlement, article 8).
- Suivi. Vous assurez le suivi des bibliothèques tierces et open source utilisées par les services prenant en charge ces fonctions, et vous surveillez leurs versions et mises à jour, en collaboration avec le fournisseur le cas échéant (RTS 2024/1774, article 10).
- Tests. Le code open source est analysé et testé avant la mise en production lorsque cela est possible, et les progiciels font l'objet de tests de sécurité au plus tard lors de la phase d'intégration (RTS 2024/1774, article 16).
- Code malveillant. Vos procédures de sécurité prévoient des mesures de protection contre les codes malveillants et n'autorisent l'installation que de logiciels autorisés sur vos systèmes (RTS 2024/1774, article 11).
- Corrections. Une politique documentée en matière de correctifs et de mises à jour définit des délais et des procédures d'escalade (Règlement, article 9 ; RTS 2024/1774, article 10). Lorsque la seule solution consiste à installer une version plus récente, la mise à niveau peut elle-même entraîner des changements incompatibles, comme nous l'expliquons dans l'article intitulé « Pourquoi “il suffit de mettre à jour” est un mauvais conseil en matière de sécurité ».
- Systèmes existants. Les systèmes informatiques existants font l'objet d'une évaluation spécifique des risques au moins une fois par an, sauf si vous êtes une micro-entreprise (règlement, article 8).
- Registre. Votre registre répertorie tous les accords contractuels relatifs aux services TIC, y compris les contrats de logiciels considérés comme des services continus, et vous pouvez justifier l'absence d'une bibliothèque donnée dans ce registre (Règlement, article 28).
- Rôles. L'organe de direction définit clairement les rôles associés aux fonctions liées aux TIC ainsi que les modalités de leur coordination (règlement, article 5). À moins que vous ne soyez une micro-entreprise, une fonction de contrôle gère et supervise les risques liés aux TIC, y compris les risques liés au parc informatique (règlement, article 6). La réglementation ne précise pas quelle équipe est chargée du suivi du parc informatique ; à vous donc de décider si cette tâche incombe à votre équipe chargée des risques liés aux TIC ou à celle chargée des risques liés aux tiers.
Commencez par une fonction essentielle
Votre registre n'affichera pas les bibliothèques que vous avez téléchargées sans contrat ; vous devrez donc les rechercher dans vos propres systèmes. Choisissez une fonctionnalité critique ou importante et dressez la liste des bibliothèques qui lui sont associées, y compris celles qui sont intégrées indirectement. Signalez toute bibliothèque dont le responsable en amont n’est plus actif ou pour laquelle il n’existe pas de correctif en amont pour votre version. Choisissez ensuite une stratégie pour chacune d’entre elles : la remplacer, passer à une version corrigée si elle existe, ou appliquer un correctif à la version que vous utilisez. Une seule fonctionnalité suffit pour établir une liste concrète de résultats et évaluer l’état du reste de votre logiciel.
Si vous optez pour la solution des correctifs, SecureChain est une option à envisager. Cet outil analyse le code source de chaque paquet open source à la recherche de logiciels malveillants connus et de modèles de code suspects avant que le paquet ne vous parvienne, puis le recompile à partir de cette même source. Il corrige les CVE récemment publiées dans ces paquets dans le cadre du SLA. Chaque paquet est accompagné d’une SBOM pour votre inventaire et de données VEX indiquant quelles vulnérabilités (CVE) affectent votre version. Sa provenance certifiée SLSA de niveau 3 atteste qu’il a été recompilé à partir de la source analysée. Lorsque les responsables de maintenance en amont cessent de fournir des correctifs de sécurité, le service Endless Lifecycle Support (ELS) prend automatiquement le relais pour ces paquets. SecureChain et ELS sont disponibles pour les écosystèmes JavaScript, Python, Java, Go et PHP.
FAQ
Qu'est-ce que la conformité à la loi DORA ?
La conformité à la loi DORA signifie qu’une entité financière se conforme à la loi européenne sur la résilience opérationnelle numérique (DORA), au règlement (UE) 2022/2554 et à ses normes techniques. L’objectif est d’assurer la continuité des services en cas de perturbations technologiques. Ces règles sont en vigueur depuis le 17 janvier 2025.
Quelles sont les exigences de conformité à la loi DORA ?
La loi DORA (Digital Operational Resilience Act) de l’Union européenne couvre cinq domaines. Il s’agit de la gestion des risques liés aux technologies de l’information et de la communication (TIC), du signalement des incidents majeurs liés aux TIC, des tests de résilience, de la gestion des risques liés aux tiers dans le domaine des TIC et du partage d’informations sur les cybermenaces. Des normes techniques apportent des précisions sur bon nombre de ces aspects.
Qui doit se conformer aux exigences de la loi DORA ?
La loi sur la résilience opérationnelle numérique (DORA) s'applique à vingt catégories d'entités financières, notamment les établissements de crédit, les établissements de paiement, les entreprises d'investissement, les assureurs et les plateformes de négociation. Certaines entités en sont exclues, et certaines petites entités sont soumises à un cadre simplifié de gestion des risques. Les prestataires de services technologiques ne sont soumis à une surveillance directe que s'ils sont désignés comme essentiels.
Les bibliothèques open source figurent-elles dans le registre DORA des informations ?
Le registre prévu par la loi sur la résilience opérationnelle numérique (DORA) recense les contrats relatifs aux services des technologies de l’information et de la communication (TIC) fournis de manière continue. Une bibliothèque issue d’un registre public ne dispose généralement pas d’un tel contrat ; elle n’y figure donc pas. Un service d’assistance payant peut changer la donne. Quoi qu’il en soit, les règles de gestion des risques s’appliquent toujours à la bibliothèque en tant qu’entité utilisatrice de logiciels.
La loi DORA fait-elle référence aux logiciels libres ?
Oui. Une norme technique relevant de la loi sur la résilience opérationnelle numérique (DORA), à savoir le règlement délégué (UE) 2024/1774 de la Commission, impose aux entités financières de recenser les bibliothèques open source utilisées par les services des technologies de l’information et de la communication (TIC) qui prennent en charge des fonctions critiques ou importantes. Elle exige également que le code open source soit testé avant sa mise en production, lorsque cela est possible.
Quelles sont les sanctions en cas de non-respect de la loi DORA ?
La loi sur la résilience opérationnelle numérique (DORA) laisse à chaque État membre le soin de fixer le niveau des sanctions applicables aux entités financières, lesquelles doivent être efficaces, proportionnées et dissuasives. Les autorités compétentes peuvent ordonner à une entité de mettre fin à une infraction et de prendre des mesures correctives, et elles publient les décisions définitives en matière de sanctions. Les fournisseurs de technologies critiques sont passibles d’une sanction distincte au niveau de l’Union européenne pouvant atteindre 1 % de leur chiffre d’affaires quotidien moyen à l’échelle mondiale, calculée quotidiennement pendant une période maximale de six mois.
À qui incombe le risque de dépendance dans le cadre de la loi DORA ?
La loi sur la résilience opérationnelle numérique (DORA) impose à chaque entité financière, à l'exception des micro-entreprises, de confier à une fonction de contrôle la responsabilité de gérer et de superviser les risques liés aux technologies de l'information et de la communication (TIC). Elle ne précise pas quelle équipe est chargée du suivi des bibliothèques. C'est l'organe de direction qui définit ce rôle ; chaque entité décide donc si cette mission incombe à son équipe chargée des risques TIC ou à celle chargée des risques liés aux tiers.
