PokeClaw vs FoneClaw : agent local ou exécution Android gouvernée

Choisir selon le bon usage

PokeClaw vs FoneClaw n’est pas un duel avec un vainqueur unique. Le choix dépend de ce que vous voulez apprendre ou accomplir. PokeClaw convient d’abord aux personnes qui veulent explorer un agent Android open source, local-first, avec un modèle qui peut tourner sur le téléphone. FoneClaw convient aux utilisateurs Android qui veulent transformer une intention en action prise en charge, avec permission, approbation, état visible, arrêt et récupération.

La distinction la plus importante tient dans le mot local. Un agent IA local sur téléphone peut vouloir dire que l’inférence du modèle se fait sur l’appareil. Cela intéresse la confidentialité, la latence, les coûts d’API et l’indépendance réseau après configuration. Mais local peut aussi vouloir dire que l’action se déroule depuis le téléphone : lire l’écran, ouvrir une app, préparer un brouillon, modifier un réglage ou vérifier un état. Ces deux propriétés se croisent parfois, mais elles ne sont pas équivalentes.

D’après le dépôt officiel PokeClaw, PokeClaw est un prototype Android open source orienté local-first. Il lit une représentation textuelle de l’interface, choisit des outils et peut utiliser un modèle local ou des fournisseurs cloud optionnels. D’après les pages publiques de FoneClaw, notre travail se place sur une autre priorité : rendre l’exécution Android gouvernée plus pratique et plus contrôlable pour l’utilisateur.

Si vous voulez inspecter le code, comprendre une boucle agentique locale et expérimenter avec un modèle embarqué, commencez par PokeClaw. Si votre question est “comment mon téléphone agit-il avec un résultat visible et une reprise claire ?”, commencez par FoneClaw.

Comparer le modèle et le chemin des données

Le premier critère sérieux est le chemin des données. PokeClaw met en avant un mode local où Gemma 4 tourne sur le téléphone via LiteRT-LM. La page officielle indique qu’après configuration, ce mode local fonctionne sans compte ni clé API. C’est un signal fort pour les développeurs et les utilisateurs avancés qui veulent tester une boucle d’agent avec inférence embarquée plutôt que dépendre d’un appel distant à chaque étape.

Cette architecture ne signifie pas que chaque configuration PokeClaw reste locale. Le même projet documente aussi des fournisseurs cloud optionnels. Dès qu’un fournisseur cloud est activé, le chemin des données change : il faut regarder quelles entrées sont envoyées, quel modèle traite la demande, quelles clés sont utilisées et quelles règles de conservation s’appliquent. Un produit local-first peut donc avoir plusieurs modes, et le test doit vérifier le mode réellement sélectionné.

Côté FoneClaw, nous ne présentons pas le produit comme une inférence entièrement sur appareil. Notre promesse utile dans ce comparatif est l’exécution Android gouvernée : entrée flottante, contexte d’écran volontaire, continuité de tâche, approbations, arrêt, récupération et routage des capacités. Les informations actuelles pour l’utilisateur sont accessibles depuis la page de téléchargement FoneClaw, tandis que la surface de fonctions se consulte sur les fonctionnalités de FoneClaw.

Pour approfondir la confiance entre local et cloud, notre guide Confiance dans un agent IA : contrôle local Android ou sécurité cloud ? sépare les enjeux de calcul, de données, d’autorisations et de preuve utilisateur.

Comparer l’observation et l’action

Un agent embarqué devient intéressant quand il observe l’état du téléphone puis choisit une action. PokeClaw documente une boucle où l’agent lit une représentation textuelle de l’interface actuelle et sélectionne des outils. Cette approche donne un terrain clair aux builders : l’agent ne se contente pas de générer une réponse, il regarde une forme structurée de l’écran, planifie une étape et appelle une action disponible.

