Oracle

• Introduction
• Chapitre 1 La genèse d'une idée
• Chapitre 2 De modestes débuts : La jeunesse de Larry Ellison
• Chapitre 3 La naissance de Relational Software, Inc.
• Chapitre 4 Obtenir le premier gros contrat : La CIA
• Chapitre 5 Le jeu des noms : Devenir Oracle
• Chapitre 6 Surfer sur la vague des bases de données : Le boom des années 1980
• Chapitre 7 L'introduction en bourse et le bord de l'effondrement
• Chapitre 8 Le retour du gamin : Restructuration et redressement
• Chapitre 9 La machine de vente implacable
• Chapitre 10 Les guerres des bases de données : Oracle contre Informix et Sybase
• Chapitre 11 L'essor de l'ordinateur réseau
• Chapitre 12 Le personnage hors du commun d'Ellison
• Chapitre 13 Conquérir l'entreprise : La suite E-Business
• Chapitre 14 L'OPA hostile sur PeopleSoft
• Chapitre 15 Acquérir la concurrence : Une stratégie de croissance
• Chapitre 16 Le pari Sun Microsystems : Le matériel et le logiciel s'unissent
• Chapitre 17 Naviguer dans la révolution du cloud
• Chapitre 18 Les batailles juridiques : Conflits avec SAP et Google
• Chapitre 19 L'obsession de l'America's Cup
• Chapitre 20 Au-delà du rôle de PDG : Ellison en tant que CTO et président
• Chapitre 21 La prochaine génération de dirigeants
• Chapitre 22 Oracle à l'ère de l'IA et du Big Data
• Chapitre 23 La culture d'Oracle : Agressive, ambitieuse et durable
• Chapitre 24 Le philanthrope et le propriétaire d'île
• Chapitre 25 L'héritage durable d'un titan américain

Dans le théâtre grandiose et souvent tumultueux de l'entreprise américaine, peu d'histoires sont aussi captivantes, aussi agressives ou aussi fondamentalement transformatrices que celle d'Oracle Corporation. Encore moins sont indissociablement liées à un fondateur aussi charismatique, controversé et inlassablement déterminé que Lawrence « Larry » Ellison. C'est un double portrait : celui d'une entreprise qui a remodelé le paysage numérique en maîtrisant l'art de la gestion des données, et celui de l'homme dont l'ambition, la clairvoyance et la volonté indomptable furent le véritable plan de sa création et de son âme durable, souvent combative. Comprendre Oracle, c'est comprendre les courants mêmes qui ont façonné l'industrie technologique moderne — du monde ésotérique de la gestion de bases de données à la frontière étendue de l'informatique en nuage et de l'intelligence artificielle.

La saga d'Oracle n'est pas simplement une histoire d'entreprise ; c'est un récit tissé dans la toile même de l'ère de l'information. Elle ne commence pas dans un garage, dans la tradition désormais sacralisée du folklore de la Silicon Valley, mais par un article universitaire — une exploration théorique d'une nouvelle façon d'organiser les données. En 1970, un chercheur d'IBM nommé Edgar F. Codd publie « A Relational Model of Data for Large Shared Data Banks », un document qui deviendra la pierre de Rosette pour une nouvelle génération de logiciels. Le modèle relationnel de Codd était élégant, puissant et, à l'époque, largement théorique. Il proposait un système où les données pouvaient être stockées dans de simples tables et les relations entre elles gérées de manière fluide et logique, une rupture nette avec les bases de données hiérarchiques rigides de l'époque. Alors que le géant IBM tardait à reconnaître le potentiel commercial du travail révolutionnaire de son propre employé, un étudiant décrocheur de 33 ans en Californie voyait non pas une théorie, mais une révolution.

