Un modèle de langage qui tourne dans la poche d'un smartphone, sans réseau, sans envoyer une seule donnée à un serveur. Il y a deux ans, quand un client m'a demandé ça pour son app de prise de notes médicales, j'ai répondu « techniquement possible, mais comptez six mois ». On l'a livré en onze semaines. Et le modèle fait 1,8 Go, pas 70.
Le développement application mobile avec intelligence artificielle embarquée n'est plus un sujet de laboratoire. C'est un choix d'architecture qu'on pose maintenant sur la table dès le premier comité de projet, au même titre que le choix du framework. Mais la moitié des équipes que je croise se plantent sur la même chose : elles confondent « IA dans mon app » (un appel API à un LLM distant) et « IA embarquée » (le modèle tourne sur l'appareil). Ce sont deux métiers différents.
Points clés à retenir
- Un modèle embarqué tient aujourd'hui dans 1 à 4 Go une fois quantifié, pas 50.
- Le vrai coût caché n'est pas l'entraînement, c'est la conversion et l'optimisation du modèle pour chaque plateforme.
- L'embarqué gagne sur la confidentialité et le hors-ligne ; il perd sur la qualité brute face à un modèle cloud.
- Gemini Nano côté Android et Core ML côté iOS changent la donne : le runtime est fourni, vous n'écrivez plus de kernels.
- L'AI Act impose des obligations de transparence qui pèsent plus lourd sur le cloud que sur l'embarqué.
IA embarquée ou cloud : l'arbitrage qu'on pose mal
La question que tout le monde pose en réunion, c'est « quel modèle on prend ? ». Mauvaise question. La première, c'est « est-ce que la donnée peut sortir de l'appareil ? ». Si la réponse est non — dossier médical, donnée biométrique, contenu chiffré — le débat est clos, vous faites de l'embarqué. Point.
Ce que coûte vraiment une requête cloud
Sur une app de traitement de texte que j'ai suivie, chaque appel à un LLM distant coûtait environ 0,4 centime d'euro en tokens. Sur le papier, rien. Sauf qu'à 40 000 utilisateurs actifs qui font quinze requêtes par jour, on arrive à 2 400 € par jour. Sept cent mille euros par an. Pour une fonctionnalité de correction grammaticale.
Le calcul a été vite fait. On est passés sur un modèle embarqué de 900 Mo, qualité légèrement en dessous sur les phrases tordues, mais zéro coût marginal et une latence divisée par trois. Le taux d'acceptation des suggestions est passé de 61 % à 68 %, curieusement — parce que la réponse arrive avant que l'utilisateur ait fini de lire.
Voilà le tableau que je sers systématiquement en début de projet :
| Critère | IA embarquée | IA cloud |
|---|---|---|
| Coût marginal par requête | Nul | Facturé au token |
| Fonctionne hors ligne | Oui | Non |
| Qualité du modèle | Limitée (1-8 milliards de paramètres typiquement) | Jusqu'à des centaines de milliards |
| Latence première réponse | 200-800 ms sur NPU récent | 500 ms à 2 s selon réseau |
| Confidentialité des données | Totale (rien ne sort) | Dépend du contrat fournisseur |
| Mise à jour du modèle | Via store, lourde | Immédiate, côté serveur |
| Taille de l'app | +1 à 4 Go | Quelques Mo |
Le faux argument du hors-ligne
On me sort souvent « l'embarqué c'est pour le hors-ligne ». Franchement, 90 % des apps n'ont pas besoin de fonctionner dans le métro sans réseau. L'argument réel, c'est la latence perçue et le coût. Le hors-ligne, c'est un bonus marketing qu'on met sur la fiche App Store.
Gemini Nano et l'IA Android : ce qui a changé concrètement
Android Studio a mis un sacré coup d'accélérateur. La vraie bascule, pour moi, c'est le moment où j'ai arrêté d'écrire du code de gestion de mémoire GPU à la main. Les runtimes fournis par la plateforme ont rendu l'embarqué accessible à des équipes qui ne sont pas des labos de recherche.
Gemini Nano, c'est quoi pour un développeur ?
Gemini Nano, c'est un modèle de taille réduite qui tourne directement sur les appareils Android compatibles, exposé via des API système (AI Core, ML Kit). Vous ne téléchargez pas de poids dans votre APK : vous appelez des fonctions de génération ou de résumé, l'appareil fait le travail. Deux conséquences pratiques.
- Le poids de l'app n'explose pas — c'est l'OS qui héberge le modèle.
- Mais vous dépendez de la disponibilité matérielle : sur un téléphone d'entrée de gamme, la fonctionnalité est absente ou dégradée.
Sur un projet de résumé d'articles, on a dû écrire un fallback cloud pour environ un tiers des appareils qui ne supportaient pas le modèle on-device. Prévoyez-le dès le départ, sinon vous refaites l'architecture en catastrophe trois semaines avant la sortie. Ça m'est arrivé.
IA Android Studio : l'assistant qui code, pas celui qui pense
Les assistants de code intégrés (type Gemini in Android Studio) font gagner du temps sur le boilerplate, les migrations de dépendances, les tests unitaires chiants. Je les utilise tous les jours. Mais sur l'IA embarquée spécifiquement, ils sont quasi inutiles : quand vous devez convertir un modèle en LiteRT avec la bonne quantification et vérifier que le NPU du fabricant l'accepte, l'assistant vous pond du code plausible qui ne compile pas.
Ma règle : l'assistant pour le code de plomberie, le cerveau humain pour le pipeline modèle. Toujours.
Le pipeline qu'on ne montre jamais : convertir un modèle pour mobile
Personne n'en parle dans les tutos, et c'est 60 % du travail réel. Vous avez un modèle qui marche sur votre machine avec PyTorch. Il ne tournera pas tel quel sur un téléphone. Le chemin ressemble à ça :
- Entraînement ou fine-tuning côté serveur, sur GPU.
- Export vers un format intermédiaire (ONNX, SavedModel).
- Conversion vers le runtime cible : LiteRT (ex-TensorFlow Lite) sur Android, Core ML sur iOS, ONNX Runtime Mobile en cross-platform.
- Quantification — passer de 32 bits à 8 bits, voire 4, pour diviser la taille par 3 à 4.
- Élagage (pruning) des poids inutiles.
- Validation sur device réel, pas sur émulateur.
Sur un modèle de reconnaissance d'images que j'ai porté, la quantification INT8 a fait passer le binaire de 340 Mo à 88 Mo. La précision a chuté de 1,2 point. Acceptable. La deuxième tentative en INT4 a fait tomber la précision de 9 points — inutilisable, on a jeté.
Et le piège que personne ne mentionne : le NPU. Sur le papier, chaque fabricant annonce des TOPS mirobolants. Dans la pratique, si votre modèle n'utilise pas les opérateurs supportés par ce NPU précis, le runtime bascule silencieusement sur le CPU, et là vous perdez un facteur cinq en vitesse. J'ai découvert ça en profilant une app qui ramait sur les Pixel mais pas sur les Samsung. Le coupable : une couche de normalisation non supportée.
Conformité : pourquoi l'embarqué vous simplifie la vie (sans vous l'enlever)
L'AI Act européen déploie ses obligations par vagues, et le calendrier continue de courir en 2026. Sans entrer dans le détail juridique — je ne suis pas juriste —, le principe est clair : plus vous traitez de données personnelles, plus vous avez d'obligations de transparence et de documentation.
Une IA embarquée qui ne fait sortir aucune donnée de l'appareil réduit mécaniquement votre surface réglementaire. Pas de transfert, pas de sous-traitant IA à documenter, pas de registre de traitement pour un flux qui n'existe pas. C'est un argument que je sers de plus en plus aux DPO, et il porte.
Faut-il mentionner à l'utilisateur qu'une IA est à l'œuvre ?
Oui. La transparence n'est pas négociable, même en local. Si votre app génère du texte ou prend une décision automatisée qui affecte l'utilisateur, il doit le savoir. Un simple libellé « suggéré par IA » suffit dans la plupart des cas. Ça coûte deux lignes de code et ça évite des ennuis.
Le point que les extraits classiques oublient : l'embarqué ne vous exempte pas du RGPD. Si votre modèle a été entraîné sur des données personnelles, la question du fondement légal reste entière, même si l'inférence se fait sur l'appareil. La localisation du calcul ne blanchit pas la provenance des données d'entraînement.
Quand ne PAS faire d'IA embarquée
Je vais être direct : dans environ un cas sur deux que j'ai vus, l'embarqué était le mauvais choix. Les signaux qui doivent vous alerter :
- Vous avez besoin d'un modèle de pointe (raisonnement complexe, génération longue).
- Votre base d'utilisateurs est sur du matériel ancien.
- Vous itérez encore sur le modèle chaque semaine — un déploiement via store à chaque mise à jour, c'est intenable.
- La fonctionnalité n'est pas centrale et le coût cloud reste sous les 500 € par mois.
Dans ces cas, un appel API bien placé fait le job. L'embarqué, c'est un investissement d'ingénierie lourd qu'on ne rentabilise que si la fonctionnalité est utilisée massivement ou si la donnée ne peut pas bouger.
Ce qui me frappe, en 2026, c'est que la frontière a bougé plus vite que les mentalités. Les modèles embarqués d'aujourd'hui égalent à peu près ce que faisait un bon modèle cloud il y a deux ans. Alors la vraie question n'est plus « est-ce que c'est assez puissant ? ». Elle est devenue : qu'est-ce que je gagne à garder mes données chez l'utilisateur ? Et pour un nombre croissant d'apps, la réponse vaut l'effort.
La prochaine fois qu'un chef de projet vous demande « on met quelle IA ? », ne répondez pas par un nom de modèle. Demandez où sont les données. La suite découle de là.
