Coûts IT et risque fournisseur : une seule carte pour le budget et DORA

Deux questions, un seul inventaire

Posez deux questions à une entité régulée et vous obtenez d'ordinaire deux réponses sans rapport. « Combien coûte notre paysage applicatif ? » part chez les finances, qui ouvrent un tableur budgétaire. « De quels tiers dépendons-nous ? » part chez les risques, qui ouvrent un registre fournisseurs. Les deux réponses se construisent à partir des mêmes objets — les applications que vous exploitez et les fournisseurs derrière elles — mais elles vivent dans des fichiers distincts, possédés par des équipes distinctes, réconciliés à la main quand ils le sont.

Cette césure coûte dans les deux sens. Le directeur financier ne voit pas que l'application signalée pour renouvellement est aussi un point unique de dépendance fournisseur. Le responsable des risques ne voit pas que le fournisseur sur lequel il est surconcentré est aussi celui qui gonfle discrètement le coût de fonctionnement. Chaque équipe optimise sa propre vue et manque le geste évident qui n'apparaît que lorsque coûts et exposition fournisseur sont sur la même carte.

Cet article parle de refermer cet écart avec un seul modèle. Un référentiel d'architecture d'entreprise est, au fond, un inventaire de ce que vous exploitez et de la façon dont tout se connecte. Quand cet inventaire porte des signaux de coûts d'un côté et des liens fournisseurs de l'autre, une seule question répond aux deux équipes à la fois — et, accessoirement, produit le type de preuve qu'attend une revue pensée pour DORA.

Ce que contient vraiment une vue portefeuille applicatif

Un registre des applications EA est plus qu'une liste de noms. Chaque application peut porter des attributs qui en font quelque chose d'analysable : un propriétaire, un niveau de criticité, son hébergement, la technologie sur laquelle elle repose, les fournisseurs dont elle dépend, et des signaux de coûts. La capacité portefeuille applicatif d'ArchiLU est bâtie précisément là-dessus — santé applicative, exposition fournisseurs, empreinte technologique, signaux de coûts et candidats à la rationalisation — si bien que le registre est une surface d'analyse, pas un catalogue figé.

L'intérêt d'attacher ces attributs au même endroit, ce sont les jointures qu'ils permettent. Parce qu'une application pointe vers son fournisseur et porte son coût, vous pouvez faire pivoter le même jeu de données en vue de coûts, en vue d'exposition fournisseur ou en liste courte de rationalisation sans le reconstruire. La réserve honnête : le modèle ne vaut que par les données que vous y mettez, et les chiffres de coûts en particulier ont besoin d'une vraie source — flux financiers, contrats, décomptes de licences. Le référentiel organise et relie ces données ; il ne les invente pas.

• Registre des applications avec propriétaire, criticité et hébergement
• Liens fournisseurs et éditeurs par application
• Empreinte technologique, pour voir la prolifération de plateformes
• Signaux de coûts attachés aux mêmes objets, depuis de vraies sources
• Candidats à la rationalisation révélés par l'image combinée

Révéler concentration et exposition de licences

Le risque de concentration est difficile à voir précisément parce que chaque dépendance prise isolément paraît raisonnable. Une fonction critique sur un fournisseur cloud est une décision d'architecture sensée. Douze fonctions critiques sur le même fournisseur sont une concentration que vous n'avez peut-être pas choisie délibérément — elle s'est accumulée. La seule façon de la voir est de suivre chaque fonction critique jusqu'au fournisseur derrière elle et de compter là où les lignes convergent.

Un modèle cartographié rend ce décompte mécanique plutôt qu'archéologique. Tracez chaque fonction critique ou importante vers ses applications, chaque application vers ses fournisseurs, et les amas apparaissent : le fournisseur qui se tient derrière une part disproportionnée de ce qui compte, la plateforme devenue porteuse à votre insu. Le même modèle révèle l'exposition de licences dans l'autre sens — là où vous payez des sièges ou de la capacité que vous n'utilisez plus, et là où un seul contrat soutient plus que son prix ne le laisse croire.

