L'émulateur PlayStation 3 ne bannit pas l'IA : il exige qu'on déclare son usage et qu'on puisse défendre son code. Derrière la colère, il y a une ressource plus rare que le code : le temps de ceux qui doivent le relire.
Le 9 mai 2026, le compte officiel de RPCS3 a adressé à ses contributeurs un message sans détour, devenu viral en quelques jours. L'équipe y demandait qu'on cesse de lui envoyer des pull requests de code généré par IA, annonçait qu'elle bannirait désormais ceux qui omettent de le déclarer, et conseillait aux volontaires d'aller apprendre à déboguer et à programmer plutôt que de produire du code qu'ils ne maîtrisent pas et qui ne tourne pas.
Deux jours plus tard, le projet annonçait la mise en ligne de ses règles dans son dépôt GitHub, en ajoutant qu'il bloquerait sans discussion les comptes venus contester sur les réseaux sociaux.
L'affaire a été reprise par la presse spécialisée - Kotaku, GamingOnLinux, PC Guide, GamesRadar, Notebookcheck - et résumée à une histoire de "boomers contre vibecodeurs". C'est passer à côté du sujet. RPCS3 n'interdit pas l'IA. Il exige que celui qui envoie du code puisse le défendre.
Ce que disent vraiment les nouvelles règles
Le texte publié dans le dépôt est plus précis que le message diffusé sur les réseaux sociaux. L'usage d'outils d'IA pour la recherche et le rétro-ingénierie est autorisé. En revanche, le contributeur doit posséder et comprendre l'intégralité du code qu'il soumet. Toute communication avec l'équipe - le code, les commentaires dans le code, les commentaires GitHub - doit venir de l'humain, pas d'un agent autonome. Une pull request ouverte par un agent doit déclarer l'ampleur de l'intervention de l'IA, ce qui a été généré et ce qui a été testé avant envoi. Sans cette déclaration, la PR peut être fermée sans même être lue. Les récidivistes s'exposent à un bannissement du dépôt.
La justification est explicitement économique, au sens du temps : l'équipe dit avoir constaté "une hausse de slop non testé et non vérifié" : du code qui "gaspille le temps des mainteneurs" et qui, dans les pires cas, une fois fusionné, casse des fonctionnalités pour tout le monde.
Le "slop", ici, ne désigne pas le code écrit avec une IA. Il désigne le code que personne n'a compris, que personne n'a lancé, et qu'on envoie quand même.
Pourquoi un émulateur de PS3 est un cas particulier
RPCS3 existe depuis 2011 et, selon Kotaku, rend aujourd'hui environ 70 % du catalogue PlayStation 3 jouable. C'est un travail de rétro-ingénierie sur deux processeurs exotiques, le Cell et le RSX, où la justesse d'un émulateur ne se mesure pas à des tests unitaires mais à des milliers de jeux qui démarrent, ou pas.
Cette nature du projet explique en partie la réaction. Une régression fusionnée par erreur ne se voit pas dans une courbe de couverture : elle se voit quand un jeu précis cesse d'afficher ses menus. Et le projet ne dispose pas d'un oracle automatique capable de dire si une modification est correcte. Il faut quelqu'un qui comprenne l'architecture matérielle pour en juger.
C'est aussi ce qui rend le problème insoluble par la seule bonne volonté : chaque PR rejetée coûte du temps à celui qui la rejette, pas à celui qui l'envoie.
Le chiffre de 25 %, et ce qu'il vaut
La Linux Foundation Research a publié le 20 octobre 2026 une enquête sur l'IA générative dans l'open source, présentée à All Things Open à Raleigh. Ces chiffres sont devenus une référence du débat : 59 % des mainteneurs constatent une hausse du volume de contributions depuis l'arrivée de l'IA générative (69 % dans les grands projets), et 25 % des pull requests entrantes sont estimées de mauvaise qualité - 31 % dans les grands projets.
Ce chiffre a des limites. Il s'agit d'une estimation déclarée par les mainteneurs, pas d'un comptage indépendant de diffs attribués à une IA. Une contribution hors sujet, abandonnée ou contraire aux règles du projet peut être qualifiée de "slop", même si elle a été écrite à la main. La même enquête relève d'ailleurs que 61 % des contributeurs disent relire et tester fonctionnellement le code généré avant de l'envoyer, et que la divulgation reste le point faible. Autrement dit : ce n'est pas l'usage de l'IA qui est mal mesuré, c'est sa déclaration.
Hilary Carter, vice-présidente de la recherche à la Linux Foundation, en tire une conclusion de gouvernance plutôt que de morale : les projets doivent, selon elle, se concevoir pour une base croissante de contributeurs générés par l'IA, et non se contenter de réagir à leur arrivée. L'enquête note au passage que seuls 35 % des projets ont une politique formelle autorisant l'IA, et que 32 % n'en ont aucune et n'en prévoient pas.
La contre-enquête : les PR d'IA ne sont pas forcément les pires
Le récit dominant - des contributions IA bâclées qui submergent les mainteneurs - a une faiblesse : il repose presque entièrement sur des perceptions. Les mesures disponibles racontent une histoire plus nuancée.
Une étude présentée à la conférence MSR 2026 a comparé, sur 2 314 pull requests de dépôts Python modifiant au moins un test, trois régimes d'écriture : PR entièrement générées par des agents, PR mixtes, et PR humaines de référence. Résultat : dans les PR purement IA, les tests ajoutés exécutent en moyenne 19,96 % des lignes de code source modifiées, contre 17,35 % pour les PR mixtes et 13,09 % pour les PR humaines. Et 80,4 % de ces PR purement IA ont une couverture non nulle, contre 62,3 % et 66,2 %. Sur la qualité des assertions, aucune différence statistiquement significative n'apparaît entre les groupes.
Les limites de ce résultat sont réelles et il faut les poser : l'échantillon ne contient que des PR qui touchent déjà à des tests - une population auto-sélectionnée, probablement plus soignée que la moyenne -, il est restreint à Python, et la couverture de tests n'est pas la correction du code. Mais il établit une chose : la "contribution assistée par IA" et le "slop" ne sont pas la même population. La variable décisive semble être le processus du contributeur, pas l'outil.
Dans l'autre sens, une expérience contrôlée de METR, menée sur 16 développeurs expérimentés de grands dépôts open source et 246 tâches réelles, a mesuré que ces développeurs passaient 19 % de temps en plus lorsqu'ils pouvaient utiliser l'IA - alors qu'ils croyaient avoir gagné 20 %. Le même institut précise que ces résultats datent du début 2025 et ne reflètent plus l'effet des modèles actuels. À retenir comme un avertissement méthodologique plus que comme un verdict : les perceptions de productivité, dans les deux sens, sont peu fiables.
Trois réponses, trois logiques
Comparer les projets éclaire mieux que les principes.
curl a supprimé son bug bounty. Daniel Stenberg a annoncé le 26 janvier 2026 la fin du programme, effectif au 31 janvier, après près de sept ans et 87 vulnérabilités confirmées pour plus de 100 000 dollars versés. Le taux de rapports confirmés est passé d'environ 15 % à moins de 5 % en 2025. "Pas même un sur vingt n'était réel", écrit-il, ajoutant que ces envois pèsent sur le moral et prennent parfois longtemps à réfuter. Détail instructif : sur les quatre derniers trimestres, le volume reçu par curl a bondi alors que celui de programmes comparables (Ruby, Node, Rails) est resté stable ou a légèrement reculé. Stenberg en tire l'hypothèse que l'argent est une part importante de l'explication - un bounty transforme l'envoi massif en activité rentable. Il reconnaît lui-même qu'il s'agit d'une conjecture. Dans un message publié depuis sur LinkedIn, il a indiqué que les rapports de sécurité "slop" avaient cessé d'arriver sur curl.
Surtout, Stenberg sépare explicitement les rapports de sécurité des pull requests : sur les PR, curl ne rencontre pas le problème, parce que, dit-il, "nous avons de bien meilleurs moyens de trier automatiquement" - outils, tests et scanners, jusqu'à 200 tâches d'intégration continue. Aucun humain ne lit une PR avant qu'elle obtienne ses voyants verts.
QEMU envisage d'assouplir son interdiction. Le projet refusait jusqu'ici tout code susceptible de dériver d'un contenu généré par IA, pour une raison juridique : la provenance et les droits. En mai 2026, Paolo Bonzini, ingénieur chez Red Hat et mainteneur de KVM, a proposé d'autoriser l'assistance par IA là où les conséquences d'une violation de droit d'auteur sont "faciles à annuler" et peu susceptibles de se propager, le coeur du code restant interdit sans accord préalable d'un mainteneur. Son argument : une interdiction totale "était facile à maintenir" tant que les sorties des LLM étaient rarement exploitables en l'état, mais une prohibition absolue est devenue plus difficile à justifier à mesure que les outils progressent. Il propose un marqueur de commit distinct, AI-used-for:, et précise que l'usage de l'IA ne dispense d'aucune autre exigence.
GitHub déplace le problème vers l'outillage. Au début de 2026, la plateforme a ouvert une discussion communautaire sur "le volume croissant de contributions de faible qualité" et évoqué des pistes : permettre aux mainteneurs de désactiver purement et simplement les pull requests, de les réserver aux collaborateurs, de supprimer des PR de l'interface, ou d'ajouter des outils de triage. Matthew Isabel, chef de produit chez GitHub, a ensuite contesté l'angle même du débat : "une mauvaise PR est une mauvaise PR, d'où qu'elle vienne" ; compter les PR générées par IA n'est pas, selon lui, la bonne métrique. La plateforme a depuis ajouté des plafonds de PR pour les contributeurs extérieurs.
Un commentaire de cette discussion résume peut-être le mieux le coût réel. Chad Wilson, mainteneur principal de GoCD, raconte avoir passé un long moment à relire une PR de documentation avant de comprendre qu'il s'agissait d'un "non-sens plausible". Sans divulgation généralisée, écrit-il, "cela transforme des gens comme moi en prompteurs d'IA involontaires" ; il y voit une érosion du lien de confiance.
Ce que la politique d'un projet dit de sa dépendance à l'humain
Les trois cas ne divergent pas par idéologie, mais par ce que le projet peut vérifier automatiquement.
Là où l'intégration continue tranche - curl -, le volume est absorbable, parce que le tri est fait par des machines et que le coût marginal d'une PR médiocre est proche de zéro. Là où la justesse dépend d'un jugement humain sur du matériel mal documenté - RPCS3 -, chaque PR médiocre consomme directement la ressource la plus rare. QEMU, qui a les deux problèmes à la fois (juridique et technique), propose une troisième voie : laisser entrer l'IA là où une erreur peut être annulée proprement.
La question du "qui paie" est donc mal posée quand on l'exprime en lignes de code. Le coût ne réside pas dans le volume produit, mais dans le temps de relecture, non facturé, supporté par une poignée de bénévoles ou de salariés des entreprises qui financent le projet. Une partie de ce coût est d'ailleurs créée en amont par l'industrie qui vend les outils : plus il est facile de générer une PR, plus il en arrive, et la charge tombe sur ceux qui n'ont pas choisi cette facilité.
Le revers, qu'il faut prendre au sérieux : une politique de bannissement a un coût, elle aussi. Sur GamingOnLinux, un lecteur faisait remarquer que ce genre de règle finit toujours par écarter de bons développeurs, et que les étiquettes automatiques de type "co-authored by Copilot" se trompent parfois. Il n'a pas tort sur le principe. La divulgation exigée par RPCS3 est justement un compromis : elle ne bloque personne avant la relecture, elle rend visible ce que le relecteur doit savoir pour ajuster sa confiance - et elle fait fuir, par auto-sélection, ceux qui ne peuvent pas expliquer leur propre diff.
Reste que la politique de RPCS3 ne rendra pas le code meilleur. Elle rend le tri possible. C'est modeste, et c'est probablement tout ce qu'un projet de cette taille peut s'offrir : non pas empêcher l'IA d'écrire, mais rappeler que dans un dépôt public, envoyer du code reste un acte de communication avec des gens qui ont un temps limité - et qu'un émulateur de PlayStation 3 ne se portera pas mieux parce qu'on aura cliqué sur "generate".