Quand on évolue dans la tech, on entend souvent parler de « dette technique ». Je trouve ce terme assez galvaudé, car souvent, lorsque l’on me parle de dette technique, ce que l’on m’explique c’est que le code ne correspond pas au « standard » du développeur qui en parle.
Voir la publication originale
Cette dernière est republiée ici afin de ne pas dépendre entièrement d'une plateforme tierce.
Qui n’a jamais rencontré cette situation ? Un développeur arrive sur un projet et découvre une architecture qu’il ne connaît pas, des conventions qui diffèrent de celles qu’il a l’habitude d’utiliser. Bien souvent, on va qualifier ça de « dette technique ». Pourtant le code est fonctionnel, correctement maintenu et répond au besoin utilisateur.
En informatique et en développement, il n’y a pas de recette universelle. Une méthode ou façon que l’on peut appliquer partout de la même manière. Tout est une question de contexte et d’équipe. Ce n’est pas parce qu’un choix technique diffère de nos habitudes qu’il est mauvais.
Mais alors la dette technique c’est quoi ? C’est un compromis conscient et assumé entre vitesse et qualité. Autrement dit, c’est un choix délibéré, une solution imparfaite pour livrer du code plus vite avec l’intention d’y revenir plus tard.
Le problème survient lorsque la dette n’est pas identifiée, ni suivie. Lorsque les compromis établis s’accumulent sans que personne n’en ait conscience. C’est à ce moment que la dette devient toxique, lorsqu’elle devient durable et ralentit les équipes.
La dette technique, il faut l’identifier et la suivre, mais il ne faut pas confondre un choix intentionnel d’un choix qui diffère de nos pratiques personnelles.
