Sur quelle dette technique informatique se concentrer en premier ?

Commençons par la définition

La dette technique, c'est l'ensemble des écarts et des compromis pris lors du développement d'un logiciel ou d'un système informatique, par rapport à des bonnes pratiques ou standard. Ces écarts, problématiques, peuvent résulter de décisions visant à accélérer le développement ou à réduire les coûts, mais qui compromettent la qualité, la maintenabilité et la performance du logiciel. La dette technique s'accumule au fil du temps si elle n'est pas traitée, ce qui peut entraîner des problèmes graves à long terme. Elle doit être gérée, en l'évitant et en la résorbant pour garantir la pérennité et la qualité des logiciels sur le long terme.

Mais toutes les dettes techniques n'ont pas la même gravité. Voyons sur lesquelles se concentrer:

- La dette technique sur le style du code

Lorsque cette dette technique devient trop important, la lisibilité du code devient moins bonne. L'analyse d'impact sur un bug devient moins fiable (la recherche d'une séquence de code buggué pour retrouver une autre occurence ne donne rien car la syntax de code diffère par exemple). Les possibiltés de merger des évolutions via son outils de versionning se réduisent du fait de conflit généré par 2 syntaxes de code différentes alors que le code est bien fonctionnellement identique.
Cette dette technique est la plus simple à corriger. Des outils peuvent souvent corriger la réduire en grande partie de manière automatique (exemple en PHP: Qodana, Scrutinizer, PHPStan...), et même si la dette accumulée est importante, les conséquences sont moins nuisibles que les autres cas. Il y a donc plus important...

- La dette technique sur les défauts de commentaires de code ou documentation

Si les commentaires décrivant le role d'une méthode, fonction, ou partie de code n'est pas renseigné au fil de l'eau, on perd une infirmation importante pour la suite du projet. Toutefois, elle peut aussi se rattraper à un coup, certes proportionnels au nombre de lignes de codes, mais qui reste gérable. Il est aussi possible de faire ce rattrapage petit à petit. Il y a des dettes bien plus graves...

- La dette technique sur la logique et l'algorithmique du code

Souvent amené par des développeurs débutants, moins par les développeurs expérimentés, on retrouve dans cette dette de la duplication de code, des bugs latents qui n'apparaissent que bien plus tard, des défauts de performances qui peuvent s'aggraver avec le temps, un code difficile à comprendre, voir beaucoup trop de code produit par rapport à ce qui sera faisable. Mais la encore, c'est un type de dette qui peut se rattraper moyennant un investissement en temps de développeurs aguerris, vous savez, ceux qu'on appelle les "pompiers du code" (réécriture des codes complexes, factorisation de code dupliqué, ...). Plus couteuse que les précédentes, elle peut aussi être rattraper petit à petit. Il y a encore plus grave...

- Le défaut d'architecture applicative

La, cela devient sérieux. Un mauvais choix d'architecture technique (choix d'un framework trop monolitique, d'une technologie "tendance" mais qui va tomber en désuétude une fois l'effet de mode passé, usage de librairies ayant de nombreuses dépendances profondes, ...) génèrera très vite un surtcoût au projet. Les dégats sur le long terme seront considérables. Devoir changer de framework trop monolitique oblige souvent à devroir réécriture et recommencer de zéro la partie codage. Les composants et librairies externes qui sortent de la mode, ne seront plus maintenus et seront source de faille de sécurité impossible à corriger (car la compétence est dans l'application métier développé et non dans ces composants externes utilisé comme prêt à l'emploi).
C'est la première dette technique à éviter absolument car celle ci est léthale sur un projet. Choisissez vos couches techniques sur la base de la pérennité et de leur capacité à résister au temps plutôt que sur leur côté tendance du moment. Intégrer dans votre manière de développer des couches d'abstractions: Exemple pour générer un graphique sur la base d'une librairie externe, piloter cette librairie par votre propre classe utilitaire, le reste de votre code devra s'appuyer sur cette classe utilitaire et non sur la librairie externe. Le jour où il y a besoin de changer ce composast externe suite aux évolutions technologiques, l'impact est centralisé sur la classe utilitaire rendant l'analyse d'impact facile à faire et le travail de remplacement beaucoup plus simple.
Mais si cette dette technique doit absolument être évitér car très couteuse à corriger lorsqu'elle a trop dérivée, il y a bien pire...

