Dans les années 70, le petit monde des mainframes est confronté à des évolutions techniques majeures dans le domaine du logiciel et qui ont été systématiquement rejetées alors qu’elles apportaient plus de confort pour les développeurs ou les utilisateurs et souvent même les deux. Pourquoi ?

Pourquoi avoir rejeté des évolutions techniques si elles étaient aussi bénéfiques ?
Et quelles ont été les conséquences de ces rejets ?

Commençons tout d’abord par établir quelles étaient ces fameuses évolutions techniques décisives : il s’agissait de l’interface caractère, des L4G et des SGBDR. Ces trois éléments, individuellement ou ensemble, permettaient d’améliorer considérablement le confort des utilisateurs et, souvent aussi, des développeurs.

1- Pourquoi ces blocages et ces rejets ?

Le mode bloc : rustique et frugal

Détaillons cela en commençant par l’affrontement entre les modes d’interface…

L’interface en mode caractère représentait un vrai progrès en termes d’ergonomie et de réactivité par rapport à l’interface en mode “bloc”. Mais elle consommait aussi plus de ressources et générait plus de trafic réseau. Et c’est pour cela que le monde des mainframes est resté campé sur le mode bloc plus frustre mais bien plus économe. Voyons cela…

Le mode caractère : tout, tout le temps 

Le fonctionnement du “mode caractère” est facile à comprendre : à chaque fois que l’utilisateur frappe au clavier de son terminal, ce dernier envoie le caractère (d’où le nom du mode) entré à l’ordinateur central via la liaison réseau. Cet envoi systématique a pour conséquence qu’on demande beaucoup de transmissions de petite taille au réseau en question. Quand il s’agissait de liaisons séries sur la distance de l’étage d’un immeuble, cela ne posait pas de problème (contexte typique des applications départementales où on retrouvait le plus de mini-ordinateurs, ces derniers s’appuyant majoritairement sur le mode caractère). En revanche, sur des liaisons à grandes distances, les performances pâtissaient sensiblement de cette utilisation à répétition du réseau.

Le terminal emblématique du mode caractère, c’est le VT100 de DEC introduit en août 1978 et qui est devenu par la suite le standard pour les terminaux en mode caractère. La configuration du VT100 était réalisée au moyen d’écrans interactifs affichés sur le terminal lui-même. Les paramètres étaient sauvegardés dans une mémoire non volatile. Le VT100 a été le premier terminal de DEC à être équipé d’un microprocesseur standard du marché, le 8080 d’Intel. On pouvait adjoindre au terminal une imprimante externe et un dispositif de graphisme et de mémoire supplémentaire. On le voit, le VT100 avait un côté “terminal intelligent” qui était séduisant. 

Terminal DEC VT100 au Living Computer Museum

Le mode bloc : en une seule fois, de temps en temps

Si le mode caractère était omniprésent dans les minis, le mode bloc lui était la norme dans le domaine des mainframes, car il était plus adapté aux transmissions longues distances : la saisie de l’utilisateur n’était transmise qu’à l’initiative de ce dernier (quand il appuyait sur la touche Enter) et elle était envoyée complète, y compris avec les éléments de décors de la “page” sous la forme d’une “image après”. L’ordinateur central recevait cette image en bloc (d’où le nom du mode) et comparait avec “l’image avant” qu’il avait gardé en mémoire afin d’en déduire les différences. Ce type de fonctionnement était conçu pour s’adapter aux moniteurs transactionnels de l’époque (comme CICS) et était particulièrement bien adapté au découpage en trames des premiers réseaux informatiques (Transpac basé sur X25 par exemple). Le 3270 d’IBM était le terminal emblématique du mode bloc tout comme le VT100 était celui qui venait à l’esprit quand on pensait au mode caractère.

Terminal d’affichage couleur IBM 3279 (1979)

Une ergonomie réduite au minimum

