Marcin Moskala a audité GeminiAI : ce que la révision a révélé sur les coroutines et l'architecture Android

Le projet Android ouvert GeminiAI, conçu comme un client Gemini complet avec une réplique de l'interface originale, a subi un audit ligne par ligne dirigé par Marcin Moskala — auteur de livres sur Kotlin et instructeur certifié par JetBrains. L'objectif de l'examen n'était pas l'apparence de l'application, mais plutôt la façon dont les coroutines, la concurrence structurée et le contrôle du cycle de vie des tâches y étaient organisés.

Comment GeminiAI a Émergé

L'histoire a commencé par une observation assez simple : GitHub avait presque aucun client Gemini complet qui pourrait être étudié non pas comme un ensemble d'appels API, mais comme un projet Android normal avec une architecture bien réfléchie. L'auteur de l'article a décidé de combler cette lacune et d'assembler une application open-source qui non seulement appelle le modèle, mais démontre également à quoi pourrait ressembler un client IA moderne sur une pile mobile. L'objectif était double : répliquer l'interface du Gemini original tout en construisant simultanément une base technique pouvant être analysée couche par couche.

En conséquence, GeminiAI a été construit en utilisant Navigation3, Jetpack Compose, Dagger-Hilt, Room, Kotlin Coroutines et Flow. Cependant, la tâche clé n'était pas de présenter les technologies, mais plutôt le comportement de l'application sous charge : streaming de réponses, gestion du contexte de dialogue, annulation correcte des opérations et absence de fuites mémoire. Pour l'auteur, c'était aussi un défi d'ingénierie personnel après des entretiens difficiles, où les questions d'architecture s'avéraient régulièrement plus importantes que la capacité à implémenter rapidement une fonctionnalité à l'écran.

L'Audit de Moskala

L'étape suivante s'avéra être beaucoup plus rigoureuse qu'un examen de code typique. En décembre 2025, le projet a participé à un atelier de Marcin Moskala, où l'analyse s'est déroulée littéralement ligne par ligne. Ce format est important car il révèle rapidement la différence entre du code qui fonctionne simplement et du code qui résiste à la croissance, aux annulations de tâches et aux scénarios asynchrones complexes. Pour les applications d'IA, c'est particulièrement critique : les erreurs de coroutine ne sont pas toujours immédiatement visibles, mais se transforment ensuite en requêtes qui pendent, états redondants et bogues d'interface difficiles à détecter.

Selon l'auteur, l'audit n'a pas pris fin avec une vérification formelle. Marcin a été ajouté aux contributeurs du dépôt, et le projet lui-même a reçu une évaluation comme un exemple pédagogique de qualité sur les coroutines pour le développement Android. C'est un signal important pour la communauté open-source : la valeur de GeminiAI s'avéra non pas dans sa réplication d'une interface de chatbot familière, mais dans la démonstration de la discipline d'ingénierie où de nombreux projets se contentent d'un emballage de démonstration sur une API.

"Le code s'avéra fiable et bien structuré — c'est un exemple fort pour étudier les coroutines sous

Android".

Ce Qui Exactement a Été Examiné

Le thème central de l'examen était la concurrence structurée — une approche dans laquelle chaque opération asynchrone vit au sein d'une portée claire de responsabilité et n'est pas perdue après la fermeture de l'écran ou l'annulation de la tâche parent. Dans l'article, ceci est lié à une idée plus large : le lancement incontrôlé d'opérations en arrière-plan dans une application moderne est aussi dangereux que les sauts infinis de GOTO dans l'ancien code. Si les tâches n'ont pas de limites de vie claires, l'application commence à payer pour cela avec la mémoire, les ressources et la prévisibilité.

• Héritage du contexte : les coroutines enfants reçoivent les paramètres du parent, y compris le dispatcher et les règles d'exécution.
• Attente d'achèvement : la portée parent ne se ferme pas tant que toutes les opérations launch et async en son sein ne sont pas terminées.
• Annulation automatique : en cas d'erreur ou d'arrêt du parent, l'arbre des tâches s'effondre sans nettoyage manuel.
• Limite de responsabilité : la logique lourde est extraite vers ChatRepository, tandis que le contrôle d'annulation reste avec ViewModel.
• Comportement dans l'interface : lorsque l'écran se ferme, les requêtes API et base de données doivent se terminer correctement, sans opérations qui pendent.

Suite au travail sur le projet, le sujet s'est étendu au-delà d'un seul dépôt. L'auteur a préparé du matériel sur la concurrence structurée basé sur les idées d'Edsger Dijkstra sur les dangers des sauts non structurés et a transféré ce débat au monde des coroutines. Pour le développement mobile, un tel pont entre l'informatique et la pratique est utile car il aide à expliquer les décisions architecturales non pas par le goût de l'équipe, mais par la logique fondamentale de gestion de la complexité. En même temps, il montre pourquoi l'annulation des tâches n'est pas un détail mineur de mise en œuvre, mais partie de l'architecture.

Ce Que Cela Signifie

L'histoire de GeminiAI montre une chose simple : dans les applications d'IA, le succès revient non seulement à ceux qui ont connecté le modèle le plus rapidement, mais aussi à ceux qui ont soigneusement assemblé l'architecture autour du streaming, de l'annulation des tâches et du cycle de vie de l'interface. Pour les développeurs Android, c'est un bon signal : même un projet qui a commencé comme une copie de Gemini peut devenir une référence s'il a vraiment des coroutines bien réfléchies, des limites de responsabilité claires et un comportement d'application dans des scénarios réels. Ce sont précisément ces détails qui séparent un projet d'apprentissage du code qui peut être utilisé comme base en production.