Android 17 fait passer l’IA sur l’appareil en production : le playbook du CTO pour une intelligence mobile privée et rap

Si votre IA mobile dépend encore d’un réseau capricieux, vous habituez vos utilisateurs à vous quitter. Android 17 arrive sur les Pixel et se diffuse chez les OEM au moment même où les modèles à poids ouverts comme GLM‑5.2 franchissent un cap de qualité et où « exécuter des modèles locaux, c’est (vraiment) bien maintenant » cesse d’être un mème. Avec des NPU à 30–60+ TOPS sur les appareils premium 2025–2026, 8–16 Go de RAM sur le milieu/haut de gamme et des fonctionnalités d’IA au niveau de la plateforme, les LLM et la vision sur l’appareil relèvent enfin d’une décision produit — plus d’une démo.

Cet article est votre cadre de décision : ce qui a réellement changé, trois architectures viables (IA de plateforme, modèle embarqué, hybride), le véritable calcul de TCO, les risques que vous endosserez et un plan sur 90 jours pour livrer quelque chose que les utilisateurs ressentent. Nous parlerons d’Android 17 en particulier, mais le même raisonnement s’applique à Wear OS 7 et aux premiers facteurs de forme XR qui émergent autour d’Android.

Ce qui a changé en 2026 (et pourquoi c’est important)

• Android 17 intègre des hooks IA plus profonds. L’assistant au niveau système de Google est plus étroitement intégré, et les OEM exposent les chemins vers les accélérateurs via des runtimes familiers. Vous disposez de moyens plus simples d’invoquer du texte et de la vision sur l’appareil sans aller‑retour vers le cloud. Ce n’est pas de la magie — juste moins de glue code et un meilleur ordonnancement.
• Les poids ouverts ont rattrapé leur retard. GLM‑5.2 domine désormais les classements communautaires, et plusieurs familles de 7–14B paramètres (Qwen, variantes de Llama) offrent un raisonnement utile en quantification 4 bits sur des NPU mobiles. Vous n’avez plus besoin d’un modèle cloud 70B pour autocompléter une réponse d’assistance ou résumer un article.
• La marge matérielle est réelle. Les smartphones Android premium soutiennent désormais 30–60 TOPS sur les NPU, avec des clusters CPU big.LITTLE en filet de sécurité. Résultat : des latences par token de 50–150 ms pour des modèles 7B en 4 bits à des contextes modestes, et des embeddings d’images suffisamment rapides pour du reranking ou de la classification OCR sur l’appareil. Vous atteindrez encore des plafonds thermiques, mais pas tout de suite.
• Pression sur la confidentialité et différenciation de marque. Les utilisateurs et les régulateurs n’aiment pas « tout envoyer dans le cloud » — surtout pour la voix, la caméra et les transcriptions d’assistance. L’exécution sur l’appareil vous permet d’affirmer « traité localement » et de le prouver. Le portage de GrapheneOS vers Android 17 le rappelle : des segments « privacy‑first » existent, et ils s’expriment.

Les trois architectures qui ne gâcheront pas vos deux prochains trimestres

1) Intégration à l’assistant de la plateforme (le chemin le plus rapide vers de la valeur pour l’utilisateur)

Utilisez l’assistant système d’Android et les intents comme votre LLM. Vous poussez le contexte utilisateur et les tâches vers un runtime de confiance sur l’appareil et vous récupérez les résultats, en gardant votre application légère. C’est l’option « ne soyez pas trop malin ».

• Avantages : Ops ML minimales. Un ordonnancement serré par l’OS vous donne une latence et une consommation correctes. Vous « héritez » des améliorations d’accessibilité, de clavier et multimodales sans effort.
• Inconvénients : Dépendance au fournisseur et surfaces d’API qui évoluent hors de votre contrôle. Plus difficile de garantir le comportement du modèle pour des parcours réglementés. Capacité limitée à ajuster, mettre en cache ou forcer l’hors‑ligne quand l’OS en décide autrement.
• À choisir quand : Vous avez besoin d’une UX IA hier — autocomplétion, résumé, actions rapides — sans équipe de recherche. Votre différenciateur est la qualité de l’UX, pas un comportement de modèle sur‑mesure.

2) Modèle à poids ouverts embarqué (votre modèle, vos règles)

Intégrez un modèle quantifié de 7–14B et exécutez‑le via TensorFlow Lite, ExecuTorch, ONNX Runtime ou MLC LLM, en visant d’abord le NPU, puis le GPU, et en dernier le CPU. Stockez les poids comme un asset à la demande, pas dans l’APK de base.

