Modèle TIME (Tolérer, Investir, Migrer, Éliminer) pour les portefeuilles d'applications

La réunion de rationalisation des applications commence à 9 h. À 11 h, l'équipe a classé douze des quatre cents applications concernées. Trois de ces douze classifications ont déjà été contestées, révisées, puis de nouveau contestées. Le programme COBOL qui gère la paie n'est clairement pas à supprimer, mais faut-il le tolérer ou investir ? Le système de facturation obsolète, que tous jugent techniquement inadéquat, doit clairement être migré, mais vers quoi, et qu'adviendra-t-il des dix-sept programmes qui en dépendent ? La réunion est prévue jusqu'à midi. À midi, quelqu'un propose de la reporter à la semaine suivante. Le mois suivant, l'initiative a discrètement cessé de produire des résultats.

Le modèle TIME de Gartner est le cadre de gestion de portefeuille d'applications le plus répandu dans les DSI. Il classe chaque application du portefeuille selon quatre dispositions : Tolérer, Investir, Migrer, Supprimer, en s'appuyant sur deux critères : la valeur métier et l'adéquation technique. Ce cadre est logiquement solide, largement applicable et cité comme méthodologie recommandée par le guide de rationalisation des applications du Conseil fédéral américain des DSI. Cependant, il échoue plus souvent qu'il ne réussit en pratique, pour une raison que ses défenseurs évoquent sans jamais l'approfondir : la pertinence des classifications dépend des preuves qui les sous-tendent. Sans preuves structurelles, sans données réelles sur les dépendances, sans mesures précises de la complexité, sans données concrètes sur la valeur métier issues de traces d'exécution plutôt que d'entretiens avec les responsables, les classifications TIME se transforment en enjeux politiques. Les désaccords sur le placement commencent aux étapes de la migration et de la suppression, où l'application préférée de chacun est en jeu, et ils ne sont jamais résolus.

Le modèle : deux axes, quatre dispositions

Le modèle TIME positionne chaque application sur une matrice 2×2. L'axe horizontal représente l'adéquation technique, c'est-à-dire la capacité de l'implémentation technique actuelle de l'application à répondre à sa fonction prévue : qualité de l'architecture, maintenabilité, capacité d'intégration, niveau de sécurité et fiabilité opérationnelle. L'axe vertical représente la valeur métier, c'est-à-dire l'importance de la fonction de l'application pour les opérations commerciales, la génération de revenus, la conformité réglementaire ou les objectifs stratégiques de l'organisation.

	Coupe hautement technique	Faible ajustement technique
Valeur commerciale élevée	INVESTIRFinancez-la. L'application est à la fois stratégiquement importante et techniquement solide. Investissez pour maintenir son avance.	ÉMIGRERL'entreprise en a besoin, mais la technologie est inadaptée. Il faut changer la plateforme, pas la fonction.
Valeur commerciale faible	TOLÉRERPour l'instant, n'y touchez pas. L'application fonctionne bien, mais ne justifie pas d'investissement supplémentaire.	ÉLIMINERÀ jeter. Faible valeur, faible qualité, aucun intérêt à la conserver.

La simplicité est voulue. TIME n'est pas conçu pour élaborer une planification d'investissement détaillée, mais pour fournir des orientations claires pour chaque application du portefeuille. Une application difficile à positionner nécessite des informations complémentaires avant toute classification.

Les modèles opérationnels à quatre quadrants

Chaque disposition TIME n'est pas qu'une simple étiquette, c'est un modèle opérationnel qui détermine comment l'organisation gère l'application à l'avenir.

Investir : Extraction maximale de valeur

Les applications d'investissement sont les fleurons du portefeuille : forte valeur commerciale et parfaite adéquation technique. Elles justifient des investissements massifs dans de nouvelles fonctionnalités, l'optimisation des performances, l'extension des intégrations et la maintenance technique. Une application d'investissement qui accuse un retard technique, un environnement d'exécution vieillissant, une sécurité obsolète ou une dette technique croissante risque d'être migrée avant même que le problème ne soit constaté.

