L'IA on-device : faire tourner l'intelligence artificielle sur l'appareil

Il fut un temps, encore récent, où traiter une requête d'intelligence artificielle depuis un téléphone signifiait presque toujours la même chose : l'appareil emballait vos données, les expédiait vers un centre de calcul lointain, attendait la réponse, puis l'affichait. Ce détour par le réseau est en train de reculer. Une part croissante de l'inférence — la phase où un modèle produit un résultat — s'exécute désormais directement sur la puce que vous tenez dans la main. Traduction d'une conversation, résumé d'un e-mail, effacement d'un objet sur une photo, transcription d'un appel : ces traitements descendent sur l'appareil, où ils répondent en quelques millisecondes, fonctionnent hors réseau et gardent vos données à demeure. Cette bascule porte un nom sobre : l'IA on-device.

Ce guide propose une lecture claire et technique de ce basculement, sans le rattacher à un modèle de téléphone précis ni à une marque unique. L'objectif est de comprendre les mécanismes communs à tout l'écosystème : les puces spécialisées qui rendent l'inférence locale possible, les modèles compacts calibrés pour ce matériel, les techniques de compression qui les font tenir en mémoire, les logiciels qui orchestrent l'exécution, et les arbitrages concrets entre traitement local et traitement distant. Que vous soyez développeur, responsable technique ou simplement curieux de ce qui se passe sous le capot, vous trouverez ici des repères vérifiables plutôt que des slogans.

Un mot de méthode d'abord. Le sujet est saturé d'arguments commerciaux, à commencer par la fameuse unité de mesure « TOPS » que chaque fabricant affiche fièrement. Nous verrons que ce chiffre raconte une partie de l'histoire, rarement toute l'histoire. La bonne posture consiste à distinguer la capacité de calcul brute des performances réellement observées sur une tâche donnée — un écart qui explique bien des surprises dans les comparatifs.

Qu'est-ce que l'IA on-device, au juste ?

L'IA on-device — parfois appelée edge AI ou IA embarquée — désigne l'exécution de modèles d'intelligence artificielle directement sur le processeur d'un appareil, sans envoyer les données vers un serveur distant. Concrètement, quand un téléphone identifie un objet dans une photo, propose une réponse à un message ou transcrit une note vocale, le calcul s'effectue sur une unité de traitement spécialisée intégrée à la puce. Selon le constructeur, cette unité porte différents noms — NPU (Neural Processing Unit), moteur neuronal, TPU mobile, APU — mais le principe reste le même : accélérer les opérations mathématiques propres aux réseaux de neurones.

Le contraste avec l'approche cloud est net. Dans l'architecture cloud, le terminal se contente de collecter la requête et d'afficher le résultat ; l'intelligence réside dans le centre de calcul. Dans l'architecture on-device, le terminal exécute lui-même le modèle. Cette différence apparemment technique a des conséquences très concrètes sur la vitesse de réponse, la confidentialité des données et la capacité à fonctionner sans connexion.

Du cloud à la puce : un parcours de compression

Historiquement, l'inférence exigeait la puissance du cloud pour une raison simple : les modèles étaient trop volumineux et trop gourmands pour tenir sur un appareil mobile. Un réseau de classification d'images de génération 2018 pesait déjà lourd, et les premiers grands modèles de langage, avec leurs centaines de millions à plusieurs milliards de paramètres, dépassaient de loin les capacités mémoire d'un téléphone. La question n'était pas de savoir si l'exécution locale était souhaitable, mais si elle était seulement possible.

Plusieurs avancées convergentes ont changé la donne. La première tient à la compression des modèles, et notamment à la quantification, qui réduit la précision numérique des poids. Un modèle stocké en flottant 32 bits qui passe en entier 4 bits divise par huit son empreinte mémoire : là où un modèle de plusieurs milliards de paramètres exigeait des dizaines de gigaoctets, sa version compressée tient dans quelques gigaoctets. La deuxième avancée relève du matériel, avec l'apparition de cœurs de calcul dédiés aux réseaux de neurones, capables d'exécuter des milliards d'opérations par seconde en consommant peu. La troisième, enfin, concerne les logiciels : des moteurs d'inférence optimisés savent désormais tirer parti de chaque couche de la pile pour router les calculs vers le composant le plus adapté.

La distillation de connaissances a joué un rôle complémentaire décisif. Cette technique consiste à entraîner un petit modèle « élève » à reproduire le comportement d'un grand modèle « professeur ». Le résultat conserve l'essentiel des capacités de son aîné pour une fraction de la taille, ce qui permet de déployer des modèles compacts mais compétents, spécifiquement calibrés pour le matériel mobile. Combinée à la quantification, la distillation a fait passer l'IA locale du laboratoire à la poche.

