Coût en tokens des agents IA : pourquoi les actions locales sur téléphone peuvent réduire la facture

Le coût en tokens ne raconte qu’une partie de l’histoire

Quand une équipe estime le coût d’un agent IA, elle commence souvent par regarder le prix par token. C’est nécessaire, mais insuffisant. Un agent qui doit comprendre une demande, relire un long contexte, choisir un outil, vérifier l’état du téléphone, demander une confirmation et corriger une erreur peut consommer plusieurs fois plus que prévu. Le prix du modèle est visible ; les boucles ratées le sont moins.

Les pages de tarification comme la tarification API d’OpenAI et la tarification de Vertex AI montrent que le coût du cloud dépend généralement du modèle, du volume d’entrée, du volume de sortie et parfois de la modalité. Nous n’avons pas besoin d’inventer des chiffres pour comprendre le principe : plus l’agent envoie de contexte, plus il produit de réponses et plus il recommence, plus la facture augmente.

Sur téléphone, cette mécanique se complique. Une demande comme « prépare une réponse au dernier message et ajoute un rappel si besoin » peut inclure le texte du message, le contexte de la conversation, l’identité du contact, les règles de l’app, une proposition de réponse, une confirmation et un retour d’état. Si l’agent ne peut pas agir clairement dans Android, il peut repasser plusieurs fois par le modèle pour reformuler ce qu’il ne parvient pas à faire.

Chez FoneClaw, nous lisons le coût comme un problème de tâche complète, pas seulement comme une ligne de facture cloud. Une action prise en charge, bien identifiée et confirmée au bon moment peut éviter des tours de raisonnement inutiles. À l’inverse, un agent qui devine l’interface, échoue, redemande du contexte et fait intervenir l’utilisateur coûte en tokens, en temps et en confiance.

Là où les tokens s’échappent dans une tâche mobile

La fuite de coût commence souvent par le contexte trop large. Pour aider sur une tâche mobile, un agent peut recevoir la demande, l’historique de conversation, des descriptions d’écran, des résultats d’outil, des consignes de sécurité, la liste des actions possibles et plusieurs corrections de l’utilisateur. Chaque élément est utile isolément. Ensemble, ils peuvent transformer une petite action en long échange coûteux.

Les reprises sont encore plus chères. Si l’agent choisit la mauvaise app, interprète mal une notification, ne comprend pas une permission absente ou propose un brouillon au mauvais destinataire, il faut renvoyer du contexte. L’utilisateur corrige, le modèle réanalyse, un nouvel outil est appelé, puis une nouvelle confirmation est demandée. La facture augmente sans que la tâche avance réellement.

Les captures et descriptions d’écran ajoutent une autre charge. Un agent cloud qui n’a pas de compréhension directe de l’état Android peut demander des représentations successives de l’interface. Il faut expliquer où se trouve le bouton, quel écran est ouvert, quelle app est active et quel choix est visible. Si l’état change entre deux étapes, le contexte précédent peut devenir inutile.

Les confirmations consomment aussi, mais elles ne sont pas du gaspillage. Demander « voulez-vous envoyer ce message ? » ou « voulez-vous ouvrir ce réglage ? » ajoute une étape, pourtant elle protège l’utilisateur. Le vrai gaspillage vient des confirmations mal conçues : trop fréquentes, trop vagues, ou répétées parce que l’agent ne sait pas distinguer préparer, proposer et agir. Notre guide pour Automatiser les tâches Android avec une seule commande vocale montre pourquoi une tâche bien découpée réduit les reprises.

Pourquoi le cloud peut décrire le téléphone sans le maîtriser

Un agent uniquement cloud peut très bien raisonner sur une tâche, mais rester loin de l’action réelle. Il peut expliquer comment ouvrir une app, rédiger un message, proposer une suite d’étapes ou analyser une capture. Pourtant, si le téléphone ne fournit pas d’action prise en charge, de permission claire ou de retour fiable, l’agent dépense des tokens à décrire ce que l’utilisateur devra encore faire à la main.

Ce décalage devient visible dans les petites tâches. L’agent sait que l’utilisateur veut envoyer un message, mais il ne peut pas vérifier l’app active. Il propose une réponse, mais ne voit pas le destinataire. Il décrit un réglage, mais ne peut pas ouvrir l’écran. Il explique une marche à suivre, puis l’utilisateur revient parce qu’un menu est différent. Chaque aller-retour ajoute du coût sans résoudre le problème de départ.

Le cloud reste utile pour les tâches de compréhension lourde : long document, analyse complexe, résumé étendu, comparaison de sources. Mais pour un phone agent, le coût réel dépend de la distance entre le raisonnement et l’action. Plus cette distance est grande, plus l’agent doit traduire, décrire, vérifier et recommencer. La question n’est donc pas cloud contre téléphone ; elle est : quelle partie doit être raisonnée dans le cloud, et quelle partie doit être faite proprement sur l’appareil ?

