Gérer votre dette technique – Convaincre votre client
Équilibrer performance, budget et stratégie : un guide pour gérer la dette technique et assurer la réussite de vos projets numériques.
Personne n’est contre la vertu, mais quand il s’agit de délier les cordons de la bourse, les volontaires s’effacent. Tout projet a son sponsor, il a un besoin, mais aussi un budget.
Comment faire entendre à un client qu’il doit payer des programmeurs à travailler sur son code sans qu’il n’en retire de nouvelle fonctionnalité? Le rôle d’un chargé de projet est entre autres d’être le liant qui comprend les besoins client et les interprète pour les communiquer de façon technique aux développeurs, mais une facette importante de ce rôle consiste également à contrôler les coûts et s’assurer que le scope attendu est livré au client dans le délai et budget prévu.
C’est le rôle du chargé de projet d’ouvrir la discussion sur le cycle de vie de l’application avec le client, surtout si l’occasion lui en est donnée par les développeurs qui identifient et lui communiquent des modules qui accusent une dette technique. Glisser cela sous le tapis serait irresponsable et ne rendrait pas service au client, il vaut mieux avoir une discussion difficile maintenant qu’une catastrophe à gérer plus tard… C’est en mettant en lumière les enjeux qu’on peut prendre la meilleure décision (éclairée).
Ce que l’on voit plus souvent et qui fait tout son sens dans une approche LEAN3, c’est de conserver un certain « levier ». On choisit de maintenir l’endettement pour le moment afin de livrer davantage de fonctionnalités rapidement. Que ce soit pour éliminer plus tôt un système legacy par son MVP, ou pour réduire le « Time to market » et donc mitiger les risques et tester la réception d’un nouveau produit auprès du marché plus hâtivement, ou encore pour une preuve de concept permettant de convaincre des parties prenantes de la pertinence et la faisabilité du logiciel pour aller chercher un budget projet étoffé.
Attention, ces raccourcis, bien qu’utiles et pertinents ne doivent pas définir la norme. Une approche intéressante est de planifier une contingence, la règle du pouce voulant qu’on réserve environ 20% supplémentaire au budget, pour glisser des « user story » qui attraient à la dette technique à l’intérieur des sprints. Pendant le postmortem, on soulève les dettes techniques mises au jour, mais également on célèbre celles qui ont été adressées, ça fait partie d’un sain processus pour un « devX4» de qualité. Quand on planifie le sprint suivant on intègre ces stories en priorisant les parties du code qui sont « core » au logiciel et en particulier celles qui sont difficiles d’approche et qui effraie les devs. Les gains les plus importants sont là, inversement il est peu utile de refactoriser du code stable ou pire du code inutilisé.
Afficher cette saine gouvernance au client lui donnera confiance que vous n’êtes pas un puriste extrémiste, mais plutôt un fournisseur engagé dans la réussite et la pérennité du projet, qui a à cœur de bien utiliser le temps et l’argent disponibles pour lui permettre de maximiser ses investissements et d’atteindre ses objectifs.
Réflexion bonus, un argument supplémentaire pour favoriser la prise en charge de la dette technique est l’importance d’une architecture de qualité pour permettre de construire sur des bases solides. Aujourd’hui il y a un « hype » incroyable sur l’IA, tout le monde veut en faire pour mousser son image et éviter d’être en retard sur la compétition. Même les gouvernements fédéral5 et provincial6 réorientent leurs programmes7 pour subventionner les projets IA au détriment d’autres projets d’innovation.
Toutefois 85% des projets IA échouent8, les spécialistes le disent, pour être du bon côté de la statistique il faut d’abord identifier le besoin stratégique que l’on cherche à combler et définir le « ROI » attendu. Mais la deuxième étape à ne surtout pas négliger consiste à mettre en place de solides fondations (performance et scalabilité des solutions, infrastructure adaptée, résiliente et efficace, systèmes automatisés et connectés, donnés de qualité, filtrées et fiables, source de vérité unique et disponible, etc.) Ce sont tous des exemples d’endroits potentiels à cibler pour éliminer des dettes techniques limitantes. C’est seulement après avoir fait tout ça que vous pourrez espérer obtenir le succès escompté avec votre projet IA.
D’ailleurs, bien qu’une partie de ces améliorations soit « back-end » et intangible, elles vont au passage améliorer le UX (expérience utilisateur), entre autres au niveau de la performance de l’application. Ainsi, il faut voir les efforts mis à régler la dette technique comme un premier pas dans la bonne direction qui fidélisera votre « end user » en lui offrant une expérience fluide, facile et sans effort qui vous distinguera de la concurrence et qui peut même bonifier votre modèle d’affaires.
2 Comment surveiller que les projets agiles ne dépassent pas leur budget ? | KuriosIT
3 10 Years Since ‘The Lean Startup’: A Product Developer’s Perspective
4 Five proven approaches for a better Developer Experience in your organisation | Thoughtworks
7 Budget Québec 2025: le gouvernement mise sur les entreprises spécialisées en IA – Les Affaires
8 IA, pourquoi 85 % des projets d’entreprise aboutissent à un échec ? – IT SOCIAL