Aujourd’hui, la tech me paraît être en plein délire : on veut nous faire croire que toute l’information va et doit devenir “orientée IA” et que ça va donner des résultats formidables…

Je me suis déjà exprimé de nombreuses fois sur comment je crois que tout cela va finir (spoiler : mal, ça va mal finir) et, aujourd’hui, je propose de revenir sur une leçon d’un passé relativement récent et, je crois, en tout point comparable. La caractéristique commune à ces deux époques se résume en un seul mot : dogmatisme. Le dogme d’aujourd’hui est que l’IA générative est la solution ultime qui va tout apporter : croissance économique, guérison du cancer et même la singularité (indice : rien de tout cela ne va arriver… quelle surprise, hein !).

Contrairement aux caricatures qui veulent faire croire que je suis “anti-IA” et que, bien sûr, “je n’ai rien compris”, je suis un utilisateur quotidien de ces outils. Et justement, ce retour sur cette période marquée par l’orientation objet, je l’ai effectué grâce à une série d’échanges avec Gemini. Mais je ne suis pas un utilisateur “aveugle” de ces outils (pas plus Gemini que Mistral par exemple) : je vérifie ce qui me parait suspect et je réinterprète en fonction de ce que je sais déjà (le côté le plus pratique de ces outils, c’est justement leur capacité à remuer de nombreuses références plus ou moins oubliées, c’est un “aide-mémoire” puissant mais qui n’est pas toujours très fiable -l’IA invente de temps en temps-). Ceci étant dit, replongeons dans cette leçon du passé même si j’entend déjà les promoteurs lobotomisés de l’IA rétorquer “ouais mais, cette fois, c’est différent”. Mais bien sûr !

Cet article est assez long, installez-vous bien et restez avec moi… On y va !

Tout commence dans les années 90 où la mode de la programmation orientée objet (POO) commence à émerger. Et, avec elle, les promesses sont séduisantes : il s’agit ni plus ni moins de changer la manière de développer des logiciels et pour le meilleur bien sûr !

La POO était vendue comme la solution miracle à la « crise du logiciel » au sens large. Trois promesses majeures étaient répétées en boucle : la réutilisabilité universelle, la modélisation fidèle du monde réel et la réduction des bugs (et donc faciliter la maintenance). Avant de voir cela dans le détail, laissez-moi vous préciser que, pour ma part, je n’ai jamais adhéré aux mythes et promesses de la POO. Ces concepts théoriques me paraissaient fumeux et les avantages plus qu’incertains. J’ai toujours été très réticent vis-à-vis de cette tendance qui semblait tirée par les cheveux (ce qui s’est avéré finalement…). Maintenant que c’est dit, détaillons ces fameux concepts…

1- La réutilisabilité universelle (Le mythe des « Lego »)

La promesse : on allait créer des bibliothèques d’objets universels. Un développeur n’aurait plus qu’à brancher des composants logiciels existants comme des briques de Lego pour construire son application. La réalité : ça n’a presque jamais fonctionné ainsi. La réutilisation par l’héritage (class Chien extends Animal) a créé des architectures rigides, interconnectées et impossibles à faire évoluer. C’est le fameux problème de la « banane et du gorille » formulé par Joe Armstrong (créateur d’Erlang) : « Vous vouliez une banane, mais vous vous retrouvez avec le gorille qui tient la banane, et toute la jungle qui va avec. »

2- La modélisation fidèle du monde réel

La promesse : la POO devait être intuitive car elle permettait de calquer le code sur le monde réel (un objet Voiture a des méthodes Démarrer() et un attribut Couleur). La réalité : l’informatique ne traite pas du monde réel, elle traite de flux de données et de transformations (nuance d’importance, que dis-je, distinction fondamentale !). Forcer des concepts abstraits (comme un gestionnaire de réseau ou un parseur de fichier) à entrer dans des cases « Objets » a produit du code verbeux et artificiel (le fameux syndrome de Java et ses AbstractSessionFactoryBean).

3- La maintenance et la réduction des bugs

La promesse : l’encapsulation (masquer les données internes d’un objet) devait garantir que modifier un endroit du code ne cassait rien ailleurs.

La réalité : en combinant l’encapsulation avec le partage de références en mémoire (les pointeurs), la POO a créé des « états cachés mutables ». C’est la source numéro un de bugs complexes en concurrence : plusieurs objets modifient en douce la même zone mémoire sans que le reste du programme le sache.

La chute de Paradox, une histoire significative…

