Depuis l’entrée en application de DORA, le 17 janvier 2025, la gestion des prestataires informatiques n’est plus un sujet cantonné aux directions techniques ou aux contrats fournisseurs.

Pour les sociétés de gestion, elle devient un enjeu de gouvernance, de conformité et de continuité opérationnelle. Outils métiers, hébergement, données, reporting, cybersécurité, KYC, plateformes investisseurs, solutions cloud : une part croissante des activités repose sur des tiers spécialisés.

Le sujet n’est donc pas seulement de sélectionner des prestataires performants. Il faut aussi connaître les services qu’ils soutiennent, évaluer leur criticité, encadrer les contrats, suivre les incidents et prévoir ce qui se passerait en cas d’indisponibilité ou de rupture de la relation.

Pourquoi DORA change le pilotage des prestataires TIC

DORA ne remet pas en cause le recours à des prestataires informatiques. Il impose en revanche aux entités financières de mieux comprendre, encadrer et surveiller les risques associés.

La logique est claire : une société de gestion peut externaliser un service, mais elle ne transfère pas pour autant sa responsabilité.

Cette évolution est structurante. Pendant longtemps, le suivi des prestataires reposait principalement sur la qualité de service, les délais, le coût ou la relation commerciale. Désormais, la gouvernance doit aussi intégrer :

• la criticité des services fournis ;
• les dépendances technologiques ;
• la sécurité et la disponibilité des données ;
• les obligations contractuelles ;
• la continuité d’activité ;
• la réversibilité ;
• la traçabilité des incidents ;
• la capacité de contrôle du prestataire.

DORA transforme donc la relation fournisseur en véritable sujet de maîtrise des risques.

Les prestataires concernés ne se limitent pas aux hébergeurs ou aux acteurs du cloud

Une erreur fréquente consiste à limiter le périmètre DORA aux grands fournisseurs cloud ou aux prestataires purement techniques.

En pratique, le champ peut être plus large dès lors qu’un tiers fournit un service reposant sur les technologies de l’information et de la communication.

Pour une société de gestion, cela peut notamment concerner :

• les logiciels de gestion de portefeuille ;
• les solutions de comptabilité et de reporting ;
• les plateformes KYC et d’onboarding investisseurs ;
• les CRM ;
• les outils de data management ;
• les solutions de cybersécurité ;
• les infrastructures cloud ;
• les systèmes de sauvegarde ;
• certains prestataires de middle ou back-office utilisant des services TIC déterminants ;
• les plateformes de communication avec les investisseurs.

Le premier travail ne consiste donc pas à désigner quelques fournisseurs évidents. Il consiste à établir une vision complète et documentée de l’écosystème TIC.

Premier chantier : cartographier les prestataires et les services TIC

La cartographie est la base du dispositif.

Elle doit permettre de relier chaque prestataire aux services fournis, aux processus concernés et aux données utilisées. Sans cette vision, il devient difficile d’évaluer correctement la criticité ou de produire un registre fiable.

Les informations à recenser

Exemple concret

Une société de gestion utilise une plateforme d’onboarding investisseurs. L’outil est géré par un éditeur, hébergé chez un fournisseur cloud et interconnecté avec un CRM et un espace documentaire.

Considérer uniquement l’éditeur comme prestataire principal ne suffit pas. Il faut aussi comprendre la chaîne technique, les dépendances et les données qui circulent entre les différents acteurs.

Deuxième chantier : identifier les fonctions critiques ou importantes

Tous les prestataires ne présentent pas le même niveau de risque.

Une solution utilisée ponctuellement pour une tâche non sensible ne doit pas être pilotée de la même manière qu’un outil indispensable au calcul, au reporting, à la conformité ou à la relation investisseurs.

L’analyse doit donc porter sur la fonction soutenue par le service TIC.

Les questions à poser

• Une interruption compromettrait-elle une activité essentielle ?
• L’indisponibilité pourrait-elle empêcher de respecter une obligation réglementaire ?
• Le service traite-t-il des données sensibles ou critiques ?
• Existe-t-il une solution alternative immédiatement disponible ?
• Une défaillance pourrait-elle affecter les investisseurs ou les fonds ?
• Le remplacement du prestataire serait-il long ou complexe ?

Exemples de qualification

