Dette technique : 5 erreurs qui coûtent 6 mois

"Trois mois." C'est ce que m'a dit le CTO d'une startup SaaS quand je lui ai demandé combien de temps prendrait la migration d'Angular vers React. Huit mois plus tard, la migration n'était toujours pas terminée, deux développeurs avaient démissionné, et 15% des clients étaient partis.

Ce n'est pas un cas isolé. Sur les 12 dernières migrations que j'ai accompagnées ou auditées, une seule a tenu son planning initial. Une sur douze. Les autres ont dépassé de 2 à 5 mois, coûté le double ou le triple du budget prévu, et dans trois cas, provoqué des départs dans l'équipe technique.

La dette technique, c'est le sujet où l'écart entre la théorie et la réalité est le plus violent. Voici les cinq erreurs que je vois revenir systématiquement — et comment les éviter.

La dette technique, c'est quoi pour un dirigeant ?

Avant de parler migration, il faut comprendre ce qui la rend nécessaire.

La dette technique, c'est l'accumulation de raccourcis pris pour aller plus vite. Imaginez que vous construisez un immeuble et que, pour gagner trois mois, vous posez les câbles électriques sans gaine, sautez l'isolation, vissez au lieu de souder. L'immeuble tient debout. Les gens y habitent. Mais chaque modification — ajouter une prise, déplacer une cloison — prend trois fois plus de temps parce qu'il faut défaire ce qui a été mal fait.

En logiciel, c'est pareil. Une fonctionnalité qui prenait 2 jours au lancement de votre produit en prend maintenant 10. Vos développeurs passent plus de temps à corriger des bugs qu'à avancer. Chaque mise à jour casse autre chose.

Comment savoir si votre dette technique est devenue critique ? Trois signaux concrets :

• Le temps de livraison explose. Une fonctionnalité simple prend des semaines. L'équipe technique parle de "complexité" sans pouvoir l'expliquer en termes business.
• Les bugs deviennent chroniques. Chaque correction en crée un nouveau. L'équipe passe ses sprints à éteindre des incendies.
• Vos devs vous parlent de "tout réécrire". C'est le stade terminal. Quand l'équipe préfère repartir de zéro plutôt que toucher au code existant, la dette a atteint un niveau qui coûte plus cher à maintenir qu'à rembourser.

La question n'est pas "est-ce qu'on a de la dette technique ?" — toute application en a. La vraie question : est-ce que cette dette freine votre croissance au point de justifier une migration ?

Erreur n°1 — Le "big bang" : tout réécrire d'un coup

C'est l'erreur la plus séduisante. Et la plus destructrice.

La startup SaaS dont je parlais en intro a fait exactement ça. 40 000 utilisateurs, un produit qui marchait mais qui ralentissait. Le CTO, compétent par ailleurs, a décidé de réécrire l'application complète sur une nouvelle stack. Toute l'équipe a basculé sur le nouveau projet.

Au mois 4, les premiers dégâts sont apparus. L'ancienne application continuait de tourner, mais plus personne ne corrigeait les bugs — tout le monde était sur la réécriture. Les tickets de support ont doublé. Au mois 6, l'équipe a réalisé qu'elle avait oublié des fonctionnalités dans la nouvelle version. Des trucs que personne n'avait documentés. Que les utilisateurs utilisaient au quotidien. Et dont l'équipe technique avait oublié l'existence.

Résultat final : 8 mois au lieu de 3, deux développeurs partis, un churn client de 15%.

Pourquoi c'est tentant : repartir de zéro, c'est propre. On fait les choses "bien" cette fois. L'équipe technique est enthousiaste. Sur le papier, le planning est limpide.

Pourquoi ça échoue : parce qu'on sous-estime toujours la complexité du système existant. Un logiciel en production depuis deux ans, c'est des centaines de décisions implicites, de cas particuliers, de comportements que les utilisateurs considèrent comme normaux. Réécrire, c'est les redécouvrir un par un — à la dure.

