Dette technique : Pourquoi le conseil d'administration doit agir maintenant

04.06.2026

7 min de lecture

La dette technique ne figure dans aucun bilan, mais coûte réellement à chaque groupe. Selon McKinsey, 10 à 20 pour cent du budget consacré aux nouveaux produits servent à éliminer les legacy systems, et même plus pour un tiers des DSI. Qui laisse cette dette au service d’ingénierie traite une question de capital comme de la maintenance. En réunion budgétaire, elle doit figurer aux côtés des investissements produits, de la stratégie de plateforme et de l’appétence pour le risque.

Les points clés en bref

La dette technique est un poste comptable sans bilan. Selon McKinsey, elle représente un cinquième à deux cinquièmes de l’ensemble du patrimoine technologique et détermine la vitesse à laquelle un groupe peut encore innover.
Une part budgétaire forfaitaire ne suffit pas. Prélever 15 pour cent pour les legacy systems est inefficace. Le remboursement ne devient effectif que lorsque chaque décision d’investissement intègre cette dette.
La décision nécessite trois rôles. Un cadre de remboursement relève de l’allocation de capital par le CEO, le CFO et le CIO conjointement, et non d’un reliquat budgétaire IT.

En lien avec :Zero Trust a besoin de connaissances process/Ce que le conseil de surveillance doit exiger

Ce que la dette technique coûte vraiment au comité de direction

La dette technique n’est pas un problème de métaphore, mais une liberté de décision engagée. Qu’est-ce que la dette technique ? Elle désigne l’effort accumulé lorsque les systèmes sont construits rapidement plutôt que proprement : architectures obsolètes, dépendances non entretenues, solutions de contournement jamais démantelées. Comme pour un crédit, des intérêts s’accumulent, sous forme de développement ralenti, de risques de panne accrus et d’efforts qui ne se transforment jamais en nouvelle valeur.

Les chiffres permettent d’appréhender l’ampleur du phénomène. McKinsey l’évalue à 20 à 40 pour cent de l’ensemble du patrimoine technologique, avant amortissement. Dans le même temps, un dixième à un cinquième du budget des nouveaux produits ne sert pas à innover, mais à réparer l’ancien. Pour environ un tiers des DSI interrogés, cette part dépasse 20 pour cent. Cela fausse toute planification de croissance avant même que la première feuille de route ne soit décidée.

20 à 40 %

de la valeur de l’ensemble du paysage technologique est engloutie dans la dette technique, selon McKinsey, avant même tout amortissement.

Source : McKinsey Digital, Tech Debt

Le réflexe de nombreuses entreprises est de traiter la dette comme un sujet d’ingénierie. C’est précisément là que commence l’erreur. Si personne au comité de direction ne connaît son ampleur, aucune décision ne peut être prise quant à son remboursement. Elle continue alors de croître silencieusement, jusqu’à ce qu’un projet devienne soudainement coûteux sans que personne ne puisse expliquer pourquoi.

De l’intuition au pilotage en trois étapes

La dette technique se maîtrise lorsqu’elle passe du diagnostic des développeurs à une logique d’investissement. Trois étapes suffisent, que la direction peut exiger.

Les trois étapes en bref

1. Rendre visible

Un inventaire des principales dettes techniques avec leurs coûts estimés : quelle dette freine quelle feuille de route ? Sans cette liste, toute discussion reste subjective.

2. Chiffrer

Chaque dette technique se voit attribuer un indicateur business : temps de développement perdu, risque de panne, projets bloqués. Seul le chiffre transforme un sujet technique en question stratégique.

3. Intégrer au plan

Le remboursement ne constitue pas un budget exceptionnel, mais fait partie de chaque décision d’investissement. Qui construit du neuf intègre la dette qu’il contracte ou résorbe.

La troisième étape est la plus inconfortable. Un projet de nettoyage ponctuel reste sans effet, car la dette se reconstitue immédiatement. McKinsey fixe une limite claire : 15 à 20 % du budget IT réservés à un fonds séparé ne suffisent pas. La tendance ne s’inverse que lorsque chaque budgétisation affiche conjointement la nouvelle dette et son remboursement.

Ce qui soutient un cadre de remboursement et ce qui le freine

Un cadre fixe pour résorber la dette technique semble simple. En pratique, son ancrage dans les processus trimestriels et d’investissement fait la différence.

Ce qui soutient

Un indicateur de dette mesurable dans le rapport trimestriel
Un responsable identifié au niveau de la direction, pas dans l’équipe
Le remboursement intégré à chaque investissement, pas en projet annexe

Ce qui freine

Un remboursement de dette réservé aux trimestres calmes
Des indicateurs que personne ne lit en comité de direction
Un budget qui disparaît dès la première coupe

Le mécanisme de freinage est le même dans de nombreuses entreprises : le remboursement de la dette est le premier sacrifié lorsque les budgets se resserrent, et son absence ne se remarque que lorsque les feuilles de route déraillent.

Qui décide in fine

L’idée reçue la plus répandue veut que la dette technique soit une question de DSI. Le DSI peut la quantifier, mais pas la résorber seul. Un cadre de remboursement relève de l’allocation de capital et nécessite l’implication du DAF autant que la priorité du DG. McKinsey désigne clairement le trio : DG, DAF et DSI ensemble. Le DSI apporte la cartographie des dettes, le DAF le cadre, le DG la priorité face à tous les autres investissements.

Le gain est concret. Là où la dette technique est pilotée activement, les équipes de développement gagnent jusqu’à 50 % de temps supplémentaire pour des travaux alignés sur les objectifs business, selon McKinsey. Ce temps représente le véritable retour sur investissement du remboursement. Il ne se mesure pas dans la réduction de la dette elle-même, mais dans la vitesse à laquelle de nouvelles initiatives voient ensuite le jour. La question du mandat détermine ici aussi si la prise de conscience se transforme en impact.

Foire aux questions

Qu’est-ce que la dette technique ?

L’effort accumulé lorsque le développement logiciel privilégie la rapidité au détriment de la qualité : architectures obsolètes, dépendances non maintenues, solutions de contournement non supprimées. Comme un crédit, elle génère des intérêts permanents sous forme de développement ralenti et de risques accrus.

Quelle est l’ampleur du problème en chiffres ?

Selon McKinsey, elle représente entre un cinquième et deux cinquièmes de l’ensemble du parc technologique avant amortissement. De plus, entre un dixième et un cinquième du budget dédié aux nouveaux produits est englouti dans la résolution des legacy, et même davantage pour un tiers des DSI.

Pourquoi une enveloppe budgétaire fixe ne suffit-elle pas ?

Parce qu’un budget dédié une fois pour toutes n’arrête pas la dette, qui continue de croître en parallèle. Le remboursement n’est efficace que lorsque chaque décision d’investissement intègre la dette technique qu’elle génère ou résorbe, au lieu de la reléguer dans un projet spécial.

Qui doit décider de sa réduction ?

Le PDG, le DAF et le DSI, ensemble. Le DSI fournit l’état des lieux et le coût des intérêts, le DAF le cadre financier, et le PDG la priorisation face aux autres investissements. Confiée à la seule direction informatique, la réduction reste sans effet.

Quels sont les bénéfices concrets d’une gestion active ?

Là où la dette technique est maîtrisée, les équipes de développement gagnent jusqu’à 50 % de temps supplémentaire pour travailler sur les objectifs métiers, selon McKinsey. Le retour sur investissement se mesure donc moins par la réduction elle-même que par la vitesse à laquelle de nouvelles innovations peuvent ensuite émerger.

Plus d’articles du réseau MBF Media