Comment interpréter la dette technique de son entreprise ?

C’est quoi une dette technique ?

La « dette technique » est un concept inventé en 1992 par Ward Cunningham, un informaticien américain. Directement inspiré de la dette financière, ce terme évoque les saturations et systèmes obsolètes qu’il faudra éventuellement corriger et qui s’accumulent avec le temps.

En effet, alors que le prêt bancaire donne lieu à des intérêts de retard, des pénalités ainsi qu’à l’allongement de la période de remboursement en cas de non paiement, la dette technologique génère, elle, des coûts supplémentaires si l’on n’y remédie pas à temps. 

Sans correctifs réguliers, les coûts (temporels et financiers) de maintenance et d’évolutions augmentent. Il devient alors de plus en plus compliqué de corriger les malfaçons, les bugs et le code de mauvaise qualité. Il devient ainsi plus difficile de rembourser sa dette technique au fil du temps.

Il est commode de penser que la dette technique arrive avec le temps, au fur et à mesure du développement d’un projet. Cette dernière peut toutefois surgir dès les premiers instants du projet, lors de la phase de planification par exemple.

Il est en effet possible dès l’amorçage du projet d’opter pour un système déjà vieillissant, ou de remettre à demain une amélioration ou une mise à jour importante.

Comment évaluer la dette technique ?

Pour évaluer au mieux sa dette technologique, il convient d’étudier les sources potentielles d’obsolescence et de malfaçon des systèmes utilisés.

Reconnaître et anticiper le vieillissement des outils utilisés

La première source de dette technique se situe au niveau des bibliothèques et des composants choisis pour accélérer ou améliorer le développement du projet. 

Quand bien même on évite de choisir des outils vieillissants et que l’on opte pour un système de développement à la pointe de la technologie, il faut garder à l’esprit que cette nouvelle technologie n’est pas pérenne. 

Il est donc important d’anticiper ce vieillissement, afin notamment de faciliter les mises à jour des composants extérieurs à l’application, sans pour autant risquer de déstabiliser l’ensemble du code.

Fonder un projet sur des technologies non matures ou au stade de prototype

Si la recherche des outils les plus modernes et novateurs n’est pas une mauvaise chose en soi, attention à ne pas en faire trop et à recourir à des outils trop récents et instables, dont la pérennité dans le temps n’est pas encore assurée. 

Utiliser une technologie qui n’est pas encore arrivée à maturité est en effet un mauvais choix pour développer un projet. C’est prendre le risque de devoir effectuer un retour en arrière coûteux en termes de temps et d’argent, parce que la solution ne tient pas au final toutes ses promesses et qu’il faut repartir de zéro.

Un code source imparfait ou inadéquat

La source de la dette technique la plus facilement identifiable est sans aucun doute le code source. 

L’une des raisons de dette technique les plus courantes consiste en la trop grande complexité du code. La production du code sophistiqué, voire de trop bonne qualité, rendra plus difficile le travail d’un nouveau développeur chargé de le faire évoluer, ou lui apporter une correction. 

Un code effectué dans la pression, sans ligne directrice claire, et avec un manque de collaboration au sein de l’équipe, a toutes les chances d’être de mauvaise qualité.

Comment interpréter la dette technique?

Nous l’avons vu, la dette technologique est inévitable. Pire, si aucune décision n’est prise pour la résorber à temps, elle s’accumule et atteint un niveau important, paralysant presque les systèmes de l’entreprise.

En effet, la dette technologique, naît bien souvent du fait d’avoir opté pour une solution technologique, puis de s’être fondée dessus sans la faire évoluer.

Les solutions en question sont le plus souvent des logiciels comme des ERP, CRM, des systèmes de gestion comptables de caisse ou de gestion des stocks. 

Les solutions technologiques vieillissantes ne deviennent ainsi plus capables de s’adapter aux nouveaux besoins de l’entreprise, qui perd en agilité et en efficacité. Cette dernière investit alors beaucoup de ressources dans la remise à niveau et se détourne des tâches plus stratégiques.

Quel est le bon niveau de dette technologique / technique selon le secteur ?

Premièrement, il faut bien garder à l’esprit que la dette technique, lorsqu’elle n’est pas hors de contrôle, n’est pas toujours mauvaise et fait partie de chaque projet de développement logiciel. 

En effet, la dette technique devient un problème majeur lorsqu’elle est ignorée ou accumulée involontairement à cause de mauvaises décisions.

Il convient ainsi de trouver un équilibre et d’établir des automatismes destinés à gérer la dette technique et à la garder sous contrôle.

Privilégier les solutions technologiques les plus adaptées au projet

Avant de choisir la solution technologique sur laquelle fonder votre projet, vous devez vous assurer que cette dernière saura s’adapter à votre entreprise et répondre aux besoins spécifiques liés au projet. 

Cette technologie doit être mature, avoir fait ses preuves et faire encore l’objet de mises à jour régulières.

Le marché du numérique regorge de technologies de qualité variable, il est ainsi important de sélectionner les meilleures pour réaliser votre projet. 

De même, il est important de limiter au maximum le nombre de technologies utilisées dans le développement du projet afin de gagner en lisibilité et en efficacité.

Mettre en place de tests réguliers afin de vérifier l’évolution des systèmes

Les tests réguliers permettent de s’assurer que le comportement du code ou des systèmes technologiques sur lesquels est fondé le projet respecte bien les attentes et qu’il n’y a pas de  bugs ou de malfaçons.

S’il est vrai que ces tests accaparent les développeurs, qui ne peuvent pas travailler sur de nouveaux projets et nouvelles fonctionnalités, ils permettent de gagner un temps considérable dans la compréhension de l’apparition de nouveaux bugs. 

En effet, en cas d’erreur, il est alors facile de déterminer la source du problème et d’effectuer les corrections nécessaires.

Garder votre équipe motivée et définir des règles de qualité immuables

Pour limiter la dette technique, il est important de définir des règles de codage, de développement et des critères et bonnes pratiques que votre équipe sera tenue de respecter dans le choix des solutions techniques à retenir. 

Ces règles doivent permettre d’écrire du code de façon structurée pour que toute l’équipe soit en mesure de le comprendre et de le maintenir.

Il peut également être intéressant d’écrire régulièrement de la documentation technique à usage interne et la maintenir à jour. 

Cette dernière permet de maintenir un certain niveau d’expertise au sein de vos équipes et renvoie une image de rigueur quant aux efforts mis en place pour limiter la dette technique. 

Pour ce type de contenu, il faut privilégier les fonctionnalités complexes et celles pour lesquelles la connaissance n’est détenue que par une seule personne.

Conclusion

Ainsi, tout comme un prêt bancaire, la dette technologique engendre des coûts supplémentaires et des pénalités si on ne la rembourse pas à temps. Le code source écrit aujourd’hui deviendra irrémédiablement la principale source de dette technique du projet de demain. 

S’assurer de sa qualité, du respect des normes et des bons choix technologiques est sans aucun doute le meilleur moyen de conserver la maîtrise de la dette technique. 

Il est ainsi crucial d’analyser les sources de la dette technique au sein de l’entreprise et d’y remédier le plus rapidement possible. 

Plus fondamentalement, il est important de mettre en place des automatismes permettant à l’entreprise de prévenir et de corriger au fil du temps les bugs et malfaçons techniques.