Dette technique d'une application : mesurer et trancher

13,5 heures sur une semaine de 41,1 heures. C'est le temps qu'un développeur moyen passe sur la dette technique, selon l'estimation des développeurs interrogés par Stripe à propos de leur propre entreprise : un tiers d'une semaine payée, sans aucune fonctionnalité nouvelle à la clé. En France, le temps perdu en maintenance atteint 20,9 heures par semaine, le niveau le plus élevé des pays étudiés.

Trois questions restent : comment mesurer la dette technique d'une application avec un chiffre plutôt qu'une impression, quelles échéances d'Apple et de Google la transforment en urgence, et comment trancher entre réparer, refondre ou réécrire.

13,5 hsur une semaine de 41,1 heures : le temps passé sur la dette technique par un développeur moyen, selon ses collègues interrogés

Source : Stripe et Harris Poll, The Developer Coefficient, septembre 2018 (plus de 1 000 développeurs et plus de 1 000 dirigeants, dont la France)

Note de méthode : les études de référence sur le sujet datent de 2018 à 2022, et aucune n'a connu d'édition plus récente. Les montants publiés en dollars sont convertis au taux de référence BCE du 12 octobre 2026, soit 1 USD pour 0,894 €.

Combien coûte la dette technique, en temps et en budget ?

La dette technique se paie d'abord en temps. Dans l'étude Stripe, les répondants estiment que, pour un développeur moyen de leur entreprise, 17,3 heures par semaine partent en maintenance au sens large — erreurs, débogage, réécriture de code existant — dont 13,5 heures sur la seule dette. Rapporté à 41,1 heures travaillées, cela fait 32,8 % du temps pour la seule dette, et 42,1 % pour l'ensemble de la maintenance. La France est le pays le plus touché de l'échantillon : 20,9 heures de maintenance sur une semaine moyenne de 39,6 heures, la plus courte, soit 52,8 %. Stripe ne publie pas la part propre à la dette par pays.

Ce sont des estimations déclaratives, pas des mesures. Ordre de grandeur pour un budget : sur vingt jours de développement achetés, si la proportion moyenne s'applique à votre projet, environ 6,6 jours remboursent la dette au lieu de construire.

Côté direction, McKinsey a interrogé en juillet 2020 cinquante DSI d'entreprises de services financiers et de technologie réalisant plus d'un milliard de dollars de chiffre d'affaires. Ils estiment que 10 à 20 % du budget technique destiné aux nouveaux produits est détourné vers la dette, et que celle-ci représente 20 à 40 % de la valeur de leur parc technique avant amortissement. 60 % la jugeaient en hausse sur trois ans.

Source : McKinsey, Tech debt: Reclaiming tech equity, 6 octobre 2020

À l'échelle d'un pays, le CISQ estime la dette technique logicielle accumulée aux États-Unis à environ 1 520 milliards de dollars en 2022, soit 1 359 milliards d'euros. Le rapport précise que ce chiffre est sa propre estimation de 2020, réévaluée de l'inflation.

Source : CISQ, The Cost of Poor Software Quality in the US: A 2022 Report, novembre 2022

Comment mesurer la dette technique d'une application ?

L'un des outils d'analyse les plus répandus, SonarQube, mesure la dette en additionnant le temps estimé pour corriger chaque problème de maintenabilité, compté en jours de huit heures. Il la rapporte ensuite au coût théorique d'écriture du code : 30 minutes par ligne par défaut.

Source : SonarSource, définitions des métriques, SonarQube Server 2026.5

Faites le calcul sur un exemple. Posons une application de 50 000 lignes de code, dont l'analyse estime la dette à 400 jours.

• Coût théorique d'écriture : 50 000 lignes × 30 minutes = 1 500 000 minutes, soit 25 000 heures, soit 3 125 jours de huit heures.
• Ratio : 400 jours ÷ 3 125 jours = 12,8 %.
• Note : C.

Le chiffre n'a de sens que comparé à lui-même dans le temps. Les 30 minutes par ligne sont une convention, pas un coût réel, et l'analyse statique ne voit ni l'architecture, ni les dépendances obsolètes, ni ce qui casse en production.

Sur mobile, trois mesures complètent donc le ratio. La première : le taux de plantage. Google Play fixe un seuil de mauvais comportement à 1,09 % de plantages perçus par les utilisateurs et 0,47 % de blocages de l'application (ANR), en moyenne sur tous les appareils. Au-delà, Play peut réduire la visibilité de l'application et afficher un avertissement sur sa fiche.

Source : Android Developers, Android vitals, page mise à jour le 9 octobre 2026

La deuxième : l'écart entre les versions de SDK (les kits de développement fournis par Apple et Google) et de framework utilisées et celles exigées par les stores, détaillé dans la section suivante. La troisième : la rétention, qui montre si les problèmes techniques font fuir les utilisateurs. Les repères par catégorie sont dans le taux de rétention d'une application mobile.

Quelles échéances Apple et Google rendent la maintenance d'une application mobile obligatoire ?

Sur le web, une dette technique peut dormir des années. Sur mobile, les stores fixent une date limite, et elle revient chaque année. La maintenance d'une application mobile n'est donc jamais optionnelle : une partie est imposée.

