OpenJDK ferme la porte aux contributions générées par IA. Pas seulement au code : la règle couvre aussi les textes, les images, les demandes de fusion, les courriels, les pages wiki et les tickets JBS. Oracle autorise l’IA pour comprendre, déboguer ou relire, mais pas pour produire ce qui franchit la porte du projet. Le message est limpide : dans le cœur de Java, l’assistant reste côté brouillon.
Le sujet revient dans l’actualité après un rappel publié ce 3 août, alors que l’industrie vend partout le développement logiciel assisté par modèle. La politique OpenJDK n’est pourtant pas une interdiction générale de l’IA : c’est une frontière de contribution, avec une exigence d’auteur humain sur ce qui est soumis au projet.
Oracle ne veut pas de code généré dans OpenJDK
La politique intérimaire approuvée par le Governing Board est large. Elle vise les grands modèles de langage, les modèles de diffusion et les systèmes similaires, et interdit le contenu généré « en partie ou en totalité ». Cela inclut le code source, mais aussi la documentation, les images et les messages qui accompagnent une modification.
La règle s’applique aux dépôts Git, aux demandes de fusion GitHub, aux courriels, aux pages wiki et aux tickets du Java Bug System. Autrement dit, réécrire un bout de code produit par un modèle ne suffit pas : la foire aux questions précise que générer cent lignes puis en retoucher dix laisse toujours une contribution partiellement générée. Le filtre ne porte donc pas uniquement sur le résultat compilable, mais sur sa provenance.
Crédit : OpenJDK, page officielle de la politique intérimaire sur l’IA — https://openjdk.org/legal/ai
Pourquoi OpenJDK serre autant la vis
Le premier argument est très concret : le temps des mainteneurs. Un modèle sait produire rapidement une grande quantité de code plausible, avec des tests qui ont l’air sérieux. Mais plausible ne veut pas dire juste, cohérent ou maintenable. Pour un projet aussi vaste que le JDK, chaque changement douteux transforme la revue humaine en chasse au texte statistiquement bien coiffé.
Le deuxième argument touche à la sécurité. OpenJDK est l’implémentation principale de la plate-forme Java et se retrouve sous des applications critiques. Une erreur subtile dans le moteur, les bibliothèques ou les outils de développement peut avoir une portée bien supérieure à celle d’un bogue dans un projet secondaire. Le projet préfère donc limiter l’entrée de contenu dont la chaîne de fabrication est difficile à établir.
Oracle ajoute enfin le risque de propriété intellectuelle. L’Oracle Contributor Agreement demande au contributeur de détenir les droits nécessaires et de pouvoir les céder sans restriction. Or les droits sur une sortie de modèle restent juridiquement discutés, et celle-ci peut ressembler à du contenu protégé. La politique ne tranche pas ce débat : elle évite de l’importer dans chaque demande de fusion.
L’IA reste autorisée, mais derrière la ligne
Un contributeur peut utiliser un outil d’IA pour comprendre une base de code, trouver une piste de débogage, relire un changement ou faire des recherches sur un projet OpenJDK. Il peut aussi faire relire un brouillon de JEP ou de documentation, à condition d’en écrire lui-même le contenu soumis. L’assistant peut donc jouer le rôle du collègue pénible qui pose de bonnes questions, pas celui du signataire.
La nuance vaut aussi pour les fonctions classiques des éditeurs : correction orthographique, autocomplétion, refactorisation ou vérification grammaticale restent admises lorsqu’elles ne reposent pas sur un grand modèle ou un système similaire. Ce n’est pas une croisade contre toute automatisation. C’est une séparation entre des transformations déterministes et un générateur dont les données d’entraînement et la sortie peuvent échapper au contributeur.
Une case à cocher ne détectera pas la provenance
OpenJDK prévoit d’ajouter une case dans les demandes de fusion gérées par Skara. Le contributeur devra confirmer que sa proposition respecte la politique. Mais la FAQ reconnaît le problème évident : distinguer de manière fiable un texte humain d’un texte généré est généralement impossible. Les mainteneurs devront donc continuer à juger le changement sur ses preuves, sa compréhension et sa qualité, pas sur une prétendue signature magique de l’IA.
La politique mentionne des indices possibles : message de validation avec un Co-Authored-By attribué à un outil, commentaires inutilement bavards, structure trop mécanique ou code défensif à l’excès. Ce sont des signaux, pas des preuves. Un développeur humain peut écrire comme un robot ; un modèle peut imiter un humain. La seule stratégie solide reste de demander au contributeur d’expliquer et d’assumer chaque ligne.
OpenJDK choisit la provenance plutôt que la promesse
Cette décision tranche avec le discours dominant des éditeurs qui promettent des équipes plus petites et du code produit à la chaîne. Elle ne dit pas que l’IA est inutile : elle dit que la valeur d’un projet ouvert ne se mesure pas au nombre de lignes générées, mais à la capacité de la communauté à relire, maintenir et transmettre ce qu’elle accepte.
La règle est intérimaire, datée du 9 avril 2026, et Oracle prépare une politique complète. D’ici là, le mode d’emploi est simple pour les contributeurs : utiliser l’IA pour analyser en privé, écrire soi-même ce qui est soumis, et ne pas confondre assistance et paternité. Dans OpenJDK, le bouton « générer » s’arrête encore avant le bouton « envoyer ». Et c’est probablement la partie la plus adulte du débat.
Sources
OpenJDK — politique intérimaire et foire aux questions sur l’IA : https://openjdk.org/legal/ai
OpenJDK — annonce du Governing Board et intégration prévue dans Skara : https://mail.openjdk.org/archives/list/announce@openjdk.org/thread/NPTV4NGSIN2IOMVESWUVN7Y3ERMUBKH2/
The Register — rappel de la politique et contraste avec l’usage interne revendiqué par Oracle : https://www.theregister.com/ai-and-ml/2026/08/03/as-larry-ellison-bets-the-farm-oracle-says-it-loves-ai-written-code-just-not-in-openjdk/
—
Recherche, relecture et illustration assistées par IA. Le contenu reflète le travail éditorial de la rédaction.
No comments yet