IA embarquée sur l’appareil : confidentialité et contraintes

Une infirmière à domicile dicte son compte rendu dans la voiture, entre deux visites, dans une vallée où le réseau mobile disparaît. Un contrôleur photographie un équipement dans un local technique en sous-sol. Un juriste veut résumer un document confidentiel sans l’envoyer vers un service en nuage. Dans les trois cas, la même idée revient : et si le modèle tournait directement sur l’appareil ? L’IA embarquée promet deux choses à la fois, la confidentialité et le fonctionnement hors ligne. Ce guide aide à vérifier si la promesse tient pour votre cas, et à quel prix.

De quoi parle-t-on exactement

On parle ici d’inférence locale : un modèle déjà entraîné s’exécute sur le téléphone, la tablette, le poste de travail, la passerelle industrielle ou la caméra, sans envoyer les données à un serveur pour obtenir le résultat. L’entraînement, lui, reste presque toujours centralisé.

Le sujet a changé d’échelle en 2024. Les grands constructeurs de téléphones et de systèmes d’exploitation ont intégré des modèles de langage compacts directement dans leurs appareils, et les ordinateurs portables récents embarquent des puces dédiées aux calculs d’IA. Parallèlement, plusieurs familles de modèles ouverts de petite taille, de quelques centaines de millions à quelques milliards de paramètres, permettent à une organisation de déployer ses propres modèles sur ses propres appareils, grâce à des environnements d’exécution comme Core ML, LiteRT (anciennement TensorFlow Lite), ONNX Runtime ou llama.cpp.

Ces modèles sont plus petits que les grands modèles hébergés, et souvent compressés par quantification : leurs paramètres sont stockés sur moins de bits, ce qui réduit leur taille et leur consommation au prix d’une légère perte de qualité. À titre d’ordre de grandeur, un modèle de trois milliards de paramètres quantifié sur quatre bits occupe environ un gigaoctet et demi de mémoire, avant même les données qu’il traite.

Ce que l’appareil protège vraiment

Le traitement local supprime un risque majeur : la donnée brute ne part pas sur un serveur tiers, ne transite pas sur le réseau, ne se retrouve pas dans les journaux d’un fournisseur. Pour des documents confidentiels, des données de santé ou des images de sites sensibles, c’est un gain réel. Mais la confidentialité d’un système ne se résume pas au lieu du calcul.

Le dernier point mérite une vigilance particulière. Plusieurs architectures dites « sur l’appareil » envoient en réalité au serveur les requêtes trop complexes pour le modèle local. Le schéma peut être parfaitement légitime, à condition d’être explicite, documenté et, si nécessaire, désactivable : l’utilisateur et le responsable du traitement doivent savoir quand la donnée part.

Sur le plan juridique, le lieu du calcul ne change pas la nature du traitement. Le RGPD s’applique dès que des données personnelles sont traitées, y compris localement, et l’organisation qui déploie l’application en reste responsable. De même, les obligations du règlement européen sur l’IA dépendent de l’usage du système (un système qui sert à évaluer des candidats ou à décider d’un droit est à haut risque où qu’il tourne), pas de l’endroit où il s’exécute.

Les contraintes qu’il faut chiffrer

La mémoire. Un modèle de langage local consomme une part importante de la mémoire vive de l’appareil. Sur un téléphone qui fait tourner d’autres applications, le système peut fermer le modèle sans prévenir. Il faut connaître la mémoire réellement disponible sur le parc, pas sur la fiche technique.

L’énergie et la chaleur. Une inférence prolongée vide la batterie et chauffe l’appareil, qui réduit alors sa fréquence de calcul. Une transcription de quelques minutes passe ; un traitement continu pendant une journée de travail demande des tests en conditions réelles.

La diversité du parc. Un modèle qui répond en une seconde sur le poste du chef de projet peut en mettre dix sur la tablette d’un agent de terrain équipé il y a quatre ans. L’évaluation doit couvrir chaque classe d’appareils réellement utilisée, et prévoir ce que fait l’application quand l’appareil ne suffit pas.

La qualité. Pour des tâches bornées (transcrire, extraire des champs, classer, traduire une phrase), les petits modèles donnent souvent des résultats suffisants. Pour raisonner sur un dossier complexe ou répondre à partir d’une large base documentaire, l’écart avec les grands modèles hébergés reste important. Il se mesure sur vos données, avec des critères fixés avant les essais.

