Panne de modèle d’assistant IA sur Android : diagnostiquer et reprendre sans doublon

Quand un assistant IA Android se bloque au milieu d’une tâche, la tentation naturelle consiste à appuyer sur Réessayer. Nous avons appris en construisant FoneClaw que ce réflexe devient risqué dès que l’assistant agit sur le téléphone : un message peut être envoyé deux fois, un réglage peut être appliqué à nouveau, ou une tâche peut reprendre avec un mauvais contexte. La bonne méthode consiste à séparer deux réalités : l’état de la réponse du modèle et l’état réel de l’action Android.

Ce guide explique comment diagnostiquer une panne de modèle d’assistant IA sur Android, conserver l’état vérifié du téléphone, limiter les réessais, choisir un modèle de secours IA Android quand il est compatible, puis reprendre sans dupliquer les effets. C’est aussi la logique que nous intégrons dans FoneClaw : rendre la progression lisible, garder les actions gouvernées par les permissions et aider l’utilisateur à décider quand il faut continuer, attendre ou changer de modèle.

Identifier le type de panne avant d’agir

Une panne de modèle d’assistant IA sur Android ne signifie pas toujours que le fournisseur est indisponible. Le même message, par exemple une réponse vide ou un délai dépassé, peut venir d’une connexion mobile instable, d’une clé API expirée, d’un quota atteint, d’une surcharge temporaire, d’un modèle retiré ou d’un blocage local pendant l’exécution Android. Avant tout réessai, nous regardons les symptômes observables : l’assistant reçoit-il encore les messages, le téléphone a-t-il exécuté une action, la page d’état du fournisseur signale-t-elle une perturbation, et l’erreur ressemble-t-elle à une authentification, une limitation de débit ou une erreur serveur ?

Les fournisseurs sérieux documentent plusieurs familles d’échec. La documentation des erreurs Claude API distingue notamment authentification, limite de débit, erreur interne, délai dépassé et surcharge. Les pages d’état d’OpenAI montrent aussi que des erreurs et de la latence peuvent provenir d’un incident temporaire, comme dans un compte rendu d’incident OpenAI sur la latence et les erreurs élevées. Ces sources ne remplacent pas l’observation locale : elles aident à éviter un mauvais diagnostic.

Dans FoneClaw, nous traitons le modèle comme le moteur de raisonnement, pas comme la preuve que le téléphone a terminé. Si l’écran Android indique qu’un contact a été créé, qu’un SMS est resté en brouillon ou qu’un réglage n’a pas changé, cette information prime sur le texte du modèle. Pour les pannes qui dépassent la couche modèle, notre guide Diagnostiquer et récupérer un agent IA mobile : runbook Android pour échecs, permissions et relance d’outil aide à élargir le diagnostic aux permissions, aux outils et à l’état de l’application.

Préserver l’état de la tâche avant tout réessai

La reprise sûre commence par un inventaire simple : qu’est-ce qui est confirmé, qu’est-ce qui était seulement prévu, et quelle action aurait un effet réel si elle était relancée ? Nous recommandons de noter le dernier état vérifié du téléphone avant de toucher au bouton de réessai. Sur Android, cet état peut être un écran visible, une notification, une fiche contact, un brouillon de message, un événement de calendrier, un réglage système ou une autorisation demandée. Une phrase du type « envoi terminé » dans la conversation ne suffit pas si l’application cible ne le confirme pas.

Nous construisons FoneClaw autour de cette séparation parce que les agents mobiles ne manipulent pas seulement du texte. Ils lisent l’écran, demandent des validations, exécutent des outils et reviennent avec des résultats. Quand une réponse LLM échoue après une action Android, le téléphone peut déjà avoir changé. À l’inverse, le modèle peut produire une réponse correcte alors que l’action locale n’a jamais abouti. Préserver l’état veut donc dire garder trois éléments : la demande d’origine, la dernière étape confirmée et la prochaine étape qui n’a pas encore été prouvée.

Si une action est conséquente, arrêtez-vous dès que son statut devient incertain. Envoyer un SMS, créer un contact, modifier un événement ou changer un réglage système demande une vérification visuelle ou un retour d’outil avant toute relance. Réessayer une requête IA sans risque consiste souvent à reformuler : « Reprends à partir de l’état actuel, vérifie d’abord si l’action a déjà été faite, puis demande confirmation avant tout effet supplémentaire. » Cette phrase protège mieux qu’un renvoi complet de la commande initiale.