Erreur n°2 — Pas de plan de retour en arrière

Un client dans la fintech a migré sa base de données de MongoDB vers PostgreSQL. Décision pertinente — PostgreSQL est plus adapté aux données structurées et aux transactions financières.

La migration a été lancée un vendredi soir. Lundi matin, l'équipe a découvert des données incohérentes. Des montants qui ne correspondaient pas, des références croisées cassées, des comptes utilisateurs dupliqués.

Le problème : aucun plan de rollback. Pas de snapshot de la base avant migration. Pas de procédure pour revenir à l'état précédent.

Trois semaines de réconciliation manuelle. Ligne par ligne. Coût : environ 40 000€ en temps de développement. Et un client B2B majeur — une société de gestion — qui a résilié. Quand une fintech perd des données, la confiance ne revient pas.

Un rollback, pour faire simple, c'est un bouton "annuler". Si la migration se passe mal, on revient à la version précédente comme si rien ne s'était passé. Chaque étape de votre migration devrait en avoir un. C'est du travail en amont, mais c'est une assurance qui coûte infiniment moins cher que le sinistre.

Erreur n°3 — Migrer sans filet de sécurité

Migrer sans tests automatisés, c'est changer le moteur d'une voiture sans pouvoir vérifier qu'elle roule encore.

Les tests automatisés, dans ce contexte, ce sont des vérifications programmées qui garantissent que chaque fonctionnalité continue de marcher après la migration. "Quand un client passe une commande, le paiement est bien débité." "Quand on modifie un profil, les données sont sauvegardées." Des choses évidentes — sauf qu'elles cassent de façon non évidente.

Sur la migration Angular-React, l'une des raisons du dérapage était justement ça. L'équipe a découvert au mois 6 que la fonction d'export de rapports — utilisée quotidiennement par les clients B2B — ne fonctionnait plus dans la nouvelle version. Personne ne l'avait testée. Personne n'y avait pensé. Trois semaines de travail supplémentaires pour une fonctionnalité qui aurait pu être vérifiée automatiquement dès le jour 1.

Avant de lancer une migration, un audit du code existant permet de cartographier ce qui doit impérativement être couvert par des tests. Si votre application n'en a pas, commencer par "poser le filet de sécurité" n'est pas du temps perdu. C'est ce qui empêche de découvrir les problèmes 6 mois trop tard.

Erreur n°4 — Sous-estimer la durée et ignorer le coût d'opportunité

Voici un chiffre que je partage avec chaque dirigeant que j'accompagne : multipliez l'estimation de votre équipe technique par 2,5. Ce n'est pas du pessimisme, c'est la moyenne que j'ai observée sur une douzaine de projets de migration.

Pourquoi les estimations sont-elles toujours fausses ? Parce qu'elles comptent le temps de développement pur. Pas le temps total. Le temps total inclut la découverte de problèmes imprévus, la correction de bugs dans l'ancien système qui bloquent la migration, les phases de tests, la documentation, la formation des utilisateurs, le debugging des cas limites que personne n'avait anticipés.

Mais le vrai piège, c'est le coût d'opportunité. Et celui-là, personne ne le met dans le budget.

J'ai accompagné une startup en forte croissance qui a gelé toutes les nouvelles fonctionnalités pendant 4 mois pour "rembourser la dette technique". L'intention était bonne. En pratique, pendant ces 4 mois, deux concurrents ont lancé des fonctionnalités que ses clients réclamaient. Le board a commencé à poser des questions. L'équipe commerciale n'avait rien de neuf à vendre.

La migration a abouti. Le code était plus propre, plus rapide, mieux structuré. Mais la boîte avait perdu sa dynamique commerciale. Le coût des fonctionnalités non livrées a dépassé le coût de la migration elle-même.

Avant de lancer une migration, posez cette question : pendant qu'on migre, qu'est-ce qu'on ne fait pas ? Et combien ça coûte de ne pas le faire ?

