Que cela soit pour les développeurs ou la direction d’une entreprise, la dette technique est un enjeu primordial. Un code obsolète, une implémentation mal consolidée peut engendrer beaucoup de complexité, des coûts importants et des problèmes qu’il faut compenser par des efforts supplémentaires. En tant que prestataire cloud reconnu dans toute l’Europe, nous sommes évidemment confrontés à ce défi permanent. Dans cet article, nous partageons notre expérience sur cette problématique à travers l’un des produits phares de notre suite d’outils de productivité en ligne, l’interface web qui permet de gérer sa messagerie ligne.

La dette technique est souvent écartée des priorités, car elle ne génère pas de valeur immédiate pour l’entreprise, mais elle peut rapidement devenir un poids mort qui empêche tout progrès futur. Julien Arnoux, VP of Engineering

La dette technique : une bombe à retardement qui peut avoir un impact critique sur le business 

Livrer des fonctionnalités plaît au marché. Alors souvent on accélère, quitte à faire l’impasse sur les anciennes parties du code dont « on s’occupera plus tard ». Mais quand les objectifs métier balaient la qualité du code sous le tapis, voilà ce que ça donne :

Chez les développeurs : c’est la frustration

Chaque itération augmente la dette. Pourtant on continue d’évoluer sur des bases logicielles créées il y a X années et qui ne correspondent plus forcément à ce qu’il faudrait aujourd’hui. On ne peut pas utiliser les derniers langages, les machines en préprod ne sont pas identiques aux machines de prod… On s’inflige des pratiques désuètes avec des blocages qui se multiplient et les risques d’erreurs également. Du coup, on ne touche plus à rien de peur de tout casser. La montagne de tâches d’ingénierie s’agrandit, le stress gagne les équipes qui perdent des ingénieurs à cause de la pénibilité du travail.  

Du côté des managers : c’est l’incompréhension

D’habitude on règle les problèmes par des « quick fix », mais il faut désormais deux semaines juste pour changer des boutons dans l’interface. Pour essayer d’atteindre des échéances irréalistes, on met la pression sur les développeurs qui « manquent de rigueur » alors qu’ils doivent constamment lutter contre les problèmes techniques et les bugs. La productivité chute et la motivation peine à résister.

Pour la direction : rien ne va assez rapidement

L’argent et la viabilité sont en jeu. Pourquoi faut-il autant de temps pour délivrer de la valeur ? Pourquoi le site est-il lent ? Pourquoi moderniser le code alors que cela ne résout aucun des problèmes exprimés par les clients ? Les décisionnaires peuvent par exemple être tentés de compenser les ralentissements par une solution immédiate comme ajouter de la puissance serveur alors que cela ne résout pas la dette technique sous-jacente qui continuera d’impacter de plus en plus la qualité du code à long terme.

Les chiffres parlent d’eux-mêmes : dans les entreprises, la dette technique serait responsable de +10% à 20% de coûts sur chaque projet, de résolution de problèmes jusqu’à 13.5 heures/semaine par collaborateur et environ 30% du budget informatique annuel.

Si on ne trouve pas l’équilibre, on va droit dans le mur. Les risques sont clairs :

  • Perte de vélocité
  • Problèmes de sécurité
  • Démotivation des équipes (technique et produit)
  • Logiciels de mauvaise qualité

Mais de quoi parle-t-on exactement avec la dette technique ?

La dette technique, c’est la différence entre le code actuel et ce qu’il devrait être dans l’idéal. Donc, plus le logiciel est de mauvaise qualité, plus la dette est importante.

Elle est inévitable, qu’elle soit intentionnelle ou pas 

On peut sacrifier la qualité du code pour en retirer un bénéfice, si on a un time to market très court ou qu’un retard de sortie d’une nouvelle version est financièrement intenable par exemple. Dans ce cas, la prise de dette est intentionnelle, mais le plus souvent elle ne l’est pas, car la dette technique est inhérente à notre métier.

Elle augmente avec chaque ligne de code 

Plus on avance dans les itérations, plus on augmente la complexité logicielle et le désordre.

Le premier problème est la complexité essentielle de notre métier. Pour le Service Mail, cela revient à pouvoir interagir avec un serveur mail de manière rapide et efficace et mettre à disposition une API consommable par une webapp et des applications mobiles.

Puis la complexité accidentelle arrive avec les problèmes imputables à la mauvaise qualité du code. Elle dépend aussi des choix techniques que l’on fait, par exemple :  lors de la refonte de la précédente version du Service Mail, une partie de la codebase a été récupérée de la toute première version écrite il y’a plus de 15 ans. Celle-ci utilisait un autre système de stockage pour les e-mails. Nous avons donc hérité de tout un tas de complexité inutile alors que nous n’utilisons plus ce système depuis longtemps.

Et pour finir le désordre naturel (l’entropie logicielle). On commence par une base logicielle simple à laquelle on ajoute des modules au fur et à mesure de la vie d’une application. La logique finit par s’enchevêtrer et devient difficile à comprendre surtout si un développeur quitte l’équipe. On se retrouve avec des morceaux de code qui ne servent plus à rien, mais qui augmentent la complexité :

 

 

