Anticiper et contrôler la dette technique
Alors que de plus en plus d’entreprises basent leur modèle d’affaires sur la création ou l’implantation d’une plate-forme logicielle, la notion de durabilité des investissements en développement devient capitale. Pour cela, il est important de considérer la prise en compte de la dette technique quand vous planifiez la réalisation de votre plateforme logicielle.
La dette technique est une métaphore créée par Ward Cunningham, l’inventeur du wiki, l’artisan de l’Extreme programming et l’un des rédacteurs du fameux Manifeste agile. Lorsque l’on prend des raccourcis ou que l’on fait des concessions lors du développement, que ce soit pour des questions de délais, de budget, de manque de rigueur ou encore de savoir-faire, on accumule une “dette” qu’il faudra rembourser dans le futur. Aussi, la valeur du code évolue et se déprécie généralement avec le temps. Aucun projet ne peut échapper à la dette technique. Il faut donc la contrôler, afin de réduire au minimum ses impacts financiers pendant toute la vie de la plateforme.
Les conséquences de l’accumulation d’une forte dette technique peuvent être désastreuses. Elle peut entraîner de la difficulté à faire évoluer une solution ou à s’arrimer à une nouvelle plateforme. L’utilisation de technologies ou de versions qui ne sont plus supportées peuvent rendre vulnérables à différentes menaces de sécurité. Une dette technique est toujours néfaste, car elle entraîne entre autres des coûts élevés de développement, handicape les possibilités de croissance de l’entreprise, en alourdit la gestion, exerce une pression sur les liquidités et beaucoup de soucis pour les gestionnaires. La qualité du code est donc un facteur important de la valeur d’une plateforme et souvent de la performance d’une organisation.
Par exemple, un code non documenté et ne suivant pas les bonnes pratiques de l’industrie deviendra difficile à transférer si jamais il appert que vous deviez internaliser le développement ou bien transférer le service de développement à un autre prestataire. Ces transferts peuvent arriver durant toutes les années d’évolution d’un système logiciel et sont généralement très coûteux. Il est ainsi important de s’enquérir des bonnes pratiques lorsque vous choisissez votre partenaire de développement.
Que faire lorsque votre projet a mal vieilli ?
Si vous avez développé votre plateforme logicielle en interne, il est souvent nécessaire de rencontrer une entreprise de développement afin de faire un audit du code. Pour faire suite à leurs constats et recommandations, il faudra prioriser et planifier les modifications à faire. Pour cela, il faut bien comprendre les problèmes relevés et les impacts d’un code désuet et de mauvaise qualité. Évidemment, et tout comme la dette financière, l’on prendra des décisions lorsque le coût de réparation de la dette est inférieur à ses bénéfices et peut être amorti.
Comment s’en prémunir sur les nouveaux projets ?
Dans bien des cas, il est préférable d’investir un peu plus au départ pour obtenir un développement qui offrira plus de pérennité. Voici quatre pistes de solutions :
- Choisir une équipe ou une firme sérieuse qui tentera de comprendre en amont avec vous la vision à court, moyen et long terme de votre solution ainsi que les objectifs d’affaires, afin de sélectionner des technologies qui pourront s’adapter à cette évolution.
- Avoir une bonne documentation du code. Cela permet de réduire les coûts de maintenance/support, tout en facilitant des transferts.
- Se doter de tests automatisés qui permettent de détecter d’éventuelles pertes dans l’intégrité et la précision des fonctionnalités du logiciel.
- Finalement, disposer d’une gestion des bogues et implanter des techniques de DevOps qui permettront de veiller en continu à la bonne santé de votre système logiciel et d’agir selon vos priorités stratégiques.
En somme
La gestion de la dette technique s’inscrit dans une dynamique de durabilité et d’investissement responsable. Il existe des solutions afin de la réduire et de planifier un écosystème technologique plus durable. Il est important de choisir ses coéquipiers ou sa firme de développement en fonction de leur maturité à gérer cette complexité.