Cette qualification ne doit pas être purement théorique. Elle doit refléter le fonctionnement réel de la société de gestion.

Troisième chantier : fiabiliser le registre d’information DORA

DORA impose la tenue d’un registre d’information recensant les accords contractuels conclus avec les prestataires de services TIC.

Ce registre n’est pas une simple liste de fournisseurs. Il constitue une vue structurée des dépendances technologiques et contractuelles de l’entité.

Il doit être maintenu à jour et pouvoir être transmis à l’autorité compétente selon les modalités applicables.

Les difficultés les plus fréquentes

• données dispersées entre achats, juridique, informatique et conformité ;
• contrats anciens ou incomplets ;
• identification difficile des sous-traitants ;
• incohérences entre le contrat et l’usage réel ;
• évolution des services non répercutée dans le registre ;
• informations manquantes sur les fonctions soutenues.

Exemple concret

Un contrat initial portait sur un outil de reporting interne. Au fil du temps, la solution a été étendue au reporting investisseurs, puis à certaines données réglementaires.

Le niveau de criticité a évolué, mais le contrat, la cartographie et le registre n’ont pas été actualisés. Le problème ne vient pas uniquement de la documentation. Il vient du décalage entre le dispositif formel et l’usage réel.

Quatrième chantier : revoir les contrats avec les prestataires TIC

DORA prévoit un ensemble d’exigences contractuelles minimales pour les services TIC, avec des dispositions renforcées lorsque le service soutient une fonction critique ou importante.

La revue contractuelle doit donc être menée en fonction de la nature du service et du niveau de dépendance.

Les thèmes à examiner

• description claire des services ;
• lieux de traitement et de stockage des données ;
• exigences de sécurité ;
• obligations de notification des incidents ;
• coopération avec les autorités ;
• accès, restitution et récupération des données ;
• droits d’audit et d’inspection ;
• continuité d’activité ;
• conditions de résiliation ;
• modalités de réversibilité ;
• suivi des sous-traitants.

Contrat commercial ou contrat réellement pilotable

Point de vigilance

La mise en conformité contractuelle ne doit pas devenir un exercice purement juridique.

Une clause peut être présente sans être opérationnelle. Un droit d’audit, par exemple, a peu de valeur si personne ne sait quand l’utiliser, quelles informations demander ou qui analysera les résultats.

Cinquième chantier : organiser le pilotage dans la durée

La conformité d’un contrat à un instant donné ne suffit pas.

Les prestataires évoluent, les outils changent, les sous-traitants se multiplient et les usages internes se transforment. Le dispositif doit donc intégrer un suivi régulier.

Les indicateurs utiles

• disponibilité du service ;
• incidents et délais de résolution ;
• respect des niveaux de service ;
• changements importants ;
• évolution des sous-traitants ;
• tests de continuité ;
• vulnérabilités identifiées ;
• plans de remédiation ;
• concentration sur un même fournisseur.

Exemple de tableau de bord

Ce pilotage doit être proportionné. Tous les prestataires n’ont pas besoin du même niveau de surveillance.

Sixième chantier : préparer la continuité et la réversibilité

La continuité ne se limite pas à demander au prestataire s’il dispose d’un plan de secours.

La société de gestion doit comprendre comment elle continuerait à fonctionner si le service devenait indisponible, si le fournisseur rencontrait une difficulté majeure ou si la relation devait être interrompue.

Les sujets à documenter

• processus métier affectés ;
• délai maximal d’interruption acceptable ;
• solution de fonctionnement dégradé ;
• sauvegarde et récupération des données ;
• responsabilités en situation de crise ;
• solution alternative ;
• délai de migration ;
• format de restitution des données ;
• ressources nécessaires à une sortie.

Exemple concret

Une société de gestion dispose d’une clause de réversibilité dans son contrat. Mais elle n’a jamais vérifié sous quel format les données seraient restituées, combien de temps durerait la migration ni si une solution alternative pourrait les reprendre.

La clause existe. La réversibilité opérationnelle, elle, reste incertaine.

Septième chantier : intégrer les incidents prestataires au dispositif global

Un incident subi par un prestataire peut devenir un incident majeur pour la société de gestion.

Il faut donc prévoir un circuit précis entre le fournisseur, les équipes internes, la conformité, la sécurité et la direction.

Le dispositif doit clarifier

