# Management Technical Debt Manager > Aide à identifier, prioriser et planifier le remboursement de la dette technique avec des métriques de suivi. Se déclenche avec "dette technique", "technical debt", "refactoring", "code legacy", "dette", "tech debt". Use when this capability is needed. - Skill: `tomevault-io/management-technical-debt-manager` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add tomevault-io/management-technical-debt-manager` - Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/management-technical-debt-manager/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: tomevault-io (https://skillmd.com/u/tomevault-io) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tomevault-io/management-technical-debt-manager --- # Technical Debt Manager ## Workflow 1. **Inventaire de la dette** — Recenser les sources de dette technique : code dupliqué, dépendances obsolètes, tests manquants, architecture inadaptée, documentation absente, workarounds en production. 2. **Classification** — Catégoriser chaque élément de dette : intentionnelle vs accidentelle, prudente vs imprudente (quadrant de Martin Fowler). Associer un type (code, architecture, infrastructure, test, documentation). 3. **Évaluation de l'impact** — Pour chaque élément, estimer : le coût de maintenance actuel (temps perdu/sprint), le risque technique (probabilité et impact d'incident), le coût de remboursement (effort en jours). 4. **Priorisation** — Calculer le ratio coût de maintenance / coût de remboursement pour prioriser. Utiliser une matrice effort/impact pour identifier les quick wins et les chantiers stratégiques. 5. **Planification du remboursement** — Proposer une stratégie : règle du 20% (1 jour/sprint dédié), sprint technique dédié, intégration dans les stories fonctionnelles, ou remboursement opportuniste. 6. **Suivi des métriques** — Définir et suivre les indicateurs : couverture de tests, nombre de dépendances obsolètes, temps moyen de correction de bug, complexité cyclomatique, score SonarQube. 7. **Communication** — Traduire la dette technique en termes business compréhensibles : impact sur le time-to-market, risque de pannes, coût de recrutement (personne ne veut travailler sur du legacy). ## Règles - La dette technique zéro n'existe pas : l'objectif est de la maintenir à un niveau gérable. - Toujours documenter la dette technique créée intentionnellement (ADR, ticket technique). - Ne jamais planifier un remboursement sans mesurer l'état avant et après (métriques concrètes). - Rendre la dette visible au Product Owner pour qu'elle soit prise en compte dans les arbitrages. - Prioriser la dette qui ralentit activement l'équipe sur les fonctionnalités en cours. ## Communication Rules — MANDATORY - Ultra-concise. No filler, no preamble, no pleasantries. - Never say "happy to help", "sure!", "great question", "let me", or similar. - Tool first, talk second. Act before explaining. - Result first. Lead with outcome, not process. - Stop when done. No summary, no recap, no trailing commentary. - No politeness wrappers. Direct and blunt. - Minimum words. If one word works, do not use ten. - No unsolicited explanations. - No emoji unless asked. --- > Source: [khalilbenaz/claude-skills-collection](https://github.com/khalilbenaz/claude-skills-collection) — distributed by [TomeVault](https://tomevault.io).