Code IA interdit dans OpenJDK : la décision choc d’Oracle

Pourquoi le gardien de Java bannit le code généré par IA, tout en misant 70 milliards de dollars sur cette même technologie

Imaginez une entreprise qui investit chaque année des dizaines de milliards de dollars dans l’intelligence artificielle, dont le cofondateur clame haut et fort que « l’IA écrit désormais notre code »… et qui, dans le même temps, interdit formellement à des milliers de développeurs bénévoles d’utiliser cette même IA pour contribuer à l’un de ses projets les plus stratégiques. Ce grand écart n’est pas une caricature : c’est exactement ce que vient de faire Oracle avec OpenJDK, le projet open source qui constitue le cœur battant du langage Java.

Si les mots « OpenJDK », « Skara » ou « OCA » ne vous disent rien, pas de panique : on va tout décortiquer, étape par étape, avec des mots simples. À la fin de cet article, vous comprendrez non seulement ce qu’Oracle a décidé, mais aussi pourquoi cette décision fait grincer des dents jusque dans les couloirs de l’entreprise elle-même.

D’abord, c’est quoi OpenJDK ? (et pourquoi ça vous concerne peut-être sans le savoir)

Java est l’un des langages de programmation les plus utilisés au monde : il fait tourner une bonne partie des systèmes bancaires, des applications Android, des logiciels d’entreprise et même certains équipements industriels. OpenJDK, c’est le projet open source qui développe le JDK (Java Development Kit) autrement dit, l’implémentation de référence de Java elle-même, celle sur laquelle s’appuient ensuite toutes les autres versions du langage.

ℹ️  Implémentation de référence, ça veut dire quoi ? C’est la version « officielle », celle qui sert de modèle à toutes les autres. Un peu comme le mètre étalon conservé à Paris a longtemps servi de référence pour tous les mètres du monde entier : si le code de base d’OpenJDK contient une faille ou un bug, c’est potentiellement des millions d’applications, partout dans le monde, qui héritent du problème.

Vous comprenez donc pourquoi la moindre ligne de code ajoutée à ce projet est examinée avec une rigueur presque chirurgicale. C’est précisément ce souci de rigueur qui est au cœur de la décision qu’on va détailler.

La décision d’Oracle, en clair

Au début du mois d’avril 2026, le comité de direction d’OpenJDK (le « Governing Board ») a approuvé une politique provisoire, mais radicale : toute contribution au projet ne doit contenir aucun contenu généré, en tout ou en partie, par des modèles de langage (LLM), des modèles de diffusion, ou tout autre système d’apprentissage profond similaire. La nouvelle est longtemps restée relativement discrète, avant d’être largement reprise et commentée début août 2026 par la presse spécialisée, notamment The Register, ce qui a déclenché une vague de réactions dans la communauté des développeurs.

Un périmètre volontairement très large

Contrairement à ce qu’on pourrait imaginer, l’interdiction ne se limite pas au code source à proprement parler. Elle englobe :

• Le code source déposé dans les dépôts Git d’OpenJDK ;
• Les descriptions et discussions liées aux pull requests sur GitHub ;
• Les e-mails échangés sur les listes de diffusion du projet ;
• Les pages du wiki communautaire ;
• Les tickets ouverts dans le JBS (Java Bug System), l’outil de suivi des anomalies du projet.

💡 Attention, nuance importante Le texte n’interdit pas d’utiliser l’IA, il interdit d’en soumettre le résultat. Un développeur reste libre d’utiliser un assistant IA en privé pour comprendre du code existant, déboguer un problème, ou explorer une piste de correction. Ce qui est prohibé, c’est de coller ensuite ce résultat généré par IA directement dans une contribution officielle au projet.

Comment Oracle compte-t-il faire respecter la règle ?

C’est là que ça devient intéressant, car le projet lui-même reconnaît une évidence gênante : il est, de manière générale, impossible de distinguer avec certitude un contenu généré par une IA d’un contenu rédigé par un humain. Faute d’outil de détection fiable, OpenJDK mise sur deux leviers complémentaires.

• Une déclaration sur l’honneur : via Skara, le système automatisé de revue des pull requests du projet, chaque contributeur devra bientôt cocher une case attestant que sa soumission respecte la politique anti-IA.
• La vigilance humaine des relecteurs, invités à repérer des indices révélateurs : messages de commit étrangement bavards, commentaires de code superflus, programmation défensive exagérée, ou encore usage d’émojis, autant de petites signatures stylistiques que les modèles de langage laissent parfois échapper.

Pourquoi une règle aussi stricte ? Trois raisons avancées par Oracle

1. La surcharge des relecteurs

Un projet open source comme OpenJDK ne vit que grâce à un nombre limité de relecteurs bénévoles ou salariés, chargés d’examiner chaque contribution avant de l’intégrer. Or du code généré par IA peut sembler parfaitement correct en apparence tout en cachant des erreurs subtiles ou des choix d’architecture discutables. Passer au crible un flot de contributions plausibles mais potentiellement fragiles finirait par épuiser une ressource humaine déjà rare, c’est ce qu’on appelle, dans le jargon, le problème de la « charge de relecture ».

2. La sécurité et la fiabilité du socle logiciel