• Avantages : Contrôle total des prompts, des garde‑fous et du cache. Hors ligne par défaut. Latence prévisible. Vous pouvez A/B tester des modèles et itérer sans attendre les releases de l’OS.
• Inconvénients : Taille d’application et coûts d’egress. Fragmentation des appareils. Vous possédez les budgets thermiques et mémoire. Et il n’existe aucun moyen parfait de « cacher » les poids — supposez leur extraction.
• À choisir quand : La confidentialité ou le hors ligne est non négociable. Vous avez besoin d’un comportement déterministe (p. ex., sorties contraintes par un template). Vous voulez faire tourner un petit planificateur ou reranker local pour un agent hybride.

3) Hybride local+cloud (pratique pour la plupart des produits)

Faites tourner un petit modèle local pour les boucles très proches de l’UI — classification d’entrée, reranking, résumés sur l’appareil. Escaladez vers un modèle cloud pour le raisonnement lourd ou la recherche. Décidez par session en fonction de la batterie, de la thermique et du budget de coût.

• Avantages : Le meilleur des deux mondes. UX plus fluide et confidentialité pour 80 % des interactions simples. Le cloud gère les cas difficiles.
• Inconvénients : Vous opérez maintenant deux chemins d’inférence et un moteur de politique. Si votre télémétrie est approximative, vous livrerez une promesse de confidentialité impossible à prouver.
• À choisir quand : Vous avez un MAU significatif et un plafond de coûts. Vous avez besoin de fiabilité sur un parc d’appareils bruyant sans sacrifier des expériences privées/instantanées.

Le calcul TCO que votre CFO respectera vraiment

Les coûts des LLM cloud varient énormément, mais la structure est la même : vous payez au token, indéfiniment, et vous êtes exposé aux changements de tarifs des fournisseurs. Sur l’appareil, c’est l’inverse : vous payez la distribution et la maintenance, principalement en amont.

Une comparaison à la louche

• Supposons 200 k MAU Android, chacun effectuant 10 courts prompts/jour (moyenne 150 tokens entrants + 150 sortants = 300 tokens). Cela fait 600 M de tokens/jour.
• Cloud uniquement : à un prix effectif médian de 2 $ par 1 M de tokens, vous êtes à 1 200 $/jour, soit ~36 k$/mois. Si votre session moyenne grimpe à 1k tokens, vous triplez la note.
• Modèle 7B sur l’appareil : livrez un fichier de poids de 1,5 Go + 0,5 Go d’assets via une distribution à la demande. Avec un egress CDN à 0,05 $/Go, le premier déploiement à 200 k utilisateurs coûte ~20 k$ one‑shot. Les deltas mensuels à 400 Mo seraient ~4 k$ si tout le monde met à jour. Vos coûts d’infra en régime établi sont sinon proches de zéro.
• Hybride : si 80 % des tâches restent locales et 20 % escaladent, votre facture cloud tombe à ~7 k$/mois, avec les mêmes coûts de distribution qu’au‑dessus.

Même si votre egress est multiplié par 2–3 et que vous ajoutez 10–20 k$/mois en ingénierie Android/ML senior, vous êtes souvent au niveau ou en dessous d’un tout‑cloud dès le mois 2–3, avec une meilleure UX et un argument confidentialité plus fort. Le point de croisement arrive d’autant plus vite que l’intensité d’usage augmente.

Contraintes d’ingénierie impossibles à ignorer

Thermique et batterie

• Le budget de tokens prime sur le débit maximum. Gardez le contexte petit. Utilisez des prompts structurés et des sorties courtes. Si vous avez besoin d’un contexte 16k+, le cloud l’emporte.
• Planifiez en bon citoyen. Préférez des inférences locales brèves qui se terminent en moins d’une seconde. Respectez les signaux de batterie et de température. Basculez vers le cloud quand le throttling se déclenche.

Mémoire et stockage

• Memory‑mappez tout ce que vous pouvez. Utilisez mmap pour les poids et le cache KV lorsque c’est pris en charge. Ne laissez pas l’ART GC entrer en conflit avec vos allocations natives — isolez les durées de vie.
• Quantifiez de manière agressive. Les poids en INT4/INT8 et la quantification du cache KV comptent davantage sur mobile que sur serveur. La différence entre 7B et 13B peut se traduire par « installation ou désinstallation ».

Matrice d’appareils

• Conditionnez les fonctionnalités aux capacités. Détectez la RAM, le NPU et les profils thermiques au premier lancement. Proposez « Mode privé (sur l’appareil) » sur les appareils haut de gamme ; par défaut, hybride sur le milieu de gamme ; autorisez un mode « Cloud uniquement » en repli.
• Distribuez les modèles dynamiquement. Utilisez Play Asset Delivery ou votre propre CDN d’assets. Ne gonflez jamais l’APK de base.

Sécurité et licences

