Dans un premier article a été défini le concept de dette technique ; un deuxième article exposait les différentes interprétations faites de cette dette technique. Mais comment et pourquoi cette dette technique apparait-elle ?
Apparition et emballement de la dette technique (3/5)
L’emprunt initial, les difficultés à rembourser
Plusieurs facteurs peuvent contribuer à l’apparition puis à la difficulté de remboursement d’une dette technique. Parmi ces facteurs à l’origine de la contraction initiale de cette dette, on trouve souvent :
- des dates de livraison trop serrées,
- des besoins mal spécifiés et/ou trop complexes,
- une collaboration insuffisante entre les parties prenantes,
- un manque de compétence ou des méthodes inadaptées ou mal appliquées,
- un turnover des équipes.
La capacité à rembourser aisément cette dette est ensuite entravée par différents paramètres, en particulier :
- le choix de coder des fonctions en dur (souvent par facilité de reprendre par défaut l’option habituelle),
- une documentation négligée,
- des tests mal (ou pas) exécutés,
- l’ajout de micro-services sans vision globale de l’architecture,
- ou encore une gestion de projet déficiente.
Des facteurs de différents types
Ces éléments d’apparition et de croissance de la dette ne sont bien sûr pas exhaustifs ! On observera toutefois qu’ils peuvent être classés en quatre catégories : processus, individus, projet, technologie.
Types de facteurs générant de la dette technique
La dette technique due à des écarts technologiques est particulièrement intéressante car elle ne résulte pas d’un choix originel malheureux, mais plutôt de l’évolution de l’environnement et du contexte (« le temps qui passe »), qui remet en cause les choix a posteriori. Dans ce cas, la dette est imputable à des événements extérieurs : obsolescence technologique, modification de l’environnement, émergence de nouvelles technologies plus performantes, etc. Ce sont là des aspects invisibles de l’évolution et du vieillissement naturel du Système d’Information.
On peut par exemple observer ce phénomène avec l’essor du DevOps. Toutes les applications développées « à l’ancienne » ne sont pas compatibles avec une évolutivité et une maintenabilité telles qu’attendues par les pratiques et outils actuels. La migration vers le Cloud, la containerisation ou encore la prise en compte de la mobilité peuvent également s’avérer compliquées pour un SI legacy.
Dans les prochains articles, nous traiterons de l’impact de la dette technique sur l’organisation et (enfin !) des moyens pour la maîtriser.