Cette question rejoint notre réflexion sur la Confiance dans un agent IA : contrôle local Android ou sécurité cloud ?. La confiance et le coût se recoupent : quand une action est visible, limitée et confirmée sur le téléphone, il y a moins d’ambiguïté à renvoyer au modèle. Quand tout passe par une description cloud, l’incertitude consomme aussi des ressources.

Ce que les actions locales peuvent réellement économiser

Les actions locales ne suppriment pas tous les coûts. Elles ne remplacent pas un modèle puissant quand il faut comprendre un long dossier, résoudre une demande complexe ou produire une réponse très nuancée. En revanche, elles peuvent réduire le besoin de replanifier une action simple à chaque fois. Ouvrir une app, préparer un brouillon, afficher un réglage ou demander une confirmation ne devraient pas nécessiter une longue discussion cloud à chaque tentative.

Le traitement côté téléphone peut aussi réduire les descriptions inutiles de l’état. Si l’action est prise en charge localement, l’agent n’a pas besoin d’expliquer tout l’écran au modèle pour chaque étape. Il peut s’appuyer sur un parcours connu : demande, permission, action, confirmation, résultat. Moins d’ambiguïté signifie souvent moins de reprises, et donc moins de tokens dépensés pour corriger une même tâche.

La documentation Android sur confidentialité et sécurité rappelle toutefois que les actions locales doivent respecter les permissions et les contrôles du système. Côté FoneClaw, nous ne présentons pas l’action locale comme un raccourci magique. Elle doit rester autorisée, visible et limitée aux capacités réellement prises en charge. Réduire le coût ne doit jamais signifier contourner la sécurité.

Cette logique vaut aussi pour les environnements professionnels. L’article Sécurité des agents IA en entreprise : pourquoi l’exécution locale change le risque approfondit la manière dont le traitement proche des données peut modifier le risque. Pour le téléphone grand public, nous retenons la même idée pratique : rapprocher certaines actions de l’appareil peut réduire le bruit, mais seulement si les permissions et les validations restent claires.

Notre approche FoneClaw : ne pas tout recalculer à chaque fois

Chez FoneClaw, nous pensons que les actions Android prises en charge doivent être aussi déterminées que possible. Quand l’utilisateur demande une tâche fréquente, l’agent ne devrait pas redécouvrir toute la logique depuis zéro. Il doit reconnaître le type de demande, vérifier les permissions, préparer l’étape attendue et demander confirmation si l’action est sensible. Moins de devinette signifie moins de coût et plus de confiance.

Nous séparons donc ce qui doit être raisonné de ce qui doit être réalisé comme action encadrée. La formulation de l’utilisateur peut demander de l’interprétation : « réponds poliment », « ouvre le bon réglage », « résume ce qui compte ». Mais une fois l’action identifiée, l’agent doit suivre un chemin stable quand il existe. Cela évite de faire appel au modèle pour résoudre encore et encore la même étape d’interface.

Nous ne prétendons pas que FoneClaw élimine le coût cloud dans tous les cas. Certaines demandes méritent un raisonnement plus large. Certaines apps ne sont pas prises en charge. Certaines permissions manquent. Certaines actions doivent être refusées ou reportées. Notre promesse doit rester concrète : réduire les boucles inutiles sur les actions compatibles, pas vendre une automatisation universelle.

Cette approche a aussi une valeur pour l’utilisateur final. Un agent qui recommence trois fois coûte plus cher au fournisseur, mais il coûte aussi du temps à la personne qui attend. Un agent qui montre ce qu’il fait, demande la bonne permission et conclut proprement réduit le support, les corrections et la frustration. Le coût total d’un agent inclut toujours l’expérience humaine.

Checklist pour estimer le coût total d’un agent

Pour évaluer le coût réel, commencez par le nombre de tours nécessaires. Une tâche peut sembler simple sur la facture d’un seul appel modèle, mais devenir chère si elle exige trois reformulations, deux captures, une correction utilisateur et une validation confuse. Mesurez le coût par tâche terminée, pas seulement le coût par message.

Ensuite, regardez la distance entre raisonnement et action. Si l’agent sait quoi faire mais ne peut pas le faire dans le téléphone, il va souvent produire des instructions plutôt qu’un résultat. Si une action locale prise en charge existe, la tâche peut être plus directe. La question à poser est : combien de fois le modèle doit-il re-décrire l’état avant que quelque chose change réellement ?

Ajoutez le temps humain. L’utilisateur qui vérifie, corrige, relance, ouvre l’app manuellement ou contacte le support crée un coût caché. Pour un produit, ce coût apparaît dans la rétention, le support, la confiance et l’usage répété. Un agent peu cher par token peut devenir cher s’il échoue souvent.

Enfin, vérifiez les limites de sécurité. Un agent qui réduit les coûts en supprimant les confirmations n’est pas réellement économique. Il déplace le coût vers le risque. La bonne optimisation garde les validations importantes, réduit les étapes inutiles et évite de renvoyer le même contexte au modèle sans raison. Pour FoneClaw, c’est le cœur du compromis : dépenser moins quand l’action est connue, mais ne jamais acheter, envoyer, modifier ou supprimer sans contrôle clair.