Crédit photo : Living on earth

Êtes-vous endetté techniquement ? Tout développement d’application générant nécessairement de la dette technique, volontaire ou involontaire, il y a fort à parier que votre code soit en dette. Toute la question est de savoir quel plan de remboursement vous envisagez.

Qu’est-ce que la dette technique ?

Lorsqu’on parle de Dette Technique dans le développement d’application, on fait référence à tout ce qu’on ne fait pas, ou mal, aujourd’hui, et qu’on devra faire plus tard à un coût plus élevé. C’est en quelque sorte la somme de tous les petits problèmes qui font perdre du temps au quotidien dans la vie d’un développeur.

Quand on code au plus vite et de manière non optimale, on contracte une dette technique que l’on rembourse tout au long de la vie du projet sous forme de temps de développement de plus en plus long et de bugs de plus en plus fréquents.

Si la question de la dette technique n’est pas nouvelle, c’est l’émergence d’outils comme SonarQube permettant d’analyser la structure du code qui a permis de sensibiliser sur le sujet.

Source : Wikipedia SonarQube

Allo, la commission de surendettement ?

Comme une dette financière, la dette technique en soi n’est pas grave : on vit très bien avec un peu de dette, tant qu’on en a conscience, et qu’on sait l’évaluer. C’est le surendettement que l’on veut éviter.

L’accumulation de dette technique correspond à différentes phases du projet : en début de projet, les contraintes sont fortes, la nécessité d’avancer rapidement pour donner l’impulsion de départ oblige à laisser filer la dette technique. Ce phénomène est parfois accentué par l’utilisation de technologies nouvelles. Une fois que le projet est viable, que la pression se relâche, il est alors temps de se pencher sur la dette accumulée et la corriger. La seule exception à cette règle étant le cadre de certains projets open source, sans contraintes financières.

Le projet se déroule en cycles d’itérations de développement; en fin de chaque itération, on mènera une première action corrective sur la dette technique pour éviter de la laisser croître trop rapidement. Au delà d’un certain seuil, on prendra des mesures de correction plus radicales pour se ramener à un niveau de dette acceptable. Ce qui donne une évolution de la dette comme le montre le schéma ci-dessous :

Source : Good and Bad Technical Debt

Zéro dette technique, une illusion ?

A contrario, il est utopique et contre-productif de viser le « zéro dette technique » : non seulement le coût d’un projet exempt de dette technique sera élevé, mais les délais de livraisons seront fortement impactés. Accumuler de la dette technique est un moyen de livrer plus rapidement si on n’a pas la possibilité d’augmenter les ressources sur le projet : il s’agit alors d’un risque calculé.

En résumé, plutôt que de considérer la dette technique comme un travers à éviter absolument, on la traitera comme un levier de la gestion de projet. Selon la phase dans laquelle on se trouve, lancement, stabilisation, accélération du projet, on utilisera la dette comme un outil de management, de la même façon qu’on augmenterait les ressources humaines allouées au projet. Un levier, certes, mais à utiliser avec précaution.

Dans un prochain article, nous verrons les différents types de dette technique, leurs origines et leurs solutions.

Se préparer à la dette technique