Un système vieillissant ne traduit pas forcément une dette technique

Qualifier des systèmes vieillissants de « dette technique » peut conduire à un mauvais plan de financement

Un directeur administratif et financier, ou DAF, peut financer un programme de remplacement des systèmes centraux de l’entreprise tout en le laissant incapable d’aller jusqu’au bout. Cela se produit lorsque plusieurs systèmes interdépendants doivent évoluer ensemble, mais que chaque demande budgétaire est traitée comme un paiement distinct, ajustable séparément, au titre de la « dette technique ». Chaque réduction peut sembler prudente prise isolément. Ensemble, ces réductions peuvent permettre au travail de remplacement de se poursuivre tout en empêchant la mise hors service de l’ancienne plateforme.

Le problème commence lorsqu’une même étiquette applique le même traitement financier à des travaux de nature différente. Ces activités incluent le remplacement de systèmes vieillissants, le déplacement de charges de travail vers le cloud, le développement d’applications mobiles et l’utilisation de la virtualisation pour exécuter plusieurs ordinateurs définis par logiciel sur un matériel partagé. Elles incluent aussi l’adoption du software as a service, des applications exploitées en ligne par un fournisseur, l’intégration d’agents IA qui exécutent des tâches via des outils logiciels, ainsi que le rapatriement de systèmes vers une infrastructure on-premises contrôlée par l’organisation. Ces changements répondent à des besoins différents, mais la confusion qui les entoure laisse aux fournisseurs la possibilité de vendre en jouant sur la peur, l’incertitude et le doute, ou FUD, une pratique qui dépasse le seul cadre d’IBM.

Pour distinguer ces besoins, Justin Greis, PDG du cabinet de conseil Acceligence, sépare les raccourcis délibérés des obligations non autorisées et du vieillissement technologique ordinaire. Son cabinet a un intérêt commercial dans la manière dont les entreprises définissent leurs problèmes de modernisation et recherchent une aide en conseil. En gardant cet intérêt à l’esprit, les dirigeants peuvent utiliser ses exemples pour poser deux questions : le financement approuvé peut-il soutenir une transition menée à son terme, et les progrès rapportés reflètent-ils un changement dans les systèmes qui limitent l’activité ?

Distinguer les raccourcis approuvés, les obligations non autorisées et le vieillissement

La question du financement commence par une explication claire des raisons pour lesquelles ce travail est nécessaire. La classification d’Acceligence demande si quelqu’un a pris un raccourci et, si oui, si la direction l’a sciemment autorisé. Ces questions permettent de distinguer un compromis métier accepté d’une obligation créée sans approbation. Elles laissent aussi la place à un système qui était adapté au moment de son achat, mais qui a depuis vieilli.

Selon cette classification, la dette technique commence par un choix délibéré de reporter une partie d’une mise en œuvre pour une raison métier. Des développeurs ou le personnel d’un centre des opérations de sécurité, qui surveille les menaces de sécurité et y répond, peuvent constater que la mise en œuvre complète dépasse le temps ou le budget disponible. La direction accepte ce compromis pour permettre à la livraison d’avancer, en sachant qu’achever plus tard le travail différé augmentera probablement le coût total. L’organisation a accepté à la fois le bénéfice immédiat et l’obligation future.

Greis illustre ce choix avec un budget de « $X » ou une échéance de « deux semaines ». Ces contraintes hypothétiques expliquent pourquoi un raccourci peut être raisonnable ; elles ne décrivent ni une dépense réelle ni une promesse de livraison. La condition essentielle est une approbation éclairée. Comme le dit Greis, « La dette technique, dans son sens d’origine, décrit un arbitrage assumé en connaissance de cause. Le terme est utile précisément parce qu’il est si spécifique. »

Sans approbation éclairée, Acceligence qualifie l’obligation de « shadow tech debt ». Dans son exemple, une personne prend un raccourci et laisse l’entreprise confrontée à une dépense dans un an, alors même que la direction n’a jamais accepté cet arbitrage. L’absence d’autorisation crée un problème de gouvernance : quelqu’un a engagé l’organisation dans une dépense future sans lui donner la possibilité d’en décider. Les dirigeants doivent donc établir qui avait l’autorité d’accepter cette obligation et comment elle est devenue visible.

