Réparer plutôt que remplacer – pourquoi pas aussi pour les logiciels ?

Imaginez que votre entreprise possède une camionnette de livraison. Elle a dix ans, quelques bosses et des sièges usés. Pourtant, elle fonctionne de manière fiable, elle est amortie depuis longtemps et remplit exactement les tâches pour lesquelles elle a été achetée.
Un nouveau modèle offrirait une technologie plus moderne et des fonctions supplémentaires. Mais l'entreprise en a-t-elle réellement besoin ? Il serait peut-être plus économique de continuer à entretenir le véhicule, de remplacer les pièces usées et de l'utiliser encore quelques années.
Pourquoi ce raisonnement serait-il fondamentalement différent pour les logiciels ?

Réparer (ou moderniser) plutôt que jeter – l'UE montre la voie

L'Union européenne a fait de la réparabilité des produits un objectif juridique. La directive (UE) 2024/1799 du 13 juin 2024, dite « droit à la réparation », impose aux fabricants de certains biens de proposer des réparations même en dehors de la période de garantie légale. Les États membres devaient transposer cette directive au plus tard le 31 juillet 2026.1
Le règlement (UE) 2024/1781 relatif à l'écoconception pour des produits durables mentionne, à l'article 5, paragraphe 1, points d) à f), la possibilité de mise à niveau, la réparabilité ainsi que l'entretien et la remise en état. Le paragraphe 2 tient même compte de l'obsolescence prématurée des produits, par exemple lorsqu'un logiciel cesse de fonctionner après une mise à jour du système d'exploitation.2
Ces dispositions concernent certains biens physiques et n'instaurent aucune obligation générale de réparation des logiciels d'entreprise. Le principe peut néanmoins être transposé : pourquoi remplacer quelque chose tant qu'il remplit sa fonction et peut continuer à être exploité de manière économique ?

Un logiciel éprouvé n'est pas nécessairement un logiciel obsolète

De nombreuses entreprises utilisent des applications développées il y a vingt ou trente ans. Depuis, des extensions et des interfaces y ont été ajoutées. L'interface utilisateur et le langage de programmation ne sont peut-être plus modernes. Pourtant, l'application traite les commandes, gère les stocks ou soutient la production. Surtout, elle connaît les particularités de l'entreprise : expériences, exceptions et règles métier qui, bien souvent, ne sont plus intégralement documentées nulle part. Son remplacement peut donc avoir des répercussions profondes sur les processus métier.

Quels sont les arguments en faveur de la poursuite du développement ?

Les logiciels existants ont fait leurs preuves en production. Les collaborateurs connaissent les procédures, les données et les interfaces sont en place, et de nombreuses erreurs ont été corrigées depuis longtemps.
Une extension ciblée peut demander nettement moins d'efforts que l'acquisition d'un nouveau système. Il suffit peut-être d'un rapport, d'une interface, d'un nouveau calcul de prix ou de l'automatisation d'une étape de travail.
Pourquoi remplacer toute l'application pour cela ?
Un langage de programmation ancien n'est pas non plus automatiquement inadapté. Ce qui compte, c'est la maintenabilité, la disponibilité des outils de développement et une plateforme bénéficiant d'un support fiable.
Une modernisation progressive permet en outre de répartir les investissements sur plusieurs années plutôt que de financer un vaste projet de remplacement.
Où se situent les limites ?
Il ne faut toutefois pas conserver les logiciels existants à n'importe quel prix. De nombreuses extensions peuvent rendre les structures des programmes difficiles à comprendre ; certaines dépendances sont inconnues et la documentation fait défaut. Même de petites modifications peuvent alors avoir des conséquences inattendues : c'est ce qu'on appelle la dette technique.
Des composants obsolètes, l'absence de mises à jour de sécurité ou des systèmes d'exploitation qui ne sont plus pris en charge peuvent présenter des risques importants. Si chaque nouvelle exigence nécessite des interventions complexes, poursuivre le développement peut, à long terme, coûter plus cher qu'un remplacement.
Le critère déterminant n'est donc pas l'âge de l'application, mais sa viabilité technique et économique à long terme.

Combien coûte réellement un nouveau logiciel ?

Souvent, les coûts d'une adaptation sont uniquement comparés au prix d'achat ou de licence d'un nouveau logiciel. Cette comparaison est trop limitée.
Une nouvelle acquisition implique l'installation, la configuration, la migration des données, la création ou l'adaptation d'interfaces et la prise en compte des processus métier spécifiques. S'y ajoutent la formation, les tests, la gestion de projet, le conseil et, éventuellement, une exploitation en parallèle.
Un exemple purement hypothétique sur cinq ans permet de l'illustrer :
Logiciel existant : CHF 40'000 de frais uniques pour la révision et les extensions, auxquels s'ajoutent CHF 12'000 par an pour la maintenance et l'exploitation.
Coût total sur cinq ans : CHF 100'000.
Nouveau logiciel : CHF 110'000 pour l'acquisition et la mise en service, CHF 55'000 pour la migration et les adaptations, CHF 15'000 pour la formation, ainsi que CHF 18'000 par an pour la maintenance et l'exploitation.
Coût total sur cinq ans : CHF 270'000.
Ces montants ne sont pas des prix du marché ; le rapport peut être différent selon la situation initiale. Des coûts de maintenance élevés ou des rénovations fondamentales peuvent également renchérir la solution existante.
Il est donc d'autant plus important d'établir une analyse économique sur plusieurs années, tenant compte de fonctions comparables, des risques et des coûts totaux. Et même si le nouveau logiciel offre davantage de possibilités, quel bénéfice concret l'entreprise en retire-t-elle ?

