Plateformes de trading, cloud, DevOps et systèmes critiques : audit, conseil, formation et assistance technique pour la finance de marché

Plateformes de négociation et systèmes critiques : le cadre MiFID II

Négociation algorithmique et résilience des systèmes

La directive 2014/65/UE (MiFID II), dont le texte est consultable sur EUR-Lex, traite directement de la robustesse des systèmes. Son article 17 impose aux entreprises d'investissement qui pratiquent la négociation algorithmique des systèmes et des contrôles de risque efficaces : résilients, de capacité suffisante, assortis de seuils et de limites, de nature à empêcher l'envoi d'ordres erronés et à ne pas contribuer à un fonctionnement désordonné du marché. Ces systèmes doivent être pleinement testés, surveillés et appuyés par des dispositifs de continuité d'activité.

L'article 48 applique des principes voisins aux marchés réglementés et aux autres plateformes de négociation : résilience des systèmes, capacité à absorber des volumes élevés d'ordres et de messages, mécanismes de suspension des négociations, tests et contrôles sur la négociation algorithmique. Ces exigences s'adressent à l'entité régulée. Les prestataires qui conçoivent, déploient ou exploitent ses outils en subissent les conséquences indirectes, notamment par le contrat.

Les normes techniques de 2017

Plusieurs règlements délégués précisent ces articles. Le règlement délégué (UE) 2017/589 (RTS 6) fixe les exigences organisationnelles des entreprises d'investissement qui pratiquent la négociation algorithmique. Il prévoit par exemple une auto-évaluation annuelle et des tests de résistance de leurs systèmes, qui ne doivent pas perturber la production, avec des scénarios fondés sur le volume de messages ou d'opérations le plus élevé des six mois précédents, doublé. Il traite aussi des tests de conformité, c'est-à-dire de la bonne interaction avec les systèmes de la plateforme. Le règlement délégué (UE) 2017/584 (RTS 7) vise les plateformes de négociation qui permettent la négociation algorithmique : évaluation de conformité avant déploiement puis au moins une fois par an, méthodes de développement et de test, capacité et continuité.

Le règlement délégué (UE) 2017/574 (RTS 25) porte sur la précision des horloges d'affaires et la traçabilité par rapport au temps universel coordonné. Pour une équipe d'architecture, l'enchaînement est simple : une exigence de test ou de capacité se traduit en environnements de test représentatifs, en jeux de données de test, en journaux horodatés et en preuves conservées. C'est précisément ce travail d'ingénierie que nos missions d'audit et de conception outillent.

Rôles et responsabilités

