Pourquoi une cartographie applicative sans propriétaire ne sert à rien

Imaginons une situation illustrative. Le RSSI demande s’il faut isoler une application de gestion des commandes après la découverte d’un accès suspect. L’exploitation connaît le serveur, le métier utilise l’outil, les achats retrouvent un contrat et la finance paie l’abonnement. Pourtant, personne ne peut décider d’interrompre le service, d’accepter le risque ou d’engager une remise à niveau. La cartographie montre l’application et ses flux. Elle ne désigne aucun propriétaire. Elle décrit donc le système sans permettre de le gouverner.

Une carte ne décide pas

Une cartographie applicative utile ne répond pas seulement à « qu’avons-nous ? ». Elle doit permettre de savoir quel processus dépend de chaque application, quelles données elle traite, qui l’utilise, comment elle s’intègre, qui la maintient et ce qui se passe lorsqu’elle devient indisponible. Sans propriétaire, ces informations restent descriptives. Aucun acteur n’est clairement tenu d’arbitrer une évolution, une dépense, une exception de sécurité ou une fin de vie.

Le problème apparaît rarement lors de la production du schéma. Il surgit au moment d’un renouvellement SaaS, d’une vulnérabilité, d’un audit, d’une migration ERP ou d’un incident. La carte devient alors un annuaire technique que les dirigeants consultent sans pouvoir trancher.

L’orphelin applicatif fabrique de la dette

Une application orpheline n’est pas nécessairement ancienne ni mal exploitée. Elle accumule pourtant des décisions différées : habilitations jamais réexaminées, contrat reconduit faute d’arbitrage, interface non documentée, sauvegarde supposée mais non testée, journaux insuffisants, composant en fin de support ou coût réparti entre plusieurs budgets. Le risque naît moins d’un défaut isolé que de l’absence d’un responsable capable d’ordonner ces sujets.

Il faut surtout éviter de confondre exploitation et propriété. L’administrateur maintient la solution ; il ne décide pas de sa valeur pour l’entreprise. Le propriétaire métier confirme l’usage, la criticité et les niveaux de service attendus. Le propriétaire IT répond de l’exploitabilité, de l’intégration, de la sécurité technique et de la trajectoire. La responsabilité économique identifie qui arbitre licences, hébergement, prestations et renouvellement. Selon l’organisation, une même personne peut cumuler deux rôles, mais les décisions associées doivent rester explicites.

Partir des processus qui ne peuvent pas attendre

Chercher d’emblée l’exhaustivité conduit souvent à une collecte interminable. Le DSI doit commencer par les processus dont l’arrêt aurait un impact immédiat : facturer, produire, payer, livrer ou authentifier les utilisateurs. Pour chacun, l’équipe remonte les dépendances : applications, données, identités, infrastructures, flux, fournisseurs et compétences rares.

Chaque fiche reçoit ensuite un noyau minimal : propriétaires nommés, criticité justifiée, utilisateurs concernés, données principales, intégrations, support, sauvegardes, journaux disponibles, PRA, statut d’obsolescence, coût, échéance contractuelle et décision attendue. Une information inconnue n’est pas laissée vide : elle devient une anomalie à traiter, avec un responsable et une date de revue. Cette discipline transforme les trous de documentation en travail gouvernable.

Installer un circuit de décision, pas un rituel documentaire

Nommer un propriétaire dans une colonne ne suffit pas. Il faut préciser ce qu’il doit décider et quand. Une revue courte peut être déclenchée par un renouvellement, un changement majeur, une alerte de sécurité, une hausse de coût, une acquisition ou une modification de criticité. Le propriétaire métier confirme le besoin et l’impact acceptable ; l’IT propose les options et leurs risques ; le responsable économique valide l’engagement ou demande une alternative.

Quatre issues doivent être possibles : maintenir, corriger, remplacer ou retirer. Si la gouvernance ne permet que d’ajouter des commentaires, elle ne gouverne rien. L’approche exposée dans Révolution Numérique ! prend ici un sens concret : relier les choix techniques aux coûts, aux risques et aux dépendances pour obtenir un arbitrage, plutôt que perfectionner une représentation sans conséquence.

Mesurer la capacité à agir

Le nombre d’applications recensées est un indicateur de production, pas de maîtrise. Un comité de direction IT devrait plutôt suivre la part des applications critiques disposant d’un propriétaire métier et IT effectivement joignable, la part des échéances contractuelles assorties d’une décision, le nombre d’applications sans test de restauration connu, sans journalisation exploitable ou avec une fin de support non arbitrée, ainsi que le délai de traitement des anomalies de propriété.

Il faut aussi observer la qualité des décisions : combien d’exceptions de sécurité ont une durée et un acceptant identifiés ? Combien de doublons possèdent une trajectoire de convergence ? Combien d’applications critiques ont un niveau de service cohérent avec leur PRA ? Ces indicateurs évitent la fausse cible du « 100 % cartographié » tout en donnant au DSI et au RSSI une base commune pour prioriser.

Les erreurs qui neutralisent l’exercice

La première erreur consiste à désigner automatiquement l’IT comme propriétaire de tout. Le métier se décharge alors de l’utilité et de la criticité, tandis que l’IT porte des choix qu’elle ne peut légitimement rendre seule. La deuxième est d’accepter des propriétaires génériques — « Finance » ou « Infrastructure » — impossibles à convoquer lors d’un arbitrage. La troisième est de multiplier les attributs avant d’avoir sécurisé les champs décisifs.

Enfin, une cartographie centralisée mais déconnectée des achats, de l’IAM, du registre SaaS, du portefeuille projets et de la gestion des incidents se périme mécaniquement. La mise à jour doit être intégrée aux événements qui modifient réellement le parc, non dépendre d’une campagne annuelle de rattrapage.

L’arbitrage final appartient au dirigeant IT

Lorsqu’une application critique reste sans propriétaire, le DSI ne doit ni tolérer indéfiniment le vide ni imposer un arrêt aveugle. Il peut désigner un responsable provisoire, borner la période d’analyse et exiger une décision documentée : conserver avec un financement et des obligations claires, réduire l’exposition, organiser le remplacement ou préparer le retrait. Pour une application non critique, sans usage démontré ni sponsor, le coût de remise sous contrôle peut justifier une extinction préparée.

La vraie question n’est donc pas : « notre cartographie est-elle complète ? » Elle est : « pour chaque dépendance importante, savons-nous qui décide, sur quelles informations et dans quel délai ? » Tant que la réponse reste floue, la carte montre le territoire, mais personne ne tient le volant.

Pour approfondir

Ouvrage : Révolution Numérique !: Le guide pour comprendre, décider et agir dans l’entreprise numérique — Amazon

Ouvrage : DSI EN CRISE: Reprendre le contrôle de l’IT, des ERP et des grands programmes — Amazon

Consulter la référence

Consulter la référence

#GouvernanceIT #ArchitectureSI #DSI #GuyDeLussigny #TransformationNumerique