Actualité
Google montre comment les applications Android répartissent l’IA entre le cloud et l’appareil
Les dernières recommandations de Google pour les développeurs Android utilisent l’application de voyage Jetpacker pour montrer comment l’IA cloud, embarquée et hybride peut fonctionner ensemble.
Google a publié une nouvelle mise à jour technique expliquant comment les développeurs Android peuvent répartir les charges de travail liées à l’intelligence artificielle entre l’appareil, le cloud ou les deux. L’article du blog Android Developers, publié le 21 juillet, utilise Jetpacker, une application de voyage open source, pour illustrer les compromis pratiques derrière les fonctionnalités d’IA modernes.
Ces recommandations s’adressent aux développeurs qui créent des applications Android intelligentes, et non aux consommateurs qui attendent une nouvelle mise à jour système. Leur message central est qu’il n’existe pas un emplacement idéal unique pour exécuter chaque modèle. Le traitement cloud peut fournir des connaissances plus larges et des fenêtres de contexte plus importantes, tandis que l’inférence sur l’appareil peut réduire la latence, limiter les transferts de données et maintenir certaines fonctionnalités sans connexion internet. L’inférence hybride est présentée comme un moyen de combiner ces avantages lorsque la compatibilité et les coûts d’exploitation entrent également en jeu.
Une application exemple, trois stratégies d’IA différentes
Jetpacker est conçue pour aider les utilisateurs à planifier et gérer leurs voyages. Google utilise l’application pour montrer qu’un même produit peut recourir à différentes architectures d’IA selon la tâche. Les fonctionnalités qui traitent des informations privées ou des tâches relativement simples peuvent fonctionner localement, tandis que les demandes nécessitant des informations récentes ou un raisonnement plus complexe peuvent être envoyées à des modèles cloud.
Le premier exemple est un assistant de musée. Un modèle local peut ne pas connaître les dernières dates d’exposition, les règles de billetterie ou les horaires d’ouverture. Jetpacker utilise donc Firebase AI Logic avec des outils d’ancrage. L’exemple peut ajouter au contexte du modèle des informations provenant d’une page web précise, de Google Search ou de Google Maps avant de générer une réponse. Cette approche vise à rendre les réponses plus pertinentes pour un lieu donné et plus utiles pour les questions dont les réponses peuvent évoluer avec le temps.
L’exemple de Google illustre également une limite importante : l’ancrage ne dispense pas les développeurs de choisir des sources fiables et de concevoir des contrôles adaptés. Un modèle ne peut travailler qu’avec le contexte qu’il reçoit. Les équipes chargées des applications doivent donc toujours décider quels sites web, données cartographiques ou autres services peuvent être considérés comme fiables avant de présenter une réponse aux utilisateurs.
L’inférence hybride maintient le traitement local dans la boucle
Le deuxième exemple est une fonctionnalité d’évaluation de restaurant. Jetpacker tente de générer une première version de l’avis sur l’appareil à l’aide de Gemini Nano, puis bascule vers un modèle cloud sur les appareils qui ne prennent pas en charge la capacité locale requise. Google présente cette méthode comme un moyen de rendre une fonctionnalité disponible sur une base plus large d’appareils Android, sans renoncer aux avantages potentiels de l’exécution locale en matière de confidentialité et de coûts.
L’API Firebase Hybrid Inference prend en charge quatre choix de routage : PREFER_ON_DEVICE, PREFER_IN_CLOUD, ONLY_ON_DEVICE et ONLY_IN_CLOUD. Dans l’exemple Jetpacker, l’application privilégie le traitement local, mais peut utiliser le cloud comme solution de repli. Les développeurs peuvent choisir un mode plus strict lorsqu’une fonctionnalité doit rester locale, ou donner la priorité au cloud lorsqu’un raisonnement plus riche est plus important que la disponibilité hors ligne.
Cette décision a des conséquences directes sur l’expérience utilisateur. L’inférence locale peut réduire la dépendance au réseau, mais elle dépend d’un matériel compatible, de la disponibilité du modèle et des ressources de l’appareil. L’inférence cloud peut prendre en charge des modèles plus performants, mais elle impose une connexion et peut augmenter la latence ou les coûts d’exploitation. Un routage hybride offre une option supplémentaire, à condition que l’application gère clairement les changements d’état du réseau et de disponibilité des modèles.
La traduction montre pourquoi le routage peut nécessiter des règles personnalisées
Le chat d’assistance hôtelière de Jetpacker illustre une configuration plus complexe. L’application commence par identifier la langue d’un message entrant avec ML Kit. Elle achemine ensuite certaines paires de langues vers un modèle sur l’appareil et envoie les autres cas vers un modèle cloud. L’exemple utilise une logique personnalisée plutôt qu’une règle universelle unique, ce qui permet à l’application de tenir compte de la langue, de la compatibilité de l’appareil et des besoins de la conversation.
C’est utile pour les applications internationales, car la qualité de la traduction, la prise en charge des modèles et les exigences de confidentialité peuvent varier selon la langue. Un développeur peut conserver sur l’appareil les paires de langues courantes tout en envoyant les combinaisons moins bien prises en charge vers un service cloud. L’exemple de Google montre le mécanisme, mais ne prétend pas que chaque langue ou chaque appareil produira des résultats identiques. Les équipes doivent toujours évaluer leurs propres langues prises en charge et définir ce qui se passe lorsqu’un modèle ne peut pas répondre avec suffisamment de confiance.
L’article souligne également le travail de sécurité requis lorsqu’une application Android envoie des requêtes d’IA vers le cloud. Pour les requêtes de production, Jetpacker intègre Firebase App Check à Play Integrity et utilise un fournisseur de débogage pendant le développement local. L’exemple de Google initialise une authentification anonyme dans le cadre du pipeline de l’application. Ces contrôles visent à limiter l’utilisation non autorisée des API et à réduire les risques de facturation imprévue ou d’abus.
Ce que cela signifie pour les développeurs Android
La mise à jour de Google consiste moins à lancer une nouvelle fonctionnalité unique qu’à fournir aux développeurs un cadre de décision. Les équipes peuvent partir des données de l’utilisateur et des exigences de la tâche : les documents sensibles peuvent favoriser le traitement sur l’appareil, les informations locales récentes peuvent nécessiter un ancrage, et la compatibilité avec un large éventail d’appareils peut bénéficier d’une solution de repli dans le cloud.
Cette approche encourage également les développeurs à exposer honnêtement les situations d’échec. Si un appareil ne dispose pas de Gemini Nano, l’application doit rendre son comportement de repli prévisible. Si une requête nécessite un accès au cloud, l’interface doit tenir compte de l’utilisation hors ligne, des délais et du consentement. Si un modèle rédige un texte ou traduit un message, les utilisateurs doivent pouvoir vérifier le résultat avant de le partager.
Pour les utilisateurs Android, le résultat concret peut être moins visible qu’une interface repensée. La même application peut répondre plus rapidement dans une situation, fonctionner hors ligne dans une autre et consulter les informations actuelles du web ou des cartes lorsque cela est nécessaire. Ces améliorations dépendent d’un routage soigneux, du choix des sources et de contrôles de sécurité, plutôt que de la seule présence d’une marque d’IA. L’exemple Jetpacker de Google constitue une référence concrète pour les développeurs qui souhaitent intégrer cet équilibre à leurs propres applications.
Sources et éléments probants