Ceci dit, le mode bloc, s’il était économe en ressources techniques, imposait une ergonomie très fruste : l’utilisateur n’avait droit à aucune aide ou aucun contrôle de saisie tant qu’il n’avait pas “transmis” sa transaction… Au contraire, les applications reposant sur le mode caractère pouvaient guider et réagir immédiatement aux saisies de l’utilisateur tout au long du processus, au niveau le plus fin et même en fonction du contexte !

À cause de la contrainte des réseaux longues distances (dans le cas du départemental avec des liaisons séries, ça ne posait pas de problème), il était encore trop tôt dans l’évolution de la technique informatique pour que le confort de l’utilisateur prime, en mettant à sa disposition des interfaces capables de réagir immédiatement à la moindre saisie ou avec des langages évolués, simples à programmer. C’est donc fort logiquement que le mode bloc l’emporta dans la bataille qui l’opposa au mode caractère. 

Voyons maintenant l’épisode du rendez-vous raté avec les SGBDR et L4G…

L’impératif de la production bloque les évolutions

Il faut d’abord se représenter le niveau de rigidité imposée par l’informatique traditionnelle reposant sur des mainframes dans les années 60 et 70. Ici, l’impératif est d’assurer la “production” et même une production de masse : répondre à des utilisateurs nombreux de façon fiable et rapide sur des applications bien balisées permettant de traiter l’essentiel des affaires courantes. On peut résumer cet ensemble d’impératifs par le transactionnel. Le transactionnel était admirablement servi par les mainframes faisant tourner des applications développées dans les années 60 et en recourant à des techniques éprouvées : du Cobol et assez peu de vrais systèmes de bases de données (l’accès à des fichiers suffisait bien).

Les applications de production (celles qui nécessitaient des saisies intensives et des temps de réponses très courts) avaient été développées lors des décennies soixante et soixante-dix. À la fin des années soixante-dix, elles étaient désormais opérationnelles et stabilisées. Le transactionnel pouvait être considéré comme achevé.

Les demandes des utilisateurs se reportaient donc naturellement vers des besoins complémentaires et c’est ainsi qu’on est passé progressivement au décisionnel. Les L4G étaient particulièrement bien taillés pour ces applications d’aide à la décision puisqu’ils étaient tous plus ou moins orientés vers la production de rapports basés sur des extractions issues des systèmes de bases de données.

Un cycle trop long et trop lourd

Car, même avec une base de données classique, vous ne pouviez pas obtenir le résultat d’une requête sur votre écran simplement en la tapant depuis le clavier de votre terminal connecté au système central de votre organisation… Non, il fallait passer par un programmeur qui allait coder votre requête dans un programme qui, une fois mis au point, sera exécuté en batch et le résultat vous arrivera sur un listing… Avec un processus aussi lourd, on imagine facilement la frustration de l’utilisateur en s’apercevant que la requête était incomplète ou pire, erronée !

Il fallait recommencer tout le parcours en espérant avoir un accès rapide au programmeur capable de s’y retrouver dans la structure de la base de données… 

Les SGBDR permettent l’interrogation interactive

L’évolution vers des bases de données relationnelles (SGBDR) permettait de résoudre tout cela en une seule fois : on avait enfin une structure de base de données à peu près lisible, un langage d’interrogation (SQL le plus souvent) assez facile à manipuler sinon à apprendre (en tout cas, bien moins complexe et rébarbatif qu’un langage de programmation, même le plus basique…) et, cerise sur le gâteau, un logiciel permettant de saisir la requête au clavier et d’avoir le résultat immédiatement (enfin, plus ou moins rapidement selon la complexité de la requête, la taille de la base de données et la qualité de son indexation…) à l’écran, un vrai paradis par rapport à la boucle programme-batch-listing !

Pour optimiser encore ce recours à l’informatique décisionnelle (c’est ainsi qu’on s’est vite mis à appeler tout ce qui n’était pas du ressort de l’informatique traditionnelle de production, le transactionnel), les L4G représentaient le couplage idéal avec les SGBDR. Voyons maintenant comment ces nouveaux langages (nouveaux pour l’époque) sont apparus…

Faire face au goulot d’étranglement

