Ce que les auditeurs DORA attendent de vos tests de charge

Selon DORA, les preuves de tests de charge et de performance font partie de la revue de résilience.

Pour les équipes de conformité et d’ingénierie des entités financières de l’UE qui doivent démontrer que leurs systèmes tiennent la charge.

Le Digital Operational Resilience Act (DORA) de l’UE s’applique aux entités financières depuis le 17 janvier 2025. Il établit un unique règlement pour la manière dont les banques, assureurs, sociétés d’investissement et leurs fournisseurs critiques de TIC maintiennent les services numériques en fonctionnement malgré les interruptions. Le test de résilience opérationnelle numérique est l’un de ses cinq piliers (aux côtés de la gestion des risques TIC, la déclaration d’incidents, les risques liés aux tiers, et le partage d’informations), et ce pilier concerne directement vos tests de charge et de performance.

Une première précision car l’acronyme est surchargé. Cet article traite du règlement de l’UE et non des “DORA metrics” DevOps (fréquence des déploiements, temps de cycle, etc.). C’est une DORA complètement différente.

L’article 25 du règlement énumère les méthodes de test qu’un programme de résilience doit utiliser. Les tests de performance et les tests de bout en bout figurent sur cette liste, aux côtés des évaluations de vulnérabilité et des tests de pénétration. Ainsi, lorsqu’un examinateur passe en revue vos tests de résilience, les preuves de tests de charge et de stress sont pertinentes.

La majorité des contenus sur DORA en ligne se concentrent sur les tests de pénétration pilotés par les menaces. Cet article couvre l’obligation plus discrète : montrer que vos systèmes restent réactifs sous volume, fournir les preuves qu’un auditeur demandera réellement, et le faire avec un outil conçu pour cela. LoadView est une plateforme de test de charge en cloud utilisant de vrais navigateurs, et les sections suivantes font correspondre chaque point de la checklist d’un examinateur DORA avec la capacité LoadView qui le produit.

Ce que couvre ce guide

1. Où les tests de charge s’intègrent dans DORA
2. Les preuves d’audit qu’un examinateur DORA attend
3. Comment LoadView soutient les tests de résilience opérationnelle DORA
4. Pourquoi les chiffres de charge au protocole seul ne tiennent pas face à un audit
5. Comment produire des preuves de test prêtes pour DORA
6. Le bilan
7. Foire aux questions

Où les tests de charge s’intègrent dans DORA

DORA est fondé sur l’analyse des risques, sans prescriptions sur les outils. Il ne dit pas « exécutez un test de charge à 500 utilisateurs chaque trimestre ». Il dit testez les systèmes TIC qui supportent des fonctions critiques ou importantes de façon régulière, et agissez selon les résultats.

Deux articles portent la majorité des exigences pour le travail de performance :

• Article 24 définit les principes généraux de test. Les entités financières testent les systèmes TIC et applications qui supportent les fonctions critiques ou importantes au moins une fois par an, via une approche basée sur le risque.
• Article 25 liste les méthodes à utiliser. Le test de performance et le test de bout en bout y sont explicitement nommés.

Pour une plateforme de trading, une API de paiements ou un portail bancaire en ligne, « résister à la perturbation » inclut les perturbations dues à la charge : une affluence lors de l’ouverture du marché, un pic le jour de paie, une promotion qui triple le trafic au paiement. Si le service ralentit ou plante sous charge, c’est un déficit de résilience opérationnelle. DORA attend que vous l’ayez identifié avant la production, ce qui justifie la place des tests de charge pour les services financiers dans le programme.

Les enjeux sont pratiques, pas seulement procéduraux. Les superviseurs peuvent exiger qu’une entité corrige les déficits de résilience détectés, donc un audit révélant un système critique non testé engendre du travail imprévu selon le calendrier du régulateur, non le vôtre.

Les preuves d’audit qu’un examinateur DORA attend

Les examinateurs travaillent sur base des preuves, pas des intentions. Lors d’une revue de vos tests de résilience, attendez-vous à ce qu’ils recherchent des artefacts comme ceux-ci:

