Flathub's New AI Policy Has Some Problems
Flathub a mis à jour sa politique d’utilisation de l’IA pour interdire explicitement le contenu généré ou assisté par IA dans les soumissions, mais cette politique, bien que compréhensible, souffre d’un manque de clarté et d’exceptions floues qui pourraient créer des inégalité...
SYNTHÈSE STRUCTURÉE
Contexte : pourquoi Flathub a durci sa politique
L’intervenant explique que la décision de Flathub fait suite à une tendance observée dans l’écosystème GNOME, dont Flathub est une filiale. En décembre 2024, GNOME avait déjà interdit les extensions générées par IA dans son store. Flathub a suivi avec une politique similaire, mais plus stricte, en réponse directe à l’afflux de soumissions de mauvaise qualité étiquetées « AI slop ». L’intervenant précise : « This was done in direct response to this. There is a AI slop tag on FlatHub. And as you can see, just in the past day, a bunch of things. » Le problème n’est pas seulement technique : c’est une charge de travail énorme pour des bénévoles non rémunérés.
Détail de la politique : ce qui est interdit
La politique s’applique à la fois aux applications soumises et au processus de soumission lui-même. L’intervenant cite le texte officiel : « This policy applies to both applications being submitted to flatub and the flatub submission itself, including the manifest, metadata, patches, build scripts, and pull request. » Concrètement, cela signifie :
- Les PR de soumission ne doivent pas être générées, ouvertes ou automatisées par des outils IA.
- Les soumissions où la majorité du code est écrit par IA sans apport humain significatif sont interdites.
- Les applications contenant du code, de la documentation ou tout contenu généré ou assisté par IA sont interdites.
- Les soumissions contenant du code incompatible avec les licences ou éthiquement douteux sont également interdites.
L’intervenant souligne que la clause sur les licences est particulièrement pertinente : « a lot of LLMs basically just do code mixing without any real consideration of the licenses being used. »
L’exception cruciale : « mature, well-maintained projects »
La politique prévoit que des exceptions peuvent être accordées aux projets matures et bien maintenus. L’intervenant analyse cette clause en profondeur : « This last part is far more important than you might initially assume it is. » Il démontre que de nombreuses applications populaires sur Flathub utilisent déjà du code assisté par IA, comme Telegram Desktop (Claude comme contributeur principal), Lutris, Gear Lever, ou encore les applications basées sur Electron/Chromium (qui intègrent des dépendances IA). L’exception permet donc à ces projets de continuer à être distribués, même s’ils violent techniquement la politique.
Le problème de la définition floue
L’intervenant identifie un manque de clarté majeur : la politique ne définit pas précisément ce qu’est une « assistance IA ». Par exemple, l’autocomplétion dans un éditeur (comme Copilot) est-elle considérée comme de l’assistance IA ? Bath Lion, le mainteneur, a répondu sur Mastodon que ce n’est « unlikely to be considered a blocker unless you literally tabbed your entire way through with autocomplete ». Mais l’intervenant critique cette approche : « These are not goals that you can aspire to. These are not check marks you can complete. This is a vibe based policy. » Autrement dit, la décision repose sur l’appréciation subjective du relecteur, ce qui crée de l’incertitude.
Le risque de deux poids, deux mesures
L’intervenant cite Tom Holwerda d’OS News : « I don’t think they had any choice in adding this exception, but it does feel a bit like rules for thee, but not for me. I can easily see the relatively small incrowded developers around FlatHub and Flatpack and their friends handing each other exceptions while enforcing much stricter rules when it comes to outsiders. » L’exception pour les projets matures pourrait être utilisée de manière inéquitable, favorisant les projets bien établis et les développeurs proches de l’équipe Flathub, tandis que les nouveaux arrivants seraient soumis à des règles plus strictes.
L’exemple concret : rsync et les régressions
Pour illustrer le problème, l’intervenant prend l’exemple hypothétique de rsync (en imaginant une version GUI sur Flathub). rsync a récemment intégré beaucoup de code généré par Claude, ce qui a causé des régressions et des plaintes. La question se pose : à partir de combien de mauvaises versions un projet mature perd-il son exemption ? L’intervenant souligne que la politique actuelle ne répond pas à cette question, laissant la porte ouverte à des conflits.
Le manque de documentation des critères d’exception
Bath Lion a précisé sur Mastodon que les critères pour l’exception incluent « community engagement, release cadence, CI, and seems to have been more than pure slop produced in three weeks ». Mais l’intervenant note que ces critères ne sont pas documentés dans la politique officielle : « If this is the actual policy, this should be documented as part of the policy because what you basically have right now is do you follow one of the maintainers on Mastodon and know their personal undocumented rules for the submission process? » Cela crée une situation où les soumissionnaires doivent deviner les règles non écrites.
L’absence de rétroactivité : une incohérence potentielle
La politique précise qu’elle ne s’applique pas rétroactivement : les applications déjà publiées restent disponibles. L’intervenant y voit un risque de système à deux vitesses : « what you’ve effectively done is created this sort of two-tier application moderation system where once you pass that initial moderation stage, you’re allowed on FlatHub. Now you effectively don’t have to follow the AI policy. » Les applications déjà acceptées pourraient continuer à utiliser l’IA sans conséquence, tandis que les nouvelles soumissions seraient bloquées.
La charge de travail des bénévoles
L’intervenant insiste sur le contexte humain : la plupart des mainteneurs de Flathub sont bénévoles. L’afflux de soumissions de mauvaise qualité (étiquetées « AI slop ») représente une perte de temps considérable. Il cite Bath Lion : « the number of unpleasant interactions I’ve had with entitled submitters acting as if they were bestowing their brilliant software upon us idiots who are rejecting it went through the roof in the last month. I’m tired. » La politique est donc aussi une réaction à l’épuisement des mainteneurs.
Les perspectives futures : un choc générationnel
L’intervenant anticipe un conflit culturel à venir : « What’s going to happen when a lot of these project leaders become the gray beards and then you have these young Gen A programmers, they become the 20-year-olds, they become the people leading the Foss world. These are people growing up with AI tooling from the very day they write any lines of code. » Les politiques actuelles, même bien intentionnées, pourraient devenir obsolètes ou sources de tensions lorsque la nouvelle génération de développeurs, pour qui l’IA est un outil naturel, prendra les rênes.
CONCEPTS CLÉS
- AI slop : Terme utilisé pour désigner les soumissions de code de mauvaise qualité, générées ou assistées par IA, souvent sans compréhension réelle du code produit.
- Vibe coding : Pratique consistant à générer du code via des prompts IA sans vérification ni compréhension humaine, souvent critiquée pour produire du code non maintenable.
- Code mixing : Phénomène où les LLMs mélangent du code provenant de différentes sources sans respecter les licences, créant des problèmes juridiques potentiels.
- FlatHub : Store d’applications Flatpak, filiale de la GNOME Foundation, qui distribue des applications Linux sandboxées.
CONCLUSION
La politique de Flathub est une réponse compréhensible à un problème réel : l’afflux de soumissions de mauvaise qualité générées par IA submerge les mainteneurs bénévoles. Cependant, son manque de clarté et ses exceptions floues créent un risque d’inégalité de traitement et de conflits futurs. L’intervenant résume bien le dile