Une application devient obsolète lorsque son support, sa technologie, son infrastructure, ses compétences ou sa capacité d’évolution ne répondent plus au niveau de service et de risque attendu.
DSI, Responsables IT, Architectes SI, Responsables applicatifs.
Ouvrir l’outil de cartographieUne fin de support, une version non maintenue, des composants incompatibles, des correctifs impossibles ou des incidents répétés sont des signaux forts. Ajoutez les délais de changement, la difficulté d’intégration et la dépendance à une personne ou un prestataire.
Un système stable peut être obsolète s’il ne peut plus être restauré, sécurisé ou adapté.
Documentez éditeur, version, dates de support, contrat, accès au code, environnements, tests et capacité de déploiement. Vérifiez que les sauvegardes et procédures de restauration couvrent réellement l’ensemble nécessaire.
Distinguez support officiel, support interne et simple tolérance d’un système ancien.
Recensez les personnes capables d’exploiter, corriger et faire évoluer l’application. Mesurez le temps de remplacement, la documentation et les possibilités de réversibilité.
Une compétence rare ne condamne pas automatiquement l’application, mais elle exige un plan de réduction de dépendance.
Priorisez les applications à la fois critiques et fortement obsolètes. Une application peu critique peut être tolérée ou retirée progressivement ; une application critique exige un traitement et des mesures compensatoires rapides.
Rendez visibles l’impact, le coût de maintien, le coût de remplacement et le risque de ne rien faire.
Les options incluent mise à niveau, refonte, remplacement, encapsulation, réduction de périmètre, mutualisation ou retrait. Chaque scénario doit préciser dépendances, migration de données, continuité et capacité de retour.
Suivez une date cible, un propriétaire et les risques résiduels jusqu’à la fin effective de l’ancien système.
Non. L’âge est un indice ; le support, la sécurité, la maintenabilité et l’adéquation au besoin déterminent l’obsolescence réelle.
Utilisez plusieurs dimensions avec preuves, puis une classe lisible plutôt qu’un score opaque.
Pas toujours. La décision dépend de la criticité, du risque, du coût et des mesures compensatoires disponibles.
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