Certains éditeurs eurent l’idée de faire évoluer les langages de développement vers un plus haut niveau d’abstraction. Cette évolution fut vite appelée quatrième génération et ces langages des L4G. Les L4G représentaient bien une réponse appropriée à un besoin qui était latent lors des années soixante-dix et quatre-vingt (surtout dans les environnements mainframes) : le goulot d’étranglement des programmes était surtout dû au fait qu’il fallait passer par le service informatique et ses programmeurs pour la moindre intervention sur les applications. Si un cadre avait besoin d’un nouveau rapport sur les ventes, il fallait écrire une nouvelle application pour cela et ce « simple » rapport se transformait en projet qui durait des mois (sans compter qu’il fallait des mois sinon des années avant que cette demande soit seulement prise en compte…).

La solution au problème de l’ingénieur

Un exemple de la puissance des L4G par rapport au Cobol est illustré par la solution à une question classique connue sous le nom du « problème de l’ingénieur » : donner une augmentation de 6% aux ingénieurs dont la note moyenne est de sept ou mieux. Pour résoudre ce problème, James Martin (un célèbre consultant, très fan des L4G) rédigea une douzaine de pages de code Cobol et seulement deux pages de code Mark IV. Avec Nomad (un L4G bien connu), ce problème pouvait être résumé en une simple ligne : CHANGE ALL SALARY = SALARY*1.06 WHERE POSITION = ‘ENG’ AND AVG (INSTANCE (RATING)) GE 7…

Une simplicité qui se paye, hélas…

Mais, bien entendu, cette simplicité se payait via une consommation de ressources importante : les L4G étaient bien plus lents en exécution que les programmes rédigés avec des langages traditionnels (tout simplement parce que les L4G étaient exécuté en mode “interprété” alors que les programmes écrits en langages traditionnels étaient eux compilés avant exécution…). Encore une fois, c’est la consommation de ressources informatique qui a fait barrage à leur adoption sur mainframe et ce aussi bien pour les L4G que pour les SGBDR. Lorsqu’on essayait de faire tourner une application développée en L4G et faisant appel à un SGBDR de façon intensive, le pauvre mainframe s’effondrait, tout simplement. Ses temps de réponse grimpaient dramatiquement au détriment de tous et d’abord des applications de gestion habituelles dont le fonctionnement correct était critique pour la bonne marche de l’entreprise… Évidemment inacceptable et les L4G et autres SGBDR étaient bientôt rejetés en raison de leurs exigences en ressources tout comme l’avait été le mode caractère des terminaux évolués.

Des montres de puissance ? En fait, non.

Car nous faisons une erreur fondamentale en voyant ces mainframes comme des monstres débordant de puissance. Monstrueux, ils l’étaient (par la taille au moins), certes. Mais puissants, pas tellement en fait. Si on compare avec nos machines d’aujourd’hui (y compris celle que vous tenez dans la main ou portez à votre poignet), les mainframes affichaient une puissance et des capacités (mémoire, stockage) ridicules…

Ces ordinateurs centraux coûteux ne pouvaient pas faire tourner des programmes trop exigeants et c’est pourquoi les applications développées pour eux étaient particulièrement optimisées (une notion importante mais qu’on a oublié depuis !). Optimisées dans tous les compartiments, y compris dans leur stockage (ce n’est pas pour rien que les programmeurs s’étaient résolus à ne stocker les années des dates que sur deux digits pour économiser de la place… ce qui conduisit au trop fameux “bug de l’an 2000” !). Des pratiques parfaitement légitimes à l’époque même si elles nous paraissent désormais absurdes et désuètes.

Tout cela pour se rendre compte qu’effectivement, les mainframes d’alors ne pouvaient pas se permettre le luxe du mode caractère, des L4G et des SGBDR… Bien entendu, à l’époque, on était conscient de ces limites et on commençait à envisager la notion de traitements distribués entre plusieurs ordinateurs reliés en réseau. On en parlait mais ça restait encore une perspective lointaine (seul DEC a commencé à le mettre en œuvre avec DECNet qui permettait de voir plusieurs VAX en réseau comme une seule et même machine).

