La dette technique ou comment transformer le rêve agile en cauchemar

Le terme de « dette technique » est utilisé en génie logiciel pour exprimer la complexité ajoutée à une application, en raison de décisions techniques voulues (ou non !) qui entraînent la livraison d’un produit de faible qualité. 

Par analogie à la dette financière, la dette technique doit être remboursée, tôt ou tard. Sinon, avec les intérêts, la dette augmentera et la faillite deviendra inévitable.  

Illustrer la dette technique dans un projet géré selon les méthodologies agiles

La dette technique consciente : confondre vitesse et précipitation

En partant de l’un des 12 principes du manifeste Agile « Livrez fréquemment un logiciel opérationnel avec des cycles court»nous pouvons être amenés à faire des choix techniques non pérennes pour livrer rapidement et à temps un incrément de produit. A ce moment, nous sommes tentés de nous dire que si nous passons du temps à chercher la solution parfaite, les organisations risquent de ne pas être satisfaites et de passer par les services d’un autre prestataire. Cependant, si une itération après l’autre, nous continuons de ne pas prendre le temps pour rembourser notre dette technique, elle ne fera que se creuser. Contracter une importante dette technique et ne pas respecter les remboursements, ni les intérêts vont mener à une accélération de la complexité du logiciel… et un retard de toutes les futures livraisons. Un véritable cercle vicieux se met en place !

La dette technique inconsciente : une équipe autonome ne naît pas du jour au lendemain

Au départ d’un projet, l’équipe responsable de la réalisation du produit n’a pas toujours toutes les compétences ou toute l’expertise nécessaires pour livrer un produit de qualité. De ce fait, l’équipe fait de mauvais choix techniques, sans même s’en rendre compte, dès la pose des premières briques. Au fur et à mesure de sa construction, le projet va gagner en complexité. Ces mauvaises décisions techniques sont différentes des précédentes, qui résultaient d’un choix tactique motivé par une priorité court-termiste

Quand une décision est stratégique, il est plus facile de convaincre les parties prenantes que la dette doit être remboursée. Malheureusement, lorsque le terme « dette technique » est utilisé pour désigner poliment une « mauvaise ingénierie », il est très difficile de mettre en place une stratégie de remboursement. Premièrement, il faut convaincre les parties prenantes qu’une mauvaise ingénierie est implémentée et qu’elle risque de causer des problèmes dans le futur. Ensuite, il reste à les convaincre que l'investissement en vaut la peine. Les différentes contraintes d’adaptation aux changements qui sont de plus en plus fréquents rend difficile, voire impossible, la dette zéro. Toutefoisil est possible de la minimiser en alliant deux stratégies, l’une préventive et l’autre corrective.  

La dette technique n’est pas une fatalité

Comment la prévenir

  • Grâce à de la transparence : l’impact des choix techniques réalisés par l’équipe de réalisation doivent être expliqués aux parties prenantes du projet 
  • Grâce à de l’excellence technique : investir pour former les développeurs aux bonnes pratiques de développement dans le code et dans les processus (principes SOLID, revue de code, TDD, DDD, pair programming…) est une nécessité ! 

Comment la résorber

  • Mettre en place du CI/CD et de l’analyse statique du code (SonarQube)
  • Améliorer les tests en augmentant et en automatisant leur couverture
  • Réserver du budget et planifier le traitement de la dette, ce qui consiste à estimer les coûts de mises à niveau, de migration ou encore de refonte dans le temps

La dette technique est une réalité dans tous les projets mais n’est pas une fatalité. Le devoir de tout manager agile consiste à la garder sous contrôle afin qu’elle n’explose pas au point de brider l’innovation ou de corrompre la qualité d’un projet.