Matrice des responsables d'applications (modèle gratuit)

« Qui est responsable de cette application ? » La plupart des DSI ne savent pas répondre pour chaque ligne de leur inventaire applicatif. On le découvre en général au pire moment : pendant un incident majeur à 19 h, quand un renouvellement de licence arrive sur le mauvais bureau, ou quand un auditeur demande qui répond d'un système qui traite des données clients. Le nom inscrit dans le tableur est celui d'un chef de projet parti il y a deux ans, ou « l'équipe ERP », qui n'est pas une personne. Ce guide propose une méthode simple et un modèle gratuit pour y remédier : responsable métier, responsable informatique, un RACI pour les huit activités qui comptent, et les règles qui gardent la matrice juste dans la durée.

TL;DR

• Chaque application a besoin de deux personnes nommées : un responsable métier (valeur, budget, accès, retrait) et un responsable informatique (exploitation, montées de version, cycle de vie), chacun avec un suppléant.
• Écrivez qui est Réalisateur, Approbateur, Consulté et Informé pour huit activités récurrentes, de l'évolution fonctionnelle au décommissionnement : c'est là que la responsabilité est vraiment mise à l'épreuve.
• Une personne par case, jamais une équipe ; une revue par an et à chaque départ.
• Repérez les applications orphelines avec des signaux simples : responsable parti, nom d'équipe au lieu d'une personne, contrat reconduit sans signature.
• Téléchargez la matrice des responsables d'applications (XLSX, aussi en CSV).

Pourquoi le responsable est-il le champ le moins bien documenté de la cartographie applicative ?

Le responsable est mal documenté parce que personne n'en a besoin le jour de la mise en service, et que tout le monde en a besoin le jour où quelque chose casse. À la mise en production, le chef de projet est l'interlocuteur évident ; personne n'écrit qui reprend le flambeau quand l'équipe projet se disperse. Les noms se périment ensuite à chaque réorganisation, départ ou mobilité, alors que le reste de la fiche reste à peu près juste.

Le coût apparaît à trois endroits :

• Des incidents sans interlocuteur. Le support sait que l'application est tombée, mais pas qui peut décider d'un contournement, accepter un mode dégradé ou activer l'escalade chez l'éditeur.
• Des décisions de rationalisation bloquées. On ne retire, ne fusionne ni ne migre une application si personne n'a autorité pour dire oui. Dans une évaluation TIME du portefeuille applicatif, les verdicts « Éliminer » sans responsable restent des années sur les slides.
• Des audits qui tournent à l'archéologie. NIS2 (article 21 de la directive (UE) 2022/2555) et DORA (règlement (UE) 2022/2554, supervisé en France notamment par l'ACPR) supposent qu'une organisation connaît ses actifs, leurs dépendances et qui en est responsable. Une matrice des responsables ne vous rend pas conforme à elle seule, mais c'est un travail préparatoire utile que les auditeurs s'attendent à trouver. Voir nos guides NIS2 et DORA.

Les PME et ETI (de 50 à 5 000 salariés environ) sont souvent les plus exposées : trop d'applications pour que chacun sache tout, trop peu de monde pour une équipe dédiée au portefeuille.

Responsable métier, responsable informatique, contact technique : qui fait quoi ?

Le responsable métier répond de ce que l'application apporte à l'organisation ; le responsable informatique répond de son fonctionnement ; le contact technique est celui qu'on appelle pour la réparer. Confondre ces trois rôles est la première cause d'échec des matrices de responsabilité : un développeur est inscrit comme « propriétaire » et on attend ensuite de lui qu'il valide un budget, ou un directeur commercial est inscrit et reçoit l'alerte d'expiration d'un certificat.

Trois remarques pratiques :

• Le responsable métier n'est pas l'utilisateur principal. C'est la personne qui a autorité sur le budget et le périmètre, en général un directeur ou responsable de service. L'utilisateur clé figure comme contact, pas comme responsable.
• Le responsable informatique est une personne, pas « l'équipe infra ». Dans une petite DSI, la même personne peut être responsable de vingt applications ; c'est acceptable tant que c'est écrit.
• Pour un SaaS, l'éditeur n'est jamais le responsable. Il exploite la plateforme ; quelqu'un chez vous reste responsable du paramétrage, des accès et du contrat.

À quoi ressemble un RACI pour les 8 activités clés d'une application ?

Un RACI indique, pour chaque activité récurrente, qui réalise (R), qui approuve et a le dernier mot (A, un seul par activité), qui est consulté avant (C) et qui est informé après (I). La responsabilité ne devient réelle que lorsqu'une activité la met à l'épreuve ; voici les huit qui reviennent dans presque tous les portefeuilles :

Comment le lire et l'adapter :

