Qui dit projet de développement, dit dette technique. C'est un phénomène inévitable : toute ligne de code écrite un risque de devenir de la dette technique.

Cette dette viendra impacter la vélocité de vos équipes - et donc la création de nouvelles fonctionnalités - mais aussi la stabilité de votre produit, voir vos capacités à attirer et conserver des talents.

Heureusement, il existe des méthodes et bonnes pratiques pour gérer - on dit parfois "payer" - cette dette, avant qu'elle ne devienne ingérable. Mais commençons d'abord par expliquer ce concept.

Comprendre la dette technique

Qu'est-ce que la dette technique ?

Définition et contexte : de la finance à l'informatique

La dette technique c’est toutes les concessions faites par une équipe de développement, le plus souvent pour respecter des délais serrés ou des objectifs commerciaux, au détriment de la qualité du code :

Application d'une solution sous-optimale (par exemple moins performante) ;
Non-respect de bonnes pratiques ;
Impasse sur les tests, etc.

C’est à Ward Cunningham, développeur et théoricien du développement, qu’on doit la popularisation du terme de dette technique. En effet, en 1992, lors d’une conférence OOPSLA, il utilise la dette financière comme métaphore pour présenter le concept :

“Quand on sort la première itération du code, c’est pareil que s’endetter. Une petite dette permet d’avancer plus vite dans le développement, à condition qu’on la rembourse rapidement après, par une réécriture. Là où est le danger c’est quand la dette reste impayée. Chaque minute où on se sert d’un code imparfait est un intérêt sur cette dette. Des entreprises de développement peuvent se retrouver complètement entravées par le poids d’une dette due à une implémentation non consolidée[...]” (Traduit de l’anglais)

Dette technique : un concept à nuancer

Si le danger qu'elle pose semble évident, il faut toutefois comprendre que contracter de la dette technique n'est pas forcément malvenue.

Au contraire, elle peut être une stratégie intentionnelle pour atteindre un objectif à court terme : on parle alors de dette technique volontaire.

De l'autre côté du spectre il y a la dette technique involontaire, où les erreurs humaines, le manque de communication au sein de l'équipe, le manque de suivi ou de contrôle qualité finissent par générer de la dette.

Pour classifier la dette technique selon son intentionnalité et sa visibilité, Martin Fowler, un théoricien de l’architecture logicielle, a développé le concept de quadrant de la dette dont voici une illustration possible :

Coût de la dette technique pour le produit et les équipes

Quand on accumule trop de dette technique, le produit devient de plus en plus difficile à faire fonctionner et évoluer : les nouvelles fonctionnalités sont de plus en plus longues à créer, et chaque modification risque d'entrainer des bugs supplémentaires.

On entre alors dans un cercle vicieux :

Chaque modification est longue et génère des bugs ;
Pour avancer le plus rapidement possible on va tendre vers des solutions rapides, mais sous-optimales (des "hacks" ou autre bidouilles) ;
et donc contracter encore plus de dette technique.

Enfin, cette spirale infernale va devenir très pesante pour l'équipe de développement, qui passe plus de temps à se battre avec la dette technique qu'à avancer sur de nouvelles fonctionnalités.

Cette charge augmente le turnover, et rend les recrutements plus difficiles : peu de développeurs aiment travailler dans ces conditions ! Un boulet dont les entreprises se passerait bien dans le marché du recrutement IT concurrentiel actuel.

Exemples de sources de dette technique

Des conventions mal respectées à travers le projet. Par exemple des équipes n'utilisant pas les même conventions de nommage, de syntaxe, etc. Les développeurs doivent jongler entre plusieurs conventions, et le code devient moins lisible ;
Un manque de documentation : l'équipe n'a jamais eu le temps de documenter le code, l'architecture, etc. Chaque départ entraine une perte de connaissance, et les onboarding deviennent de plus en plus long. Pire, certains problèmes ou fonctionnalités deviennent infaisables, ou beaucoup plus long.
Des bugs incompréhensibles ou à moitié réglés : des bugs résolus à la vite, sans connaitre la cause réelle ou sans que l'équipe ait pu aller au bout des choses, vont générer de nouveaux bugs difficiles à résoudre.
Des choix architecturaux mauvais, ou qui ne sont plus en adéquation avec le produit. On fait entrer des ronds dans des carrés, et tout devient plus dur.
Le code mort ou obsolète : c’est du code qui n’est plus utilisé par les équipes mais qu’on n’a pas retiré du logiciel ; le code mort est parfois difficile à repérer et en plus de ça, il peut sérieusement nuire aux performances, et compliquer la maintenance du code.

Pourquoi gérer la dette technique ?

