Qu'estce que la dette technique ? Comment la maîtriser ?

Concevoir des applications se fait souvent dans un souci du respect des délais. Mais, à trop vouloir réduire le temps de développement, cela peut se faire au détriment de la qualité du code. Si de nombreux chefs d’entreprise ont conscience qu’il y a un prix à payer pour créer un logiciel rapidement, ils ne saisissent pas forcément ce qu’implique de compromettre la qualité du code et son maintien sur la durée. Appelé « Dette technique », cela peut avoir des conséquences néfastes sur le budget de l’entreprise. Découvrez comment maîtriser cette dette technique.

LA DETTE TECHNIQUE : DÉFINITION

Un projet de développement logiciel inclut souvent une conception logicielle, formalisée ou non. L’écriture du code, si elle suit les bonnes pratiques, assure la cohérence du projet et facilite sa maintenance :

• corrective : corriger les bugs informatiques,
• évolutive : ajouter de nouvelles fonctionnalités au logiciel.

La dette technique survient quand les bonnes pratiques n’ont pas été respectées lors de l’écriture du code de votre solution. Dans ce cas, une conception logicielle négligée va induire des coûts futurs à rembourser sous forme de temps de développement supplémentaire, et des bugs de plus en plus fréquents. Il convient donc de régler la dette technique le plus tôt possible pour éviter de mobiliser inutilement vos équipes.

UNE DETTE TECHNIQUE PEUT ÊTRE INTENTIONNELLE OU NON

Une dette technique non intentionnelle est due à des malfaçons : non-respect de la conception, non-respect des règles de codage, etc. Il n’y a aucun bénéfice à retirer de ce type de dettes.

Une dette technique intentionnelle est calculée à l’avance. Puisque favoriser la qualité de la conception augmente la charge de travail, les développeurs d’un logiciel peuvent choisir de sacrifier la qualité pour en retirer un bénéfice. Par exemple, s’il faut rendre rapidement une nouvelle version du logiciel, respecter la conception idéale peut mettre en péril la livraison du produit. Dans cette situation, l’objectif (la sortie de la nouvelle version) est prioritaire. L’intentionnalité de la dette technique serait donc de contracter une dette à court terme pour favoriser l’évolution du projet à long terme. L’essentiel serait alors de rembourser cette dette rapidement, une fois l’objectif atteint, pour éviter l’accumulation des intérêts.

LES CAUSES DE LA DETTE TECHNIQUE

Lors du développement d’une solution, vous pouvez anticiper beaucoup de choses et passer une grande partie de votre temps à planifier votre projet ou à perfectionner votre code. Mais il y a toujours quelques éléments qui échappent à votre contrôle et qui peuvent entraîner une dette technique. Il s’agira :

• de la pression du temps : les équipes de développement publient souvent des applications qui ne sont pas complètes en raison de la pression pour livrer le produit dans un délai limité. Les équipes de développement peuvent même réduire les performances et la qualité pour arriver plus rapidement sur le marché.
• du changement constant : même les applications complètes terminées à temps peuvent être obsolètes lorsqu’elles arrivent sur le marché. Les attentes toujours croissantes des clients, la montée de nouvelles opportunités de marché, les nouvelles cyberattaques et le turn-over des développeurs créent des défis permanents pour les responsables informatiques.
• la technologie obsolète : le développement d’applications modernes implique généralement plusieurs langages de codage, frameworks et bibliothèques, qui peuvent devenir obsolètes ou ne pas être pris en charge chaque année. Le Python d’aujourd’hui pourrait être le Visual Basic de demain.

LES CONSÉQUENCES NÉFASTES DE LA DETTE TECHNIQUE

L’expert low-code OutSystems a interrogé de nombreux dirigeants informatiques à travers le monde sur la dette technique, son coût, ses origines et les solutions envisagées afin d’y pallier. Plus de 500 d’entre eux concèdent que cette dette est un problème contre lequel ils doivent lutter au quotidien. Les résultats de cette enquête sont édifiants :

