La modernisation ou le remplacement d'un logiciel hérité est rarement une question purement technique. La valeur commerciale, les ressources disponibles et l'état réel du système sont également des facteurs déterminants. De nombreuses entreprises choisissent, par habitude, de continuer à utiliser l'ancien système ou, par impatience, d'opter pour quelque chose de complètement nouveau, sans examiner sérieusement les solutions intermédiaires.
Quiconque souhaite moderniser un logiciel hérité dispose de quatre étapes intermédiaires entre la poursuite de l'exploitation et la refonte complète. Le Modèle 6R les classe comme suit : Retire, Rehost, Revise, Refactor, Rebuild, Replace. Quatre facteurs déterminent l'étape appropriée : l'état technique, la valeur commerciale, les ressources disponibles et l'objectif stratégique. Un système stable mais difficile à maintenir nécessite généralement un Refactor, et non un Replace.
Moderniser les logiciels hérités selon le modèle 6R
Le modèle 6R distingue six approches pour les systèmes existants, allant du changement le plus mineur au plus important (ARDURA Consulting, 06/2025).
| Option | Que se passe-t-il ? | Convient si |
|---|---|---|
| Retire | Le système sera mis hors service, sans remplacement | il n'existe plus de valeur commerciale mesurable |
| Rehost | transférer tel quel vers la nouvelle infrastructure | C'est seulement la plateforme qui est obsolète, pas le code |
| Revise | de légères adaptations techniques sans modification de l'architecture | Ce sont certaines faiblesses qui gênent, pas l'ensemble |
| Refactor | Refonte structurelle du code, la fonctionnalité reste inchangée | le code est stable, mais difficile à maintenir |
| Rebuild | Nouveau développement basé sur la logique existante | l'architecture n'est plus évolutive |
| Replace | Remplacement par une solution entièrement nouvelle | La technologie et la logique métier sont toutes deux au bout du rouleau |
L'arbre de décision en sept questions
L'ordre des questions détermine la rapidité avec laquelle une option peut être écartée.
- Le système apporte-t-il encore une valeur commerciale mesurable ? Non, alors « Retire ». Cette question se résout souvent plus vite qu'on ne le pense, surtout quand personne ne connaît vraiment les chiffres d'utilisation.
- La technologie sous-jacente est-elle complètement obsolète ? Si le fabricant n'existe plus, qu'il n'y a plus d'assistance et qu'il n'y a pas non plus de communauté de développeurs, il n'y a d'autre solution que de reconstruire ou de remplacer le système.
- L'architecture est-elle extensible par principe ? Si ce n'est pas le cas, même si le code fonctionne, cela limite toutes les options de modernisation, à l'exception de la refonte ou du remplacement.
- Le code est-il techniquement stable, mais difficile à maintenir ? C'est précisément là que Refactor trouve toute son utilité (ARDURA, 06/2025). La valeur commerciale est bien présente ; le problème technique réside dans la qualité du code, et non dans l'architecture.
- Une nouvelle infrastructure suffit-elle, sans modifier le code ? Dans ce cas, le réhébergement est l'option la plus rapide et la moins chère.
- Y a-t-il uniquement quelques petits défauts techniques ? Dans ce cas, Revise suffit, sans intervention majeure.
- N'est-il pas possible de répondre clairement à l'une des questions 1 à 6 ? Il faut alors procéder à une analyse technique plus approfondie avant de prendre une décision. Les décisions hâtives à ce stade sont la cause la plus fréquente de l'échec ultérieur des projets de modernisation.
Ce qui détermine réellement la décision
Selon ARDURA, le choix de la bonne option dépend de quatre facteurs : l'état technique, la valeur commerciale, les ressources disponibles et les objectifs stratégiques (ARDURA, 06/2025). Un système présentant une valeur commerciale élevée et un mauvais état technique justifie un investissement. Un système dont la valeur commerciale est faible justifie rarement un tel investissement, quel que soit son état technique.
Il convient ici d'adopter une position claire. Dans la pratique, ceux qui souhaitent moderniser des logiciels hérités ont souvent tendance à ignorer le refactoring, car le « remplacement » semble être la solution la plus radicale : un nouveau système débarrassé de l'ancien fardeau. C'est une erreur de raisonnement lorsque la valeur commerciale de l'ancien système est élevée et que le code est simplement difficile à maintenir, mais techniquement stable. Dans ce cas, une refonte (Rebuild) ou un remplacement (Replace) coûte nettement plus de temps et d’argent que ne le justifie le problème réel, à savoir la maintenabilité.
Évaluer votre ancien système à l'aide de ces sept questionsNous examinons l'architecture, les dépendances et les chiffres d'utilisation, puis nous vous indiquons laquelle des six options reste valable.
Modernisation sans interruption de l'exploitation
Les opérations de « rehost » et de « revise » s'effectuent généralement en parallèle des activités quotidiennes. En revanche, les opérations de « rebuild » et de « replace » nécessitent presque toujours une phase de transition avec un fonctionnement en parallèle, durant laquelle l'ancien et le nouveau système fonctionnent simultanément.
Un détail du contrat est souvent négligé dans ce contexte. Quiconque remplace un ancien système devrait vérifier dans quelle mesure le nouveau prestataire ou partenaire de développement crée un nouveau « lock-in ». Nous décrivons les clauses de protection les plus importantes à cet égard dans le Article sur la manière d'éviter la dépendance vis-à-vis d'un fournisseur. La répartition des coûts sur cinq ans figure dans le article sur les coûts cachés.
Foire aux questions
À quoi reconnaît-on la défaillance technologique totale d'un système ?
Les signes caractéristiques sont notamment un fabricant qui ne propose plus d'assistance, un langage de programmation ou une plateforme pour lesquels il est difficile de trouver des développeurs, et une architecture qui ne permet plus d'ajouter de nouvelles fonctionnalités sans compromettre celles qui existent déjà. Si plusieurs de ces critères sont remplis, il n’y a pratiquement pas d’autre solution que la refonte ou le remplacement (ARDURA, 06/2025).
La modernisation est-elle possible sans interruption de l'activité ?
C'est le cas pour le « rehost » et le « revise », car la mise en place de l'infrastructure ou de petites modifications peut généralement se faire sans interruption. En revanche, pour le « rebuild » et le « replace », un fonctionnement en parallèle pendant des semaines, voire des mois, est la norme, ce qui implique un investissement en temps et en ressources pour les deux systèmes simultanément.
Combien coûte la simple poursuite de l'exploitation d'un système hérité ?
Les coûts de l'inaction sont rarement visibles immédiatement, mais ils augmentent d'année en année. Parmi ceux-ci figurent des coûts de maintenance croissants, un risque de sécurité grandissant et une perte de capacité d'adaptation face aux nouvelles exigences métier. Avant de moderniser leurs logiciels hérités, les entreprises ont tout intérêt à procéder à une évaluation de leur propre système, car les chiffres généraux ne sont guère utiles dans ce domaine.
La prochaine étape
torck évalue les anciens systèmes selon le modèle 6R avant de formuler une recommandation en faveur d'une refonte (Rebuild), d'une réorganisation (Refactor) ou d'un remplacement (Replace). Nos équipes de développement à Maxhütte-Haidhof, Vienne et Rabat connaissent bien les écueils grâce à leurs propres projets de modernisation dans l'industrie et le commerce. Le partenaire contractuel pour ce projet est la société allemande torck GmbH. Dans le Premier entretien Passons ensemble en revue votre système.
German 
English 
French