Les mainteneurs open source ripostent contre le « AI slop », un programme de primes à la fois

En 2026, "AI slop" est devenu le mot de l'année du dictionnaire Macquarie — un contenu de mauvaise qualité généré par IA générative, "contenant souvent des erreurs, et non demandé par l'utilisateur". Les mainteneurs open source n'avaient pas besoin d'un dictionnaire pour comprendre. Ils en triaient des milliers depuis un an, et le collectif Jazzband — un pôle bien connu de projets d'empaquetage Python — a fermé complètement en 2026, son mainteneur principal citant le volume insoutenable de pull requests et d'issues spam générées par IA comme facteur décisif.

La thèse ici n'est pas que les outils d'IA sont mauvais pour le code — de nombreuses contributions légitimes commencent désormais avec une assistance IA. C'est que l'économie de la revue open source a été construite sur une hypothèse précise : qu'une pull request soumise représente du temps et un jugement humain réel, ce qui justifie qu'un mainteneur y consacre du temps réel. L'IA générative a brisé exactement cette hypothèse au point de goulot d'étranglement exact — la capacité de revue humaine — que l'open source n'a jamais pu faire évoluer.

À quoi ressemble vraiment l'AI slop dans une file de PR

Ce n'est pas manifestement malveillant. Jeffrey Paul, vice-président des solutions open source chez Fueled, le décrit comme des soumissions de personnes qui ne comprennent pas pleinement le problème, la solution proposée, ou les deux — un contributeur a lancé un outil IA, obtenu quelque chose de plausible, et l'a soumis sans vérifier que cela fonctionnait réellement. Le code compile souvent. Il passe parfois les tests. Il ne fait fréquemment pas ce qu'il prétend, et le découvrir nécessite la même profondeur de revue que l'évaluation d'une contribution légitime — l'effort ne diminue pas, seul le coût de soumission diminue.

Cette asymétrie résume toute la crise en une phrase : générer une PR d'apparence plausible ne coûte désormais presque rien au contributeur, tandis que la vérifier coûte toujours au mainteneur la même chose qu'avant.

Le programme de primes de curl : une étude de cas chiffrée

Aucun projet n'a été plus transparent publiquement sur les dégâts que curl. Le fondateur Daniel Stenberg a suivi la qualité des soumissions tout au long de 2025 alors que des rapports de sécurité générés par IA inondaient le programme de primes du projet. Mi-2025, seulement environ 5% des soumissions étaient de vraies vulnérabilités — le reste étant des rapports générés par IA structurellement corrects en apparence mais décrivant des failles inexistantes. Stenberg a fermé entièrement le programme de primes début 2026. Cela n'a pas résolu complètement le problème — les soumissions slop arrivent toujours par e-mail et GitHub — mais cela a supprimé l'incitation financière directe qui faisait de curl une cible spécifique. Seuls sept mainteneurs examinent les rapports de sécurité de curl, un nombre qui n'a pas évolué malgré l'explosion du volume de soumissions.

RubyGems envisagerait la même mesure, selon Marty Haught, directeur open source, après des mois sans un seul rapport de vulnérabilité valide malgré un volume continu de soumissions.

Le coût humain, pas seulement le coût du processus

Rémi Verschelde, mainteneur du moteur de jeu Godot, a décrit le tri de l'AI slop comme épuisant et démoralisant — une distinction qui mérite réflexion. Examiner une contribution humaine de mauvaise foi ou peu soignée est frustrant mais compréhensible ; on peut raisonner sur l'intention du contributeur. Examiner de l'AI slop signifie investir à répétition un effort cognitif réel pour évaluer quelque chose sans aucune intention derrière, puis le rejeter. C'est un type spécifique et cumulatif d'épuisement, distinct de la surcharge habituelle des mainteneurs, et c'est un facteur documenté dans la décision de Jazzband de fermer plutôt que de continuer.

À quoi ressemble vraiment la réponse

WordPress a déployé des directives formelles de contribution IA exigeant la divulgation de l'utilisation d'outils IA et définissant des schémas inacceptables, comme les gros volumes de code non révisé, explicitement pour réduire la charge des mainteneurs évaluant des soumissions à l'aveugle. GitHub, sous pression en tant que plateforme hébergeant la majeure partie de ce trafic, a annoncé un ensemble de fonctionnalités destinées aux mainteneurs visant à leur donner plus de contrôle sur le volume et la qualité des soumissions.

Le schéma commun à toutes les réponses — règles de divulgation de WordPress, fermeture des primes curl, outils GitHub — est le même : reporter le coût de la soumission peu soignée sur celui qui la soumet, car pendant trois ans ce coût est retombé entièrement sur le mainteneur.

Que faire réellement

Si vous maintenez un projet, les méthodes de curl et WordPress sont désormais reproductibles : exigez la divulgation de l'utilisation d'IA dans votre modèle de contribution, et traitez une première soumission slop comme une opportunité pédagogique, mais une seconde comme motif d'avertissement ou de blocage — la plupart des contributeurs légitimes s'ajustent une fois prévenus, et ceux qui ne le font pas n'allaient de toute façon jamais être des contributeurs durables. Si vous êtes un contributeur utilisant des outils IA, la discipline qui vous évite la liste slop d'un mainteneur est simple et sans éclat : exécutez et vérifiez le code vous-même avant de le soumettre, et soyez capable d'expliquer avec vos propres mots pourquoi le correctif est juste. C'est exactement le test que l'AI slop échoue, et c'est la seule chose que les outils génératifs ne peuvent toujours pas faire à votre place.