Open source : les contributions IA pèsent sur les épaules des mainteneurs

Accepter ou non les contributions IA, un débat ouvert dans l’écosystème

Face à l’afflux massif de commentaires, de propositions, « d’issues » et de code, chaque projet adapte ses règles. Certains mainteneurs ont délimité les contours des contributions IA dès 2023. Melissa Weber Mendonça, ingénieure sénior DevEx chez QuantSight, une société de consulting spécialisée dans l’open source, a organisé le référencement en crowdsourcing des positions et les guides de conduite IA de 182 projets open source. Résultat, seulement 82 d’entre eux acceptent ouvertement le recours aux LLM pour produire du code.

Parmi les refus notables, l’on notera celui de l’OpenJDK. Oracle et la communauté derrière le langage de programmation Java ont mis en place une politique temporaire. Elle interdit pour le moment la génération de code par IA, mais aussi de texte, d’images, de mails, de pages Wiki. Bref, de tout contenu IA pouvant intégrer le projet. Les contributeurs sont autorisés à utiliser les outils d’IA pour « comprendre, débugger et examiner le code [Java] et d’autres contenus, ainsi que mener des recherches liées aux projets OpenJDK, à condition de ne pas contribuer à la création de contenus générés par ces outils ».

Oracle évoque des enjeux de sécurité. Le respect des licences ouvertes et propriétaires associées à l’écosystème Java justifie cette prudence. Les mainteneurs de la machine virtuelle QEMU appliquent le même dispositif, tout comme ceux du langage de programmation Clojure. Ils sont toutefois plus tolérants concernant la génération de commentaires dans le code.

D’autres projets directement ou indirectement prisés par les entreprises – dont Kubernetes, PyTorch, NumPy, Fedora, Apache Airflow ou Drupal – acceptent les contributions IA à condition que les usagers l’indiquent clairement.

IA ou pas, le contributeur engage (potentiellement) sa responsabilité

 Du côté de Valkey, les mainteneurs suivent les recommandations générales de la Linux Foundation, leur fondation d’attache. La politique de l’ONG tient en trois points. Elle autorise les contributions de code générées par IA. En revanche, les contributeurs s’assurent que les éditeurs des IDE agentiques « n’imposent pas de restrictions contractuelles quant à l’utilisation des résultats générés qui seraient incompatibles avec la licence open source, les politiques du projet en matière de propriété intellectuelle ou la définition de l’open source ».

Les portions de code doivent être correctement attribuées et licenciées. Dans certains cas, il convient d’obtenir la permission des mainteneurs des autres projets open source invoqués. Enfin, les contributeurs doivent se conformer aux règles internes du projet. Par exemple, au sein de la Linux Foundation, les responsables des projets ont tout à fait le droit de rejeter les contributions IA.

« En fin de compte, c’est toujours une personne qui contribue individuellement au code », résume Madelyn Olson. « Que celui-ci ait été entièrement ou partiellement généré par l’IA, puis finalisé, ou entièrement créé par une personne, c’est la personne qui contribue au code qui est en dernier ressort responsable de cette contribution, et c’est en quelque sorte le critère que nous retenons ».

La Linux Foundation, l’Apache Software Foundation et l’Eclipse Foundation, les trois ONG – les plus influentes dans l’écosystème – partagent cette recommandation.

Dès lors, les mainteneurs de Valkey acceptent les contributions IA, mais pas le « slop IA ». Cette expression renvoie aux contenus de mauvaise qualité générés par un grand modèle de langage ou un modèle de diffusion.

« Si nous constatons qu’un contributeur propose un bout de code qui ressemble à de l’AI Slop, nous ne le retiendrons pas parce qu’il est généré par une IA, mais parce qu’il est de mauvaise qualité ou qu’il sera difficile de le maintenir à long terme », relate Madelyn Olson.

Un difficile retour en arrière

Pour Jean Boussier, membre de « Core Team » du framework Rails (Ruby on Rails) et contributeur pour Ruby, la « boîte de Pandore a été ouverte ».

« Dans l’écosystème open source, il y a des oppositions idéologiques, techniques, il y a tout un débat », résume-t-il. C’est déjà trop tard, estime-t-il. « Quand bien même l’on voudrait bannir les LLM, ce serait très difficile à détecter. L’on passerait plus de temps à faire la police qu’à réellement gagner du temps. Je pense que la boîte de Pandore a été ouverte. Il n’y aura pas de retour en arrière. Il faut vivre avec », déclare-t-il.

À noter que les projets Ruby et Rails n’ont pas à proprement parler de politiques concernant les contributions IA.

Après des débuts « horribles », l’ingénieur constate une légère amélioration des contenus générés.

« Le volume a explosé, la qualité, pas vraiment. Par exemple, nous avons un contributeur japonais qui nous propose de bons et de très mauvais PR (Pull Requests). Il n’y a généralement rien à redire sur les patchs, la description du pull request est concise et claire et ils corrigent de vrais bugs. En revanche, ces bugs sont souvent inédits ou difficiles à reproduire », illustre Jean Boussier.

« Nous mergeons ces pull requests, mais est-ce vraiment un bon usage du temps des mainteneurs et des LLM ? Je n’en suis pas convaincu ».

