Dette technique : votre app est lente ou mal codée ?

Un fondateur m'appelle un mardi. Son app SaaS rame depuis deux semaines. Son développeur a passé trois jours à "investiguer" et son verdict tombe : il faut refaire l'architecture. Budget estimé : 40 000 euros. Minimum trois mois.

Le fondateur me demande un deuxième avis. Je regarde l'hébergement. L'application tourne sur un serveur à 7 euros par mois. Sept euros. Pour une app avec 800 utilisateurs actifs.

On passe à 50 euros par mois. Deux heures de travail. L'app vole.

Pas besoin de refaire l'architecture. Pas besoin de 40 000 euros. Le serveur étouffait, c'est tout. Ce genre de situation, je le croise régulièrement. Un problème d'infrastructure déguisé en dette technique informatique — et un devis de refonte qui n'aurait rien résolu.

La dette technique, c'est quoi (sans le jargon) ?

Imaginez que vous faites construire un restaurant. Pour ouvrir vite, vous faites des compromis : la cuisine est trop petite, l'électricité est bricolée, la ventilation est sous-dimensionnée. Le jour de l'ouverture, tout fonctionne. Vous servez 30 couverts sans problème.

Six mois plus tard, vous voulez passer à 80 couverts. Et là, tout coince. La cuisine est trop étroite pour un deuxième cuisinier. L'électricité ne supporte pas un four supplémentaire. Chaque amélioration nécessite de casser un mur.

C'est exactement ça, la dette technique informatique. Des raccourcis pris pendant le développement — parfois volontairement pour aller plus vite, parfois par manque de compétence — qui rendent chaque évolution future plus lente, plus risquée et plus chère.

Ce que les dirigeants ne réalisent pas toujours : la dette technique ne rend pas forcément votre application lente. Elle rend votre équipe lente. Une fonctionnalité qui devrait prendre deux semaines en prend six. Un bug corrigé en fait apparaître deux autres. Votre développeur passe plus de temps à contourner les problèmes existants qu'à construire du neuf.

D'ailleurs, ne confondez pas dette technique et bugs. Un bug, c'est quelque chose qui ne marche pas — un bouton qui plante, un calcul faux. La dette technique, c'est du code qui marche aujourd'hui mais qui rend les évolutions de demain difficiles ou dangereuses. On peut avoir une app sans bug apparent et crouler sous la dette technique.

Les symptômes que vous pouvez repérer sans lire une ligne de code

Vous n'avez pas besoin de comprendre le code pour détecter la dette technique. Trois signaux d'alerte fiables.

Le temps de développement qui dérive. Au début du projet, les fonctionnalités sortaient en quelques jours. Maintenant, la moindre modification prend des semaines. Votre développeur vous dit que "c'est plus compliqué que prévu" de plus en plus souvent. Ce n'est pas forcément de la mauvaise volonté — c'est un code qui est devenu un labyrinthe.

Les bugs qui reviennent. Vous signalez un problème, votre dev le corrige, et deux semaines plus tard un problème similaire réapparaît ailleurs dans l'application. C'est le signe que le code est tellement enchevêtré qu'une correction à un endroit casse quelque chose à un autre.

Les estimations qui explosent systématiquement. Cinq jours estimés, trois semaines réelles. Pas parce que votre dev est incompétent, mais parce qu'il découvre en cours de route que les fondations ne supportent pas ce qu'il essaie de construire.

Un cas que j'ai vu l'an dernier résume bien le problème. Une app e-commerce construite à l'origine pour gérer 50 produits. Le catalogue avait grandi à 8 000 références. L'application chargeait tous les produits en mémoire à chaque requête — pour 50, ça passait inaperçu. Pour 8 000, chaque page mettait 12 secondes à s'afficher. La correction — paginer les requêtes — a pris deux semaines. Pas trois mois de refonte. Un correctif ciblé sur le bon composant.

Dette technique ou infra : le diagnostic en 4 questions

Voici les questions que je pose systématiquement quand un client me dit "mon app est lente". Vous pouvez les poser à votre développeur vous-même.

1. Depuis quand c'est lent ? Si l'app a toujours été lente, même avec peu d'utilisateurs, c'est probablement un problème d'infrastructure ou de configuration. Si la lenteur est apparue progressivement avec la croissance, c'est plus souvent de la dette technique.

2. C'est lent pour tout le monde en même temps ? Tout le monde rame au même moment → problème de serveur, il n'a pas assez de puissance. C'est aléatoire ou ça touche certaines pages et pas d'autres → problème de code.

3. Les ralentissements sont pires aux heures de pointe ? Lent le matin quand tout le monde se connecte, fluide à 22h ? Votre infrastructure ne grandit pas avec votre usage. Ça se corrige côté hébergement, sans toucher au code.

4. Votre développeur peut corriger le problème en une journée ? Demandez-lui franchement. S'il peut, c'est de l'infra ou de l'optimisation ponctuelle. S'il parle de "refactoriser", "reprendre les fondations" ou "revoir l'architecture", c'est de la dette.

Ce diagnostic n'est pas infaillible. Mais il permet de trier correctement la grande majorité des situations — et surtout, il vous évite d'engager 40 000 euros quand le problème se règle en changeant de serveur.

