- septembre 1, 2025
Les projets de refonte technique : des projets sans valeur... vraiment ?
Derrière un projet de refonte technique, souvent perçu comme « sans valeur », se cachent des enjeux stratégiques : sécurité, conformité, continuité et même opportunités d’évolution métier. Et si la vraie question n’était pas si vous devez refondre, mais comment donner du sens à cette démarche ?
Cela ne vous aura pas échappé : la durée de vie des solutions IT est de plus en plus courte.
Parmi les nombreuses causes, on peut citer :
– L’émergence rapide de nouvelles technologies,
– La nécessité pour les éditeurs de faire évoluer tout aussi rapidement leurs produits,
– La fragmentation de la stack technique et l’interdépendance croissante des composants qui la compose (logiciels, middlewares, OS, infrastructures),
– L’intégration toujours plus profonde des différentes solutions qui composent le système d’information,
– Et enfin, le rôle stratégique désormais joué par le SI dans la performance et la résilience de l’entreprise.
Nous avons tous déjà entendu l’histoire d’une application qui répond parfaitement aux besoins métiers… mais qui repose sur un système d’exploitation ou un middleware obsolète, devenu incompatible avec les versions actuelles.
Face aux risques générés par cette obsolescence (failles de sécurité, non-conformité réglementaire, indisponibilités, perte des compétences…), il devient urgent d’agir.
Quand (et pourquoi) lancer un projet de refonte technique ?
C’est souvent à ce moment qu’un projet de refonte technique ou de migration devrait voir le jour. Mais comment justifier un projet qui, de prime abord, ne semble rien apporter de plus que l’existant ?
– Comment convaincre les parties prenantes et notamment les métiers de soutenir un projet qui ne changera rien à leur quotidien ?
– Comment mobiliser les équipes IT sur un projet dont l’objectif est d’obtenir… la même solution qu’avant ?
– Comment défendre un budget pour “refaire la même chose” ?
Ces questions sont bien évidemment légitimes.
La criticité, un levier de justification
Tout d’abord, posons ensemble la notion de criticité.
Un livreur a besoin que son camion démarre chaque matin. Sans cela, il ne peut livrer ses clients. Un industriel, lui, investit massivement dans la prévention des pannes pour éviter tout arrêt de production.
Pour l’IT, c’est la même chose : certaines solutions sont vitales à l’entreprise, mais leur criticité est souvent mal comprise ou difficile à communiquer.
Dans cet article, nous définirons la criticité d’une solution IT comme étant l’impact qu’aurait une panne, une cyberattaque ou une non-conformité réglementaire sur l’activité, la performance, les données ou la réputation de l’entreprise. Plus l’impact est fort, plus la criticité est élevée.
Dès lors, un projet de refonte technique d’une solution critique ne peut pas être sans valeur. Encore faut-il savoir l’expliquer.
La cartographie et le BIA comme fondations
Disposer d’une cartographie à jour du SI et des processus métiers devient alors indispensable pour dialoguer avec les métiers, évaluer la criticité et communiquer au sein de l’entreprise sur les enjeux associés.
Cette démarche peut être reliée aux travaux de rédaction du rapport de BIA (Business Impact Analysis) qui permet de définir la criticité métier des applications.
Elle peut également déboucher sur la rédaction d’un PCA (Plan de Continuité d’Activité) et d’un PRA (Plan de Reprise d’Activité). L’occasion de faire d’une pierre deux coups.
Le travail d’identification des solutions critiques peut aussi mettre en évidence des solutions non critiques pour lesquelles la migration sera plus difficile à justifier. Cela peut même conduire à décider du décommissionnement d’une solution obsolète dont la valeur est faible au regard du rapport bénéfices/risques.
Quoiqu’il en soit, seule une vision claire de la place de chaque solution dans le SI et des services rendus à l’entreprise permet de trancher.
Le coût caché des solutions vieillissantes
Si la criticité ne suffit pas à convaincre, l’argument du coût de maintenance est un autre levier puissant.
Plus une solution vieillit, plus ses coûts de support et de maintenance explosent : incidents récurrents, correctifs longs et complexes, évolutions difficiles, rigidité technique, modèles de données obsolètes, insatisfaction croissante des utilisateurs…
Au-delà de l’impact financier direct, ces coûts détournent l’IT de ses enjeux d’innovation et limitent la capacité de l’entreprise à investir dans des projets porteurs de valeur.
L’essentiel de ces dépenses étant lié à la main-d’œuvre, il apparaît incontournable de disposer d’un suivi des temps suffisamment précis pour démontrer le surcoût imputable à l’obsolescence. Une bonne pratique qui ne peut être dans notre cas que bénéfique.
Donner de la valeur à un projet perçu comme sans valeur
Supposons que la criticité ait été démontrée et que le budget soit validé. Comment mobiliser les parties prenantes sur un projet qui n’apporte a priori rien de nouveau ?
En faisant preuve de pédagogie, les enjeux de continuité, de conformité, de sécurité et de coûts deviennent compréhensibles par tous.
Et surtout, pourquoi ne pas profiter de cette refonte pour requestionner les usages et les besoins métiers ?
Sur une solution de 5 ou 10 ans d’âge, il est souvent pertinent de vérifier :
– si la solution est toujours adaptée aux besoins réels,
– si les usages sont vraiment homogènes dans toute l’entreprise,
– si des pratiques de shadow IT (Excel, macros, outils non officiels) ne se sont pas installées.
Un cadrage approfondi est donc toujours bénéfique : non seulement il réduit les risques, mais il donne aussi de la valeur tangible à un projet jugé a priori « sans valeur ».
Les principaux risques d’un projet de refonte
Contrairement aux idées reçues, les projets de refonte ou de migration sont loin d’être des projets simples. Leur nature leur confère une complexité toute particulière : on les pense simple car on maîtrise la solution actuelle. Ou du moins on pense la maîtriser…
1/ Le risque du projet de refonte « iso-fonctionnel »
Une migration « as-is » paraît rassurante mais est rarement réaliste.
Derrière une simple mise à niveau technique se cachent souvent des évolutions fonctionnelles, parfois imposées par de nouveaux composants. Par exemple lorsqu’une version modifie la façon de modéliser les données.
À cela s’ajoute une pression légitime de la gouvernance et des métiers, qui voient dans la refonte une opportunité d’introduire des améliorations fonctionnelles.
Résultat : un projet initialement pensé comme « iso- » glisse progressivement vers un périmètre élargi, accumulant retards, complexité et impasses techniques.
2/ La perte de connaissance métier et fonctionnelle
Sur les solutions anciennes, il est fréquent que les processus métiers ou les modèles de données soient mal documentés… voire plus du tout maîtrisés.
Le risque le plus insidieux n’est pas tant l’absence de documentation que l’illusion de maîtrise : les équipes sont convaincues de bien comprendre les processus, jusqu’au moment où, en fin de projet, les hypothèses de départ s’avèrent fausses.
Bien sûr, il est toujours possible de remettre les processus à plat et de reconstruire la compréhension. Mais plus cette prise de conscience intervient tardivement, plus l’impact sur les coûts et les délais est dévastateur. Dans certains cas, cela peut mettre en péril l’équilibre même du projet.
3/ La complexité des interfaces et du shadow IT
Un projet de refonte ne s’arrête jamais à l’application elle-même : il doit aussi prendre en compte l’écosystème d’interfaces qui la relient aux autres briques du système d’information.
Sans une cartographie précise et à jour, certaines de ces interconnexions risquent de passer sous le radar. Le danger est encore plus grand avec le shadow IT qui a pu s’installer au fil du temps et qui peut rester invisible jusqu’à la bascule en production.
Une analyse technique approfondie est donc indispensable pour identifier tous les points d’adhérence. Elle doit permettre non seulement de sécuriser les interfaces critiques, mais aussi de décommissionner celles qui sont devenues inutiles. C’est une occasion rare de simplifier et d’assainir le système d’information, en réduisant sa dette technique.
Quelle méthode adopter ?
Chaque contexte étant différent, il n’y a pas de recette toute faite pour réaliser ce type de projet.
On identifie toutefois trois grandes approches :
– L’approche big bang : séduisante sur le papier, cette méthode permet un basculement rapide et théoriquement simplifié. Si elle réussit, elle compresse fortement les délais. Mais elle exige une maîtrise quasi parfaite de tous les axes du projet : spécifications, qualité des environnements, exhaustivité des tests, voire phase de double production. Dans un contexte complexe, elle reste l’approche la plus risquée… mais pas impossible, à condition d’une préparation irréprochable.
– L’approche itérative : plus sécurisée, elle consiste à avancer pas à pas en livrant des lots successifs. Elle réduit les risques et facilite l’adhésion des métiers, mais suppose que la solution refondue soit suffisamment modulaire, tant sur le plan technique que fonctionnel. Certains systèmes monolithiques ou fortement couplés la rendent difficilement applicable.
– Le lift and shift : migration technique minimale, suivie d’évolutions fonctionnelles. Cette méthode sépare la problématique de portabilité technique de celle d’évolution métier. Elle peut être pragmatique et limiter les risques initiaux, mais attention au piège de la « refonte iso- » qui peut amener à surestimer la faisabilité des évolutions fonctionnelles avec la conception technique d’origine.
En définitive, la méthode retenue doit refléter le niveau de maturité de l’entreprise, sa capacité à absorber le changement et ses contraintes de délai ou de budget. L’essentiel reste de choisir une approche qui sécurise l’exécution tout en maintenant la valeur et l’adhésion des parties prenantes.
Conclusion : une culture d’amélioration continue
En réalité, les projets de refonte sont ceux qu’on aimerait éviter… mais qu’on ne peut repousser éternellement.
Favoriser une culture d’amélioration continue du patrimoine IT permet d’allonger la durée de vie des solutions, d’embrasser les changements au fur et à mesure, de préserver la cohérence d’ensemble et ainsi de limiter les refontes trop brutales.
Cette culture d’amélioration continue doit reposer sur une vision IT à moyen ou long terme complètement alignée sur la stratégie d’entreprise.
L’enjeu n’est pas seulement de moderniser techniquement, mais d’anticiper autant que possibles les besoins et les contraintes de demain.
Au fond, une refonte IT réussie est avant tout une démarche fonctionnelle et organisationnelle, soutenue par la technologie comme levier.
A propos de l'auteur
Willy Rusillon | Fondateur et Dirigeant de la société exonance