La revue de code assistée à l’IA, où « combattre le feu par le feu »

Madelyn Olson et d’autres mainteneurs de Valkey utilisent désormais les agents IA pour les aider à trier le bon grain de l’ivraie. Les bonnes contributions des mauvaises.

« Les agents IA sont devenus compétents pour réviser et aider à réviser le code », constate-t-elle. « Je pense que c’est a été un processus d’apprentissage pour tous les mainteneurs, mais surtout une démarche individuelle », nuance-t-elle. « Il n’existe pas encore de politique formelle de révision de code à l’échelle des organisations ou des projets. Nous avons quelques outils et ils détectent la plupart certaines choses basiques ».

« Il s’agit de combattre le feu par le feu », ajoute Jacob Murphy, mainteneur de Valkey et ingénieur logiciel chez Google Cloud. « L’IA génère beaucoup plus de contributions, mais il existe aussi des moyens d’utiliser l’IA pour faciliter notre travail. La révision en fait partie. Nous faisons également beaucoup de “backporting” », détaille-t-il. « Par exemple, lorsque nous recevons des corrections de bugs ou des correctifs de vulnérabilités, leur portage dans des versions antérieures [de Valkey] représente un défi de taille pour nous. Nous pouvons aujourd’hui automatiser une grande partie de ce processus ».

Certains mainteneurs de Valkey effectuent encore des revues de code manuelles, ligne par ligne. « Cependant, nous pouvons nous aider de l’IA pour détecter les problèmes avant qu’ils atteignent ce stade », complète Jacob Murphy.

Madelyn Olson explique également que les IDE agentiques permettent de corriger les pipelines CI/CD. C’est notamment utile pour analyser les erreurs de tests et les relancer le cas échéant. Cela fluidifie déjà le lancement de nouvelles versions. Alors que le rythme de mise à jour de Valkey était « inconsistant », il est désormais plus stable et plus rapide. Cela laisserait davantage de temps pour faire la chasse aux bugs les plus sévères.

Certains vont jusqu’à mettre en place des pipelines agentiques pour gérer plusieurs projets open source.

« Dans mon propre flux de travail, j’ai maintenant des préréviseurs agentiques », indique Russel Spritzer, un des gestionnaires principaux des projets Apache Iceberg, Polaris, MagPie, mentor du projet Ossie et ingénieur principal chez Snowflake. « Je reçois des rapports sur toutes les nouvelles contributions soumises sur mes projets et je les parcours avant d’y consacrer réellement mon temps ».

Cela n’empêche pas Russel Spritzer de regretter une perte de qualité. Elle serait moins liée au code qu’à la pertinence des contributions.

« Si je dois parler à un agent IA, autant que j’utilise le mien », tranche-t-il. « Je n’ai aucun problème à ce que quelqu’un utilise l’IA, mais la personne qui contribue doit assurer d’apporter sa perspective », recommande-t-il.

Comment recruter les futurs mainteneurs ?

Pour Jean Boussier, il semble dès lors plus difficile d’identifier les contributeurs qui pourraient rejoindre les réviseurs et les mainteneurs. Des réviseurs qui manquent parfois cruellement. « Personnellement, je me basais beaucoup sur des propriétés externes du code pour juger les contributions. Ces signaux ne sont plus des critères fiables. À moi de repenser mes revues », illustre-t-il.

Plus spécifiquement, ces signaux l’aidaient à déterminer si un contributeur comprend la fonction qu’il tente de corriger ou d’améliorer et, a fortiori, le framework Rails dans son ensemble.

« Le problème, sur la durée, sera d’établir la manière dont on attire de nouveaux contributeurs et de nouveaux mainteneurs », juge-t-il. « Comment s’assurer que quelqu’un qui paie des tokens pour générer du code le comprenne ? », s’interroge-t-il. « C’est très facile de générer du code et de passer à autre chose ».

La moyenne d’âge du secteur permet de relativiser cet enjeu à court terme, estime-t-il. Selon le State Of Dev 2025 mené par Devographics l’année dernière auprès de 7000 développeurs, 44 % d’entre eux ont 30 à 39 ans et 22 % des sondés ont 20 à 29 ans.

En outre, comme le signalent Madelyn Olson et Russel Spritzer, les mainteneurs et contributeurs de grands projets sont embauchés par des éditeurs. La réticence encore forte des mainteneurs face à « l’AI Slop » et cette professionnalisation de l’open source devrait limiter l’érosion de la qualité de briques les plus utilisées par les entreprises. Sans compter l’amélioration progressive des outils d’IA et des pratiques associées.

En revanche, Jean Boussier anticipe la multiplication des projets open source « one-man show ». « Je pense à quelqu’un qui utilise l’IA pour tout faire, sans vraiment prendre de contributions. S’ils les acceptent, il y a de forte chance que cet homme-orchestre ne les fera pas vérifier par des mainteneurs humains », évoque-t-il.

Si un tel projet gagne en popularité et devient une dépendance pour une librairie d’envergure, qu’adviendra-t-il ? « Lorsqu’il y a trop d’assistance, l’on finit par débrancher notre cerveau, à trop faire confiance au système. C’est ce qui m’inquiète le plus avec les LLM et leurs résultats inconsistants. Cela peut mal finir », avertit-il.