Régulation
Externalisation IT : la vigilance de l'ACPR
Rappeler les exigences applicables au cloud et aux prestataires critiques du secteur financier.
6 min de lecture
4,9sur 5303 votes
- 2,5Klecteurs
- 11en ce moment
- 55partages
L’externalisation IT permet de confier un service technologique à un prestataire, mais elle ne décharge pas une banque, un assureur ou un autre acteur financier de ses responsabilités. L’ACPR attend notamment une gouvernance claire, une évaluation des risques, des contrats adaptés et une capacité réelle à suivre les incidents et la continuité des services.
Confier l’hébergement, la cybersécurité, le support applicatif ou une plateforme de données à un tiers est devenu courant dans le secteur financier. Cette organisation peut apporter des compétences spécialisées et une meilleure capacité d’exécution. Elle introduit aussi une dépendance qui doit être connue, pilotée et documentée.
La vigilance ne porte donc pas uniquement sur le choix initial du fournisseur. Elle concerne toute la relation : la nature du service confié, son importance pour l’activité, les données concernées, les engagements contractuels, le suivi quotidien et les scénarios de défaillance. Avec le règlement européen DORA, applicable depuis le 17 janvier 2025, la résilience opérationnelle numérique occupe une place centrale dans cette approche.
Externalisation IT : la vigilance de l’ACPR ne s’arrête pas au contrat
Un contrat signé ne constitue pas, à lui seul, une maîtrise du risque. L’établissement doit pouvoir expliquer pourquoi il externalise une fonction, quels risques il a identifiés et quelles décisions il conservera en interne. La responsabilité de la direction demeure engagée dans la surveillance du dispositif.
Cette logique évite une confusion fréquente : un prestataire peut réaliser une opération technique, sans devenir responsable de la conformité prudentielle de son client. Lorsqu’un outil indispensable devient indisponible, qu’une donnée est mal protégée ou qu’un incident ralentit un service essentiel, l’établissement doit rester capable d’agir, de décider et de rendre compte.
Pour être crédible, le pilotage doit dépasser les tableaux de bord reçus chaque mois. Il suppose de savoir qui contrôle le prestataire, à quelle fréquence, sur quels indicateurs et selon quelles modalités d’escalade. Une alerte utile doit parvenir à la bonne personne assez tôt pour permettre une décision.
Identifier les services TIC qui créent une dépendance sensible
Toutes les prestations IT n’ont pas le même poids. La maintenance d’un outil interne peu utilisé ne présente pas la même exposition qu’une solution qui traite des données clients, exécute des opérations importantes ou permet aux équipes de travailler. Le premier travail consiste donc à décrire précisément le service et ses conséquences possibles en cas de dysfonctionnement.
Cette analyse peut s’appuyer sur des questions concrètes :
- Le service est-il nécessaire à une activité essentielle ou importante ?
- Quelles informations sont traitées, stockées ou accessibles par le prestataire ?
- Existe-t-il un autre moyen de poursuivre l’activité en cas d’indisponibilité ?
- Le fournisseur dépend-il lui-même de sous-traitants déterminants ?
- La concentration des services chez un même acteur augmente-t-elle l’exposition globale ?
La réponse ne doit pas rester théorique. Une cartographie utile montre les liens entre applications, données, fournisseurs et métiers. Elle aide à reconnaître les dépendances avant qu’un incident ne les révèle dans l’urgence.
Une gouvernance interne capable de challenger le prestataire
Externaliser une compétence ne signifie pas renoncer à toute expertise interne. L’établissement doit conserver des interlocuteurs capables de comprendre les enjeux du service, d’évaluer les informations fournies et de demander des correctifs lorsque cela est nécessaire. Sans ce niveau de maîtrise, le suivi risque de devenir purement déclaratif.
La répartition des rôles mérite d’être formalisée. La fonction métier peut exprimer les besoins et mesurer l’impact opérationnel. Les équipes IT évaluent l’architecture, la sécurité et les dépendances. Les fonctions de contrôle apprécient les risques et la qualité des preuves. La direction arbitre les décisions importantes, notamment lorsqu’une prestation critique évolue ou se dégrade.
| Point de contrôle | Ce qu’il permet de vérifier |
|---|---|
| Périmètre du service | Les fonctions, données et interfaces réellement confiées |
| Niveau de criticité | Les conséquences d’une interruption ou d’une altération |
| Indicateurs de suivi | La qualité de service, les incidents et les actions correctrices |
| Plan de continuité | La capacité à maintenir ou rétablir l’activité |
| Stratégie de sortie | Les conditions d’un transfert ou d’un remplacement du fournisseur |
DORA et les incidents TIC : organiser une réaction traçable
DORA renforce le cadre européen de résilience opérationnelle numérique applicable au secteur financier. Dans ce contexte, la gestion des incidents TIC ne peut pas reposer sur des échanges informels entre un client et son prestataire. Il est important de prévoir les canaux d’alerte, les informations à transmettre, les délais internes et les personnes habilitées à qualifier la situation.
À lire aussi
L’ACPR a publié l’instruction n° 2025-I-09 relative à l’externalisation de l’obligation de déclaration des incidents majeurs liés aux technologies de l’information et de la communication. Ce point rappelle qu’une organisation peut confier certaines tâches de déclaration, tout en conservant une obligation de supervision du processus.
En pratique, un établissement gagne à tester sa chaîne de réaction. Qui reçoit le premier signal ? Comment distingue-t-on une anomalie limitée d’un incident important ? Quels éléments sont disponibles pour apprécier les conséquences ? Comment conserve-t-on la trace des décisions ? Ces questions doivent recevoir des réponses utilisables, y compris lorsque les équipes sont sous pression.
Des clauses contractuelles qui rendent le contrôle possible
Le contrat d’externalisation IT doit traduire les exigences opérationnelles dans des engagements vérifiables. Une formulation trop générale sur la sécurité ou la disponibilité laisse souvent place à des interprétations divergentes lorsque survient un incident. Les obligations doivent être reliées au service réellement rendu et aux risques recensés.
Certains sujets méritent une attention particulière : l’accès aux informations nécessaires au contrôle, les conditions de recours à la sous-traitance, la localisation et la protection des données, la notification des incidents, les droits d’audit et les règles applicables à la fin de la relation. La stratégie de sortie mérite d’être pensée avant tout désaccord. Elle doit tenir compte du transfert des données, de la réversibilité technique, de la continuité du service et des compétences nécessaires en interne.
Il ne s’agit pas de rechercher un contrat parfait sur le papier. L’objectif est de disposer d’engagements que l’établissement peut suivre et faire respecter. Une clause non testée, inconnue des équipes opérationnelles ou impossible à documenter apporte peu de sécurité réelle.
Préparer des preuves utiles lors d’un contrôle ACPR
La qualité d’un dispositif se mesure aussi à sa capacité à produire des éléments cohérents. Une politique interne, une analyse de risques et un contrat doivent raconter la même histoire. Si le service est présenté comme critique dans une cartographie, mais suivi comme une prestation ordinaire dans les comptes rendus, l’écart devra être expliqué.
Les documents à garder accessibles peuvent inclure l’évaluation préalable du prestataire, la description du service, les décisions de gouvernance, les résultats des revues, les incidents recensés, les plans d’action et les exercices de continuité. Leur valeur dépend moins de leur volume que de leur actualisation et de leur cohérence avec le fonctionnement observé.
La vigilance de l’ACPR sur l’externalisation IT invite donc à adopter une discipline durable. L’établissement doit rester en mesure de comprendre ce qu’il délègue, de contrôler ce qui est exécuté et de réagir si le service ne répond plus aux attentes prévues.
Une banque peut-elle confier la gestion d’un incident TIC à un prestataire ?
Elle peut confier certaines tâches opérationnelles, mais elle doit conserver la maîtrise de ses obligations et la capacité de superviser le processus. L’externalisation ne fait pas disparaître la responsabilité de l’établissement face à l’incident.
Quels risques faut-il examiner avant une externalisation IT ?
Il faut notamment examiner l’importance du service, la sensibilité des données, les dépendances techniques, le recours éventuel à des sous-traitants, les conséquences d’une interruption et les possibilités de remplacer le prestataire.
Pourquoi prévoir une stratégie de sortie avec un prestataire informatique ?
Une stratégie de sortie prépare la continuité du service si la relation doit cesser ou se dégrader. Elle anticipe le transfert des données, la réversibilité, les compétences à mobiliser et les délais nécessaires pour éviter une rupture brutale.
L’auteur
Consultante en gouvernance et audit des prestataires
Je conseille les établissements bancaires et assurantiels sur la gouvernance des risques et l’audit de leurs prestataires critiques, avec un focus sur la résilience opérationnelle. J’accompagne les directions conformité dans l’évaluation des dispositifs de contrôle et la préparation aux contrôles de l’ACPR.
Voir tous ses articlesVotre avis compte
Cet article vous a-t-il été utile ?
4,9sur 5303 votes
Commentaires
Soyez le premier à réagir.