Le tournant on-device n'est pas né d'une seule invention. Il résulte de la rencontre de trois progrès parallèles : des modèles plus petits, des puces plus efficaces et des logiciels plus fins. Aucun n'aurait suffi seul.

Les trois piliers : latence, confidentialité, autonomie

Pourquoi cette migration vers le local ? Trois facteurs se renforcent mutuellement.

Le premier est la latence. Un aller-retour vers le cloud dépend de la qualité du réseau et introduit un délai perceptible. L'inférence locale, elle, franchit désormais un seuil remarquable : des mesures publiées sur des modèles de vision par ordinateur en production font état de latences inférieures à 20 millisecondes sur mobile, et des benchmarks constructeurs montrent que plusieurs dizaines de modèles s'exécutent en moins de 5 millisecondes sur le NPU des puces récentes. Pour la traduction en direct, la reconnaissance vocale ou les filtres photo, cette réactivité fait toute la différence à l'usage.

Le deuxième pilier est la confidentialité. Traiter une requête localement supprime le problème à la racine : les données ne quittent pas l'appareil. Cet argument prend une résonance particulière dans le cadre européen, où le RGPD encadre strictement le traitement des données personnelles et où l'IA Act (Règlement UE 2024/1689) ajoute des obligations de transparence pour les systèmes d'IA à usage général, y compris ceux embarqués dans les terminaux. Quand le calcul reste local, la conformité se trouve mécaniquement simplifiée.

Le troisième pilier est l'autonomie fonctionnelle. Un appareil capable d'exécuter ses fonctions d'IA sans connexion réseau reste utilisable partout — dans les transports souterrains, en avion, en zone à couverture limitée. Cette indépendance vis-à-vis du réseau constitue un atout tangible, particulièrement sur les marchés où la couverture demeure inégale.

Un quatrième facteur, moins visible, accélère la transition côté fabricants : le coût de l'inférence cloud. Chaque requête envoyée à un centre de calcul consomme de la puissance de traitement, de la bande passante et de l'infrastructure. Multiplié par les centaines de millions de terminaux vendus chaque année et par les milliards de requêtes quotidiennes, ce coût devient considérable. Déplacer une partie de l'inférence vers le terminal représente donc, à grande échelle, une économie substantielle. L'IA on-device n'est pas seulement plus agréable pour l'utilisateur : elle est aussi plus rationnelle économiquement pour qui déploie à l'échelle.

Les puces qui rendent l'inférence locale possible

Le cœur de l'IA on-device, c'est le silicium. Chaque fabricant de puces mobiles a intégré des unités de calcul spécialisées pour les opérations propres aux réseaux de neurones : multiplications matricielles, convolutions, mécanismes d'attention. Plutôt que de passer en revue des modèles de puces qui se périment vite, examinons les grandes familles d'architecture, qui, elles, restent stables.

NPU, moteur neuronal, TPU mobile : trois noms, une même idée

Le NPU, ou Neural Processing Unit, est le terme générique le plus répandu. Il désigne un bloc de la puce entièrement dédié à l'accélération des calculs de réseaux de neurones. Sa force tient à sa spécialisation : là où un processeur généraliste doit gérer une grande variété de tâches, le NPU ne fait qu'une chose, mais la fait très efficacement, avec un excellent rapport entre performance et consommation.

Le moteur neuronal (Neural Engine chez certains) suit la même logique, avec une architecture multicœur pensée pour l'intégration verticale. Les moteurs neuronaux récents intégrés aux puces de la génération 2024-2025 sont crédités d'une puissance de l'ordre de 38 TOPS dans les familles de processeurs de bureau associées, un chiffre modeste sur le papier mais compensé par une optimisation logicielle de bout en bout.

Le TPU mobile (Tensor Processing Unit dérivé des accélérateurs de centre de calcul) illustre une troisième approche : concevoir la puce autour d'un modèle spécifique plutôt que de maximiser la puissance brute. L'affinité native entre la puce et le modèle qu'elle est censée exécuter permet des optimisations impossibles sur du matériel générique. Le pari est clair : une bonne co-conception vaut mieux qu'un chiffre de performance élevé mais mal exploité.

Les TOPS : ce que ce chiffre mesure, et ce qu'il ne mesure pas