Ce qui arrive quand la dette technique s’accumule

On finit par passer plus de temps à compenser les difficultés plutôt qu’à créer des fonctionnalités et ajouter réellement de la valeur au logiciel :

 

 

Alors, comment faire pour affronter la dette technique ?

C’est une question d’équilibre, le compromis entre la qualité et le coût, est presque la donnée de base dans le développement logiciel.

Commencer par la rendre visible

Il est important de convaincre tout le monde : ses collègues, son manager, sa direction. Pas si facile ? Il est essentiel de traduire la dette technique pour les managers et les CEO en expliquant les points suivants :

  • montrer les gains à court terme compromettent la compétitivité à long terme;
  • expliquer que les problèmes techniques se transformeront en perte de clients;
  • sensibiliser au fait que le code obsolète réduit la prévisibilité et rend le projet opaque.

« Moderniser son code n’est pas un snobisme de développeur ». C’est une nécessité pour le business :

Les équipes qui réduisent leur dette technique libèrent jusqu’à 50% de temps en plus pour créer de la valeur.

Stopper l’hémorragie pour éviter l’accumulation en cours

On ne va pas changer la culture d’une équipe du jour au lendemain, mais il faut être conscient des facteurs aggravants pour les limiter au maximum :

  • délais intenables
  • mauvaise définition du besoin
  • mauvaise organisation de l’entreprise (silotage des équipes)
  • manque de connaissance métier
  • sur le plan technique : mauvaises pratiques, pas de doc, over-engineering, pas de tests, etc. 

3 principes qui peuvent aussi aggraver la dette :

  • Aucune solution miracle. Les frameworks qui promettent de régler tous les problèmes n’existent pas.
  • Éviter le mimétisme : « Netflix fait des microservices », « Google est en monorepo ». Faire la même chose que les autres « parce qu’ils le font » ne produira pas les résultats attendus dans un contexte différent (voir Culte du cargo). 
  • Le syndrome de la fenêtre brisée : c’est l’idée que si on laisse une fenêtre brisée dans un bâtiment sans la réparer cela va inciter à l’incivilité et la dégradation d’autres fenêtres du bâtiment, puis des murs, puis du quartier, etc.. C’est très fréquent dans le logiciel : on hésite moins à pousser un morceau de code médiocre si l’état général du code est déjà mauvais et on se retrouve avec une montagne de code spaghetti à maintenir.

Quelques principes à appliquer pour l’éviter :

  • La règle du boy-scout : s’attacher à laisser le terrain (code) aussi propre après son passage qu’on l’a trouvé en arrivant. Merci pour les prochains 😉 
  • K.I.S.S. : Keep it simple stupid (faire simple, c’est compliqué, mais faites-le quand même).
  • Y.A.G.N.I. : You ain’t gonna need it (nous les développeurs ont est très doués pour rajouter des choses « au cas où » on en aura besoin…) 
  • D.R.Y. : Don’t repeat yourself (au lieu de dupliquer son code, on essaie au maximum de le factoriser d’une autre manière).

De manière générale, les techniques de craft sont une bonne ressource.

Comment rembourser la dette technique existante ?

Maintenant on s’attaque au gros du morceau. Si on veut avoir le maximum d’impact : 

  1. Identifier les zones à risque pour la dette technique.
  2. Illustrer les bénéfices à les traiter
  3. Catégoriser : sécurité, maintenabilité, automatisation, quality assurance, continuous integration…
  4. Prioriser les dettes techniques à rembourser en fonction de leur impact
  5. Traiter

Par exemple :

  • « J’ai une dépendance qui est dépassée depuis 6 mois. Elle n’est plus maintenue et potentiellement il y a des failles de sécurité ».
  • Le bénéfice : « potentiellement éviter des failles de sécurité ».
  • On traite ensuite ce point en fonction des autres dettes identifiées en fonction des priorités et de l’impact recherché. 

Investir régulièrement pour réduire la dette existante 

Grâce au travail d’identification, on peut planifier le remboursement de la dette technique et l’intégrer à la roadmap du produit/service. Cette démarche se fait donc avec le Product Owner ou le Product Manager.

Tout rembourser ? Une question de mesure.

La dette technique est une course de fond. Il est complètement stérile de rechercher la pureté du code à tout prix, mais de privilégier la qualité contribue largement au potentiel de développement. Ne pas avoir un logiciel endetté attire les développeurs plutôt que de les faire fuir. Le mieux à faire est de réévaluer régulièrement la dette pour ajuster les curseurs et toujours suivre le bon cap.

En savoir plus

La conférence complète sur la dette technique, donnée le 24 novembre 2022 à 42Lausanne :

Julien Arnoux est VP of Engineering chez Infomaniak. Il navigue dans la tech depuis plus de 15 ans ; d’abord en tant que développeur, puis lead dev et enfin VP. Il a pu observer les différents aspects du développement de produits web de la technique à l’organisationnel.