Erreur n°5 — Foncer sans cartographier l'existant

"On connaît notre produit, on sait ce qu'il fait." Non. Pas complètement.

Sur les 12 migrations que j'ai accompagnées, la seule qui a tenu son planning est aussi la seule où l'équipe a passé trois semaines à cartographier l'existant avant d'écrire une ligne de code. Chaque écran, chaque fonctionnalité, chaque cas particulier, chaque intégration avec un service tiers. Le tout documenté et validé avec les utilisateurs clés.

Les 11 autres ont commencé par le code.

Ce qui manque, on le découvre toujours trop tard. Une fonctionnalité d'export que personne dans l'équipe technique n'utilise, mais que 30% des clients utilisent chaque semaine. Un workflow de validation spécifique à un gros client, implémenté il y a 18 mois par un freelance parti depuis. Un comportement non documenté que les utilisateurs considèrent comme acquis.

Découvrir ça au mois 6, c'est refaire le planning, décaler les deadlines, et expliquer au board pourquoi ça prend encore plus de temps. Découvrir ça au mois 1, c'est un ajustement de planning de 48 heures.

C'est aussi à cette étape qu'il faut poser la vraie question : faut-il tout migrer, ou seulement les parties qui posent problème ? Dans 9 cas sur 10, une refonte ciblée suffit. Elle coûte 3 à 5 fois moins cher qu'une réécriture complète, et elle aboutit 3 à 5 fois plus vite.

Comment rembourser sa dette technique sans tout casser

Les migrations qui marchent suivent toutes le même schéma. Et ce n'est pas le big bang.

Un de mes clients a migré son backend Node.js vers un nouveau framework. 30 000 utilisateurs, une application métier critique, zéro tolérance à l'interruption de service. La migration a duré 6 mois — le planning prévu — et aucun utilisateur n'a vu la différence.

Qu'est-ce qui a fait la différence ?

Migration progressive, module par module. Chaque semaine, un module était migré, testé en parallèle de l'ancien, puis basculé. Si un problème apparaissait, retour à l'ancien module en 5 minutes. Les utilisateurs n'ont rien vu.

Un mois de préparation avant de toucher au code. L'équipe a écrit des tests sur les fonctionnalités critiques du système existant et cartographié toute l'application. C'est ce mois "perdu" qui a permis de gagner les cinq suivants.

Un point hebdomadaire de 15 minutes avec le dirigeant. Pas des réunions techniques. Un suivi factuel : qu'est-ce qui a été migré cette semaine, qu'est-ce qui a cassé, qu'est-ce qui est prévu. Le dirigeant savait où en était le projet sans avoir besoin de comprendre le code.

Checklist avant de lancer votre migration

Posez ces questions à votre équipe technique. Si la réponse est "non" à plus de deux, vous n'êtes pas prêts :

• Toutes les fonctionnalités existantes sont-elles documentées et validées avec les utilisateurs ?
• Chaque étape de la migration a-t-elle un plan de retour en arrière ?
• Les fonctionnalités critiques sont-elles couvertes par des tests automatisés ?
• L'estimation a-t-elle été revue par quelqu'un d'extérieur à l'équipe ?
• La migration est-elle découpée en étapes indépendantes qu'on peut livrer une par une ?
• Le coût des fonctionnalités gelées pendant la migration a-t-il été chiffré ?

La dette technique n'est pas une fatalité. Mais la rembourser sans méthode, c'est souvent ce qui coûte le plus cher — en temps, en argent, et en énergie. Si vous sentez que votre produit ralentit et que votre équipe technique parle de migration, le bon réflexe n'est pas de leur dire "allez-y". C'est de poser les bonnes questions. Et si vous ne savez pas lesquelles poser, un regard technique extérieur avant de lancer le chantier peut vous éviter 6 mois de retard et quelques nuits blanches.