Les TOPS (Tera Operations Per Second) sont devenus l'argument marketing numéro un des fabricants de puces. Le chiffre grimpe à chaque génération : les NPU des ordinateurs portables récents atteignent désormais 80 TOPS sur les configurations les plus musclées, contre environ 45 TOPS un an plus tôt. Mais que mesure réellement ce nombre ?

Un TOPS quantifie le nombre d'opérations arithmétiques — multiplications, additions — que le NPU peut effectuer par seconde, généralement en précision entière 8 bits. Ce chiffre reflète la capacité de calcul brute, mais pas l'efficacité réelle sur une tâche donnée. Une puce affichant un budget TOPS élevé peut se montrer moins performante qu'une puce plus modeste sur un modèle précis, si son architecture n'est pas optimisée pour les opérations que ce modèle sollicite. Le débit théorique ne dit rien de la façon dont la mémoire est alimentée, ni de la manière dont le compilateur traduit le modèle en instructions.

• Le TOPS mesure un plafond, pas une moyenne. C'est la performance maximale dans des conditions idéales, rarement atteinte en usage réel.
• La précision compte. Un TOPS en entier 8 bits n'équivaut pas à un TOPS en entier 4 bits ou en flottant 16 bits ; comparer des chiffres exprimés dans des précisions différentes n'a pas de sens.
• L'efficacité énergétique prime souvent. Sur un appareil sur batterie, les opérations par watt importent davantage que les opérations par seconde. Une puce moins puissante mais plus sobre peut offrir une meilleure expérience soutenue.
• Le goulet d'étranglement est fréquemment la mémoire. Alimenter le NPU en données assez vite est souvent plus limitant que la puissance de calcul elle-même.

Pour évaluer les performances réelles, mieux vaut se tourner vers des benchmarks standardisés. MLPerf Mobile, maintenu par le consortium MLCommons, mesure la latence et le débit sur des modèles standardisés avec des règles strictes de soumission, ce qui rend les résultats comparables entre appareils. D'autres suites évaluent des modèles réels de classification d'images, de segmentation ou de traitement du langage, et distinguent les performances du processeur, du GPU et du NPU. Ces mesures restent plus fiables qu'un chiffre de TOPS isolé.

La contrainte thermique, souvent oubliée

Un dernier facteur, rarement mis en avant dans les fiches techniques, mérite attention : la gestion de la chaleur. Un appareil compact dissipe difficilement l'énergie produite par une inférence intensive. Passé un certain seuil, la puce réduit volontairement sa cadence pour éviter la surchauffe — un phénomène appelé throttling thermique. Résultat : les performances mesurées en conditions contrôlées, à température ambiante modérée, chutent sensiblement dans un usage réel prolongé. Les benchmarks internes des fabricants signalent des écarts notables entre le pic de performance et la performance soutenue sur plusieurs minutes de calcul. Un châssis bien conçu, capable d'évacuer la chaleur, maintient des performances plus proches du plafond théorique — un critère de qualité discret mais réel.

Les modèles compacts : l'art de faire petit et bon

Le matériel ne suffit pas. Encore faut-il des modèles taillés pour lui. C'est tout l'enjeu des SLM — Small Language Models, ou petits modèles de langage — et plus largement des modèles compacts multimodaux qui peuplent désormais nos appareils.

Que veut dire « petit », concrètement ?

Un travail de recensement académique de référence propose une définition opérationnelle : les petits modèles de langage sont des modèles transformeurs à décodeur uniquement comptant entre 100 millions et 5 milliards de paramètres. Cette fourchette couvre un large éventail d'appareils, des objets connectés aux tablettes en passant par les téléphones. Ce même travail a recensé et mesuré 57 petits modèles populaires, en analysant à la fois leurs capacités et leur coût d'exécution — une base empirique précieuse pour comprendre ce qui tient réellement dans un appareil.

Les mesures publiées éclairent l'ordre de grandeur. L'empreinte mémoire à l'exécution de ces modèles s'étend d'environ 275 mégaoctets à un peu plus de 2,4 gigaoctets, avec une consommation qui croît de façon globalement linéaire avec le nombre de paramètres. La taille du vocabulaire pèse aussi : certains modèles à très grand vocabulaire consomment nettement plus de mémoire à nombre de paramètres comparable. Ces chiffres expliquent pourquoi un téléphone doté de 8 gigaoctets de mémoire vive constitue souvent le seuil d'entrée pour l'exécution locale des modèles de langage, et pourquoi les configurations plus généreuses offrent davantage de marge.

Les familles de modèles on-device

