02.02 · Piloter
Rationaliser son portefeuille applicatif
La rationalisation est l’exercice le plus ambitieux d’une DSI — et celui qui échoue le plus souvent. Pas par incompétence, par excès d’ambition. Voici comment la rendre tenable.
Pourquoi 70 % des rationalisations échouent
Le scénario type : une DSI lance un programme de rationalisation pour sortir trente applications en dix-huit mois. Au bout de neuf mois, on en a sorti quatre. Au bout de dix-huit, six. Le programme s’éteint sans bilan officiel. Cette histoire — racontée chaque année dans la moitié des DSI installées — masque une cause structurelle simple : la rationalisation est pensée comme un projet alors qu’elle est unchangement de processus.
La grille TIME : quatre destinations possibles
La méthode TIME (Tolerate, Invest, Migrate, Eliminate), popularisée par Gartner, reste l’outil le plus simple pour classer un portefeuille. Chaque application doit se retrouver dans une seule case — pas dans deux, jamais dans aucune.
Tolerate
Valeur fonctionnelle correcte, qualité technique acceptable. À maintenir sans investissement majeur.
Invest
Valeur fonctionnelle forte mais qualité technique à améliorer. Cible de modernisation prioritaire.
Migrate
Valeur fonctionnelle forte mais technologie en fin de vie. Replatformer vers une alternative moderne.
Eliminate
Faible valeur fonctionnelle ou doublon. À retirer du portefeuille — c’est ici que la rationalisation se joue.
La méthode 5R, parfois étendue en 8R, propose un découpage plus fin pour les transformations cloud. Pour l’exercice de rationalisation applicative pure, TIME suffit — et sa simplicité est une force.
La règle des trois cohortes
Le piège classique de la rationalisation : vouloir tout traiter en même temps. Une démarche tenable s’organise en trois cohortes successives, chacune ciblant un type d’application différent.
Cohorte 1 — les doublons évidents (3 à 6 mois). Deux outils pour la même fonction. Le moins utilisé sort, le plus utilisé absorbe les utilisateurs. Gain rapide, opposition faible, sert de preuve de capacité pour la suite.
Cohorte 2 — les applications à faible usage (6 à 12 mois). Moins de 20 % d’utilisateurs actifs, pas de doublon mais valeur marginale. La décision est plus politique : il faut traiter individuellement avec chaque sponsor. La cohorte la plus instructive sur la dynamique organisationnelle.
Cohorte 3 — les remplacements stratégiques (12 à 24 mois). Applications valorisées mais obsolètes techniquement, ou silos métier à fusionner. Vrai projet d’intégration, à mener sous régime projet.
Pourquoi la sortie d’application est si difficile
Le retrait d’une application implique presque toujours trois pertes : une perte de fonctionnalité (jamais 100 % remplacée), une perte de confort utilisateur (changer d’outil coûte du temps), et une perte de données historiques (l’export n’est jamais aussi propre que l’usage en ligne). Ces trois pertes sont supportées par les utilisateurs immédiatement, alors que les gains — coût, sécurité, simplicité — sont diffus et différés. C’est cette asymétrie qui explique pourquoi les applications survivent à elles-mêmes pendant des années.
La seule réponse opérationnelle : désigner pour chaque application un Accountable de sa sortie, avec un horizon et un critère de décision. Sans cette désignation, la sortie est techniquement possible mais politiquement impossible.
Ce qu’il faut retenir
- Une rationalisation échoue parce qu’elle est pensée comme un projet. C’est un changement de processus — gouvernance avant analyse.
- La grille TIME classe simplement, et sa simplicité est une force. Toute application non classée est un risque latent.
- Trois cohortes successives, jamais en parallèle. Doublons, faible usage, remplacements stratégiques — dans cet ordre.