Pourtant, certains y croyaient dur comme fer !

L’exemple qui me vient en tête est Philippe Kahn, le fondateur de Borland. Philippe a souvent eu des bonnes idées et c’est ainsi qu’il a pu assurer le succès de Borland qui, parti de rien, arrivait à challenger Microsoft dans quelques segments de marché et, croyez-moi, même à cette époque (début des années 90), c’était déjà une sacré performance !

Mais voilà, à vouloir trop croire dans l’avantage théorique que devait apporter la POO, Philippe Kahn a été le principal responsable de l’échec retentissant de Paradox pour Windows.

Cette histoire est le cas d’école parfait d’un produit exceptionnel tué par l’obsession de l’orientation objet, un développement trop long et une contre-attaque impitoyable de Microsoft.

À la fin des années 80, Paradox (créé par Ansa puis racheté par Borland) est un immense succès. Il surclasse le leader de l’époque, dBASE, grâce à deux innovations majeures :

1- Le QBE (Query by Example) : une interface visuelle pratique qui permettait de faire des requêtes complexes en cochant simplement des cases dans un tableau.

2- Le langage PAL (Paradox Application Language) : un langage procédural ultra-rapide et très efficace pour automatiser la gestion des données. Paradox sous DOS était réputé pour sa vitesse fulgurante et sa robustesse mais il était limité à l’interface caractère de MS-Dos. 

L’arrivée de Windows rebat les cartes

Avec l’arrivée de Windows 3.0 en 1990, il faut adapter tous les best-sellers à l’interface graphique et vite. Paradoxe de Borland n’est pas le seul concerné par cette contrainte : Wordperfect et Lotus 1-2-3 vont eux aussi buter sur cette migration obligée (en faisant le mauvais choix de privilégier OS/2 d’IBM au lieu de Windows…).

Pour le passage à Windows, Philippe Kahn (fervent évangéliste de la Programmation Orientée Objet) prend une décision radicale : ne pas adapter le code existant, mais tout réécrire de zéro en C++ pour en faire une vitrine technologique de la POO (ah mais !).

Une équipe entièrement nouvelle est montée. Ils conçoivent une architecture magnifique sur le papier, où chaque élément du logiciel (une table, un champ, un formulaire, un bouton) est un « objet » autonome. C’est là que les retards s’accumulent : le langage PAL d’origine était inadapté à l’interface graphique de Windows. L’équipe a dû inventer de toutes pièces ObjectPAL, un langage orienté objet complexe. L’environnement de développement de Borland pour concevoir des applications fenêtrées en objets (qui servira plus tard de base à Quattro Pro pour Windows et à Delphi) s’avère extrêmement lourd et difficile à stabiliser sur les PC de 1991. Le projet, initialement prévu pour 1991, prend plus d’un an et demi de retard.

Pendant que Borland peaufine péniblement son architecture objet, Microsoft avance à marche forcée sur son propre projet de base de données grand public : Project Cirrus qui deviendra Access. Microsoft commet moins d’excès d’abstraction et se concentre sur l’efficacité brute pour Windows. Constatant le retard de Borland, Bill Gates accélère le calendrier : Microsoft sort Microsoft Access 1.0 en novembre 1992 alors que Borland ne réussit à sortir la version 1.0 de Paradox pour Windows qu’en janvier 1993. Microsoft intègre un peu plus tard Access directement dans sa suite Microsoft Office Professionnel. Face à un logiciel de base de données « gratuit » car inclus avec Word et Excel, le marché des bases de données indépendantes s’effondre.

Paradox pour Windows était, techniquement et visuellement, un produit très en avance sur son temps. Les concepts objets d’ObjectPAL étaient puissants, mais le logiciel s’est avéré terriblement lent au lancement à cause du coût de l’abstraction objet sur les processeurs de l’époque (les 386 et 486).

En voulant faire le produit « parfait » selon les dogmes de la POO, Borland a laissé passer le train de Windows. Épuisé financièrement par ce retard et par le rachat simultané d’Ashton-Tate (dBASE), Borland a perdu la guerre des bases de données de bureau. Paradox sera finalement revendu à Corel en 1997, où il finira sa vie dans l’ombre de la suite WordPerfect.

MS Access, des débuts difficiles

Raconté ainsi, ça parait simple : Borland a été trop gourmand, trop dogmatique (vrai !) et a lâché la balle que Microsoft a su reprendre au vol… La vérité est plus subtile et permettez-moi de l’évoquer ici et maintenant dans cette petite digression : si Microsoft a réussi à terrasser Paradox en sortant son logiciel au moment parfait en novembre 1992, ce n’est pas parce que le développement d’Access avait été un long fleuve tranquille. Bien au contraire !