Les grands acteurs proposent chacun leur famille de modèles compacts, mais avec des philosophies convergentes. Un modèle on-device de référence, décliné par certains constructeurs Android, existe en deux variantes : une première d'environ 1,8 milliard de paramètres pour les appareils à mémoire standard, et une seconde d'environ 3,25 milliards pour les appareils mieux dotés en mémoire vive et en NPU. Ces modèles sont nativement multimodaux : ils traitent texte, images et audio dans un même pipeline.

Du côté de l'écosystème verticalement intégré, le modèle de langage fondation embarqué compte lui aussi autour de 3 milliards de paramètres. Un rapport technique détaillé publié en 2025 en décrit les optimisations : un entraînement conscient de la quantification en 2 bits, et un partage du cache clé-valeur entre deux blocs du modèle qui réduit l'empreinte du mécanisme d'attention de 37,5 %, sans dégradation proportionnelle de la qualité. Pour la partie vision, le même rapport mentionne une ossature visuelle d'environ 300 millions de paramètres. Ces chiffres, publiés et vérifiables, donnent une idée précise de ce qu'exécutent réellement les appareils récents.

La leçon des petits modèles est contre-intuitive : réduire la taille ne se paie pas toujours en qualité. Bien distillé, bien quantifié, un modèle de quelques milliards de paramètres couvre l'essentiel des usages quotidiens — résumé, reformulation, classification, traduction — avec une justesse que l'utilisateur ne distingue pas de celle du cloud.

Les adaptateurs légers : spécialiser sans dupliquer

Une technique s'est imposée pour spécialiser un modèle sans en démultiplier les copies : les adaptateurs de bas rang, souvent désignés par l'acronyme LoRA (Low-Rank Adaptation). Le principe consiste à greffer sur un modèle de base un petit module entraîné pour une tâche précise — résumé, correction, réécriture — au lieu de charger un modèle spécialisé entier. Sur mobile, cette approche est particulièrement précieuse : un même modèle de base reste en mémoire, et l'appareil bascule d'une tâche à l'autre en chargeant simplement l'adaptateur correspondant, qui ne pèse que quelques mégaoctets. Les interfaces de programmation d'IA générative proposées aux développeurs mobiles reposent largement sur ce mécanisme : chaque fonction — résumé, relecture, description d'image — s'appuie sur le modèle commun augmenté d'un adaptateur spécifique.

La quantification : diviser la précision, multiplier l'usage

Si un seul concept devait résumer ce qui a rendu l'IA locale possible, ce serait la quantification. Cette technique consiste à représenter les poids et parfois les activations d'un modèle avec moins de bits que la précision d'entraînement d'origine. Comprendre ses mécanismes, c'est comprendre pourquoi votre téléphone peut faire tourner ce qui exigeait naguère une carte graphique de bureau.

Le principe : moins de bits, moins de mémoire

Un modèle entraîné utilise typiquement des nombres flottants sur 16 ou 32 bits pour représenter chaque poids. La quantification réduit cette précision : un poids passé de 32 bits à 8 bits occupe quatre fois moins de place ; passé à 4 bits, huit fois moins. Comme l'empreinte mémoire d'un modèle est le principal facteur limitant sur un appareil mobile, ce gain est décisif. Il ne s'agit pas seulement de faire tenir le modèle : une empreinte plus petite signifie aussi moins de données à faire circuler entre la mémoire et le processeur, donc une inférence plus rapide et plus sobre en énergie.

Deux grandes stratégies coexistent. La quantification post-entraînement s'applique à un modèle déjà entraîné, sans le réentraîner — rapide à mettre en œuvre, mais avec un risque de perte de qualité si elle est menée sans précaution. La quantification consciente de l'entraînement (quantization-aware training) intègre la contrainte de précision réduite dès la phase d'apprentissage, ce qui permet au modèle de s'adapter et de limiter la dégradation. C'est cette seconde approche, poussée jusqu'à 2 bits dans certains modèles fondation récents, qui autorise les compressions les plus agressives tout en préservant la qualité.

Ce que disent les mesures

Les données empiriques sont éloquentes. Le recensement académique déjà cité a évalué cinq niveaux de quantification et conclut qu'un format 4 bits bien choisi offre le meilleur compromis : il réduit la latence de décodage d'environ 50 % en moyenne, tout en préservant l'essentiel de la qualité. Ce résultat explique pourquoi le 4 bits est devenu le format de prédilection pour l'exécution locale des modèles de langage.