- Le défaut du modèle de donnée

Avant tout développement, penser aux données qui seront à gérer et comment elles seront structurées, sans penser aux problématiques du code. Leur stockage et organisation en base de données doivent coller à la réalité, pas à la vision de l'écran qui sera développer à venir. Imposez vous de respecter la forme normale de données, autant que possible, même si en apparence, cela semble devoir générer plus de développements. Les défauts dans la structure de la base de données sont encore plus mortel que les défaut d'architecture.
Ils peuvent générer des applications inutilisables lors de montée en charge, vont générer du code incompréhensible ou des bugs en pagaille qui augmenteront de manière exponentielle avec la quantité de code si la structure de donnée n'est pas correct. Les écrans avec le temps auront des temps de réponse de plus en plus mauvais dès qu'on devra faire évoluer le besoin initial simple avec un besoin plus proche de la réalité.
Ces types de défauts sont encore pire que les précédents, car corriger une dette sur l'organisation des données nécessite de revoir les tables et colonnes et par conséquent de redevoir écrire le code qui accède à ces données (comme pour la dette de défaut d'architecture, il faut refaire le code), mais pas uniquement : Les données devront aussi être "redressé", splittés ou fusionnées pour être stocker différemment. Et parfois cela n'est juste pas possible car la donnée initial avait été stocké de manière trop aggrégée. C'est la double peine ! Le code doit être refait, mais on doit aussi accepter de perdre une parti de ses données ou devoir écrire encore plus de code jetable pour tenter un rattrapage.
N'oubliez pas que si votre base de donnée est bien organisée, et en phase avec la réalité de la vie, les développements, même réalisés par des codeurs débuttants resteront claires. Dans le pire des cas, ils seront superflus, ce qui nous ramène à la dette technique 3, qui peut se rattraper à moindre coût.
Inversement, une base de donnée mal structurée vous enfermera probablement à vie dans les problèmes. Dans les gros projets d'entreprises, c'est souvent cette dette technique qui est à l'origine de l'abandon complet d'un projet car, elle provoque des dégats, dès les premières évolutions fonctionnelles ou besoin de corrections de spécifications initiales (ce qui sera toujours nécessaire sur de gros projets) et l'ampleur du surcoût d'une telle dette ne fait qu'aller en augmentant de manière exponentielle.

Et la dette technique sécuritaire ?

Par définition, une dette technique est un défaut de code ou de conception, par rapport à des bonnes pratiques ou standard, volontairement remis à plus tard pour des raisons de cout, de délai, ou de sujet non prioritaire. Hors la sécurité doit, de nos jours, être toujours un point prioritaire (aussi bien en architecture, conception qu'en coding). Aussi je suis parti du principe qu'elle n'existait pas (une faille x ou y détectée en pentest relevant plutôt du bug de vulnérabilité que d'une dette volontairement contractée). Mais il est clair que si elle existe sur un projet donné ayant vocation à passer en production, elle prend la pôle position !

En conclusion

Bref, pour un projet qui a besoin de durabilité, soyez très vigilents et pragmatiques sur vos choix d'architecture applicative (certains vous reprocherons de ne pas être à la mode, ignorez les, on ne choisit pas une architecture juste pour se faire plaisir. 10 ans après, votre projet sera toujours la, pas le leur), mais surtout soyez intransigeant sur votre modèle physique de donnée: Pensez stockage et liaison de vos tables telle que c'est dans la vrai vie (et non telle que l'écran, traitement ou fonction attendue semble le demander). Pour ces 2 cas de dettes, même les meilleurs "Pompiers du code" ne pourront plus rien faire si la dette s'est trop accumulée... à part laisser bruler, alors vous savez sur quoi vous consacrer.