Routage de modèles pour agent mobile : choisir Kimi, DeepSeek, GLM ou un autre modèle
Guide durable pour router un modèle dans un agent Android : fiabilité, latence, coût, contexte, confidentialité, fallback et preuve d’action avec FoneClaw.
- Le routage de modèles pour agent mobile consiste à choisir le bon moteur pour une tâche précise, pas à sacrer un modèle permanent pour toutes les actions Android.
- La décision doit croiser fiabilité des appels d’outils, latence, coût, contexte utile, confidentialité, disponibilité et capacité de fallback.
- Kimi, DeepSeek et GLM sont des candidats actuels intéressants, mais leur valeur pour un agent Android se vérifie dans une boucle complète : plan, outil, permission, approbation, résultat et reprise.
- Dans FoneClaw, le modèle raisonne et prépare l’action ; FoneClaw gouverne l’exécution Android avec 100+ built-in tools, des confirmations visibles et une récupération quand le téléphone ne peut pas continuer.
Router plutôt que classer un vainqueur
Le routage de modèles pour agent mobile consiste à choisir le modèle le plus adapté à une tâche donnée, puis à vérifier que ce choix produit une action fiable sur le téléphone. La bonne question n’est donc pas « quel modèle gagne ? », mais « quel modèle convient à cette action Android, avec ce contexte, ce coût, cette latence et ce niveau de risque ? »
Un classement statique vieillit vite. Les modèles changent, les prix évoluent, les fenêtres de contexte s’étendent, les API apparaissent ou se retirent, et le comportement en appels d’outils peut varier d’une version hébergée à l’autre. Kimi, DeepSeek, GLM et d’autres modèles peuvent chacun être utiles, mais un agent mobile ne vit pas dans un tableau de benchmark. Il vit dans une boucle d’exécution : comprendre la demande, choisir une capacité, préparer des arguments, demander l’accord quand il le faut, agir dans Android et contrôler le résultat.
Cette séparation est centrale dans FoneClaw. Le modèle est un moteur de compréhension et de planification. L’exécution Android reste une couche distincte, avec des outils gouvernés, des permissions visibles et des reprises lorsque l’état du téléphone ne correspond pas au plan. Pour les lecteurs qui veulent configurer un endpoint plutôt que rester dans la théorie, notre guide Connecter une API de modèle IA à un agent Android avec FoneClaw détaille le parcours de configuration sans transformer cette page en tutoriel d’API.
Cinq signaux pour choisir un modèle
Un bon routage de modèles IA commence par cinq signaux : fiabilité, latence, coût, contexte et confidentialité. Ces critères ne s’additionnent pas mécaniquement. Ils se pondèrent selon la tâche. Préparer une note courte, lire un écran, planifier un enchaînement calendrier-message ou résumer un document long ne demande pas la même route.
| Signal | Question pratique | Impact sur un agent Android |
|---|---|---|
| Fiabilité | Le modèle produit-il des appels d’outils stables, des arguments corrects et des refus utiles en cas d’ambiguïté ? | Une bonne réponse textuelle ne suffit pas si l’action Android échoue ou vise le mauvais élément. |
| Latence | L’utilisateur attend-il une réponse immédiate dans un flux mobile ? | Les petites actions répétées supportent mal un modèle lent, même très puissant. |
| Coût | La tâche est-elle fréquente, longue ou sensible au budget ? | Le coût des LLM influence les choix de routage, surtout pour les workflows répétés. |
| Contexte | Faut-il tenir compte d’un écran, d’un historique, d’un document ou de plusieurs étapes ? | Une grande fenêtre de contexte aide seulement si le modèle utilise les bons éléments sans se disperser. |
| Confidentialité | Quelles données quittent l’appareil et quel fournisseur les traite ? | Les routes locales, en ligne ou personnalisées n’ont pas les mêmes contraintes de données et de disponibilité. |
La fiabilité des appels d’outils mérite une attention particulière. Un modèle pour agent Android doit produire des intentions structurées, reconnaître quand une information manque et éviter d’inventer une capacité. Une demande comme « envoie ça à Julie » peut sembler simple, mais l’agent doit résoudre le contact, comprendre « ça », sélectionner l’action, préparer le contenu et attendre la confirmation si l’envoi est sensible.
La latence et le coût orientent souvent la route de base. Un modèle rapide et économique peut traiter les tâches de tri, de reformulation ou de sélection simple. Un modèle plus fort peut être réservé aux plans longs, aux ambiguïtés et aux contextes denses. Pour approfondir le lien entre coût et architecture d’agent, notre article Coût en tokens des agents IA : pourquoi les actions locales sur téléphone peuvent réduire la facture explique pourquoi tout ne doit pas être envoyé au modèle le plus cher.
Kimi, DeepSeek et GLM comme candidats
Kimi, DeepSeek et GLM sont de bons exemples de candidats actuels pour une politique de routage, parce qu’ils représentent des directions différentes : disponibilité dans des sélecteurs de modèles, optimisation de coût, raisonnement, contexte et ambition d’infrastructure. L’arrivée de Kimi K3 dans un sélecteur grand public de développement, signalée par l’annonce GitHub sur Kimi K3 dans Copilot, montre qu’un modèle peut gagner en visibilité rapidement. Ce signal est utile, mais il ne prouve pas à lui seul une fiabilité d’action Android.
DeepSeek et GLM doivent être lus de la même manière : comme des moteurs potentiels, pas comme des garanties d’exécution mobile. Un modèle peut exceller sur du raisonnement, du code, du contexte long ou une langue donnée, puis se montrer moins régulier lorsqu’il doit produire des appels d’outils stricts avec des champs exacts. À l’inverse, un modèle moins spectaculaire dans un classement général peut être très efficace pour une tâche courte, bien bornée et fréquente.
La vérification doit donc se faire tâche par tâche. Pour un agent Android, nous testons d’abord la qualité du plan, puis la stabilité des arguments, puis la capacité à demander une clarification. Ensuite seulement vient l’exécution côté téléphone. Si le modèle choisit le mauvais outil, oublie une confirmation ou ignore une permission manquante, le problème ne se voit pas toujours dans une note de benchmark.
Le bon usage de Kimi, DeepSeek, GLM ou d’un autre modèle est donc de les placer dans une matrice vivante. Une route peut servir les réponses rapides, une autre les tâches longues, une autre les workflows sensibles, et une autre le fallback quand un fournisseur est indisponible. Le routage de modèles pour agent mobile devient une politique d’exploitation, pas une comparaison figée.
Réagir aux changements de prix et d’accès
Les prix, quotas et disponibilités d’API changent assez souvent pour rendre fragile une stratégie « set and forget ». L’annonce de l’API unifiée de Google pour le routage de modèles illustre une tendance d’infrastructure : les équipes veulent piloter plusieurs fournisseurs derrière une surface gérée, avec des règles de route plutôt qu’un seul modèle câblé en dur. Ce mouvement confirme un besoin réel, mais il ne remplace pas les tests produit.
Quand un prix baisse, il ne faut pas basculer toutes les tâches automatiquement. Il faut vérifier la stabilité des schémas, la latence, les erreurs de fournisseur, la qualité en langue locale et le comportement sur les cas ambigus. Un modèle moins cher peut réduire la facture sans dégrader l’expérience si la tâche est simple et réversible. Pour une action sensible, le coût ne doit jamais écraser l’exigence de fiabilité et d’approbation.
Une bonne politique de fallback distingue trois niveaux. Le premier est le fallback technique : un fournisseur répond mal ou trop lentement. Le deuxième est le fallback qualité : le modèle ne comprend pas assez bien la demande ou produit des arguments faibles. Le troisième est le fallback produit : le téléphone ne peut pas continuer parce qu’une permission manque, une app n’est pas prête ou l’utilisateur doit intervenir.
Dans FoneClaw, nous gardons ces niveaux séparés. Changer de modèle peut résoudre un problème de raisonnement, mais pas une permission Android refusée. Passer à un fournisseur plus disponible peut améliorer la continuité, mais ne doit pas rendre une action sensible silencieuse. Le routage doit préserver les confirmations, la visibilité et les limites de l’action.
Mesurer la qualité dans la boucle Android
La qualité d’un modèle pour agent Android se mesure à l’intérieur de la boucle complète. Le premier point est le plan : le modèle comprend-il l’objectif et propose-t-il une séquence compatible avec le téléphone ? Le deuxième point est l’argument : produit-il les bons champs, dans le bon format, avec une ambiguïté explicitement signalée ? Le troisième point est l’état de l’appareil : l’action est-elle possible avec les permissions, l’app et l’écran disponibles ?
Cette évaluation évite un piège fréquent. Un modèle peut répondre correctement en français à la demande « prépare un SMS à Camille », tout en échouant dans l’exécution s’il confond deux contacts, oublie de demander validation ou continue comme si l’accès aux messages était déjà accordé. L’agent doit donc tester les erreurs de terrain, pas seulement les réponses idéales.
Nous recommandons un test reproductible : même téléphone, même compte, mêmes permissions, même application cible, même demande, puis comparaison de deux routes de modèle. Notez les échecs par type : mauvaise intention, mauvais outil, argument incomplet, latence trop forte, confirmation absente, permission manquante, résultat non visible ou reprise insuffisante. Ces étiquettes sont plus utiles qu’un score global.
Pour une méthode plus complète de mesure, notre guide Benchmark d’agents Android : évaluer un agent téléphonique en 2026 montre comment transformer les tâches réelles en essais comparables. Le routage de modèles devient beaucoup plus solide quand les décisions reposent sur des échecs observés.
Configurer le raisonnement, gouverner l’action
Chez FoneClaw, nous construisons le routage autour d’une séparation nette : le modèle raisonne, FoneClaw gouverne l’action Android. L’utilisateur peut commencer avec le modèle gratuit par défaut ou configurer une route compatible, en ligne ou prise en charge sur l’appareil selon le cas. Le modèle aide à comprendre la demande, à choisir une capacité possible et à préparer un plan. FoneClaw conserve ensuite les contrôles d’exécution.
Cette architecture nous évite de confondre provider et action. Un modèle peut proposer d’ouvrir une app, de préparer un message, de lire un état, de créer une note ou de planifier une étape. FoneClaw vérifie ensuite la capacité disponible parmi 100+ built-in tools, l’état Android, les permissions et le niveau d’approbation requis. AutoAttach, Suggest et Fallback peuvent aider à faire correspondre la demande au bon contexte ou à la bonne capacité, mais ils ne remplacent pas l’accord de l’utilisateur pour les étapes qui engagent une donnée ou une action sensible.
Le routage devient alors un levier de fiabilité. Une tâche courte peut être servie par une route rapide. Une tâche à contexte long peut passer par un modèle plus adapté. Une action incertaine peut déclencher une clarification au lieu d’un outil. Une indisponibilité fournisseur peut activer un fallback sans changer les règles d’approbation. L’exécution visible reste la constante.
Pour relier cette logique au comportement concret d’un agent sur téléphone, notre page Contrôle du téléphone par agent IA : ce qu’un agent Android doit vraiment faire détaille la chaîne qui va de l’intention à l’action : app cible, permission, état visible, confirmation et résultat vérifié.
Le premier test doit rester réversible. Comparez deux routes sur une action simple, comme créer une note de test, préparer un événement sans l’enregistrer immédiatement ou ouvrir une app précise. Mesurez la compréhension, le temps de réponse, la qualité du plan, l’appel d’outil proposé, l’approbation et la reprise. C’est dans ce petit essai que le meilleur modèle pour un workflow mobile commence à apparaître.
Construire une politique de routage
Une politique de routage pratique tient sur une séquence courte. D’abord, classez la tâche : conversation, lecture de contexte, préparation d’action, action sensible ou reprise après échec. Ensuite, définissez un plancher de qualité : schéma stable, bonne langue, ambiguïtés signalées, résultat visible. Puis fixez un plafond de coût et de latence adapté à l’usage réel.
- Choisissez une route rapide pour les demandes simples et fréquentes.
- Réservez une route plus forte aux tâches longues, ambiguës ou riches en contexte.
- Gardez une route de fallback quand un fournisseur ralentit ou devient indisponible.
- Ne basculez pas silencieusement les actions sensibles sans conserver l’approbation et la visibilité.
- Enregistrez les modes d’échec, pas seulement la qualité de réponse.
Cette discipline rend les modèles nommés plus utiles. Kimi, DeepSeek, GLM et les autres ne sont pas des trophées à placer en haut d’une page ; ce sont des routes candidates à tester dans un agent mobile réel. Le routage de modèles pour agent mobile fonctionne quand il améliore une tâche Android complète : comprendre, planifier, appeler la bonne capacité, respecter les permissions, afficher le résultat et reprendre proprement si le téléphone bloque.