La dette technique est un des sujets les plus sensibles dans les équipes IT, chez les éditeurs, chez les développeurs. Que signifie une dette technique ou même plus largement le legacy qui est une des formes de la dette technique. 

Une des définitions que nous pouvons donner est : la dette technique est tout élément informatique déployée, en production ou non. Par exemple, une application desktop développée il y a plusieurs années qui fonctionne toujours mais qui n'a jamais été migrée ou réécriture pour suivre les évolutions de la pile technique ou encore un site web "historique" qui tarde à être mis à jour. Côté éditeurs, la dette technique peut s'illustrer de nombreuses manières :

- supporter des OS anciens de 5 ou 6 ans 

- supporter des architectures matérielles anciennes qui ne sont plus commercialisées par un constructeur

Prenons l'exemple d'un navigateur web. une des dettes techniques est générée par le support d'OS "anciens" ou de CPU 32 bits. Continuer ce support mobilise du temps et des développeurs. Il faut vérifier que les builds fonctionnent de la même manière, si besoin en retirer des fonctions nécessitant une CPU récente. Les tests se font alors sur l'ensemble des configurations possibles. Cela oblige à maintenir un parc matériel fonctionnel. Cela oblige aussi à multiplier les binaires : binaires par architecture CPU, binaires selon les OS et les différentes versions d'OS (si besoin). Certains binaires peuvent embarquer plusieurs cibles matérielles.

Régulièrement, les éditeurs retirent telle ou telle compatibilité pour simplifier le processus de développement et réduire les plateformes supportées. Cela permet de recentrer les équipes et de nettoyer le code. Quand vous lisez les notes de version de langages ou de frameworks, très souvent, il est indiqué les fonctions ou API qui sont retirées du core code. Le code "mort" qui reste dans les projets pèse forcément sur les builds et la taille des binaires. 

Cette dette technique représente donc une charge pour les équipes, un coût en temps et en € et des risques de sécurité. Quand vous avez des sites déployés sur des PHP non supportés, vous introduisez un risque de sécurité car la stack n'est plus mise à jour. Or migrer vers une version récente si vous êtes sur des versions N-2 ou N-3, ne s'improvise pas. Il faut définir le cadre de la migration, vérifier que les codes passeront sans encombre, modifier les codes et les dépendances si nécessaire. Le chantier sera automatiquement plus long et plus sensible.

Pour les apps mobiles, les OS obligent souvent à suivre les évolutions d'une manière ou d'une autre. Sur le web, c'est moins le cas. Vous pouvez fonctionner sur une stack serveur qui a 5 ans sans évolution majeure. Par contre, quand vous déciderez de déployer une stack à jour, votre app web risque d'être fortement impactée. 

Il n'y a pas de réponse universelle. Une dette technique est à la fois une opportunité mais aussi un boulet qui peut impacter les équipes et les évolutions futures. Tarder la migration, ou la réécriture, plus ce sera pénible. De nombreuses applications fonctionnent dans les entreprises sans avoir été migrées. Nous entendons souvent les mêmes arguments : l'application fonctionne, elle remplit son rôle, nous en avons besoin, personne ne sait comment elle fonctionne réellement et les dépendances ne sont pas ou mal maîtrisées, nous n'avons pas le temps ni le budget pour réécrire.