L’ampleur et la persistance de cette obligation la distinguent aussi des contournements plus limités souvent qualifiés de shadow IT : des technologies acquises ou utilisées en dehors des processus approuvés. Dans les exemples d’Acceligence, quelqu’un peut obtenir une instance cloud, un environnement informatique loué, avec une carte de crédit, ou installer un routeur grand public en attendant un mois la livraison d’un équipement d’entreprise approuvé. Acceligence considère que ces contournements sont généralement moins susceptibles de créer une dépense future substantielle pour l’entreprise. Leurs conséquences exigent néanmoins du discernement, car des choix non autorisés peuvent créer des niveaux de responsabilité différents.

Le vieillissement constitue une autre raison d’investir. Un mainframe ou un premier déploiement cloud a pu être un achat adapté, et coûteux, à l’époque, tout en nécessitant un remplacement à mesure que les besoins métier et la technologie évoluent. Dans l’illustration d’Acceligence, un investissement réalisé en 2000 et réexaminé en 2026 montre ce passage du temps. Son besoin de modernisation reflète les exigences actuelles ; il n’établit en rien si la mise en œuvre d’origine comportait un raccourci.

Pour cette catégorie liée au vieillissement, Greis a forgé l’expression « tech gravity », un terme qu’Acceligence utilise pour désigner des investissements qui étaient appropriés au moment où ils ont été réalisés mais qui nécessitent ensuite un renouvellement. La distinction utile tient à la cause du travail : un raccourci approuvé appelle une explication du compromis accepté, une obligation non autorisée appelle une action de gouvernance, et un système vieillissant appelle une décision de modernisation. Les dirigeants peuvent utiliser ces distinctions dans une discussion sur le financement sans adopter cette nouvelle terminologie. Chaque catégorie conduit la direction à prendre une décision différente.

Financer les dépendances nécessaires à la mise hors service

La distinction influe sur le financement lorsque la mise hors service d’une plateforme exige que plusieurs systèmes évoluent ensemble. Dans la première illustration de Greis, un directeur des systèmes d’information, ou DSI, présente au conseil d’administration une proposition de mise hors service sur plusieurs années et décrit la plateforme comme un passif pouvant être réduit au fil du temps. Le conseil approuve la proposition, après quoi le DAF valide une allocation prudente pour la première année. Le travail peut commencer, mais cette allocation laisse l’engagement complet ouvert à des décisions ultérieures.

L’autorisation de commencer peut masquer un désaccord sur ce qu’exige l’achèvement. Le DSI dispose d’un objectif approuvé, tandis que le DAF a autorisé un montant initial de dépenses. Ces décisions permettent à l’équipe d’avancer, mais laissent sans réponse la question de savoir si les systèmes interdépendants peuvent effectuer la transition coordonnée nécessaire pour mettre la plateforme hors service. La proposition doit donc relier les étapes de dépense aux conditions requises pour arrêter l’ancien système.

L’écart devient visible deux ans après le début de l’exemple de Greis, lorsque le programme prend du retard. Les systèmes se révèlent plus interconnectés que ne l’indiquait l’inventaire initial, et l’allocation ne permet pas de faire évoluer tous les systèmes dépendants ensemble. Cette découverte accroît le besoin de coordination au moment même où le dispositif de financement le limite. Ainsi, les progrès réalisés sur des composants individuels laissent l’ancienne plateforme toujours nécessaire.

Un inventaire aide à identifier ces composants, mais la mise hors service exige aussi une explication de la manière dont leurs dépendances seront supprimées. Certains travaux peuvent être terminés alors qu’une connexion non résolue ailleurs empêche encore l’arrêt. La décision budgétaire doit donc couvrir la combinaison et le calendrier des changements nécessaires pour aller jusqu’au bout. Comptabiliser le travail finançable dans le cadre d’une seule allocation répond à une question plus étroite.

