La dette technique dans le développement d'applications est l'accumulation d'erreurs et souvent de coûts supplémentaires en raison de décisions antérieures faites sans prendre en compte la qualité du développement. Ces décisions court-termistes engendreront des coûts plus élevés sur le long terme en demandant des ressources supplémentaires pour corriger ou maintenir ces erreurs de conception. Ce terme, inventé par Ward Cunningham en 1992, s'inspire de la dette financière pour décrire un phénomène similaire appliqué au développement logiciel.
Contrairement à un bug, la dette technique est un problème latent. Ce sont les risques liés à la dette technique qui augmentent avec le temps pouvant faire augmenter le nombre de bugs ou rendre la maintenance plus difficile sur le long terme.
La conception logicielle, souvent formalisée via un cahier des charges associé à plusieurs rapports techniques, doit permettre de planifier les critères de qualité d'un logiciel. Cette base d'un projet de développement doit rendre l'application cohérente sur le long terme et planifier la maintenance corrective ou évolutive (ajout de fonctionnalités) pour limiter la dette technique.
Comment apparaît la dette technique ?
- La contrainte de temps est la principale source de dette technique. Une phase de développement accélérée entraîne souvent des compromis qui crée des erreurs et des approximations qui vont créer de la dette technique.
- Ce phénomène se voit le plus souvent dans des applications métiers comme des ERP où les fonctionnalités peuvent être mal planifiées et ne pas répondre à tous les cas de l'entreprise.
- La deuxième contrainte est la réduction des coûts qui crée la tentation de réduire les investissements structurels (qualité du code) ou de sécurité (mise à jour, tests).
- Windows XP a été l'exemple majeur d'un manque d'évolution de nombreuses entreprises par rapport aux mises à jour logicielles.
- Un manque de recherche des besoins des utilisateurs entraîne souvent l'utilisation de solutions rapides à mettre en place, mais non adaptées aux besoins du projet.
- De nombreux sites internet utilisent WordPress alors que ce CMS est trop complexe pour un simple site vitrine. Sa maintenance et ses performances entraînent des coûts supplémentaires et des risques de sécurité.
La dette technique a un impact sur la qualité et les coûts
Quand on conçoit un projet avec des contraintes de temps ou de moyens, on contracte une dette que l'on va devoir rembourser sur le long terme pour maintenir la qualité d'une application. L'analogie avec la dette financière prend un sens quand on pense aux intérêts d'une dette. Une dette technique risque de coûter plus cher à rembourser sur le long terme1. Un code de mauvaise qualité ou une application non adaptée entraînera une dette avec plus d'intérêts. Il faudra plus de moyens et plus de temps pour la rembourser.
Il est primordial de développer des guides de qualité à atteindre pour maintenir une qualité correspond aux besoins des utilisateurs. Cela permet de créer des applications qui peuvent évoluer harmonieusement. La dette technique devient problématique lorsqu'une équipe doit passer son temps à réparer les problèmes engendrés par la dette2. C'est-à-dire de payer la dette. Une dette technique trop importante est responsable d'applications stagnantes qui n'évoluent pas ou pire se dégradent. Dans le cadre de l'évolution d'une application, un contrôle de la qualité limite l'apparition de bugs lors de mise à jour et un déploiement de fonctionnalités.
La dette technique est souvent associée à des problèmes de sécurité
Le manque d'investissement dans la qualité se fait souvent en premier lieu au niveau de la sécurité, particulièrement dans le développement de site internet. De nombreux projets ne prévoient pas de plan pour la mise à jour logicielle ce qui créent de potentielles failles exploitables.
Ce problème est très visible avec WordPress qui représente 34% des sites internet (60% des CMS) en ligne3. La mise à jour de ce CMS est souvent retardée pour des raisons de compatibilités4, idem pour les plugins qui peuvent devenir des failles de sécurité potentielles 5.
La dette technique crée de la dette écologique
Lutter contre la dette technique revient à intégrer un travail d'écoconception dans un projet. Le but est de créer des services résilients. La dette écologique se base d'ailleurs sur une définition similaire : l'accumulation d'une surexploitation des ressources par nos logiciels actuels au détriment de l'avenir du futur de l'application.
Le manque d'optimisation ou de temps consacrer à la qualité réduit les performances des applications et augmentent leurs poids et la complexité, donc la consommation énergétique sur le long terme6. Des choix techniques non adaptés ont les mêmes conséquences.
Le marketing peut avoir le même effet. L'installation de tracking sur des sites où on ne prévoit pas de temps ou de moyen pour analyser les données entraîne aussi la consommation de ressources inutiles en plus de problèmes légaux à prévoir (adaptation RGPD).
La dette écologique est souvent la conséquence d'une dette technique.
La simplification et le minimalisme pour une dette technique nulle
Un projet complexe avec une dette technique nulle demanderait un budget important. Car la qualité est directement liée au temps et aux moyens comme le rappel simplement le triangle d'or de la gestion de projet.
Dans le cas d'une application complexe demandant de nombreux besoins, seuls quelques grands groupes pourraient avoir les moyens de développer une qualité proche de la perfection technique et encore de nombreux échecs démontrent que c'est rarement le cas.
Le problème viendrait plus dans de nombreux cas de la formalisation des besoins et de la compréhension des usages. Notre société demande beaucoup de ressources pour des fonctionnalités non adaptées et à l'impact bénéfique limité. Un travail de recherche des besoins plus approfondi, couplé à une vision résiliente d'internet permettrait de créer des projets dont la qualité viserait les principes de base d'internet; l'accessibilité, l'échange, et des nouvelles valeurs nécessaires comme l'éthique, la vie privée et l'écologie. C'est exactement dans ce cadre que s'inscrivent des recherches autour de sites résilients et l'optimisation des ressources pour s'adapter aux stricts besoins des usages. Une simplicité permettant d'éviter une dette technique structurelle alimentée par le choix de mauvaises solutions.
Publications et notes
-
Erik Frederick, Technical Debt, Toptal ↩
-
Constantin Guay, Comment et pourquoi visualiser la dette technique, 2018 ↩
-
Kinsta, WordPress market share, 2019 ↩
-
WordPress.org, Statistiques, 2019 ↩
-
Sucuri, Hacked report, 2017 ↩
-
James Christie, Sustainable Web Design, A List Apart, 2013 ↩