# Legacy ou dette technique, aveu d’échec ou moteur d’innovation ?

## **La dette technique n’est pas un aveu d’échec, c’est le moteur de votre innovation.**

Legacy ou dette technique, ce terme est parfois perçu comme un véritable gros mot, mal connu, mal perçu et mal communiqué. Il glace le sang de n’importe quel développeur, un nouvel arrivant s’imagine devoir passer des mois sur de la correction pure. Mais il terrorise tout autant les autres *stakeholders* : les équipes produit, la direction, les comités … etc. On l’associe instantanément à un code médiocre, à des hacks bâclés, et à un manque de professionnalisme. En tant que CTO, je ne peux que constater que cette vision est non seulement réductrice, mais aussi dangereuse. Car, si on la considère comme un aveu d’incompétence, on refuse d’aborder un sujet qui est au cœur de notre métier.

La réalité est bien différente. La dette technique n’est pas un ennemi à abattre, mais un outil stratégique à maîtriser. C’est une conséquence inhérente à l’agilité, à l’innovation, et à la croissance d’un produit. Elle est aussi l’évolution naturelle du code, même le plus qualitatif. Un code parfait à un instant T peut devenir une dette technique avec le temps, à mesure que les technologies, les langages et les pratiques évoluent. Loin d’être un échec, la dette technique est souvent la preuve que nous avons fait les bons choix au bon moment pour le business.

Il est temps de déconstruire les mythes et de réapprendre à dialoguer sur ce qui est le moteur de notre évolution.

## **🗺️ La dette technique : plus qu’un “mauvais code”**

L’idée même de dette technique a été popularisée par Ward Cunningham en 1992 (co-auteur du *Manifeste pour le développement Agile de logiciels*). Il l’a imaginée comme une métaphore financière : un raccourci de développement (“*contracter la dette*”) nous permet de livrer une fonctionnalité rapidement, mais génère des “intérêts” futurs, c’est-à-dire un coût supplémentaire pour la maintenance et les modifications à venir.

Or, le terme a été galvaudé. Pour beaucoup, “dette technique” est devenu un synonyme de “code de mauvaise qualité”. Si un code est difficile à lire, mal documenté, ou truffé de bugs, on l’estampille “dette technique”. C’est un raccourci intellectuel qui masque la véritable nature du phénomène.

En réalité, il existe plusieurs types de dette, et toutes n’ont pas la même valeur :

*   La dette intentionnelle (ou “prudente”) : C’est un choix délibéré et stratégique. Par exemple, une fonctionnalité doit être livrée en urgence pour répondre à une opportunité de marché. L’équipe choisit une solution rapide, en sachant pertinemment qu’elle devra y revenir plus tard pour la “refactoriser” et la rendre plus robuste. C’est un investissement dans le futur de l’entreprise, en échange d’un travail à accomplir plus tard. C’est une décision saine et calculée, qui a permis de gagner un avantage concurrentiel en réduisant significativement le *time to market*. Situation qui s’applique très bien au monde des *startups early stage*, où le *time to market* est un point critique pour l’amorçage.
    
*   La dette involontaire (ou “imprudente”) : Celle-ci est le résultat d’un manque d’expérience, de connaissances, ou d’un manque de vigilance. L’équipe a fait de son mieux, mais a fait des erreurs de conception ou de mise en œuvre. Elle peut également être le symptôme d’une absence de stratégie cohérente et globale sur la stack technique, ou d’une politique de recrutement axée sur la réduction des coûts et non sur les compétences. C’est le type de dette qu’il faut absolument réduire au maximum grâce à de bonnes pratiques, des revues de code et de la formation. Comme j’aime à le dire : il vaut mieux former des personnels qui partiront, que de rester avec ceux que l’on ne forme pas.
    
*   La dette environnementale et “Bit rot” : C’est une dette qui s’accumule avec le temps. L’écosystème évolue : les langages de programmation vieillissent, les frameworks deviennent obsolètes, les dépendances ne sont plus maintenues. Même un code initialement parfait devient une dette s’il n’est pas régulièrement maintenu et mis à jour.
    

Comprendre ces nuances est essentiel. Cela permet de sortir du fantasme du “code parfait” et d’embrasser la réalité de notre métier : nous gérons un patrimoine technologique vivant, qui est en constante évolution.

## **📈 Pourquoi la dette technique est un indicateur de succès (parfois)**

Il est crucial de cesser de voir la dette technique comme un échec. Si une entreprise n’a pas de dette technique, cela signifie souvent qu’elle est en situation de stagnation. Cela peut indiquer :

*   Un manque d’ambition : L’entreprise ne prend aucun risque. Elle avance lentement, n’expérimente pas, et ne saisit pas les opportunités de marché rapides.
    
*   Un produit sans succès : Si le produit n’a pas évolué depuis des années, il n’y a pas eu de nouvelles fonctionnalités à livrer, donc pas de dette à accumuler.
    