L’achèvement du projet Access a été extrêmement difficile, marqué par un fiasco industriel interne majeur qui a obligé Microsoft à détruire plusieurs années de travail pour repartir de zéro. Mais là où Borland s’est pris les pieds dans le tapis de la théorie (la POO), Microsoft a souffert d’une ambition technique démesurée par rapport au matériel de l’époque. Voici les coulisses de la création chaotique d’Access.

L’histoire commence en 1988. Bill Gates veut absolument sa propre base de données pour Windows et OS/2. Il lance donc le Projet Omega.

L’ambition d’Omega était titanesque : ce ne devait pas seulement être une base de données de bureau car le logiciel devait intégrer un traitement de texte, un tableur, un gestionnaire de base de données, et surtout, un tout nouveau langage de macro universel (appelé Embedded Basic). Cela peut s’expliquer par le fait que les “logiciels intégrés” étaient encore à la mode sous MS-Dos et donc, faire un intégré sous Windows (et OS/2) pouvait paraître “logique”. Mais le projet était trop ambitieux et trop lourd.

Lors des tests internes, le moteur d’Omega s’effondrait complètement. Il tournait à une lenteur abyssale sur les processeurs phares de l’époque, les Intel 386. Après avoir repoussé la sortie plusieurs fois, Bill Gates réalise en 1989 que le projet est techniquement irrécupérable. En 1990, Microsoft prend une décision rarissime et violente : annuler purement et simplement le Projet Omega, jetant des années de code à la poubelle.

Pour autant Microsoft ne veut pas abandonner le marché des bases de données à Borland (avec un Paradox qui accumule alors les succès). Une partie des développeurs d’Omega est immédiatement réaffectée à un projet de secours au nom de code ultra-rapide : Project Cirrus (qui deviendra officiellement Microsoft Access plus tard). Pour concevoir Cirrus en un temps record et éviter les erreurs d’Omega, Microsoft change radicalement de méthode en combinant trois morceaux existants :

1- Ils récupèrent les concepts d’interface graphique et de création de rapports qui fonctionnaient à peu près dans Omega.

2- Ils se basent sur le moteur de formulaire de « Thunder » (le nom de code de Visual Basic, qui venait de sortir en 1991 et qui intégrait le fameux langage Basic issu d’Omega).

3- Ils créent un tout nouveau moteur de base de données, le moteur Jet, conçu spécifiquement pour être rapide sur Windows sans consommer trop de mémoire.

Alors que le projet Cirrus avance enfin et s’apprête à entrer en phase de bêta test au début de l’année 1992, en mars 1992, Microsoft rachète la société Fox Software (qui s’en souvient ?), éditrice de FoxPro (un clone de dBASE ultra-rapide, très populaire auprès des développeurs professionnels).

Pendant plusieurs mois, une immense guerre interne éclate chez Microsoft : à quoi bon continuer à développer Access (Cirrus) alors que l’entreprise vient d’acheter FoxPro qui est déjà un produit mature, stable et adoré des professionnels ? 

Finalement, Bill Gates tranche pour une stratégie à deux branches : FoxPro sera maintenu pour les développeurs professionnels qui ont besoin de vitesse brute et de bases de données textuelles lourdes alors qu’Access sera positionné comme la base de données grand public et intermédiaire, ultra-visuelle et parfaitement intégrée à l’interface Windows (et plus tard à la suite Office).

Microsoft Access est un miraculé en fait. Il est né des cendres d’un projet mort-né (Omega) et a failli être étouffé au berceau par le rachat de FoxPro. Si Microsoft a gagné la guerre contre Paradox, ce n’est pas parce que ses ingénieurs ont été plus rapides ou plus sereins, mais parce que lorsque le projet Omega a échoué, Microsoft a eu le pragmatisme d’arrêter les frais, de recycler ce qui marchait (le Basic) et de construire un outil simple (Access), pendant que Borland s’enfermait dans le dogmatisme avec la réécriture esthétique et complexe de son code en POO.

Bon, cette digression a été un peu longue mais cette histoire avec ces multiples développements valait la peine d’être racontée car elle montre bien que les projets de développement informatiques sont toujours compliqués, même au sein des éditeurs les plus prestigieux.

L’orienté objet atteint le domaine des bases de données