Engagements opérationnels pour Invest :

• Capacités d'ingénierie dédiées au développement de fonctionnalités et à la maintenance technique
• Mises à jour de sécurité et de conformité prioritaires
• Couverture du comité d'examen architectural pour chaque changement important
• Surveillance proactive avec des objectifs SLA au niveau 1

Migration : Remplacer la plateforme, préserver la fonction

Les applications migrées remplissent une fonction métier essentielle à l'organisation, mais reposent sur une plateforme technique devenue inadaptée, trop coûteuse à maintenir, trop fragile pour être étendue et trop isolée des environnements d'intégration modernes. La valeur ajoutée pour l'entreprise justifie l'investissement dans la migration ; en revanche, l'état actuel de la plateforme rend le maintien de celle-ci peu rentable.

La décision de migration répond à une question précise : la fonction mérite-t-elle d’être conservée ? Si oui, migrez. La destination de la migration et la méthode de migration relèvent d’une décision distincte que la classification TIME ne prend pas ; elle constate seulement que la plateforme actuelle n’est pas la solution.

Le scénario de migration le plus courant dans les environnements existants : un programme batch COBOL qui implémente une logique métier critique, des calculs réglementaires complexes, des règles de tarification propriétaires et une logique fiscale spécifique à chaque juridiction, sur une plateforme dont l’extension, les tests et l’intégration sont onéreux. La logique est irremplaçable ; le problème réside dans la plateforme. Migrez vers une plateforme moderne qui préserve la logique tout en offrant les fonctionnalités opérationnelles désormais requises par l’entreprise.

Tolérer : Inaction délibérée avec une date d'expiration

Le quadrant « Tolérer » est le plus mal compris. Il ne signifie pas « cette application est satisfaisante », mais plutôt « sa qualité technique ne justifie pas un investissement pour la modifier immédiatement, et sa valeur commerciale ne justifie pas sa suppression ». Il s'agit d'un choix délibéré d'accepter le statu quo pendant une période définie, et non d'un report indéfini.

L'état « Tolérer » est une suspension temporaire, et non un état permanent. Chaque application classée dans ce quadrant doit avoir une date de révision précise, généralement entre 12 et 18 mois, ainsi que des conditions définies qui déclencheraient un reclassement anticipé : une faille de sécurité non corrigible, la mise hors service d'une dépendance nécessitant un changement de plateforme, une augmentation de la valeur commerciale justifiant un investissement dans l'application, ou une modification de sa fonction métier la rendant caduque.

Les organisations qui considèrent la tolérance comme permanente accumulent précisément la dette technique que le modèle TIME visait à prévenir. Un programme COBOL toléré en 2019 et toujours dans le quadrant « Tolérance » en 2026 a bénéficié de sept années supplémentaires de maintenance différée, maintenance dont il aura finalement besoin, soit en urgence lors d'une panne, soit par une migration forcée lorsque la plateforme ne pourra plus être prise en charge.

Éliminer : La décision que tout le monde prend et que personne n'applique

L'élimination est la classification la plus simple et la décision la moins fréquemment prise. L'application présente une faible valeur commerciale et une faible adéquation technique ; il n'y a donc aucune raison de la conserver. Mettez-la hors service.

L'échec de la mise en œuvre est bien documenté : la liste « Éliminer » est largement alimentée, mais quasiment jamais mise en application. Un examen de portefeuille réalisé en 2024 dans une grande institution financière a identifié 87 actifs candidats à l'élimination. Dix-huit mois plus tard, 71 d'entre eux étaient encore en activité. C'est dans ce décalage entre le classement et la mise hors service que les programmes de rationalisation perdent leur élan.

Trois obstacles spécifiques empêchent l'exécution d'Elimine :

Dépendances cachées. L'application a été classée comme « À éliminer » en raison de son apparente autonomie. Après classification, une analyse structurelle révèle que douze autres programmes produisent des données traitées par l'application candidate à l'élimination, ou que trois systèmes externes lui envoient des données via une interface de fichiers non documentée. L'application n'est pas autonome ; elle constitue l'infrastructure cachée d'autres systèmes. Sa classification doit être réexaminée.

