La dette technique, c’est quoi ?

C’est en 1992 que Ward Cunningham  amène le concept de dette techniques en le comparant au système financier. Tout comme une hypothèque ou un emprunt, il y a des intérêts qui courent et s’accumulent. 

On retrouve 2 types de dettes techniques : intentionnel ou non intentionnelle

Non intentionnelle

Une dette technique non intentionnelle c’est une erreur que les développeurs ont fait par exemple en ne respectant pas les règles de codage ou de conception.

Intentionnelle

Une dette technique intentionnelle est quant à elle une décision prise par les développeurs pour, par exemple, rendre une application disponible à une certaine date. Des raccourcis pris intentionnellement qui vont créer de la la dette.

Dans tous les cas, la dette technique va augmenter la complexité de votre solution et la rendre moins évolutive.

La dette, un fléau inévitable ?

Malheureusement, la dette reste inévitable.

A la première ligne de code vous avez déjà contracté une petite dette.

Elle peut être simplement liée au suivi (ou non) des mises à jour d’un framework ou des équipements que vous utilisez dans votre infrastructure. Elle peut aussi être représentée par la perte de connaissance technique avec des départs de personnels.

Prévoir un budget pour ne pas faire banqueroute.

Faut-il prévoir un budget pour s’occuper de la dette ! Bien évidemment. 

Le remboursement de la dette est un effort conséquent et devrait donc être intégré dans le budget de votre projet. Si cela n’est pas prévu vous ne serez pas enclin à réduire cette dette régulièrement.

Pourquoi rembourser la dette ?

Rembourser la dette vous permettra tout d’abord de vous assurer une certaine qualité de vos applications mais cela permettra aussi d’être capable de livrer autant de nouvelles fonctionnalités ou de mise à jour sur la même période de temps au fil des ans. 

Finalement cela permet aussi aux développeurs d’être plus confiant lors de modification de code et donc de travailler plus sereinement.

Nous souhaitons tous éviter le point de non-retour qui commence souvent par « Il faut tout réécrire! »

Avec le temps, l’équipe passe plus de temps à corriger qu’à créer de la valeur

Comment rembourser la dette technique ?

Pour minimiser la dette, il est important de définir des règles de codage et de qualité ainsi qu’un budget pour la traiter. Ces éléments représentent plus de temps à disposition des développeurs pour travailler sur la dette technique et la qualité de conception.

Mettre en place une intégration continue et un déploiement continu (CI/CD) fait aussi partie des bonnes pratiques.

Notre conseil “mangez en un peu tous les jours”. Payez les intérêts régulièrement par exemple à chaque itération (ou Sprint) pour vous assurer de ne pas accumuler des intérêts de retard.

Comment rendre visible et prioriser la dette technique ?

Pour pouvoir travailler sur votre dette, il faut d’abord la rendre visible puis la prioriser. Nous vous conseillons d’inclure ces éléments dans votre backlog comme source de travail de l’équipe.

Dernièrement, nous avons proposé un workshop qui permet d’atteindre ces objectifs. Vous pouvez télécharger son déroulé en cliquant sur l’image ! Plus d’excuse pour amener de la visibilité sur votre dette !

Notre workshop canvas autour de la dette technique

Conclusion

La dette technique est un vrai fléau que nous retrouvons régulièrement chez nos clients. Ne répétez pas les mêmes erreurs, investissez le plus tôt possible pour vous assurer une pérennité !