Le Hiérarchiseur de Dette Technique : Transformez une Pile de Problèmes Connus en Backlog Classé
Pourquoi ce prompt est important
Teams that prioritize tech debt by gut feeling or by whoever complained most recently routinely spend a full quarter fixing a low-impact annoyance while the actual system most likely to cause the next outage sits untouched for another two quarters, because nobody scored it against anything concrete.
À quoi nous l'utilisons
A tech lead has 40 open technical debt tickets accumulated over a year, a sprint planning meeting in two hours, and no agreed-upon method for deciding which 5 items the team will actually commit to fixing this quarter instead of just the ones the loudest engineer complained about last.
Prompt
Act as a staff engineer who specializes in technical debt triage and has to defend every prioritization decision to both engineering leadership and the business side, not just to other engineers. Context: - Team size and sprint capacity: [TEAM SIZE AND STORY POINTS OR HOURS AVAILABLE PER SPRINT] - Known tech debt items: [PASTE YOUR LIST OF TECH DEBT ITEMS, ONE PER LINE, WITH A ONE-SENTENCE DESCRIPTION OF EACH] - Roadmap context: [WHAT THE TEAM IS SHIPPING IN THE NEXT 1-2 QUARTERS, SO WE KNOW WHICH SYSTEMS WILL SEE THE MOST CHANGE OR LOAD] - Incident history: [ANY OUTAGES, SEV1/SEV2 INCIDENTS, OR CUSTOMER ESCALATIONS THAT TRACE BACK TO ANY OF THESE ITEMS, IF KNOWN] Task: For each tech debt item, score it on four dimensions using a 1-5 scale and produce a single composite score: 1. Blast radius - how many systems, teams, or customers would be affected if this item causes a failure 2. Incident probability - how likely this item is to cause a production incident in the next two quarters, given the roadmap context above 3. Cost of delay - how much more expensive or risky this item becomes the longer it's left unaddressed (interest accrual, not just current pain) 4. Effort to fix - estimated engineering time, flagged clearly as either a confident estimate (based on reading the actual code or system) or a rough guess Then rank all items by composite score and draw a clear line recommending the top items that fit within the stated sprint capacity for this quarter. Constraints: - Recommend no more than 5 items for this quarter's commitment, regardless of how many items are on the list - Any item with a safety, data-integrity, or compliance dimension must be flagged as a must-fix regardless of its composite score, and called out separately from the ranked list - Do not let "this annoys me as an engineer" stand in for blast radius or incident probability - every score needs a one-sentence justification tied to actual system behavior or business impact - If effort estimates are guesses rather than informed by code inspection, say so explicitly rather than presenting false precision Output format: A markdown table with columns: Item | Blast Radius (1-5) | Incident Probability (1-5) | Cost of Delay (1-5) | Effort (1-5, lower is less effort) | Composite Score | Recommendation (Fix this quarter / Defer / Must-fix regardless of score) Followed by a short narrative (3-4 sentences per item) explaining the reasoning for the top 3 recommended items, and a separate callout box listing any must-fix safety/compliance items that bypass the ranking entirely.
Résultat
| Item | Blast Radius | Incident Probability | Cost of Delay | Effort | Composite | Recommendation |
|---|---|---|---|---|---|---|
| Auth service still on sync HTTP calls to 3 downstream services, no circuit breaker | 5 | 4 | 5 | 3 | 17 | Fix this quarter |
| Legacy billing cron job has no idempotency key, double-charges on retry | 4 | 3 | 4 | 2 | 13 | Must-fix regardless (compliance/financial risk) |
| Admin dashboard still uses deprecated internal API v1, scheduled for shutdown in 5 months | 2 | 5 | 3 | 3 | 13 | Fix this quarter |
| Test suite takes 47 minutes, no parallelization | 2 | 1 | 2 | 4 | 9 | Defer |
| Inconsistent error logging format across 6 microservices | 2 | 1 | 2 | 2 | 7 | Defer |
Why the top 3
Auth service sync calls (score 17): This is the clearest must-fix for pure risk reasons. With three downstream dependencies and no circuit breaker, a single slow dependency degrades login for the entire platform, and the roadmap shows two new services calling into auth next quarter, which only raises the odds of a cascading timeout. Effort is a confident estimate at 3 because the team already scoped this during the Q2 reliability review.
Billing cron double-charge bug: This bypasses the ranking entirely and goes in the must-fix box. A double-charge is a compliance and trust issue regardless of how rarely the retry path triggers; probability of occurrence doesn't matter when the downside is a refund process and a support escalation every time it fires.
Admin dashboard on deprecated API v1: Incident probability is scored a 5 specifically because the shutdown date is fixed and known — this isn't a maybe, it's a scheduled failure if untouched. Blast radius is lower than the auth item because only internal admin users are affected, which is why it ranks third despite the certain failure date.
Must-fix callout: Billing cron idempotency bug — financial and compliance exposure independent of composite score. Recommend assigning to this sprint even if it displaces one of the ranked items above.
Chaque équipe d'ingénierie a un backlog de dette technique auquel personne ne fait entièrement confiance. Les éléments sont ajoutés quand quelque chose agace quelqu'un, et ils sont priorisés de la même façon — selon la fraîcheur de la plainte, pas le risque réel. Cette approche produit systématiquement un trimestre entier passé à corriger une irritation mineure tandis que le système le plus susceptible de causer la prochaine panne reste intact, parce que personne ne l'a jamais noté face à quoi que ce soit de concret.
Ce prompt impose une passe de notation structurée sur chaque élément du backlog avant toute décision de priorisation. Il utilise quatre dimensions — rayon d'impact, probabilité d'incident, coût du report et effort — précisément parce que ces quatre éléments réunis capturent ce que «priorité» signifie réellement dans un système en production, et aucun ne correspond directement à quel point un problème est agaçant pour l'ingénieur qui doit le contourner au quotidien.
Pourquoi quatre dimensions, pas un seul score
Un simple champ «priorité : haute/moyenne/basse» écrase trop d'informations pour être utile, et c'est aussi le champ le plus vulnérable à celui qui parle le plus fort en réunion de planification. Diviser le score en rayon d'impact (combien de systèmes ou d'utilisateurs sont exposés), probabilité d'incident (à quel point cet élément précis risque réellement d'échouer, étant donné ce qui sera déployé ensuite), coût du report (le problème s'aggrave-t-il plus il reste en place) et effort (ce que ça coûte réellement de le corriger) force chaque argument de classement à être formulé dans ces termes spécifiques. «Ça m'agace vraiment» ne rentre dans aucune des quatre cases, ce qui est précisément le but.
Pourquoi l'échappatoire des corrections obligatoires compte
Tous les risques ne devraient pas être classés face à l'effort. Un bug de conformité ou d'intégrité des données qui survient rarement mais cause de réels dégâts chaque fois qu'il se déclenche ne devrait pas perdre face à un élément de probabilité plus élevée mais d'enjeu plus faible simplement parce que les calculs tombent ainsi. Le prompt isole explicitement ces cas dans une catégorie de correction obligatoire qui contourne la liste classée, car les fondre dans un score composite gonfle artificiellement l'urgence apparente de tous les autres éléments ou enfouit une responsabilité réelle sous un tas de plaintes de performance mineures.
Pourquoi l'honnêteté sur l'effort est une contrainte séparée
Les estimations d'effort pour la dette technique sont fréquemment des conjectures déguisées en chiffres, et une équipe qui traite une estimation conjecturée de trois jours comme une estimation de trois jours vérifiée dans le code finit par dépasser la capacité du sprint pour des raisons que personne ne peut retracer. Forcer le modèle à indiquer quelles estimations sont fiables plutôt qu'approximatives garde la sortie honnête sur ce qu'elle sait réellement.
Comment utiliser la sortie
Apportez le tableau classé et l'encadré des corrections obligatoires directement à la planification du sprint. Le plafond strict de cinq éléments par trimestre n'est pas arbitraire — il est là pour forcer une véritable décision d'engagement plutôt qu'un backlog qui grossit à chaque sprint sans que rien ne soit réellement corrigé.