Larry Ellison, aux côtés de ses cofondateurs Bob Miner et Ed Oates, prit le concept abstrait de Codd pour le forger en un produit commercial, un outil qui deviendrait le socle de l'entreprise moderne. Ils fondèrent leur société en 1977, d'abord sous le nom de Software Development Laboratories, puis Relational Software, Inc., avant d'adopter finalement le nom de leur produit phare — Oracle. Le nom lui-même faisait référence à un projet précédent sur lequel ils avaient travaillé pour la CIA, une origine à juste titre énigmatique pour une entreprise qui deviendrait maître dans la gestion des informations les plus sensibles et les plus précieuses au monde. Leur produit, Oracle Database, fut le premier système de gestion de base de données relationnelle (RDBMS) disponible commercialement à utiliser le langage Structured Query Language (SQL), qui allait devenir la norme de l'industrie.

L'histoire d'Oracle, cependant, n'est pas celle d'une innovation sereine. C'est un récit de concurrence féroce, de « guerres des bases de données » qui virent des rivaux s'élever et s'effondrer, d'une culture d'entreprise réputée pour ses tactiques de vente sans pitié et une volonté intransigeante de gagner. Ellison cultiva un environnement aussi exigeant que gratifiant, un lieu où le succès se mesurait en parts de marché et en concurrents vaincus. Cette éthique agressive propulsa l'ascension fulgurante de l'entreprise dans les années 1980, l'établissant comme la plus grande société mondiale de logiciels de gestion de bases de données en 1987. Ce fut une période de croissance explosive, où le logiciel Oracle devint le moteur invisible alimentant banques, compagnies aériennes, détaillants et gouvernements à travers le monde.

Pourtant, cet élan implacable mena également l'entreprise au bord du gouffre. Le tournant de la décennie vit Oracle faire face à une expérience de quasi-faillite, une crise née d'une culture de vente trop agressive qui enregistrait des revenus futurs comme des bénéfices actuels. Ce fut un creuset qui mit le leadership d'Ellison à l'épreuve et força une restructuration douloureuse mais nécessaire de l'entreprise. Le retour qui suivit témoigne de la résilience ancrée dans l'ADN d'Oracle, une histoire de redressement et de recentrage qui prépara le terrain pour des décennies de domination.

Aucun portrait d'Oracle ne saurait être complet sans une exploration approfondie de la personnalité hors norme de son fondateur. Larry Ellison est une figure d'une complexité et de contradictions immenses. Milliardaire autodidacte qui figure constamment parmi les individus les plus fortunés de la planète, sa vie est une tapisserie de passions extravagantes, de la course de yachts de compétition et de l'America's Cup à la possession de sa propre île hawaïenne. C'est un technologue visionnaire doué d'une capacité surnaturelle à repérer la prochaine grande vague, mais c'est aussi un dirigeant notoirement dur et parfois polarisant. Son style de direction, souvent décrit comme autocratique et modelé sur les principes des samouraïs, est légendaire dans la Silicon Valley. C'est un style qui a inspiré à la fois une loyauté farouche et de vives critiques, mais son efficacité dans la construction d'une puissance technologique mondiale est indéniable.

L'évolution d'Oracle est aussi une histoire d'adaptation stratégique, souvent par le biais d'acquisitions agressives. Ellison comprit très tôt que pour maintenir sa croissance et sa pertinence, Oracle devait aller au-delà de son produit de base de données principal. Cela conduisit à une série de rachats à hauts risques, souvent hostiles, qui remodelèrent le paysage du logiciel d'entreprise. Les acquisitions de PeopleSoft, Siebel Systems, BEA Systems et Sun Microsystems ne furent pas de simples transactions commerciales ; ce furent des conquêtes stratégiques qui étendirent l'empire d'Oracle vers des domaines critiques comme la planification des ressources de l'entreprise (ERP), la gestion de la relation client (CRM), les intergiciels (middleware) et le matériel informatique. Le rachat de Sun Microsystems, en particulier, fut un pari monumental, donnant à Oracle le contrôle du langage de programmation Java, très populaire, et de la base de données MySQL, et la transformant en une entreprise capable, comme son vieil rival IBM, d'offrir une pile technologique complète et intégrée, du matériel au logiciel.

