La durée de vie de votre logiciel est tributaire de facteurs internes (conception, utilisation, capacité à avoir anticipé les besoins, etc.) comme externes (technologies, etc.). Difficile de donner une date précise de ‘fin de vie’ de votre application ou de votre logiciel de gestion. Alors quels signes d’ obsolescence logicielle guetter avant de changer ? Quand faut-il se poser la question d’une refonte ou évolution ?

Voici 5 points à surveiller.

1) La technologie sur laquelle est développée votre application est obsolète

La problématique de l’obsolescence logicielle survient lorsque votre application repose sur une technologie qui ne suit pas les évolutions, involontairement ou volontairement. L’éditeur peut, en effet, décider de ne plus sortir de nouvelles mises à jour de sa technologie et ce pour diverses raisons.

Cela peut devenir rapidement problématique car votre application, développée à un instant T sur une certaine version de la technologie utilisée, risque de prendre du retard si les mises à jour ne sont plus installées. Risque d’autant plus grand si votre application utilise des périphériques qui continueraient, eux, de bénéficier de nouvelles mises à jour ; elle pourrait finir par ne plus les supporter.

Vous pouvez croiser les doigts pour que votre application tienne encore quelque temps ; ce qui pourra être le cas si vous souhaitez la laisser telle quelle. Cependant, si vous avez des projets d’évolution, mieux vaut prendre la décision de la faire évoluer sur une technologie plus pérenne.

2) La maintenance devient de plus en plus couteuse

La maintenance peut aussi être source d’obsolescence logicielle. En effet, plusieurs facteurs viennent impacter directement les coûts de maintenance. Cela peut-être les développements et évolutions consécutifs qui rendent laborieux toute opération de maintenance, la technologie utilisée qui n’intéresse plus les développeurs (les experts pouvant maintenir votre application sont rares et ceux que vous trouvez sont chers) ou encore les bugs qui s’accumulent.

Dans tous les cas, mieux vaut savoir concrètement l’investissement que nécessite la maintenance et se demander s’il ne serait pas préférable de l’investir ailleurs.

3) L’application ne suit pas le marché

Que font vos concurrents ? Pour un logiciel comme pour tout produit, Il est crucial de suivre les tendances technologiques de votre marché pour éviter l’obsolescence logicielle et rester compétitif. En d’autres termes, si vous êtes encore en client lourd alors que vos principaux concurrents sont passés en SaaS depuis l’année dernière, vous êtes surement en retard. Si vous souhaitez ne pas perdre de part de marché, il est sans doute temps de repenser votre application.

Que veulent vos clients ? Outre les avancées de vos concurrents, veillez bien à répondre aux attentes de vos utilisateurs. Si votre application ne les intéresse plus, ils ne l’utiliseront plus. Attention, vous risquez de mécontenter vos utilisateurs s’ils attendent des fonctionnalités que vous ne proposez pas, mais également si vos évolutions vont à l’encontre de leur utilisation. Dernier exemple en date, celui de SnapChat qui est revenu sur la refonte de son application après avoir fortement déçu des usagers et reçu une pétition signée par plus d’un million de personnes.

4) Votre application n’a pas été pensée pour être évolutive

Que ce soit :

– à cause d’un mauvais choix

– parce que la situation ou les besoins ont évolués et votre choix bon à un certain moment ne l’est plus

– ou parce qu’elle n’a pas été pensée pour évoluer,

l’architecture de votre application peut vous bloquer.

Or, si ce sujet n’a pas été pris en compte en amont vous risquez fort de vous retrouver face à une application figée et vous devrez partir vers une autre architecture pour continuer d’évoluer ou pour évite.

Il est du ressort de l’architecte d’être visionnaire et faciliter l’upgrade de votre logiciel. D’ailleurs, de plus en plus, les architectes ne veulent plus se limiter à une plateforme. L’architecture de l’application est éclatée pour ne pas tout focaliser sur une interface et ne pas avoir de problèmes de redéploiement par la suite.

Vous risquez de vous trouver face à un problème similaire si votre application est développée dès son origine sur des technologies vieillissantes ou sur le point d’être « délaissées ». Là encore, si l’application n’a pas vocation à évoluer et qu’elle fonctionne bien, pas de raison d’envisager une refonte ; la question se pose si vous êtes un peu plus ambitieux et envisagez des évolutions futures.
Il est en effet important de surveiller les technologies sur lesquelles est développée votre application pour éviter l’obsolescence logicielle et être capable de la faire évoluer.

5) Le support des technologies est arrêté

Lorsque la technologie devient obsolète, les éditeurs décident à un moment d’arrêter le support. C’est un signal fort lancé à ceux qui utilisent la techno, un signe qu’il faut évoluer pour éviter l’obsolescence logicielle. Car cela devient problématique pour les développeurs qui sont amenés dans leur utilisation de la technologie à communiquer au support pour deux raisons principales :

– Bugs

– Problèmes de compatibilités à des nouvelles contraintes comme les nouvelles versions de navigateurs web ou de systèmes d’exploitation – Windows, OS, etc.

Si plus aucun moyen n’est donné à la résolution de ces problèmes techniques, on risque de se trouver gêné dans les développements futurs.

Dans la grande majorité des cas, l’arrêt d’un support est annoncé longtemps en avance pour permettre aux utilisateurs de se retourner. Ainsi, tous les ans, Microsoft publie un calendrier des produits et technologies en fin de support.

Puisque l’exception confirme la règle, on peut citer l’exemple de Silverlight une technologie naissante et annoncée pendant plusieurs années par Microsoft ; cependant, brusquement et peu de temps après, Microsoft s’est retiré, au profit de l’HTML5, laissant les utilisateurs perplexes…

La refonte ou le changement de votre logiciel est, au même titre que le développement de logiciel sur mesure, un investissement qu’il s’agit de considérer avant d’entreprendre. Si parfois il est nécessaire, il n’est pas négatif. En effet, c’est aussi l’occasion de nettoyer ou enrichir une application ou encore de reformuler ses besoins qui évoluent. Dans un projet de développement informatique, on estime que près de la moitié des fonctionnalités souhaitées ne sont jamais utilisées ( J.Johnson, Keynote speech, XP2002 (Sardaigne, Italie)). Utiliser la méthodologie Agile dans ses projets permet de se concentrer d’abord sur les fonctionnalités les plus importantes et limiter ce pourcentage.

Un audit de code ou applicatif peut vous aider à y voir plus clair et vous aider à déterminer si votre logiciel peut évoluer ou s’il sera nécessaire de tout redémarrer. D’ailleurs, la refonte n’est pas forcément complète et peut, selon le besoin, se limiter à un module.

Merci à Naïla Zeroug et Sabrina Pereira avec qui l’article a été écrit. : )