Obstacles à la migration des données : l’application contient des données non destructibles, des documents réglementaires soumis à des délais de conservation obligatoires, des données clients à transférer vers un système successeur et l’historique des transactions interrogé annuellement par les services d’audit. La migration des données doit précéder la mise hors service et représente un coût important.

Obligations réglementaires. Certaines applications ne peuvent être mises hors service, même si leur valeur métier est nulle, car les cadres réglementaires exigent les fonctionnalités qu'elles offrent. Une application de reporting générant un rapport réglementaire trimestriel a une valeur réglementaire qui n'apparaît dans aucune évaluation de sa valeur métier. Tant que l'obligation réglementaire n'est pas transférée à un autre système, l'application doit rester opérationnelle.

Le problème des preuves : pourquoi TIME échoue sans données structurelles

Le principal point faible des implémentations TIME est précisément identifié dans la documentation de Catio : les désaccords sur le placement commencent aux étapes « Migrer » et « Éliminer », où l’application préférée de chacun est en jeu. Sans preuve objective, chaque classification devient une négociation. Le responsable de l’application plaide pour « Investir ». L’équipe informatique plaide pour « Migrer ». L’équipe financière souhaite « Éliminer ». La réunion se termine par « Tolérer », car c’est la solution la moins conflictuelle.

Les preuves structurelles permettent de résoudre ces négociations en remplaçant l'opinion par la mesure.

Pour l'évaluation technique de l'ajustement, les éléments qui comptent :

Indicateur d'ajustement technique	Matériau	Déplace la classification vers
Complexité cyclomatique par programme (moyenne)	Analyse de code statique	Faible = meilleur ajustement, Élevé = moins bon ajustement
Pourcentage de code mort	Analyse d'accessibilité	Code mort élevé = ajustement inférieur
Fan-in (nombre de dépendances entrantes)	Cartographie des dépendances	Une ventilation élevée augmente la tolérance plutôt que l'élimination
Étendue du partage de cahier	Analyse de dépendance de COPY	Partage élevé = couplage plus fort = adaptation moindre
Temps écoulé depuis le dernier changement significatif	Journal de gestion des modifications Git	Une longue période d'inactivité peut indiquer un code mort ou une stabilité.
nombre de vulnérabilités de sécurité	SAST scan	Nombre élevé = ajustement plus faible

Pour l'évaluation de la valeur commerciale, les éléments de preuve qui comptent :

Indicateur de valeur commerciale	Matériau	Déplace la classification vers
Volume de transactions par période	journaux d'exécution JCL, enregistrements du planificateur	Volume élevé = valeur plus élevée
Éventail en aval	Cartographie des dépendances	Un fort taux de diffusion = une valeur plus élevée (beaucoup en dépendent)
Indicateur de fonction réglementaire	Classification des données, registre de conformité	Présent = valeur minimale plancher indépendamment des autres scores
Adjacence des revenus	Analyse des flux de données vers les systèmes de facturation/revenus	Adjacence directe = valeur plus élevée
Nombre d'utilisateurs ou nombre d'appels API	Journaux d'accès, trafic réseau	Nombre élevé = valeur plus élevée

L'information essentielle : pour les systèmes COBOL existants, la plupart de ces indicateurs ne sont pas disponibles dans les entrées CMDB, les entretiens avec les responsables d'applications ni l'analyse du trafic réseau. Ils sont accessibles grâce à l'analyse structurelle du code source, des journaux d'exécution et du planning des tâches JCL, qui documente ce qui s'exécute réellement en production et à quel moment.

Évaluation de l'adéquation technique des systèmes COBOL et des systèmes existants

Les critères d'évaluation standard de l'adéquation technique, tels que la compatibilité API, la préparation au cloud natif, la prise en charge de la conteneurisation et l'architecture de microservices, sont inadaptés aux programmes batch COBOL. Un programme COBOL ne peut être conteneurisé ; l'évaluer selon des critères cloud natifs aboutit donc à un score d'adéquation technique nul pour chaque programme existant, ce qui n'apporte aucune information utile à l'organisation.