Plus prosaïquement, tout ce qu’on savait faire de concret à l’époque, c’était de proposer des mainframes toujours plus gros, suivant en cela la loi de Grosch (voir à https://fr.wikipedia.org/wiki/Loi_de_Grosch) qui s’est ensuite avérée être erronée (pas de chance, hein !).

Un exemple vécu

Lors d’une mission de mise en place d’un infocentre autour de DB2 pour les groupe André (les chaussures) à la fin des années 80, j’ai pu constater la voracité de DB2 (le SGBDR vedette d’IBM alors). Le DB2 en question n’était pas installé sur le 3090 qui était réservé (préservé !) aux applications de production et qu’il n’était pas question de perturber d’aucune façon. Notre DB2 était donc installé à part sur un 4381 (un mainframe d’IBM mais considéré comme “entrée de gamme”) qui était l’ordinateur de réserve d’André (au cas où le 3090 aurait une défaillance, le 4381 était capable de faire tourner les applications en “mode dégradé”…). Sur ce 4381, notre SGBDR était à son aide et prenait même toute la place : à part le système (MVS/SP) et son interface TSO, rien d’autre ne tournait (ni même ne pouvait tourner !). Nous avions un petit mainframe rien que pour notre infocentre et ça allait tout juste comme cela !

C’est donc la gourmandise en ressources techniques des évolutions telles que les L4G et les SGBDR qui ont provoqué leur rejet par les techniciens mainframes. En conséquence, toutes les initiatives « progressistes » qui avaient commencé à apparaître comme les L4G et la notion d’infocentre furent mises en sommeil (nous y reviendrons).

Mais cette première victoire des “conservateurs” sur les “progressistes” eut un effet pervers : persuadés de détenir la bonne architecture, les tenants du mainframe restèrent figés par la suite dans une posture où les revendications en faveur du confort des utilisateurs furent systématiquement ravalées au rang de caprices sans importance ou impossibles à satisfaire au nom des contraintes techniques (alors qu’il était simplement trop tôt).

2- Les conséquences de ces rejets

Nous venons de voir pourquoi ces évolutions positives, nécessaires mêmes, avaient été rejetées par le monde des mainframes. Monde rigide et incapable de prendre en compte (pour des raisons bien réelles de ressources limitées) autre chose que le sacro-saint transactionnel.

Comment allaient réagir les partisans et promoteurs de ces évolutions ?
Les abandonner, les laisser mourir dans les fossés de l’Histoire de l’évolution technique ?

Certes non et deux camps bien distincts se formèrent : d’une part le clan des mainframes qui campait sur leur pré carré et, d’autre part, le clan des « évolutionnistes » qui trouva un terrain d’expression avec les minis-ordinateurs…

C’est que, quasiment au même moment (au virage des années 70), une nouvelle classe de machines était apparue et avait trouvé sa niche : les minis. Bien moins coûteux à acquérir et bien plus simples à exploiter que les ordinateurs centraux habituels (qui eux tendaient à être de plus en plus gros), ces nouvelles machines permettaient d’apporter l’informatique à un autre niveau : l’échelon départemental.

C’est sur ce terrain que s’est jouée la première vraie scission (quasiment l’équivalent d’un schisme !) de l’histoire de l’informatique. Les acteurs traditionnels restaient sur les mainframes, les nouveaux acteurs tentaient leur chance sur les minis.

Des raisons financières

Déjà, les éditeurs de SGBD traditionnels préféraient s’affronter sur le terrain des mainframes plutôt que sur celui des mini-ordinateurs pour deux raisons : 1) le prix des licences sur mainframe était plus élevé que sur mini-ordinateur (alors que l’effort de vente était quasiment le même) 2) les mini-ordinateurs étaient plus destinés à faire tourner des progiciels que de servir de plateformes pour des applications spécifiques « développées à la maison » (in house programming), terrain de prédilection des SGBD sur grands systèmes.