Les mises à jour. Corriger un modèle hébergé se fait en une fois. Corriger un modèle déployé sur mille appareils suppose un canal de distribution, des versions signées, un déploiement progressif et la capacité de revenir en arrière. Plusieurs versions coexisteront toujours sur le terrain : les résultats doivent indiquer quelle version les a produits.

La protection du modèle. Un modèle installé sur un appareil peut être extrait. Si le modèle a été affiné sur des données sensibles, ou s’il représente un investissement important, ce risque doit être évalué.

Appareil, serveur ou hybride : une décision en trois questions

Le schéma hybride est fréquent : l’appareil traite ce qui est sensible ou urgent (transcrire, masquer les noms, extraire des champs), puis seul un résultat réduit, éventuellement pseudonymisé, part vers un serveur pour les traitements plus lourds. C’est souvent le meilleur compromis, à condition que la frontière soit écrite, testée et visible dans l’interface.

Pour les applications qui doivent répondre à partir de vos documents, la question de l’architecture rejoint celle de la méthode : notre comparatif RAG ou affinage de modèle détaille les options. Pour les machines et les capteurs, notre note sur le calcul en périphérie traite le cas industriel.

Les cas qui s’y prêtent, et les autres

Certains usages tirent pleinement parti du traitement local. La transcription de la voix sur le terrain, l’extraction de champs sur un formulaire photographié, le masquage automatique des noms avant tout envoi, la traduction de phrases courtes hors ligne, la reconnaissance visuelle d’un défaut sur une ligne de production où la latence compte : ce sont des tâches courtes, bornées, répétées, où la donnée est sensible ou le réseau incertain.

D’autres s’y prêtent mal. Répondre à des questions sur l’ensemble des procédures d’une organisation suppose d’accéder à une base documentaire centrale et à jour. Rédiger une analyse longue ou raisonner sur plusieurs documents sollicite des capacités que les petits modèles n’ont pas. Prendre ou préparer une décision à fort enjeu demande une traçabilité centralisée que l’appareil ne fournit pas seul. Dans ces cas, l’appareil peut préparer la donnée, mais le traitement principal relève du serveur.

Avant de lancer un projet

• Le cas d’usage est borné : une tâche précise, avec des critères de qualité écrits.
• Le parc d’appareils réel est connu : modèles, mémoire disponible, âge, système.
• Les flux de données sont cartographiés, y compris journaux, télémétrie et synchronisation des résultats.
• Les cas de basculement vers un serveur sont listés, ou explicitement exclus.
• Le stockage local est chiffré et l’appareil perdu peut être effacé à distance.
• Le canal de mise à jour du modèle et le retour arrière sont prévus avant le premier déploiement.
• L’analyse RGPD et la qualification au regard de l’AI Act ont été faites sur l’usage, pas sur l’architecture.

Notre offre IA d’entreprise déploie des agents encadrés et audités, sur serveur, sur l’appareil ou en mode hybride selon la sensibilité des données ; le cadrage commence toujours par ces sept questions.

Questions fréquentes

L'IA embarquée dispense-t-elle des obligations du RGPD ?

Non. Traiter des données personnelles sur l'appareil reste un traitement : finalité, base légale, information des personnes, sécurité et, si nécessaire, analyse d'impact s'appliquent. Le traitement local réduit certains risques, notamment les transferts et l'exposition côté serveur, ce qui peut simplifier l'analyse, mais il ne la supprime pas.

Faut-il des appareils récents pour faire tourner un modèle localement ?

Pour un modèle de langage, oui en général : il faut de la mémoire vive disponible et, idéalement, une puce d'accélération (NPU ou GPU). Pour des modèles plus petits et spécialisés, comme la classification d'images ou la détection de mots-clés, des appareils modestes suffisent. Le test sur le parc réel, et pas seulement sur le dernier modèle de téléphone, est indispensable.

Un petit modèle local est-il assez bon ?

Pour des tâches bornées (transcription, extraction de champs, classement, reformulation courte), souvent oui. Pour un raisonnement complexe ou des réponses s'appuyant sur une large base documentaire, les grands modèles hébergés restent nettement supérieurs. Il faut évaluer sur vos propres cas, avec des critères de qualité définis à l'avance.

Comment mettre à jour un modèle déployé sur de nombreux appareils ?

Comme une application : par un canal de distribution maîtrisé, avec versionnage, signature, déploiement progressif et possibilité de retour arrière. La taille des modèles, souvent de plusieurs centaines de mégaoctets à quelques gigaoctets, impose de prévoir les mises à jour sur réseau sans fil et de vérifier l'espace disponible.