Y a-t-il une bonne et une mauvaise dette technique ?

En finance, on distingue la bonne dette - celle qui correspond à un investissement - de la mauvaise dette - celle qui sert à financer un fonctionnement. Si vous vous retrouvez, une fois la dette remboursée, dans une meilleure situation que si vous ne vous étiez pas endetté, alors on peut considérer qu’il s'agissait d’une bonne dette.

Est-ce qu’une telle distinction est pertinente quand il s’agit de la dette technique ?

La dette technique est un concept inventé par l’informaticien Ward Cunningham en 1992. Le terme vient d'une métaphore, inspirée du concept existant de dette dans le domaine financier, appliqué au domaine informatique. 

La dette technique concerne un projet de développement logiciel, ce qui inclut souvent une conception logicielle, formalisée ou non. L'écriture du code source, selon la conception définie, assure la cohérence du projet et facilite sa maintenance. 

Toutes ces réalisations nécessitent des investissements importants, parfois imprévus et qui peuvent constituer un gouffre financier pour certaines entreprises.

Est-il possible de distinguer une bonne dette technique d’une mauvaise ? Existe-t-il des dettes techniques après lesquelles l’entreprise se situe dans une meilleure situation ?

Qu’est-ce que le quadrant de la dette technique ?

Dans une entreprise, l’utilisation de logiciels à différentes strates du développement de celle-ci est indispensable : c'est pourquoi avoir une dette technique est inévitable. Toutefois, il faut savoir l’identifier, la catégoriser et l’expliquer.

Une méthode existe pour pouvoir facilement classer la dette technique : le quadrant de la dette technique. Cette représentation est indispensable pour mener une réflexion d’identification de la dette technique sur un projet existant. 

L’idée est de classer les projets de développement de logiciels en quatre catégories découlant de deux axes comme le montre le schéma ci-dessous : 

• L’axe Volontaire / Involontaire
• L’axe Excessive et imprudente / Modérée et prudente

En appliquant cette méthode de représentation, vous serez en mesure d'identifier si la dette qu’engendre votre projet est bénéfique (réfléchie et intentionnelle) ou néfaste (irréfléchie et involontaire) sur le long terme pour votre entreprise.

Bonne ou mauvaise, comment réduire la dette technique ?

La Definition of Done (DoD)

L’objectif de l’équipe de développement est de définir l’ensemble des critères qui peuvent être considérés comme « done », c’est-à-dire « finis », « terminés ».

Avec cette méthode DoD, l’équipe définit clairement un cadre avec des critères à vérifier à chaque nouvelle implémentation de fonctionnalité (User Story). Cette fonctionnalité sera « terminée » une fois l’ensemble des points vérifiés.

Voici un exemple de définition qu’une entreprise peut se fixer : 

• Mise en place des tests unitaires.
• Examen du code par les pairs
• Inspection du code
• Intégration d’une user story
• Vérification de la bonne documentation de l’user story 

La réalisation de ces objectifs indiquent que la nouvelle fonctionnalité développée sur le produit peut être considérée comme “terminée”. L’équipe qui gère la conception de la fonctionnalité doit être autonome. Cette méthode permet de ne pas avoir de mauvaises surprises et de coûts supplémentaires et d’imposer une rigueur à la hauteur des attentes de l’entreprise.        

Le test automatisé

Par définition, le test automatisé s’exécute sans l’intervention d’un humain contrairement au test manuel. L’automatisation des tests nécessite l’utilisation de logiciels informatiques afin de mettre en œuvre et d’exécuter les actions prédéterminées dans un script. Cela permet aussi d’analyser un parcours prédéfini.

Quels sont les avantages du test automatisé ? 

Il permet de gagner du temps et de l’argent. Des économies énormes sont réalisées sur les charges car l’humain est moins sollicité, si ce n’est pour effectuer la maintenance du test. Un autre atout est la rigueur au niveau des tests. Enfin, le test automatisé permet une flexibilité au niveau du temps : les tests peuvent être exécutés en dehors des horaires de travail des employés de l’entreprise.

