Retour aux articles

L'agence

WanadevStudio

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 est traîné et qui freine progressivement les tentatives pour faire évoluer un projet.

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

C'est quoi la dette technique ?

Le terme "dette technique" est une métaphore inventée par Ward Cunningham en 1992. En effet, 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 ensuite 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. 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 ;-) !

Commentaires

Il n'y a actuellement aucun commentaire. Soyez le premier !

  • Tests automatiques fonctionnels d’applications 2D/3D

    Il y a 9 mois

    Comme nous le disions dans cet article, l’automatisation des tests dans le développement logiciel est indispensable : dès lors qu’une application commence à avoir un minimum d’importance, les tests automatiques permettront de gagner énormément de temps en évitant de reproduire ad vitam æternam les mêmes tests manuels, et éviteront beaucoup de régressions. Dans cet article, nous allons présenter différents types de tests automatiques dans le cadre plus spécifique d’applications 2D/3D, puisque c’est ce que nous faisons ! Cela va du test basique qui clique sur 3 boutons aux tests de plusieurs minutes reproduisant les actions comme un véritable utilisateur. Accrochez-vous, c’est parti !

  • Configurateur web à l'abonnement : forces et faiblesses

    Il y a 10 mois

    Aujourd’hui, si vous cherchez à mettre en place un configurateur sur votre site, deux grandes possibilités s'offrent à vous : les solutions par abonnement (du type SaaS) ou le développement sur mesure. Au premier abord, les solutions semblent proches, mais les enjeux sur le long terme eux, sont bien différents.

  • Les frameworks front, tous les mêmes !
    Méthodologie

    Il y a 11 mois

    C'est une phrase que j'ai osé sortir un jour dans la salle de pause de Wanadev. Je ne sais plus exactement avec quel collègue je discutais, j’essayais de le rassurer, il possédait déjà une certaine expérience avec React et allait devoir, en arrivant sur le projet sur lequel je travaille, se mettre à Vue.
    Il a malheureusement fallu qu'un autre collègue de passage nous entende pour ne pas trouver la conversation inintéressante et suggérer que j'en fasse un petit talk pour nos réu du lundi. Et, de fil en aiguille, me voilà en train d'en faire un article de blog. Comme quoi, note pour moi-même, il faut toujours se méfier des discussions dans les salles de pause.

  • [NOVEMBRE 2021] C'est la gazette de Wanadev !
    Méthodologie

    Il y a 1 an

    Retrouvez ici les informations et actus du mois de novembre de l'Agence! Au programme de cette édition : découvrez le configurateur de fenêtre développé pour Caseo, recontrez François Deleglise, notre directeur communication et un nouvel espace de jeu pour les professionnels du loisir en VR. Bonne lecture !

  • Un peu d'ingérence dans votre infogérance ?
    Méthodologie

    Il y a 2 ans

    Même si les impacts sont difficiles à mesurer, on peut dire qu’il a eu un avant et un après incident OVH. Sans épiloguer sur l'incendie du 5 mars 2021 dernier, un petit vent de panique a soufflé sur les milliers de clients découvrant les problématiques de sécurisation des données. Les réactions à chaud d'une partie des utilisateurs (touchés ou non) montrent la méconnaissance et l'incompréhension qui existent dans les offres d'hébergement. Qui est responsable ? Qui fait quoi ? Comment vérifier mon offre ? Voici quelques clés de compréhension.

  • Améliorer la qualité avec les tests et la review

    Il y a 2 ans

    L’importance des tests et de la revue de code dans le cadre du développement logiciel est parfois négligée ou passée au second plan. Cet article a pour but de montrer que les tests logiciels constituent une étape cruciale qu’il faut considérer avec beaucoup de rigueur.