Une dépendance à mettre à jour. Des tests qui échouent sans raison claire. Un module que personne ne veut modifier. L’équipe connaît les problèmes, mais la prochaine livraison arrive vite et la capacité est déjà engagée.
Dans cette situation, demander du temps pour « réduire la dette technique » reste trop vague. Il faut pouvoir expliquer ce qui mérite d’être corrigé maintenant, ce qui peut attendre et les conséquences de ce choix.
Je recommande de commencer avec une méthode simple : comparer l’impact des dettes et l’effort nécessaire pour les traiter, en tenant compte des échéances et de l’incertitude. Elle suffit pour amorcer une discussion utile entre le lead technique, l’architecte et la personne responsable des priorités du produit.
Partir de ce que la dette nous fait subir
La métaphore de la dette aide à distinguer deux choses : l’effort pour corriger un problème et le surcoût qu’il impose tant qu’il demeure présent. Ce surcoût peut prendre la forme de reprises, de validations manuelles, d’incidents ou de changements plus difficiles à livrer.
La dette peut venir d’un raccourci assumé, mais aussi d’une compréhension incomplète du besoin ou d’un système qui a vieilli. Pour décider quoi traiter, son origine compte moins que ses conséquences actuelles et prévisibles.
« Ce module est mal conçu » exprime un jugement technique. « Chaque changement dans ce module demande deux jours de validation manuelle » donne une base de discussion beaucoup plus concrète.
Avant de proposer une correction, je chercherais donc à répondre à trois questions :
- Quel problème cette dette crée-t-elle?
- À quelle fréquence le subissons-nous?
- Que risque-t-il de se passer si nous attendons?
Un composant peu élégant, mais stable et rarement modifié, peut rester acceptable longtemps. Une automatisation fragile utilisée à chaque livraison mérite peut-être une intervention beaucoup plus rapide.
Comparer l’impact et l’effort, sans chercher un score parfait
Une matrice impact/effort constitue un bon point de départ. Pour chaque dette, on estime le bénéfice attendu de la correction et le travail nécessaire pour l’obtenir.
L’impact doit rester concret : temps récupéré, incidents évités, changements facilités ou exposition réduite. L’effort doit inclure les tests, le déploiement et les dépendances envers d’autres équipes. Une modification de deux heures peut nécessiter plusieurs jours de coordination.
Des catégories comme faible, moyen et élevé suffisent souvent pour une première discussion. L’important est de rendre les hypothèses visibles. Un « impact élevé » sans explication apporte peu d’information.
J’ajouterais deux éléments à cette comparaison :
- L’échéance réelle - Une fin de support ou un engagement contractuel peut imposer de commencer avant qu’un problème se manifeste.
- L’incertitude - Un effort estimé à trois jours après analyse n’a pas la même valeur qu’une estimation donnée sur un système peu connu.
Lorsqu’un incident majeur est en cours ou qu’une vulnérabilité est exploitée, la réponse opérationnelle prend le relais. On ne devrait pas attendre une séance de classement du backlog pour intervenir.
Un exemple : trois dettes, une capacité limitée
Prenons un cas fictif. Une équipe dispose de cinq jours de capacité pour traiter de la dette au cours du prochain mois. Trois sujets sont en discussion.
| Dette | Conséquence observée | Effort estimé | Contrainte ou incertitude |
|---|---|---|---|
| Tests instables dans le pipeline | Trois heures par semaine consacrées aux relances et aux diagnostics | Deux jours | Les échecs semblent concentrés dans quelques tests |
| Dépendance bientôt hors support | La maintenance du composant deviendra plus difficile à assurer | Quatre à huit jours | Fin de support dans trois mois; compatibilité à vérifier |
| Module fortement couplé | Chaque changement exige des validations étendues | Dix à vingt jours | Une évolution fonctionnelle est prévue dans six mois |
Je commencerais par réserver deux jours aux tests instables, sous réserve de confirmer la cause des échecs. Le coût est récurrent, le périmètre semble limité et l’équipe pourra vérifier rapidement si la correction améliore ses livraisons.
J’utiliserais ensuite une journée pour vérifier la compatibilité de la dépendance et préparer la migration. La fin de support laisse encore du temps, mais la fourchette d’effort est trop large pour planifier sereinement. Cette investigation doit déboucher sur un périmètre, une estimation révisée et une date de démarrage.
Les deux jours restants serviraient aux premiers travaux de migration s’ils sont suffisamment définis et utiles séparément. Sinon, il faudrait revoir l’allocation selon les résultats de l’investigation.
Enfin, je reporterais la refonte complète du module couplé, avec une date de réévaluation avant l’évolution fonctionnelle. Une préparation ciblée pourrait alors suffire; il serait prématuré d’engager vingt jours sans mieux connaître les changements à venir.
Cet ordre reste discutable. Si la dépendance présente une exposition importante ou exige une longue fenêtre de validation, sa migration peut passer devant les tests. La comparaison sert justement à faire ressortir ces contraintes.
Quand l’effort est flou, financer une réponse précise
La dette d’architecture est parfois difficile à estimer. Le comportement du système est mal documenté, les dépendances sont nombreuses et une correction peut déplacer le problème ailleurs.
Dans ce cas, je recommande une investigation courte avec une question précise : peut-on isoler ce traitement? Quels consommateurs dépendent de cette interface? Quels comportements faut-il couvrir avant de modifier le composant?
Il faut aussi définir ce qu’on attend à la fin : une décision, une estimation mieux étayée ou un découpage réalisable. Sans résultat attendu, l’analyse peut s’étirer sans faciliter l’arbitrage.
Le manque de données doit conduire à expliciter l’incertitude. Une inquiétude technique crédible mérite parfois une investigation, même si aucun incident n’a encore eu lieu.
Mettre assez d’information dans le backlog pour décider
Une dette devrait apparaître dans le backlog où se prennent les décisions de livraison. Les notes d’architecture peuvent fournir le détail, mais le travail doit être visible au moment des arbitrages.
Un ticket court peut suffire s’il contient :
- Le problème et un élément concret qui l’appuie.
- Son impact actuel et les conséquences possibles d’un report.
- La correction envisagée, son effort et ses principales inconnues.
- L’échéance ou la date de réévaluation.
- Le résultat attendu pour considérer le travail terminé.
Pour les tests instables, ce résultat pourrait être la disparition des échecs intermittents identifiés, confirmée sur une période définie, tout en conservant les vérifications utiles.
Pour une migration, ce serait la dépendance mise à jour, les parcours concernés validés et le déploiement effectué. « Analyser la migration » décrit une étape, pas la résolution de la dette.
Le lead ou l’architecte apporte l’analyse technique. La personne responsable des priorités du produit participe au choix du moment et de la capacité à investir. Les équipes d’exploitation ou de sécurité interviennent lorsque le sujet les concerne.
Réserver de la capacité et vérifier ce qu’elle apporte
Une allocation récurrente rend le traitement de la dette plus prévisible. Elle permet d’engager du travail sans devoir renégocier son existence à chaque planification.
Je me méfierais toutefois d’un pourcentage présenté comme une règle universelle. Une enveloppe de 5 % peut permettre quelques corrections ciblées et rester insuffisante pour une migration structurante. Son utilité dépend aussi de la possibilité de regrouper cette capacité en périodes de travail exploitables.
Je distinguerais les petites corrections récurrentes des chantiers qui demandent un investissement explicite. Un renouvellement technologique important doit avoir une place dans la planification, avec ses dépendances et ses échéances.
Pour vérifier les résultats, quelques mesures proches du problème valent mieux qu’un tableau de bord exhaustif. Dans notre exemple, on suivrait le temps consacré aux relances du pipeline, l’avancement réel de la migration et, plus tard, l’effort de validation des changements dans le module couplé.
Fermer des tickets démontre que du travail a été réalisé. Il reste à vérifier que ce travail a réduit le problème observé. Si les tests demeurent aussi instables après la correction, le bénéfice attendu n’est pas atteint.
Accepter un report, avec une raison et une date
Une priorisation utile conduit aussi à reporter certaines corrections. La capacité est limitée, et toutes les dettes ne justifient pas une intervention immédiate.
Le report devrait laisser une trace simple : pourquoi la situation reste acceptable, quelle mesure temporaire est nécessaire et quand la décision sera réexaminée. Un changement de contexte peut justifier de revenir dessus plus tôt.
Pour commencer, prenez les quelques dettes qui préoccupent le plus l’équipe. Décrivez leurs conséquences, comparez l’effort de correction et identifiez les inconnues qui empêchent de décider. Vous aurez déjà une base concrète pour choisir le prochain travail à financer et expliquer ce qui attendra.
Conclusion
Avec un budget limité et des échéances serrées, chaque correction doit justifier la capacité qu’on lui consacre. Je privilégierais les travaux qui réduisent une difficulté récurrente, préparent une échéance importante ou permettent de prendre une décision mieux informée.
Pour commencer, prenez les quelques dettes qui préoccupent le plus l’équipe. Décrivez leurs conséquences, comparez l’effort de correction et identifiez les inconnues qui empêchent de décider. Choisissez ensuite ce que vous pouvez réellement mener à terme et fixez une date pour revoir le reste.
Une bonne décision doit pouvoir s’expliquer simplement : voici pourquoi nous traitons cette dette maintenant, ce que nous attendons de la correction et ce que nous acceptons en reportant les autres.