Mon projet de livre sur l’histoire de l’informatique avance bien. Après l’ère des constructeurs, je suis en train de rédiger l’ère des éditeurs et j’ai pensé que c’était une bonne idée que de partager quelques extraits de cette grosse section à venir…
Voici donc l’histoire des débuts des SGBD Relationnels suivit du parcours de SAP… Vos commentaires, suggestions, corrections sont les bienvenues, ça va sans dire, hein !
Le parcours accidentel mais fructueux de SAP
SAP fut fondée en avril 1972 par cinq anciens employés d’IBM allemagne. Les cinq associés quittèrent IBM car ils étaient motivés par la proposition d’ICI (Imperial Chemical Industries, le groupe chimique britanique bien connu était alors client d’un mainframe IBM 370 et voulait que soit développé un logiciel de gestion de production et de comptabilité) qui venait d’être rejettée par IBM allemagne qui ne voulait pas sortir de son rôle de constructeur. ICI proposa le contrat aux cinq « conjurés » qui virent ainsi l’opportunité de créer leur société avec un projet qui pourrait être proposé à d’autres clients par la suite.
Ce que ICI voulait était un embryon de logiciel de gestion de production inspiré de la notion de MRP très en vogue dans les années 70 (comme on l’a vu avec ManMan d’ASK).
==== encadré sur MRP/ERP ========
Voilà ce que nous dit wikipedia sur les notions de MRP et d’ERP
On distingue le MRP (Material Requirements Planning), né formellement aux Etats-Unis en 1965 et qui ne représente alors qu’une méthode de calcul des besoins en matières, de son évolution, le MRP2 ou MRP II (Manufacturing Resources Planning). Ce modèle plus large, qui intègre la gestion de toutes les ressources de l’entreprise (consommables, c’est-à-dire « matières et composants », et renouvelables, c’est-à-dire « capacité machines et main-d’œuvre »), constitue un système de pilotage des ressources qui repose sur la prévision des ventes et les nomenclatures de produits et qui opère comme le MRP en flux poussé (c’est-à-dire que l’on établit le plan de production sur la base de prévisions).
Le MRP transforme en données de production les données commerciales relatives aux ventes. Le MRP2 intègre d’autres fonctions telles que la planification à capacité infinie, l’ordonnancement à capacité finie des ressources machine et main d’œuvre, le suivi de production, le calcul des coûts, etc.
Le MRP2 est le précurseur des progiciels ERP (Enterprise Resources Planning) et reste souvent l’un de leurs modules fondamentaux.
——-
Le terme ERP provient du nom de la méthode MRP (Manufacturing Resource Planning) utilisée depuis les années 1970 pour la gestion et la planification de la production industrielle.
Le principe fondateur d’un ERP est de construire des applications informatiques (paie, comptabilité, gestion de stocks…) de manière modulaire (modules indépendants entre eux) tout en partageant une base de données unique et commune. Cela crée une différence importante avec la situation préexistante (les applications sur mesure existant avant les ERP) car les données sont désormais supposées standardisées et partagées, ce qui élimine les saisies multiples et évite (en théorie) l’ambiguïté des données multiples de même nature (exemple : société TRUC, TRUC SA et Sté TRUC…).
L’autre principe qui caractérise un ERP est l’usage systématique de ce qu’on appelle un moteur de workflow (qui n’est pas toujours visible de l’utilisateur), et qui permet, lorsqu’une donnée est entrée dans le système d’information, de la propager dans tous les modules du système qui en ont besoin, selon une programmation prédéfinie.
Ainsi, on peut parler d’ERP lorsqu’on est en présence d’un système d’information composé de plusieurs applications partageant une seule et même base de données, par le biais d’un système automatisé prédéfini éventuellement paramétrable (un moteur de workflow).
==========
La coopération avec ICI a été fondamentale dans les débuts de SAP : non-seulement ICI permettait aux cinq fondateurs de développer le logiciel sur le mainframe de la société mais le contrat prévoyait que le produit final pourrait être proposé à d’autres clients sans qu’ICI ne touche de royalties. ICI alla même jusqu’à arranger des visites clients afin de faciliter la prospection de SAP (comme anciens d’IBM allemagne, nos cinq fondateurs avaient accès aux vaste réseau de clients d’IBM, leur cible de base pour la commercialisation de leur logiciel).
La première version du logiciel alors appelé MIAS (pour Material Information and Accounting System) fut terminée en janvier 1973 mais des modules supplémentaires furent développées l’année suivante. La commercialisation progressait également de façon satisfaisante : en 1975, MIAS était installé sur 40 sites et ce nombre atteignait 100 en 1978.
En 1977, SAP porta son logiciel sur mainframe Siemens avec lequel il y eu un accord de commercialisation mais le focus sur les systèmes IBM restait primordial.
En 1979, SAP pu enfin acquérir son propre mainframe IBM et en profita pour se lancer dans le développement d’une nouvelle version de son logiciel enfin appelé R/2 qui pu être lancé en 1981. Pour se conformer à la norme MRP-II, R/2 contenait des modules supplémentaires dont certains comme le module de RH avait été développé en coopération avec des clients. La phase suivante du développement a été l’internationalisation du logiciel et sa commercialisation.
Là encore, il ne s’agit pas de l’exécution d’un plan soigneusement définit à l’avance mais plutôt d’une opportunité apportée par les clients et que SAP n’a fait que suivre (mais le mérite n’est pas nulle : les dirigeants auraient pu rester aveugles et sourds à ces opportunités et les rejetter les unes après les autres… comme d’autres l’ont fait !). Cette fois, c’est la direction européenne de John Deere qui décidé d’installer R/2 dans toutes ses usines en europe et cela nécessitait sa traduction en anglais et en français. SAP créa une filiale en Suisse en 1984 pour accompagner ce développement à l’internationale.
Les concurrents américains de SAP tentèrent également de s’implanter en europe mais il s’avéra que le chemin était plus difficile pour eux que pour un européen qui était déjà habitué aux nombreuses contraintes locales (monnaies, législations et autres). De plus, les éditeurs américains bénéficiaient du confort d’un marché domestique vaste, ce qui reléguait la conquête du « reste du monde » à toujours plus tard…
Au fur et à mesure de son expansion, SAP réussit à déclencher un autre relais de croissance sans tomber dans le piège classique de l’intégration verticale : le besoin de personnel compétent pour accompagner les installations et paramétrage de R/2 allant croissants, au lieu d’essayer d’embaucher des consultants en interne, SAP su s’appuyer sur des sociétés extérieures en tissant un réseau de partenariat. Cette démarche fut particulièrement fructueuse quand ce réseau s’entendit au-delà des SSII classiques pour toucher aussi ce qu’on appelait alors les « big six » : Price Waterhouse, Coopers & Lybrand, Deloitte & Touche, Arthur Andersen, KPMG et Ernst & Young, les sociétés de consultants spécialisées dans l’audit et la comptabilité. (ces « big six » sont aujourd’hui devenus les « big four » suite à des fusions et acquisitions entre eux…). Ces consultants avaient un accès fréquent aux directions générales (bien plus que les SSII) et servirent de relais commercial très efficace pour diffuser la bonne parole en faveur de R/2…
Le tournant vers R/3
Dans les années 1987/88, SAP s’introduisit à la bourse de Francfort mais c’est aussi lors de cette période qu’IBM, son principal partenaire technique lança son offre AS/400 ainsi que ses premiers systèmes Unix (la première station de travail Unix de big blue, la 6150 avait été dévoilée en 1986). Influencé par IBM et par un client (les chemins de fer allemand, la Deutsch Bahn), SAP se lança dans le développement d’une version de son logiciel pour l’AS/400 : R/3. Initialement, R/3 n’était pas du tout destiné à remplacer R/2 mais plutôt pour attaquer le marché des PME. Les sociétés moyennes n’étaient évidemment pas équipées avec des mainframes et un mini comme l’AS/400 leur était directement destiné.
Le développement de R/3 a été plus que difficile puisqu’il pris quatre ans (de 1987 à 1991) et failli être annulé à deux mois de son annonce au CEBIT de 1991… Il s’avéra que R/3 était trop exigeant en ressources pour tourner sans mal sur un AS/400 !
Et la solution fut plutôt de le proposer sur serveur Unix. En fait, le développement avait eu lieu sur Unix et avec un SGBDR Oracle, R/3 fonctionnait convenablement. Ce tournant représentait beaucoup pour une société qui avait jusque-là quasiment exclusivement dans l’ombre d’IBM mais il s’avéra être la bonne décision. En europe, les ventes de R/3 démarrent doucement mais la perçée eu lieu aux USA : présenté à l’occasion de la réunion Sapphire (le groupe utilisateurs des clients américains), R/3 emporta l’enthousiasme des grandes sociétés américaines qui étaient déjà au fait du modèle client-serveur utilisé par R/3.
Le chiffre d’affaires de SAP explosa principalement grâce à la croissance de ses ventes aux USA. Accessoirement, cela aida aussi Oracle à consolider sa position de SGBDR de référence. La collaboration avec Oracle est progressivement devenue une cohabitation au fur et à mesure que le fournisseur de SGBDR devenait un concurrent direct (au fil des années, Oracle a racheté PeopleSoft et J.D. Edwards, deux ex-concurrents de SAP). Du coup, SAP chercha à se défaire de cette « dépendance » vis-à-vis d’Oracle.
Courant 1998, les spéculations et rumeurs allaient bon train sur le SGBDR que SAP pouvait ou allait racheter. Sybase et Informix (ce dernier va être racheté par la suite par IBM) étaient les plus souvent cités car, même si les installations de l’ERP SAP/R3 reposaient majoritairement sur Oracle comme base de données, l’opposition et la concurrence entre les deux éditeurs était vive. Il apparaissait donc naturel que SAP veuille pratiquer l’intégration verticale en rachetant un éditeur de SGBDR afin de proposer sa base de données plutôt que celle d’Oracle par ailleurs éditeur d’ERP lui aussi.
Finalement, SAP s’est contenté de passer un accord avec Software AG autour du SGBD Adabas. A travers cet accord, SAP obtenait le droit de développer et de revendre sa propre version d’Adabas renommée SAP DB pour l’occasion. Mais cet accord eu peu d’effets par la suite et, encore aujourd’hui, au moins les deux tiers des installations de SAP R/3 tournent avec Oracle comme SGBDR.
SAP ne s’est pas retrouvé confronté qu’à Oracle comme ancien partenaire technique… Microsoft qui affirmait (par le biais d’une déclaration de Bill Gates) qu’il ne « ferait jamais de logiciel de comptabilité » dans les années 90 a évolué depuis : fin 2000, Microsoft racheta Great Plains Software qui développait et commercialisait une logiciel de compta justement… En 2002, récidiva avec le rachat de Navision qui proposait un ERP. Ces acquisitions furent rassemblées par la suite dans la division Microsoft Business Solution.
Mais SAP reste le leader de ce secteur et continue son expansion dans tous les sens avec le rachat spectaculaire de Business Objects (l’éditeur français d’outils d’infocentre) en 2008 (opération annonçée en octobre 2007).
La montée des SGBDR
Alors que le marché des bases de données semblait clairement répartit dans les années 80 avec les SGDB relationnels pour le décisionnel et les SGBD traditionnels pour le transationnel, cette frontière s’effaça dans les années 90 et les SGDR se généralisèrent. Mais, avant cela, le chemin fut long et difficile. Nombreux doutaient que les SGBDR deviennent plus qu’une curiosité de laboratoire pour universitaires.
Charles Bachman lance le mouvement
La préhistoire des bases de données repose presque entièrement sur un nom : Charles Bachman. C’est lui qui, en 1961 et chez General Electric, développa le premier IDS (pour Integrated Data Store), un système pionnier de base de données capable de prendre en compte les nouveaux supports de stockage comme les disques magnétiques qui commençaient à apparaitre.
Les tous premiers logiciels de bases de données datent donc des années 60. La technologie d’alors était encore assez frustre et les principes retenus ne permettaient pas l’indépendance des applications avec le système de base de données utilisé.
C’est aussi Bachman qui au milieu des années 60 rassembla le DBTG (Database Task Group) qui allait publier une série d’articles et de spécifications sur les méthodes d’accès aux bases de données par des langages comme Cobol.
Le DBTG fut intégré à CODASYL (déjà responsable de la normalisation du Cobol) et produisit une norme qui fut adoptée aussitôt par de nombreux constructeurs… Saut IBM !
C’est qu’IBM, de son côté, avait lançé sur son marché son propre SGBD (IMS, en 1968) qui était dérivé d’un projet réalisé pour la NASA pendant le programme Apollo. Jusqu’à l’apparition du modèle relationnelle, les principaux systèmes étaient soit hiérarchiques (comme IMS d’IBM ou Total de Cincom)) soit navigationnel (ou réseau, conformes au modèle proposé par le DBTG issu de CODASYL en octobre 1969) comme IDMS (Computer Associates), Datacom DB (d’ADR, plus tard rachété par Computer Associates), ou Adabas (Software AG, Adabas -mais aussi Datacom DB- a été largement modifié avec le temps et a même été adapté au modèle relationnel…).
C’est ce modèle navigationnel promu par CODASYL qui provoqua une poussée de développement dans le monde des bases de données jusqu’alors pas très dynamique. Quand General Electric décida d’abandonner le secteur informatique, c’est la SSII de John Cullinane racheta leur base de données et s’occupa de la migration du logiciel pour la porter sur mainframe IBM (mais il eu aussi des versions pour DEC et ICL). IDMS (c’est le nom que donna Cullinane à ce produit) était conforme à la « norme » CODASYL alors que les autres bases de données qui dominaient jusqu’alors le marché (IMS et TOTAL) ne l’étaient pas… Du coup, IDMS connue une croissance foudroyante et ses ventes passèrent de $2 millions en 1975 à $20 millions en 1980.
Le développement d’applications sur ces SGBD n’était pas facile et c’est pour cela que certains éditeurs proposait d’associer leur base de données avec un langage de programmation de haut niveau qu’on a vite baptisé L4G (langage de 4ème génération). Les deux « couples » (SGBD + L4G du même éditeur) les plus fameux du début des années 70 étaient sans doute Datacom/Ideal (d’ADR) et Adabas/Natural de Software AG. Adabas (qui est une abréviation de « adaptable database system ») vient de la société allemande Software AG. Adabas a été développé par Software AG avec l’aide de l’AVI Institut. Cet éditeur était le seul acteur européen un peu important (avant que SAP le dépasse et le fasse un peu oublier) dans un secteur entièrement dominé par les sociétés américaines.
On reviendra sur cette épisode des L4G car il le mérite et revenons à nos acteurs… Charles Bachman reçu le prix Turing en 1973 et, à cette occasion, prononça le fameux discours « The programmer as navigator » (le programmeur comme navigateur). Charles Bachman est alors à son apogée mais intéressons-nous plutôt à celui qui va lui succèder… Un certain Codd.
Codd pose les bases du relationnel
C’est Edgar F. Codd qui en 1970 posa les bases du modèles relationnel. Dans une série d’articles, Codd proposa un modèle qui reposait sur deux principes : 1) l’indépendance des données par rapport à leur mode de stockage matériel, 2) une navigation automatique grâce à un langage de requêtes de haut niveau qui évite au programmeur de devoir « naviger » d’un enregistrement à l’autre pour trouver la donnée qu’il cherche…
Associé à un langage d’interrogation « ad hoc », les bases de données relationnelles représentaient effectivement une vraie perçée par rapport à la complexité et à la rigidité des systèmes de bases de données en usage au début des années 70. Avec une base de données classiques (conforme ou non au modèle CODASYL), 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… Le relationnel 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 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 gateau, 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 !
Donc, Codd proposait donc cela à travers sa série d’article publiés en 1970 mais rien d’autre… Il fallu attendre un peu avant de voir les premières implémentations expérimentales.
System/R chez IBM, l’enfant non désiré !
Codd travaillait chez IBM mais big blue n’avait pas l’intention de remettre en cause IMS qui fonctionnait bien pour une idée dont on ne savait pas encore si elle était vraiment réalisable (et si oui, amenait-elle effectivement les bénéfices espérés ?). Mais Codd sut mener une action de lobbying intelligente, y compris en acceptant un débat avec Charles Bachman qui représentait alors l’autorité suprême en matière de bases de données… Tant et si bien qu’IBM fut quasiment « forcé » de lancer un projet de recherche au laboratoire de San José pour vérifier la faisabilité des travaux de Codd.
Le projet s’appelait System/R et la première phase (en 1974/75) permit de produire rapidement un prototype qui démontrait la validité des principes énoncés par Codd. Le code de ce premier proto ne fut pas repris par la suite car il s’agissait vraiment d’un premier jet. La seconde phase (en 1978/79) produisit une version plus complète fonctionnellement, permettant l’accès concurrentiel (multi-utilisateurs) et surtout, dotée d’un langage d’interrogation qui fit du chemin depuis… SQL.
System/R était un projet de recherche et il ne fut donc jamais commercialisé en tant que tel. On sait que le premier SGDR d’IBM fut SQL/DS proposé en 1982 pour les mainframes tournant sous VM et VSE. Pour la version MVS, il fallu attendre 1983 et le fameux DB2. Ce qu’on sait moins c’est que le code de System/R fut tout de même réutilisé en partie pour la toute première implémentation d’un SGBDR chez IBM : celui qui était intégré au système d’exploitation du System/38 en 1980 (le 38 était le mini-ordinateur de Big Blue, successeur du 36 et avant l’AS/400).
A la suite de System/R, Larry Ellison créa Oracle en 1977 (mais, dans un premier temps, la société s’appelait Software Development Laboratories, puis en 1979 le nom changea pour Relational Software, Inc. -RSI- et, enfin, en 1982, RSI changea encore pour Oracle Systems).
Mais avant Oracle, Micheal Stonebraker, chercheur à Berkeley, développa un prototype universitaire de SGBDR à peu près à la même époque qu’IBM avec System/R et lui aussi en s’inspirant de l’article de Codd.
Ingres et la vertue de l’essaimage
Codd posa les bases mais c’est bien Stonebraker qui sema la première graine !
Alors que Codd se débattait pour qu’IBM fasse enfin quelque chose avec ses idées, Micheal Stonebraker agissait sans perdre de temps. Aidé d’Eugen Wong, il trouva un peu d’argent afin de lancer un projet de recherche basé sur le modèle relationnel et ce dès 1973. Initialement, les fonds sont venus de la branche études économiques de Berkeley afin de réaliser un système de modélisation géographique. C’est pour cela que le projet s’appelait Ingres (qui voulait dire Intervactive Graphics and Retrivial System et non une référence au célèbre peintre français du XIXème siècle…).
Au bout du compte, c’est surtout la NSF (National Science Foundation) qui finança le projet Ingres qui dura jusqu’en 1982 (puis fut suivit de Postgres destiné à promouvoir les bases de données objets mais c’est une autre histoire et qui ne connue pas un dénouement aussi heureux que pour le relationnel !). Ingres était très semblable à System/R mais reposait sur des Minis de DEC plutôt que sur un maiframe IBM. Une première version était « montrable » dès 1974 mais fut suivie par plusieurs révisions afin de rendre le code plus maintenable. Très vite, Stonebraker commença à diffuser le code d’Ingres en dehors de Berkeley afin de reccueillir des commentaires et des idées sur le prototype qui évoluait en permanence.
En 1976, Ingres fut doté d’un langage de requêtes (QUEL) très semblable à SQL (semblable mais différent tout de même…). On sait que dans l’affrontement entre QUEL et SQL, c’est ce dernier qui triompha mais le riche héritage d’Ingres va bien au-delà de cette anecdote : durant les années « Berkeley » du projet Ingres, pas moins de 30 personnes ont travaillé dessus à tour de rôle (mais il n’y eu jamais plus de 6 programmeurs à la fois sur le code en évolution permanente). Si on ajoute les 15 programmeurs qui ont développé et corrigé le code de System/R, ça nous fait une petite cinquantaine d’individus qui se sont ensuite éparpillés autour de Berkeley et de San José pour créer effectivement les éditeurs qui ont donné force et vie au modèle relationnel. En effet, tous ceux qu’on retrouvent impliqués dans les multiples projets des années 80 autour des SGDR sont passés à un moment ou à un autre soit à Berkeley sur Ingres, soit à San José sur System/R.
Micheal Stonebraker lui-même créa Ingres Inc pour commercialiser le code de son projet. Bob Epstein participa à la fondation de Britton-Lee avant de rejoindre Sybase et ainsi de suite. Epstein explique bien que « ce qui resta d’Ingres est l’expérience d’avoir un prototype et de savoir quelle parties devaient être développées d’une façon différente… » et pour une technologie encore immature comme l’était le relationnel à l’époque, c’était simplement énorme.
Oracle a commencé son activité à Belmont, dans le nord de la Californie. Ses premiers concurrents venaient également de la même région, tous voisin du laboratoire IBM de San José où avaient été menées les recherches sur System/R. Larry Elisson embaucha des programmeurs qui avait participé à Ingres et il developpa un SGBDR doté du langage SQL avant même qu’IBM dévoile SQL/DS. Il avait eu vent du langage SQL à travers les articles publiés par le groupe qui travaillait sur System/R. Mais les tous premiers produits disponibles comme Oracle souffrait d’un grave défaut : ils étaient terriblement gourmand en ressources et aussi très lents lors de l’exécution de requêtes complexes (et la lisibilité de SQL ou de Quel favorisait l’écriture de requêtes complexes, forcément…).
La parenthèse des « machines base de données »
Pour faire face à cette consommation de ressources qui effrayait les responsables de sites informatiques et les faisait bannir d’avance l’idée même d’installer un SGBDR (fut-il doté de l’étiquette magique IBM…) sur leurs précieux mainframes, certains entrepreneurs eurent l’idée de réaliser des serveurs dédiés et optimisés pour l’exécution de ces gourmands SGBDR… Autrement, dit des machines base de données !
La notion de machine dédiée faisait partie des idées qui faisait fureur à l’époque, tout comme les stations de travail dédiées dédiées au langage LISP. Mais cette notion fit long feu et seul Teradata dans le domaine des bases de données put faire fructifier cette idée pendant quelques années.
Justement, Teradata faisait partie des pionniers de cette vague de serveurs dédiés, l’autre étant Britton-Lee (où on retrouve Bob Epstein parmi les fondateurs). Pour comprendre pourquoi ce concept connu quelques succès, il suffit de se replacer dans le contexte de l’époque et, pour cela, donnons la parole à un témoin, Paul Stuber, responsable de l’analyse des ventes de la société Wrigley (les chewing gums)… Stuber est l’heureux client d’un serveur Britton-Lee et il explique en 1988 ce que ça lui apporte :
« il s’intégre bien avec nos PCs et c’est comme un appareil spécialisé pour nous. Il n’est pas affecté par ce qui se passe sur notre mainframe et il ne le perturbe pas non plus. De plus, la sécurité est plus facile à assurer sur cette simple machine.
Les SGBDR font du bon travail mais ils exigent une très grosse machine. Celle-là est petite et notre service suffit pour la gérer. Nous pouvons ainsi offrir des données en ligne à nos forces de vente et marketing sur n’importe quel PC ici. »
Le témoignage de Stuber est éclairant sur son avantage principal : le serveur de données dédié permet d’avoir un serveur d’infocentre indépendant du mainframe. Il suffisait pour cela de mettre en place la procédure et le traitement permettant de « déverser » les données utiles (stockées dans un SGBD traditionnel le plus souvent) depuis le mainframe vers la machine base de données.
Mais alors, si ce concept était si pratique, pourquoi Britton-Lee n’a-t-il pas prospéré (et Teradata est de son côté resté un fournisseur cantonné dans une niche : les très grosses bases de données) ?
Tout d’abord parce que ces solutions étaient coûteuses (voire même très coûteuses dans le cas de Teradata) et que leur avantage initial en matière de performances n’est pas resté valide longtemps face aux progrès constants des serveurs Unix issus du secteur des stations de travail (ceux-ci évoluant sans cesse et très vite… des machines conçues et fabriquées sur mesure en petites quantités ne pouvaient pas suivre face à des machines polyvalentes produite en masse).
Ensuite parce que les logiciels de SGBDR ont progressés. Donc, au tournant des années des années 90, un serveur Unix équipé d’Oracle, Informix et Ingres présentait à peu près le même potentiel de performances qu’une serveur Britton-Lee avec, en plus, l’avantage de la polyvalence (le serveur Unix pouvait être recyclé pour un autre type d’application, réutilisation impossible avec une machine base de données), le tout pour moins cher.
Maturité et lutte commerciale
Un début de maturité du marché commence à voir le jour au début des années 90 et, en dehors du monde fermé d’IBM, la lutte commerciale se résume à un affrontement entre Oracle, Informix et Ingres (plus quelques autes éditeurs de moindre importance et qu’on a oublié depuis…). Chacun de ses trois acteurs se dispute sur le thème « c’est moi qui suis le plus relationnel de tous ! » et chacun se contente de jouer sur le terrain du décisionnel (les SGBDR sont encore considérés comme bien trop lents pour être utilisés pour des applications de production).
Sybase fut le premier éditeur de SGDR à aller jouer sur le terrain du transactionnel. L’idée de Mark Hoffman, Bob Epstein, les fondateurs de la société, était de faire l’équivalent logiciel d’une machine dédiée aux bases de données mais sans ses inconvénients. Le résultat fut SQL Server qui ouvrit une nouvelle voie pour les SGBDR. SQL Server est véritablement le premier SGBDR moderne : il est doté d’innovations techniques internes qui font la différence comme les procédures stockées et les déclencheurs. Il est aussi fourni avec des librairies dynamiques qui permettent le développement d’applications sans avoir à passer par un pré-compilateur.
Cette modernité a séduit Bill Gates qui passe un accord avec Sybase pour porter SQL Server sur OS/2 (et sur Windows NT par la suite, l’accord permet aussi à Microsoft d’utiliser le nom « SQL Server » et la firme de Redmond va en faire un tel usage que Sybase préférera renommer son produit par la suite pour éviter les confusions…).
Sybase ne fut pas seule à s’engoufrer dans la brêche et c’est Oracle qui en consolida sa position en devenant N°1 du secteur dès le début des années 90. Les « anciens » acteurs de ce marché comme Cullinet ou ADR était poussé vers la sortie (le plus souvent rachetés par CA justement !) et seul IBM put rester un acteur significatif de ce marché avec son offre traditionnelle (IMS) allant de pair avec son offre relationnelle (DB2).
Informix su trouver une niche en s’embarquant au sein de nombreux progiciels destinés à des petites machines Unix mais Ingres fut la principale victime de cette lutte commerciale, pourquoi ?
Le rachat infructueux par ASK n’aida certainement pas à ce que le produit pionnier trouve son marché mais il semble que ce soit surtout par ambition qu’Ingres se soit perdu en chemin : pour retrouver un avantage en performance face à Oracle et Sybase, Ingres inc consacra beaucoup de ses ressources à un projet mené conjointement avec Sequent (un constructeur de minis spécialiste des traitements faisant appel à de multiples processeurs fonctionnant en parallèle). Le projet avec Sequent consomma de l’argent mais fut long à déboucher. Finalement, Ingres fut obligé d’arrêter les frais et c’est Informix qui récupéra la mise en remplaçant Ingres au pied levé auprès de Sequent !
Le rachat par Computer Associates fut la touche finale dans ce long processus de mise à mort… Contrairement à ses habitudes, le management de CA voulait garder les programmeurs d’Ingres car ils avaient été duement prévenus que des spécialistes du noyau d’un SGBDR ne courraient pas les rues… Mais le management très « côte est » de CA s’accomodait mal de la décontraction et des moeurs de l’équipe de développement très « cote ouest » d’Ingres et CA commit l’erreur fatale : exiger des programmeurs qu’ils signent une clause de non-concurrence s’ils voulaient que leur contrat soit transféré sous la bannière CA… Une précaution qui semblait logique dans le cadre d’une gestion rigoureuse mais qui provoqua la fuite de l’équipe qui était alors courtisée par tous les concurrents (on raconte même qu’Oracle faisait tourner des mini-bus aux couleurs d’Oracle autour de l’immeuble d’Ingres pour proposer des contrats aux sortants !).
Sans équipe de développement pour le maintenir et le faire évoluer, Ingres ne survit pas longtemps au sein du catalogue de Computer Associates… Un rachat pour rien ou presque !
Informix racheté par IBM en avril 2001, Sybase un peu effacé, c’est désormais Microsoft qui reste pour donner la réplique à Oracle, solide leader de ce secteur désormais bien mature (nous évoquerons l’épisode MySQL dans la section consacrée à l’Open Source).