En 2026, la communauté open source se trouve à un carrefour critique, confrontée à un afflux sans précédent de contributions générées par l’intelligence artificielle, souvent de faible qualité. Ce phénomène, baptisé “AI slop”, met à rude épreuve le contrat social tacite qui a longtemps régi les relations entre les mainteneurs et les contributeurs. Alors que les algorithmes promettaient de surcharger la productivité, ils ont, paradoxalement, engendré une surcharge de travail pour les mainteneurs, déjà souvent bénévoles et en proie à l’épuisement. Des projets majeurs, du modeste utilitaire cURL au client terminal Ghostty, ont été contraints de réévaluer radicalement leurs politiques, allant jusqu’à l’interdiction pure et simple des contributions assistées par l’IA. Au cœur de cette crise se pose une question fondamentale : comment maintenir la qualité, la confiance et l’esprit collaboratif dans un écosystème où l’effort de contribution a été dévalué par la facilité de la génération assistée par l’IA ? L’urgence de trouver des solutions durables et équitables pour la survie et la prospérité de l’open source n’a jamais été aussi palpable, nécessitant une réinvention des normes et des outils de collaboration face à cette nouvelle ère technologique.
En bref :
- L’afflux de contributions générées par l’IA, surnommées “AI slop”, menace le modèle traditionnel de l’open source.
- Ces contributions de faible qualité augmentent la charge de travail et le risque d’épuisement des mainteneurs.
- Certains projets ont adopté des politiques strictes, allant jusqu’à l’interdiction totale des contributions d’IA.
- Les fondations open source se concentrent principalement sur les questions de licence, délaissant souvent les défis de qualité et de l’épuisement.
- Le “Assisted-by:” est en passe de devenir une norme pour la divulgation de l’utilisation de l’IA dans les contributions.
- Les plateformes comme GitHub sont confrontées à un dilemme d’incitation, favorisant l’engagement plutôt que la maintenabilité.
- Des solutions pratiques sont nécessaires pour les contributeurs, les mainteneurs, les plateformes et les fondations afin de restaurer la confiance et la qualité.
Comprendre l’érosion du contrat social de l’open source
Pendant des décennies, l’écosystème open source a prospéré grâce à un contrat social implicite entre ses acteurs. Les contributeurs, qu’ils soient des développeurs en herbe ou des entreprises établies, trouvaient leur récompense dans l’apprentissage, l’enrichissement de leur parcours professionnel ou la réalisation d’objectifs commerciaux, tout en faisant partie d’une œuvre collective. En retour, les mainteneurs s’engageaient à cultiver une communauté, à orienter le projet et à guider les nouveaux venus. Ce modèle reposait sur l’idée que si de mauvaises requêtes de tirage (pull requests) existaient, leur création nécessitait un investissement de temps et d’efforts, agissant comme un filtre naturel.
L’avènement de l’intelligence artificielle a rompu cet équilibre délicat. Aujourd’hui, il est possible de générer des contributions d’apparence plausible avec un effort et une compréhension minimaux, submergeant le système d’un volume sans précédent. Seth Larson, développeur en résidence pour la sécurité à la Python Software Foundation, a exprimé sa préoccupation quant aux mainteneurs qui gèrent ce phénomène de manière isolée, risquant de gaspiller un temps précieux sur des rapports erronés. Cet épuisement, souvent ignoré, menace la pérennité des projets et la santé mentale de ceux qui les animent, comme détaillé dans l’article de RedMonk sur le “AI slopageddon” et son impact sur les mainteneurs.
La réponse radicale de certains projets face à l’afflux d’IA
La réaction face à cette vague de “AI slop” a été rapide et parfois drastique. Le projet Ghostty de Mitchell Hashimoto a, en janvier 2026, mis en œuvre une politique de tolérance zéro, bannissant définitivement toute soumission de code de mauvaise qualité générée par l’IA. Parallèlement, Steve Ruiz, fondateur de tldraw, a choisi d’auto-fermer toutes les requêtes de tirage externes, estimant que dans un monde d’assistants de codage IA, la valeur du code des contributeurs externes devenait discutable. Ces mesures, bien que radicales, soulignent la gravité de la crise perçue par certains leaders de l’open source.
Le cas de cURL est peut-être le plus emblématique de cette tension. Après six ans et 86 000 dollars de récompenses, Daniel Stenberg, son fondateur et développeur principal, a mis fin au programme de primes de bogues en janvier 2026. La raison ? Une “AI onslop” (jeu de mots intentionnel) qui voyait une proportion croissante de rapports de bogues générés par l’IA, sans aucune vulnérabilité réelle. Ces incidents mettent en lumière un changement fondamental, remettant en question l’ère de la “contribution ouverte” telle que nous la connaissions.
Qu’est-ce précisément le “AI slop” dans l’open source ?
Il est crucial de distinguer le “AI slop” du simple “mauvais code” qui a toujours existé dans l’open source. Le “AI slop” survient lorsqu’un contributeur colle une question GitHub dans un modèle de langage comme ChatGPT, puis soumet le résultat sans aucune vérification ni compréhension. Cela se manifeste par des rapports de bogues apparemment légitimes mais décrivant des vulnérabilités inexistantes, ou des requêtes de tirage qui prétendent corriger des problèmes que le projet n’a pas.
Ces contributions, souvent qualifiées de “vibe coding patches”, semblent plausibles à première vue mais contiennent des hypothèses hallucinées ou du code de piètre qualité. Craig McLuckie, cofondateur et PDG de Stacklok, a déploré que les issues marquées comme “good first issue” soient désormais inondées de “slop” de basse qualité, drainant le temps des mainteneurs. Cette transformation du “slop” en code de qualité via le processus de révision nuit non seulement à la productivité, mais aussi au moral des équipes, comme exploré dans l’article de Medium sur le nouveau problème de l’open source en 2026 : le “AI slop”.
Les caractéristiques distinctives des contributions d’IA problématiques
Le “AI slop” se caractérise par plusieurs traits révélateurs. On y trouve des appels de fonction hallucinés, une exactitude affichée mais erronée, et une verbosité suspecte. Ces contributions peuvent sembler anodines, mais elles masquent un manque total de compréhension du code source ou du contexte du projet. Elles demandent aux mainteneurs un effort disproportionné en triage et en rejet, déviant leur attention des tâches cruciales et des contributions valides.
Ce phénomène n’est pas qu’un problème de quantité ; c’est un problème de qualité insidieux qui sape la confiance. Les mainteneurs doivent désormais dépenser une énergie considérable non pas à améliorer le code, mais à démêler le vrai du faux, à identifier les faux positifs générés par l’IA. Bien que les modèles s’améliorent rapidement, le “AI slop” actuel est souvent identifiable. Cependant, la question se posera bientôt de savoir si la détection sera encore pertinente, ou si l’indistinguabilité croissante du code IA remettra en cause la notion même de provenance.
L’évolution des politiques de contribution en matière d’IA
Les prises de position des mainteneurs concernant les soumissions d’IA continuent d’évoluer rapidement. L’approche de Daniel Stenberg avec cURL illustre bien ce cheminement. Après s’être plaint des rapports de bogues générés par l’IA en janvier 2024, il a constaté, à la mi-2025, qu’environ 20 % des soumissions à son programme de primes provenaient du “AI slop”, avec un taux de validité des vulnérabilités authentiques chutant drastiquement. En mai 2025, il a introduit une case à cocher exigeant la divulgation de l’utilisation de l’IA, mais cela n’a pas suffi à endiguer le flux. Face à sept soumissions en seize heures en janvier 2026, il a finalement fermé le programme, démontrant l’impuissance des mesures intermédiaires.
De même, l’approche de Mitchell Hashimoto a basculé d’une exigence de divulgation obligatoire en août 2025 à une politique de tolérance zéro fin janvier 2026 pour Ghostty, n’autorisant les contributions IA que pour les problèmes acceptés et les mainteneurs. Cette position n’est pas “anti-IA”, mais “anti-idiot”, comme il l’a précisé, soulignant que la qualité prime, quelle que soit la méthode de génération. Steve Ruiz, avec tldraw, a adopté la mesure la plus radicale en fermant automatiquement toutes les requêtes de tirage externes, remettant en question la valeur des contributions externes lorsque l’écriture du code est devenue la partie facile. Il a même découvert que ses propres scripts IA pouvaient créer des “AI slop issues”, qui, une fois transmises à d’autres outils IA de contributeurs, généraient des requêtes de tirage basées sur les hallucinations de son IA, créant une boucle infinie de “AI slop”.
Les projets “indécis” et le poids du consensus
Alors que certains projets ont pris des positions tranchées, une grande majorité d’entre eux naviguent encore dans l’incertitude. Debian, par exemple, a vu sa résolution générale sur l’IA retirée, reflétant les vifs débats internes. FluxCD est un autre exemple, où, selon Stefan Prodan, mainteneur principal, la décision est en attente d’un alignement avec d’autres projets de la CNCF. Ces projets choisissent souvent une approche attentiste, reconnaissant la rapidité d’évolution des outils IA et la difficulté de rédiger des politiques pérennes.
La sagesse de cette approche réside dans la nature même de l’open source, où le consensus communautaire est primordial. Des projets comme Debian fonctionnent par résolutions générales et de longs débats par listes de diffusion, car leur légitimité découle de l’adhésion de la communauté, non de décrets. Même les projets plus petits, souvent régis par des comités de pilotage ou des modèles de collaboration basés sur l’ambiance générale, ne permettent pas à une seule personne de fermer unilatéralement la porte aux contributions d’IA. Face à ce tsunami de contributions, beaucoup préfèrent surfer sur la vague plutôt que de quitter la mer, espérant que des solutions émergeront du processus d’expérimentation et de débat.
Les fondations open source et le défi du “AI slop”
On pourrait s’attendre à ce que les grandes fondations open source fournissent un cadre clair pour gérer le “AI slop”. Or, la plupart de leurs politiques se concentrent sur les aspects de licence et de propriété intellectuelle plutôt que sur la gestion de la qualité ou l’épuisement des mainteneurs. La Linux Foundation, par exemple, estime que le code généré par l’IA est acceptable à condition que les licences soient compatibles, se préoccupant de la compatibilité des termes des outils IA avec les licences open source. L’Apache Software Foundation, quant à elle, a recommandé dès 2023 la divulgation de l’utilisation de l’IA via un tag “Generated-by:” dans les messages de commit, reconnaissant que c’est un domaine en évolution rapide.
L’Eclipse Foundation met en garde contre la propension aux erreurs de l’IA et rappelle aux contributeurs leur responsabilité d’assurer l’exactitude, suggérant un avertissement sous l’en-tête de copyright. L’OpenInfra Foundation a adopté les étiquettes “Generated-By:” et “Assisted-By:”, exigeant que le code généré par l’IA soit traité comme provenant d’une “source non fiable” et soumis à un examen accru. Cependant, ces directives, bien que pertinentes pour les aspects légaux, n’abordent pas directement la crise de qualité et l’épuisement que subissent les mainteneurs au quotidien. La communauté open source s’interroge sur l’absence de soutien plus concret de la part de ces institutions face à cette marée de “slop” technologique, comme le met en lumière l’article sur le standard émergent “Assisted-by:” pour les contributions AI.
Le manque de guidance sur la qualité et l’épuisement
Le fossé est frappant entre les préoccupations juridiques des fondations et la réalité opérationnelle des mainteneurs. Tandis que les questions de propriété du code généré par l’IA, ou le risque qu’un outil comme Copilot régurgite du code GPL dans un projet sous licence MIT, sont des préoccupations légitimes, elles ne sont pas celles qui poussent Daniel Stenberg à écrire des billets de blog intitulés “Death by a thousand AI slops”. Les mainteneurs sont actuellement submergés par des contributions de faible qualité, mais les fondations n’ont pas encore offert de véritable bouée de sauvetage en matière de contrôle qualité ou de prévention de l’épuisement professionnel.
Ce manque de clarté crée une charge supplémentaire pour les mainteneurs, qui doivent non seulement gérer le flux de code, mais aussi élaborer leurs propres politiques sans un soutien institutionnel solide. Sans directives claires sur la manière de trier, de rejeter ou de gérer ces contributions de manière efficace, l’épuisement des mainteneurs ne fera que s’aggraver. La nécessité d’une intervention des fondations sur ces questions pratiques et humaines est devenue impérative pour préserver la vitalité de l’écosystème open source.
Les “options nucléaires” : les projets qui interdisent les contributions d’IA
Certains projets ont choisi de bannir purement et simplement le code généré par l’IA. C’est un instrument brutal, et ses détracteurs affirment qu’il est inapplicable. Cependant, pour les projets qui ont emprunté cette voie, l’interdiction sert à plusieurs fins au-delà du simple filtrage. Elle écarte les contributeurs opportunistes et envoie un signal fort sur le type de culture que le projet souhaite cultiver. Gentoo Linux, en avril 2024, a interdit toutes les contributions générées par l’IA, citant des préoccupations de copyright, des problèmes de qualité et des questions éthiques, notamment l’impact environnemental de la formation de ces modèles.
Michał Górny, à l’origine de l’interdiction, a expliqué que c’était une excellente démarche de relations publiques pour Gentoo. Il estimait qu’à l’heure où de nombreux projets s’enthousiasmaient pour l’IA, de nombreux utilisateurs de Gentoo appréciaient l’approche “old school” de l’ingénierie logicielle, où les humains comptent plus que la “productivité”. Cette position presque contre-culturelle résonne avec une communauté qui a toujours valorisé l’artisanat plutôt que la commodité. NetBSD a suivi, classant le code généré par LLM comme “corrompu”, interdisant les commits sans approbation écrite préalable de l’équipe principale. Les projets BSD ont une préoccupation supplémentaire : leurs licences permissives les empêchent d’incorporer accidentellement du code GPL, ce que les outils IA formés sur GitHub ont la fâcheuse habitude de reproduire, comme le retrace l’analyse de Shuji Sado sur les théories de propagation de la GPL aux modèles IA.
La portée et les limites des interdictions strictes
Ces “options nucléaires” suggèrent que pour certaines communautés, les risques perçus du code généré par l’IA l’emportent sur tout gain potentiel de productivité. Ces projets choisissent délibérément d’optimiser la confiance et la provenance plutôt que le débit. Cela met en lumière une vérité inconfortable qui ne fera que s’accentuer : l’application de ces interdictions est en grande partie symbolique. À mesure que le code généré par l’IA deviendra de plus en plus indiscernable du code écrit par l’homme, la détection des violations passera de difficile à fonctionnellement impossible.
Le “AI slop” d’aujourd’hui est souvent évident avec ses appels de fonction hallucinés et ses erreurs confiantes. Mais les modèles s’améliorent rapidement. D’ici un ou deux ans, la question ne sera plus “pouvons-nous détecter le code IA ?”, mais “est-ce même important si nous ne le pouvons pas ?”. La véritable signification de ces interdictions pourrait ne pas résider dans leur applicabilité, mais dans ce qu’elles révèlent sur un segment croissant de la communauté open source qui considère le développement assisté par l’IA non pas comme une inévitabilité à gérer, mais comme une menace pour l’entreprise fondamentalement humaine de la création logicielle collaborative.
Désalignement des incitations : les plateformes et le fardeau du mainteneur
La crise du “AI slop” n’est pas seulement un problème technique ou culturel, c’est aussi un problème économique, particulièrement évident dans la relation entre les mainteneurs open source et les plateformes qui hébergent leur travail. En mai 2025, GitHub a lancé une fonctionnalité permettant aux utilisateurs de générer des problèmes via Copilot. Il suffit de décrire un problème à l’IA, qui génère un rapport de bogue que l’utilisateur soumet. L’annonce de GitHub promettait que cela rendrait la création de problèmes “plus rapide et plus facile, sans sacrifier la qualité”. Les mainteneurs ont rapidement émis des réserves sur cette “qualité”.
Immédiatement, des demandes ont été formulées pour bloquer les problèmes générés par Copilot, mais la réponse de GitHub a été négative. Le bot Copilot ne peut être bloqué, et les problèmes qu’il génère n’indiquent pas leur origine IA, apparaissant sous le nom de l’utilisateur humain. Cela rend le filtrage impossible. Pour de nombreux développeurs préoccupés par le “AI slop”, c’est inacceptable. Comme l’a expliqué Andi McClure en mai 2026 sur un problème GitHub, le manque d’outils de filtrage pourrait forcer à des actions drastiques, comme fermer complètement les problèmes et les PRs, et déplacer l’hébergement vers des sites comme Codeberg, un dépôt de code à but non lucratif qui n’intègre pas ces outils hostiles aux mainteneurs.
Les enjeux des mesures de rétention des utilisateurs
Le problème fondamental réside dans l’alignement des incitations. GitHub génère des revenus lorsque les utilisateurs utilisent ses services, et les fonctionnalités IA augmentent les métriques d’engagement. Stefan Prodan a formulé un diagnostic accablant de la situation : “Le AI slop attaque les mainteneurs OSS par déni de service distribué (DDOS), et les plateformes hébergeant les projets OSS n’ont aucune incitation à l’arrêter. Au contraire, elles sont incitées à gonfler les contributions générées par l’IA pour montrer de la ‘valeur’ à leurs actionnaires.” Cette tension place GitHub, en tant que plateforme dominante, au centre de toutes les discussions sur le “AI slop”.
Lorsque GitHub décide que les problèmes générés par Copilot ne peuvent pas être bloqués, cette décision affecte des millions de dépôts. Steve Ruiz a explicitement lié la décision de tldraw de fermer les contributions externes à l’outillage de GitHub, suggérant que cette politique est temporaire en attendant de meilleurs outils. Le message est clair pour GitHub : ses outils risquent de détourner certains mainteneurs des modèles de contribution ouverte. Cependant, la question demeure de savoir si GitHub entendra ce message ou aura les bonnes incitations pour y donner suite. L’entreprise parie probablement que les fonctionnalités basées sur l’IA attireront plus d’utilisateurs qu’elles n’en repousseront, et que les mainteneurs resteront en raison de la force des effets de réseau de GitHub. La crise du “AI slop” déterminera si les mainteneurs s’adapteront, à contrecœur, à un monde où les plateformes optimisent l’engagement plutôt que la maintenabilité.
Naviguer dans l’avenir de l’open source assisté par l’IA
L’état actuel de l’open source est souvent décrit comme une “zone de guerre” pour les mainteneurs, dont le moral est au plus bas, comme l’a exprimé Mitchell Hashimoto en janvier 2026. Cette situation exige des actions concrètes et coordonnées de toutes les parties prenantes. Pour les contributeurs, il est essentiel de faire preuve de transparence et de compréhension. Si l’IA est utilisée, elle doit l’être comme un outil d’assistance, non comme un substitut à la pensée critique. Joshua Rogers a démontré cette approche en aidant Daniel Stenberg à identifier cinquante bogues réels grâce à des outils assistés par l’IA, prouvant que l’IA peut être un atout précieux lorsqu’elle est correctement maîtrisée.
Les mainteneurs, quant à eux, sont encouragés à développer des politiques claires et publiquement documentées, et à ne pas souffrir en silence. Ils ne sont pas seuls dans cette lutte, et leur frustration est légitime. Il est impératif que les plateformes, au lieu de se concentrer uniquement sur les métriques d’engagement, construisent des outils qui servent réellement les maintenurs, leur offrant la capacité de filtrer, bloquer et gérer le flux de contributions. De même, les fondations doivent s’attaquer aux problèmes de qualité et d’épuisement, en plus des questions de licence, qui, bien que cruciales, ne résolvent pas la crise actuelle. Enfin, pour ceux qui soumettent du “AI slop” dans l’espoir de gonfler leur graphique de contributions GitHub avec des PRs sans effort, le message est clair : il est temps d’arrêter.
Le “Assisted-by:” : un standard en devenir
L’émergence du “Assisted-by:” comme un standard de fait dans l’écosystème open source est l’une des avancées les plus significatives pour la gouvernance de l’IA. Ce trailer Git, qui indique qu’un outil IA a aidé un développeur humain à écrire ou à améliorer une contribution, répond à trois impératifs concrets. D’abord, il offre une précision sémantique, car l’utilisation la plus courante de l’IA est l’assistance, où l’humain reste l’auteur et le propriétaire. Ensuite, il assure une clarté juridique, car il maintient le contributeur humain comme le seul auteur et signataire des accords de licence (CLA ou DCO), tout en documentant la participation de l’outil. Enfin, il garantit la lisibilité machine, permettant une analyse facile par les outils CI/CD, les crochets de pré-commit et les outils SBOM.
La convergence de nombreuses fondations et projets sur ce trailer est un signe encourageant. Bien qu’il n’y ait pas encore de norme unique à l’échelle de l’industrie, le “Assisted-by:” représente une solution pratique qui permet aux mainteneurs de trouver les contributions assistées par l’IA lorsque cela est nécessaire. Pour les mainteneurs, l’adoption de cette convention est simple : un paragraphe dans le fichier CONTRIBUTING.md, ou un AGENTS.md, peut faire toute la différence. La gouvernance de l’IA dans l’open source est le défi le plus difficile, et la confiance des communautés dans les versions de 2030 dépendra de la justesse des conventions adoptées aujourd’hui. L’humain est l’auteur, l’outil a assisté, et il est crucial de le marquer comme tel. Pour en savoir plus, consultez l’article sur le problème du “AI slop” menaçant les mainteneurs open source.
- Lire les politiques publiées côte à côte : Apache Software Foundation, Fedora, Linux Kernel, LLVM, OpenInfra, OpenTelemetry et Rocky Linux.
- Commencer par celle qui se rapproche le plus de votre modèle de gouvernance et l’adapter.
- Si votre projet n’a pas encore choisi de trailer, adopter “Assisted-by:” et le documenter là où les contributeurs le liront. La prochaine personne qui examinera votre historique de commits vous en remerciera.