D'autres travaux comparent les précisions entières. Sur des scénarios de déploiement à l'échelle, l'entier 8 bits ressort comme un excellent point d'équilibre : plusieurs analyses indépendantes font état de baisses de coûts matériels et de consommation d'énergie de l'ordre de moitié par rapport aux précisions plus élevées — l'ampleur exacte variant fortement selon le matériel et l'étude considérés —, pour une perte de qualité contenue. Plusieurs méthodes spécialisées ont affiné cette approche, comme la quantification consciente des activations, conçue précisément pour la compression des modèles en vue d'un déploiement sur appareil.

Les moteurs d'inférence : le chaînon logiciel

Entre le modèle et la puce s'intercale une couche logicielle essentielle : le moteur d'inférence. C'est lui qui traduit les opérations mathématiques du modèle en instructions optimisées pour le NPU, le GPU ou le processeur, et qui répartit la charge selon la nature de la tâche. Plusieurs écosystèmes dominent le paysage, avec des philosophies distinctes.

Les moteurs polyvalents

Parmi les moteurs les plus répandus figure un projet communautaire réputé pour son extensibilité, capable d'exécuter une grande variété d'architectures de modèles en combinant calcul sur processeur et sur GPU. Sa popularité tient à sa souplesse : il prend en charge des fonctionnalités avancées comme le décodage spéculatif — qui accélère la génération de texte — et l'inférence multimodale. Il sert souvent de point d'entrée pour qui veut expérimenter l'exécution locale d'un modèle de langage.

Un autre moteur, fondé sur la compilation de modèles, adopte une approche différente : il compile le modèle en amont pour la plateforme cible, appliquant des optimisations au niveau des opérations et du graphe de calcul. Cette compilation permet un déploiement multiplateforme, du téléphone au navigateur, avec des performances ajustées à chaque environnement.

Les solutions adossées aux grands frameworks

Un moteur unifié issu de l'écosystème PyTorch permet d'exécuter des modèles directement sur appareil sans conversion intermédiaire. Un article technique publié en 2026 le décrit comme une solution unifiée pour l'exécution sur appareil, prenant en charge plusieurs backends matériels — ce qui offre une couche d'abstraction appréciable pour les développeurs qui entraînent leurs modèles dans cet écosystème et veulent les déployer sur mobile avec un pipeline simplifié.

Du côté des frameworks intégrés aux systèmes d'exploitation, deux approches se distinguent. La première, propre à l'écosystème verticalement intégré, exploite automatiquement le moteur neuronal, le GPU ou le processeur selon la charge et le type d'opération, sans que le développeur ait à gérer cette répartition. Sa force est la prévisibilité : les performances restent constantes d'un appareil à l'autre, car le fabricant contrôle toute la pile. La seconde, côté Android, s'appuie sur un moteur d'inférence mobile très répandu qui exécute des modèles au format compact, prend en charge la quantification entière 8 et 4 bits, et route l'exécution vers le NPU ou le GPU via des délégués. Ce moteur sait exécuter certains modèles avec entraînement conscient de la quantification en 4 bits dans son propre format optimisé, directement sur le GPU.

L'IA comme service système

La tendance la plus structurante consiste à exposer les capacités d'IA comme un service du système d'exploitation, accessible à toutes les applications. Plutôt que de demander à chaque développeur de déployer et gérer son propre modèle, le système intègre un service qui orchestre l'inférence : téléchargement du modèle, mise à jour, chargement en mémoire, répartition entre NPU, GPU et processeur, et gestion des priorités pour ne pas dégrader l'expérience.

Concrètement, un développeur d'application de notes, de fitness ou de messagerie peut ainsi intégrer des fonctions de résumé, de traduction ou de classification sans compétence en apprentissage automatique : il envoie du texte, il reçoit un résumé. Cette abstraction, portée par des interfaces de programmation d'IA générative intégrées aux kits de développement mobiles, est la clé de l'adoption massive. Elle est disponible sur les appareils équipés des principales plateformes de puces mobiles, à travers le service système d'IA, ce qui garantit une portée large indépendamment du fabricant du terminal.

La bascule décisive n'est pas seulement matérielle. Elle tient à cette idée simple : faire de l'IA un service du système, comme la géolocalisation ou les notifications l'ont été avant elle. Le jour où résumer un texte devient un appel d'interface standard, l'IA locale cesse d'être une prouesse pour devenir une commodité.

Cas d'usage : ce que l'IA locale sait déjà faire

Les capacités théoriques ne valent que par leurs applications concrètes. Passons en revue, par catégories, les usages où l'inférence locale s'est imposée.

