Quiconque souhaite évaluer la dette technique se heurte d’abord à un problème de définition. Ce terme, inventé dans les années 1990 par Ward Cunningham, désignait à l’origine le surcoût qu’une équipe devra payer plus tard pour avoir pris des décisions rapides aujourd’hui. Dans la pratique, cela se résume rapidement à une impression : le code est ancien, personne n’ose s’attaquer à certains modules, chaque modification prend plus de temps qu’elle ne le devrait. Or, une impression ne suffit pas à justifier un budget. Quiconque souhaite demander des fonds pour la refactorisation dans le cadre du prochain budget annuel a besoin de chiffres qui tiennent la route face à la direction et qui puissent être comparés au budget de l’année précédente.
Mesurer la dette technique consiste à mettre en rapport l'effort estimé nécessaire à sa résolution avec l'ensemble des coûts de développement. Dans la pratique, on utilise pour cela le « Technical Debt Ratio » et le modèle SQALE, tel qu'il est mis en œuvre par SonarQube. Ces deux indicateurs ne deviennent significatifs qu'au fil de plusieurs trimestres. Cet indicateur ne suffit pas à lui seul pour établir un budget, mais il permet d'engager le dialogue avec la direction.
Quel est le coût concret de la dette technique ?
L'ampleur du problème a été étudiée par McKinsey dans une enquête menée en 2020 auprès de responsables technologiques. Selon cette enquête de McKinsey (2020), 10 à 20 % du budget consacré aux nouveaux produits sert à réduire la dette technique. La même enquête de 2020 estime le volume de la dette technique à 20 à 40 % de la valeur de l'ensemble du parc technologique. 60 % des DSI interrogés par McKinsey en 2020 ont constaté une augmentation par rapport aux trois années précédentes. Selon cette même enquête, les entreprises pratiquant une gestion active de la dette ont déclaré consacrer jusqu'à 50 % de temps supplémentaire à des tâches créant réellement de la valeur, plutôt qu'à la maintenance courante.
C'est la part du budget alloué aux nouveaux produits qui, selon l'enquête McKinsey, sert à réduire la dette technique au lieu de financer de nouvelles fonctionnalités.
McKinsey, 2020
Ces chiffres proviennent d'une enquête menée auprès de cadres dirigeants et non d'une analyse technique de bases de code individuelles. Ils donnent une idée de l'ordre de grandeur, mais ne constituent pas des valeurs de référence pour votre propre entreprise.
Mesurer la dette technique : les indicateurs à prendre en compte
Un indicateur couramment utilisé est le « Technical Debt Ratio », c'est-à-dire le rapport entre les coûts liés à la résolution de la dette technique et les coûts totaux de développement. D'après une analyse de Sourcegraph datant de 2024, une valeur située dans la fourchette basse à un chiffre est considérée comme saine. Selon cette analyse de 2024, la tendance observée sur plusieurs trimestres compte davantage que la valeur absolue. Une équipe dont le ratio passe de 3 à 6 % a un problème, même si 6 %, pris isolément, ne semble pas encore préoccupant.
Le modèle SQALE, tel qu'il est utilisé par le logiciel d'analyse SonarQube, est également très répandu. Il convertit les violations des règles de qualité définies en un temps estimé de correction et le compare au temps de développement estimé pour l'ensemble du projet. Il en résulte un indicateur qui peut être comparé dans le temps, à condition que l'ensemble des règles sous-jacentes ne soit pas constamment modifié. Si l'équipe change d'outil ou de règles, la comparabilité disparaît. C'est précisément là que réside l'une des faiblesses de cette méthode.
| critère | Ratio de dette technique | Modèle SQALE |
|---|---|---|
| Base de calcul | Coûts de correction par rapport aux coûts de développement | Temps de correction estimé des violations de règles par rapport au temps de développement |
| Valeur indicative | Un pourcentage bas à un chiffre est considéré comme sain | Ce n'est pas une valeur de référence absolue, mais simplement une comparaison au sein d'un même référentiel |
| pertinence | Tendance sur plusieurs trimestres | Évolution tant que le référentiel de règles reste inchangé |
| Fin de la comparabilité | lorsque l'estimation des coûts change au sein de l'équipe | lorsqu'on change d'outil ou de référentiel |
Quand les indicateurs atteignent leurs limites
Le « Technical Debt Ratio » et le modèle SQALE mesurent ce qu'un outil d'analyse est capable de détecter : le code en double, les fonctions trop complexes, les tests manquants, les modèles obsolètes. Les choix architecturaux qui ne se révèlent néfastes qu'au bout de plusieurs années, comme une délimitation de module mal définie ou une base de données conçue pour un profil de charge différent, passent à travers les mailles du filet. Il en va de même pour les connaissances qui quittent l'entreprise avec le départ d'une seule personne.
Une équipe peut afficher un ratio de 2 % tout en restant prisonnière d’un système que seule une personne comprend encore. Quiconque souhaite mesurer la dette technique devrait donc noter par écrit ces « angles morts » à côté de l’indicateur. Les indicateurs constituent un point de départ pour la discussion avec la direction. Ils ne remplacent toutefois pas cette discussion. Quiconque présente un chiffre devrait donc également être en mesure de citer les deux ou trois systèmes pour lesquels, d’après sa propre expérience, ce chiffre s’avère trop bas. L’article explique à partir de quel moment une modernisation est plus rentable que de simples retouches Moderniser ou remplacer les logiciels hérités ? Un arbre de décision.
Donner la priorité au budget consacré à la refactorisation
Pour établir les priorités, une règle empirique s'impose : trier les modules en fonction de la fréquence des modifications et du taux d'erreurs, et non en fonction de l'impression subjective de certains développeurs. Un module qui est rarement modifié et qui présente néanmoins un aspect peu soigné peut être laissé de côté. Un module qui subit des modifications chaque semaine et qui génère un nombre d’erreurs supérieur à la moyenne doit figurer en tête de liste. Dans la pratique, il s’agit souvent de modules centraux tels que la tarification, la gestion des stocks ou le traitement des commandes, c’est-à-dire précisément les domaines où les erreurs ont les conséquences les plus coûteuses.
Lorsqu’une partie des dettes provient de code généré par l’IA, il est utile, avant d’établir des priorités, d’examiner séparément les risques liés à ces segments de code, car les failles de sécurité peuvent s’y confondre avec le désordre habituel du code. Consacrer entre 10 et 20 % du budget de développement au remboursement courant de la dette constitue un point de départ réaliste, comme le suggèrent également les chiffres de McKinsey pour 2020. Les entreprises dont les systèmes centraux sont particulièrement anciens se situent généralement dans la partie haute de cette fourchette.
Les chiffres de McKinsey proviennent d'une enquête menée auprès de cadres dirigeants, et non d'une analyse des bases de code individuelles. Ils donnent un ordre de grandeur, mais ne constituent pas un objectif à atteindre pour votre entreprise. De plus, le « Technical Debt Ratio » et le SQALE ne prennent en compte que ce qu’un outil d’analyse est capable de détecter. Une limite de module mal définie et les connaissances qui quittent l’entreprise avec le départ d’une seule personne restent invisibles dans ces deux indicateurs.
Interpréter son indicateur dans son contexte
Un ratio de dette technique de 6 % n'a que peu d'importance pour un module rarement modifié, mais en a beaucoup pour un système central soumis à de fréquentes modifications. Une discussion sur les modules concernés permet de replacer ce chiffre dans son contexte avant la prochaine session budgétaire.
Foire aux questions
Comment mesurer la dette technique sans outil ?
Même sans outil spécifique, deux symptômes permettent souvent de détecter ce problème. Premièrement, le temps. Une petite modification prend-elle aujourd’hui nettement plus de temps qu’il y a un an, alors que l’équipe n’a pas diminué en taille ? Deuxièmement, le comportement d’évitement. Y a-t-il des fichiers ou des modules que les développeurs préfèrent éviter lors de la planification, car personne ne sait exactement ce qui se passera s’ils s’y attaquent ? En discutant ouvertement de ces deux questions au sein de l’équipe et en comparant les réponses tous les quelques mois, on obtient une image utile de la situation, même sans SonarQube ni logiciel similaire.
Quel budget faut-il consacrer à la refactorisation ?
Une fourchette comprise entre 10 et 20 % du budget de développement consacré aux nouveaux produits correspond à ce que McKinsey a observé en 2020 chez les entreprises interrogées. Cela ne constitue toutefois pas une valeur figée. Un produit récent dont le code a peu évolué s'en sortira avec nettement moins, tandis qu’un système central vieux de dix ans, soumis à une fréquence de modification élevée, aura plutôt besoin de plus. Plutôt qu’un pourcentage fixe, il est plus judicieux de fixer un montant lié au ratio de dette technique mesuré et renégocié à chaque cycle budgétaire.
À quoi reconnaît-on qu'une refactorisation intervient trop tard ?
Un signe d'alerte évident est le fait que les estimations relatives aux nouvelles fonctionnalités soient régulièrement plus de deux fois supérieures à la réalité, car personne ne peut prévoir à l'avance les répercussions d'une modification sur le code existant. Un deuxième signe est la rotation du personnel, qui touche principalement les équipes travaillant sur les parties les plus complexes du système. Lorsque ces deux signaux se manifestent simultanément, un simple sprint de refactorisation ne suffit plus. Il faut alors mettre en place un programme s’étalant sur plusieurs mois, doté d’un budget spécifique.
torck développe Logiciels sur mesure pour l’industrie et le commerce, souvent sur des systèmes hérités où des dettes se sont accumulées inaperçues au fil des années. Les équipes de développement de Maxhütte-Haidhof, Vienne et Rabat reprennent régulièrement ce type de bases de code et savent à quel moment un indicateur sera utile lors de la prochaine réunion budgétaire et à quel moment il ne fera que générer de la paperasse. Le partenaire contractuel est la société allemande torck GmbH, ce qui garantit l’engagement nécessaire dans le cadre de programmes de refactorisation s’étalant sur plusieurs années. Si vous avez besoin d’une évaluation de votre dette technique, vous pouvez la demander lors d’un Premier entretien .
German 
English 
French