Un système d’information mal cartographié perd sa capacité d’évolution. On empile des briques, on multiplie les adhérences, et tout semble à peu près fonctionner tant qu’on ajoute simplement des fonctionnalités. Mais au moment d’une refonte majeure — migration cloud, rationalisation post-fusion, changement de socle technologique — la machine s’enraye. On découvre alors que le SI, sans carte ni rangement, ressemble plus à un grenier encombré qu’à un patrimoine maîtrisé.
👉 J’ai déjà écrit sur la cartographie du SI et sur les applications. Cet article est le chaînon suivant : comment donner une nomenclature à ce patrimoine.
Inventorier ne suffit pas
En général, quand je fais la découverte d’un système d’information, cela ressemble souvent au schéma ci-dessous en le multipliant par 10 ou plus. La complexité peut devenir vite redoutable !
La découverte du SI n’est pas forcément immédiate car elle nécessite d’avoir un inventaire applicatif ou de le faire s’il n’existe pas. Parfois, je trouve plusieurs inventaires applicatifs émis par plusieurs sources. Bien sûr, ils ne sont pas cohérents entre eux et la corrélation entre les items demande une certaine dose d’intuition !
Cependant, même si cette étape est nécessaire, elle ne suffit pas pour pouvoir tracer des trajectoires d’évolution du SI. Il faut pouvoir relier le SI à l’organisation afin que l’organisation comprenne comment se mobiliser pour étendre, changer et maintenir le SI. Cela paraît évident … et pourtant ! Il arrive souvent que des parties du SI soient à personne ou à plusieurs. Ces situations créent souvent des frictions.
Nous avons besoin de créer un point de vue sur le patrimoine applicatif pour embarquer l’organisation. Afin de simplifier le schéma ci-dessous, nous pouvons regrouper les éléments en agrégat. Idéalement le regroupement a une signification pour le métier (nommé par des termes métier) et pour l’organisation (aligné sur la structure organisationnelle).
La représentation peut ensuite être simplifiée en ne conservant que les agrégats. On peut envisager de les ranger dans une Business Capabilité Map (BCM) ou dans une représentation visuelle type tableau des éléments périodique !
Les applications comme boîtes de rangement
Pour cartographier, il faut doc ranger. Et ce qu’on range dans le SI, ce sont des applications.
L’application devient la boîte de référence : elle regroupe des fonctions, des données, des flux, et c’est sur elle que l’on raisonne pour décider si on conserve, remplace, modernise ou externalise.
Pourquoi ne pas utiliser l’unité de déploiement pour clé de rangement ? Avec le temps, l’unité de déploiement est devenue de plus en plus petite. On peut citer les architectures en micro-service ou en micro-frontend. Les SI deviennent ainsi découpés très finement. Il n’est pas rare de trouver plus de 2000 composants pour un SI d’une entreprise moyenne. Il est évident que travailler à cette échelle est très complexe et que l’alternative qui consiste à raisonner plutôt sur une centaine d’application est pragmatique.
Encore faut-il que cette boîte ait une identité stable. Sinon, on se retrouve avec une application qui change de nom selon les projets, qui se fond dans un programme puis ressurgit ailleurs, ou qui prend le nom du progiciel sur lequel elle est bâtie. Bref : impossible de suivre son histoire.
Le code applicatif : une identité stable
La réponse, c’est le code applicatif : une clé unique et durable, qui traverse tout le cycle de vie de l’application.
- Le nom peut changer (souvent pour des raisons de communication), le code reste.
- C’est ce code qui devient le label fédérateur : on le retrouve dans les workloads, les bases de données, les journaux, les rapports, les sauvegardes, les noms des machines, les flux réseau…
En systématisant la codification des assets de l’IT par rapport au code applicatif, on en tire des bénéfices à long terme :
- Le cout de possession des applications se calcule comme la consolidation des couts des assets associés au code applicatif (couts directs) et la réimputation partielle des couts des assets communs (couts indirects).
- Les assets orphelins sont un indice de ressources inutilisées ou un signalement d’un défaut organisationnel.
Relier applications et composants
Les développeurs, eux, travaillent sur des composants : des unités déployables.
Pour que la nomenclature fonctionne, chaque composant doit porter le code de l’application à laquelle il appartient. C’est ce qui permet de relier la boîte (l’application) à ses briques techniques.
En faisant du composant un élément d’une application, il ne peut appartenir qu’à une seule application. Comme une application appartient à une seule équipe fonctionnelle et est opéré par une seule équipe IT, il n’y a pas d’ambiguïté sur le cadre de responsabilité du composant.
Donner du sens : typer les composants
Tous les composants ne sont pas égaux. Pour les ranger, il faut une typologie.
De mon expérience, trois critères suffisent :
- Lieu de déploiement : chez le client, dans le SI interne ou chez un tiers.
- État : service applicatif ou base de données (persistant ou non).
- Mainteneur : interne ou tiers.
Avec ça, on obtient une règle de nommage simple :
[code applicatif]-[type composant]-[qualificatif]Un exemple de types de composants courants :
| Type de composant | Libellé | Lieu de déploiement | Etat | Mainteneur |
| app | Application mobile | client | sans | interne |
| web | Application Web | client | avec | interne |
| api | Service applicatif | SI | sans | interne |
| db | Base de données | SI | avec | interne |
| prg | Progiciel | SI | avec | tiers |
| saas | SaaS | Tiers | avec | tiers |
Encadré pratique : exemple de nomenclature
| Code applicatif | Type composant | Qualificatif | Nommage |
|---|---|---|---|
| paie | api | main | paie-api-main |
| paie | db | main | paie-db-main |
| paie | web | main | paie-web-main |
| paie | saas | studio | paie-saas-studio |
| finance | saas | sap | finance-saas-sap |
Cette discipline rejoint les pratiques de l’APM (Application Portfolio Management) décrites par MEGA, LeanIX, Ardoq : avoir une nomenclature standardisée, claire et unique est ce qui permet de comparer les applications, d’identifier les doublons, et surtout de prendre des décisions stratégiques.
APM et Product Management : un rendez-vous manqué ?
L’APM existe depuis plus d’une décennie. Il propose un cadre clair pour inventorier, évaluer et rationaliser le portefeuille applicatif. Sur le papier, l’APM devrait être incontournable — or il reste souvent cantonné aux directions architecture ou urbanisme, perçu comme une démarche “d’ingénieurs de la cartographie”.
Pourquoi ? Parce que, pendant ce temps, l’agilité et le product management ont changé le vocabulaire et les priorités. Là où l’APM range et classifie, le product management valorise, priorise et fait évoluer. On a d’un côté une logique patrimoniale et transverse, de l’autre une logique opérationnelle et orientée produit.
👉 Le paradoxe, c’est qu’il s’agit en réalité de deux faces de la même pièce : le product management gère la valeur courante, l’APM gère la soutenabilité dans le temps.
Deux flux orthogonaux : projets et patrimoine
On peut représenter le SI comme traversé par deux flux :
- Les projets : financés, pilotés, visibles. Ils incarnent “l’argent bien dépensé”, car ils créent des nouveautés.
- Le patrimoine : maintenance, mises à jour, obsolescence. Il incarne “la dépense forcée”, qu’on subit plus qu’on ne la choisit.
Historiquement, l’organisation a séparé les deux, créant une fracture :
- le projet est glorifié,
- le patrimoine est toléré.
L’agilité a tenté de dépasser cette contradiction en fusionnant projet et patrimoine dans la même unité : le produit. Le product management va encore plus loin en donnant une équipe, un budget et une feuille de route à chaque produit.
La limite : les programmes transverses
Mais la fusion n’est pas toujours possible. Lorsqu’on conduit un programme transverse (par exemple : rationaliser tout le domaine finance, ou remplacer un progiciel de référence), on sort du périmètre d’un produit. On touche à des morceaux multiples du patrimoine, qui n’ont pas été pensés pour évoluer ensemble.
Et c’est là que l’APM redevient critique :
- il donne la vision transverse,
- il révèle les doublons et les adhérences,
- il permet d’arbitrer rationnellement au-delà du périmètre produit.
En ce sens, l’APM ne s’oppose pas au product management : il l’encadre et le complète.
Conclusion : ranger pour évoluer
Un patrimoine applicatif, c’est comme une bibliothèque. Tant que les livres n’ont pas de code et qu’ils ne sont pas rangés dans des catégories claires, on peut toujours lire, mais on ne retrouve rien et on ne remplace rien sans douleur.
Avec un code applicatif unique et une nomenclature simple, on passe d’un grenier en désordre à une bibliothèque organisée. Et surtout, on redonne au SI ce qui lui manque le plus souvent : sa capacité d’évolution.
👉 Références :