Langage : résumer, reformuler, traduire

Le traitement du langage est le terrain le plus mûr. Des outils d'écriture intégrés au système permettent de reformuler un texte, d'en ajuster le ton, de corriger la grammaire ou de résumer un document long, directement dans les champs de saisie standard. Le résumé d'e-mails, la suggestion de réponses contextuelles et la reformulation s'appuient sur un modèle de langage compact exécuté localement. La traduction en direct, notamment pendant les conversations, fonctionne entièrement sur l'appareil pour une part croissante des paires de langues, ce qui garantit à la fois confidentialité et fonctionnement hors réseau. La qualité atteinte sur ces tâches courantes rivalise, pour l'usage quotidien, avec celle des services distants.

Image : reconnaître, effacer, générer

La vision par ordinateur locale couvre un large spectre. La reconnaissance visuelle — encercler un objet à l'écran pour l'identifier — s'exécute sur le NPU, même si la recherche d'informations associée peut ensuite passer par le réseau. La retouche photo assistée, en particulier la suppression d'objets ou de personnes avec reconstruction cohérente de l'arrière-plan, repose sur des modèles dits d'inpainting exécutés localement, capables de traiter une image de plusieurs millions de pixels en quelques secondes. La génération d'images stylisées à partir d'une description textuelle est également passée sur l'appareil, avec une limitation aux styles non photoréalistes : produire des images photoréalistes exige davantage de puissance et de mémoire que ce que permet aujourd'hui l'exécution locale, mais la frontière recule à chaque génération.

Audio et productivité personnelle

La transcription et le résumé d'appels ou de notes vocales s'effectuent intégralement sur l'appareil pour certaines fonctions, ce qui signifie que le contenu ne quitte jamais le terminal. Une autre catégorie d'usage, plus discrète mais très parlante, concerne l'indexation sémantique du contenu personnel : analyser automatiquement les captures d'écran stockées, comprendre leur contenu et permettre de les retrouver en langage naturel. « Quel était le numéro de confirmation de ma réservation ? » devient une requête interprétable localement, sans envoyer ces informations sensibles au réseau. Cet exemple illustre parfaitement la promesse de l'IA locale : transformer une masse de données personnelles désorganisées en une base de connaissances interrogeable, sans jamais la déléguer à un tiers.

• Langage : résumé, reformulation, correction, traduction en direct, suggestion de réponses.
• Image : reconnaissance visuelle, suppression d'objets, génération stylisée non photoréaliste.
• Audio : transcription et résumé d'appels ou de notes vocales.
• Productivité : indexation sémantique des captures d'écran et des documents personnels.
• Accessibilité : description automatique d'images pour les personnes déficientes visuelles, sous-titrage en direct.

Confidentialité : ce qui reste, ce qui part

La promesse « vos données restent sur votre appareil » mérite une lecture nuancée. En pratique, la plupart des écosystèmes adoptent une architecture hybride, où certaines tâches sont traitées localement et d'autres transitent par le réseau selon leur complexité. Comprendre cette répartition est essentiel pour évaluer la réalité de la confidentialité.

L'architecture hybride, norme de fait

Le schéma dominant fonctionne par paliers. Les tâches courantes — résumé, traduction, reformulation, reconnaissance visuelle — sont traitées sur l'appareil. Les tâches plus lourdes — analyse de documents très longs, génération d'images haute résolution, requêtes complexes exigeant une connaissance étendue — basculent vers le cloud. La transition est généralement transparente pour l'utilisateur, signalée par un indicateur discret. Cette hiérarchie permet de combiner le meilleur des deux mondes : la réactivité et la discrétion du local pour le quotidien, la puissance du distant pour l'exceptionnel.

Une approche particulièrement aboutie consiste à structurer explicitement ces paliers : traitement local d'abord, puis, si nécessaire, un cloud aux garanties renforcées, et enfin, en dernier recours et avec consentement explicite, un service tiers spécialisé. Certains fabricants ont bâti une infrastructure cloud dédiée appliquant des garanties cryptographiques : données chiffrées de bout en bout, serveurs sans stockage persistant, et possibilité pour des chercheurs indépendants de vérifier le code exécuté. Cette transparence, documentée publiquement, renforce la crédibilité de la démarche et constitue une référence dans l'industrie.

Le cadre européen, catalyseur plutôt que frein

