Plus de 80 % des incidents majeurs déclarés à l’AMF pour 2025 au titre de DORA sont venus des prestataires, d’après le rapport publié par l’AMF le 24 septembre 2026. Sous DORA, un prestataire TIC se surveille comme un administrateur : chaque changement de droits de ses applications doit être détecté, attribué, qualifié et inscrit au registre des modifications. Le contrat fixe le cadre. Il ne voit rien passer un jeudi matin.
Que dit le rapport de l’AMF sur les incidents majeurs de 2025 ?
Trente-trois incidents majeurs ont été déclarés à l’AMF pour l’année, dont trente et un par des sociétés de gestion de portefeuille. Plus de huit sur dix trouvaient leur origine chez un prestataire, et l’AMF place la résilience numérique et le contrôle de la chaîne de prestataires parmi ses priorités de supervision. En août, nous écrivions que ce bilan dirait ce que le superviseur juge sous-déclaré. Il dit d’abord où regarder.
L’idée reçue : le risque prestataire se règle au contrat
Elle se comprend. L’article 30 du règlement DORA énumère les clauses qu’un contrat de services TIC doit contenir : description des services, lieux de traitement des données, niveaux de service, droits d’accès et d’audit, conditions de sortie. Beaucoup de sociétés de gestion ont abordé 2025 avec des contrats renégociés sur ce modèle, et ont rangé le sujet.
Le bilan de l’AMF dément ce classement. Un contrat décrit un périmètre au jour de la signature, alors que les incidents naissent dans l’exploitation, au fil des mises à jour et des droits qui s’élargissent sans que personne l’ait demandé, souvent chez un éditeur que le prestataire a lui-même choisi et que la société de gestion n’a jamais vu passer.
Un RCCI nous répondra : « notre prestataire est certifié, il contrôle ses propres outils ». Une certification atteste qu’un système de management existe et qu’il a été audité à une date donnée. Elle ne dit pas qui a vu passer la modification de jeudi dernier, ni où elle est écrite.
Un jeudi matin, une application qui s’élargit seule
Le cas vient de chez nous et touche nos propres outils. Un jeudi matin d’octobre 2026, notre contrôle continu de la configuration Microsoft 365 a relevé, chez plusieurs clients, une modification des autorisations d’une application tierce, sans demande de changement correspondante. L’automatisation de l’éditeur d’un de nos outils d’inventaire venait d’élargir les droits de son application : gestion d’Exchange Online pour l’ensemble des utilisateurs et lecture des paramètres SharePoint.
Le constat automatique annonçait aussi des autorisations retirées. L’équipe l’a vérifié au lieu de le croire : c’était un artefact, rien n’avait été retiré. Elle a établi l’auteur et l’origine du changement par le journal d’audit Entra, à la minute près, puis l’a inscrit au registre des modifications, où il reste réversible.
Un éditeur légitime, aucune malveillance. Mais un périmètre élargi sur plusieurs tenants, qu’aucun contrat n’aurait signalé.
Comment prouver qu’un prestataire TIC reste dans son périmètre ?
Par une trace écrite au moment du changement, et retrouvable sans fouille. L’article 9 de DORA demande de limiter les accès logiques à ce qui est nécessaire aux fonctions légitimes et approuvées ; l’article 28 rappelle que l’entité qui recourt à un prestataire reste à tout moment pleinement responsable du respect de ses obligations. Une application tierce qui s’attribue des droits relève des deux articles à la fois.
Nous en tirons le test du jeudi matin : prenez le dernier changement de droits d’une application tierce dans votre Microsoft 365 et demandez à votre prestataire, sous vingt-quatre heures, son auteur, son heure, son origine et la ligne du registre des modifications où il figure. Une seule réponse manque, et la preuve n’existe pas.
Les checklists du chapitre registre de notre guide DORA aident à rattacher chacun de ces changements au prestataire concerné, tel qu’il figure au registre d’information.
Une sortie se termine au dernier rôle retiré
La même semaine, l’équipe menait le retrait d’un autre outil de gestion tiers sur les tenants que nous gérons. Ses applications avaient été désactivées. Sur un tenant, elles détenaient encore des rôles Exchange : le retrait n’était pas terminé. L’article 28 exige des stratégies de sortie pour les services qui soutiennent des fonctions critiques ou importantes ; sur le terrain, une sortie de prestataire est terminée quand son dernier rôle est retiré, pas quand ses applications sont désactivées.
Nous inscrivons au registre tout élargissement de droits, même minime, même venant d’un éditeur que nous avons retenu. Certains clients trouvent ce registre bavard. Nous le préférons bavard plutôt que muet le jour d’un contrôle.
Ce que DORA ne tranche pas
Le règlement ne dit pas à partir de quel élargissement de droits un changement chez un prestataire devient une modification de l’accord à documenter comme telle, et nous n’avons trouvé aucune position publiée de l’AMF qui le précise. Nous retenons donc le seuil le plus bas.
La prochaine remise du registre d’information est attendue au premier trimestre 2027. D’ici là, mesurez le temps qu’il faut à votre prestataire pour sortir la ligne de jeudi dernier. C’est ce registre que nous tenons pour les sociétés de gestion que nous accompagnons en infogérance finance régulée.
Marin consacre trente minutes à passer avec vous votre dernier changement de droits au test du jeudi matin : réserver ce créneau. Sans engagement, aucune relance.
Marin Barjhoux, fondateur et président chez ITAIA
Sources
- AMF, Rapport sur les incidents majeurs DORA déclarés à l’AMF en 2025, 24 septembre 2026 : 33 incidents majeurs, dont 31 dans les sociétés de gestion de portefeuille, plus de 80 % liés aux prestataires ; priorités de supervision.
- EUR-Lex, Règlement (UE) 2022/2554 sur la résilience opérationnelle numérique du secteur financier (DORA) : article 9 (limitation des accès logiques), article 28 (responsabilité de l’entité, stratégies de sortie), article 30 (clauses contractuelles).