On commence à bien imaginer l'impact de la dette, mais il intéressant d’aller un peu plus loin et de se demander pourquoi il ne faut jamais dépasser le stade de la “petite dette”, pour reprendre les mots de Cunningham.

Conséquences d'une gestion trop tardive

Plus la dette s'accumule, plus il devient difficile et coûteux de la rembourser. C’est pour cela qu’il faut réfléchir à des stratégies pour gérer la dette en continue (sur lesquelles nous reviendrons plus loin).

En plus des conséquences qu’on a déjà présentées sur le cercle vicieux et le moral des équipes, il faut aussi noter qu'une trop grande dette technique veut aussi dire ralentissement du développement des fonctionnalités à venir à cause d’un code devenu complexe. Les coûts de maintenance augmentent également, car il devient de plus en plus difficile de corriger les bugs et de résoudre les problèmes de performance connus.

Qui dit ralentissements et augmentation des coûts dit retards de livraison et donc problèmes de relation client pour l’entreprise, éventuelle répercussion sur la réputation de l'organisation, etc.

Bénéfices d'une gestion bien pensée et proactive

A contrario, en améliorant continuellement la qualité du code :

On réduit les bugs et les problèmes de performance ;
On livre des produits plus stables et plus performants ;
On facilite la maintenance du code ;
On réduit les coûts de développement à long terme ;
On gagne en agilité en tant qu’équipe.

Comment gérer la dette technique ?

En créer le moins possible : sensibiliser et former

Quel que soit le niveau de responsabilité au sein de l’équipe de développement, quand on code, on est souvent concentrés sur un ou plusieurs objectifs bien précis et dans le monde du numérique, quel que soit le produit, application web en SaaS ou encore fonctionnalité front-end à ajouter à un logiciel, le temps est toujours compté. Dans ces conditions, il est parfois difficile de prendre du recul et de rendre compte de l’importance de lutter contre l’accumulation de la dette technique.

C’est pourquoi il faut former les équipes de développement à la gestion de la dette technique et les sensibiliser à l’importance de la qualité du code.

De l'autre côté, les équipes produits et managers doivent eux aussi être sensibilisés à cet aspect, pour le prendre en compte dans leurs plannings et laisser du temps aux équipes pour créer le "juste niveau" de dette.

En créer le moins possible : outils et méthodes

Des outils dédiés, d'analyse de code par exemple, permet de s'assurer que des conventions sont respectées.

Ainsi, les linters sont d'une aide précieuse pour uniformiser une base de code. Des tests automatisés permettent d'éviter les regressions.

Enfin, des processus comme la revue de code ou le pair programming permettent d'améliorer le code, créant ainsi moins de dettes.

Mesurer : outils et KPI

Aujourd’hui, on dispose de plusieurs outils pour identifier et suivre la dette technique au sein d’une équipe de développement.

L’une des méthodes de suivi les plus indispensables est l’analyse statique du code : automatisée ou non, c’est une relecture pour identifier les erreurs logicielles ou les violations de règle, les mauvais patterns, les codes morts, bref tout ce qui génère de la dette technique.

Par ailleurs, il faut aussi s’assurer que les efforts fournis pour lutter contre la dette technique sont efficaces. C’est là qu’il faut choisir les bons KPI en fonction de votre projet et de votre équipe. Voici quelques exemples :

Complexité cyclomatique ;
Nombre de lignes obsolètes ;
Nombre d’itérations sur une période donnée.

Réduire : cycles de développement et méthode agile

Intégrer la gestion de la dette technique aux cycles de développement est nécessaire (sinon elle s’accumule) et est loin d’être insurmontable.

Cela peut se faire en y dédiant des temps spécifiques comme une heure par jour ou un jour par semaine.

Une des méthodes les plus efficaces, décrite dans Shape UP! de Basecamp, est d'avoir des "cool-down", des périodes de plusieurs jours voir plusieurs semaines ou l'équipe peut souffler et, notamment, régler de la dette technique.

La gestion de la dette technique s’intègre donc tout à fait aux méthodologies telles que Scrum :

les occurrences de dette technique sont ajoutées au backlog du produit et elles seront abordées à chaque sprint review pour déterminer qui doit se charger du refactoring et comment.

Le plus important : s'en donner les moyens

Tous les points précédents n'ont du sens que si l'entreprise donne des moyens concrets - financiers donc - pour régler sa dette technique.

Les équipes techniques sont souvent au courant du poids de la dette, mais les équipes produits peuvent avoir l'impression que les choses tournent bien, et ne pas voir l'intérêt d'allouer du temps à son remboursement.

Les jours dédiés dans les sprints disparaissent au profit de nouvelles fonctionnalités, les refactoring tant attendus prennent du retard, etc.