De plus, au début des années quatre-vingt, la technologie relationnelle apparaissait (avec quelques raisons) comme trop immature pour intéresser les fournisseurs de SGBD traditionnels (sauf IBM) permettant à Oracle et consorts de se développer au sein de leur « niche »… Et que s’est-il passé ensuite ?

Pas grand-chose au final : les minis ont comblé les utilisateurs sur la niche où ils étaient bien dimensionnés mais ils n’ont pas été capables d’aller au-delà. Non, pour cela, il fallut attendre une autre vague majeure de l’évolution technique : les micro-ordinateurs (PC).

La vague PC relance l’innovation

Les PC permettaient d’adresser les besoins individuels des utilisateurs : du jamais vu dans le monde codifié et bien balisé de l’informatique traditionnelle !

Au début, cela est resté relativement modeste et confiné à la bureautique (le tout avec une interface caractère héritée de ce que proposaient les minis). Et puis les choses se sont mises en route : l’interface graphique est apparue puis s’est imposée et, dans la foulée, on a voulu développer de vraies applications en réseau capables de servir des dizaines, voire des centaines de PC reliés en réseau. Et, pendant ce temps, le monde des mainframes apparaissait comme immuable, figé, inamovible, comme une forêt pétrifiée par un cataclysme inexplicable…

En rejetant des évolutions techniques immatures qui étaient arrivées un poil trop tôt, les mainframes se sont coupés du mouvement et se sont rétractés sur eux-mêmes. Ce fut cela la principale conséquence de ce tournant manqué. L’innovation technique n’était pas la bienvenue dans ce monde fossilisé ?
Pas de problème, elle trouva un terrain d’expression enthousiaste sur les PC en réseau !

Le modèle client-serveur s’impose

Pour développer des applications qui reposent à la fois sur l’interface graphique côté utilisateurs et sur les SGBDR côté serveurs, il fallait une architecture qui permette la distribution des traitements de façon simple et pratique. Le modèle client-serveur s’est alors imposé comme la solution évidente, naturelle. Il permettait de combiner le “meilleur des deux mondes” : d’une part l’interface évoluée (graphique) côté utilisateur et, d’autre part, les fonctions avancées des SGBDR modernes sur des serveurs puissants (minis d’abord, stations de travail ensuite, PC montés en grade -comme le Compaq SystemPro- enfin).

Un serveur Compaq SystemPro, un des premiers PC a vraiment pouvoir jouer le rôle de serveur : puissant et sécurisé.

On a même cru que ces configurations client-serveur allaient pouvoir rivaliser avec les mainframes et permettre un “downsizing” révolutionnaire en déboulonnant les grosses machines et en les envoyant dans les poubelles de l’Histoire !

Un règne assez court

Bien entendu, cette révolution promise par les plus enthousiastes des partisans du client-serveur (et j’en étais !) n’a pas eu lieu : les mainframes n’ont pas été déboulonnés, ils sont restés en place pour faire tourner les fameuses applications de production que les organisations n’avaient aucun intérêt (ni envie !) à refaire. Ensuite, ni l’avènement du Web ni le bug de l’an 2000 n’ont remis en cause les mainframes mais ont accentué leur isolement.

Pour finir, la vague du cloud a encore érodé leur position mais sans les faire disparaître tout à fait pour autant. Ils sont toujours là à chaque fois que, par exemple, vous payez avec votre carte de crédit. Ils sont devenus les fossiles vivants d’une époque révolue, témoignages figés d’une épopée commencée au tout début des années soixante et qui s’est arrêtée à son apogée à la fin des années soixante-dix.

Leçons et enseignements

La leçon de ce tournant manqué c’est que l’innovation technique, la vraie, celle qui s’appuie sur des avantages concrets, mesurables, des bénéfices durables, cette innovation là trouve toujours sa voie. Même quand l’environnement dominant la rejette, elle renaît sous d’autres cieux et se met à fleurir grâce à ce nouveau terreau.

Un domaine technique qui n’évolue plus (même pour de bonnes raisons) est un domaine condamné. Même si les machines sont toujours utilisées, la dynamique les a déserté et est partie ailleurs exercer ces effets bénéfiques.