Pour les systèmes COBOL et mainframe, le score d'adéquation technique nécessite des critères spécifiques à COBOL :

Score de complexité (pondération : 30 %) : Complexité cyclomatique moyenne des paragraphes et sections du programme. Les programmes dont le score CC moyen est inférieur à 10 présentent une complexité gérable ; ceux dont le score CC est supérieur à 20 présentent une complexité structurelle qui rend la maintenance coûteuse et risquée.

Score de maintenabilité (pondération : 25 %) : Score composite prenant en compte le pourcentage de code mort, l’étendue du partage des copybooks et le taux de duplication. Un programme présentant 40 % de code mort, 15 copybooks partagés et une duplication de code importante a une faible maintenabilité, indépendamment de sa correction fonctionnelle.

Score de risque de dépendance (pondération : 20 %) : Nombre de dépendances entrantes pondéré par la criticité des dépendances entrantes. Un programme comptant 50 dépendances entrantes provenant de programmes de niveau 1 présente un risque de dépendance élevé ; toute modification de ce programme nécessite la coordination de 50 programmes en aval.

Score de modernité (pondération : 15 %) : mise à jour du dialecte COBOL et de la version du compilateur, modernité de la syntaxe JCL et interface de base de données (ancienneté du SQL embarqué, VSAM vs DB2, traitement par lots uniquement vs traitement par lots + CICS). Les programmes écrits en COBOL-85 avec SQL embarqué DB2 sont plus modernes que ceux écrits en COBOL-74 avec accès aux fichiers uniquement via VSAM.

Score de posture de sécurité (pondération : 10 %) : Présence d’identifiants codés en dur, accès aux fichiers non protégé, absence de vérification de l’état des fichiers et exposition à l’injection SQL dans la construction SQL dynamique.

Technical Fit Score = (100 - complexity_score) × 0.30
                    + maintainability_score × 0.25
                    + (100 - dependency_risk) × 0.20
                    + currency_score × 0.15
                    + security_score × 0.10

Where each component is scored 0-100, with 100 being best.

Cette formule de notation produit un score d'adéquation technique de 0 à 100, issu d'une analyse du code structurel et non d'une évaluation qualitative. Deux applications aux fonctions identiques mais aux caractéristiques structurelles différentes obtiendront des scores d'adéquation technique différents, reflétant fidèlement les investissements nécessaires à leur maintenance et à leur extension.

Le problème de la dérive tolérée : gouvernance pour le quadrant de détention

Le quadrant « Tolérer » est celui où s'accumule la dette technique au fil du temps dans toute organisation utilisant TIME sans gouvernance explicite de ce quadrant. Le mécanisme est simple : une application y entre car il n'est pas jugé utile de la modifier, puis elle y reste indéfiniment, sa modification n'étant jamais la priorité absolue.

Une discipline de gouvernance tolérante empêche le report indéfini :

Déclencheurs de reclassement conditionnel :

• Vulnérabilité de sécurité identifiée ne pouvant être corrigée sous 30 jours → examiner la possibilité de migrer ou d'éliminer
• Le fournisseur annonce la fin de vie d'un composant de plateforme dont dépend l'application → consulter Migrate
• Le score de valeur commerciale dépasse le seuil (nouvelle exigence réglementaire, changement de modèle économique) → examen en vue d'un investissement ou d'une migration
• Les obligations de retraite liées à la dépendance entraînent une modification de l'interface → examen en vue d'une migration ou d'une suppression
• L'analyse du code mort révèle que l'application est effectivement inactive → examen en vue de son élimination

Cadence de révision basée sur le temps :

• Les demandes sont soumises à Tolerate avec une date d'examen de 12 mois
• Lors de l'examen à 12 mois, la demande est explicitement reclassée ou explicitement ré-tolérée avec une nouvelle date de 12 mois.
• La réautorisation nécessite une justification écrite expliquant pourquoi les conditions n'ont pas changé.
• Une demande ayant fait l'objet d'une nouvelle tolérance plus de deux fois sans reclassement entraîne une saisine du comité d'examen de l'architecture.

