ArchiLU, page principale
Documentation

Registre des prestataires TIC et de la sous-traitance : le tenir à jour depuis l’architecture

Un registre des prestataires TIC sert s’il reste exact et interrogeable. Tenu dans un tableur, il dérive dès qu’une application ou un prestataire change. Dans ArchiLU, le registre d’informations DORA se produit à partir de la chaîne des fonctions, des applications, des prestataires et des contrats ; l’entité reste responsable de sa complétude.

Mis à jour le

Un registre exigé, rarement tenu à jour

Une entité régulée de l’Union européenne tient une forme de registre de ses prestataires TIC et de ses arrangements de sous-traitance. DORA en fait un registre d’informations sur les accords contractuels portant sur des services TIC fournis par des prestataires tiers. La CSSF porte des attentes de documentation de la sous-traitance pour les entités qu’elle supervise. Pour les entités essentielles et importantes, NIS2 ajoute la sécurité de la chaîne d’approvisionnement.

Produire le registre une fois est rarement le plus difficile. Il faut ensuite le garder exact : une application est retirée, un prestataire change, un sous-traitant apparaît, une fonction est reclassée. Dans un tableur, ces changements attendent la mise à jour trimestrielle de quelqu’un.

Ce texte aide à la documentation ; il ne constitue pas un conseil juridique. Le texte exact et son application à votre entité relèvent de votre fonction conformité et d’un conseil qualifié.

Pourquoi un registre tenu dans un tableur dérive

Le tableur recopie des faits qui vivent ailleurs : l’inventaire applicatif, les contrats, les niveaux de criticité. Chaque copie peut se désynchroniser. Les relations les plus utiles, comme la fonction soutenue par un prestataire ou le sous-traitant qui intervient derrière lui, finissent en texte libre, impossible à compter ou à rapprocher.

Dans un référentiel, le registre s’appuie sur les objets qui portent ces faits. La fonction pointe vers ses applications, l’application vers ses services TIC, le service vers son prestataire et son contrat. Quand le prestataire d’une application change, la chaîne, l’analyse d’exposition et le registre lisent le même objet. Quelqu’un tient toujours les données à jour ; le rapprochement entre plusieurs copies disparaît.

Des fonctions critiques jusqu’aux prestataires et aux contrats

Le modèle suit la logique du règlement. Les fonctions critiques ou importantes, comme les paiements, l’entrée en relation, l’administration de fonds ou le reporting réglementaire, sont portées par des applications. Chaque application repose sur des services TIC fournis par des tiers : éditeur, hébergeur, fournisseur cloud, opérateur externalisé.

Dans ArchiLU, le catalogue des fonctions réunit leur criticité, leur responsable et les applications qui les servent. Une vue dédiée suit les relations jusqu’aux fournisseurs et distingue le fournisseur d’une application du prestataire d’un service TIC. Les contrats qui couvrent ces services apparaissent dans la chaîne. La présence d’un contrat ne suffit pas : son périmètre doit être documenté.

Le référentiel ne classe pas les fonctions à la place de l’entité et ne décide pas si un accord entre dans le périmètre du registre. Ces appréciations restent aux fonctions risques et conformité.

  • La fonction, sa criticité au sens de DORA et son responsable.
  • Les applications et les services TIC qui la soutiennent.
  • Le prestataire, ses sous-traitants, sa substituabilité et son plan de sortie.
  • Le contrat, son échéance, son renouvellement et son périmètre.

Sous-traitance en chaîne et concentration

Le prestataire de premier rang figure dans le registre. Le sous-traitant dont il dépend disparaît plus facilement d’un tableur : une note dans une cellule que personne ne relit. Les accords qui soutiennent des fonctions critiques ou importantes demandent pourtant de connaître cette chaîne.

Dans ArchiLU, la chaîne descend de la fonction critique ou importante jusqu’au sous-traitant et au contrat. L’analyse d’exposition part d’un prestataire, remonte aux fonctions qui en dépendent et calcule ses constats, dont la concentration. Chaque capacité montre son fournisseur dominant et sa part. Chaque constat mène à une demande, à un risque ou à une décision du board.

L’appréciation d’un prestataire, la position contractuelle et les notifications restent à l’entité et à ses conseils.

Produire le registre et compléter les manques

Dans ArchiLU, le registre d’informations DORA se produit comme un rapport réglementaire, à partir de la chaîne. Chaque donnée manquante part vers son responsable, qui la complète, la confirme ou assume le manque avec un motif. Chaque rapport réglementaire se fige avec son empreinte.

Les modèles du registre sont fixés par le règlement d’exécution (UE) 2024/2956. L’entité reste responsable de la complétude du registre, de la classification de ses accords et de sa remise à l’autorité compétente.

L’auditeur entre par sa mission et lit la même chaîne en lecture seule, bornée à son périmètre et à sa période. Sa mission s’ouvre sur un dossier de preuves en huit parties, figé avec ses empreintes.

Hébergement et lecture partagée

Le registre de vos fonctions critiques et des tiers qui les soutiennent indique vos points les plus exposés. Chaque organisation a son instance ArchiLU dédiée, hébergée dans l’Union européenne ; un déploiement chez le client est proposé en option, sur devis.

Risques, conformité, achats, IT et architecture travaillent sur les mêmes objets et ouvrent leurs fiches depuis la vue de la chaîne. Les offres comptent des utilisateurs illimités, lecteurs compris.

Dans ArchiLU

Partez de la fonction. Retrouvez le fournisseur.

Dans ArchiLU : Paiements → Moteur de paiements → Maelis Paiements. Quatre écrans du même logiciel, reliés par les mêmes objets.

Vue réelle de la chaîne de dépendances Paiements dans ArchiLU, avec applications, services TIC, fournisseurs et maillons à compléter.

Voyez la dépendance. Repérez ce qui manque.

La vue dédiée relie Paiements à son application, aux services TIC et aux fournisseurs documentés. Les contrats apparaissent quand ils couvrent ces services ; les liens manquants sont signalés, objet par objet.

Questions fréquentes

ArchiLU produit-il le registre d’informations DORA ?
Oui, comme un rapport réglementaire produit à partir de la chaîne des fonctions, des applications, des services TIC, des prestataires et des contrats. Chaque donnée manquante part vers son responsable. L’entité reste responsable de la complétude du registre, de la classification des accords et de sa remise à l’autorité compétente.
Pourquoi tenir le registre dans un référentiel d’architecture ?
Le registre décrit des objets qui changent : applications, prestataires, contrats, fonctions. Dans le référentiel, leurs responsables tiennent ces objets. Quand l’un change, la chaîne et le registre lisent la même donnée, sans copie à rapprocher.
Comment ce registre se relie-t-il à DORA, à NIS2 et à la CSSF ?
DORA demande un registre d’informations sur les accords de services TIC. NIS2 porte des exigences de sécurité de la chaîne d’approvisionnement pour les entités essentielles et importantes. La CSSF porte des attentes de documentation de la sous-traitance pour les entités qu’elle supervise. Les trois reposent sur la même chaîne, de la fonction critique aux tiers ; le détail juridique relève d’un conseil qualifié.
Le modèle montre-t-il les sous-traitants et la concentration ?
Oui. La chaîne descend de la fonction critique ou importante jusqu’au sous-traitant et au contrat. L’analyse d’exposition calcule la concentration, et chaque capacité montre son fournisseur dominant et sa part. L’appréciation de chaque prestataire reste à l’entité.