• Supposez que les poids fuient. N’insérez pas de secrets dans les prompts. Considérez votre modèle sur l’appareil comme redistribuable du point de vue de la menace.
• Lisez la licence. Certains poids ouverts restreignent l’usage commercial ou exigent une attribution. Intégrez la conformité dans votre pipeline de build.

Patterns produit qui fonctionnent vraiment sur l’appareil

• Autocomplétion et réponses suggérées : boucles de latence très serrées avec sorties templatisées. Livrez un modèle 7B avec un décodeur contraint et la sensation d’instantanéité sera là.
• Résumés et extraits saillants : e‑mail, documents, fils de discussion. Découpez, résumez localement, puis n’escaladez qu’en cas de « deep dive ».
• Classification sur l’appareil et tri OCR : détection de spam, contenus sensibles, extraction de reçus. Vous évitez d’envoyer les photos des utilisateurs vers vos serveurs.
• Reranking et planification pour des agents : utilisez un petit modèle local pour choisir des outils ou prioriser des actions. Demandez au cloud quand le plan devient complexe.

Là où le sur‑appareil est une mauvaise idée : génération multimodale lourde, long contexte RAG sur des bases de connaissances personnelles, ou parcours juridiques/conformité nécessitant des sorties déterministes et auditables que votre pile mobile ne peut pas garantir.

Une pile minimale viable pour l’IA sur l’appareil avec Android 17

• Runtime : commencez avec TensorFlow Lite ou ExecuTorch pour couvrir largement les chemins matériels. Gardez MLC LLM en réserve pour itérer vite spécifiquement sur les LLM.
• Modèle : un 7B à poids ouverts éprouvé (GLM‑5.2‑7B, Qwen‑7B ou équivalent) quantifié en INT4. Fine‑tune hors de l’appareil ; livrez des adaptateurs si votre runtime les prend en charge.
• Assets : distribuez les modèles via Play Asset Delivery en « install‑time optional » ou à la demande ; vérifiez le checksum ; prenez en charge les mises à jour delta.
• Repli : un endpoint cloud avec quotas stricts et disjoncteurs. Quand l’appareil est chaud, faible en batterie ou sous 6 Go de RAM, escaladez automatiquement.
• Télémétrie : compteurs préservant la confidentialité : tokens traités, percentiles de latence, événements de throttling thermique, tags de capacités d’appareil. Pas de logs de contenu.

Articulation avec Wear OS 7 et les premières XR

Les wearables et les nouvelles lunettes XR exigent des interactions <100 ms et des budgets thermiques encore plus stricts. Le schéma pragmatique est : classer ou générer du texte court sur l’appareil (ou le téléphone appairé), puis escalader vers le téléphone/cloud pour le long format. Les évolutions du multitâche et de l’exécution en arrière‑plan d’Android 17 aident ici — votre application hôte sur le téléphone peut porter le modèle plus lourd et transmettre les résultats à la montre ou aux lunettes via des canaux à faible latence.

Équipe et processus : qui fait le travail

• Android core : 2–3 seniors Kotlin qui maîtrisent les cycles de vie, le travail en arrière‑plan et la distribution via Play.
• Native/ML : 1–2 ingénieurs à l’aise avec NDK/C++ et au moins un runtime d’inférence mobile. C’est là que la plupart des équipes sous‑investissent.
• Ingénieur ML : 1 personne pour gérer la quantification, les harnais d’évaluation et le fine‑tuning hors de l’appareil.
• QA et perf : 1 ingénieur d’automatisation pour monter un labo de perf sur 6–8 appareils cibles avec 6–8 heures/jour de recouvrement avec votre équipe US.

Le vivier de talents Android de Brazil est profond — les ingénieurs seniors avec expérience en Kotlin, NDK et TensorFlow Lite ne sont pas rares. L’avantage pratique des pods nearshore est simple : vous pouvez lancer des expériences de perf quotidiennes sur des heures partagées et livrer chaque semaine sans réveiller qui que ce soit à 3 a.m.

Registre des risques (pour éviter les surprises à la semaine 7)

• Régressions thermiques sur les appareils milieu de gamme : votre 99e percentile n’est pas sur un flagship. Mettez des garde‑fous tôt ; ne découvrez pas cela en bêta.
• Dérive de modèle et incohérences UX : si vous A/B testez des modèles, votre centre d’aide et vos scripts QA deviendront obsolètes. Versionnez vos prompts et sorties.
• Promesse légale vs réalité : si vous communiquez « sur l’appareil », vous devez le prouver. Auditez chaque chemin. Si même 10 % des parcours vont dans le cloud, écrivez « hybride » dans la copie.
• Contre‑coup lié au gonflement de l’app : un téléchargement initial de 2 Go en cellulaire vous vaudra des notes 1 étoile. Par défaut, privilégiez le Wi‑Fi et expliquez le choix.

