L’avenir des écrans en mode caractère

L’argument majeur des groupes de pression marketing anti écran en mode
caractères consiste généralement à  comparer les applicatifs mainframe au DOS
des années 80 sur PC. « Les écrans passifs, c’est comme si, disent les détracteurs,
on continuait à  utiliser de vieilles versions du traitement de texte Word
datant du DOS des années 80 avec un système d’exploitation moderne comme
Windows XP! Bien sûr que le traitement de texte datant du DOS parviendrait
à  couvrir toutes les fonctionnalités de base demandées par les utilisateurs ! Estce
une raison pour priver les utilisateurs des interfaces intuitives graphiques ? »
En fait, les écrans passifs des applications mainframe back office gèrent par
définition les données critiques de l’entreprise. Ce qui est recherché dans ce
type d’application mainframe est avant tout une grande fiabilité. Par définition,
les écrans passifs sont des écrans esclaves. Nous savons maintenant depuis
l’échec de l’architecture client/serveur des années 90, qu’il est préférable
d’avoir des écrans esclaves que de devenir esclaves des écrans.
Les programmes COBOL et RPG avec les écrans en mode caractères peuvent
être comparés au niveau des exigences de fiabilité et de sécurité au marché
de l’automobile. Dans les années 60, les voitures avaient 4 roues, un moteur
essence et pouvaient transporter 5 personnes à  90 km/h sur les routes
départementales. Les automobiles d’aujourd’hui aussi. L’évolution technologique
a permis d’accroître la fiabilité de la mécanique et de la sécurité en général.
Une voiture actuelle consomme
moins d’essence et pollue moins. Dans
les années 60 il n’y avait pas d’Air Bag, pas
de ceintures de sécurité, pas de freins
ABS. Aujourd’hui, les pneus ne risquent
plus d’exploser à  pleine vitesse et le réseau
autoroutier est beaucoup plus important.
L’entretien des voitures est maintenant
réduit. De la même manière un
écran passif d’un S/38 des années 80 ressemble
à  s’y méprendre à  un écran esclave
actuel. Cependant, les progrès techniques
internes accomplis au niveau de la puissance, de la sécurité et de la
fiabilité ont été considérables, surtout depuis l’avènement des processeurs
RISC POWER 5.
En fait, il y a les produits qui évoluent au gré des campagnes marketing et
les produits où les contraintes de sécurité et de fiabilité exigent des évolutions qualitatives de structure. La sécurité
d’un passager est importante, la préservation
des données vitales de l’entreprise
aussi. Par exemple, un produit
automobile ou un i5 ne peuvent pas
être comparés au produit téléphone
portable où les nouvelles technologies
se caractérisent par les texto, le téléchargement
de sonneries, les appareils
photos numériques incorporés etc… à 
grand renfort de campagnes marketing.
On ne joue pas de la sorte avec les
données vitales d’une entreprise car sa
vie en dépend.

Pour en revenir à  la modernisation
des écrans en mode caractères, on aurait
pu croire que l’échec du client/serveur
lourd des années 90 allait un peu
refroidir les ardeurs des détracteurs
des écrans esclaves. Apparemment, on
ne renonce pas aussi facilement à  un
gâteau mondial de 5000 milliards de
dollars. Les mêmes groupes de pressions
des années 90 s’accrochent et reviennent
encore à  la charge, mais cette
fois avec le client léger web. Cependant,
par rapport aux années 90, les
ambitions se sont considérablement
réduites. Comme dit le proverbe
« faute de grives on mange des
merles ». Tous ces consultants reviennent
vers nous avec sous le bras des
scénarios qui paraissent bien huilés.
Dans un premier temps, il nous est
proposé de webiser toutes les
« vieilles » interfaces 3270 ou 5250 en
HTML/JAVA et dans un second temps
d’écrire les nouvelles applications Web
en JAVA basées sur J2EE afin d’assurer
une certaine continuité des anciennes
applications avec les nouvelles. Le vrai
progrès par rapport au client/serveur
des années 90 étant que l’on n’est plus
obligé de réécrire tout de suite l’existant.
Merci bien ! Cependant, ce scénario
soulève de grandes interrogations.
Naturellement, personne ne nie les
avancées web : les sites de présentation,
les boutiques en ligne, la webisation
ciblée de certaines applications
commerciales pour remplacer le
client/serveur lourd etc… Tout le
monde reconnaît les vertus des interfaces
Windows pour analyser les données
critiques transférées sur un serveur
dédié. Le problème posé est tout
autre : peut-on généraliser les applications
Web basées sur JEE en Java à  l’informatique
back office mainframe afin
de gérer les données critiques de l’entreprise
?
Le flot HTML/Java nécessite au minimum
10 fois plus de bande passante
que le flot 5250. Nous savons que pour l’informatique embarquée dans les lieux de stockage et de fabrication,
la présentation graphique web n’apporte aucun
avantage. Nous constatons que tous les grands noms de la
distribution en Europe, en Asie et aux US utilisent tous des
écrans en mode caractères pour la logistique. Peut on imaginer
un seul instant que ces grosses sociétés vont prendre le
risque de se trouver confrontées un jour ne serait-ce qu’ aux
problèmes posés par les virus PC qui bloquent la production
et à  une bande passante détériorée de 10 fois uniquement
pour que les salariés puissent bénéficier d’écrans plus sexy ?
Comme le disait un manager d’une grande société à  qui on
proposait une telle solution : « Nous sommes là  pour travailler.
Nous ne sommes pas aux Folies Bergères. »