La première ligne est celle où les équipes perdent le plus de points. Sans SLA de performance documentées, un test de charge n’a pas de seuil de réussite/échec, et un auditeur ne voit qu’un graphique sans norme derrière. Fixez d’abord les objectifs : le temps de réponse P95 par transaction critique, un plafond du taux d’erreur, et la charge maximale que chaque système doit supporter.

Les lignes deux et trois concernent la temporalité et la rigueur. Exécuter un test de charge avant chaque mise en production montre que le volume est vérifié avant que les clients n’accèdent au code, et intégrer ce contrôle dans le pipeline de mise en production assure sa régularité. Le test de stress va plus loin qu’un test de charge en dépassant les pics prévus jusqu’à ce que quelque chose lâche, ce qui fait que le point de rupture est un chiffre connu et non une surprise le jour de l’ouverture du marché.

La quatrième ligne correspond à l’artefact que les examinateurs manipulent le plus. Un rapport avec les percentiles de temps de réponse, les taux d’erreur, et le profil de charge qui les a produits est la preuve centrale, et il doit porter une date et une version pour s’attacher à une version précise.

La cinquième lie le test à une prévision. La documentation de planification de capacité indique combien de marge le dernier test a mesurée et quand la croissance l’aura épuisée. Les lignes six et sept distinguent un vrai programme d’un programme papier. Lorsqu’un test met en lumière une goulot d’étranglement, l’examinateur veut l’action corrective, c’est pourquoi LoadView rapporte que les goulots d’étranglement identifiés précisent : quel étage était lent, ce qui a changé, et le résultat du retest.

Comment LoadView soutient les tests de résilience opérationnelle DORA

Chaque ligne de cette liste de preuves correspond directement à une fonctionnalité de LoadView. Le tableau ci-dessous associe l’artefact demandé par l’examinateur à la capacité LoadView qui le produit, pour que l’exigence de conformité et la fonctionnalité de l’outil correspondent une à une.

Deux détails de LoadView font la majorité du travail ici. Le premier, c’est que les tests s’exécutent dans de vrais navigateurs, ainsi les temps affichés dans votre rapport sont les temps qu’un client verrait réellement, ce qui crédibilise le rapport comme preuve de résilience. Le second, c’est que le flux complet est scripté comme un parcours utilisateur plutôt qu’une série de requêtes brutes, donc un test de bout en bout selon l’article 25 couvre la connexion, la transaction et la confirmation comme dans une vraie session. Les deux sections suivantes abordent chacun de ces points.

Pourquoi les chiffres de charge au protocole seul ne tiennent pas face à un audit

Un test de charge qui envoie des requêtes HTTP brutes peut afficher de gros chiffres de débit. Mais pour un service financier orienté client, ces chiffres décrivent le serveur, pas le client. Ils ignorent le JavaScript, le contrôle antifraude tiers, la redirection SSO, et l’écran de confirmation rendu.

Un examinateur voulant savoir si les clients peuvent transiger sous charge attend des preuves sur l’expérience client, pas seulement sur le taux de requêtes côté origine. Le test de charge en vrai navigateur exécute le test via de vrais Chromium, donc les temps de réponse dans votre rapport sont ceux que le client verrait. En termes simples, le test charge la page comme le navigateur du client le ferait : en exécutant les scripts, redirections, et le rendu, au lieu de seulement pinguer le serveur.

Pour une banque ou un fournisseur de paiements, c’est la différence entre « l’API a répondu en 200ms » et « le parcours login-confirmation a pris neuf secondes car l’appel de scoring antifraude a fait file d’attente ». Le second dégrade le service. Et justement, c’est ce que cherche une revue de résilience, ce pourquoi le test de concurrence transactionnelle sur de vrais parcours utilisateurs produit des preuves plus solides qu’un simple graphique de débit au niveau protocole.

Un outil annonçant « 100 000 requêtes par seconde » sans exécuter la page mesure le débit HTTP, pas ce que le client expérimente à l’écran de connexion. Un auditeur vérifiant la résilience côté client veut le second chiffre.

