F-Droid : environ 70 % des applications contiendraient du code généré par IA
En bref
- Un développeur a analysé 130 applications de F-Droid (un magasin d'applis Android libres) et conclut que ~70 % présenteraient des indices d'utilisation d'IA, notamment via des commits en masse, des README génériques ou des patterns d'automatisation.
- L'auteur précise que LLM n'équivaut pas à « mauvaise qualité » et a recalibré environ 10 apps après publication, mais le ratio reste élevé.
- Le débat HN conteste largement la méthodologie : difficulté à diagnostiquer l'IA par le code seul, biais potentiels (gros commits peuvent être humains), et surtout la question implicite : pourquoi cela poserait-il problème si les apps fonctionnent ?
Ce que dit la source
L'auteur observe que depuis 2022 il est devenu difficile de trouver du logiciel clairement écrit à la main. Naviguant sur F-Droid, il s'est demandé quelle proportion des applications repose sur du code généré par IA. Il présente une analyse de 130 apps classées selon des critères (commits en masse, absence de révision, READMEs boilerplate, autorisations suspectes, absence d'historique git cohérent) et conclut qu'environ 70 % montrent des « signes » d'implication d'IA. L'auteur souligne que cela n'invalide pas les projets : beaucoup d'équipes compétentes encadrent les sorties d'IA, et il s'agit d'une démarche exploratoire faite « pour s'amuser ».
- Méthodologie : l'auteur reconnaît l'impossibilité d'une certitude absolue (le texte seul ne porte pas assez de métadonnées) mais pointe des indices systématiques : commits massifs, absence de code review, READMEs génériques
- Autocorrection : ~9-10 apps ont été recatégorisées à la hausse (plus humaines qu'initialement jugées) après seconde relecture
- Deux cas flagrants : DuressKeyboard et UnlicenseLauncher éditées uniquement via l'interface web GitHub, jamais via git
- L'étude prédatée : beaucoup d'apps analysées existaient avant 2022, donc le label « AI » peut être anachronique ou discutable
Dans les commentaires
Débat partagé, mais plutôt sceptique envers la méthodologie. Une part importante des commentateurs conteste soit le diagnostic (overcounting, confusion entre signes faibles et preuve d'IA), soit sa pertinence (si l'app fonctionne, pourquoi s'en soucier ?). Les points de friction sont solides : confondre « gros commit initial » avec « codé par IA », exemple du Yubico Authenticator cité comme mal classé, et le biais temporel (les vibe-coders ayant peut-être plus de releases, ils remontent davantage dans les listes).
- Critique sur la méthodologie : plusieurs commentateurs (jraph, pona-a) relèvent des cas mal classés et demandent plus de détails sur le raisonnement ; exemple concret du Yubico Authenticator (Flutter officiel Yubico) dont le code ne montre pas de signes d'IA mais que l'auteur a pourtant marqué.
- Ambiguïté temporelle : Dwedit note que des projets antérieurs à 2022 ne peuvent pas être « générés par IA » au sens strict, or la liste en contient.
- Acceptation pragmatique de l'IA en prod : edg5000, samayashar et lrvick défendent l'usage d'IA comme outil normal (version 2026 du métier), pas comme bêtise ; lrvick détaille un exemple credible (init system Rust 1500 lignes, avec audit et test suite).
- Critique éthique : tonymet et alienbaby tournent la question : les apps sont gratuites, libres de licence, et si elles fonctionnent, pourquoi exiger de la « belle » écriture humaine ? Reproche d'élitisme aux consommateurs open source.
- Débat limité sur les risques de sécurité : t1234s soulève un vrai point (apps malveillantes achetées et modifiées), mais isolé, pas de fil substantiel dessus.
Notre lecture
Étude intéressante comme instantané du ratio apparent d'IA dans F-Droid, mais ni la méthodologie ni la question ne sont aussi solides qu'elles semblent. L'auteur le reconnaît d'ailleurs dès l'intro. Le vrai débat, qui se dessine dans HN, est ailleurs : (1) peut-on diagnostiquer l'IA au code ? probablement pas avec certitude ; (2) devrait-on s'en soucier ? seulement si impact réel sur sécurité ou maintenance, pas pour une question de pureté. La vague d'utilisation d'IA en développement est réelle (2026 oblige), mais confondre « beaucoup de code traversé par une IA » et « application bâclée » est un raccourci. À noter : plusieurs commentateurs expérimentés soulignent que les LLMs bien encadrés produisent du code solide. Aucune action immédiate pour une DSI ; surtout un signal qu'en FOSS comme ailleurs, l'IA est maintenent un outil banal, et qu'il faut s'y habituer plutôt que de la chasser.