Le temps, c'est aussi de l'argent

Un changement de système peut durer de nombreux mois. Les services concernés doivent définir les exigences, examiner les procédures, tester les fonctions et documenter les erreurs. Les collaborateurs sont alors partiellement détournés de leurs activités quotidiennes. Dans les projets de longue durée, les exigences peuvent de nouveau évoluer pendant la mise en œuvre.
Des extensions ciblées peuvent souvent être réalisées plus rapidement, sans transformer l'ensemble de l'environnement informatique. Elles doivent elles aussi être développées, testées et documentées avec soin. Il ne faut toutefois pas sous-estimer les efforts nécessaires à une migration complète.

Quand l'acquisition d'un nouveau logiciel est-elle judicieuse ?

De nouvelles obligations légales ou réglementaires peuvent exiger des fonctions qui ne pourraient être réalisées dans le logiciel existant qu'au prix d'efforts disproportionnés, par exemple en matière de protection des données, de sécurité ou de déclarations propres à un secteur d'activité.
Un modèle économique profondément modifié, des sites supplémentaires, l'internationalisation ou une augmentation considérable du périmètre fonctionnel peuvent également dépasser les capacités de l'architecture existante.
L'absence de support technique constitue une autre raison : si des composants indispensables ne sont plus disponibles ou si la plateforme ne peut plus être exploitée en toute sécurité, il faut agir. Mais une modernisation de l'infrastructure ne suffirait-elle pas, plutôt que de remplacer toute l'application ? La situation devient particulièrement délicate lorsque plus personne ne comprend le logiciel.

Quand les connaissances se perdent

Une application fonctionnelle peut devenir un risque lorsque son développeur prend sa retraite, que l'administrateur quitte l'entreprise et que la documentation est lacunaire. Souvent, une seule personne a effectué les modifications pendant des années.
Aux questions concernant certaines fonctions, on répond alors : « Il faut demander à notre administrateur. » (Voir l'article de blog du même nom : Il faut demander à notre administrateur)
Sans ces connaissances, les modifications deviennent risquées : personne ne peut en évaluer les conséquences de manière fiable. La perte de connaissances est toutefois d'abord un problème organisationnel, et pas nécessairement technique.
L'analyse du code source, la documentation des processus critiques et le développement de compétences internes ou externes peuvent rendre à nouveau possible la poursuite du développement. L'élément décisif est l'effort nécessaire pour retrouver ces connaissances.
L'acquisition d'un nouveau logiciel ne résout pas automatiquement ce problème. Lors d'une migration aussi, il faut comprendre les règles métier existantes, faute de quoi des fonctions importantes ou des exceptions risquent de disparaître. Un état des lieux est donc utile dans les deux cas.

Analyser d'abord, décider ensuite

Avant tout investissement important dans un logiciel d'entreprise, plusieurs questions doivent être clarifiées :
- L'application existante répond-elle aux exigences actuelles ?
- Quelles fonctions supplémentaires seront réellement nécessaires dans les prochaines années ?
- La base technique peut-elle continuer à être exploitée de manière fiable et sûre ?
- Le code source, la documentation et les compétences correspondantes sont-ils disponibles ?
Et surtout : comment les coûts totaux et les risques de la poursuite du développement se comparent-ils à ceux d'un remplacement sur une période réaliste ?
Au-delà des coûts, il faut aussi considérer les conséquences pour les collaborateurs, les clients et les processus métier. Une solution intermédiaire est souvent judicieuse : conserver les fonctions centrales éprouvées tout en modernisant ou en remplaçant certains composants.

Conclusion : tout ce qui est ancien ne doit pas forcément disparaître

Revenons à la camionnette : tant qu'elle fonctionne de manière fiable, qu'elle est sûre et qu'elle remplit économiquement sa mission, il n'est pas nécessaire de la remplacer. Des coûts de modernisation durablement élevés peuvent toutefois justifier l'achat d'un nouveau véhicule.
Il en va de même pour les logiciels. La réparabilité encouragée par l'UE invite à réfléchir : un logiciel n'est pas un produit jetable, mais le résultat d'investissements, d'expériences, de processus métier et, souvent, de décennies de connaissances. Un nouveau logiciel peut présenter des avantages. Mais la modernité ne constitue pas, à elle seule, un bénéfice économique.
Avant tout grand projet de remplacement, il convient donc de se poser la question suivante :
« Que ne pouvons-nous précisément plus réaliser avec notre logiciel existant – et son remplacement complet est-il vraiment le meilleur moyen d'y parvenir ? »

Cet article est une traduction de l'original allemand réalisée à l'aide de l'intelligence artificielle

Article original : Reparieren statt ersetzen – warum eigentlich nicht auch bei Software?