L'IA sur mobile : ce qui tourne sur l'appareil, ce qui part au serveur

Sur mobile, la question « où tourne le modèle » n’est pas un détail d’implémentation. Elle change la taille du téléchargement, l’autonomie, le comportement hors réseau, et la façon dont on livre une correction.

Elle se tranche tâche par tâche. Une même application peut très bien détecter une langue localement et rédiger un résumé côté serveur.

Le réflexe par défaut : le serveur

Je commence toujours par là, pour trois raisons.

Le modèle reste à jour. Un modèle appelé par le réseau se change sans publier de nouvelle version. Sur mobile, où une publication passe par une validation de magasin et où une partie des utilisateurs ne met jamais à jour, cette différence est majeure : un modèle embarqué dans la version 2.1 vivra sur les téléphones pendant des années.

La logique reste unique. Si l’application web et l’application mobile appellent le même service, elles se comportent pareil. Dupliquer un traitement des deux côtés, c’est garantir une divergence sous six mois.

L’application reste légère. Un modèle utile pèse de quelques dizaines à quelques centaines de mégaoctets. Sur un magasin, le poids de téléchargement a un effet mesurable sur l’installation, et il est très mal perçu sur un forfait limité.

Les quatre cas où l’appareil gagne

La latence est dans la boucle d’interaction. Tout ce qui doit répondre pendant que l’utilisateur agit — détecter du texte dans le viseur, guider un cadrage, suggérer pendant la frappe. Un aller-retour réseau se voit ici, et il se voit d’autant plus que le réseau est mauvais, c’est-à-dire précisément quand l’utilisateur est en déplacement.

L’usage a lieu sans réseau. Un encadrant au bord d’un terrain, un technicien en sous-sol, un opérateur en zone blanche. Si la fonctionnalité doit marcher là, elle doit être locale — ou prévoir explicitement une dégradation, ce qui est souvent le meilleur compromis.

La donnée ne doit pas sortir. Photo d’un document d’identité, contenu médical, image de sécurité. Un traitement local permet d’annoncer que rien ne quitte l’appareil, et c’est un argument qui se vérifie — donc qui vaut quelque chose.

Le volume rendrait le coût serveur absurde. Analyser chaque image d’un flux vidéo par appel réseau n’est pas seulement lent, c’est économiquement impossible. Ce sont typiquement des tâches de vision, courtes et massives.

Le coût caché du modèle embarqué

C’est la partie qu’on sous-estime, et elle ne se voit pas au moment du choix.

La batterie. Un traitement local mobilise le processeur neuronal ou le GPU. Sur un usage ponctuel, c’est indolore. Sur un usage continu, l’appareil chauffe, le système réduit les performances, et l’utilisateur attribue à l’application une lenteur qui vient de la protection thermique.

La disparité du parc. Les appareils récents ont des accélérateurs efficaces. Les appareils de cinq ans, non. Un traitement fluide sur le téléphone du développeur peut être inutilisable sur celui d’une bonne partie des utilisateurs. Il faut donc tester sur un appareil d’entrée de gamme ancien — c’est le seul test qui compte, et c’est le plus souvent négligé.

La double implémentation. Les plateformes n’ont pas les mêmes cadres d’exécution ni les mêmes formats de modèle. Un traitement local, c’est deux intégrations à écrire et à maintenir, plus la conversion du modèle. C’est ce qui rend un embarqué bien plus cher qu’il n’en a l’air.

L’impossibilité de corriger vite. Un modèle local qui se comporte mal sur un cas se corrige par une publication, avec ses délais de validation. Côté serveur, c’est un déploiement.

Photo : domaine public (CC0).

Le découpage qui marche

Dans la pratique, le partage que je retiens presque toujours :

• sur l’appareil — la détection et le pré-traitement : y a-t-il un document dans l’image, la photo est-elle nette, l’utilisateur parle-t-il. Ce sont des tâches courtes, fréquentes, dont le résultat conditionne la suite ;
• côté serveur — la compréhension et la génération : extraire les valeurs, rédiger, décider.

Ce découpage a un bénéfice inattendu sur la facture : le filtrage local évite d’envoyer les cas inutiles. Une photo floue rejetée sur l’appareil, c’est un appel serveur en moins et une seconde d’attente épargnée à l’utilisateur.

Photo : Wilfred Iven — licence CC0.

Le cas hybride, et sa complexité réelle

Une option intermédiaire revient régulièrement en cadrage : faire tourner localement quand c’est possible, et basculer sur le serveur sinon. Sur le papier, on prend le meilleur des deux.

Dans les faits, c’est le choix le plus coûteux, et il faut le dire avant de s’y engager. Il suppose deux implémentations à maintenir, une règle de bascule à écrire et à tester, et surtout deux comportements possibles pour la même action — donc deux jeux de résultats à valider, et des incidents où la première question devient « ça a tourné où ? ».

Je ne le déconseille pas par principe. Je demande simplement qu’on nomme le déclencheur de la bascule avant de commencer : absence de réseau, type d’appareil, taille du contenu. Quand cette règle ne se formule pas en une phrase, l’hybride n’est pas encore mûr.

Ce que l’exécution sur l’appareil coûte vraiment

Trois postes que la comparaison « pas de coût serveur » laisse de côté.

Le poids de l’application. Embarquer un modèle ajoute des dizaines, parfois des centaines de mégaoctets. Sur un magasin d’applications, c’est ce qui fait renoncer au téléchargement en données mobiles — et ce qui fait désinstaller quand l’appareil manque de place.

La batterie et la chauffe. Une inférence soutenue mobilise le processeur graphique ou l’unité dédiée. Sur quelques secondes, personne ne s’en aperçoit ; sur un traitement continu, l’appareil chauffe, le système bride, et l’application apparaît en tête de la consommation.

La mise à jour du modèle. Corriger un comportement suppose de republier l’application et d’attendre que le parc se mette à jour — des semaines, parfois des mois. Côté serveur, la même correction est effective en une minute pour tout le monde.

La question qui tranche, en pratique

Une seule : est-ce que ça doit marcher sans réseau ?

Si oui — un technicien en sous-sol, un contrôle sur le terrain — l’exécution sur l’appareil n’est pas une optimisation, c’est la seule option, et il faut en accepter les trois coûts ci-dessus.

Si non, le serveur gagne presque toujours : modèle plus capable, mise à jour immédiate, aucun poids ajouté à l’application. Reste alors à traiter la latence et la confidentialité des données envoyées, qui sont des sujets bien mieux outillés que la contrainte matérielle d’un téléphone.

La question à trancher au cadrage

Une seule, posée pour chaque traitement plutôt que pour l’application entière :

Cette tâche doit-elle répondre pendant que l’utilisateur agit, ou peut-elle attendre un aller-retour réseau ?

Si elle peut attendre, elle part au serveur — et on garde la possibilité de changer d’avis, ce qui n’est pas vrai dans l’autre sens. Un traitement serveur peut être rapatrié sur l’appareil plus tard ; un modèle embarqué dans une version publiée reste installé chez les utilisateurs bien après qu’on a décidé de s’en passer.