Une cartographie applicative est un référentiel qui relie les applications aux processus métier, aux responsables, aux données, aux technologies et aux flux. Elle permet à la DSI et aux métiers de comprendre le portefeuille applicatif, d’identifier les dépendances et les risques, puis de décider quelles applications maintenir, sécuriser, moderniser, consolider ou retirer.
DSI, Architectes SI, RSSI, Responsables applicatifs, PME et ETI.
Ouvrir l’outil de cartographieComparer l’existant aux capacités attendues et construire des scénarios de transformation cohérents.
Repérer les doublons fonctionnels, les coûts dispersés, les usages faibles et les applications sans propriétaire.
Identifier les chaînes applicatives critiques et les dépendances nécessaires au PCA et au PRA.
Mesurer les impacts d’une migration, d’un remplacement, d’une fusion ou d’une externalisation.
Une cartographie applicative décrit de manière structurée les logiciels utilisés par l’entreprise et les relations qui les unissent aux activités, aux données et à l’infrastructure. Elle ne se limite pas à un dessin : le référentiel associé conserve les attributs nécessaires pour analyser la criticité, l’obsolescence, les responsabilités, les coûts, les contrats et les décisions de cycle de vie.
La représentation peut prendre plusieurs formes complémentaires. Une vue métier montre quels processus dépendent de quelles applications. Une vue fonctionnelle met en évidence les capacités couvertes et les doublons. Une vue applicative détaille les échanges entre systèmes. Une vue technique précise les composants, hébergements et technologies. Le niveau de détail doit toujours répondre à une question de pilotage identifiable.
Cartographier le SI réduit les décisions prises à l’aveugle. Lors d’un incident, d’une migration ou d’un changement de fournisseur, la DSI doit savoir quels métiers, données, interfaces et contrats seront touchés. La cartographie facilite aussi le dialogue avec la direction en traduisant un patrimoine technique en services, risques, coûts et options compréhensibles.
Elle sert également de socle à l’urbanisation, à la cybersécurité, à la gestion des actifs, au PCA/PRA, à la conformité et au budget. Elle ne garantit toutefois ni l’exhaustivité ni la sécurité : sa valeur dépend de la qualité des données, de la validation par les propriétaires et de la fréquence de mise à jour.
Commencez par les services et processus essentiels, puis recensez les applications qui les supportent. Pour chaque élément, nommez un propriétaire métier et un responsable technique. Collectez un socle limité mais exploitable : finalité, utilisateurs, criticité, données, hébergement, éditeur, version, coût, contrat, support, interfaces, risques connus et décision envisagée.
Évitez de viser un modèle parfait dès la première campagne. Un inventaire de cinquante applications validées et maintenues apporte plus de valeur qu’un catalogue de cinq cents lignes sans responsable. Indiquez la source, la date de vérification et le niveau de confiance afin de distinguer une information confirmée d’une hypothèse à instruire.
Une application est critique lorsque son indisponibilité, la perte de ses données ou une altération de son fonctionnement provoque un impact important sur l’activité, les personnes, les obligations ou la réputation. Pour approfondir la démarche et qualifier les applications critiques, évaluez l’impact selon la durée d’interruption : quelques heures, un jour, plusieurs jours. Ajoutez la sensibilité des données, le nombre d’utilisateurs, les dépendances aval et la disponibilité d’un mode dégradé.
Ne confondez pas criticité métier et fragilité technique. Une application peut être très critique mais bien maîtrisée ; une autre peu critique peut présenter une obsolescence sévère. Le croisement impact, probabilité, récupérabilité et qualité des contrôles permet de définir les priorités de traitement sans transformer toute l’inventaire en urgence absolue.
Pour chaque interface, documentez la source, la destination, les données échangées, le sens, la fréquence, le protocole, le mécanisme d’authentification, le responsable et la procédure en cas d’échec. Commencez par les applications critiques et les flux indispensables à la clôture, à la production, à la facturation, à la paie ou à la relation client.
Représentez les chaînes de dépendance plutôt que des liens isolés. Un portail peut dépendre d’un fournisseur d’identité, d’une API, d’un référentiel client et d’un prestataire cloud : il est alors utile d’évaluer les dépendances aux prestataires. Cette chaîne révèle les points uniques de défaillance et les composants dont la reprise doit précéder celle des autres. Validez ces relations avec les équipes qui exploitent réellement les échanges.
L’obsolescence ne concerne pas seulement la version du logiciel. Examinez la fin de support, la disponibilité des correctifs, la compatibilité avec l’architecture cible, la maintenabilité du code, les compétences internes, la dépendance à un prestataire, la qualité de la documentation et la capacité à restaurer le service. Une dette invisible peut devenir critique au départ d’une personne clé.
Utilisez une échelle simple et justifiée, par exemple maîtrisé, sous surveillance, à traiter et critique. Associez chaque classement à une preuve et à une date de révision. La note n’est pas une décision automatique : elle sert à comparer les risques et à préparer des scénarios de maintien, de sécurisation, de modernisation ou de remplacement.
La démarche consiste à rationaliser le portefeuille applicatif pour chercher à réduire la complexité sans dégrader les capacités métier. Regroupez les applications par fonctions couvertes, puis comparez valeur d’usage, coût complet, risques, qualité des données, intégration, expérience utilisateur et trajectoire éditeur. Les doublons apparents peuvent répondre à des contraintes différentes ; l’analyse doit donc précéder toute décision de retrait.
Pour chaque application, formalisez une orientation : investir, maintenir, tolérer, consolider, remplacer ou retirer. Chiffrez les coûts de transition, de migration des données, d’accompagnement et de résiliation, pas seulement les licences économisées. Vérifiez aussi les dépendances : supprimer une application sans traiter ses interfaces déplace souvent la complexité au lieu de la réduire.
Définissez un responsable du référentiel, mais répartissez la validation. Les propriétaires métier confirment la finalité et la criticité ; les responsables applicatifs vérifient technologies et interfaces ; les achats contrôlent contrats et coûts ; le RSSI complète les risques ; les équipes données qualifient les informations sensibles. Une revue périodique et un contrôle lors de chaque projet évitent l’obsolescence du référentiel.
Suivez quelques indicateurs : proportion d’applications avec propriétaire, données validées récemment, applications hors support, interfaces non documentées, coûts sans affectation, risques sans plan d’action et décisions de retrait en retard. La cartographie devient alors un outil de pilotage continu plutôt qu’un livrable figé produit uniquement pour un audit.
Une PME peut commencer par un atelier de deux heures avec les métiers pour lister les services essentiels et leurs outils. La DSI complète ensuite les responsables, fournisseurs, données, sauvegardes et dépendances, puis fait valider les dix applications les plus critiques. Un premier comité décide de trois actions : tester une restauration, sécuriser une interface fragile et préparer le remplacement d’un logiciel hors support.
Voici un exemple d’inventaire applicatif illustratif permettant de structurer le référentiel initial :
Commencez par les applications qui soutiennent les processus critiques, puis décrivez leur finalité, propriétaire, utilisateurs, données, hébergement, interfaces et niveau de criticité. Faites valider ces informations par les métiers et les équipes techniques. Une cartographie utile répond à une décision précise — continuité, rationalisation, transformation ou sécurité — et reste assez simple pour être mise à jour.
À lire aussi : Méthode de cartographie applicative
Collectez au minimum le nom, la finalité métier, le propriétaire, le responsable technique, les populations utilisatrices, le fournisseur, le mode d’hébergement, les données sensibles, les interfaces, les coûts, le cycle de vie et la criticité. Ajoutez seulement les champs nécessaires aux décisions visées. Un référentiel trop ambitieux devient vite incomplet ; mieux vaut un noyau fiable, enrichi par étapes.
Évaluez l’impact d’une indisponibilité sur les opérations, les clients, les obligations, la finance et la réputation, puis tenez compte de la durée maximale tolérable. Croisez cette gravité avec les dépendances, les solutions de contournement et les besoins de confidentialité ou d’intégrité. Faites valider le classement par le propriétaire métier : la DSI ne peut pas décider seule de l’impact opérationnel.
À lire aussi : Évaluer la criticité applicative
La cartographie applicative décrit le patrimoine : applications, rôles, propriétaires, technologies et cycle de vie. La cartographie des flux représente les échanges entre ces composants, avec données, sens, fréquence, protocole et dépendances. Les deux vues se complètent : l’inventaire dit ce qui existe, tandis que les flux montrent comment une panne, une évolution ou une compromission peut se propager.
À lire aussi : Cartographier les flux SI
Attribuez un propriétaire à chaque fiche et intégrez la mise à jour aux événements existants : lancement de projet, mise en production, renouvellement de contrat, revue de risque et décommissionnement. Organisez une revue périodique des applications critiques et mesurez les fiches sans responsable ou date de validation. L’outil importe moins que la gouvernance : une cartographie vivante doit faire partie des processus de changement.
La DSI anime le référentiel et garantit la cohérence du modèle, mais la responsabilité est partagée. Le propriétaire métier valide la finalité, la criticité et les utilisateurs ; le responsable technique renseigne architecture, interfaces et cycle de vie ; achats ou finance contribuent aux contrats et coûts. Un responsable de données doit arbitrer les écarts et suivre la qualité globale.
Traitez les SaaS comme les autres applications, en ajoutant l’éditeur, la localisation des données, l’authentification, les administrateurs, les sous-traitants, les interfaces, l’export et les conditions de réversibilité. Recherchez aussi le shadow IT auprès des métiers et dans les dépenses. Le navigateur masque parfois la dépendance réelle : une application SaaS peut être critique malgré l’absence d’infrastructure interne.
Regroupez les applications par capacité métier, puis comparez redondance fonctionnelle, coûts, satisfaction, risque, obsolescence et effort de migration. Identifiez les solutions à conserver, consolider, remplacer ou retirer, sans décider sur le seul coût de licence. La cartographie révèle les dépendances et permet de séquencer la rationalisation afin d’éviter qu’une suppression ne casse un flux ou un processus critique.
Ajoutez des indicateurs vérifiables : fin de support, versions, compétences disponibles, incidents, vulnérabilités, maintenabilité, dépendances et capacité de mise à niveau. Distinguez l’âge de l’obsolescence réelle : une solution ancienne mais supportée peut être moins risquée qu’un composant récent mal maîtrisé. Reliez chaque constat à un impact et à une option de traitement pour alimenter la feuille de route.
À lire aussi : Analyser l’obsolescence applicative
Associez chaque processus critique aux applications, données, interfaces, infrastructures et fournisseurs dont il dépend. Ajoutez les objectifs de reprise, les solutions de contournement, les sauvegardes et les responsables. Cette chaîne permet de vérifier que les priorités techniques correspondent aux besoins métiers et de concevoir des scénarios de test réalistes. Une application critique isolée de ses dépendances donne une vision incomplète du risque.
À lire aussi : Construire un PCA/PRA DSI
Ce sujet fait partie des fiches pratiques du livre Pilotegest consacré au pilotage des systèmes d’information. L’article apporte une méthode originale en texte ; la planche complète reste réservée à l’ouvrage.
Découvrir les 40 fiches dans le livrePar Équipe Pilotegest · Dernière mise à jour : 25/08/2026