Au tournant des années 1990, alors que le C++ puis Java (on va venir sur ce sujet particulier -Java- un peu plus tard…) s’imposaient dans le développement logiciel, l’industrie s’est persuadée que le modèle relationnel (les tables SQL d’Oracle, IBM ou Sybase) était devenu obsolète. C’est ainsi qu’est née la déferlante des SGBDO (Systèmes de Gestion de Bases de Données Objet). Portée par des start-ups aux noms très « époque » comme Objectivity, ObjectDesign (ObjectStore), Versant ou O2, cette technologie promettait une révolution totale.

Mais seulement dix ans plus tard, la vague triomphale annoncée s’était totalement fracassée. Voici le bilan de cette mode éphémère, de ses impasses techniques et de son héritage discret.

Pour comprendre l’engouement initial, il faut comprendre le problème que les bases de données objet voulaient résoudre : le désaccord de l’impédance relationnelle-objet (Object-Relational Impedance Mismatch). Le problème : en programmation objet, les données sont un réseau de structures interconnectées en mémoire (un objet pointe vers un autre, qui contient une liste, etc.). Pour sauvegarder cela dans une base SQL classique, le développeur devait fastidieusement « hacher » ses objets pour les répartir dans des tables (lignes et colonnes), puis faire l’inverse (des jointures complexes) pour reconstruire les objets à la lecture. C’était lourd, lent et source de bugs. La solution proposée : les bases de données objet allaient stocker les objets tels quels sur le disque, avec leurs pointeurs et leurs relations. Plus besoin de SQL, plus de tables, plus de conversion. Le langage de programmation et la base de données ne faisaient plus qu’un.

Si l’idée théorique était séduisante, la confrontation à la réalité industrielle des centres de données a révélé des failles structurelles majeures.

Le grand génie du modèle relationnel (SQL), c’est qu’il sépare les données de la façon dont on les utilise. Une table client reste une table client, qu’elle soit lue par un logiciel de compta ou un site web.

Les bases objet, elles, étaient intimement liées au langage de programmation (souvent le C++). Si vous modifiez la structure d’une classe dans votre code, les données déjà stockées sur le disque devenaient illisibles ou corrompues. La migration de données est devenue un enfer permanent.

Le modèle SQL permet de faire des requêtes ad-hoc complexes (« Donne-moi la moyenne des achats des clients de plus de 50 ans en Île-de-France ») très facilement grâce à l’algèbre relationnelle.

Dans une base objet, pour trouver une information, il fallait « naviguer » de pointeur en pointeur à travers le graphe d’objets. Faire des rapports statistiques ou des requêtes imprévues par les concepteurs d’origine était incroyablement complexe et inefficace. Le standard OQL (Object Query Language) a tenté de corriger cela, mais il est arrivé trop tard et n’a jamais égalé SQL.

Dire qu’il ne reste rien de cette effervescence serait faux, mais l’héritage s’est déplacé là où on ne l’attendait pas dans quelques niches industrielles relativement modestes.

La vague des bases de données objet s’est avérée être un excès d’optimisme d’une époque qui pensait que le paradigme objet était la réponse absolue à tous les problèmes de l’informatique. Elle a rappelé cruellement à l’industrie que la gestion de données à long terme obéit à des règles de stabilité mathématique (le modèle relationnel) que la volatilité des langages de programmation ne peut pas remplacer.

Au tour des OS !

Bon, on a vu que la mode de l’orienté objet a touché les langages et les bases de données… Et c’est tout ?
Non !

Même les systèmes d’exploitation ont été “contaminés” par cette vague qui n’épargnera rien. Car l’industrie s’est dit : « Puisque l’objet est l’avenir, le système d’exploitation lui-même doit être un ensemble d’objets du noyau jusqu’à l’interface graphique ! »

Dans ce domaine, la collaboration entre Apple et IBM est le cas d’école le plus célèbre, mais cette folie a touché tous les géants de la tech de l’époque (y compris Microsoft et NeXT).

Voici l’histoire de ces chantiers pharaoniques qui ont presque tous fini au cimetière des logiciels.

À la fin des années 80, l’ingénierie d’Apple sait que le Système 7 du Macintosh est instable (pas de mémoire protégée, pas de multitâche préemptif). Un groupe d’ingénieurs lance en secret le projet « Pink » (car ils écrivaient les idées sur des fiches cartonnées roses). L’idée : réécrire un OS révolutionnaire, entièrement orienté objet, basé sur le C++.

