L’IA sur mobile : comment savoir ce qui s’exécute sur l’appareil

Dire qu’un téléphone intègre une IA sur l’appareil peut désigner une capacité du processeur, une fonction précise ou une partie du flux de travail. Cela ne prouve pas, à lui seul, que tous les outils intelligents du téléphone fonctionnent localement. Une application peut utiliser un modèle installé pour une tâche et faire appel à des serveurs pour une autre, ou combiner les deux méthodes au cours d’une même interaction. Il est donc préférable de se demander quelle tâche est traitée où, plutôt que de chercher à savoir si le téléphone « possède une IA locale ». Une appellation générale décrit parfois une technologie disponible sans préciser le fonctionnement réel d’une fonction destinée à l’utilisateur.

Cette distinction a des conséquences pratiques. Si une opération s’effectue sur le téléphone lui-même, elle pourrait rester disponible sans connexion, mais cela dépend de l’application et de ses autres exigences. Si un serveur intervient, une connexion et la disponibilité du service peuvent être nécessaires. Le lieu de traitement compte aussi pour comprendre la gestion des données, mais une exécution locale ne garantit pas automatiquement la confidentialité. Il faut encore vérifier quelles données l’application recueille, lesquelles elle synchronise et quels contrôles elle propose. Savoir où se déroule le calcul répond à une question précise ; cela ne décrit pas à lui seul l’ensemble des flux de données ni les conditions d’utilisation de la fonction.

Commencez par rechercher le nom exact de la fonction, plutôt que les formulations générales d’une campagne. Consultez la documentation du fabricant ou du développeur consacrée à cette fonction précise et vérifiez si elle indique un traitement sur l’appareil, dans le cloud ou une combinaison des deux. La documentation destinée aux développeurs Android décrit, par exemple, l’intégration de l’inférence de modèles de langage sur Android avec Google AI Edge. Elle permet de vérifier qu’une voie technique d’exécution locale existe, mais ne prouve pas qu’une fonction particulière d’un téléphone commercial l’utilise. Un guide de plateforme et l’implémentation d’un produit constituent des preuves de nature différente : ne prenez pas l’un pour la confirmation de l’autre.

Notez également les conditions susceptibles de modifier le résultat : modèle de téléphone, version du système, langue, région, téléchargement préalable du modèle, autorisations et connexion. La disponibilité annoncée peut dépendre de ces exigences et varier d’un utilisateur à l’autre. Pour organiser vos vérifications, comparez les points suivants. Recherchez des indications qui concernent la fonction précise et sa configuration actuelle, au lieu de supposer qu’une exigence indiquée pour un modèle ou une région vaut partout. Si la documentation ne tranche pas l’un de ces points, consignez cette incertitude plutôt que de la combler par déduction.

• Tâche : l’action précise décrite par la source, par exemple résumer un texte ou reconnaître une image.
• Traitement : l’indication explicite que le calcul se fait localement, sur des serveurs ou selon une approche hybride.
• Exigences : connexion, modèle de téléphone, version, région, langue et paramètres.
• Données : les informations envoyées, conservées ou associées à un compte, selon la politique applicable.

Un guide destiné aux développeurs peut établir qu’une plateforme permet d’exécuter des modèles sur l’appareil. Google AI Edge documente l’inférence de modèles de langage sur Android au moyen de MediaPipe. Cela précise une possibilité d’implémentation, mais ne permet pas de savoir automatiquement quelles applications l’adoptent, quel modèle elles utilisent ou si elles envoient des requêtes supplémentaires au cloud. La capacité d’une plateforme et le comportement d’une fonction ne sont pas la même affirmation. Un guide technique aide à comprendre ce que les développeurs peuvent créer ; pour établir le fonctionnement d’une fonction destinée au grand public, il faut des éléments qui portent sur cette fonction. Gardez ces niveaux de preuve distincts au moment de conclure.

Il faut aussi distinguer l’exécution locale d’un fonctionnement entièrement indépendant du réseau. Une application peut calculer une réponse sur le téléphone tout en ayant besoin d’une connexion pour ouvrir une session, télécharger des ressources, actualiser des données ou synchroniser des résultats. À l’inverse, le fait qu’une fonction fonctionne hors ligne lors d’un test donné ne révèle pas à lui seul ce qui se passe dans d’autres situations d’utilisation. Le guide Android sur l’architecture offline-first présente la disponibilité hors ligne comme un choix de conception de l’application et de sa couche de données ; il ne permet pas de déduire où un produit particulier exécute son IA. Un essai sans connexion renseigne donc sur la disponibilité dans ce test, sans résoudre les questions plus larges du lieu de traitement ou de la gestion des données.

Pour évaluer la confidentialité, recherchez des informations distinctes sur le traitement, la conservation et les contrôles. La documentation d’Apple sur Apple Intelligence distingue le traitement sur l’appareil des requêtes qui peuvent recourir à Private Cloud Compute pour certaines tâches. Apple présente son système cloud comme conçu pour protéger les données pendant ce traitement. Il s’agit de l’explication du fournisseur concernant son architecture et les garanties qu’il déclare ; il ne faut pas en faire une affirmation universelle sur tous les assistants, fabricants ou services. Lorsque vous consultez ces informations, identifiez l’écosystème et les requêtes concernés, sans supposer que le même dispositif s’applique à d’autres produits.

Une description utile devrait permettre d’identifier les données traitées, le moment où elles quittent le téléphone, la finalité de ce transfert et ce qui leur arrive ensuite. Si le texte promet seulement que les données sont « protégées » ou que l’IA est « privée », sans préciser le flux, une question reste sans réponse. Vérifiez aussi les réglages d’historique, d’activité, de synchronisation et d’utilisation des données, ainsi que leur rattachement au système d’exploitation ou à une application tierce. Ne confondez pas une mesure de sécurité annoncée avec l’absence de transfert de données, ni l’absence d’explication publique avec la preuve que des données sont envoyées. Une conclusion prudente précise ce que la documentation confirme, ce qu’elle n’établit pas et les éléments qui restent indéterminés.

Lorsqu’on examine une fonction, la conclusion doit correspondre à la portée des éléments disponibles. Si une documentation consacrée à cette fonction indique qu’une tâche est traitée localement, on peut le dire en précisant les exigences et limites mentionnées. Si un document explique seulement un outil pour développeurs ou une capacité générale de plateforme, la conclusion doit rester à ce niveau. Si aucune explication vérifiable ne concerne la fonction, il convient d’indiquer que la méthode de traitement n’est pas confirmée par les sources consultées. Cette démarche évite de transformer une possibilité technique en affirmation sur un produit fini et d’affirmer qu’un traitement est local ou dans le cloud lorsque cela reste inconnu.

Avant de choisir un téléphone ou d’activer un outil, il est raisonnable d’effectuer quatre vérifications : trouver la documentation de la fonction exacte, relever ses exigences, consulter la politique de données correspondante et tester le comportement hors ligne uniquement comme vérification pratique de disponibilité. Ce dernier test ne remplace pas la documentation sur la confidentialité et ne prouve pas, à lui seul, ce qu’il advient de chaque donnée. Les recherches disponibles ici ne démontrent pas l’existence d’une annonce récente précise et ne permettent pas d’attribuer une méthode de traitement à toutes les fonctions d’une marque. Ce guide propose donc une méthode de vérification, et non une actualité sur un lancement. La conclusion doit rester circonscrite à la tâche, aux éléments et aux conditions effectivement examinés.