Comme expliqué dans notre article Transformer la dette technique en atout stratégique : guide pratique, la dette technique n’est pas mauvaise en soi. Elle devient néfaste lorsqu'elle n’est ni clairement identifiée, ni maîtrisée. Et c’est précisément ce cas de figure qu’il faut éviter.

Pourquoi ? Parce qu'une dette technique hors de contrôle peut avoir un lourd impact financier et entraîner, à plus ou moins long terme, une baisse de la vélocité dans le développement, des difficultés à intégrer de nouveaux développeurs sur le projet, et la détection de bugs lors des tests ou par vos clients.

D’un point de vue technique, la dette technique peut prendre de nombreuses formes. Elle peut aller du manque de lisibilité du code (par exemple, des variables mal nommées ou un manque de commentaires) à des problèmes plus fondamentaux dans la conception structurelle du logiciel (comme l'utilisation d'un langage de programmation ou d'un framework inadapté).

Pour identifier une dette technique, le plus simple est de se baser sur les problèmes concrets et observables rencontrés dans le projet. Dans cet article, nous allons vous aider à identifier les symptômes visibles d’une dette technique, ainsi que les solutions qui s’offrent à vous dans chaque cas.

‍

Quand la dette technique se manifeste par… l’augmentation du temps de développement

Si vous constatez que les développements prennent de plus en plus de temps, il s'agit probablement d’une dette d’architecture. Ce type de dette survient lorsque la structure du logiciel, conçue sans anticiper les changements futurs, devient obsolète et contraint les développeurs.

Par exemple, si votre projet a subi des modifications importantes, vous pouvez rester dépendant d’une architecture dépassée. Imaginez une route qui contourne une enceinte carrée. Si l’enceinte est détruite, la route n’a plus de sens et il serait plus judicieux d'en construire une nouvelle.

La dette d’architecture impacte la maintenabilité, la scalabilité et l’évolutivité du projet.

Un autre exemple est l'utilisation d'une structure monolithique au début d’un projet. Si certaines fonctionnalités deviennent obsolètes et d’autres sont fortement utilisées, il peut être bénéfique de découper le logiciel en plusieurs services. On parle alors d’architecture en “microservices”. Bien que cela apporte des contraintes infrastructurelles et organisationnelles, cela facilite le développement et la maintenance de chaque service. De plus, cela permet d'éviter le "code mort" qui n'est plus testé ni maintenu.

Quand la dette technique se manifeste par… des erreurs dans les estimations de temps de développement

Si vous constatez de plus en plus d’erreurs dans les estimations de temps pour le développement, cela peut indiquer une dette dans le code. Ce type de dette résulte d'une mauvaise qualité de rédaction du code, incluant des complexités inutiles, des duplications de code, et un mauvais style, rendant le code difficile à comprendre et à modifier.

Complexités inutiles

Les complexités inutiles dans le code sont comparables à des phrases à rallonge pour exprimer des idées simples. Cela rend le code insupportable à lire et difficile à gérer, tout comme écouter quelqu’un utiliser 500 mots pour dire qu’il va acheter du pain.

Duplications de code

Les duplications de code sont problématiques car modifier quelque chose nécessite de le faire à plusieurs endroits souvent inconnus. C’est comme remplacer des prises électriques dans une maison, puis découvrir plus tard que certaines ne sont pas compatibles avec de nouveaux appareils.

Mauvais style

Un mauvais style de code englobe de nombreux aspects esthétiques. Comme pour un texte littéraire, la cohérence est essentielle pour faciliter la lecture. Des contresens dans une phrase rendent le texte difficile à comprendre, tout comme un code mal rédigé. Bien que le logiciel puisse fonctionner, la lisibilité et la cohérence du code sont cruciales pour sa maintenance et sa compréhension. Le code est une forme d’écriture qui doit avoir du sens et être lisible, même dans sa "langue bizarre".

Quand la dette technique se manifeste par… l’augmentation du nombre de bugs

Si vous constatez une recrudescence du nombre de bugs, cela peut être dû à une dette d’architecture et/ou une dette de tests. La dette de tests fait référence à un manque de tests automatisés, remplacés par des tests manuels. Tester manuellement chaque nouvelle version est chronophage et inefficace. Pour éviter cela, différentes sortes de tests automatisés peuvent être mis en place : tests unitaires, tests d’intégration et tests fonctionnels.

Tests unitaires

Les tests unitaires valident les fonctionnalités au niveau du code, en vérifiant tous les cas d’usage possibles (comme “1 + 1 = 2”). Ils garantissent que les nouveaux développements ne cassent pas les fonctionnalités existantes.

Tests d’intégration

Les tests d’intégration s’assurent que les interactions entre différents services fonctionnent correctement, par exemple que les API n’ont pas été modifiées. Si une API change, cela indique qu’un autre service pourrait être affecté et nécessiter des ajustements.

Tests fonctionnels

Les tests fonctionnels vérifient que le système fonctionne correctement dans son ensemble, en simulant les actions d’un utilisateur. Il existe autant de tests fonctionnels que de fonctionnalités dans votre service, comme le parcours de souscription. Ces tests devraient être mis en place en dernier, car ajouter des tests fonctionnels limite votre capacité à modifier l’interface utilisateur. Ils sont particulièrement utiles lorsque votre application est stable et mature, car chaque modification pourrait entraîner l’échec de ces tests.

Quand la dette technique se manifeste par… des difficultés lors de l’intégration de nouveaux développeurs

Si vous constatez que l’intégration d’un nouveau développeur prend beaucoup de temps, cela peut être dû à une dette dans le code ou une dette documentaire. L'une rend le code difficile à appréhender et l'autre n’aide pas suffisamment le nouveau venu à prendre en main le projet globalement.

Types de documentation

Il existe deux types de documentation : technique et du code.

• Documentation technique : comprend la structure du projet et les procédures internes, comme l’infrastructure des serveurs, l’installation, les méthodes de développement et de déploiement.
• Documentation du code : aide les développeurs à comprendre des algorithmes complexes. En théorie, la lecture du code devrait suffire, mais lorsqu'elle ne suffit pas, c'est une dette de code.

‍

Dette documentaire

La dette documentaire survient lorsque le code ou l’infrastructure évoluent sans mise à jour correspondante de la documentation. Cela peut être dû à un manque de temps ou à un oubli, surtout lorsque la documentation est séparée du code. Pour éviter cette dette, il est crucial d'intégrer l'ajout et la mise à jour de la documentation dans vos procédures de développement.

Conclusion

La dette technique, bien qu'initialement perçue comme une entrave, peut être gérée efficacement pour minimiser ses impacts négatifs. En identifiant ses symptômes tels que l’augmentation du temps de développement, les erreurs d’estimation, la recrudescence des bugs ou les difficultés d’intégration de nouveaux développeurs, vous pouvez prendre des mesures concrètes pour y remédier.

Adopter des pratiques comme l’optimisation de l’architecture, la rédaction de code propre, l'automatisation des tests et la mise à jour régulière de la documentation est crucial. Ces actions permettent de maintenir un équilibre entre rapidité de développement et qualité du code, assurant ainsi la pérennité et l’évolutivité de vos projets. En fin de compte, une gestion proactive de la dette technique transformera cette contrainte en un atout stratégique pour votre entreprise. Et si vous souhaitez avoir l’avis d’un expert sur le sujet, contactez-nous !