L'évolution des techniques étant de plus en plus rapide, il faut être désormais très sportif pour rester compatible avec quelque chose qui a été acheté ou écrit il y a plus de quatre ans. Le plus souvent, cela se solde par un rachat de mises à jour du progiciel ou une coûteuse réécriture dans les nouvelles technologies. Et la situation peut empirer lorsque le choix des architecture s'avère être mauvais. Qui n'a pas connu un seul budget informatique qui n'a pas explosé par rapport au devis initial ? Un projet dont le budget ne fait que dérapé est un projet bien maîtrisé...
Après analyse, cette phase est plutôt vu comme une contrainte de mise à jour, un ticket régulier à payer, plus qu'une nécessité. Certes, le client-serveur apporte plus de confort aux utilisateurs que le système centralisé muni de terminaux passif ; certes l'Intranet permet un périmètre de consultation plus vaste qu'un applicatif équivalent écrit en client-serveur pour des postes Windows. Mais à part ces conforts, ces modernités de technologies, ces modes, est-ce que cette révolution chronique imposée en vaut fonctionnellement la chandelle ? Est-ce que les lois ou les concepts à gérer évoluent tant que cela ? Est-ce que les économies d'exploitation tant promises sont au rendez-vous ?
La réponse est non. La majorité de l'existant devrait être récupérable.
On nous a parlé de l'objet qui permet d'architecturé les applicatifs de la sorte que certaines parties soient récupérables quand d'autres sont changées voire abandonnées. Mais le concept objet ne résout pas tous les problèmes, d'autant plus que cette modélisation ne convient pas à toutes les situations.
Que nous apporte l'objet lorsqu'on est contraint de migrer ses applicatifs de Windows 98 à Windows 2000 ? De Oracle 8.0 à Oracle 9.1 ? Pire encore, de Unix SCO à Windows 2000 ou de Unix vers AS 400 ?
En fait le dilemme du choix de la solution pour le nouvel applicatif n'en est pas un. Il s'agit plutôt d'une angoisse : tôt ou tard, le nouvel applicatif passera lui aussi à la poubelle et il faudra remettre la main à la poche, quand bien même il serait fonctionnellement des plus satisfaisants.
La question initiale devient : quel est le système à mettre en oeuvre pour qu'il soit mis à la poubelle le plus tard possible parce que cela coûte cher de le réactualiser ?