Une dette qu'on ne peut pas refactorer
La dette technique se rembourse : on réécrit un module, on ajoute des tests, on met à jour une dépendance. Chaque remboursement est partiel, mesurable et arrêtable.
La dette de plateforme fonctionne autrement. Elle naît quand le besoin dépasse ce que l'outil sait faire, et aucun effort interne ne la réduit : vous ne pouvez pas refactorer une limite de la plateforme. Elle ne se règle qu'en changeant d'outil, ce qui est un chantier indivisible et coûteux. C'est précisément pour cela qu'elle est repoussée jusqu'au moment où elle bloque l'activité.
Comment elle se manifeste
Les contournements deviennent la norme. Un service tiers ajouté pour faire ce que l'outil ne fait pas, puis un deuxième, puis une automatisation pour relier les deux. Chaque contournement paraît raisonnable isolément.
Les demandes métier reçoivent la même réponse. Quand « ce n'est pas possible avec notre outil » revient plusieurs fois par trimestre, ce n'est plus une contrainte technique, c'est un frein commercial.
La facture progresse plus vite que l'usage. Signe que vous êtes sur la partie coûteuse de la grille tarifaire, celle qui monétise votre croissance.
Une seule personne sait comment ça marche. La logique vit dans un éditeur visuel non documenté, non versionné, que personne d'autre n'ose modifier.
Pourquoi elle s'aggrave silencieusement
Parce que chaque contournement soulage le symptôme et augmente la dépendance. Le service tiers ajouté aujourd'hui devient une pièce du système demain, et le coût de sortie inclut désormais ce service en plus de la plateforme initiale.
Elle s'aggrave aussi parce qu'elle n'appartient à personne. La dette technique est portée par l'équipe technique, qui la voit et la porte à l'ordre du jour. La dette de plateforme se répartit entre le métier, qui subit les refus, et la direction, qui voit la facture, sans que personne ne rapproche les deux.
Comment la traiter
En la mesurant avant qu'elle ne bloque. Trois indicateurs suffisent : le nombre de demandes métier refusées pour raison d'outil, le coût annuel cumulé de la plateforme et de ses satellites, et l'estimation à gros grain du coût de sortie. Voir TCO logiciel pour la méthode.
Ces trois chiffres transforment un ressenti diffus en arbitrage. Et l'arbitrage est le plus souvent progressif : sortir d'abord le processus le plus critique vers un développement dédié, laisser le reste en place, et réexaminer un an plus tard. Une migration totale et immédiate est rarement le bon plan, mais l'attente passive ne l'est jamais. Voir aussi vendor lock-in.