Le registre des demandes d'autorisation : liste mise à jour régulièrement de toutes les demandes d'autorisation, avec leur date de classification, leur date de révision, leur responsable et les conditions qui déclencheraient une reclassification. Ce registre est examiné à chaque réunion du comité d'examen de l'architecture, et non seulement lors de la revue annuelle du portefeuille.

Rendre Eliminate exécutable : combler le fossé du déclassement

C’est au niveau de l’écart entre la mention « à éliminer » et la mention « mise hors service réussie » que les programmes de rationalisation s’enlisent. Pour combler cet écart, il est nécessaire de considérer chaque décision d’élimination comme un projet avec un périmètre, des dépendances et des critères de réussite définis, et non comme une conclusion.

Liste de contrôle pour l'exécution d'Eliminate :

• Vérification des dépendances terminée : L'analyse statique confirme l'absence de dépendances de production entrantes (et pas seulement l'absence de dépendances documentées, mais l'absence de dépendances structurellement vérifiées).
• Plan de traitement des données approuvé : Les exigences réglementaires en matière de conservation des données ont été identifiées, et un plan de migration ou d'archivage des données a été approuvé par les services juridiques et de conformité.
• Notification en aval terminée : Le propriétaire de chaque système consommateur a été informé et a confirmé l'absence de dépendance active.
• Vérification des obligations réglementaires terminée : Aucune soumission réglementaire active, aucun audit ni aucune exigence de conformité ne dépendent de la demande
• Propriétaire du démantèlement désigné : Une personne désignée responsable de la mise hors service, et non seulement de la décision de classification.
• Plan de restauration défini : Procédure de rétablissement du service si la mise hors service révèle une dépendance non découverte
• Date de mise hors service engagée : Une date précise sur le calendrier informatique, et non pas « quand on aura le temps ».

L'étape d'analyse structurelle : la décision « Aucune suppression » ne passe à la planification de la mise hors service que lorsqu'une analyse structurelle confirme l'absence de dépendances entrantes provenant des chemins d'exécution de production. La cause la plus fréquente d'échec de l'exécution de la suppression est la découverte d'une dépendance après l'annonce de la mise hors service, ce qui entraîne une restauration. Une analyse des dépendances structurelles effectuée avant l'annonce permet d'éviter ce problème.

Le cycle de réévaluation TIME

Les classifications TIME ne sont pas figées. La valeur commerciale évolue au gré de la stratégie de l'organisation. L'adéquation technique se modifie en fonction de la maintenance, de l'extension ou du vieillissement de l'application. Le modèle n'est qu'un instantané ; le portefeuille, lui, nécessite une vision évolutive.

Réévaluation annuelle complète : chaque application du portefeuille est évaluée selon les critères actuels de valeur commerciale et d’adéquation technique. Les classifications inchangées depuis trois années consécutives font l’objet d’un examen approfondi : soit l’application est réellement stable (justifier en conséquence), soit l’évaluation ne prend pas en compte les évolutions en cours.

Réévaluation déclenchée par un événement : certains événements spécifiques déclenchent un réexamen immédiat de la classification :

• Fusion ou acquisition (regroupement de nouveaux portefeuilles)
• Changements réglementaires affectant les obligations de conformité
• Annonce de fin de vie d'une plateforme majeure (base de données, système d'exploitation, environnement d'exécution)
• Changement significatif du modèle économique (nouvelle gamme de produits, retrait du marché, restructuration organisationnelle)
• Incident de sécurité concernant l'application

Suivi des modifications : Chaque reclassement est consigné avec les informations suivantes : classification précédente, nouvelle classification, date, justificatif du changement et approbateur. L'historique de classification de chaque application constitue la piste d'audit qui démontre que le portefeuille est géré activement et non simplement catégorisé puis oublié.

Comment SMART TS XL Fournit les preuves de la classification TIME