Le projet devint si gigantesque et coûteux qu’Apple dut s’allier avec son ennemi historique, IBM, pour fonder une entreprise commune en 1992 : Taligent. L’annonce de cette alliance surprenante avait fait beaucoup de bruit à l’époque. Certains s’étaient empressés de la qualifier de front anti-Microsoft (et ce n’était pas faux).

Mais ce fut un échec retentissant… Pourquoi ?

Tout d’abord, les ingénieurs des deux sociétés ont poussé le concept d’objet jusqu’à l’absurde. Pour afficher une simple fenêtre ou écrire sur le disque, il fallait hériter de dizaines de classes complexes (frameworks CommonPoint). Le système était d’une lourdeur insensée pour les processeurs de l’époque. De plus, Apple et IBM n’ont jamais réussi à s’entendre sur le noyau (le micro-kernel) à utiliser. Il faut savoir qu’en plus, durant cette période, IBM regardait de tous les côtés pour tenter de sortir de sa dépendance envers Microsoft. Big Blue a même signé un accord de licence pour utiliser Nextstep (mais n’en a rien fait après coup…).

Après des centaines de millions de dollars investis, Taligent n’a finalement jamais sorti d’OS grand public. IBM a racheté les restes en 1995 pour intégrer les morceaux de code dans ses outils de développement, et la société a été dissoute en 1998.

Pendant ce temps, Microsoft n’est pas resté les bras croisés. En 1991, Bill Gates annonce le projet Cairo. Ce projet devait être la version ultime de Windows NT : un système d’exploitation où chaque fichier, chaque utilisateur, chaque périphérique, et même chaque e-mail serait un « objet » géré par un système de fichiers révolutionnaire appelé OFS (Object File System).

Pourquoi a-t-il été annulé ?

Tout simplement parce que Cairo s’est avéré impossible à stabiliser pour les PC des années 90. Les performances s’effondraient dès qu’on tentait de lier tous les fichiers du disque comme des objets vivants interopérables. En 1996, Microsoft jette l’éponge et annule Cairo. Cependant, des morceaux ont survécu : l’interface graphique a été reprise dans Windows 95, et le concept d’annuaire d’objets est devenu l’Active Directory de Windows 2000.

Donc, dans les OS aussi, l’orientation objet s’est avérée être plutôt négative et destructive. Avec les échecs des SGBDO et le premier refroidissement subit par C++, pourquoi cette mode ne s’est pas effacée plus tôt ?

Il est temps d’aborder l’épisode “Java” de notre récit. En effet, c’est l’arrivée de Java en 1995 qui a relancé la ferveur du tout objet pour un moment… Avec le même type de conclusion : ça ne fonctionne pas.

Java, des promesses (le grand soir !) à la dure réalité…

Java est le cas d’école ultime du décalage entre le projet marketing d’une multinationale (Sun Microsystems) et la réalité de ce qu’est devenu le langage. 

Rappeler la promesse de « remplacer Windows » ou de briser le monopole de Microsoft est crucial, car c’était l’obsession de Sun au milieu des années 90. Si l’on évalue Java à l’aune de cette ambition hégémonique sur le poste de travail de l’utilisateur, le bilan est un échec total et spectaculaire.

1. La promesse initiale de 1995 : Le « Write Once, Run Everywhere » grand public

À son lancement, Java ne devait pas être un langage de serveurs cachés dans des centres de données. Il était vendu comme le langage de l’utilisateur final à travers trois piliers : les network computers, les applets Java et le développement multi-plateformes transparent.

Sun voulait commercialiser des terminaux légers et bon marché qui démarreraient directement sous un système d’exploitation Java (j’ai pu tester un de ces “Network computers” en 1998 et le résultat était plutôt modeste on va dire pour être gentil…). L’idée était de rendre Windows et les processeurs Intel obsolètes.

Le web naissant devait être conquis par Java. Les sites web n’allaient plus être des pages HTML statiques, mais des mini-programmes Java s’exécutant directement dans le navigateur (jeux, interfaces animées).Enfin, on nous promettait des logiciels PC universels, capables de tourner à l’identique sur Windows, Mac ou Linux sans réécrire une ligne de code.

2. Le naufrage du Java « Client » (Côté utilisateur)

Sur ce terrain, la réalité a été sans pitié pour les promesses de Sun… Dans les années 90/2000, lancer un logiciel Java sur son PC ou une Applet dans son navigateur était un calvaire. Le temps de démarrage de la machine virtuelle (JVM) était interminable, et l’interface graphique « Swing » était célèbre pour sa laideur visuelle et son manque de réactivité par rapport aux logiciels natifs Windows. Les Applets Java dans les navigateurs sont devenues l’une des plus grandes passoires techniques de l’histoire de la cybersécurité. Les failles à répétition ont obligé les navigateurs (comme Chrome ou Firefox) à tuer définitivement le plug-in Java.