Greis décrit directement cette contrainte : « Le problème, c’est qu’un programme comme celui-ci a un niveau minimal d’engagement en dessous duquel il ne peut pas aboutir, et le cadrage en dette n’a donné au DSI aucun moyen de le dire. » Dans son illustration, ce minimum découle des systèmes qui doivent évoluer ensemble et de la préparation qu’exige leur transition. Une proposition de financement doit expliquer ces dépendances afin que le conseil puisse comprendre pourquoi une allocation plus faible peut rendre la mise hors service irréalisable.

Sans cette explication, chaque demande ultérieure peut sembler comme un nouveau paiement discrétionnaire au titre d’un passif de long terme. Le DAF réduit la demande, le DSI accepte la réduction, et l’équipe poursuit le travail qu’elle peut se permettre. Répéter cette négociation peut entretenir l’activité tout en reportant les changements nécessaires à l’arrêt. Des décisions qui paraissent prudentes dans chaque période budgétaire peuvent, collectivement, empêcher l’atteinte de l’objectif approuvé.

Ce retard compte parce que l’organisation continue de supporter les coûts d’exploitation de l’ancienne plateforme et ses dépendances fragiles tout en finançant la transition. Greis qualifie cette prolongation indéfinie de « résultat le plus coûteux possible ». Son argument porte sur la charge combinée d’une modernisation inachevée et d’un système existant qui reste indispensable. Toute économie immédiate résultant d’une allocation réduite doit être mise en balance avec la durée supplémentaire pendant laquelle ces deux obligations se poursuivent.

Un financement par étapes peut néanmoins fonctionner, à condition que ces étapes préservent une transition réalisable. Le conseil peut autoriser des dépenses dans le temps tout en maintenant les ressources, le calendrier et les travaux dépendants nécessaires à l’achèvement. S’il réduit l’engagement, la proposition doit identifier le changement correspondant en matière de calendrier, de périmètre ou de faisabilité. Le DSI doit rendre cette conséquence explicite lorsqu’il sollicite l’approbation, afin que l’autorisation de poursuivre s’accompagne d’une voie crédible vers la mise hors service.

Mesurer les changements dans la dépendance aux systèmes centraux

Même un plan de financement réalisable a besoin d’un indicateur de progression montrant si les dépendances pertinentes évoluent réellement. La deuxième illustration de Greis examine ce problème de reporting : une entreprise passe cinq ou six ans à mettre à jour des applications orientées client, à déplacer l’analytics vers le cloud et à remplacer des outils de collaboration. Au bout du compte, son inventaire montre qu’une majorité d’applications a été modernisée. Ce décompte enregistre une livraison substantielle, mais laisse l’effet métier peu clair.

L’effet métier dépend des systèmes dont ces applications ont encore besoin. Greis cite le grand livre comptable, la plateforme d’administration des polices, le moteur bancaire central et le système de gestion des commandes comme exemples de systèmes sous-jacents qui peuvent rester en place. La plateforme concernée varie selon l’entreprise, mais chacune peut continuer à fournir des données essentielles ou à traiter des transactions pour des applications plus récentes. Des remplacements plus faciles peuvent donc faire monter le nombre d’applications modernisées tout en laissant intactes ces dépendances.

Dans l’illustration de Greis, chaque nouvelle application dépend encore des systèmes inchangés pour les données et les transactions. L’inventaire enregistre un remplacement alors même que la relation avec l’ancienne plateforme persiste. Comme l’explique Greis, « Quand quelque chose change dans le cœur du système, la couche moderne casse. Quand le métier demande une nouvelle capacité, la réponse passe toujours par l’ancienne plateforme. » L’application visible a changé, tandis que la contrainte sous-jacente sur la capacité de livraison du métier demeure.

Pour les responsables engineering et produit, cette contrainte détermine le degré de liberté que le remplacement crée réellement. Une capacité demandée qui exige des changements dans un ancien système transactionnel doit toujours se conformer aux exigences et aux dépendances de ce système. L’équipe applicative a peut-être atteint son objectif immédiat tout en laissant en place la contrainte plus large sur la livraison. Le reporting d’avancement doit décrire les deux résultats afin que les dirigeants puissent juger ce que le travail achevé permet réellement.

