Méthodologie
L’auteur a passé en revue 102 applications répertoriées sur F-Droid, en examinant les dépôts Git récents, les messages de commit et les éléments visuels (icônes, README). Il a défini un système à trois niveaux : Mostly AI (> 50 % du code supposé généré par LLM), Hard to say / Mostly human (< 50 % de code LLM) et No signs of AI (absence d’indice). La classification repose sur des « odeurs » telles que des icônes générées automatiquement, des README rédigés intégralement par un modèle, ou la présence d’infrastructures d’automatisation de révision de code. Aucun outil automatisé de détection n’a été utilisé ; l’évaluation reste donc subjective et dépend de l’interprétation des commits.
Résultats préliminaires
Parmi les 102 applications, environ 18 % ont été placées dans la catégorie Mostly AI. Ces projets affichent des signes évidents : icônes générées par IA, commits massifs avec des messages génériques, et parfois l’intégration d’outils de revue automatisée qui soumettent les changements sans intervention humaine. Un autre ≈ 45 % se situent dans la catégorie Hard to say / Mostly human, où l’on observe des contributions ponctuelles de LLM mais une majorité de code écrite à la main. Le reste, soit ≈ 37 %, ne montre aucun indice d’utilisation d’IA, souvent accompagné d’une politique explicite interdisant les contributions générées par LLM.
Les observations soulignent que les projets les plus actifs, avec des cycles de release rapides, tendent à présenter davantage d’« odeurs » d’IA, suggérant une corrélation entre pression de livraison et recours aux modèles de langage. En revanche, les applications maintenues par des communautés établies (ex. Nextcloud, LibreContacts) affichent majoritairement le statut No signs of AI.
Limites et perspectives
La principale contrainte de l’étude réside dans l’absence d’un détecteur fiable de code LLM. La classification repose sur des critères visuels et textuels, susceptibles de produire des faux positifs (ex. icônes créées manuellement mais stylisées) ou des faux négatifs (code généré puis fortement refactoré). De plus, l’auteur reconnaît un biais personnel : il exprime une aversion envers les LLM, ce qui peut influencer la sévérité de l’évaluation. Le manque de métriques objectives (par ex. proportion de lignes de code attribuées à un modèle) limite la reproductibilité.
Pour affiner l’analyse, il serait nécessaire de développer un outil d’analyse syntaxique capable de détecter des patterns typiques des modèles de génération (commentaires génériques, fonctions très similaires à des snippets de documentation OpenAI). Une comparaison avec des projets similaires hors F-Droid permettrait également d’évaluer si la tendance observée est spécifique à l’écosystème Android libre ou généralisable à l’ensemble du logiciel libre.