Les tests au niveau protocole mesurent le serveur ; les tests LoadView en vrai navigateur mesurent le parcours login-confirmation du client.

Comment produire des preuves de test prêtes pour DORA

Vous n’avez pas besoin d’une nouvelle catégorie d’outil pour satisfaire ce pilier. Vous avez besoin de tests correspondant à la liste des preuves et d’un enregistrement à remettre à un auditeur. Voici la séquence dans LoadView :

1. Écrivez les exigences de performance pour chaque fonction critique. Fixez les percentiles de temps de réponse et un plafond du taux d’erreur par transaction, faites-les valider, et entrez-les comme seuils réussite/échec pour que les résultats s’évaluent automatiquement.
2. Enregistrez le test comme un vrai parcours utilisateur. Utilisez le enregistreur EveryStep pour capturer le parcours réel (login, transaction, confirmation) clic par clic dans un vrai navigateur, puis rejouez-le sous charge avec le test de charge d’application web au lieu de rejouer des appels HTTP bruts.
3. Testez jusqu’au pic prévu, puis au-delà. Configurez des types de courbes de charge pour maintenir les utilisateurs virtuels au pic prévu pour le test de charge, puis une courbe en paliers qui dépasse ce pic pour le test de stress, afin de répondre aux questions “peut-on gérer le jour” et “où c’est que ça casse”.
4. Injectez la charge depuis les régions que vous servez. Si vos clients sont dans toute l’UE, lancez les tests depuis plus de 30 zones d’injection géodistribuée pour mesurer la performance là où sont les utilisateurs, pas uniquement depuis un centre de données.
5. Conservez le rapport. Exportez les rapports de test de performance avec percentiles, taux d’erreur, profil de charge, cascade, et horodatage, et archivez-les avec le dossier de mise en production. C’est ce fichier que l’examinateur lira.
6. Refaites les tests selon un planning et après modification. Répétez au moins une fois par an pour les fonctions critiques, après toute mise en production impactant un chemin critique, et dès que la croissance vous rapproche du plafond de capacité mesuré par le dernier test. Planifier l’exécution et l’intégrer dans votre pipeline CI/CD automatise ce rythme, au lieu d’un rappel calendaire.

Gérés ainsi, les preuves se construisent naturellement comme un sous-produit de tests que vous voudriez exécuter de toute façon. Comme LoadView est entièrement cloud-hébergé, il n’y a pas d’infrastructure de génération de charge à déployer ni à justifier devant un auditeur, et les artefacts correspondent à ce que demande un examinateur DORA, dans l’ordre où il le demande.

Le champ d’application de DORA s’étend aussi aux fournisseurs tiers TIC critiques sur lesquels vous comptez. Si une passerelle de paiement, un service d’identité ou une API de données est sur un chemin critique, son comportement sous charge fait aussi partie de votre tableau de résilience, donc le test de charge API de ces points de terminaison garde les mêmes preuves archivées pour les services que vous ne gérez pas vous-même.

Découvrez comment LoadView produit les preuves qu’un examinateur DORA demande. Programmez une démo LoadView pour calibrer un test selon vos pics de volumes et exporter les rapports que vos auditeurs demanderont.

Le bilan

DORA ne vous remet pas une checklist de tests de charge, mais son pilier de tests de résilience et les méthodes de l’article 25 intègrent les tests de performance et de charge à ce qu’un examinateur peut inspecter. Les systèmes importants sont ceux qui supportent les fonctions critiques ou importantes, et le critère est qu’ils continuent à servir les clients sous volume.

Produisez les sept artefacts qu’un examinateur attend, basez-les sur des résultats en vrai navigateur plutôt que des débits au niveau protocole, et refaites les tests à mesure que les volumes croissent. LoadView est conçu pour générer chacun de ces artefacts à partir d’un seul test scripté, rendant un audit de vos tests de performance aussi simple que de fournir des enregistrements que vous conservez déjà.

Foire aux questions