Alors que l'industrie technologique basculait du logiciel sur site vers le nuage, Oracle fit face à son plus grand défi. Initialement sceptique face à la révolution du nuage, Ellison et Oracle furent perçus comme des retardataires sur un marché dominé par de nouveaux titans comme Amazon Web Services. Pourtant, sous-estimer la capacité d'adaptation d'Oracle, c'est méconnaître son histoire. L'entreprise a depuis investi des ressources immenses dans le développement de sa propre infrastructure en nuage et d'une suite complète d'applications basées sur le nuage, pivotant l'intégralité de son modèle économique pour rivaliser dans cette nouvelle ère. De récents accords massifs avec de grandes entreprises d'IA comme OpenAI signalent une percée spectaculaire et réussie sur ce marché critique, démontrant une fois de plus la capacité de l'entreprise à se réinventer et à défier ses rivaux.

Le récit d'Oracle est également ponctué de batailles juridiques très médiatisées, notamment avec des concurrents comme SAP et Google. Ces affrontements au tribunal offrent une fenêtre sur la nature farouchement compétitive de l'entreprise et sa défense intransigeante de sa propriété intellectuelle. Ce sont des chapitres d'une histoire plus large sur la nature même de l'innovation, de la concurrence et des règles du jeu à l'ère numérique.

Cet ouvrage parcourra ces moments charnières, de la genèse de l'idée de base de données relationnelle à la position actuelle d'Oracle en tant qu'acteur clé de l'ère de l'IA et des mégadonnées. Nous explorerons la jeunesse de Larry Ellison, les forces qui ont façonné son ambition, et comment son dynamisme personnel est devenu la culture d'entreprise de la société. Nous disséquerons les acquisitions clés qui ont défini sa stratégie de croissance, les innovations technologiques qui l'ont maintenu à l'avant-garde de l'industrie, et les controverses qui ont ombre son succès.

Nous examinerons la machine de vente implacable qui a alimenté ses revenus, la personnalité hors norme de son fondateur, et l'héritage durable d'une entreprise qui a été une présence constante et redoutable dans le monde de la technologie pendant près d'un demi-siècle. C'est l'histoire d'un titan de l'industrie américaine, une entreprise souvent aussi honnie que respectée, mais dont l'impact sur la façon dont le monde utilise l'information est simplement indéniable. C'est l'histoire d'Oracle, et de l'oracle qui l'a bâtie.

Toute révolution commence par une seule pensée, souvent hétérodoxe. Dans le monde des technologies de l'information, l'une des révolutions les plus profondes et les plus lucratives a débuté non pas par un produit, une entreprise ou un fondateur charismatique, mais par un article universitaire. Avant Oracle, avant Larry Ellison, il y avait Edgar F. « Ted » Codd. Et avant Codd, il y avait un monde qui peinait à gérer ses données d'une manière fastidieuse, inflexible et fondamentalement défaillante. Pour saisir l'ampleur de l'idée qui allait engendrer une industrie pesant des milliards de dollars, il faut d'abord appréhender le paysage technologique rigide et emmêlé des années 1960.

À l'ère de l'informatique centrale (mainframe), les données étaient reines, mais c'était un monarque retenu captif dans un donjon numérique. Les méthodes dominantes pour organiser l'information étaient les modèles de base de données hiérarchique et en réseau. Ces premiers systèmes constituaient des prouesses d'ingénierie pour leur temps, mais ils étaient notoirement difficiles à manipuler. Le modèle hiérarchique, développé par IBM, organisait les données selon une structure arborescente. Imaginez un organigramme : un enregistrement racine unique au sommet, des branches menant vers des enregistrements « fils », qui pouvaient à leur tour avoir leurs propres enfants. Pour retrouver une information, il fallait partir du sommet et descendre le bon chemin, comme un spéléologue suivant un unique boyau dans une grotte. Il n'existait aucun moyen aisé de sauter d'une branche à l'autre.

