Si vous êtes développeur ou participez à un projet de développement, vous avez forcément déjà entendu parler de la « dette technique ». Ce concept, que nous allons expliquer en détails, est un vrai problème que l’on retrouve dans tous les projets informatiques. Inévitable, on peut cependant la maitriser ; et c’est de ça que nous allons parler dans cet article.
Dette technique : définition
L’expression « dette technique » a été popularisé par Ward Cunningham en 1992, dans le cadre du développement logiciel. Elle fait directement référence à la notion de dette financière, appliquée au monde de l’informatique.
Découpons ce terme pour en comprendre un peu plus le principe.
Dette
Comme on vient de le dire, la dette technique est une référence à la dette applicable dans le monde financier. Une dette (littéralement quelque chose que l’on doit) évoque la notion d’obligation de remboursement, avec des intérêts.
Appliquée au monde de l’informatique, la dette technique n’impose pas moins un coût financier important (car son remboursement nécessite des actions humaines, et donc coûteuses).
Et, comme dans le monde financier, il y a des bons et des mauvais payeurs, ces derniers ne faisant que retarder une échéance inévitable, avec une dette qui empire au fil du temps, et des intérêts qui s’accumulent.
Technique
Et, évidemment, cette dette n’est pas directement pécuniaire, mais technique. C’est à dire, on accumule du retard sur les technologies qu’on utilise ; retard qu’il faudra rattraper (rembourser) tôt ou tard.
Pour rentrer dans les détails, il s’agit souvent de frameworks ou d’autres outils qu’on utilise, qui finissent par périmer. Au bout d’un moment, il faudra forcément mettre à jour notre code pour qu’il soit toujours compatible, et bénéficie des correctifs et du support. C’est ça, la dette technique.
Typiquement, dans un projet de développement web, si on utilise une version d’un framework qui devient dépréciée, il faudra mettre à jour votre code pour bénéficier des dernières fonctionnalités et de son bon maintien. Plus on attend, plus le framework évoluera, et plus on aura à passer de temps pour modifier le projet. C’est là que la dette s’accumule et que les intérêts explosent.
Les raisons de la dette technique
Maintenant qu’on a défini ce qu’est une dette technique, expliquons un peu les raisons de celle-ci. Pour ce faire, nous allons partir du principe qu’il y a deux types de dettes techniques : la dette intentionnelle (ou assumée), et la dette non intentionnelle.
Dette intentionnelle
On parle de dette intentionnelle lorsqu’on laisse un retard technique s’installer consciemment. C’est le cas lorsque le projet ou la fonctionnalité sur lequel on travaille a une deadline serrée, par exemple. On passe un peu plus vite sur les bonnes règles de codage, moins de temps à comparer les différents plugins, moins de temps à écrire des tests.
Cela a deux conséquences : celle du respect de la date limite, et l’installation d’une dette technique partiellement évitable.
Comme celle-ci est intentionnelle, il convient de prendre en compte son remboursement dans le planning, dès le début du projet.
Dette non intentionnelle
La dette non intentionnelle est la pire, car, contrairement à celle volontaire, on ne peut pas vraiment estimer ses coûts, ne sachant pas son étendue. Pire, on peut complètement passer à côté du concept de dette technique, et la laisser perdurer sur de longues périodes.
Concrètement, les raisons d’une dette technique non intentionnelle sont souvent :
- Un mauvais respect des règles de codage (ou une non définition de celles-ci en interne) ;
- Une mauvaise communication entre les membres de l’équipe, les équipes et/ou le client, ce qui peut mener à l’utilisation de mauvais outils ;
- Des mauvais choix techniques (packages externes, frameworks) ;
- La non utilisation des tests, créant des bugs qui ne seront potentiellement jamais corrigés.
Cette liste n’est pas exhaustive. Il faut toujours garder dans un coin de sa tête qu’une dette non intentionnelle a beaucoup de chances d’être contractée, quoi qu’il arrive. Ainsi, même si on a l’impression de tout faire dans les règles, faire régulièrement des points techniques sur d’éventuelles dettes est recommandé.
Comment minimiser (ou rembourser) la dette technique ?
On va partir d’un principe clair : la dette technique ne peut pas être éviter. Pour la simple raison que la majorité des outils que vous allez utiliser (frameworks, API, plugins, etc.), évoluera, changera de version, dans le temps. Et à partir du moment où vous utilisez un outil périmé, une dette technique se créer.
En exagérant, on pourrait même dire que vous accumulez une dette technique dès la première ligne de code. Bref, la question ici ne va pas être d’éviter cette dette, mais de comment la minimiser, et de la rembourser.
Avant la conception
Déjà, il convient de prendre dès mesures dès la phase d’analyse, avant même que la première ligne de code ne soit tapée.
Voyons une petite liste des choses à faire avant la conception, pour éviter l’installation d’une trop lourde dette technique :
- Reconnaître l’existence de cette future dette, déjà ;
- Éviter de choisir uniquement les dernières technos à la mode, car moins stables ;
- Limiter le nombre de technos, frameworks et plugins que le projet utilise ;
- Bien choisir les modules (ou plugins) externes : prendre en compte le nombre de mainteneurs, d’étoiles sur GitHub et les dates de dernières mises à jour ;
- Former les développeurs (et l’équipe de développement en général) sur les bonnes pratiques et sur les technologies que le projet va utiliser ;
- Définir en interne des méthodologies (type TDD) et une liste de bonnes pratiques (règles de codage, notamment).
En respectant ces quelques points, les intérêts de la dette technique devraient s’en trouver déjà allégés.
Pendant la conception
Pendant la conception ensuite, il y a là aussi quelques astuces à appliquer :
- Inclure le remboursement de la dette technique en temps réel dans les plannings, notamment en cas de développement agile – cela évitera d’alourdir constamment la dette ;
- Écrire des tests, pour éviter de causer des bugs qui traineront pendant des mois, voire des années ;
- Faire des revues de code régulières, permettant aux développeurs de se rendre compte des erreurs des uns et des autres.
Là encore, il est important de prendre ces conseils en considération, si on veut éviter une dette trop lourde quand viendra la mise en production.
Après la conception
Enfin, une fois le produit (ou sa version 1, ou son MVP) poussé en production, il faut s’occuper du remboursement de cette dette et de ses intérêts. Lors de cette phase, on a tendance à relâcher un peu la pression et à penser aux prochaines features avant de consolider le projet déjà livré.
Pourtant, c’est l’inverse qu’il faut faire. Il faut plutôt penser à :
- Prévoir le remboursement de cette date dans les plannings de développement des prochaines features/correctifs de bugs ;
- Faire un état des lieux régulier sur les dernières versions de chaque outil externe utilisé sur le projet, et les conséquences en cas de non intégration des nouvelles versions.
Conclusion
En conclusion, la dette technique n’est pas quelque chose à prendre à la légère. Mise de côté ou sous-estimée, elle peut finir par coûter très cher à une entreprise. Comme on l’a vu, les raisons de cette dette peuvent être multiples, et plus ou moins bonnes.
Mais, dans tous les cas, il convient de la minimiser et de la rembourser, et mieux vaut s’y prendre tôt pour éviter d’accumuler les intérêts.
Avez-vous déjà eu à subir de lourdes dettes techniques ? Racontez-nous en commentaire !
