La dette, qu’elle soit technique ou financière, devient coûteuse quand on la laisse s’accumuler. Mais bien gérée, une dette technique peut devenir un levier d’efficacité. Grâce à une maintenance régulière, il est possible d’éviter les mauvaises surprises et les projets de modernisation coûteux et non planifiés. Voici comment.
Votre objectif : être proactifs dans la maintenance de votre solution numérique
Une solution numérique est vouée à évoluer dans le temps. Cette évolution sera à la fois intentionnelle, menée par une volonté d’optimisation continue, mais aussi non intentionnelle, poussée par les évolutions techniques qui l’entourent, comme la mise à jour nécessaire des systèmes (iOS, Android) ou l’évolution des langages de programmation.
En intégrant des phases de maintenance en continu tout au long des cycles de développement, on évite les interventions d’urgence coûteuses, les blocages opérationnels imprévus et l’accumulation de correctifs temporaires qui fragilisent la solution à long terme. Cette approche permet également aux équipes de rester en contrôle du produit et de mieux planifier les évolutions futures, plutôt que de consacrer trop de temps à éteindre des feux.
« Effectuer les mises à jour régulièrement augmente la prévisibilité de celles-ci et coûte beaucoup moins cher qu’une monstrueuse mise à jour risquée de temps en temps », nous explique Charles Lévesque, développeur de l’équipe de Maintenance & Support. En effet, c’est le moyen idéal de mitiger le risque d’imprévus et donc le risque de dépassement de budget en priorisant activement le règlement de la dette.
Comment se constitue votre dette technique?
Lorsque la proactivité n’est pas au rendez-vous, une dette technique (ou technologique) se crée. Et comme en finances : tant qu’une dette technique n’est pas payée (ou corrigée), elle accumule des intérêts. Vous le verrez, ceux-ci prendront plusieurs formes : érosion de l’architecture logicielle, réusinage (refactoring), bogues… Ils peuvent même causer des risques importants en sécurité ou causer de dettes techniques additionnelles, conduisant parfois à une nécessité de moderniser entièrement votre application pour qu’elle reste fonctionnelle et compétitive.
Différentes approches à la maintenance applicative
Il existe trois types de maintenance :
- Maintenance corrective, pour corriger les bogues informatiques;
- Maintenance évolutive, pour ajouter de nouvelles fonctionnalités au logiciel ;
- Maintenance performative, pour améliorer la maintenabilité du logiciel.
Le règlement de la dette technique se situe davantage au niveau de la maintenance performative, gage de pérennité d’une solution numérique. Lorsque la maintenance régulière est négligée trop longtemps, elle laisse place à des projets de modernisation applicative complexes qui dépassent la simple mise à jour et touchent à l’architecture même de la solution.
Différents types de dettes techniques
Imaginons que vous décidez initialement de développer votre PWA sur une seule base de code pour réduire les coûts, ou de développer une application mobile en Flutter parce que vous possédez déjà l’expertise à l’interne. Si ces décisions semblent influencer uniquement le début du projet, elles ont en réalité une influence sur l’ampleur de la dette technique puisqu’elles orienteront tous les choix technologiques tout au long du cycle de vie de la solution. Ce choix en début de projet marque le début de la dette. Elle est inévitable, mais en la gardant à l’œil, elle peut être maîtrisée et contenue.
Il existe plusieurs types de dettes techniques qui peuvent être repérées et priorisées à l’aide de la méthode SQALE (Software Quality Assessment based on Lifecycle Expectations, soit Évaluation de la qualité logicielle selon les attentes concernant le cycle de vie). Cette méthode repose sur neuf critères : réutilisabilité, portabilité, sécurité, utilisabilité, efficacité, altérabilité, fiabilité et testabilité.
Voici une liste des dettes techniques les plus courantes :
- Grande boule de boue (Big Ball of Mud) : système ou un logiciel n’ayant pas d’architecture évidente. Il peut être conseillé de réécrire complètement ce type de logiciel.
- Érosion de l’architecture logicielle : écart entre l’architecture prévue d’un logiciel et son implémentation. L’architecture d’un système logiciel ne permet plus de modifications puisque des changements continus introduits dans le système l’ont rendu impossible à maintenir. Dans ce cas particulier, on dira alors que le système est cristallisé.
- Programmation spaghetti : code non structuré et difficile à maintenir, pouvant être causé par plusieurs facteurs tels que des exigences changeantes dans un projet, l’absence de règles de style de programmation ou une ingénierie logicielle excessive.
- Code smell : bien que le terme soit subjectif, il s’agit d’une mauvaise pratique de conception ou d’implémentation logicielle qui conduit à l’apparition de défauts. Un code smell peut ralentir le développement d’une application ou d’une fonctionnalité, mais aussi causer de futurs bogues.
- Anti-patron (Antipattern) : erreurs de conception logicielle héritées de la phase de conception du logiciel, par l’absence ou la mauvaise utilisation de modèles de conception (design pattern). Ces erreurs ont souvent pour résultat une lenteur excessive du logiciel, des coûts de réalisation ou de maintenance élevés, des comportements anormaux et des bogues.
Cerner et corriger les dettes techniques
« Une dette technique n’est pas forcément mauvaise. Un développeur expérimenté peut introduire une dette technique consciemment afin de débloquer un projet ou de se conformer à un échéancier contraignant. Dans ce cas, la dette technique devrait être nommée, documentée et payée (ou corrigée) dès que possible », précise Julien Bonnier, développeur de l’équipe Maintenance & Support.
« Les dettes techniques peuvent être intégrées directement dans le carnet de produit (backlog) au même titre que des fonctionnalités à prioriser », explique Mathieu Fillion, Gestionnaire de l’équipe de développement.
Dès l’étape de choix techniques en début de projet, il est important d’avoir à l’esprit les notions de pérennité des solutions choisies. En effet, la dette technique peut parfois être causée par le choix d’une solution plus facile à développer – au détriment d’une solution plus adaptée, mais qui exige plus de travail. Il faut donc avoir une vision à long terme pour effectuer un choix qui combine du mieux possible les impératifs de mise en marché et de durabilité.
Garantir un code de qualité
Puisque les dettes techniques peuvent fréquemment être causées par des erreurs d’architecture ou de développement, les architectes et développeurs se doivent d’adopter différentes pratiques exemplaires pour limiter les risques de dettes techniques.
De nombreux processus sont implantés dans le sprint afin de contrer ces éventuelles erreurs, notamment la revue de l’architecture en début de projet, ou la revue des codes pour chaque requête tirée (pull request) lors du développement. D’autres pratiques très importantes s’intègrent également dans les processus dans une optique de DevSecOps : garder les bibliothèques à jour ou encore avoir et conserver des pipelines de déploiement continu pour permettre des corrections rapides lorsqu’une faille est décelée.
Le vrai coût de la maintenance
Selon cet article, la maintenance d’une solution numérique représenterait de 50 à 75 % des coûts totaux d’une solution. Selon notre expérience, les projets et les années, les coûts réels de maintenance, c’est-à-dire de mises à jour des systèmes, représenteront en moyenne selon les projets et selon les années un coût total de 10 à 20 % de l’investissement initial dans le projet. Les coûts d’évolution, eux, seront différents en fonction des objectifs d’affaires pour chaque solution numérique.
À retenir : plus la solution numérique est maintenue de manière proactive, moins les coûts seront élevés – et imprévus!
*Article mis à jour le 8 mai 2025.