• qui reçoit l’alerte ;
• qui qualifie l’incident ;
• comment l’impact métier est évalué ;
• qui décide d’une escalade ;
• quelles informations doivent être conservées ;
• quand l’autorité doit être informée ;
• comment le retour d’expérience est organisé.

L’objectif n’est pas uniquement de réagir. Il est aussi d’apprendre et d’éviter la répétition.

Huitième chantier : surveiller le risque de concentration

Une société de gestion peut utiliser plusieurs outils différents tout en dépendant, indirectement, du même fournisseur cloud ou du même sous-traitant.

La concentration ne se mesure donc pas seulement au nombre de contrats.

Elle peut être :

• technologique ;
• géographique ;
• contractuelle ;
• liée à un éditeur ;
• liée à une infrastructure cloud ;
• liée à une compétence difficilement remplaçable.

Exemple concret

Trois solutions métiers différentes sont utilisées pour la comptabilité, le reporting et le KYC. Elles semblent indépendantes, mais sont toutes hébergées sur la même infrastructure.

Une défaillance commune pourrait donc affecter plusieurs fonctions en même temps.

Ce que DORA ne doit pas produire

Une mauvaise mise en œuvre de DORA peut conduire à une inflation documentaire sans amélioration réelle de la résilience.

Les principaux écueils sont connus :

• multiplier les fichiers sans responsable clair ;
• remplir le registre une fois par an sans le relier au pilotage ;
• revoir les contrats sans tester la continuité ;
• confier le sujet uniquement à l’IT ;
• traiter tous les prestataires de manière identique ;
• oublier les usages réels au profit de l’organisation théorique.

DORA doit au contraire servir à mieux comprendre les dépendances, clarifier les responsabilités et améliorer la continuité.

Comment répartir les responsabilités

La gestion des prestataires TIC ne peut pas reposer sur une seule fonction.

Une gouvernance utile ne signifie pas nécessairement multiplier les comités. Elle signifie surtout savoir qui décide, qui suit et qui alerte.

À quel moment demander un accompagnement externe

Un accompagnement devient pertinent lorsque :

• la cartographie des prestataires reste incomplète ;
• le registre d’information repose sur des données dispersées ;
• les contrats n’ont pas été évalués selon la criticité ;
• plusieurs prestataires soutiennent des fonctions sensibles ;
• les plans de continuité ne sont pas testés ;
• la société ne dispose pas de ressources disponibles pour piloter le chantier ;
• les responsabilités restent partagées sans véritable chef de file.

Le rôle d’un cabinet spécialisé n’est pas de produire une documentation supplémentaire pour elle-même.

Il consiste à relier les exigences réglementaires à la réalité des opérations, des contrats, des outils et des équipes.

Pourquoi le sujet correspond au positionnement de Yumani Finance

Le pilotage des risques liés aux prestataires TIC se situe à l’intersection de plusieurs expertises mises en avant par Yumani Finance :

• conformité et suivi réglementaire ;
• gestion des risques ;
• transformation digitale et outils métiers ;
• optimisation des processus ;
• pilotage opérationnel ;
• accompagnement des sociétés de gestion et des acteurs du Private Equity.

Cette lecture transversale est essentielle. DORA ne peut pas être traité efficacement comme un projet uniquement informatique, réglementaire ou juridique.

Il faut comprendre la chaîne complète : le besoin métier, l’outil, le contrat, les données, le contrôle, la continuité et la gouvernance.

DORA a fait évoluer la relation entre les sociétés de gestion et leurs prestataires informatiques.

Le sujet n’est plus seulement de vérifier que les outils fonctionnent ou que les contrats sont signés. Il faut désormais connaître les dépendances, qualifier les fonctions critiques, maintenir un registre fiable, encadrer les contrats, suivre les incidents et préparer les scénarios de continuité et de sortie.

La difficulté n’est pas uniquement réglementaire.

Elle est surtout organisationnelle : faire travailler ensemble les métiers, l’IT, la conformité, les risques, le juridique et la direction autour d’une vision commune.

Bien menée, cette démarche ne produit pas seulement de la conformité. Elle rend la société de gestion plus lucide sur ses dépendances et plus robuste face aux incidents.

FAQ – DORA : piloter les risques liés aux prestataires informatiques d’une société de gestion