• Les entreprises perdraient actuellement 6 000 € par seconde pour maintenir des lignes de code désuètes.
• En moyenne, les sociétés dépensent 28% de leur budget informatique à lutter contre la dette technique. Alors qu’à peine 33% de ce budget est alloué à l’innovation.
• Plus une entreprise grandit, plus ce problème s’intensifie : les Petites et Moyennes Entreprises dépensent 27% de leur budget informatique dans la dette technique. Les grandes entreprises dépensent 41% de leur budget informatique dans la dette technique.
• 51% des grandes entreprises déclarent que la dette technique nuit à la conquête de nouveaux marchés.
• 64% déclarent qu’elle aura un impact majeur sur leurs activités futures.
• 69% déclarent qu’elle limite leur capacité à innover.
• 32% disent que l’un de leurs plus gros soucis est l’apparition d’erreurs détectées uniquement après la commercialisation.

À QUEL TYPE DE DETTE TECHNIQUE VOTRE ENTREPRISE FAIT-ELLE FACE ?

Dans une quête de rapidité, la dette technique est-elle toujours néfaste ? Pour répondre à cette question, il est utile d’utiliser le « quadrant de la dette technique » de Martin Fowler. Ce quadrant catégorise le type de dette technique en fonction de l’intention et du contexte.

• Prudent et volontaire : quand l’équipe sait qu’elle accumule les intérêts. Pourtant, elle préfère faire face aux conséquences plus tard. Cette décision est acceptable si les enjeux sont suffisamment faibles ou si le gain d’une version antérieure est supérieur aux coûts de la dette technique.
• Imprudent et délibéré : lorsque l’équipe peut connaître les conséquences et les éviter, mais privilégie toujours la vitesse à la qualité.
• Prudent et par inadvertance : lorsque l’équipe apprend comment la solution aurait dû être implémentée après l’implémentation.
• Inconsidéré et par inadvertance : lorsque l’équipe n’a pas l’expérience et met en œuvre aveuglément la solution. L’équipe ne se rend pas compte qu’elle se met dans un gigantesque gâchis.

Le côté gauche de ce quadrant doit être évité à tout prix.

TROUVER LE BON ÉQUILIBRE ENTRE RAPIDITÉ ET QUALITÉ

La qualité et les performances des logiciels sont primordiales pour une bonne expérience utilisateur. La vitesse est, quant à elle, essentielle pour atteindre les objectifs commerciaux dans les délais. La gestion de la dette technique nécessite donc un équilibre entre qualité et rapidité.

La meilleure façon de gérer la dette technique est de travailler dessus en continu et de permettre à votre équipe d’ingénierie de :

• voir les problèmes de codebase,
• signaler et de consigner ces problèmes,
• les hiérarchiser et de les résoudre.

Il faut donc dans ce cas :

• Faciliter le suivi et la visualisation de la dette technique pour votre équipe,
• Avoir un espace via lequel votre équipe peut discuter de ces problèmes de base de code
• Intégrez votre travail de dette technologique dans votre flux de travail existant.

CONCLUSION

Si la dette technique n’est pas maîtrisée, elle peut très vite prendre de l’ampleur et impacter considérablement le budget de votre entreprise.

La pression infligée aux équipes pour produire les solutions toujours plus vite, le changement régulier de développeurs dans les équipes, ou bien l’obsolescence des langages et framework de développement sont les premières causes de cette dette technique.

Mais attention, toute dette technique n’est pas forcément néfaste. A vous de voir à quel type de dette vous faites face grâce au « quadrant » de Martin Fowler.

Enfin, pour la maîtriser, il vous faudra trouver le juste milieu entre rapidité et qualité. Entourez-vous d’experts pour cela. L’équipe de Premaccess conseille de nombreuses entreprises sur ce sujet. N’hésitez pas à nous contacter.