L'Europe est en avance sur l'encadrement de l'IA, et cela influence directement les choix techniques. Le RGPD impose le consentement explicite pour tout traitement de données personnelles ainsi qu'un droit à la portabilité. L'IA Act (Règlement UE 2024/1689) ajoute des obligations de transparence pour les systèmes d'IA à usage général, y compris embarqués. Pour les fabricants, l'IA on-device offre une réponse élégante à ces exigences : si les données ne quittent pas l'appareil, la conformité s'en trouve simplifiée.

Ces contraintes se traduisent en adaptations concrètes. Certains services d'IA ont été ajustés pour garantir que les images ou textes traités ne soient pas conservés au-delà du temps de traitement. Des panneaux de contrôle ont été ajoutés aux réglages pour lister les données traitées localement et permettre d'en effacer l'historique. Des indicateurs visuels signalent quand l'IA intervient. Loin de brider l'innovation, ce cadre pousse vers des solutions plus respectueuses de la vie privée, qui deviennent ensuite la norme au-delà de l'Europe. Un marché de plusieurs centaines de millions de consommateurs pèse suffisamment pour imposer ses standards. Pour approfondir les droits des utilisateurs et les bonnes pratiques, notre guide sur l'IA et la vie privée détaille les leviers concrets de maîtrise des données personnelles.

La confidentialité par le local n'est pas une garantie absolue : elle dépend de la frontière, parfois floue, entre ce qui reste sur l'appareil et ce qui part. Mais elle déplace le curseur dans le bon sens. Moins une donnée voyage, moins elle s'expose.

On-device et cloud : un tableau des forces respectives

Opposer frontalement l'inférence locale et l'inférence distante serait une erreur. Les deux approches sont complémentaires, et le bon arbitrage dépend de la tâche. Un panorama comparatif aide à raisonner.

Les limites réelles de l'IA locale

L'honnêteté commande de reconnaître les bornes de l'exécution locale. La première est la taille des modèles : un appareil mobile plafonne aujourd'hui à quelques milliards de paramètres, là où les modèles cloud en comptent des dizaines ou des centaines de milliards. Pour le raisonnement long, la connaissance encyclopédique fine ou la génération de contenus très élaborés, le cloud garde l'avantage.

La deuxième limite est énergétique. L'inférence locale consomme la batterie : un NPU en charge tire une puissance non négligeable, et un usage intensif de l'IA se ressent sur l'autonomie. Les fabricants atténuent cet effet par des mécanismes d'optimisation — mise en veille du NPU entre les requêtes, répartition dynamique vers les cœurs basse consommation pour les tâches légères, regroupement des opérations — mais le coût énergétique reste un paramètre à surveiller.

La troisième limite tient à la mémoire, particulièrement critique pour les usages émergents. Un agent autonome qui devrait maintenir un contexte riche — historique des actions, état des applications, préférences — tout en exécutant un modèle atteint vite les bornes de la mémoire vive disponible. C'est aujourd'hui l'un des principaux obstacles techniques à la généralisation des assistants locaux les plus ambitieux.

Ce qui vient : agents locaux, multimodalité, inférence répartie

L'IA on-device n'a pas fini de progresser. Plusieurs axes prospectifs se dessinent, ancrés dans les feuilles de route déjà publiques.

Les agents locaux, prochaine frontière

Les fonctions de coordination entre applications préfigurent l'étape suivante : des agents capables d'exécuter des séquences d'actions sans intervention à chaque étape. Un agent local pourrait surveiller une boîte de réception, repérer une facture, l'ajouter à un suivi comptable et programmer un rappel — le tout sur l'appareil, sans exposer ces informations au réseau. Le principal obstacle reste la mémoire : maintenir un contexte riche tout en exécutant le modèle sollicite fortement la mémoire vive. Les prochaines générations de puces, avec des architectures mémoire plus efficaces et des NPU capables de gérer des contextes plus longs, devraient desserrer cette contrainte. Pour un panorama complet des architectures d'agents, notre dossier sur l'IA agentique détaille les cadres logiciels et les cas d'usage.

La génération multimédia locale

La génération d'images sur l'appareil est déjà une réalité pour les styles non photoréalistes. La frontière suivante concerne la vidéo et l'audio. Des démonstrations de génération de courts clips vidéo directement sur puce mobile, à partir de modèles de diffusion quantifiés, existent déjà : le rendu n'est pas instantané, mais suffisant pour des usages créatifs. La génération musicale locale progresse de même, avec des modèles compacts produisant de courtes boucles en quelques secondes de calcul. La qualité reste en retrait par rapport aux versions distantes, mais la trajectoire est nette.

L'inférence répartie entre appareils

