Marcin Moskała passe GeminiAI au crible : ce que l'audit révèle sur les coroutines et l'architecture Android

GeminiAI, un projet Android open source, se veut un client Gemini complet qui reprend l'interface d'origine. Il a été audité ligne par ligne par Marcin Moskała, auteur de livres sur Kotlin et formateur certifié JetBrains. L'apparence de l'application n'était pas au centre de l'examen. Marcin Moskała s'est surtout penché sur la qualité de la conception des coroutines, de la structured concurrency et du contrôle du cycle de vie des tâches.

Comment est né GeminiAI

Tout part d'un constat simple. GitHub ne comptait presque aucun client Gemini complet qu'on puisse étudier comme un vrai projet Android à l'architecture réfléchie, et pas comme une simple suite d'appels d'API. L'auteur de l'article a décidé de combler ce manque. Il a développé une application open source qui ne se contente pas d'interroger le modèle : elle montre à quoi peut ressembler un client d'IA moderne sur une stack mobile. L'objectif était double. Il fallait reproduire l'UI de Gemini et, en parallèle, bâtir une base technique qu'on puisse décortiquer couche par couche.

GeminiAI repose ainsi sur Navigation3, Jetpack Compose, Dagger-Hilt, Room, Kotlin Coroutines et Flow. Mais l'enjeu principal n'était pas d'aligner des technologies en vitrine. Il s'agissait de maîtriser le comportement de l'application sous charge : streaming des réponses, gestion du contexte de la conversation, annulation correcte des opérations et absence de fuites mémoire. Pour l'auteur, c'était aussi un défi d'ingénierie personnel. Il sortait d'entretiens d'embauche difficiles, où les questions d'architecture pesaient régulièrement plus lourd que la capacité à coder vite une fonctionnalité à l'écran.

L'audit de Moskała

L'étape suivante s'est révélée bien plus exigeante qu'une code review classique. En décembre 2025, le projet a été examiné lors d'un workshop de Marcin Moskała, littéralement ligne par ligne. Ce format fait vite apparaître la différence entre un code qui fonctionne, sans plus, et un code qui tient face à la croissance, aux annulations de tâches et aux scénarios asynchrones complexes. Pour une application d'IA, c'est particulièrement critique. Les erreurs dans les coroutines ne se voient pas toujours tout de suite, mais elles finissent en requêtes bloquées, en états superflus et en bugs d'UI difficiles à traquer.

Selon l'auteur, l'audit ne s'est pas réduit à une vérification de forme. Marcin Moskała a été ajouté aux contributors du dépôt, et le projet a été salué comme un exemple pédagogique de qualité sur les coroutines dans le développement Android. Le signal compte pour la communauté open source. La valeur de GeminiAI ne tient pas à la reproduction d'une interface de chatbot familière. Elle tient à la discipline d'ingénierie dont il fait preuve là où beaucoup de projets se limitent à une surcouche de démo plaquée sur une API.

«

Le code est fiable et bien structuré : c'est un excellent exemple pour apprendre les coroutines sous Android. »

Ce qui a été examiné

L'analyse s'est concentrée sur la structured concurrency. Dans cette approche, chaque opération asynchrone vit dans un périmètre de responsabilité clairement défini et ne se perd pas après la fermeture d'un écran ou l'annulation de la tâche parente. L'article rattache ce principe à une idée plus large : lancer des opérations en arrière-plan sans contrôle est aussi dangereux pour une application moderne que les sauts GOTO à répétition l'étaient pour le code d'autrefois. Quand les tâches n'ont pas de durée de vie clairement bornée, l'application en paie le prix en mémoire, en ressources et en 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 de la fin : le parent scope ne se ferme pas tant que tous les launch et async qu'il contient ne sont pas terminés.
• Annulation automatique : en cas d'erreur ou d'arrêt du parent, l'arbre de tâches se replie sans nettoyage manuel.
• Frontière de responsabilité : la logique lourde est déportée dans ChatRepository, tandis que le contrôle de l'annulation reste du ressort du ViewModel.
• Comportement de l'UI : à la fermeture de l'écran, les requêtes vers l'API et la base de données doivent se terminer proprement, sans opérations en suspens.

Après ce travail, le sujet a dépassé le cadre d'un seul dépôt. L'auteur a rédigé un article sur la structured concurrency en s'appuyant sur les idées d'Edsger Dijkstra sur la nocivité des sauts non structurés, et a transposé ce débat dans l'univers des coroutines. Pour le développement mobile, ce pont entre computer science et pratique a un intérêt concret : il permet de justifier les choix d'architecture non par les goûts de l'équipe, mais par la logique fondamentale de la gestion de la complexité. Il montre aussi pourquoi l'annulation des tâches n'est pas un détail d'implémentation, mais une composante de l'architecture.

Ce que cela signifie

L'histoire de GeminiAI illustre une idée simple. Dans les applications d'IA, l'avantage ne revient pas seulement à celui qui branche le modèle le plus vite, mais aussi à celui qui construit avec soin l'architecture autour du streaming, de l'annulation des tâches et du cycle de vie de l'interface. Pour les développeurs Android, le signal est encourageant : même un projet parti d'une copie de Gemini peut devenir une référence, à condition que les coroutines, les frontières de responsabilité et le comportement en conditions réelles soient vraiment pensés. Ce sont ces détails qui séparent un pet project d'apprentissage d'un code sur lequel on peut s'appuyer en production.