• Un seul A par ligne, toujours. Deux approbateurs, c'est aucun. Si responsable métier et responsable informatique revendiquent tous deux la décision sur une montée de version, tranchez maintenant, pas pendant la montée de version.
• Le RSSI passe de I à C quand l'incident majeur est un incident de sécurité.
• La revue des accès est une décision métier. La DSI attribue les droits, mais seul le responsable métier peut dire si une personne doit encore les avoir. C'est la ligne que les auditeurs regardent en premier.
• Le décommissionnement a deux R. Le responsable informatique planifie, l'équipe technique exécute ; le responsable métier décide. Notre checklist de décommissionnement (dépendances d'abord) détaille chaque phase.

Cette grille est un point de départ, pas une norme. Si vous avez un DPO, ajoutez une colonne pour l'archivage et les accès ; si un comité de pilotage SI valide tous les contrats, c'est lui qui porte le A du renouvellement. Notre article sur la gouvernance IT des PME en croissance présente des exemples de RACI à l'échelle de l'organisation (achats, incidents de sécurité, budget).

Que contient le modèle de matrice des responsables ?

La matrice comporte une ligne par application et une colonne par responsabilité, plus une date de revue. Le modèle gratuit a deux onglets : la matrice elle-même et le RACI ci-dessus, pré-rempli pour que vous n'ayez qu'à l'ajuster.

Les colonnes de la matrice :

Téléchargez-la ici : matrice des responsables d'applications (XLSX) ou CSV. Les lignes d'exemple (un CRM, une application de paie, un WMS) sont fictives ; remplacez-les par votre propre inventaire. Si vous n'avez pas encore d'inventaire, commencez par un référentiel unique de vos applications.

Faites-le à la main avec le modèle — ou laissez UrbaHive le tenir à jour avec le reste de votre cartographie. Plan gratuit : 1 utilisateur, 25 applications, sans carte bancaire.

Quelles règles gardent la matrice vivante ?

Une matrice reste juste quand le changement de responsable fait partie des arrivées, mobilités et départs, pas d'un grand ménage annuel. La plupart des matrices sont exactes le jour où on les remplit et fausses six mois plus tard. Quatre règles l'évitent.

1. Une personne nommée par case, jamais une équipe. « Équipe ERP » ou « support-si@ » ne se joignent pas à 19 h et ne valident pas un budget. Si la responsabilité est réellement partagée, nommez celui qui arbitre.
2. Un suppléant pour chaque responsable. Congés et arrêts maladie ne sont pas des exceptions, ce sont des certitudes. Le suppléant est le premier nom à appeler en l'absence du responsable, et son successeur naturel s'il part.
3. Une revue annuelle, planifiée. Envoyez une fois par an à chaque responsable la liste de ses applications et demandez un oui ou une correction. Les applications critiques peuvent être revues tous les six mois. Notez la date : une ligne non confirmée depuis plus de 12 mois est un signal d'alerte.
4. Une mise à jour à chaque départ et à chaque changement de poste. Ajoutez « transfert des responsabilités applicatives » à la checklist de départ RH et au processus de mobilité interne. Cette seule règle évite la plupart des orphelines.

Une habitude aide beaucoup : faire de « responsable confirmé » un préalable à tout projet, renouvellement ou montée de version. Une responsabilité vérifiée au moment des décisions reste à jour.

Comment repérer les applications orphelines ?

Une application orpheline est une application sur laquelle personne ne peut, aujourd'hui, prendre de décision. Elle apparaît rarement comme une case vide ; elle se cache derrière un nom qui ne signifie plus rien. Les signaux à chercher :

Les orphelines recoupent souvent le shadow IT : une application achetée par un service sur une carte bancaire a des utilisateurs, mais rarement un responsable au sens ci-dessus. Quand aucun responsable ne peut être trouvé, c'est un indice fort qu'il faut la retirer ; traitez-la comme candidate lors de la prochaine revue du portefeuille.

Le même risque existe sur les processus métier : un processus sans responsable ou reposant sur une seule personne est traité dans notre article sur les risques opérationnels et le bus factor. Applications et processus tombent ensemble, d'où l'intérêt de les relier.

Quand un tableur ne suffit-il plus ?

Un tableur suffit pour remplir la matrice la première fois ; il ne suffit plus quand il faut la tenir à jour et la relier au reste du SI. Les limites arrivent vite : plusieurs versions circulent par e-mail, personne ne sait laquelle fait foi, et la matrice ne sait rien des flux, des serveurs ni des processus. Quand un responsable part, vous pouvez changer son nom, mais pas voir en un clic ce qui dépendait aussi de lui. Nous détaillons ces limites dans les alternatives à Excel pour la cartographie SI.

Voici comment UrbaHive gère les responsabilités, dit précisément pour que vous sachiez ce qu'il fait et ne fait pas :

