Comment parler de dette technique à un COPIL
La dette technique est le sujet que personne ne veut porter en COPIL. Les PMs l'évitent parce que c'est difficile à quantifier. Les ingénieurs tentent de pousser mais savent qu'on leur dira de prioriser les features.
Résultat : on ne l'aborde jamais vraiment, ou pas assez, jusqu'au jour où ça devient bloquant.
Le problème de cadrage habituel
La plupart des COPILs adorent parler des nouvelles features. Beaucoup moins des sujets qui ralentissent silencieusement l’organisation depuis des mois. La dette technique fait partie de ces sujets.
Le problème, ce n’est pas que les dirigeants “ne comprennent pas la tech”. Le problème, c’est qu’on présente souvent la dette technique comme un problème d’ingénieurs, alors qu’il s’agit en réalité d’un problème de capacité produit future.
Le bon cadrage : impact produit
La dette technique devient décisionnaire quand elle est traduite en impact produit mesurable.
Avant
« On a besoin de X sprints pour refactorer la feature Y. »
Après
« Chaque nouvelle feature sur le checkout prend actuellement 3x plus longtemps qu'elle ne devrait, à cause du couplage fort entre le module de paiement et le catalogue. Si on ne résout pas ça avant Q3, le projet de personnalisation des offres prendra 6 semaines au lieu de 2. »
La différence ? Le second argument est exprimé en coût d'opportunité futur, pas en travail technique passé.
La matrice impact/urgence
Pour présenter la dette en réunion stratégique, j'utilise une matrice simple :
| Type de dette | Impact sur la vélocité | Risque si non traité | Priorité |
|---|---|---|---|
| Couplage module paiement | Élevé (-40% sur checkout) | Bloquer Q3 | P1 |
| Tests unitaires insuffisants | Moyen | Régressions fréquentes | P2 |
| Logging manquant | Faible | Debugging lent | P3 |
Cette présentation transforme un sujet opaque en décision de priorisation normale.
Ce qu'il ne faut PAS faire
- Ne pas tout mettre dans le même sac. ( soyez stratégique et n'allez pas au charbon pour toutes les batailles) « On a de la dette partout » ne mène nulle part. Sélectionne 2-3 points critiques.
- Ne pas parler en jargon technique. Coupling, refactoring, legacy — ces mots ne résonnent pas.
- Ne pas demander un sprint dédié générique. Demande un résultat précis : « réduire le temps moyen de delivery sur le checkout de 3 semaines à 1 semaine d'ici fin Q2. »
Le bon moment pour en parler
Le meilleur moment pour adresser la dette technique en COPIL, c'est avant un chantier majeur, pas pendant. Intègre-la dans le planning de la roadmap : « pour livrer X, on a besoin de d'abord adresser Y ».
Pour finir
Toutes les dettes techniques ne doivent pas être traitées immédiatement. Certaines peuvent rester en place longtemps sans impact majeur.
Le rôle du PM n’est pas de défendre “moins de dette” de manière abstraite. Le rôle est d’identifier :
quelles dettes ralentissent réellement le produit, lesquelles augmentent le risque, et lesquelles menacent la roadmap future.
Sinon, la discussion devient idéologique au lieu d’être stratégique.
Si tu as des questions sur comment structurer ce type de présentation, n'hésite pas à me contacter.