Les outils officiellement documentés côté PokeClaw couvrent des fonctions comme le toucher, la saisie de texte, l’ouverture d’app, la lecture d’écran, les captures, la messagerie, l’auto-réponse et la fin de tâche. C’est utile pour expérimenter la navigation dans des apps et comprendre comment un agent Android peut relier état visible, instruction et geste. La limite pratique doit rester dans le test : lire une interface et agir avec des outils génériques ne prouve pas une compatibilité parfaite avec chaque app, chaque langue ou chaque écran.

Chez FoneClaw, nous abordons la boucle depuis le contrôle utilisateur. L’utilisateur peut lancer FoneClaw depuis un accès flottant, attacher l’écran actuel quand il veut donner ce contexte, puis demander une action prise en charge. Le routage des capacités aide à diriger la demande vers le bon type d’action disponible, sans transformer toute intention en exécution automatique. Les outils intégrés couvrent des catégories Android concrètes, mais la valeur réelle vient du cadre : permission, approbation, état vérifié, arrêt et récupération.

Pour les lecteurs qui veulent comprendre précisément l’entrée flottante et le contexte volontaire, Assistant IA flottant Android : comprendre et agir depuis l’écran actuel explique le chemin produit que nous avons construit. Le point clé du comparatif est simple : PokeClaw rend très visible la boucle expérimentale modèle-interface-outil ; FoneClaw rend centrale la boucle intention-contrôle-action-récupération.

Comparer permissions, approbations, arrêt et récupération

Le contrôle des actions ne se résume pas au fait qu’un projet soit open source, local ou cloud. PokeClaw demande l’accessibilité Android pour lire l’écran et effectuer des gestes. Cette permission est puissante : elle rend possible l’observation et l’action dans l’interface, mais elle exige aussi une attention particulière. Avant de tester un agent Android PokeClaw, il faut comprendre ce que la permission autorise, sur quelles apps le test porte et comment l’agent se comporte quand l’écran ne correspond pas à ce qu’il attend.

La documentation PokeClaw parle aussi de règles, de gardes, de détection de blocage et d’échecs propres. Ces éléments comptent plus qu’une démonstration spectaculaire. Un agent sûr doit savoir reconnaître qu’il ne peut pas continuer, signaler l’état, éviter de répéter une action risquée et terminer proprement. Pour une auto-réponse ou une action de messagerie, le test doit observer si le contenu reste lisible, si le destinataire est correct et si l’utilisateur garde une étape de contrôle adaptée au risque.

Chez FoneClaw, nous avons appris que la sécurité perçue vient de la clarté du flux. Une permission donne un droit technique ; une approbation donne un accord dans le contexte actuel. Nous construisons donc autour d’un état visible, d’approbations pour les actions qui le demandent, d’un arrêt possible, de vérifications après action et d’une récupération guidée quand une permission ou un état manque. Cette discipline sert autant les réglages système que les messages, les brouillons, les captures ou les changements d’app.

Si vous cherchez une alternative à PocketClaw ou à tout autre agent Android expérimental, évitez de juger seulement par promesse d’autonomie. Demandez plutôt : que se passe-t-il quand l’agent se trompe ? Peut-on arrêter ? Le résultat final est-il relu ? Une permission manquante mène-t-elle vers un chemin compréhensible ? Pour aller plus loin sur l’architecture FoneClaw des outils, Plugins, Skills et Workflows, Outils, Plugins, Skills et Workflows FoneClaw : choisir la bonne couche détaille les frontières entre capacités et exécution.

Comparer installation, matériel et coût réel

Le matériel change fortement l’expérience d’un agent IA local. La page officielle PokeClaw indique un téléchargement APK direct et Android 9+ arm64. Elle précise aussi qu’un premier lancement en mode local télécharge environ 2,6 Go et demande environ 4 Go de RAM libre. Ces chiffres rendent le choix concret : l’inférence locale donne plus de contrôle sur le chemin du modèle, mais elle consomme stockage, mémoire et temps de démarrage.