Votre plan de livraison sur 90 jours

Jours 0–30 : prouver la boucle locale

• Choisissez un seul flux visible utilisateur (p. ex., suggestions de réponse) avec un budget de tokens <200 et un budget de latence <200 ms.
• Intégrez un modèle 7B INT4 via TensorFlow Lite ou ExecuTorch comme asset à la demande. Mesurez latence P50/P95, impact batterie par session et taux de throttling sur 4 appareils.
• Implémentez un moteur de politique basique : choisissez local vs cloud selon la RAM de l’appareil, la batterie et l’état thermique.
• Mettez en place une télémétrie préservant la confidentialité. Aucun contenu, uniquement des compteurs et timings.

Jours 31–60 : rendre le tout robuste

• Portez le déploiement des fonctionnalités selon la capacité de l’appareil. Proposez un réglage : Privé (sur l’appareil), Équilibré (Hybride), Cloud uniquement.
• Ajoutez une gestion en arrière‑plan des assets de poids et des patchs delta. Vérifiez les checksums et reprenez les téléchargements interrompus.
• Introduisez des templates de prompt et un décodage contraint pour des sorties prévisibles. Ajoutez des prompts de red team pour les jailbreaks hors ligne.
• Câblez le repli cloud avec des disjoncteurs durs et des quotas par utilisateur pour plafonner les dépenses.

Jours 61–90 : étendre et durcir

• Ajoutez un second cas d’usage sur l’appareil (p. ex., résumé de document ou tri de boîte de réception). Partagez le même moteur de politique et la même télémétrie.
• Lancez une expérience 50/50 : assistant de plateforme vs modèle embarqué pour un flux simple. Comparez latence, énergie et CSAT.
• Automatisez les exécutions de perf en labo d’appareils sur les builds nightly. Échouez le build si la latence P95 ou l’énergie par session régresse de >15 %.
• Expédiez une copie marketing qui correspond à la réalité — « sur l’appareil » pour les appareils éligibles, « hybride » sinon. Publiez une note de confidentialité décrivant exactement ce qui tourne où.

Comment l’actualité d’aujourd’hui doit infléchir votre roadmap

• Les déploiements d’Android 17 signifient que vous pouvez vous appuyer sur des primitives système plutôt que sur de la glue maison. Ne sur‑ingénieriez pas votre première itération.
• GLM‑5.2 en tête des poids ouverts est votre feu vert pour tester un modèle 7B local sans vous excuser sur la qualité. Gardez un chemin cloud pour la longue traîne.
• « Exécuter des modèles locaux, c’est bien maintenant » n’est pas qu’une vibe. Le gain UX de la suppression des aller‑retour réseau est mesurable — les utilisateurs accomplissent plus vite, et votre coût de support par ticket baisse quand les suggestions arrivent instantanément.
• Les utilisateurs privacy‑first prêtent attention. Avec l’arrivée de GrapheneOS sur Android 17, attendez‑vous à une demande plus forte d’options hors ligne. Construisez‑les maintenant ou perdez ces utilisateurs au profit de produits qui le font.

L’essentiel

Vous n’avez plus besoin d’un labo de recherche pour livrer une IA mobile privée et rapide. Android 17 vous apporte les primitives, les poids ouverts vous apportent la qualité à petite taille, et les NPU modernes vous donnent de la marge. Le difficile, c’est la discipline : choisissez une boucle, quantifiez‑la, conditionnez‑la aux capacités de l’appareil et dites la vérité dans votre communication confidentialité.

Si vous voulez de l’aide : nous montons des pods Android nearshore qui relient Kotlin, NDK et inférence ML, avec 6–8 heures/jour de recouvrement avec les équipes US. Nous mettrons votre première fonctionnalité sur l’appareil en production en un trimestre — et nous vous laisserons un moteur de politique et un harnais de perf réutilisables.

Points clés

• Android 17 + des NPU modernes rendent une IA sur l’appareil <200 ms praticable pour une vraie UX, pas seulement des démos.
• Choisissez entre assistant de plateforme, modèle embarqué ou hybride selon vos besoins de confidentialité, de contrôle et de latence.
• Le sur‑appareil déplace les coûts du spend par token dans le cloud vers de la distribution ponctuelle et un peu d’ingénierie — souvent le point mort dès le mois 2–3.
• Conditionnez les fonctionnalités aux capacités de l’appareil ; utilisez une livraison de modèles à la demande ; prévoyez toujours un repli cloud.
• Supposez que les poids fuient ; respectez les licences ; instrumentez une télémétrie préservant la confidentialité pour étayer vos promesses.
• Livrez une boucle resserrée en 90 jours, puis étendez — l’automatisation de la perf et un moteur de politique sont vos leviers.

Auteur : Diogo Hudson Dias