Nous pouvons dire que l’informatique de gestion se résume
à  deux structures fondamentales : des listes ou sous-fichiers
pour rechercher l’information et à  des formulaires
pour renseigner l’information. Un programme Java ne peut
pas mettre à  jour l’information autrement que par des formulaires
et rechercher l’information autrement que par des
listes, ce que l’informatique mainframe fait depuis des
lustres. De plus personne n’a jamais essayé de démontrer
scientifiquement que l’ergonomie web ou les écrans
Windows puissent apporter un gain tangible de productivité
pour gérer l’information de gestion par rapport à  un écran en
mode caractères.
Mais il y a bien pire. La technologie Web a été pensée à 
l’origine pour des sites de présentation. Elle n’est pas adaptée
aux sessions persistantes des écrans esclaves des mainframes.
Les spécialistes chevronnés Java Web J2EE parlent à 
propos de l’ extrême complexité structurelle à  mettre en
oeuvre d’ un étouffement technologique. Ces applications ne
peuvent pas se passer des systèmes d’exploitation Windows
ou Linux dans la mesure où des applets Java doivent s’exécuter
sur le poste client. Seuls les écrans esclaves 5250 et
3270 sont réellement des clients légers puisqu’ils peuvent
s’affranchir de tout système d’exploitation micro et de la vulnérabilité
qui en résulte.
Les programmes RPG paraissent d’une simplicité biblique
à  côté. Pourquoi investir dans une technologie qui
n’apporte aucune valeur ajoutée à  l’entreprise et qui au
contraire pose des problèmes structurels de complexité ? Par
nature, les applications critiques ont besoin de stabilité, de
pérennité et de simplicité pour pouvoir être maintenues sur
le long terme par des équipes réduites qui connaissent bien
le métier de l’entreprise et qui ne sont pas forcément de purs
techniciens.
L’argument massue des détracteurs des
écrans en mode caractères consiste à  dire :
« les utilisateurs en ont assez de vos écrans
passifs et maintenant qu’ils ont goûtés aux
écrans graphiques, ils ne veulent plus revenir
en arrière. » Cet argument était vrai il
y a quelques années encore lors de la
grande période de l’hystérie graphique.
Aujourd’hui, les utilisateurs ont pris conscience,
avec la montée en charge et l’extrême
variété des virus informatiques, qu’il
est préférable d’avoir un mainframe afin de
ne pas mettre en péril la société qui les fait vivre. De plus, les
utilisateurs savent bien que l’on ne peut pas demander à  une
équipe réduite qui développe un logiciel à  un seul exemplaire
la même ergonomie qu’un progiciel vendu à  des milliers
d’exemplaires et développé par des équipes de plusieurs
dizaines de personnes car les budgets ne sont pas
comparables. En fait, les utilisateurs ont toujours eu peur de
l’informatique, de ses bugs, de ses virus, de son instabilité et
sont bien contents dans le fond de bénéficier d’un système
stable et d’une équipe informatique qui maîtrise pleinement
la situation en cas de problème. Toutes les très grosses sociétés
gèrent les données critiques avec des mainframes.
Nous savons que l’i5 est maintenant un mainframe avec ses
écrans esclaves. Pourquoi les PME n’auraient-elles pas droit
elles aussi à  des mainframes pour gérer leurs données critiques
?
Si une entreprise aujourd’hui voulait investir une somme
importante dans un nouvel applicatif de gestion back office :
faudrait il le développer en Java J2EE ou en RPG avec écrans
en mode caractères ? Afin de ne pas faire de la peine à  trop de
monde, nous préférons répondre à  la question par une
image : dans les années 60, on prédisait qu’au début du
21ième siècle les villes seraient enfermées dans des coupoles
climatisées et que les habitants y circuleraient avec des fusées
dans le dos. Pour les coupoles, on repassera.
Cependant, si vous en avez assez de ces voitures ringardes et
si quelqu’un vous propose un jour de vous élancer de la fenêtre
avec des fusées dans le dos, laissez votre voisin de palier
sauter en premier… sauf si vous habitez au rez-de-chaussée
bien entendu.