Une piste plus prospective consiste à faire collaborer plusieurs appareils d'un même foyer pour exécuter un modèle plus grand que ce que chacun pourrait gérer seul. Un téléphone traiterait les premières couches d'un modèle, transmettrait les résultats intermédiaires à une tablette proche, qui achèverait l'inférence. Cette approche permettrait, à terme, d'exécuter localement des modèles de plusieurs milliards de paramètres supplémentaires en répartissant la charge, sans jamais solliciter le cloud. Les feuilles de route des fabricants de puces indiquent par ailleurs que les générations à venir viseront l'exécution de modèles nettement plus volumineux, portées par des architectures mémoire unifiée plus généreuses et des NPU franchissant de nouveaux paliers de puissance. À cet horizon, un terminal haut de gamme disposera d'une capacité d'inférence comparable à celle d'un ordinateur de bureau d'il y a quelques années.

La convergence des appareils

Un dernier axe mérite mention : l'unification de l'expérience d'IA entre le téléphone, la tablette et l'ordinateur. Les grands écosystèmes tendent vers un modèle unique qui suit l'utilisateur d'un appareil à l'autre, avec synchronisation du contexte et des préférences. Cette continuité, portée par des moteurs d'inférence communs à toutes les plateformes d'un même écosystème, dépasse le seul univers mobile et gagne le poste de travail. Le mouvement engagé sur le téléphone irrigue désormais l'ensemble des appareils personnels.

L'IA locale, une réalité quotidienne

Que retenir de ce panorama ? D'abord, que l'IA on-device n'est plus un pari technologique mais une réalité fonctionnelle que des centaines de millions de personnes utilisent sans même y penser. Les trois piliers — latence, confidentialité, autonomie — se renforcent mutuellement, et un quatrième, le coût pour les fabricants, garantit que cet investissement se poursuivra.

Ensuite, que la mécanique repose sur un trépied cohérent : des puces spécialisées dont il faut savoir lire les chiffres sans se laisser hypnotiser par les TOPS, des modèles compacts calibrés pour ce matériel, et des techniques de quantification qui, en divisant la précision numérique, ont multiplié les usages possibles. Les mesures publiées le confirment : un format 4 bits bien choisi réduit la latence de moitié, l'entier 8 bits abaisse coûts et énergie d'environ moitié, et des modèles de quelques milliards de paramètres tiennent dans quelques gigaoctets de mémoire.

Enfin, que l'architecture gagnante est hybride. Le local traite le quotidien avec réactivité et discrétion ; le distant prend le relais pour l'exceptionnel. La vraie question, pour un développeur comme pour un utilisateur averti, n'est donc pas « local ou cloud ? » mais « quelle tâche mérite quel traitement ? ». C'est cet arbitrage, et non un dogme, qui définit la bonne pratique.

La prochaine étape — des agents locaux capables de déléguer des séquences d'actions complexes — se dessine déjà. Les puces, les modèles et les logiciels sont en place ; il reste à desserrer la contrainte mémoire et à bâtir les interfaces de confiance qui permettront de confier des tâches sensibles à un agent qui n'exposera rien au réseau. C'est un chantier passionnant, que nous continuerons de suivre. Pour prolonger la réflexion sur les modèles distants qui complètent l'IA embarquée, notre comparatif des grands assistants d'IA éclaire l'autre versant de l'équation.

Sources

Cet article s'appuie sur des travaux techniques publics et vérifiables :

• Lu et al., « Small Language Models: Survey, Measurements, and Insights » — arXiv 2409.15790 (définition des SLM, 57 modèles mesurés, empreinte mémoire, gains de la quantification 4 bits).
• Apple, « Apple Intelligence Foundation Language Models Tech Report 2025 » — arXiv 2507.13575 (modèle fondation ~3 milliards de paramètres, quantification 2 bits, partage du cache clé-valeur, ossature visuelle 300 M).
• Meta / PyTorch, « ExecuTorch — A Unified PyTorch Solution to Run AI Models On-Device » — arXiv 2605.08195 (moteur d'inférence unifié multi-backend).
• Android Developers, « On-device GenAI APIs as part of ML Kit help you easily build with Gemini Nano » — android-developers.googleblog.com (service système d'IA, adaptateurs LoRA par tâche, plateformes de puces prises en charge).
• « Empowering Edge Intelligence: A Comprehensive Survey on On-Device AI Models » — arXiv 2503.06027 (panorama des modèles d'IA sur appareil).
• MLCommons, benchmark de référence MLPerf Mobile — mlcommons.org (mesures standardisées de latence et de débit sur mobile).