> Tech > Cas concrets de modernisation d’applications

Cas concrets de modernisation d’applications

Tech - Par iTPro.fr - Publié le 24 juin 2010
email

on Soule
Trois expériences concrètes démontrent qu'il est parfois préférable de rajeunir un code RPG existant que de le remplacer. L'ambiance était tendue, presque sinistre, quand le directeur informatique annonca la nouvelle. Le projet de remplacement de l'application RPG AS/400 par un nouveau système client/serveur Windows NT avait coûté plusieurs dizaines de millions de francs, pris un an et demi de retard, et semblait voué à  l'échec. Le moment était venu d'arrêter l'acharnement thérapeutique : continuer était trop risqué.
Cette mauvaise nouvelle entraînait bien sûr une question : que faire à  présent ? Comme consultant appelé pour recoller les morceaux, c'est à  moi que l'on posa la question.

Il s'agissait de remplacer une application de traitement transactionnel centralisée avec peu d'accès à  distance. L'information parvenait sous forme imprimée aux agences régionales pour être introduite dans le système AS/400 à  l'aide de terminaux 5250. Le nouveau système avait pour mission de distribuer les applications NT à  des centaines de sites.
Les utilisateurs finaux avaient beaucoup participé à  la conception d'une nouvelle interface Windows (implémentée en Visual Basic) et les chefs de projet souhaitaient que l'on puisse utiliser cette nouvelle interface.

Notre solution : conserver l'application AS/400 en la modernisant. Le projet NT prévoyait un serveur à  chaque site, mais nous avons écarté cette hypothèse trop chère et difficile à  gérer. Nous avons préféré utiliser l'AS/400 existant comme système central, relié aux sites par Internet ou par une liaison fixe, selon la taille et le volume du trafic de chaque site.
Pour faciliter la mise en place, limiter les coûts d'assistance, et offrir l'interface graphique, nous avons opté pour un outil frontal générateur d'applets Java. Nous avons utilisé les images déjà  réalisées en VB, comme modèle pour créer un nouveau frontal graphique en Java, pratiquement identique aux panneaux VB que les utilisateurs souhaitaient. Dupliquer le comportement non modal, orienté événements, de l'application VB, a été un peu plus difficile, mais nous y sommes parvenus en modifiant les programmes RPG de manière à  traiter et acheminer quelques nouvelles requêtes. Comme le frontal graphique fonctionne dans Windows ou dans un navigateur, le déploiement a été facile, quel que soit le type de connexion entre un site et l'AS/400.

Du point de vue gestion, la modernisation de l'application existante présentait plusieurs avantages, dont le plus important, dans le cas présent, était le risque minimum. Le projet NT était à  haut risque, avait utilisé la plus grande partie du temps et de l'argent alloués, et avait échoué. La direction ne voulait surtout pas entendre parler d'une autre proposition scabreuse.
Précisément, le choix de modernisation de l'application était rassurant puisqu'il permettait d'utiliser l'existant en matériel, logiciel et compétences. Il était facile d'estimer les coûts de création et de déploiement de l'application, puisqu'ils étaient fondés sur des technologies et des compétences confirmées. Et notre client dépendait de peu de consultants externes pour pallier des compétences maison absentes.
Résultat : un nouveau système en quelques mois, au lieu de quelques années, pour quelques milliers de dollars, au lieu de quelques millions.

Cas concrets de modernisation d’applications

L’état-major (au sens littéral du terme car c’étaient tous des généraux en retraite)
de notre client (une association à  but non lucratif ayant des agences dans le
monde entier) avait convoqué son équipe informatique et quelques consultants en
session extraordinaire.
Pourquoi la page Web de l’association était-elle statique plutôt qu’interactive
?
Pourquoi les agences utilisaient-elles encore une application DOS sur leurs PC
?
Pourquoi l’association n’était-elle pas une organisation du 21e siècle conformément
au projet de son leader ?
Le budget informatique, les promotions dans le service informatique interne et,
bien entendu, les postes informatiques de l’année suivante étaient en jeu. Les
généraux ne se contentaient pas d’un « Affirmatif !  » franc et massif ; ils voulaient
des réponses immédiates !

L’application sous DOS, écrite en Dbase gérant l’inscription des membres et l’édition
d’étiquettes, était difficile à  supporter et à  maintenir. Certaines agences utilisaient
des communications asynchrones pour se connecter à  l’AS/400 de l’association pour
effectuer des téléchargements et des mises à  jour alors que d’autres recevaient
par courrier les mises à  jour sous forme de disquettes ou de bandes.
Le personnel changeait souvent, entraînant des problèmes de sécurité, une grande
confusion et de nombreux appels à  la hot-line de l’association. Les utilisateurs
n’étaient pas très satisfaits de l’application en raison de son interface et des
difficultés de communication rencontrées avec l’AS/400 central. En outre, les
agences et l’association centrale voulaient que les membres puissent, via Internet,
renouveler leur adhésion, mettre à  jour leur adresse, s’inscrire à  des événements,
télécharger des documents et participer à  des groupes de discussion.

Téléchargez gratuitement cette ressource

Les 7 étapes d’un projet de dématérialisation RH

Les 7 étapes d’un projet de dématérialisation RH

Dans ce livre blanc, nous vous donnons les clés pour concevoir votre projet de dématérialisation RH. Vous découvrirez chacune des étapes qui vous permettront d’apporter de nouveaux services aux collaborateurs, de vous adapter aux nouvelles pratiques et de renforcer la marque employeur.

Tech - Par iTPro.fr - Publié le 24 juin 2010