Rien de tout cela n'est un verdict de conformité, et nous continuerons de le dire. La conformité DORA est appréciée par les régulateurs et les auditeurs au regard de vos mesures, pas par un graphique. Ce que le modèle vous donne, c'est de la visibilité : une vue défendable et à jour de l'endroit où dépendances et argent se concentrent, qui constitue l'entrée du travail de risque et de contrat — pas un substitut à celui-ci.

De la carte à une décision de rationalisation

La vue combinée gagne son utilité quand elle change une décision. Un candidat à la rationalisation est rarement « le plus cher » tout court — c'est l'application qui est chère, doublonnée et liée à un fournisseur sur lequel vous êtes surconcentré. Cette triangulation est invisible dans n'importe quel tableur isolé et évidente sur un modèle où coût, doublon et fournisseur reposent sur le même objet.

Le flux pratique est modeste, et c'est tout l'intérêt. Établissez une liste courte de candidats à partir de l'image combinée, vérifiez chacun face à sa criticité et à ses dépendances pour ne pas retirer quelque chose de porteur, puis consignez la décision — contexte, options, choix, justification — face aux applications concernées. La carte propose ; l'humain dispose ; le registre de décision garde la trace. C'est cette trace qui transforme une coupe de coûts ponctuelle en un acte de gouvernance documenté et reproductible.

• Liste courte là où coût, doublon et exposition fournisseur se recoupent
• Validez face à la criticité et aux dépendances avant de retirer
• Consignez la décision face aux applications concernées
• Gardez la trace pour que la revue suivante parte de la preuve, pas de la mémoire

La vue pensée pour DORA : documentation et preuve, pas garantie

Sous DORA, les entités financières régulées sont attendues pour connaître et documenter leurs dépendances IT, identifier celles qui soutiennent des fonctions critiques ou importantes, et gérer le risque tiers et de concentration. Un référentiel qui cartographie déjà applications, fonctions, fournisseurs et coûts produit cette documentation comme sous-produit de son usage, plutôt que comme une course annuelle séparée.

Nous sommes délibérés sur la limite. ArchiLU ne livre pas de bibliothèque de contrôles DORA préconstruite ni de certification, et il serait malhonnête de laisser croire le contraire. Ce qu'il offre, c'est la colonne vertébrale analytique et documentaire — le modèle à jour et connecté à partir duquel la preuve s'assemble plus vite. Traitez-le comme une aide à votre travail de risque, juridique et de sécurité, pas comme un remplacement ; l'appréciation réglementaire reste du côté des personnes et des contrats, là où elle doit être.

Pourquoi cela convient spécifiquement à une institution régulée de l'UE

Trois propriétés d'ArchiLU comptent davantage dans un contexte européen régulé que partout ailleurs. Il peut être hébergé dans l'UE ou en on-premise, si bien que la carte sensible de ce qui dépend de quoi et de ce que cela coûte ne quitte pas un périmètre que vous contrôlez. Il est disponible nativement en français et en anglais, ce qui compte quand le même modèle doit servir un comité des risques francophone et un audit anglophone. Et il est licencié pour des utilisateurs illimités plutôt que par siège, si bien que les personnes des finances, des risques et de l'architecture qui doivent toutes lire la même carte ne sont pas bridées par un nombre de sièges — pour le détail commercial, il vit sur la page des tarifs plutôt qu'ici.

La combinaison est le coin d'entrée : un référentiel hébergeable de façon souveraine et multilingue, où coûts et exposition fournisseur partagent un seul modèle. Pour situer le plus vite votre propre pratique sur les dimensions portefeuille, gouvernance et risque, l'évaluation gratuite de maturité EA note dix dimensions et renvoie un plan priorisé en une dizaine de minutes — une première étape sensée avant de décider de voir la vue portefeuille sur vos propres données lors d'une démo.