Comprendre la dette technique d'un projet

Tout nouveau projet est obsolète ! Même infime et difficile à percevoir au départ, une dette technique se crée inévitablement au fil du temps. C'est un poids qui s’alourdit peu à peu et freine progressivement les possibilités d'évolution d'un projet.

^ cet article est une grosse mise à jour d'une version publiée initialement en 2020.

C'est quoi la dette technique ?

Le terme "dette technique" est une métaphore inventée par Ward Cunningham en 1992. Que cela soit d'une manière intentionnelle ou non, la conception d'un logiciel reporte automatiquement des coûts de développement supplémentaire futur. Évidement des erreurs de conception et un développement de mauvaise qualité vont accroitre ce phénomène, mais dans tous les cas, il n'est pas possible de l'éviter. Même la plus brillante et compétente des équipes de développement créé de la dette. Pourquoi ? Car les projets évoluent constamment, ils répondent aujourd'hui à des problématiques auxquelles ils ne devront plus faire face plus tard. Les projets changeront car l’écosystème, la technologie des serveurs, des devices et les utilisateurs changent. En tant que créateurs de solutions informatiques, nous devons assumer cette conséquence, vivre avec et faire le nécessaire pour la maîtriser.

La dette technique ? Non, LES dettes techniques !

Si on prend du recule, on constate que la dette existe à tous les niveaux ! Dans les interfaces, dans les outils de déploiement, dans les solutions de tests, dans l'infrastructure serveur... et même dans la façon de gérer un projet !

On retrouve plusieurs notions différentes :

• L'obsolescence : utiliser de vieilles technologies, de vieilles architectures techniques ou d’anciennes méthodes de développement qui rendent le projet déjà en retard sur son temps.
• La mauvaise qualité : développer sans contraintes, sans bonnes pratiques, ne pas avoir d’homogénéité entre les projets et les autres développeurs, c'est le risque d'un projet difficile à maintenir.
• L'over-engineering : faire un code très structuré, très robuste, mais aussi un peu machine à gaz peut rendre le développement futur complexe et lent.
• La nouveauté à tout prix ! : partir sur des technologies très jeunes et non fiabilisées, c'est ne pas avoir le recul suffisant et prendre un risque dans le maintien du projet.

Vu et entendu !

Ce projet est notre nouvelle référence technique ! - Mai 2020
Comment j'ai pu écrire ça ?! - Septembre 2021

Le magnifique code qui est produit aujourd'hui sera le monstre de demain. Les technologies évoluent et les développeurs progressent ! C'est aussi pour ça que l'amélioration continue est utile : méthode SCRUM, méthode Kaizen.

Franchement, ce langage est parfait pour faire ça ! - octobre 2020
On aurait du prendre l'autre, il vient tout juste de sortir ! - décembre 2020

Et oui, chacun son avis sur le choix d'une techno, seulement, à un moment, il faut décider ! Un peu de pragmatisme peut être utile (stabilité, maturité, recul sur le langage et durée de vie du projet).

J'ai besoin de ça rapidement, vous le ferez au propre plus tard - mars 2020
On peut savoir pourquoi il vous faut 3 jours pour rajouter cette petite fonctionnalité ? - mars 2022

Évidemment, produire du code rapidement est parfois un impondérable pour un client, mais cela ne doit pas devenir la règle. Au fil du temps, les fonctionnalités créées rapidement sans recul et sans structure seront aussi les plus instables et difficiles à améliorer.

Les pistes pour limiter la dette

Côté dev

On en parlait plus haut, mais il est très important de bien comprendre ceci : on ne gagne pas un Tour de France avec un VTT, aussi performant soit-il ! Un choix technique ne doit pas être arbitraire, mais doit être discuté et argumenté au sein de l'équipe.

• La standardisation du code, du code review, des ateliers techniques et une architecture de projet validée à plusieurs**. Prenez aussi le temps de mettre en place des phases de refactoring. Prévoyez même la montée de version de vos librairies qui sera plus facile à faire au fil du projet qu'après avoir cumulé des années de retard.
• Plus il y a de technos, plus la maintenance sera difficile. C'est évident, mais c'est bon de le rappeler. Ajouter une nouvelle techno à un projet doit se discuter en vérifiant les compétences dans l'équipe et la pérennité d'un tel choix.
• Code compréhensible = maintenance facile.
• Pas de développeur unique par fonctionnalité/projet. En passant par du code review ou du développement en pair programming, on partage les compétences et les expériences. On favorise ainsi la reprise d'un projet par d'autres développeurs.
• Apprendre de ses erreurs par des débriefs réguliers et des ateliers techniques
• Normaliser les pratiques de développement automatiquement. Des outils existent pour standardiser et vérifier la qualité du code. Il faut trouver un bon équilibre pour ne pas bloquer la dynamique de développement.
• Utiliser des technologies communes et supportées par une grosse communauté.
• Tester et expérimenter. Si vous souhaitez tester une nouveauté, prenez quelques jours pour le prototyper avant de l'intégrer sur le projet de votre client.
• S'adapter au projet : Le niveau de qualité d'un projet est très dépendant du contexte (projet temporaire, taille, type de client...)

@ Je ne code pas (que) pour moi, je code pour les autres. Souvent la clarté et l’utilité doit primer sur la qualité dans une moindre mesure.

Côté client

Vous devez toujours envisager un projet sur le long terme pour vous permettre de maintenir et de faire évoluer votre projet tout en limitant la dette technique. Un projet à l’arrêt est un projet qui créé de la dette chaque jour.

• Entourez-vous de personnes compétentes, un directeur technique ou un lead développeur qui sera garant d'un développement cohérent tout en gardant une vision client. Préférer un profil d’expérience est primordial ! (ne faites pas l'erreur d'avoir des stagiaires sans supervision par exemple)
• Même si les coups de rushs sont parfois nécessaires, laissez du temps aux équipes de développement. Prévoyez aussi régulièrement de la place dans votre planing pour de la maintenance en profondeur du projet. (refactoring).
• Il est aussi parfois nécessaire de faire le point, de regarder dans le rétroviseur. Vous pouvez donc demander la réalisation d'un audit (en externe, mais aussi par l'équipe elle-même) afin de cibler les forces et les faiblesses du projet pour mieux planifier les challenges techniques à venir.
• Participez aux réunions techniques, posez des questions même si vous ne vous sentez pas à la hauteur techniquement. Elles peuvent être un éclairage pour l'équipe.

Les 5 règles d'or pour maîtriser sa dette technique

• Je prends en compte le contexte du projet dans mon choix technique,
• J'utilise d'abord des technos testées / maitrisées,
• Chaque choix technique doit être débattu dans l'équipe,
• Je commente efficace,
• Je pense à la vie "d'après" de mon projet.

Cet article est valable aujourd'hui, mais qui sait ? Peut-être que demain il ne sera plus, puisqu'il comporte lui-même sa dose de dette technique potentielle. Et vous, quel avis ? Ce sujet est à débattre, et bien sûr, à améliorer ;-) !