• Chaque fiche application a un responsable et des contacts supplémentaires. Les personnes peuvent être des membres avec un compte ou des contacts sans compte, internes ou externes : l'ingénieur support de l'éditeur peut figurer sans licence. Une pratique courante consiste à mettre le responsable métier comme responsable et à ajouter le responsable informatique et les suppléants comme contacts ; si vous voulez distinguer métier et IT dans un champ dédié, un champ personnalisé peut le porter.
• Le RACI est porté par les étapes de processus, pas par les applications. Dans l'éditeur de processus, chaque étape porte ses acteurs RACI et les applications qu'elle utilise (principale, d'appui ou source de données). Le RACI applicatif de cet article reste dans le modèle ; pour l'avoir dans l'outil, vous pouvez modéliser une activité récurrente comme « Incident majeur » sous forme de processus dont les étapes portent le RACI. Voir comment lier processus métier et cartographie applicative.
• Capacités et processus ont aussi un responsable. Les processus sans responsable ou non revus depuis 12 mois sont signalés automatiquement ; ce signal existe sur les processus, pas sur les applications.
• L'analyse d'impact part d'une personne. Lancée depuis quelqu'un qui s'en va, elle montre les objets directement liés à cette personne, sur un niveau en amont et en aval, répartis sur cinq couches (technique, applicative, fonctionnelle, métier, personnes). Elle ne suit pas les flux d'application en application. Voir l'analyse d'impact.
• Le départ d'un membre transfère ce qu'il possédait. Quand un membre quitte l'organisation, ce dont il était propriétaire est transmis à quelqu'un d'autre au lieu de pointer vers un nom vide.
• Le journal d'audit enregistre chaque modification avec les valeurs avant et après : vous voyez quand un responsable a changé et qui l'a changé. Il se consulte dans l'application, il n'est pas exportable.
• Les rôles s'appliquent à toute l'organisation. Owner, Editor, Member et Viewer déterminent qui peut modifier la cartographie ; ce n'est pas la même chose qu'être responsable d'une application.

Il n'y a pas d'import CSV ou Excel. Pour charger le modèle, saisissez les fiches à la main, ou demandez à un assistant IA connecté via le connecteur MCP (avec le droit d'écriture activé) de lire votre fichier rempli et de créer les fiches. Une fois vos applications en place, un assistant en lecture seule peut aussi répondre à « quelles applications n'ont pas de responsable ? » pour votre prochaine revue.

UrbaHive est conçu pour les PME et ETI, de 50 à 5 000 salariés ; la prise en main se fait en quelques heures, et l'interface existe en français et en anglais. Le plan gratuit couvre 1 utilisateur et 25 applications avec toutes les fonctionnalités ; voir la cartographie applicative et les tarifs pour les équipes.

Questions fréquentes

Quelle différence entre un responsable d'application et un product owner ?

Un product owner, dans une équipe agile, gère le backlog d'un produit en développement actif et priorise ce que l'équipe construit ensuite. Un responsable d'application répond de l'application sur toute sa vie, y compris quand plus personne ne la développe. Pour un produit interne en cours de développement, la même personne peut tenir les deux rôles ; pour un SaaS ou un progiciel stable, il y a un responsable d'application et, en général, pas de product owner du tout.

Chaque application doit-elle avoir un responsable métier ?

Oui, à de rares exceptions près. Les composants purement techniques (outil de supervision, système de sauvegarde) peuvent avoir la DSI comme responsable métier, en la personne du DSI ou d'un de ses adjoints. Pour tout ce que les utilisateurs manipulent, le responsable métier est le seul à pouvoir décider des accès, des priorités et du retrait. Une application pour laquelle on ne trouve aucun responsable métier est une sérieuse candidate au retrait.

À quelle fréquence revoir les responsables d'applications ?

Une fois par an pour tout le portefeuille, tous les six mois pour les applications critiques, et immédiatement à chaque départ ou changement de poste. C'est la mise à jour au fil des événements qui garde la matrice exacte entre deux revues.

Que faire si personne ne veut être responsable d'une application ?

Remontez au comité de pilotage SI, qui désigne un responsable (en général le directeur du service qui l'utilise le plus) ou inscrit l'application sur la liste des retraits. Une responsabilité imposée avec un périmètre clair et un suppléant est bien mieux acceptée qu'une responsabilité sans limites.

Lancez votre matrice des responsables

Téléchargez le modèle de matrice des responsables d'applications, remplissez-le cette semaine pour vos 20 applications principales, et envoyez à chaque responsable sa liste pour confirmation. Quand vous voudrez que les responsabilités restent reliées aux flux, aux serveurs et aux processus, créez votre compte UrbaHive gratuit : 1 utilisateur, 25 applications, sans carte bancaire. Pour garder votre documentation à jour, lisez aussi documentation d'architecture vivante.