La même page indique qu’un échauffement CPU peut prendre environ 45 secondes, tandis que du matériel accéléré pris en charge peut réduire ce délai. Ces exemples ne garantissent pas la vitesse de votre appareil. Ils montrent surtout où regarder : processeur, mémoire libre, stockage, température, batterie, version Android, moteur d’inférence et taille du modèle. Un téléphone ancien peut réussir une démonstration courte et devenir frustrant dans une tâche répétée. Un téléphone plus puissant peut réduire l’attente sans supprimer les limites d’interface ou de permissions.

FoneClaw pose d’autres questions d’installation. Le point d’entrée à vérifier est la disponibilité actuelle, les permissions nécessaires, les catégories d’actions prises en charge et la qualité du flux sur votre téléphone. Notre approche ne demande pas au lecteur de juger FoneClaw comme un moteur local d’inférence ; elle demande de tester l’exécution Android gouvernée dans les conditions réelles de l’appareil.

Pour les lecteurs qui veulent comprendre les compromis de performance des LLM embarqués, Optimisation LLM embarquée pour agents mobiles Android approfondit mémoire, latence, accélération et expérience utilisateur.

Relier chaque produit aux bons workflows

Un tableau de fonctions ne suffit pas. La bonne comparaison part du workflow. PokeClaw est bien adapté aux expériences où l’on veut inspecter le code, observer une boucle locale, modifier des outils, comprendre les limites d’un prototype et tester des scénarios comme la navigation d’app ou l’auto-réponse WhatsApp documentée. Son dépôt indique une licence Apache 2.0 et décrit aussi des limites de marque ; le statut de marque ne change pas l’intérêt technique du code pour l’expérimentation.

FoneClaw sert un autre besoin : prendre une intention Android et la faire passer par un chemin gouverné. D’après les informations produit disponibles au moment de cette mise à jour, les capacités actuelles couvrent accès flottant, contexte d’écran volontaire, continuité de tâche, approbations, arrêt, récupération des permissions, vérification d’état, routage des capacités et plus de 100 outils intégrés. Pour nous, cette surface n’a de valeur que si elle reste testable par l’utilisateur : action visible, contexte compréhensible, confirmation quand il le faut, reprise en cas de blocage.

Le test exact prime toujours sur la fiche produit. Essayez le même scénario sur le même téléphone, avec les mêmes permissions et la même app cible. Notez la latence, les demandes de permission, les actions proposées, les confirmations, les erreurs et le résultat final. C’est ainsi que l’on évite de confondre promesse locale, prototype open source et produit d’exécution gouvernée.

Choisir puis lancer un test réversible

Choisissez PokeClaw en premier si votre priorité est l’apprentissage technique : modèle local, boucle d’outils, accessibilité Android, code ouvert et adaptation expérimentale. Choisissez FoneClaw en premier si votre priorité est l’action Android prise en charge avec contrôle utilisateur : ouvrir une app, lire un état visible, préparer un brouillon, vérifier un réglage ou reprendre une tâche interrompue.

Le premier test doit être réversible. Évitez l’envoi réel d’un message, l’achat, la suppression, le changement de compte ou toute action difficile à annuler. Utilisez plutôt ce protocole en cinq étapes.

1. Choisissez une tâche simple : ouvrir une app, lire un état visible ou préparer un brouillon non envoyé.
2. Notez les permissions demandées avant de lancer l’action.
3. Observez la latence, l’écran lu, l’action proposée et l’étape de confirmation.
4. Arrêtez ou interrompez la tâche une fois, puis vérifiez si la reprise est claire.
5. Contrôlez l’état final : rien de sensible ne doit partir sans validation explicite.

Consultez les pages officielles de chaque projet avant d’élargir les permissions ou les workflows. Une seule réussite ne prouve pas la fiabilité. Un bon choix tient dans la répétition : même appareil, mêmes conditions, résultat visible, arrêt clair et récupération compréhensible. C’est là que PokeClaw et FoneClaw deviennent comparables sans réduire l’un à l’autre.