Réessayer sans créer une boucle de surcharge

Les pannes transitoires existent. Un délai dépassé, une réponse 5xx ou une surcharge temporaire peut disparaître après quelques secondes. Mais le bon réessai reste borné. Notre règle pratique pour un assistant Android est simple : un premier réessai court si l’état du téléphone est stable, puis un délai plus long si l’erreur ressemble à une surcharge serveur, puis un arrêt net après un petit nombre de tentatives. À ce stade, il vaut mieux inspecter la page d’état, les quotas et la configuration que continuer à pousser la même requête.

Cette discipline évite la tempête de réessais. Un compte rendu OpenAI sur une perturbation de ChatGPT et de la plateforme décrit comment l’augmentation du trafic de réessai peut amplifier la charge en aval. De son côté, Anthropic recommande un backoff exponentiel pour les erreurs serveur réessayables dans sa documentation API. En clair : attendre davantage entre les tentatives protège votre tâche et réduit la pression sur le service déjà ralenti.

Un code 429 mérite une lecture plus fine. Il peut signaler une limite de débit momentanée, mais aussi une limite de dépenses, de plan ou d’accès qui ne disparaîtra pas avec dix clics. Dans FoneClaw, nous voulons que la reprise après panne LLM mobile reste lisible : l’utilisateur doit voir que la réponse est en échec, que l’action Android garde son état, et que la prochaine tentative ne rejoue pas aveuglément les gestes déjà effectués. Réessayer devient alors une décision, pas une boucle.

Changer de modèle seulement après vérification

Changer de modèle sans répéter les actions commence par une idée centrale : le modèle de secours remplace le service de raisonnement, pas l’état du téléphone. Si l’assistant avait ouvert une application, rempli un champ ou préparé un message avant l’erreur, ce travail local ne disparaît pas parce que vous choisissez un autre modèle. La reprise doit donc transporter le contexte utile, déclarer ce qui est déjà confirmé et demander au nouveau modèle de continuer depuis l’écran actuel.

La compatibilité compte. Tous les modèles n’acceptent pas les mêmes formats d’entrée, la même taille de contexte, les mêmes images, les mêmes paramètres ou les mêmes conventions d’appel d’outils. Un modèle plus rapide peut être très bon pour reformuler une étape, mais moins adapté à une tâche multimodale qui dépend d’une capture d’écran. Un modèle plus robuste peut mieux gérer une longue conversation, mais demander une configuration différente. Pour choisir calmement entre Kimi, DeepSeek, GLM ou d’autres options, nous renvoyons les lecteurs vers Routage de modèles pour agent mobile : choisir Kimi, DeepSeek, GLM ou un autre modèle, qui se concentre sur les critères de sélection.

Dans FoneClaw, le choix reste gouverné par l’utilisateur. Nous fournissons un chemin de modèle par défaut et la possibilité de configurer des modèles compatibles, puis nous gardons la reprise attachée à l’état vérifié de la tâche. Une bonne demande au nouveau modèle ressemble à ceci : « Le contact existe déjà, le message n’est pas envoyé, l’écran actuel montre le brouillon ; vérifie le destinataire et demande mon accord avant l’envoi. » Cette formulation évite le piège du grand recommencement.

Reprendre au premier point non confirmé

La reprise après panne LLM mobile doit repartir du premier point non confirmé, pas du début narratif de la conversation. Si l’assistant devait ouvrir Gmail, chercher un message, résumer son contenu et créer un mémo, chaque étape possède un statut différent. Ouvrir l’application et trouver le message sont des lectures ou navigations relativement sûres. Créer le mémo est une écriture. Modifier, envoyer, supprimer ou publier ajoute encore plus de conséquence. La reprise correcte lit d’abord l’état actuel, puis agit seulement sur l’étape suivante.

Nous utilisons souvent une règle de frontière : lire avant d’écrire, vérifier avant de confirmer, demander un nouvel accord si la cible ou l’effet a changé. Si un message avait été préparé pour Camille et que l’écran montre maintenant un autre destinataire, l’ancienne approbation ne couvre plus la nouvelle action. Si un événement de calendrier existe déjà, il faut l’ouvrir ou le rechercher avant d’en créer un autre. Si un réglage système affiche déjà l’état voulu, la tâche peut se terminer par une vérification plutôt que par une nouvelle action.