Le modèle en réseau constituait une avancée, autorisant un enregistrement « fils » à avoir plusieurs enregistrements « pères », créant ainsi une structure plus reticulaire de pointeurs et de liens. Développé par des innovateurs comme Charles Bachman, ce modèle offrait plus de souplesse que les relations strictes un-pour-plusieurs du système hiérarchique. Pourtant, les deux modèles partageaient un défaut critique : la structure logique des données était indissociablement liée à leur stockage physique sur bandes magnétiques ou disques. Les programmeurs devaient connaître le chemin précis, prédéfini, menant aux données souhaitées. Récupérer une information exigeait d'écrire du code complexe et procédural naviguant dans ces parcours électroniques. Une simple demande pour un nouveau type de rapport pouvait nécessiter un effort de programmation significatif et coûteux.

C'était le monde qu'habitait Edgar F. Codd, un mathématicien britannique de naissance, diplômé d'Oxford, travaillant au San Jose Research Laboratory d'IBM. Codd n'était pas un homme d'entreprise typique. Ayant soutenu une thèse de doctorat sur les automates auto-reproducteurs, son esprit était câblé pour l'élégance mathématique et la pureté logique. Il observait l'état de la gestion de bases de données et n'y voyait pas un défi d'ingénierie, mais une violation fondamentale des principes logiques. Il estimait que l'utilisateur d'une base de données n'avait pas besoin de savoir comment ni où les données étaient stockées physiquement. L'application devait être séparée du stockage. Ce concept, qu'il nomma « indépendance des données », constituait le cœur de sa vision révolutionnaire.

En juin 1970, Codd publia sa vision dans un article qui résonnera pendant des décennies dans les couloirs de l'informatique : « A Relational Model of Data for Large Shared Data Banks ». Le titre était modeste, mais son contenu, sismique. Codd proposait une manière radicalement simple de concevoir les données. Au lieu d'arbres complexes ou de réseaux de pointeurs, les données pouvaient être organisées en tables simples, qu'il appelait « relations ». Chaque table comprendrait des lignes (qu'il nommait « n-uplets » ou tuples) et des colonnes (« attributs »). Chaque ligne représentait une entité unique, comme un employé ou un produit, et chaque colonne une caractéristique de cette entité, comme un nom ou un prix. Le modèle était intuitif ; il ressemblait à une collection de feuilles de calcul.

Le véritable génie du modèle de Codd résidait dans sa gestion des liens entre les données. Les relations n'étaient pas définies par des pointeurs physiques ou des liens hiérarchiques qu'il fallait programmer à l'avance. Elles s'établissaient simplement par les données elles-mêmes. Si la table « Employés » et la table « Départements » contenaient toutes deux une colonne « ID_Département », une relation se formait implicitement. Pour savoir quels employés travaillaient dans quel département, il suffisait de faire correspondre les valeurs de ces colonnes. Cela signifiait que de nouvelles questions ad hoc pouvaient être posées aux données sans réécrire l'application ni restructurer la base. La puissance du système découlait de ses fondements mathématiques dans la théorie des ensembles et la logique des prédicats, qui permettaient une manipulation cohérente et prévisible des tables de données.

L'article de Codd était, en substance, une déclaration d'indépendance pour les données. Il affranchissait la représentation logique de l'information de son implémentation physique. Un programmeur ou un utilisateur pouvait désormais demander ce qu'il voulait, et non dicter comment l'ordinateur devait le trouver. Cette distinction entre instructions déclaratives et procédurales marquait un changement de paradigme monumental. Le travail de Codd était dense, académique, mathématiquement rigoureux. À sa déception, son potentiel commercial n'apparut pas immédiatement à son employeur, IBM.

International Business Machines régnait alors en maître incontesté sur le monde des grands systèmes, et son produit phare de base de données était l'Information Management System (IMS), une puissante base de données hiérarchique classique. IMS générait des revenus significatifs, et l'entreprise y était fortement investie. Le modèle relationnel de Codd était perçu en interne non comme une opportunité, mais comme une menace. On craignait que ce nouveau modèle élégant ne soit trop lent, un gouffre de performance incapable de rivaliser avec l'IMS finement optimisé. Par conséquent, IBM tarda à exploiter les recherches révolutionnaires de son propre employé. Si elle lança bien un projet de recherche nommé System R pour explorer le concept, ce fut un pas hésitant plutôt qu'un saut enthousiaste.