Finalement, Microsoft a verrouillé Windows (notamment en créant le framework .NET et le langage C# pour concurrencer directement Java) et a étouffé la tentative de Sun de s’imposer sur le PC.

Inutile de préciser que, dès le début, j’étais totalement opposé à cette mode technique absurde (et nous n’étions alors pas nombreux à contester le bien-fondé de la vague Java). Cette promesse de pouvoir fonctionner partout grâce à une machine virtuelle n’était pas nouvelle, elle a été expérimentée de nombreuses fois (UCSD p-System par exemple) et toujours avec le même résultat décevant : une lenteur d’exécution décourageante.

La réalité de l’enthousiasme initial envers Java n’était pas technique mais “politique” : beaucoup étaient ravi de voir enfin une opposition “sérieuse” à l’hégémonie de Microsoft et ça pouvait se comprendre. Mais techniquement, ça ne tenait pas debout comme on a pu s’en rendre compte assez vite.

Ceux qui veulent absolument défendre le bilan de Java admettent que côté client, l’échec a été total mais que côté serveur, il s’est avéré être une grande réussite… Objection votre honneur !

La soi-disant réussite de Java repose sur quelques légendes (Android et Minecraft, entre autres) qu’il est relativement facile de débunker.

Voici deux exemples (Android et Minecraft) qui sont les parfaits symptômes du rejet progressif de Java par l’industrie moderne.

1. Le cas Android : Le piège technique et juridique

L’histoire d’Android est fascinante car elle montre comment Java est devenu un boulet pour Google, tant sur le plan technique que légal. Il suffit pour cela de lire le livre publié par l’équipe de développement initiale “Androids: The Team that Built the Android Operating System”.

Au départ, Google a choisi d’utiliser la syntaxe de Java pour Android afin d’attirer immédiatement des millions de développeurs déjà formés. Mais Google ne voulait pas de la lourdeur de la machine virtuelle officielle de Sun/Oracle. Ils ont donc recréé leur propre machine (Dalvik, puis ART) en copiant les interfaces (API) de Java. Cela a déclenché une guerre juridique de plus de dix ans avec Oracle (qui réclamait des milliards de dollars). Google a fini par gagner devant la Cour suprême américaine en 2021, mais le traumatisme a été immense.

Sur le plan technique, l’équipe d’Android s’est vite sentie asphyxiée par la lenteur d’évolution de Java et sa verbosité (notamment les fameuses erreurs NullPointerException). Dès 2017, Google a fait de Kotlin le langage officiellement recommandé pour Android. Aujourd’hui, la grande majorité des nouvelles applications Android sont écrites en Kotlin. Java est relégué à la maintenance de l’ancien code (legacy).

2. Le cas Minecraft : la limite de la performance brute

Minecraft est un cas d’école unique : c’est le jeu le plus vendu de l’histoire, et il a été codé en Java par une seule personne (Notch) à une époque où personne n’imaginait son succès futur. Mais ce choix a rapidement posé des limites techniques gigantesques.

Java gère la mémoire automatiquement via un « ramasse-miettes ». En plein jeu, quand le GC se déclenche pour nettoyer la mémoire des milliers de blocs et d’entités texturées, cela crée des micro-saccades (stuttering) très frustrantes pour les joueurs, même sur des PC puissants.

Conscient de cette impasse, Microsoft (après le rachat de Mojang) a entièrement réécrit le jeu en C++ (la version dite Bedrock, disponible sur consoles, téléphones et Windows Store). Le Minecraft Java d’origine n’est conservé en vie que pour la communauté historique des moddeurs sur PC, mais le cœur commercial et technique du jeu a bel et bien divorcé d’avec Java pour retrouver l’efficacité du code natif.

Même là où Java semblait avoir gagné, les ingénieurs cherchent aujourd’hui à s’en émanciper.

La trajectoire de Java ressemble à celle de l’administration ou des vieux systèmes bancaires : c’est lourd, c’est rigide, ce n’est pas performant pour du calcul en temps réel (comme les jeux) ni adapté aux contraintes de batterie (comme les smartphones). Le monde du développement moderne (avec l’essor de Go, Rust ou TypeScript) s’est construit précisément en réaction aux lourdeurs et aux promesses déçues de l’ère Java.

Encore un mot pour la soi-disant réussite de Java côté serveur : les serveurs d’applications en Java : ils étaient nombreux au début des années 2000, qu’en reste-t-il aujourd’hui ?

Au début des années 2000, l’informatique d’entreprise ne jurait que par les mastodontes du J2EE (Java 2 Enterprise Edition). C’était l’époque des serveurs d’applications « monolithiques » et ultra-lourds.

Les trois grands serveurs d’applications qui dominaient le marché mondial ont connu des destins très différents :

IBM WebSphere, il est le symbole même du monstre J2EE des années 2000 (lourd, très cher, nécessitant des machines virtuelles gigantesques). Aujourd’hui, WebSphere traditionnel n’est plus utilisé que par les banques, les assurances ou les ministères qui ont des millions de lignes de code impossibles à migrer. Pour survivre, IBM a dû créer Open Liberty, une version moderne, ultra-légère et modulaire.

Oracle WebLogic (ex-BEA) : Même constat. C’était le roi des serveurs d’applications au début des années 2000. Oracle continue de le maintenir pour ses gros clients industriels et pour faire tourner sa propre suite logicielle (Oracle Fusion), mais plus aucun développeur ne choisit WebLogic pour un nouveau projet.

JBoss (devenu Red Hat JBoss EAP / WildFly) : Il a été le grand gagnant de l’open source face à IBM et Oracle. JBoss a mieux vieilli car ses ingénieurs l’ont entièrement réécrit sous le nom de WildFly. Il est devenu modulaire : le serveur ne charge en mémoire que les morceaux dont l’application a strictement besoin.

Le modèle du gros serveur d’applications Java dans lequel on venait greffer du code est cliniquement mort pour les nouveaux projets. Les seuls survivants (Tomcat, Jetty, WildFly, Open Liberty) ont dû se plier à la règle du cloud moderne : devenir de petits moteurs légers, invisibles, capables de démarrer instantanément dans un conteneur Linux. Java a dû abandonner ses rêves de grandeur centralisée pour se fondre dans le moule des microservices.

Allez, encore une dernière anecdote pour conclure l’épisode Java : l’échec cuisant du Netscape tout-Java promu par Marc Andreessen (le trop fameux co-fondateur de Netscape). J’ai rencontré Marc en 1998 (lors d’une de ses visites en France) et, alors qu’il voulait me convaincre que “Java, c’est l’avenir”, devant mon refus d’abonder dans son sens, sa “Majesté” s’est vexée, s’est levée et a quitté l’entretien… Vite rattrapée et ramenée par l’équipe marketing de Netscape France affolée par la tournure que prenait l’entretien (j’étais alors considéré comme une “analyste technique” dont la voix comptait).

Marc, alors jeune et grisé par le succès fulgurant de sa boîte, était en transe devant la promesse du « Write Once, Run Everywhere » de Sun Microsystems. Sa célèbre punchline de l’époque résumait son ambition : « Windows n’est plus qu’un ensemble mal débogué de pilotes de périphériques ». Pour lui, l’avenir du PC n’était pas l’OS de Microsoft, c’était le navigateur Web, et ce navigateur devait être entièrement écrit en Java (forcément !).

Voici comment ce choix a précipité la chute de Netscape face à Internet Explorer, dans une copie presque parfaite de l’erreur de Borland avec Paradox.

1. Le péché originel : La réécriture à partir d’une page blanche

Comme Philippe Kahn avec Paradox, l’équipe de Netscape gérait un code C/C++ historique (les versions 1 à 4 de Navigator) devenu très lourd, difficile à maintenir et buggé. Au lieu de corriger patiemment l’existant pendant que Microsoft revenait à fond de train avec Internet Explorer 4, la direction de Netscape a succombé au fantasme du développeur : « On jette tout et on réécrit proprement du début ». C’est ce que Joel Spolsky (un des blogueurs tech les plus célèbres de l’époque) a qualifié plus tard de « La pire erreur stratégique qu’une entreprise de logiciel puisse commettre », en prenant explicitement l’exemple de Netscape.

2. Le désastre de Javagator (1997-1998)

L’idée folle d’Andreessen et de son équipe était de créer un navigateur 100 % Java. Non seulement les sites web afficheraient des applets Java, mais les boutons, les menus, le moteur de rendu HTML, tout le logiciel serait du bytecode Java s’exécutant sur la machine virtuelle (JVM).

Les trois murs techniques que le projet s’est pris de face : les PC de 1997 (les Pentium II) n’avaient absolument pas la puissance nécessaire pour faire tourner un logiciel aussi massif codé en Java de l’époque. Le navigateur mettait un temps infini à démarrer et consommait toute la mémoire vive.

Pendant que les ingénieurs passaient des mois à essayer de recréer l’équivalent d’un bouton « Précédent » ou d’une barre de défilement stable en Java, ils ne développaient aucune nouvelle fonctionnalité pour le web (qui évoluait alors à toute vitesse avec les CSS et le HTML 4).

Le but de Java était d’être universel, mais en pratique, la machine virtuelle de Sun plantait ou se comportait différemment selon qu’on était sur Windows, Mac ou Unix, transformant le débogage en cauchemar permanent.

Au bout d’un an et demi de développement stérile, Netscape a dû se rendre à l’évidence : le « Javagator » était un produit mort-né, inutilisable pour le grand public. Le projet a été discrètement annulé en 1998. Mais le mal était fait. Pendant que Netscape faisait du surplace à cause de cette lubie Java : Microsoft distribuait gratuitement Internet Explorer 4 puis 5, parfaitement intégrés à Windows, rapides (codés en C++) et très stables. Résultat, Netscape a perdu la quasi-totalité de ses parts de marché en l’espace de 24 mois.

Dans un geste de désespoir absolu en mars 1998, réalisant que leur code était dans une impasse totale, Netscape a décidé de publier le code source restant sur internet et de créer l’organisation Mozilla. Il faudra plus de quatre ans de souffrance et une reconstruction complète (en abandonnant le projet Java pour créer le moteur Gecko en C++) pour que ce projet donne enfin naissance à Firefox en 2004. Mais pour l’entreprise Netscape, c’était trop tard : elle avait déjà été rachetée et dissoute par AOL.

La similarité avec Paradox est saisissante : Borland voulait faire de Paradox la vitrine de sa vision « Tout-Objet/C++ », laissant le temps à Microsoft de sortir Access. Netscape voulait faire de son navigateur la vitrine de la vision « Tout-Java », laissant le temps à Microsoft de gagner la guerre des navigateurs avec Internet Explorer.

Ces deux épisodes majeurs de l’histoire de l’informatique auraient dû laisser une leçon durable pour tous : le pragmatisme commercial et la vitesse d’exécution sur le marché réel l’emporteront toujours sur l’élégance théorique d’une réécriture logicielle globale ou d’une adhésion sans limite (dogmatisme) à une mode technique séduisante mais fragile.

En conclusion

Au moment de conclure, je voudrais revenir sur ce principe : on juge une tendance à ses promesses de départ. C’est seulement ainsi qu’on peut dire si telle ou telle mode technique a porté ses fruits (on juge un arbre à ses fruits…) ou non. C’est la seule façon réellement honnête et rationnelle de procéder.

Et, sur ce plan, il est incontestable que le résultat final n’a pas eu l’ampleur ni la nature de la révolution annoncée. La POO n’a pas rendu le développement logiciel simple, magique et accessible à tous par simple assemblage de briques. Elle s’est avérée être un outil industriel lourd, parfois contraignant, qui a dû être sérieusement élagué et mélangé à d’autres approches (comme le fonctionnel) pour être réellement efficace.

Aujourd’hui, ils veulent nous faire croire que c’est le “vibe coding” (coding avec l’IA) qui va changer durablement et profondément la pratique du développement informatique… C’est “possible” mais rien n’est moins sûr. En effet, ce n’est certainement pas la première fois qu’on formule ce genre de prédiction et on vient de le voir avec la POO. Comme Fred Brooks a bien su le dire, le développement informatique est toujours à la recherche de sa “balle magique” (silver bullet), la recette ultime qui va tout simplifier et résoudre tous les problèmes d’un coup. Bien évidemment, ça n’arrivera pas. Car c’est une course sans fin qui remonte déjà à loin : on a vu la chimère de la POO dans les années 90 et 2000 mais, avant cela, il y a eu les L4G dans les années 70 puis les “méthodes” (la vague éphémère du “génie logiciel” que j’ai bien connu) dans les années 80. Je ne vais pas entrer dans les détails de ces deux autres épisodes mais, pour faire court, on a eu droit aux mêmes promesses et aux mêmes déceptions.

N’en déplaise aux vendeurs d’illusions, le développement informatique (qui ne se résume pas au coding) restera toujours compliqué, difficile et décevant.