Cette logique évite de confondre fluidité du texte et réussite réelle. Un modèle peut redevenir disponible et produire une explication convaincante alors que l’action Android est restée incomplète. L’inverse arrive aussi : l’action a réussi, mais la réponse finale s’est perdue. Dans FoneClaw, nous continuons à renforcer les résultats visibles, les contrôles de progression et les vérifications d’écran pour que la reprise se fasse à partir de preuves locales, pas d’une supposition.

Traiter quotas, clés expirées et modèles retirés comme des réglages

Toutes les erreurs ne méritent pas un réessai. Une authentification refusée demande une clé valide, une session reconnectée ou une configuration corrigée. Une limite de débit peut demander d’attendre, tandis qu’une limite de plan ou de dépenses demande souvent une action sur le compte fournisseur. Un délai dépassé peut être transitoire, mais il peut aussi révéler une requête trop lourde pour le modèle choisi. Un modèle retiré appelle une migration. La documentation Anthropic sur le cycle de vie des modèles illustre ce point : quand un modèle n’accepte plus les requêtes, le remède consiste à sélectionner un remplaçant indiqué par le fournisseur, pas à répéter l’ancien appel.

Dans FoneClaw, nous avons appris que la configuration de modèle doit être accessible sans pousser les utilisateurs vers des manipulations fragiles. Si vous utilisez votre propre fournisseur, gardez les clés dans les écrans prévus, ne les copiez pas dans une conversation et vérifiez le nom exact du modèle, le point d’entrée API, le format attendu et les limites de votre plan. Pour la mise en place initiale, notre guide Connecter une API de modèle IA à un agent Android avec FoneClaw détaille la logique de connexion d’un modèle compatible à un agent Android.

Une bonne correction durable réduit le nombre d’échecs futurs : remplacer un modèle retiré, alléger les pièces jointes, raccourcir une requête trop longue, choisir un modèle qui accepte les images quand la tâche dépend de l’écran, ou ajuster les quotas. Une fois le réglage corrigé, reprenez depuis l’état actuel du téléphone. Le fait d’avoir réparé la configuration ne donne pas automatiquement le droit de rejouer une action déjà partiellement exécutée.

Utiliser FoneClaw pour reprendre sans doubler les actions

Dans FoneClaw, nous avons conçu la reprise autour de la visibilité. L’utilisateur peut suivre les tâches déléguées plus clairement, relire les réponses longues, utiliser le réessai quand il est sûr, et envoyer un retour avec le contexte pertinent pour nous aider à comprendre l’échec. Cette approche vient d’un apprentissage très concret : sur Android, un assistant utile doit montrer où il en est, car une panne de modèle et une action de téléphone incomplète n’ont pas la même conséquence.

Le chemin recommandé est volontairement simple. D’abord, regardez la dernière réponse et l’état d’action visible. Ensuite, vérifiez l’écran ou le résultat d’outil correspondant : message envoyé ou brouillon, contact créé ou formulaire encore ouvert, réglage appliqué ou inchangé. Si l’erreur ressemble à une panne temporaire, utilisez un réessai borné. Si elle pointe vers un modèle incompatible, un quota ou un modèle retiré, changez la configuration avant de reprendre. Pour les situations où l’agent semble aller dans une direction risquée, notre guide Arrêter un agent IA sur Android : confinement, permissions et récupération explique comment interrompre et reprendre proprement.

FoneClaw fournit un chemin de modèle par défaut et prend en charge la configuration de modèles compatibles. Les modèles IA personnalisés disposent désormais d’une section dédiée avec édition directe, afin que vous puissiez ajuster un fournisseur, un nom de modèle ou un point d’entrée sans transformer la reprise en bricolage. Le choix du modèle reste entre vos mains : FoneClaw ne suppose pas qu’un autre fournisseur peut reproduire exactement le même raisonnement, les mêmes entrées ou les mêmes limites.

Pour vérifier l’étendue actuelle des capacités, la page Fonctionnalités FoneClaw présente les usages Android couverts, y compris les 100+ built-in tools, la progression visible et les actions gouvernées. Pour installer la version actuelle, passez par la page Télécharger FoneClaw. Notre direction produit reste la même : rendre la reprise plus explicite, garder les actions sensibles sous contrôle utilisateur et aider chaque tâche à continuer depuis le premier point réellement non confirmé.