OpenJDK est au fondement de systèmes critiques utilisés par des entreprises, des gouvernements et de nombreuses organisations à travers le monde. Un code qui « a l’air » de fonctionner, mais qui cache une faille de sécurité ou un comportement instable, représente ici un risque disproportionné par rapport à un projet plus anodin.

3. Le flou juridique sur la propriété intellectuelle

C’est sans doute l’argument le plus décisif aux yeux de certains observateurs. Tout contributeur à OpenJDK doit signer le fameux OCA (Oracle Contributor Agreement), un contrat qui exige que le contributeur soit bien l’unique propriétaire des droits de la contribution, et qu’il puisse les céder à Oracle sans restriction. Problème : la propriété intellectuelle d’un code généré par une IA entraînée sur des milliards de lignes provenant d’on ne sait où reste, à ce jour, un terrain juridique mouvant. Sai Rahul Poruri, directeur général de l’association FOSS United, estime d’ailleurs que ce motif de propriété intellectuelle pèse davantage dans la décision d’Oracle que les questions de sécurité ou de charge de travail.

Le paradoxe qui fait jaser : « fais ce que je dis, pas ce que je fais »

Voici où l’histoire devient franchement savoureuse. Au moment même où OpenJDK ferme la porte au code généré par IA, la maison-mère Oracle annonce vouloir investir 70 milliards de dollars dans les infrastructures d’intelligence artificielle sur l’année, contre 55,7 milliards l’année précédente. Larry Ellison, cofondateur d’Oracle, a lui-même déclaré publiquement que des modèles d’IA écrivent désormais une part significative du code interne de l’entreprise, tandis que le co-PDG Mike Sicilia vantait des équipes d’ingénierie plus légères grâce à ces mêmes outils.

⚠️ Deux poids, deux mesures chez Oracle elle-même Autre indice révélateur de ce grand écart interne : GraalVM, un autre projet Java également piloté par Oracle (via ses laboratoires Oracle Labs), a adopté la politique strictement inverse. Non soumis au comité de direction d’OpenJDK, GraalVM autorise explicitement ses contributeurs à s’appuyer sur des assistants IA, à condition que la personne qui soumet le changement en reste pleinement responsable et soit capable d’en expliquer chaque ligne. Deux projets, sous le même toit, deux philosophies diamétralement opposées.

OpenJDK n’est pas seul : comparatif des politiques IA dans l’open source

Ce débat dépasse largement Java. Plusieurs grands projets open source ont dû, ces derniers mois, trancher la même question épineuse, chacun avec sa propre philosophie.

Projet	Position sur l’IA	Logique retenue
OpenJDK	Interdiction totale des contributions générées par IA	Zéro tolérance : propriété intellectuelle et sécurité prioritaires
GraalVM (Oracle Labs)	Autorisée, sous responsabilité du contributeur	Confiance encadrée : inspirée du modèle du noyau Linux
Noyau Linux	Autorisée avec divulgation obligatoire	Transparence + validation humaine systématique
LLVM	Autorisée avec relecture humaine et divulgation	Responsabilisation du contributeur
GCC	Interdiction du contenu « juridiquement significatif »	Tolérance limitée : tests générés par IA possibles au cas par cas

Une règle vraiment applicable ? Ce que révèle une étude surprenante

Interdire quelque chose sur le papier est une chose ; le faire respecter en est une autre. Une étude menée par des chercheurs de l’université de Pékin, portant sur 106 tâches réparties dans 49 dépôts open source différents, a testé si des agents de codage IA consultaient spontanément les fichiers de politique du projet avant de proposer une contribution.

Le résultat interpelle : sans instruction spécifique, les agents n’ont ouvert le fichier de politique pertinent que dans 3,5 % des cas. Pire encore, sur les quatre combinaisons d’agents et de modèles testées, aucune n’a respecté à 100 % les règles imposant de refuser une contribution dans un projet où l’IA est bannie, soit un taux de conformité de 0 %. Un signal fort que la simple existence d’un règlement, aussi clair soit-il sur le papier, ne suffit pas à garantir son application concrète sur le terrain.

ℹ️ « Faire confiance, mais vérifier » Pratik Ambhore, responsable de l’ingénierie des données chez R Systems, résume bien la tension actuelle : il qualifie l’interdiction d’Oracle de mesure de gestion des risques transitoire plutôt que de modèle durable, et plaide pour une approche fondée sur la divulgation et la responsabilisation humaine plutôt qu’une interdiction pure et simple, difficile à faire respecter dans les faits.

Cette affaire dépasse largement l’anecdote autour d’un langage de programmation. Elle illustre une tension bien réelle que toute organisation confrontée à l’IA générative devra tôt ou tard trancher : celle qui existe entre l’accélération promise par ces outils et la nécessité de préserver la confiance, la sécurité et la clarté juridique d’un patrimoine logiciel critique. Le choix d’Oracle peut sembler contradictoire vu de l’extérieur et il l’est, dans une certaine mesure, mais il révèle surtout que « utiliser l’IA en interne pour aller plus vite » et « accepter du code IA venu de l’extérieur sans contrôle » sont deux problématiques aux enjeux de responsabilité totalement différents.