Dans une entité financière, la responsabilité d'un système critique ne se délègue pas. L'organe de direction répond du cadre de gestion du risque lié aux TIC (technologies de l'information et de la communication) ; la direction des systèmes d'information et le responsable de la sécurité des systèmes d'information l'exécutent ; la deuxième ligne de défense (risques, conformité, contrôle permanent) le surveille ; l'audit interne le revoit. Les prestataires, éditeurs, hébergeurs et sociétés de conseil, interviennent dans un cadre contractuel qui précise leurs livrables et leurs engagements. Pour une mission d'ingénierie, la règle pratique est de savoir à tout moment pour le compte de quelle entité on agit et sous quelles règles d'accès et de changement, afin de ne jamais se substituer à l'un des acteurs ni de contourner un contrôle.

DORA, cloud et prestataires tiers

Opérations, changements et systèmes historiques

Le règlement (UE) 2022/2554 (DORA), applicable depuis le 17 janvier 2025, fait de la gestion des systèmes d'information un sujet de gouvernance. Son article 8 impose d'identifier et de cartographier les actifs et leurs interdépendances, y compris les liens avec les prestataires de services TIC qui soutiennent des fonctions critiques ou importantes. Il demande aussi, pour les entités autres que les microentreprises, une évaluation spécifique du risque sur tous les systèmes historiques, au moins une fois par an et avant et après leur connexion à de nouvelles technologies. L'article 12 exige des politiques de sauvegarde et de restauration, des systèmes de reprise séparés de l'environnement source, une capacité redondante et des objectifs de reprise adaptés à la criticité des fonctions.

Le règlement délégué (UE) 2024/1774 en détaille les exigences, dont la sécurité des opérations, la gestion de la capacité, la journalisation et la gestion des changements. L'article 25 liste des tests dont certains sont familiers des équipes d'ingénierie : tests de performance, tests de bout en bout, revues de code, tests de compatibilité. Le texte de référence est sur EUR-Lex.

Cloud, concentration et sortie

Le chapitre V de DORA (Digital Operational Resilience Act, règlement sur la résilience opérationnelle numérique du secteur financier) place la responsabilité chez l'entité : elle reste pleinement responsable lorsqu'elle recourt à un prestataire (article 28), tient un registre d'informations de ses accords sur les services TIC et prévoit des stratégies de sortie documentées et testées pour les fonctions critiques ou importantes. L'article 29 demande d'évaluer le risque de concentration avant de contracter : prestataire difficilement substituable, contrats multiples avec le même prestataire, chaînes de sous-traitance. L'article 30 liste les clauses du contrat, dont la description des services, les lieux de traitement des données, les niveaux de service, l'assistance en cas d'incident et, pour les fonctions critiques ou importantes, les droits d'accès et d'audit et les stratégies de sortie.

L'article 31 permet de désigner des prestataires critiques. La première liste a été publiée le 18 novembre 2025 par l'EBA (European Banking Authority, Autorité bancaire européenne), l'EIOPA (European Insurance and Occupational Pensions Authority, Autorité européenne des assurances et des pensions professionnelles) et l'ESMA (European Securities and Markets Authority, Autorité européenne des marchés financiers). Côté orientations, celles de l'EBA sur l'externalisation (EBA/GL/2019/02) ont encadré le recours au cloud depuis le 30 septembre 2019 ; l'EBA a publié le 18 septembre 2026 de nouvelles orientations sur le risque lié aux tiers, avec une période transitoire de deux ans. Les orientations de l'ESMA de 2021 sur le cloud ont été restreintes à certains dépositaires, DORA couvrant les autres entités. Pour les services TIC, DORA reste la référence.

Souveraineté, réversibilité et coûts

Le choix d'un hébergeur ne se réduit pas à la technique. En France, le référentiel SecNumCloud de l'ANSSI (Agence nationale de la sécurité des systèmes d'information), dans sa version 3.2, définit des exigences de sécurité pour les prestataires de cloud, dont la protection vis-à-vis de droits extra-européens ; il ne s'impose pas à toutes les entités financières, et son usage relève de votre analyse. Le règlement (UE) 2023/2854 (Data Act) donne par ailleurs aux clients de services de traitement de données, dont le cloud, des droits de changement de fournisseur, applicables depuis le 12 septembre 2025, avec une suppression des frais de changement prévue à compter de janvier 2027. La pratique FinOps complète le tableau : suivre les coûts et l'empreinte du cloud est un sujet de gouvernance, pas seulement de facturation. Le recours à plusieurs hébergeurs n'est pas une réponse automatique au risque de concentration : il ajoute de la complexité d'exploitation et de sécurité, et ne vaut que si les stratégies de sortie sont réellement documentées et testées.

DevOps, observabilité et systèmes historiques

Livraison continue sous contrainte de contrôle

DevOps n'est pas un contournement du contrôle : dans une entité financière, il se pratique avec des environnements décrits en code, des revues, des tests automatisés, des validations tracées, une séparation des droits entre développement et exploitation, et des retours arrière préparés. Chaque changement doit laisser une trace utilisable par le contrôle interne, et un incident doit pouvoir être relié au changement qui l'a causé. Des outils comme Terraform, Ansible, Kubernetes ou OpenShift servent cette discipline lorsque les règles sont écrites avant l'outil.

Les architectures événementielles, la séparation des lectures et des écritures (CQRS) et la conception pilotée par le domaine (DDD) répondent à des besoins de débit, d'évolutivité et de lisibilité du métier. Elles ont un coût de complexité : nous aidons à décider là où elles sont utiles et à documenter leurs limites, sans promesse de performance.

Observabilité, fiabilité et incidents

Prometheus, Grafana et OpenTelemetry sont des outils de supervision et de traçage largement utilisés. Leur intérêt dépend de la qualité des indicateurs choisis et des seuils d'alerte : une supervision sans astreinte organisée ne détecte rien d'utile. L'approche de fiabilité (SRE) définit des objectifs de niveau de service et organise le retour d'expérience après incident. Elle s'articule avec DORA, qui impose un processus de gestion, de classification et de notification des incidents liés aux TIC (articles 17 à 19) : une bonne observabilité donne des données fiables pour classer un incident et en dater la détection.

Les tests de charge et de performance des API et des microservices se préparent comme des essais : profil de charge réaliste construit à partir de volumes publics ou de test, environnement représentatif, critères d'acceptation écrits, résultats conservés. Un test qui ne ressemble pas à la production donne une fausse assurance ; nous insistons donc sur la représentativité de l'environnement et sur la lecture critique des résultats, plutôt que sur un chiffre isolé.

Systèmes centraux, COBOL et modernisation

Beaucoup d'établissements exploitent encore des systèmes centraux IBM z/OS et des applications COBOL (Common Business-Oriented Language, langage de programmation de gestion) au cœur de leurs traitements. La difficulté n'est pas seulement technique : les compétences sont rares, la documentation est parfois ancienne et chaque évolution peut toucher des chaînes entières. DORA traite ces systèmes comme n'importe quel actif, avec l'évaluation annuelle des systèmes historiques. Une modernisation par étapes, qui isole des services, expose des interfaces et transfère les connaissances, réduit le risque davantage qu'une réécriture d'un bloc.

Ce que nous faisons, et ce que nous ne faisons pas

Ce que nous faisons

Nous auditons des architectures, des capacités et des chaînes de changement. Nous conseillons sur une architecture cible, une stratégie cloud et une trajectoire DevOps. Nous concevons des architectures événementielles et cloud-native. Nous déployons, migrons et industrialisons des plateformes et des pipelines. Nous apportons une assistance technique, sous la responsabilité et l'encadrement d'Optédif, avec des livrables définis, au forfait ou en récurrent ; lorsque cette assistance est un service TIC pour une entité financière, les clauses de l'article 30 de DORA peuvent s'appliquer au contrat. Nous formons en intra-entreprise. Nos exemples reposent sur des données publiques ou de test.

Ce que nous ne faisons pas

• Nous n'exerçons aucune activité réglementée : ni négociation pour compte propre ou de tiers, ni gestion de portefeuille, ni conseil en investissement, ni exploitation d'une plateforme de négociation.
• Nous n'accédons à aucun ordre, aucune position ni aucune information privilégiée : nos missions portent sur l'architecture, les processus, les outils et les données de test.
• Nous n'opérons aucun test d'intrusion ni aucun test fondé sur la menace (TLPT), qui relèvent de prestataires qualifiés et des testeurs de l'article 27 de DORA, et nous ne sommes pas qualifiés par l'ANSSI.
• Nous ne promettons ni latence, ni disponibilité, ni gain de coût, et nous n'attestons pas la conformité d'une plateforme à MiFID II ou à DORA.
• Nous ne formulons aucune consultation juridique : l'interprétation des textes et des contrats revient à vos juristes.

Pour vérifier les textes

Consultez les sources officielles : le règlement DORA sur EUR-Lex, le règlement délégué 2017/589 et le site de l'ANSSI.