Un modèle qui tourne dans un centre de données a droit à l’oubli : il peut prendre plus de mémoire, plus d’énergie, plus de secondes, personne ne le voit. Le même modèle dans votre poche n’a droit à rien de tout cela. L’IA embarquée, c’est-à-dire un modèle qui s’exécute sur l’appareil lui-même sans passer par un serveur, n’est pas une version réduite du cloud : c’est une discipline de contraintes, où chaque gain se paie ailleurs.
Voici la réponse courte. L’embarqué gagne quand la latence, la confidentialité et la disponibilité hors connexion comptent plus que la puissance brute ; le cloud garde l’avantage dès qu’il faut un très grand modèle, un contexte long ou des connaissances fraîches. Ce partage n’est pas un état provisoire de la technique. Il vient de la physique de la machine que vous tenez dans la main.
La mémoire, le débit et la chaleur fixent le plafond
Le premier plafond est la mémoire vive. Pour produire le moindre mot, un modèle doit avoir ses poids chargés, et ces poids occupent une place que le système d’exploitation, le navigateur et vos applications se disputent déjà. L’ordre de grandeur est facile à retenir : un modèle de 3 milliards de paramètres pèse environ 3 Go quantifié en 8 bits, environ 1,5 Go en 4 bits. Ajoutez le cache des états intermédiaires, qui grossit avec la longueur de la conversation, et vous comprenez pourquoi les modèles embarqués des grandes plateformes, d’Apple Intelligence à Gemini Nano, se situent dans les quelques milliards de paramètres et non dans les centaines.
Le deuxième plafond est plus subtil, et c’est celui que la plupart des comparatifs ratent : la bande passante mémoire. En génération, l’appareil relit l’essentiel des poids du modèle à chaque token produit. La vitesse d’écriture ne dépend donc pas de la puissance de calcul brute du processeur, mais du débit auquel la mémoire sait servir ces octets. Doublez la taille du modèle, vous doublez les octets à faire transiter par mot généré. Un téléphone n’écrit pas plus vite parce qu’on lui ajoute du calcul.
Le troisième plafond se voit dans votre main : la chaleur. Une inférence soutenue fait monter la puce en température, le système réduit alors les fréquences pour protéger l’appareil, et les performances observées après trente secondes n’ont plus rien à voir avec celles de la première seconde. Un serveur, lui, dissipe. Un téléphone endure.
Reste le paradoxe de la latence. L’embarqué supprime l’aller-retour réseau, donc le temps avant le premier mot s’effondre : la réponse démarre en quelques dizaines de millisecondes là où un appel distant en demande souvent plusieurs centaines. Mais le débit ensuite, en mots par seconde, reste inférieur à celui d’un grand modèle servi par des accélérateurs dédiés. L’embarqué est rapide à démarrer, lent à durer.
Compresser un modèle, c’est choisir ce qu’on accepte de perdre
Faire tenir un modèle dans un téléphone passe par trois familles de techniques, et aucune n’est gratuite.
- La quantification réduit la précision des poids, typiquement de 16 bits vers 8 bits (INT8) ou 4 bits (INT4). C’est le levier le plus rentable : la taille et le trafic mémoire fondent presque proportionnellement. En dessous de 4 bits, la dégradation devient visible à l’usage.
- L’élagage supprime les poids ou les têtes d’attention qui contribuent peu. Le gain de taille est réel, le gain de vitesse dépend beaucoup du matériel, qui n’exploite pas toujours les structures creuses.
- La distillation entraîne un petit modèle à imiter un grand. On ne compresse plus un modèle, on en fabrique un autre, plus fiable sur le domaine visé et plus fragile en dehors.
Ce qu’on perd suit un ordre assez régulier, et il vaut la peine de le connaître avant de tester. Les connaissances rares partent en premier : les entités peu fréquentes, les dates, les chiffres précis. Vient ensuite la tenue sur les raisonnements longs, où les petites erreurs s’additionnent. Puis les langues sous-représentées dans l’entraînement. La conversation courante, elle, résiste très bien : l’embarqué paraît donc convaincant sur les usages du quotidien, et trompeur dès qu’on l’interroge sur des connaissances.
Un levier échappe à cet arbitrage : le décodage spéculatif. Un tout petit modèle propose plusieurs mots d’avance, le modèle principal les valide en une passe. On accélère sans changer le résultat produit, au prix d’un peu de mémoire supplémentaire. C’est l’une des rares optimisations qui ne se paient pas en qualité.
Où l’IA embarquée gagne contre le cloud
Le bon critère tient à la fréquence de la tâche, pas à sa difficulté. Une fonction déclenchée cent fois par jour et par utilisateur, dont chaque appel distant coûterait une fraction de centime, devient économiquement absurde dans le cloud dès que la base d’utilisateurs grandit. Sur l’appareil, ce coût marginal disparaît du bilan de l’éditeur : il est payé en batterie par l’utilisateur.
Quatre familles d’usages passent ce test sans discussion : la transcription et la dictée, la traduction hors connexion, le traitement d’image local (détection, retouche, recherche dans la photothèque), et tout ce qui relève du tri et du routage, à savoir classer une notification, résumer un message, décider si une requête mérite d’être envoyée plus loin. Ces tâches ont trois traits communs : elles sont fréquentes, elles tolèrent mal l’attente, et elles manipulent des données que l’utilisateur n’a aucune envie de voir partir.
D’ailleurs, le choix ne se fait plus en tout ou rien. À la WWDC de juin 2026, Apple a ouvert son framework Foundation Models aux modèles tiers à partir d’iOS 27, avec une interface unique qui permet de basculer entre exécution locale et exécution distante. La décision devient un paramètre du produit : on traite en local par défaut, on escalade vers le cloud quand la requête le justifie. Concevoir une fonctionnalité d’IA embarquée, aujourd’hui, c’est surtout écrire cette règle d’escalade.
La confidentialité, l’argument que le cloud ne peut pas copier
C’est l’avantage structurel de l’embarqué : la donnée qui ne quitte pas l’appareil n’a pas besoin d’être protégée en transit, ni stockée ailleurs, ni couverte par un contrat de sous-traitance. Sur des messages privés, des photos, des données de santé ou des documents professionnels, cela change la nature du produit et pas seulement sa fiche technique.
Deux nuances, tout de même, parce que l’argument est trop souvent servi sans elles. Un modèle local ne rend pas une application privée : la télémétrie, les journaux d’usage et les analyses de comportement continuent de partir si personne ne les a coupés. Et dans une architecture hybride, tout se joue au moment de la bascule. Qu’est-ce qui déclenche l’envoi au serveur, l’utilisateur le voit-il, peut-il le refuser ? Un système qui escalade en silence offre la confidentialité du cloud avec le discours de l’embarqué.
Corriger un modèle déjà installé sur des millions d’appareils
Côté serveur, corriger un comportement se fait en une nuit. Sur l’appareil, le modèle est un fichier de plusieurs centaines de mégaoctets à plusieurs gigaoctets, installé chez des millions de personnes, sur des versions de système différentes, souvent derrière une connexion mobile limitée. La mise à jour relève alors de la logistique plus que du déploiement.
La réponse dominante consiste à figer le modèle de base fourni par la plateforme et à n’expédier que de petits adaptateurs spécialisés, quelques mégaoctets, entraînés pour une tâche précise. L’éditeur d’application n’embarque plus son propre modèle, il ajuste celui du système. Google suit la même logique côté Android : Gemini Nano tourne dans le service système AICore, et les applications l’appellent par les API GenAI de ML Kit plutôt que d’embarquer leurs propres poids.
Deux conséquences pratiques en découlent. D’abord, plusieurs versions de votre modèle coexistent en permanence sur le parc : vos prompts et vos garde-fous doivent être testés sur l’ancienne comme sur la nouvelle, sans quoi une amélioration côté plateforme se traduira par une régression côté produit. Ensuite, un modèle embarqué ne doit jamais servir de base de connaissances : ce qu’il sait date de son entraînement et ne se corrige pas à distance. Les faits doivent venir d’ailleurs, d’un index local sur les données de l’utilisateur ou d’un appel distant assumé. Le modèle raisonne, il ne mémorise pas pour vous.
Côté matériel, le goulot est passé du calcul à la mémoire
Le calcul n’est plus le facteur limitant : les puces mobiles embarquent des NPU (unités de traitement neuronal) dédiés depuis plusieurs générations. Les verrous se sont déplacés vers la mémoire et le stockage, autrement dit vers la capacité à faire circuler des gigaoctets de poids assez vite et assez souvent. Le stockage UFS 5.0 vise précisément ce goulot : Samsung annonce jusqu’à 10,8 Go/s en lecture séquentielle et une production de masse au quatrième trimestre 2026, avec des débits pensés pour les modèles de langage embarqués. La fragmentation reste l’autre difficulté : chaque fondeur expose son accélérateur avec ses propres outils, et le même modèle quantifié ne se comporte pas identiquement d’une puce à l’autre.
Rien de tout cela n’annonce la fin du cloud, ni son contraire. Ce qui se joue est plus intéressant : la frontière entre les deux devient une décision de conception, prise fonction par fonction, avec un budget de mémoire, de batterie et de millisecondes à respecter. Les équipes qui sauront écrire cette règle d’escalade, et l’expliquer à leurs utilisateurs, prendront une avance que la prochaine génération de puces ne comblera pas.
Questions frequentes
Qu’est-ce que l’IA embarquée exactement ?
C’est un modèle d’intelligence artificielle qui s’exécute directement sur l’appareil (téléphone, ordinateur, objet connecté, véhicule) sans envoyer les données à un serveur distant. Le traitement, le stockage des poids du modèle et la génération de la réponse se font en local.
Quelle taille de modèle peut tenir dans un smartphone ?
Les modèles embarqués des grandes plateformes se situent aujourd’hui dans l’ordre de quelques milliards de paramètres. Un modèle de 3 milliards de paramètres occupe environ 3 Go en 8 bits et environ 1,5 Go en 4 bits, auxquels s’ajoute la mémoire du cache d’attention pendant la conversation.
L’IA embarquée est-elle plus rapide que le cloud ?
Elle est plus rapide à démarrer, car elle supprime l’aller-retour réseau et affiche les premiers mots en quelques dizaines de millisecondes. En revanche, le débit de génération reste inférieur à celui d’un grand modèle servi par des accélérateurs de centre de données.
Que perd un modèle quand on le compresse pour l’embarquer ?
La quantification, l’élagage et la distillation dégradent d’abord les connaissances rares (entités peu fréquentes, dates, chiffres précis), puis la tenue sur les raisonnements longs et les langues peu représentées. La conversation courante résiste bien, ce qui rend la dégradation difficile à repérer sans tests ciblés.
Une application avec un modèle local est-elle automatiquement respectueuse de la vie privée ?
Non. La télémétrie, les journaux d’usage et les analyses de comportement peuvent continuer d’être envoyés, et beaucoup d’architectures sont hybrides et escaladent certaines requêtes vers le cloud. Le point à vérifier est la règle qui déclenche cette bascule et sa visibilité pour l’utilisateur.