Ce qui se règle en quelques heures

Quand le diagnostic pointe vers l'infrastructure, la bonne nouvelle c'est que les solutions sont rapides et peu chères.

Monter en gamme sur l'hébergement. Passer d'un serveur mutualisé à un serveur dédié, ou simplement choisir une offre avec plus de puissance. Coût : entre 20 et 200 euros par mois. Temps de migration : quelques heures.

Ajouter un CDN. Un réseau de serveurs qui rapproche le contenu de vos utilisateurs, où qu'ils soient. Si vos images ou fichiers mettent du temps à charger, un CDN divise les temps de chargement. Souvent gratuit ou quelques dizaines d'euros par mois.

Optimiser la base de données. Ajouter des index — des sortes de tables des matières qui permettent de retrouver une information sans parcourir toute la base. Une intervention d'une demi-journée pour un dev compétent. J'ai vu des temps de réponse divisés par 10 avec cette seule opération.

L'histoire du serveur à 7 euros n'est pas un cas extrême. Je vois régulièrement des applications en production sur des hébergements choisis au lancement pour leur prix — et que personne n'a pensé à upgrader quand les utilisateurs se sont multipliés.

Budget total pour ce type de correction : entre 200 et 2 000 euros. À comparer aux dizaines de milliers d'euros d'une refonte. Pour situer ces chiffres dans le contexte global, j'ai détaillé les vrais coûts d'une application en 2026.

Quand c'est vraiment de la dette technique — et pourquoi "tout refaire" est rarement la réponse

Si le diagnostic pointe vers la dette technique, la réaction instinctive de beaucoup de développeurs est de tout réécrire. C'est compréhensible. Travailler dans du code mal structuré, c'est frustrant au quotidien. Mais réécrire un produit entier, c'est un projet à part entière — avec ses propres risques et ses propres dérapages.

Un fondateur m'a raconté son expérience. Il a payé 60 000 euros pour une refonte complète. Six mois de travail. L'ancienne app avait un vrai problème de performance. La nouvelle était plus propre, mieux structurée... et pas plus rapide. Le goulot d'étranglement — une base de données sans index — existait dans les deux versions. Deux jours de travail sur l'ancien code auraient suffi.

En 15 ans de carrière, j'ai vu exactement deux projets qui nécessitaient réellement une refonte totale. Deux. Dans tous les autres cas, le problème était localisé. On identifie les composants qui posent problème, on les corrige un par un, sans arrêter le produit et sans repartir de zéro.

Le refactoring ciblé coûte entre 5 000 et 30 000 euros selon la taille du problème. Une refonte complète, c'est 30 000 à 100 000 euros — sans compter les mois de retard sur votre roadmap pendant lesquels vos concurrents avancent.

Si votre développeur vous dit "il faut tout refaire", posez-lui cette question : quel composant précis pose problème, et combien coûte sa correction sans tout réécrire ? Si la réponse est vague — "c'est l'ensemble", "tout est lié" — c'est un signal d'alerte. Un bon diagnostic technique est toujours précis.

C'est ce type de diagnostic qu'un CTO externe peut apporter : un regard indépendant, sans intérêt à gonfler le devis, qui traduit la réalité technique en décision business.

Éviter que le problème revienne

Tout le monde accumule de la dette technique. Ce n'est pas un signe d'échec — c'est la conséquence normale de choix faits sous contrainte de temps et de budget. Le problème, ce n'est pas d'en avoir. C'est de ne pas la gérer.

Faites auditer votre code régulièrement. Pas quand l'app ralentit — avant. Un audit de code annuel coûte entre 1 500 et 4 000 euros. C'est l'équivalent technique du bilan comptable : vous savez où vous en êtes, ce qui doit être corrigé en priorité, et ce qui peut attendre. J'ai détaillé ce que contient un audit et ce qu'il coûte dans un article dédié.

Réservez du temps pour la maintenance. La règle que j'applique avec mes clients : 15 à 20% du temps de développement consacré à la réduction de dette. Pas 100% sur les nouvelles fonctionnalités. C'est un investissement qui maintient la capacité de votre équipe à livrer vite sur le long terme.

Ayez un regard technique indépendant. Si votre seul interlocuteur technique est celui qui a écrit le code, vous n'avez qu'une version de l'histoire. Un avis extérieur ponctuel — un CTO à temps partagé, un auditeur — vous donne la visibilité qui vous manque pour décider en connaissance de cause.

La prochaine fois que votre dev dit "il faut tout refaire"

La dette technique informatique est un vrai sujet. Mais une application lente n'est pas toujours un problème de code. Et un problème de code ne nécessite presque jamais de tout reconstruire.

La prochaine fois que votre développeur vous propose une refonte, sortez les quatre questions du diagnostic. Si c'est de l'infra, la correction prend des heures et coûte quelques centaines d'euros. Si c'est de la dette, exigez un diagnostic précis — quel composant, quel coût, quel risque — avant d'engager un budget à cinq chiffres.

Et si vous n'avez personne en interne capable de faire ce tri, c'est exactement à ça que sert un CTO externe.