On entend beaucoup parler de dette technique. Les chefs de projet la citent souvent pour justifier des coûts supplémentaires, les développeurs pour justifier le dépassement de délai dans la création d’une fonctionnalité… De quoi parle-t-on exactement ? De quoi est composée la dette technique d’un projet ? Peut-on l’éviter, et surtout, lorsqu’elle existe, peut-on maîtriser la dette technique de son projet ? Autant de questions auxquelles nous allons essayer de répondre.
Qu’est-ce que la dette technique d’un projet ?
Lorsque l’on démarre un projet, la phase de conception permet de faire les meilleurs choix technologiques à un instant t pour répondre au besoin du client, et l’on peut se dire qu’il sera facile de maîtriser la dette technique. Tous les développeurs, responsables de projet ou architectes aimeraient travailler avec les dernières technologies, les dernières nouveautés en termes de langage de programmation, de bases de données, de matériel.
Est-ce toujours le cas ? Non bien sûr ! Même sur un nouveau projet, on part très rarement d’une feuille blanche. Il y a généralement un existant, avec lequel il faut faire. Le système d’information dans lequel va devoir s’intégrer la nouvelle application n’est pas forcément de première jeunesse, à l’état de l’art, et pourtant, il faudra que tout fonctionne.
Le code source produit, quel que soit son âge, n’est pas exempt de défauts. Plus le temps passe, et plus les défauts deviennent évidents. Il peut s’agir d’anomalies, de défauts de conception ou même d’obsolescence. On ne compte plus les applications qui fonctionnent grâce à une version du langage qui n’est plus maintenue et qui ne bénéficie plus de mise à jour, même de sécurité.
Le code source des applications se détériore donc au fur et à mesure du temps qui passe. C’est tout cela la dette technique. Du code source dont l’efficacité diminue, une architecture qui vieillit. La conséquence directe est le coût de la maintenance et des évolutions du code qui augmente. On voit encore trop souvent lors de projets les équipes de développement subir de fortes contraintes parce qu’il faut diminuer les coûts, et donc aller vite, coder vite. La qualité du code s’en ressent forcément, et un programme de mauvaise qualité, même s’il fonctionne, c’est la dette technique qui augmente, avec les anomalies qui se multiplient et les coûts et les temps de correction qui augmentent.
Peut-on éviter la dette technique ?
La réponse est simple : non ! Il serait logique de penser qu’en partant sur les toutes dernières technologies s’appuyant sur la dernière version des composants de l’architecture, le projet n’ait pas de dette technique.
Ça sera peut-être vrai, durant la première journée. A partir du moment où l’équipe de développement commencera à produire du code, vous aurez une dette technique. Et elle n’aura de cesse de grandir tout au long du développement de l’application (sans parler de la dette technique héritée de l’infrastructure existante comme évoqué plus haut).
Comment faire alors, si l’on ne peut pas l’éviter ? Il va tout simplement falloir apprendre à vivre avec, mais aussi, savoir la reconnaître !
Comment reconnaître la dette technique d’un projet ?
Pour commencer, même si en management de projet, on parle de « dette technique », il n’y a pas une dette, mais des dettes. Elles peuvent se situer à tous les niveaux du projet, et vous n’aurez pas forcément la maîtrise et les moyens nécessaires pour toutes les traiter. Vous pourrez naturellement faire attention au code source produit et aux solutions directement embarquées dans l’application en cours de développement. En revanche, vous n’aurez certainement pas la maîtrise de l’ensemble des outils qui gravitent autour du projet, et qui sont souvent communs à toutes les équipes : infrastructure réseau, serveurs, outils de tests et de déploiement…
Pour tous les outils sur lesquels vous n’avez aucun contrôle, vous ne pourrez rien changer, il va falloir faire avec.
En revanche, vous serez en mesure de traquer et reconnaître la dette technique au sein même du projet, et c’est déjà une bonne chose.
La première source de dette technique se situe au niveau des bibliothèques et des composants que vous avez sélectionné pour accélérer ou améliorer le développement de l’application. On évite forcément de baser la future application sur des composants obsolètes (encore que l’on n’ait pas toujours le choix, le client étant parfois capable d’imposer l’utilisation d’une solution ancienne, mais qu’il maîtrise parfaitement). Mais il faut bien garder en tête que même si l’on sélectionne une bibliothèque ou un composant récent, à jour, à la pointe de la technologie, il deviendra lui-même un jour ou l’autre obsolète. Il est donc important d’anticiper ce vieillissement, afin notamment de faciliter les mises à jour des composants extérieurs à l’application, sans pour autant risquer de déstabiliser l’ensemble du code.
Si l’obsolescence est une catastrophe, elle a son pendant, qui ne vaut pas toujours mieux, le jeunisme. Sélectionner des technologies récentes et innovantes ne veut pas dire utiliser des outils trop récents, trop jeunes, et parfois instables, dont la pérennité dans le temps n’est pas encore assurée. Utiliser une technologie qui n’est pas encore arrivée à maturité, à moins qu’il ne s’agisse d’un POC (« Proof Of Concept », dont le but n’est pas d’obtenir une application à mettre en production, mais juste de prouver que ça fonctionne, au travers d’un prototype opérationnel), est généralement un mauvais choix. C’est prendre le risque de devoir effectuer un retour en arrière coûteux en termes de temps et d’argent, parce que la solution ne tient pas au final toutes ses promesses.
La source de la dette technique la plus facilement identifiable est sans aucun doute le code source. Un code produit sous pression (la fonctionnalité commandée le matin même est forcément à livrer pour l’avant-veille), sans ligne directrice claire, sans que les bonnes pratiques soient mises en place et partagées par l’ensemble des développeurs de l’équipe, sera forcément de mauvaise qualité. Il se dégradera beaucoup plus rapidement, avec l’apparition de nombreuses anomalies, et sera de plus en plus complexe à maintenir et à faire évoluer. Une mauvaise organisation de l’équipe de développement est souvent synonyme d’explosion de la dette technique.
Vouloir produire un code de trop bonne qualité n’est pas nécessairement plus productif. Ne dit-on pas toujours « le mieux est l’ennemi du bien » ? On est toujours tenté de produire le code le plus générique possible, découplé des besoins métier du client, de façon à ce qu’il soit facilement réutilisable dans un autre contexte, dans un autre projet. En plus, c’est généralement un défi intellectuel auquel aiment se prêter les développeurs. Certes, le code pourra être réutilisé (en réalité, il ne l’est jamais, ou très rarement), mais à quel prix ? On obtient généralement un code très complexe, une architecture compliquée, et il sera très difficile pour un nouveau développeur, expérimenté ou non, de le comprendre et de se l’approprier pour le faire évoluer, ou lui apporter une correction. Finalement, ça ne sera qu’une source de dette technique supplémentaire.
Peut-on maîtriser la dette technique d’un projet ?
Maintenant que nous savons que la dette technique est inévitable, mais qu’elle est reconnaissable, peut-on vraiment la maîtriser ? Heureusement, la réponse est oui, à condition de contrôler un certain nombre de facteurs.
Limiter les technologies
Pour commencer, il est important de limiter le nombre de technologies qui vont entrer en jeu dans la construction de l’application. Plus elles seront nombreuses, et plus la maintenance de l’application sera complexe. Il faut également s’appuyer sur des technologies qui ont fait leurs preuves et dont les composants sont stables, maintenus et régulièrement mis à jour. Peut-être que la technologie qui vient de sortir fait des merveilles et correspondrait tout à fait à votre besoin, mais peut-être aussi qu’elle sera totalement abandonnée dans quelques mois, par désintérêt de ses créateurs ou parce qu’elle n’a finalement pas été autant adoptée que prévu.
Répondre au besoin
La technologie sélectionnée devra avant tout être adaptée au besoin. Le choix ne doit pas être décrété (lorsque le langage Java est arrivé sur le marché, beaucoup de clients ont dit « je veux une application écrite en Java », au lieu de dire « je veux une application qui répond à mon besoin, proposez-moi la meilleure solution » ; d’autres solutions que Java auraient parfois été plus adaptées et plus simples à mettre en place, et cela aurait pu sauver bon nombre de projets), mais discuté, réfléchit, et approuvé par l’ensemble de l’équipe technique.
Modèle unique du code source
Le code source doit suivre un modèle unique, adopté et appliqué systématiquement par l’ensemble des développeurs travaillant sur le projet. De cette façon, le code source sera lisible et compréhensible, qu’il soit écrit par un développeur présent dès le début ou par quelqu’un qui n’intègrera le projet que plusieurs mois après son début, voire après sa fin pour s’occuper de la maintenance de l’application. Le code source doit être également parfaitement commenté (c’est-à-dire que des commentaires doivent être placés aux endroits où le code est stratégique, et non pas partout, afin de ne pas noyer les informations importantes). Ce point est même plus important que de rédiger une documentation exhaustive… qui ne sera jamais maintenue à jour car trop lourde.
Code source générique
Sauf pour un besoin particulier, le code source écrit devra répondre en priorité au besoin exprimé plutôt que d’être générique et réutilisable. Si l’on sait que cette partie de code pourra être réutilisée dans le même projet, et répond à un besoin immédiat de l’entreprise ou d’autres équipes projet, elle pourra là être écrite pour être générique. Dans le cas contraire, il y a fort à parier que les développeurs se feront plaisir, mais qu’ils perdront du temps à écrire un code qui ne sera jamais réutilisé, et que les coûts de maintenance augmenteront également.
Développeurs généralistes
Il est important également que les développeurs ne soient pas trop spécialisés. Si un seul développeur a travaillé sur une fonctionnalité et qu’il n’a pas échangé avec les autres, le moindre problème survenant dans cette partie du code peut rapidement tourner à la catastrophe s’il n’est plus là. Des revues de code, des séances de programmation par paire, des réunions de présentation doivent être mises en place de façon à ce que n’importe quel membre de l’équipe de développement soit en mesure de comprendre et de travailler sur une portion de code qu’il n’a pas écrite. Cela simplifie également la maintenance du code, puisque n’importe lequel des développeurs pourra intervenir sur l’ensemble de l’application.
Tests unitaires
La mise en place de tests unitaires (TU) et si possible du développement piloté par les tests (TDD), est un énorme atout pour diminuer et maîtriser la dette technique du projet. Ce mécanisme s’intègre parfaitement au processus d’amélioration continue mis en place dans un projet agile Scrum. Non seulement les tests unitaires vont servir de documentation technique (la lecture des tests correspondant à une portion de code va mieux renseigner le développeur sur son fonctionnement que n’importe quelle documentation), mais ils vont également permettre de s’assurer que le comportement du code est bien celui attendu, et s’assurer de la non-régression à chaque nouvelle version livrée.
Pour conclure sur la dette technique d’un projet
Le code source écrit aujourd’hui deviendra irrémédiablement la principale source de dette technique du projet demain. S’assurer de sa qualité, du respect des normes et des bons choix technologiques est sans aucun doute le meilleur moyen de conserver la maîtrise de la dette technique. La méthode SQALE (« Software Quality Assessment based on Lifecycle Expectations ») fournit par exemple un moyen d’évaluer de façon objective la dette technique d’un projet. Utilisée avec une méthode agile comme Scrum et un outil performant d’analyse statique de code, elle peut être d’une redoutable efficacité pour maîtriser la dette technique de son projet.
Nutcache est l’outil de gestion de projet collaboratif en ligne idéal pour gérer vos projets agiles. Testez-le gratuitement pendant 14 jours!