Le projet System R, démarré en 1974 dans le même laboratoire de San Jose où travaillait Codd, s'avéra immensément influent. L'équipe devait construire un prototype prouvant qu'une base de données relationnelle pouvait offrir de bonnes performances transactionnelles. Crucialement, l'équipe en charge du projet n'était pas profondément familiarisée avec les idées de Codd et en était isolée. Cette séparation conduisit à un développement clé. Codd avait proposé son propre langage mathématiquement pur, Alpha, mais l'équipe System R le jugea trop difficile pour des utilisateurs ordinaires.

Deux chercheurs de l'équipe, Donald D. Chamberlin et Raymond F. Boyce, se mirent en quête de quelque chose de plus accessible. Leur objectif : un langage d'interrogation ressemblant à l'anglais courant, utilisable par des personnes sans formation formelle en programmation. Leur première tentative, baptisée SQUARE, s'avéra maladroite. Ils affinèrent leur approche et créèrent un nouveau langage qu'ils nommèrent SEQUEL, pour Structured English Query Language. Il reposait sur des commandes déclaratives simples comme SELECT, FROM et WHERE. Un utilisateur pouvait spécifier les colonnes souhaitées, les tables les contenant et les conditions de filtrage, le tout en une seule instruction cohérente.

SEQUEL, ensuite raccourci en SQL à cause d'un litige de marque avec une entreprise d'ingénierie britannique, était la pièce manquante du puzzle. C'était la clé pratique et conviviale pour déverrouiller la puissance théorique du modèle relationnel de Codd. La combinaison était puissante : une manière simple et flexible de stocker les données, et un langage simple et puissant pour les interroger. Le projet System R démontra avec succès qu'une base de données relationnelle utilisant SQL pouvait être construite et performante, son premier client, Pratt & Whitney, embarquant en 1977.

Pendant qu'IBM prototypait et prouvait le concept en interne avec prudence, l'idée libérée par Codd prenait vie propre dans le monde universitaire. À l'Université de Californie à Berkeley, une autre équipe de chercheurs dirigée par Michael Stonebraker et Eugene Wong avait également lu l'article de Codd de 1970 et s'était inspirée pour construire sa propre base de données relationnelle. Leur projet, démarré en 1973, s'appelait Ingres (Interactive Graphics and Retrieval System). Comme l'équipe System R d'IBM, ils développèrent aussi leur propre langage d'interrogation, appelé QUEL, considéré par de nombreux universitaires de l'époque comme supérieur à SQL par son élégance.

Ainsi, au milieu des années 1970, la scène était plantée. Les fondations théoriques avaient été posées par Ted Codd. Deux grands projets de recherche, l'un chez le premier constructeur informatique mondial, l'autre dans une université de premier plan, prouvaient la viabilité du concept. Un nouveau langage puissant et relativement simple, le SQL, avait été inventé pour interagir avec ce nouveau type de base de données. Pourtant, le monde commercial n'avait pas saisi l'opportunité. IBM, protectrice de ses produits existants, ne commercialisait pas encore sa création de manière agressive. Ingres restait un projet universitaire, accessible à d'autres chercheurs mais pas encore une entreprise commerciale.

Un vide intellectuel existait entre la théorie académique et un marché commercial massif et inexploité. L'article de Codd et les travaux sur System R n'étaient pas secrets ; ils étaient publiés et présentés en conférences. Les détails du modèle relationnel et la structure du langage SQL étaient en accès libre. Il ne manquait plus que quelqu'un possédant la combinaison adéquate de flair technique, d'ambition entrepreneuriale et de volonté de parier sur l'idée d'autrui pour voir l'opportunité. La genèse était achevée. L'idée attendait un évangélisateur, un bâtisseur et un vendeur. Elle attendait Larry Ellison.