[Temps de lecture : 9 minutes]
« On devrait tout refaire. »
C’est la phrase que Struxis entend le plus souvent lors des premiers rendez-vous. L’application a 5, 8, 10 ans. Elle rame. Le prestataire historique ne répond plus. Chaque évolution coûte une fortune et casse quelque chose. La tentation est irrésistible : repartir de zéro.
Sauf que dans 70% des cas que Struxis audite, la refonte complète est la mauvaise décision. Plus chère, plus longue, plus risquée qu’une évolution ciblée. Cet article explique comment trancher objectivement – avec des critères factuels, pas de l’intuition.
75%
des projets ERP échouent (refonte incluse)
3-5x
plus cher qu’une évolution ciblée
6-18
mois de délai pour une refonte
70%
des refontes que Struxis auditeurs étaient évitables
Le piège de la refonte « évidente »
La refonte séduit parce qu’elle promet un nouveau départ. Une ardoise vierge. Un code propre. Une interface moderne. Terminé les bugs, terminé la dette technique, terminé les contournements.
C’est un mirage. Voici ce que la refonte implique réellement :
- Re-spécifier l’intégralité du système (y compris les 200 règles métier que personne n’a documentées)
- Redévelopper 100% du code – même les 80% qui fonctionnaient très bien
- Migrer les données (la partie la plus sous-estimée et la plus risquée)
- Former les équipes à un outil entièrement nouveau
- Gérer une période de double run (ancien + nouveau système en parallèle)
- Subir 6 à 18 mois sans évolution de l’existant (l’équipe est mobilisée sur la refonte)
La refonte, c’est le projet IT le plus risqué qui existe : on reconstruit un système qui fonctionne (mal) en espérant que le nouveau fonctionnera mieux. L’histoire montre que c’est loin d’être garanti..
Les 5 signaux d’alerte : « il faut agir »
Avant de décider entre refonte et évolution, il faut d’abord confirmer que le système actuel pose un vrai problème. Voici les 5 signaux qui ne trompent pas :
🔴 Signal 1 – Les coûts de maintenance explosent
Le budget maintenance a doublé ou triplé en 2–3 ans sans amélioration visible. Chaque correction génère de nouvelles anomalies. Le prestataire passe plus de temps à corriger qu’à évoluer.
🔴 Signal 2 – Chaque évolution casse quelque chose
Pas de tests automatisés. Les modules sont interdépendants. Le prestataire n’ose plus toucher à certaines parties du code. Les évolutions demandées depuis 12+ mois ne sont toujours pas livrées.
🔴 Signal 3 – La technologie est obsolète
Le framework n’est plus maintenu (ex : PHP 5, Angular.js 1.x, Flash). Les dépendances ont des vulnérabilités connues non corrigées. Trouver un développeur compétent sur cette stack devient difficile.
🔴 Signal 4 – L’outil ne couvre plus le besoin métier
Le business a évolué, pas l’outil. Des processus entiers sont gérés sur Excel ou email parce que l’application ne les supporte pas. L’écart entre le besoin réel et l’outil se creuse.
🔴 Signal 5 – Plus personne ne comprend le code
Le développeur d’origine est parti. La documentation est inexistante. Le code est un enchevêtrement de patches accumulés sur 8 ans. Le score de reprenabilité est inférieur à 4/10.
Si 3 signaux ou plus sont présents, il faut agir. Mais « agir » ne veut pas dire « tout refaire ». Ça veut dire « auditer pour décider objectivement ».
La matrice de décision Struxis : évolution ou refonte ?
Struxis utilise une matrice à 10 critères pour recommander objectivement l’une ou l’autre approche. Chaque critère est évalué pendant l’audit, et le verdict est argumenté avec des données – pas de l’intuition.
| Critère | → Évolution recommandée | → Refonte recommandée |
| Score de reprenabilité | 5–10/10 : code maintenable | 0–4/10 : code incompréhensible |
| Dette technique | Localisée (2–3 modules) | Généralisée (> 60% du code) |
| Stack technique | Encore maintenue et recruitable | Obsolète, plus de support |
| Couverture fonctionnelle | 60–80% du besoin couvert | < 40% du besoin couvert |
| Écart existant / cible | Modéré : 5–15 fonctionnalités à ajouter/modifier | Massif : le métier a fondamentalement changé |
| Coût de l’évolution | < 40% du coût d’une refonte | > 60% du coût d’une refonte |
| Base de données | Exploitable, schéma cohérent | Corrompue, incohérente, non migrable |
| Intégrations tierces | API stables, peu de dépendances | Intégrations obsolètes, protocoles non standard |
| Risque métier d’interruption | Fort (évolution progressive préférable) | Faible (fenêtre de bascule possible) |
| Temps disponible | Court (< 6 mois) : évolution par lots | Long (12+ mois acceptables) |
💡 La règle Struxis : si 7 critères ou plus pointent vers l’évolution, la refonte est probablement disproportionnée. Si 6+ pointent vers la refonte, il faut l’envisager sérieusement – mais avec un cadrage ultra-rigoureux.
Le scénario que personne ne propose : l’évolution modulaire
Dans la réalité des projets que Struxis accompagne, le choix n’est presque jamais binaire. Il existe un troisième scénario, souvent le plus pertinent et toujours le plus ignoré :
L’évolution modulaire : on ne refait QUE ce qui doit l’être Au lieu de tout jeter et tout reconstruire, on identifie les 2–3 modules problématiques (ceux qui concentrent 80% de la dette technique et des bugs) et on les refait — un par un, lot par lot — en gardant le reste intact. C’est le scénario que Struxis recommande dans 60–70% des cas. Ses avantages : • 3 à 5 fois moins cher qu’une refonte complète |
La question n’est pas « faut-il tout refaire ? ». C’est « quels modules faut-il refaire, dans quel ordre, et lesquels peut-on garder ? » La réponse est toujours dans l’audit, jamais dans l’intuition.
Comparatif : les 3 scénarios face à face
Évolution ciblée | Évolution modulaire | Refonte complète | |
Budget typ. | 5 000–20 000 € | 20 000–60 000 € | 80 000–250 000 € |
Délai | 1–3 mois | 3–6 mois | 6–18 mois |
Risque | Faible | Modéré | Très élevé |
Interruption de service | Aucune | Aucune | 2–6 semaines |
% du code remplacé | 5–15% | 20–40% | 100% |
Impact utilisateur | Invisible | Progressif | Brutal (formation) |
Réversibilité | Facile | Par lot | Impossible |
Quand choisir | Problème localisé, score 7+/10 | Dette sur 2–3 modules, score 4–6/10 | Code irrécupérable, score < 4/10 |
3 cas concrets : la même question, 3 réponses différentes
🟢 CAS A – Évolution ciblée
TPE e-commerce, 15 salariés, appli custom PHP de 8 ans
Score de reprenabilité : 5/10. 80% du code est sain. Le problème est localisé sur 2 modules (commandes et facturation). Le prestataire a proposé une refonte à 120K€.
Verdict Struxis : évolution modulaire en 4 lots. Budget total : 42K€. Délai : 4 mois. 120K€ économisés. Zéro interruption.
🔵 CAS B – Évolution modulaire
PME services, 45 salariés, ERP custom + CRM sur mesure
Score de reprenabilité : 4/10 sur le CRM, 7/10 sur l’ERP. Le CRM est un assemblage de patches sur une base Symfony 3 (plus maintenue). L’ERP fonctionne correctement en Laravel 9.
Verdict Struxis : garder l’ERP, remplacer le CRM par Axonaut (déjà en compta) avec intégration API. Budget : 35K€. Refonte globale évitée : 180K€.
🔴 CAS C – Refonte justifiée
PME industrielle, 120 salariés, logiciel métier Access + VBA de 15 ans
Score de reprenabilité : 1/10. Base Access avec 8 000 lignes de VBA, 0 documentation, 0 tests, données incohérentes, performances catastrophiques. Le système plante 2–3 fois par semaine. Aucune évolution possible.
Verdict Struxis : refonte justifiée. Migration vers une solution SaaS métier après benchmark de 6 solutions. Budget : 95K€. Délai : 8 mois. Le gain : un outil qui ne plante plus, maintenable par l’éditeur.
La méthode Struxis : 4 étapes pour décider
01
Auditer
Cartographie fonctionnelle + technique. Score de reprenabilité /10. Coût de maintenance actuel.
02
Chiffrer
Estimation budget par scénario : évolution ciblée vs. modulaire vs. refonte complète.
03
Comparer
Matrice 10 critères. Chaque scénario est évalué factuellement. Pas d’intuition.
04
Recommander
Recommandation argumentée + plan d’action + budget détaillé. Le client décide en connaissance de cause.
Cette méthode prend 3–5 jours (audit + analyse + restitution) et coûte entre 2 000 et 5 000€. Sur un projet où l’enjeu est de choisir entre 35K€ d’évolution et 150K€ de refonte, le ROI est immédiat.
Les 3 erreurs à ne surtout pas commettre
ERREUR N°1 – DÉCIDER SANS AUDITER
Choisir entre refonte et évolution sans avoir audité le code, c’est comme choisir entre rénovation et démolition sans avoir inspecté
ERREUR N°2 – DEMANDER L’AVIS DU PRESTATAIRE QUI VA RÉALISER
Demander à un prestataire de développement s’il faut refaire ou évoluer, c’est demander au garagiste s’il faut changer la voiture. La réponse est biaisée structurellement : une refonte = 6–18 mois de facturation. Une évolution = 2–3 mois. L’avis doit venir d’un tiers neutre.
ERREUR N°3 – SOUS-ESTIMER LA MIGRATION DE DONNÉES
Si la refonte est choisie, le risque n°1 est la migration de données. Des années de données métier dans un schéma qui ne correspond pas au nouveau. Des doublons, des incohérences, des formats différents. C’est souvent le poste le plus sous-budgété et celui qui fait déraper le planning.
La bonne décision, c’est celle qui repose sur des données
Refonte ou évolution ? La réponse n’est ni l’une ni l’autre a priori. C’est celle que l’audit révèle. Celle que les chiffres soutiennent. Celle que la matrice de décision recommande.
Le rôle de Struxis n’est pas de pousser un scénario plutôt qu’un autre. C’est de donner au décideur les données dont il a besoin pour trancher sereinement. Et si le verdict est « ne faites rien pour l’instant », c’est parfois la meilleure recommandation.
« La pire décision en projet IT, ce n’est pas de choisir la mauvaise option. C’est de choisir sans les données pour décider. »
Refonte ou évolution ? La réponse est dans l’audit.
Struxis propose un diagnostic flash (1-2 jours, 700-1 500€) incluant un score de reprenabilité, une analyse coût/bénéfice et une recommandation argumentée.