Il existe 3 types courants de tests automatisés : les tests unitaires, d’intégration et fonctionnels. Ces trois tests sont souvent représentés sous la forme d’une pyramide décrivant les avantages et gains de chaque type de test.

Les tests unitaires qui testent de "petites" unités de code sont à la base de la pyramide. Ils ont pour rôle de tester chaque fonctionnalité extraite de manière isolée et d’observer les anomalies potentielles. Ils sont très rapides et faciles à exécuter.

Les tests d'intégration constituent le milieu de la pyramide. Ils vérifient si tout fonctionne correctement ensemble.

Enfin, les tests fonctionnels sont au sommet de la pyramide. Ils visent à simuler un parcours d'un utilisateur final sur l'application, depuis l'interface utilisateur, afin de faire marcher toute la structure du code. Ce sont les plus lents à exécuter car ils testent une partie beaucoup plus grande de votre code.

En combinant l’ensemble de ces tests, cela permet de limiter les erreurs de code à plusieurs niveaux et donc d’éviter des frais en cas de bug. Plus un bug est détecté tôt, moins son coût de correction est élevé !

L'intégration continue

L'intégration continue est un ensemble de pratiques utilisées en développement logiciel qui a pour objectif de vérifier à chaque modification de code source que celle-ci ne peut pas avoir de répercussions négatives entraînant une régression dans l'application développée.

En détectant les problèmes d’intégration au plus tôt lors du développement, cette méthode évite les pertes de temps des développeurs, ce qui permet de gagner en efficacité. Outre ces gains de temps, elle permet d'automatiser l'exécution des suites de tests et de voir l'évolution du développement du logiciel.

Le Feature Workflow Branching

Le workflow de branche par fonctionnalité (ou Feature Workflow Branching) consiste à séparer le développement de chaque fonctionnalité dans une branche adaptée plutôt que dans la branche principale (master). 

Cette encapsulation permet à plusieurs développeurs de travailler facilement sur une fonctionnalité particulière sans perturber la base de code principale. Cela signifie également que la branche principale ne contiendra jamais de code cassé, ce qui est un énorme avantage pour les environnements d'intégration continue.

Une autre alternative pour les développeurs est la technique du feature flipping qui consiste à activer ou à désactiver des fonctionnalités au sein d’une application.

Elle est d’un intérêt non négligeable dans le cadre d’une stratégie d’intégration continue, puisqu’elle va permettre :

• De déployer en acceptation voire en production des fonctionnalités non encore “releasées”, ou non encore testées, que l’on souhaite évidemment désactiver.
• De faire ce que l’on appelle de l’A/B testing, soit libérer des fonctionnalités pour certains utilisateurs en les cachant pour d’autres.
• D’activer sélectivement les fonctionnalités selon un planning préétabli.
• De dégrader partiellement les fonctionnalités d’un site en cas de situations critiques (surcharge, perte de services externes, etc.).

On peut comparer le workflow branching à un circuit en dérivation en électricité : si un appareil tombe en panne, les autres appareils branchés sur le circuit continueront de fonctionner.

Choisir une stratégie de gestion de branches qui facilite le déploiement rapide est donc essentiel pour avoir un meilleur contrôle du code et de son déploiement, sans impacter le code principal.

En conclusion

Il existe des dettes techniques qui n’ont pas été anticipés et qui sont la conséquence d’oublis et d’erreurs dans les processus de développement de logiciels. Ces dettes sont à éviter en utilisant les techniques mentionnées ci-dessus dans l’article. 

Toutefois, il est indispensable d’investir dans des logiciels de qualité pour rester compétitif, c’est pourquoi une dette technique peut être bénéfique du moment que l’apport de l’investissement compense le montant engagé et qu’il existe une réelle plus-value finale.

---

---