On dit continuellement que tout change très vite dans le secteur informatique et dans les techniques utilisées dans l’électronique et l’informatique. C’est en partie vrai mais en partie seulement. Aujourd’hui, dans cet article, nous allons plutôt parler des choses immuables, celle qui ne change jamais (ou presque jamais !) et vous allez voir qu’il y en a plein de ce genre dans l’informatique justement.

Une architecture Von Neumann omniprésente

Déjà un élément qui n’a jamais changé depuis le début c’est l’architecture des ordinateurs qui encore aujourd’hui répond à un formalisme qu’on appelle l’architecture Von Neumann.

Eh oui, c’est peut-être une surprise pour vous mais c’est toujours la même architecture depuis le début. C’est aussi parce que cette organisation des composants s’est avérée être efficace et relativement facile à mettre en œuvre. La technique informatique a évolué (un peu) sur les matières utilisées pour les composants et la structure même de ses composants mais l’architecture de base, elle, n’a jamais évolué. Cela peut enfin changer à l’avenir avec l’avènement des ordinateurs quantiques qui eux, sont radicalement différents mais comme cet avènement est encore lointain je gage que l’architecture Von Neumann a encore de beaux jours devant elle.

Le silicium irremplaçable ?

Autre chose qui n’a pas bougé depuis les débuts de l’informatique moderne : c’est l’usage du silicium pour les composants électroniques. Alors il est important de préciser qu’on parle de l’informatique moderne c’est-à-dire depuis le début des années 60 pas avant ou les ordinateurs étaient encore équipés quelquefois de lampe à vide et là ce n’était pas (du tout !) du silicium. J’ai beau être un ancêtre, avoir connu la carte perforée, mon ancienneté ne remonte tout de même pas jusque-là !

Donc le silicium semble être irremplaçable, indétrônable puisque depuis le début on n’a pas fait sans y avoir recours. Pourtant il y a eu quelques tentatives, dans les années 80 par exemple, avec l’utilisation de l’arséniure de gallium mais ça n’a pas été très loin. Donc encore un domaine qui se caractérise par un certain immobilisme.

Les projets, toujours un bain de sang !

Ce qui ne change toujours pas et qui est à la limite du désespérant, c’est la difficulté de mener des projets informatiques et d’aboutir dans les délais prévus et dans le budget prévu. En vérité, plus de la moitié des projets engagés par les clients, les constructeurs ou les éditeurs n’aboutissent tout simplement pas (pas du tout !). Depuis toujours, le développement logiciel est une activité difficile qui finit le plus souvent par un échec cuisant. Les méthodes évoluent, les outils évoluent mais ce qui ne change pas c’est la difficulté d’écrire des programmes et surtout de les mettre au point de manière satisfaisante. Une percée radicale ou une évolution significative sont annoncées régulièrement mais, presque 50 ans après le livre de Frédéric Brooks (The mythical man-month, à lire absolument !), on constate toujours qu’il n’y a toujours pas de balle d’argent (there is no silver bullet) et que les projets informatiques peinent à sortir du puits à goudron (tar pit).

La hype règne en maître !

Une autre constante du secteur de l’informatique, c’est ce qu’on appelle “la hype”. Il s’agit du battage médiatique à l’occasion d’une nouvelle mode technique. Ici tous les mots sont importants en particulier le fait qu’il s’agit de mode et non pas de techniques établies. Rappelons que le principe d’une mode c’est que ça se démode !

Alors dire que ça ne change pas est légèrement inexact car en fait la hype empire d’année en année donc quelque part ça change quand même un peu. Il y a quelques décennies il était raisonnable de parler de battage médiatique à chaque fois qu’une nouvelle mode technique apparaissait et semblait prometteuse. Puis on est passé à l’exagération médiatique et maintenant j’affirme qu’on en est à l’hystérie médiatique. En effet, à chaque fois qu’une nouvelle mode technique ou une pseudo mode technique apparaît et semble être plus ou moins prometteuse, on constate un déchainement hystérique (non, le mot n’est pas trop fort) de promesses extravagantes qui n’ont évidemment aucune chance de se réaliser. Le pire a été atteint avec le web 3 qui non seulement n’apportait pas grand-chose sur le plan technique mais en plus était tout simplement une escroquerie dans sa nature même.

Des promesses, toujours des promesses

Autre chose qui paraît immuable, qui semble ne jamais changer, ce sont les promesses commerciales pour vendre l’informatique au sens large ou des nouveaux systèmes ou des nouveaux logiciels ou des nouvelles architectures. Dernièrement on en a encore eu l’exemple avec la montée puis la généralisation du Cloud, la promesse était, encore une fois, que ça allait revenir moins cher. Combien de fois ai-je entendu cela pendant mes 40 ans de carrière dans le secteur ? 

Et, à chaque fois (chaque fois, j’insiste !), cela s’est avéré inexact. Il n’y a pas que l’argument économique qui revient constamment dans les promesses exagérées du discours commercial du secteur informatique, il y a également des affirmations du genre “ça va être plus facile à développer” ou encore “l’exécution des programmes sera bien plus rapide”. Je simplifie un peu (à peine !) mais vous avez tout de suite perçu l’idée générale derrière ces affirmations car vous aussi; vous les avez entendues encore et encore…

L’immobilisme n’est pas une fatalité

J’insiste ici sur les éléments qui ne changent pas mais cela ne veut pas forcément dire que des choses sont destinées à rester toujours les mêmes y compris dans les domaines déjà cités. Je voudrais prendre comme exemple la fameuse loi de Moore qui s’était toujours vérifiée depuis le milieu des années 60 mais qui a fini par s’effacer récemment. Donc, même une situation qui perdure année après année, décennie après décennie, n’a pas vocation à être en place éternellement, comme on a pu le voir justement avec la loi de Moore. Ceci pour dire que je ne prétends pas que toute l’informatique est condamnée à l’immobilisme et que rien ne change jamais, bien évidemment. Je veux juste mettre l’accent sur des exemples significatifs qui montrent que le progrès frénétique et les changements tout azimut ne sont pas une généralité en informatique contrairement aux idées reçues.

Pas un techno-réfractaire !

J’insiste aussi sur le fait que je ne suis pas contre l’évolution technique, je ne suis même pas un sceptique de l’évolution technique. Je voudrais juste qu’on en prenne la mesure exacte plutôt que de basculer systématiquement dans les fantasmes les plus délirants dès qu’on parle de l’évolution technique et de son inévitable accélération, qui est tout ce qu’on veut sauf prouvée. La meilleure preuve que je ne suis pas un “techno-réfractaire”, c’est que ce texte que vous êtes en train de lire, je ne l’ai pas directement rédigé mais plutôt dicté directement à mon Mac puisque, désormais, cette technique est suffisamment au point pour être utilisable (après, il faut bien le dire, des décennies d’efforts). Et d’ailleurs, dicter un texte n’est pas tellement plus facile ni même plus rapide que de le taper directement au clavier parce qu’il faut savoir à l’avance ce qu’on veut exprimer.

En conclusion

Il ne s’agit pas ici de seulement dénoncer une fois de plus les idées reçues trop nombreuses et trop stupides dans ce secteur comme dans de nombreuses autres. Tout au long de ma carrière en informatique j’ai justement essayé de promouvoir de façon équilibrée ce qui me paraissait être légitime, intéressant, utilisable, applicable en un mot. et c’est pour cela que j’insiste autant à travers mes livres ou dans des articles comme celui-ci sur le côté nocif de la hype ou sur les impasses que représentent les idées reçues.

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.