La pertinence des décisions de classification du modèle TIME dépend de la qualité des preuves qui les sous-tendent. Pour les applications modernes disposant d'une CMDB, d'une surveillance des API et d'architectures documentées, ces preuves sont accessibles. En revanche, pour les applications COBOL existantes où la CMDB est incomplète, où les responsables ont pris leur retraite et où la structure des dépendances n'est pas documentée, les preuves doivent provenir d'une analyse structurelle du code lui-même.

SMART TS XL's analyse de code statique Ce système génère les données techniques nécessaires à l'évaluation COBOL : complexité cyclomatique par programme, pourcentage de code mort, détection de failles de sécurité (identifiants codés en dur, accès aux fichiers non protégés) et actualisation du dialecte COBOL. Ces indicateurs sont calculés à partir du code source, et non d'estimations de développeurs, et ne dépendent pas de la mémoire des développeurs quant au fonctionnement de l'application.

La cartographie des dépendances applicatives génère les décomptes de dépendances entrantes, évitant ainsi les décisions d'élimination prématurées, et les décomptes de dépendances sortantes, utiles à l'évaluation de la valeur métier. Une application présentant 45 dépendances entrantes provenant de programmes de production n'est pas une candidate à l'élimination sûre, quelle que soit l'évaluation de sa valeur métier par son propriétaire. Le nombre de dépendances constitue le critère structurel qui prime sur l'argument de classification.

L' analyse de modernisation des systèmes existants produit l'inventaire du code mort qui modifie les classifications : les programmes qui apparaissent dans la CMDB comme des applications actives mais qui n'ont aucune dépendance de production entrante sont des candidats au code mort, reclassés de Tolérer à Éliminer sur la base de preuves structurelles, et non sur l'évaluation par le propriétaire de l'entreprise d'un programme dont il n'a peut-être jamais su l'existence.

La capacité d'analyse d'impact rend possible la mise en œuvre de la procédure d'élimination : l'analyse structurelle qui confirme l'absence de dépendances de production entrantes avant toute planification de la mise hors service. C'est le rempart qui empêche l'échec le plus fréquent lors de l'exécution de la procédure d'élimination : la dépendance non détectée qui apparaît après l'annonce.

La fonction de recherche d'entreprise permet d'interroger le processus de classification TIME tout au long du cycle de réévaluation : elle permet de trouver toutes les applications classées comme « Tolérer » avec une date de révision dans les 30 prochains jours, toutes les applications classées comme « Éliminer » sans date de mise hors service, et toutes les applications dont le score d'adéquation technique est inférieur à 30 mais qui sont toujours classées comme « Investir ». Ces requêtes constituent l'outil de gouvernance qui permet au modèle TIME de rester un instrument de gestion actif et non un simple exercice de classification ponctuel.

Un cadre de référence n'est valable que si ses preuves le justifient.

La structure à deux axes du modèle TIME est correcte. La valeur commerciale et l'adéquation technique constituent les dimensions pertinentes pour les décisions relatives au portefeuille d'applications. Les quatre orientations représentent les options appropriées. Le problème ne réside pas dans le cadre lui-même, mais dans les données probantes que les organisations y apportent.

Les classifications basées sur les données d'entretiens et les estimations de la CMDB alimentent les débats organisationnels. Celles fondées sur l'analyse structurelle, la complexité mesurée, le nombre de dépendances vérifiées et l'évaluation technique du code permettent de prendre des décisions justifiées. Le responsable d'une application qui soutient que son programme COBOL nécessite un investissement plutôt qu'une migration a plus de mal à convaincre lorsque l'analyse structurelle révèle une complexité cyclomatique moyenne de 35, 40 % de code mort et 12 failles de sécurité. L'équipe informatique qui plaide pour la suppression d'un programme a moins de poids dans ses arguments lorsque l'analyse des dépendances met en évidence 45 dépendances entrantes en production.

Le modèle TIME est pertinent lorsque les preuves sont suffisantes. L'analyse structurelle du portefeuille d'applications permet aux organisations de constituer ces preuves pour les applications existantes qui nécessitent le plus de décisions de rationalisation et pour lesquelles la documentation facilitant ces décisions est la moins susceptible d'être disponible.