La Matrice de Priorisation du Technical Debt
Pourquoi ce prompt est important
High-debt organizations spend 40% more on maintenance and ship features 25-50% slower than peers, and technical debt costs US companies over $2.4 trillion annually — the cost of not prioritizing isn't just slower engineering, it's a compounding tax on every future feature the team ships.
À quoi nous l'utilisons
Your team has a scattered list of known technical debt items sitting in a backlog nobody has prioritized, and you need a defensible remediation plan before the next quarterly planning meeting with product and finance stakeholders.
Prompt
Act as an engineering leader who needs to defend a technical debt remediation roadmap to a CFO and a VP of Product in the same meeting. CONTEXT: - Our team's available capacity for debt remediation next quarter: [E.G. "1 engineer, 20% time" OR "2 sprints total"] - Current business priority: [GROWTH / STABILITY / COST-CUTTING] - Raw list of known technical debt items: [PASTE YOUR LIST — one item per line, however informal] TASK: For each debt item, score it 1-5 on each of these four dimensions: 1. Delivery drag — how much does this slow down future feature work in the affected area? 2. Incident risk — how often is this implicated in production issues, outages, or urgent fixes? 3. Revenue/customer exposure — does this affect paying customers, SLAs, or revenue-generating flows directly? 4. Remediation cost — how much effort would fixing this actually take (5 = very cheap, 1 = very expensive)? Then compute a priority score and rank all items. CONSTRAINTS: - Do not recommend more remediation work than the stated capacity allows — sequence items into what actually fits. - Do not treat all debt as equally urgent — explicitly deprioritize items that score low on both delivery drag and incident risk, even if they're technically embarrassing. - Justify the top 3 items in plain English a non-engineer could read and approve without a glossary. OUTPUT FORMAT: 1. Scored Table: Item | Delivery Drag | Incident Risk | Revenue Exposure | Remediation Cost | Priority Score 2. Recommended Sequence: which items fit in the stated capacity, in order 3. Plain-English Justification: 1 paragraph per top-3 item, written for a non-technical stakeholder
Résultat
Scored Table:
| Item | Delivery Drag | Incident Risk | Revenue Exposure | Remediation Cost | Priority Score |
|---|---|---|---|---|---|
| Auth tokens don't expire | 2 | 5 | 5 | 4 | 16 |
| No test coverage on checkout service | 4 | 4 | 5 | 2 | 15 |
| Deploy script has 3 manual steps | 3 | 3 | 2 | 5 | 13 |
| Reporting dashboard queries primary DB directly | 2 | 2 | 1 | 3 | 8 |
Recommended Sequence (fits 20% time / 1 engineer for the quarter):
- Fix auth token expiration first — highest incident risk and direct revenue/compliance exposure, and at remediation cost 4 it's genuinely cheap to fix. This alone likely consumes 2-3 weeks of the available capacity.
- Add test coverage to checkout service next — this is the most expensive item on the list (cost 2), so it should be scoped to the highest-risk checkout paths only this quarter, not full coverage. Partial coverage of the payment and cart-abandonment flows is achievable in the remaining capacity.
- Deploy script and dashboard query issues are explicitly deferred to next quarter — both score below the auth and checkout items, and capacity is fully allocated after the above two.
Plain-English Justification:
Auth tokens don't expire: Right now, if someone's login session is ever compromised, whoever has that token can access their account indefinitely — there's no automatic cutoff. This is both a security exposure and, depending on our contracts, could put us in breach of customer data-handling commitments. It's also a relatively fast fix, which is why it's first.
No test coverage on checkout: Every time we change anything near checkout, we're relying on manual QA and hope to catch payment bugs before customers do. Given checkout is where we make money, a bug slipping through here has a direct and immediate revenue impact — but building full test coverage is a genuinely large effort, so we're scoping this to the highest-traffic paths first rather than promising full coverage this quarter.
Deploy script manual steps: This one is annoying and occasionally causes a bad deploy, but it doesn't touch customers directly or put revenue at risk the way the other two do — it's a real problem, just not this quarter's problem given our capacity.
Les backlogs de technical debt finissent généralement de deux façons : soit chaque élément est marqué comme « critique » par l'ingénieur que ça agace le plus, soit la liste est ignorée en bloc parce que personne n'arrive à transformer « ce module n'a aucune couverture de tests » en quelque chose qu'un chef de produit ou un directeur financier acceptera de financer. Ce prompt impose un passage de scoring par impact business avant toute séquence de remédiation, de sorte que le plan qui en résulte survive à une conversation de roadmap en présence de non-techniciens.
Pourquoi chaque section du prompt existe
Rôle : Le prompt attribue à l'AI le point de vue d'un responsable technique qui doit défendre une roadmap de remédiation devant un directeur financier et un VP Produit dans la même réunion — et pas seulement celui d'un ingénieur senior évaluant la qualité du code. Ce cadrage est essentiel : un relecteur purement technique classe les éléments par élégance et correction ; un responsable imputable à la fois sur le budget et la livraison les classe selon ce qui met réellement l'entreprise en danger.
Contexte : Le prompt demande la capacité actuelle de votre équipe pour le prochain sprint ainsi que les priorités actuelles de l'entreprise (croissance, stabilité, réduction des coûts), car un même élément de technical debt se classe différemment selon ce que l'organisation cherche à optimiser en ce moment. Une startup en phase de scaling et une entreprise en mode stabilisation ne devraient pas obtenir le même résultat de priorisation à partir de la même liste de dette.
Tâche : Chaque élément de dette est évalué selon quatre dimensions — le frein à la livraison (dans quelle mesure il ralentit les futurs développements fonctionnels dans la zone concernée), le risque d'incident (à quelle fréquence il est impliqué dans des problèmes en production), l'exposition aux revenus et aux clients, et le coût de remédiation — plutôt qu'une vague note de « sévérité » unique, car un score unique écrase des arbitrages bien distincts en un chiffre contre lequel personne ne peut réellement argumenter.
Contraintes : Le prompt interdit explicitement le « refactor de tout » comme livrable et exige que le plan respecte la capacité de sprint déclarée, car un exercice de priorisation qui recommande plus de travail que l'équipe ne peut absorber n'est pas un plan, c'est une liste de vœux.
Format de sortie : La sortie prend la forme d'un tableau classé (et non de prose) spécifiquement pour pouvoir être intégré dans un support de revue de roadmap sans travail de mise en forme supplémentaire, suivi d'une justification en un paragraphe rédigé dans un langage accessible qu'une partie prenante non technique peut réellement lire et approuver.
Le prompt
Act as an engineering leader who needs to defend a technical debt remediation roadmap to a CFO and a VP of Product in the same meeting.
CONTEXT:
- Our team's available capacity for debt remediation next quarter: [E.G. "1 engineer, 20% time" OR "2 sprints total"]
- Current business priority: [GROWTH / STABILITY / COST-CUTTING]
- Raw list of known technical debt items: [PASTE YOUR LIST — one item per line, however informal]
TASK:
For each debt item, score it 1-5 on each of these four dimensions:
1. Delivery drag — how much does this slow down future feature work in the affected area?
2. Incident risk — how often is this implicated in production issues, outages, or urgent fixes?
3. Revenue/customer exposure — does this affect paying customers, SLAs, or revenue-generating flows directly?
4. Remediation cost — how much effort would fixing this actually take (5 = very cheap, 1 = very expensive)?
Then compute a priority score and rank all items.
CONSTRAINTS:
- Do not recommend more remediation work than the stated capacity allows — sequence items into what actually fits.
- Do not treat all debt as equally urgent — explicitly deprioritize items that score low on both delivery drag and incident risk, even if they're technically embarrassing.
- Justify the top 3 items in plain English a non-engineer could read and approve without a glossary.
OUTPUT FORMAT:
1. Scored Table: Item | Delivery Drag | Incident Risk | Revenue Exposure | Remediation Cost | Priority Score
2. Recommended Sequence: which items fit in the stated capacity, in order
3. Plain-English Justification: 1 paragraph per top-3 item, written for a non-technical stakeholderÀ quoi ressemble concrètement la sortie
Pour une équipe disposant d'une capacité « 1 ingénieur, 20 % du temps » sur un trimestre axé CROISSANCE, avec une liste brute comprenant « aucune couverture de tests sur le service de paiement », « les tokens d'authentification n'expirent pas », « le tableau de bord reporting interroge directement la base de données primaire » et « notre script de déploiement comporte trois étapes manuelles que quelqu'un oublie toujours », une sortie typique se lirait ainsi :
Conseils pratiques
- Lancez ce prompt avant votre prochain cycle de planification, et non pendant — la conversation de scoring fait remonter des désaccords sur les priorités business qu'il vaut mieux résoudre avant que les capacités soient allouées, et non lors d'une réunion de roadmap tendue.
- Utilisez les justifications en langage clair mot pour mot lorsque vous demandez un budget ou des effectifs supplémentaires — elles sont conçues pour passer devant un public non technique sans que vous ayez besoin de traduire à la volée.
- Relancez le prompt chaque fois que la priorité business déclarée change (de croissance à stabilité, par exemple) — la même liste de technical debt devrait produire une séquence sensiblement différente, et si ce n'est pas le cas, les paramètres de scoring sont à revoir.
- Ne sautez pas l'étape de déprioritisation explicite — une liste de technical debt où tout est « important » est la raison la plus fréquente pour laquelle les roadmaps de remédiation ne survivent jamais au contact d'un sprint réel.