Pratiques de réduction de la dette technique

On a dit précédemment qu’il fallait former ses équipes pour éviter l’accumulation d’une dette technique trop importante et cela comprend bien évidemment un ensemble de bonnes pratiques.

Encourager la contribution positive et l’amélioration progressive

Il s’agit ici de culture d’équipe : il faut encourager une mentalité collective positive où chaque développeur devrait chercher à améliorer le code chaque fois qu'il y travaille, même si c’est par petites touches. Par exemple, en renommant une variable mal nommée ou en supprimant une ligne de code obsolète, etc.

Dans le même esprit, il peut aussi être pertinent de discuter régulièrement de :

l’état du code ;
comment l'améliorer ;
comment affiner les stratégies déjà en place.

Encourager ces petites améliorations au quotidien est assez intéressant car c’est moins risqué et plus facilement rectifiable qu’un gros refactoring qui viendrait tout mettre à mal avec de nombreux potentiels bugs.

Préparer et vérifier continuellement

L’idée est ici de choisir des noms de variables, de fonctions ou de classes les plus clairs possibles. Afin que n’importe quel autre membre de l’équipe puisse s’y retrouver facilement et rapidement. Exemple : une fonction nommée calculerTotalFacture est beaucoup plus explicite que ctf. Même chose pour les règles d'indentation, et de formatage du code.

D’une manière générale, bien documenter le code avec des documents annexes dès le départ permet aux développeurs de comprendre facilement le code existant et de le modifier sans introduire de nouvelles dettes.

Quant aux tests c’est le passage obligatoire pour s’assurer de la qualité du code et du produit en développement. C’est le seul moyen de savoir si quelque chose ne fonctionne pas.

Respecter le principe DRY

“Don’t Repeat Yourself”. Selon ce principe, on préférera créer des couches d’abstraction telles que des classes ou des fonctions plutôt que de dupliquer des lignes de code. Ces couches permettent de réduire le nombre d’opérations logiques nécessaires et donc un code inutilement long qui présente plus de risques d’erreurs ou de problèmes de performance.

Supprimer le code obsolète

Malheureusement, il arrive souvent que code obsolète se cache dans le reste du code, c’est donc un travail qui peut s’avérer fastidieux. Cependant, des outils spécialisés peuvent aider à trouver ces blocs de code inutilisés ou inefficaces, et des revues de code régulières peuvent également contribuer à identifier les zones problématiques. En effet, supprimer le code obsolète fait partie de ces tâches plus faciles quand elles sont faites petit à petit plutôt que d’un seul coup et souvent dans l’urgence.

En fin de compte, le plus important à retenir dans la gestion de la dette technique c’est cette dimension de permanence : c’est un effort qui ne doit bien sûr pas être dans l’esprit des développeurs à tout moment, mais qui doit être fourni suffisamment régulièrement et progressivement pour éviter de tomber dans un cercle vicieux dangereux pour la qualité du code, le bon fonctionnement du produit et le moral de l’équipe.

Quoiqu’il en soit un regard extérieur aide toujours à prendre du recul, alors si vous souhaitez des conseils d’expert en développement web, appli ou encore SaaS, Lonestone se met à votre disposition pour vous aider à mener à bien votre projet web. Contactez-nous !

À retenir : Comment calculer la dette technique ?

Qu’est-ce qui cause la dette technique ?

La dette technique peut être volontaire ou involontaire, dans les deux cas, cela est souvent dû à un souci de gain de temps. Pour schématiser, la dette technique survient lorsqu’on code vite mais pas de manière optimale. Cela correspond dans les faits à de nombreuses pratiques dont voici quelques exemples : laisser du code obsolète, nommer des fonctions de manière peu claire, dupliquer des lignes de code plutôt que de créer une classe ou une fonction, implémenter des patterns qu’on ne maîtrise pas, etc.

Comment évaluer la dette technique ?

En ce qui concerne les métriques, tout dépend de votre projet, de votre équipe et des délais et de la roadmap de développement. Au niveau des outils, il est évidemment fortement recommandé d’établir un backlog produit qui vous permettra de suivre l’évolution de la dette via les tories, bugs et différentes tâches exécutées.

C’est quoi la dette technique en scrum ?

Dans la méthode SCRUM la dette technique prend la forme de toutes les tâches à exécuter et à prioriser pour améliorer la qualité du code. Ces tâches sont indiquées dans le backlog produit et devront être attribuées à un ou plusieurs membres de l’équipe de développement qui devra ou devront s’en charger lors d’un prochain sprint.

Méta Description : Découvrez comment identifier, comprendre et gérer efficacement la dette technique pour améliorer la qualité du code et optimiser les performances des logiciels.