La même distinction s’applique au coût d’exploitation et au risque. Dans le scénario de Greis, le risque, le coût de fonctionnement et le temps nécessaire pour livrer de nouvelles capacités se sont à peine améliorés malgré la hausse du pourcentage de modernisation. Le DSI doit expliquer pourquoi les remplacements achevés ont produit si peu de changement dans les résultats attendus par le conseil. Un simple décompte des applications ne peut pas l’expliquer, car il donne le même poids à chaque remplacement, quel que soit son effet sur la dépendance aux systèmes centraux.

Un reporting plus utile conserve le décompte tout en expliquant ce que chaque remplacement a changé sur le plan opérationnel. Le conseil peut alors reconnaître le travail accompli tout en voyant si les systèmes responsables des coûts persistants, de l’exposition au risque et des contraintes de livraison sont toujours en place. Ce choix de reporting influence aussi les budgets futurs : si les dirigeants ne récompensent que le décompte, ils peuvent continuer à privilégier les remplacements les plus faciles. Le reporting peut alors orienter l’investissement à l’écart des changements plus difficiles nécessaires pour modifier les résultats métier.

Rendre les conséquences claires pour les décideurs du financement

Parce que le reporting façonne l’investissement, les DSI et les directeurs IT doivent relier les contraintes techniques aux décisions que les dirigeants contrôlent. Ils peuvent s’appuyer sur ce qu’ils savent déjà de leurs systèmes, mais doivent rendre cette connaissance exploitable par le DAF, le PDG et le conseil lorsqu’ils fixent les budgets et les attentes. Un conseil qui demande « pourquoi cela prend-il autant de temps ? » doit comprendre quelles dépendances restantes déterminent l’achèvement. La réponse doit relier chaque changement nécessaire à l’engagement et au calendrier qu’il exige.

Une explication claire dépend aussi de la volonté des équipes de décrire ouvertement les conditions actuelles. Greis déclare : « Le mot dette implique une idée de faute, et cela a déformé la manière dont les organisations perçoivent leurs propres systèmes. D’après mon expérience, les équipes parlent bien plus franchement de ce qu’elles portent lorsque le fait de le décrire ne ressemble pas à un aveu. » Son expérience de consultant fournit une raison supplémentaire de distinguer le vieillissement ordinaire d’un raccourci antérieur. Une description moins accusatrice peut rendre plus facile l’obtention des informations nécessaires à la planification.

Ces informations comptent lorsque les dirigeants modifient une proposition. S’ils supposent que chaque réduction de financement produit une amélioration proportionnellement plus faible, ils peuvent fixer des attentes que des systèmes interdépendants rendent irréalisables, affaiblissant ainsi le retour sur investissement attendu. La responsabilité actuelle repose sur la décision qu’ils prennent maintenant : un engagement plus faible doit avoir une conséquence explicite sur le calendrier, le périmètre ou la faisabilité de la mise hors service. L’approbation doit consigner cette conséquence afin que la promesse de livraison corresponde aux ressources et aux dépendances que l’organisation a accepté de soutenir.

Points clés

• Classer l’obligation : les DSI doivent distinguer les raccourcis approuvés, les engagements non autorisés et le vieillissement ordinaire des systèmes avant de demander un financement. Chacun appelle une décision différente en matière de remboursement, de gouvernance ou de modernisation.
• Financer une mise hors service réalisable : les DAF et les DSI doivent s’accorder sur les changements interdépendants nécessaires pour arrêter une ancienne plateforme. Un financement par étapes doit préserver une voie vers l’achèvement, avec des réductions budgétaires liées à des changements explicites de périmètre, de calendrier ou de faisabilité.
• Mesurer les changements dans les contraintes métier : les rapports de modernisation doivent montrer comment le travail achevé modifie la dépendance aux systèmes centraux, le coût d’exploitation, le risque et le délai de livraison. Le seul décompte des applications peut masquer les contraintes qui subsistent.
• Rendre explicites les conséquences budgétaires : les DSI doivent expliquer quelles dépendances restantes déterminent l’achèvement et comment les changements de financement les affectent. Les approbations du conseil doivent consigner ces conséquences afin que les attentes de livraison correspondent à l’engagement autorisé.