Source : Apple Developer, Upcoming Requirements, consulté le 12 octobre 2026

Source : Android Developers, exigences de niveau d'API cible pour Google Play, page mise à jour le 1er octobre 2026

Source : Android Developers, prise en charge des pages de 16 Ko, page mise à jour le 16 septembre 2026

La sanction Google est sournoise. Une application existante qui cible Android 14 ou moins n'est pas retirée : elle disparaît simplement pour les nouveaux utilisateurs dont le téléphone tourne sous une version d'Android plus récente que sa cible. Le parc installé ne voit rien, l'acquisition s'éteint.

Les pages mémoire de 16 Ko sont une évolution de la gestion de la mémoire des téléphones Android récents. Elle ne touche que les applications qui embarquent du code natif, directement ou par une bibliothèque tierce : selon Google, une application écrite uniquement en Java ou en Kotlin est déjà compatible.

C'est là que la dette technique devient chiffrable en jours. Monter le niveau d'API cible ou la version de Xcode, c'est souvent monter aussi les bibliothèques qui en dépendent. Une application longtemps restée sans mise à jour doit franchir plusieurs versions d'un coup. Le choix du framework pèse lourd ici, comparé en détail dans Flutter ou React Native ; et le passage en revue des stores, une fois la mise à niveau faite, est décrit dans publier une application sur Google Play et l'App Store. Si l'échéance tombe avant que l'écart de versions ait été mesuré, c'est par là que commence un audit de l'application.

Réparer, refondre ou réécrire son application : comment trancher ?

• Réparer : corriger les points bloquants sans toucher à la structure. Monter une version de SDK, remplacer une bibliothèque abandonnée, corriger les plantages les plus fréquents.
• Refondre : reprendre l'application module par module, en gardant en ligne la version existante. L'ancien et le nouveau code cohabitent jusqu'à ce que le dernier module ancien disparaisse.
• Réécrire : repartir d'une base vide, et basculer d'un coup.

1. Une échéance de store bloque-t-elle les mises à jour ? Si oui, la mise en conformité passe avant tout le reste. Si le framework ou une dépendance critique ne permet pas d'atteindre le niveau exigé, la question devient : remplacer cette couche seulement, ou tout le socle.

2. Quel est le ratio de dette ? La grille proposée ici s'appuie sur les notes Sonar. En A ou B, réparer au fil de l'eau suffit. En C ou D, refondre les modules les plus touchés, en commençant par ceux que l'on modifie le plus souvent.

3. Le seuil des 50 % est-il franchi ? McKinsey estime qu'au-delà d'une dette égale à 50 % de la valeur des actifs techniques d'un périmètre, le risque et le coût des systèmes existants dépassent leurs bénéfices. Il présente alors la reconstruction comme un dernier recours, aux conséquences lourdes, qu'on ne peut pas toujours éviter. La note E de Sonar commence au même seuil. Les deux mesures ne sont pas identiques. L'une rapporte une estimation de dette à la valeur du parc. L'autre rapporte un temps de correction à un coût d'écriture théorique. Le hasard des seuils les fait coïncider.

Même là, la réécriture reste un pari. En avril 2000, Joel Spolsky qualifiait de « pire erreur stratégique » la décision de Netscape de réécrire son navigateur de zéro : près de trois ans après la version 4.0, la suivante entrait tout juste en première bêta publique.

Source : Joel Spolsky, Things You Should Never Do, Part I, 6 avril 2000

Quand la décision penche vers la refonte, la méthode et les livrables sont décrits sur la page refonte d'application mobile.

Quelles erreurs transforment une dette en refonte forcée ?

Attendre l'échéance du store. Une mise à niveau de SDK lancée le mois de la date limite se fait sous contrainte, sans marge pour les régressions. C'est le scénario où une simple réparation finit en refonte d'urgence.

Mesurer la dette au nombre de lignes. Une application de 50 000 lignes en note A est en meilleure santé qu'une application de 10 000 lignes en note D. C'est le ratio qui compte, et son évolution d'une version à l'autre.

Réécrire pour changer de technologie. Une nouvelle base de code ne rembourse pas la dette : elle repart à zéro avec ses propres raccourcis, y compris lorsque le code est régénéré par vibe coding, pendant que l'ancienne version doit continuer à être maintenue. Si les fonctionnalités ne sont pas stabilisées, la nouvelle version court après l'ancienne.

Quels points vérifier lors d'un audit d'application mobile ?

Un audit d'application mobile tient en une liste de questions vérifiables.

Les quatre premières lignes ne sont pas des recommandations : ce sont des conditions de publication. Une application qui en rate une ne peut déjà plus, ou ne pourra bientôt plus, être mise à jour. La cinquième n'empêche pas de publier, mais Google Play réduit la visibilité de l'application qui la dépasse.

Le coût d'une remise à niveau se raisonne comme celui d'un développement, détaillé dans le prix d'une application mobile, et doit se comparer à ce que l'application rapporte, estimable avec le simulateur de revenus d'application : le calcul complet figure dans la rentabilité d'une application mobile.