*   Un manque de croissance : Le business n’a pas grandi au point de nécessiter de nouvelles architectures, des optimisations, ou des mises à l’échelle.
    

Un exemple parfait pour illustrer ce point est celui des systèmes bancaires historiques. On parle de la compensation pour les échanges interbancaires, des systèmes qui font les échanges avec les autres banques sur les mouvements bancaires qu’ils partagent. Ces systèmes sont parfois codés dans des langages dont ils sont les seuls à encore les utiliser. Ils sont extrêmement robustes et n’évoluent pas depuis des décennies.

> *“Le véritable enjeu est de ne pas ignorer cette dette et de l’adresser de la manière la plus adaptée.”*

## **🏦 Gérer la dette technique comme un investissement**

La gestion de la dette technique doit être une priorité stratégique, pas une corvée reléguée aux moments de calme (qui n’arrivent jamais) ou par à-coups. Voici quelques pistes pour la transformer en un avantage :

1.  **Visibilité et communication :** La dette technique ne doit plus être une discussion de couloir entre développeurs. Elle doit être quantifiée, mesurée, et intégrée au backlog produit. Un product manager et un technical manager qui parlent le même langage sur ce sujet ont un avantage stratégique énorme.
    
2.  **L’amortissement régulier :** Comme une dette financière, la dette technique doit être remboursée régulièrement. Il ne s’agit pas d’un “big bang” de refonte, ni d’un sprint de temps à autre. Il faut allouer une fourchette de 20 % à 30 % du temps à chaque sprint à l’amélioration de la qualité du code et à la maintenance technique (*on ne parle pas ici de temps pour, corriger des bugs d’une itération précédente ou traiter un retour client*). C’est le seul moyen d’éviter que les intérêts ne s’accumulent. La réduction de la dette est une manière d’innover plus rapidement pour répondre aux opportunités futures du marché, et non un frein à l’innovation.
    
3.  **L’implication des équipes :** Les développeurs ne doivent pas être vus comme de simples “réparateurs de bugs”. Ils sont les mieux placés pour identifier la dette technique et proposer des solutions. En les impliquant dans la prise de décision, on les responsabilise et on leur redonne le sentiment de posséder le code.
    

La dette technique, bien gérée, permet à l’équipe d’être plus agile, plus rapide, et plus efficace sur le long terme. Elle est le signal qu’un produit est en vie, qu’il grandit, et que l’équipe est prête à relever de nouveaux défis.

## **💡 De la dette à l’actif stratégique**

Au terme de cette réflexion, il est clair que la dette technique n’est pas un concept à fuir ou un problème à ignorer. Elle est une composante inhérente à notre métier, un reflet direct de la vitesse à laquelle nous innovons et des choix que nous faisons. Dans un monde où les technologies évoluent en permanence et où le marché exige une réactivité constante, le code, même excellent, devient inévitablement obsolète.

> *“L’important n’est pas d’avoir ou non de la dette, car on en aura quoi qu’il arrive, mais de ne pas l’ignorer et de l’adresser correctement au bon moment”*

Le terme “dette technique” est en réalité un agrégat de points techniques concrets et vitaux pour une entreprise : migration de code, refactorisation, correction de bugs, optimisation des performances, amélioration de la scalabilité ou réduction des coûts de fonctionnement. C’est en faisant admettre cette réalité aux *stakeholders* que l’on passe d’une vision d’un mot “vulgaire” à celle d’un investissement stratégique continu. Rien n’est plus préjudiciable pour une organisation que de voir les équipes techniques se battre avec un code illisible, alors que la direction refuse d’allouer du temps à l’amélioration pour délivrer toujours plus et plus vite. La difficulté principale est justement de faire comprendre que ces sujets ne doivent pas être traités de manière ponctuelle, mais de manière continue, avec le même sérieux que les nouvelles fonctionnalités.

## **💡 Conclusion :**

C’est lorsqu’elle est ignorée ou mal traitée que la dette technique se transforme en passif. À ce moment-là, le coût de la maintenance explose, la vélocité de l’équipe s’effondre, et la motivation ou l’engagement des développeurs finit par disparaître. J’ai trop souvent vu des talents préférer quitter le navire face à une complexité qui aurait pu être évitée. Ils s’épuisent à combattre des systèmes figés et, lorsqu’ils ne se sentent pas écoutés par l’entreprise sur la nécessité de s’attaquer sérieusement au problème, ils choisissent de partir. L’entreprise perd alors ses ressources les plus précieuses.

Gérer la dette technique, c’est finalement une question de maturité. C’est reconnaître que l’investissement continu dans la qualité du code est un atout stratégique majeur. C’est donner aux développeurs les moyens d’innover plus rapidement en réduisant la friction. C’est transformer un sujet perçu comme repoussant en un avantage concurrentiel tangible.

> *“En fin de compte, la dette technique est un choix : celui de l’ignorer et de risquer l’immobilisme, ou celui de la maîtriser et d’accélérer notre capacité à créer de la valeur.”*

David DOYEN  
CTO [Bankin’](https://bankin.com)