Feuille de route de FoneClaw OS : notre chemin vers le téléphone IA agentique

De l’agent Android actuel à la destination FoneClaw Agent OS

La feuille de route de FoneClaw OS commence par ce que nous livrons déjà : FoneClaw est déjà un agent téléphonique Android conçu pour réduire la distance entre une intention et une action mobile gouvernée. L’utilisateur formule une demande, un modèle configuré raisonne sur la tâche, puis des outils FoneClaw exécutent les actions Android prises en charge avec état visible, permissions, approbations, arrêt et récupération. Cette base Android est le terrain où nous apprenons chaque jour comment un agent doit vivre dans un téléphone réel.

Notre destination est claire : construire un FoneClaw Agent OS basé sur AOSP et, à terme, un téléphone FoneClaw pensé autour de l’agent personnel. Dans cette vision, l’agent sur l’appareil porte l’identité active de l’utilisateur, ses préférences, sa mémoire utile et le contexte transversal entre services. Le téléphone devient un environnement d’intention : l’utilisateur demande un résultat, l’agent compose les capacités disponibles, les permissions restent visibles, les actions importantes attendent une décision et le résultat peut être relu.

La base actuelle de FoneClaw pose cette continuité de manière tangible. L’assistant flottant avec bulle déplaçable et panneau compact donne un point d’entrée plus naturel au-dessus des tâches Android. L’attachement de l’écran actuel en un geste apporte du contexte à la demande, en excluant les surcouches FoneClaw pour garder la lecture propre. La continuité entre Home et l’assistant flottant permet de suivre une tâche depuis plusieurs points d’entrée sur le même téléphone. Les approbations, l’arrêt et la récupération de permissions circulent avec la tâche, au lieu de rester coincés dans un écran unique. La page Télécharger FoneClaw présente ce point de départ public.

Nous construisons donc la destination à partir du comportement, puis de l’intégration. Un téléphone agentique crédible doit savoir invoquer l’agent au bon moment, comprendre le contexte visible, maintenir l’état, appliquer les permissions, composer des services, s’interrompre proprement et montrer ce qui a été fait. Le futur FoneClaw Agent OS reprend ces mêmes exigences au niveau système. Pour le vocabulaire général de cette catégorie, Téléphone IA agentique : définition, signaux 2026 et rôle de FoneClaw donne le cadre de lecture, tandis que cette page fixe notre position de produit et de marque.

Pourquoi le modèle centré sur les applications freine les agents

Le smartphone moderne a été construit autour de l’application : une icône, un écran, une navigation, un compte, des réglages, puis une autre application pour la suite de la tâche. Ce modèle a créé un écosystème très riche, et ces services gardent une valeur évidente. La friction apparaît lorsque l’utilisateur devient l’orchestrateur permanent. Pour organiser une réunion, il lit un message, vérifie un calendrier, ouvre une carte, consulte un fichier, prépare une réponse et confirme un rappel. La tâche est unique dans son esprit, mais le téléphone la découpe en fragments.

Un agent personnel change l’unité de travail. Il part de l’intention, puis cherche les capacités qui permettent de produire un résultat. L’écran reste un pont utile avec l’existant : FoneClaw peut travailler avec un état visible, un panneau compact, une action prise en charge ou un résultat à confirmer. Cette compatibilité est précieuse dans l’Android actuel. Elle révèle aussi la direction suivante : les services gagneront à exposer des fonctions structurées, avec entrées, sorties, permissions et erreurs compréhensibles par un agent.

Les Android AppFunctions illustrent ce mouvement de plateforme. Elles montrent comment des applications peuvent déclarer des fonctions découvrables par des assistants autorisés. Pour nous, ce type d’évolution confirme une intuition produit : l’avenir du téléphone agentique combine compatibilité avec les applications existantes et contrats plus directs entre services et agents. L’utilisateur garde les applications qu’il connaît, tandis que l’agent peut progressivement coordonner des capacités plus propres que des gestes d’écran.

FoneClaw place cette coordination au cœur de l’expérience. L’agent reçoit la demande, identifie les services utiles, vérifie les permissions, prépare l’action, attend l’approbation quand l’effet le demande et affiche le résultat. La page Fondation d’un agent de système d’exploitation : les trois couches qu’un agent IA de téléphone doit maîtriser détaille ce modèle de contexte, d’action et de gouvernance ; ici, nous l’appliquons à notre chemin vers FoneClaw Agent OS.

Voix d’abord, boutons physiques ensuite, écran en troisième

Le futur téléphone FoneClaw suit une hiérarchie d’interaction précise : voix d’abord, boutons physiques ensuite, écran en troisième. La voix est le mode naturel pour exprimer une intention complète. Une phrase comme « prépare une réponse à Claire, ajoute un rappel demain matin et montre-moi avant validation » contient déjà le but, la cible, le moment et l’exigence de contrôle. Elle évite à l’utilisateur de traverser plusieurs menus pour assembler une tâche simple.

Les boutons physiques ajoutent la fiabilité. Ils peuvent invoquer l’agent, confirmer une étape préparée, arrêter une action en cours, rouvrir un état de tâche ou revenir au contrôle manuel. Dans un environnement bruyant, en mobilité, dans une réunion ou pour une action sensible, un bouton dédié donne une certitude que la voix seule ne fournit pas toujours. Le bouton devient un geste de confiance : je lance, je confirme, je stoppe, je reprends.

L’écran garde un rôle essentiel : il montre les choix, les preuves, les destinataires, les fichiers, les changements de réglages, les données transmises et l’historique d’exécution. Dans cette hiérarchie, l’écran sert moins à chercher l’endroit où agir qu’à vérifier la qualité de l’action proposée. Avant un message, il affiche le texte et le contact. Avant une modification, il expose la cible. Avant une opération destructive, il rend l’effet lisible. L’écran devient la surface de jugement.

Cette organisation reflète notre expérience actuelle de FoneClaw. L’assistant flottant rapproche l’invocation de l’écran courant, la voix réduit l’effort de saisie, les approbations gardent le contrôle et l’arrêt partagé protège l’utilisateur pendant une tâche. Pour approfondir cette logique d’interaction, Téléphone IA centré sur la voix : pourquoi la prochaine interface du mobile ne sera pas seulement un écran plus intelligent explique comment une interface mobile devient plus agentique quand elle donne la priorité à l’intention.

AOSP comme fondation et pile FoneClaw centrée sur l’agent

Nous choisissons AOSP comme fondation de long terme parce que l’Android Open Source Project fournit une base ouverte pour construire un système compatible avec les réalités d’un téléphone : matériel, sécurité, permissions, comptes, connectivité, affichage, notifications, applications et services système. AOSP apporte le socle. FoneClaw apporte le modèle d’exploitation agentique qui organise l’expérience autour de l’intention, du contexte et de l’action gouvernée.

La pile que nous construisons se comprend en plusieurs niveaux. À la base, le matériel et AOSP assurent les capacités fondamentales du téléphone. Au-dessus, l’agent core FoneClaw porte l’intention, l’état de tâche, la mémoire utile, les préférences et l’orchestration. Une couche de politique décide le niveau de permission, d’approbation, de trace et d’interruption nécessaire selon l’effet réel de l’action. Une couche d’exécution relie le raisonnement du modèle aux actions Android prises en charge. Les Agent Plugins exposent ensuite des capacités de service plus spécialisées, avec des entrées et sorties structurées.

Cette architecture permet de choisir la bonne route de calcul. Certaines tâches ont intérêt à rester sur l’appareil pour la vitesse, la confidentialité, la disponibilité ou la proximité du contexte personnel. D’autres utilisent des ressources en ligne lorsqu’un modèle, une recherche, une intégration externe ou un service distant apporte la capacité attendue. Le rôle de l’agent est de sélectionner cette route en fonction de la tâche, de la donnée, de la latence, de la permission et du résultat. L’utilisateur voit ce qui change au moment où l’effet devient important.

Les capacités actuellement disponibles de FoneClaw préparent déjà cette pile. Le modèle configuré raisonne, les outils gouvernés exécutent, Home et l’assistant flottant partagent l’état, les approbations suivent la tâche et la récupération de permissions ramène l’utilisateur vers l’action possible. À mesure que nous avançons vers FoneClaw Agent OS, ces mécanismes deviennent des responsabilités système plus profondes : contexte durable, invocation fiable, mémoire inspectable, politiques lisibles, plugins déclarés et résultats vérifiables.

D’un marché d’applications à un écosystème d’Agent Plugins

Un marché d’applications organise l’offre autour de l’installation, de l’icône et de la navigation. Un écosystème d’Agent Plugins organise l’offre autour de capacités de service que l’agent personnel peut composer. Dans notre vision, l’utilisateur demande un résultat : réserver, classer, vérifier, transformer, envoyer, télécharger, archiver, planifier, comparer. L’agent choisit ensuite les capacités autorisées qui correspondent à cette intention, avec le minimum de contexte nécessaire et un résultat observable.

Un Agent Plugin doit être lisible par le système et par l’utilisateur. Il déclare ce qu’il sait faire, les entrées qu’il accepte, les sorties qu’il produit, les permissions qu’il sollicite, les erreurs possibles, sa version, son origine et son comportement de récupération. Il peut offrir une capacité professionnelle spécialisée : gestion de fichiers, extraction de contenu, service métier, automatisation documentaire, connecteur de messagerie, opération média, gestion de tickets ou intégration d’entreprise. Le contrat compte autant que la capacité, car un agent utile doit savoir quand appeler un service, quoi lui transmettre, comment interpréter le résultat et comment revenir à l’utilisateur.

Le produit actuel pose les premières briques de cette direction. Le dépôt officiel FoneClaw Android documente les outils, Skills, Workflows, plugins, approbations et chemins de contribution. La page Fonctionnalités FoneClaw présente les capacités utilisateur actuelles, dont les 100+ outils intégrés, dans un cadre orienté tâches Android. Les plugins complètent le noyau lorsque la capacité relève d’un paquet séparé, d’un service spécialisé ou d’un contrat d’extension.

Nous concevons cet écosystème avec une logique de confiance active. Le plugin apporte une capacité déclarée. L’agent choisit cette capacité selon l’intention. L’utilisateur voit la demande, la permission et le résultat. Les actions à effet réel reçoivent une approbation proportionnée. L’échec fournit une raison et une reprise. Pour les lecteurs qui veulent approfondir ce modèle de compétences, de permissions et d’audit, Sécurité des compétences d’agents IA : pourquoi les permissions sur mobile doivent être vérifiées au moment de l’action explique comment l’extensibilité peut rester concrète et contrôlable sur mobile.

L’agent personnel devient le propriétaire du contexte transversal

Le cœur du FoneClaw Agent OS est l’agent personnel sur l’appareil. Il porte l’identité active, les préférences, la mémoire utile et le contexte transversal entre services. Aujourd’hui, une grande partie de ce contexte se fragmente entre applications : contacts importants, adresses, habitudes de déplacement, documents, conversations, réservations, tâches, factures, préférences de ton, horaires et projets. L’utilisateur garde souvent la cohérence dans sa tête. L’agent personnel doit rendre cette cohérence opérationnelle.

La propriété du contexte change la relation entre services. Un plugin ou un service reçoit les données nécessaires à l’action demandée : une adresse pour une livraison, une date pour une réservation, un fichier pour une conversion, un destinataire pour un message, un extrait de contexte pour une décision. Les enregistrements propres au service, comme une transaction, une facture, un reçu ou une obligation métier, restent associés au service concerné. Le profil transversal, lui, appartient à l’utilisateur via son agent personnel.

Cette approche donne une valeur particulière à l’appareil. Le téléphone devient le point où l’identité, les préférences et la mémoire peuvent être inspectées, modifiées, révoquées ou supprimées. L’utilisateur doit pouvoir comprendre pourquoi l’agent propose une action, quelle mémoire a été utilisée, quelle donnée part vers un service et quel résultat revient. Cette lisibilité transforme le contexte personnel en outil de contrôle plutôt qu’en matière cachée.

FoneClaw avance dans cette direction avec des états de tâche clairs, une continuité entre points d’entrée, des approbations liées à l’action et une récupération de permissions. Le futur Agent OS portera cette logique plus profondément : mémoire durable et inspectable, historique d’activité, suppression claire, règles par service et partage limité au besoin. Pour traiter cette dimension en détail, Agent IA avec contexte personnel : le guide téléphone développe la place du contexte personnel dans un téléphone agentique.

FoneClaw face aux approches IA OS et agents de constructeurs

Plusieurs acteurs explorent déjà des routes vers le téléphone agentique. Ces routes ont des points communs : déplacer l’expérience depuis la navigation d’applications vers l’expression d’intention, rapprocher modèles et services, intégrer des agents au système ou au matériel, attirer des développeurs vers de nouvelles capacités. Pour FoneClaw, cette comparaison sert à clarifier notre propre architecture : agent Android actuel, destination AOSP, voix d’abord, agent personnel sur l’appareil et Agent Plugins comme capacités de service.

Deux routes méritent une lecture dédiée pour les lecteurs qui suivent les appareils et assistants chinois : Doubao Agent Phone et Nubia NaviX Ultra : ce qui change couvre le cas Doubao, tandis que les pages StepFun, HONOR et Xiaomi citées dans le tableau gardent leurs contextes propres. Notre trajectoire FoneClaw se lit à travers une constante : partir des tâches réelles sur Android, améliorer l’invocation et le contexte, renforcer les permissions et la récupération, puis porter cette expérience au niveau système.

Comment FoneClaw avance déjà vers cette destination

Nous mesurons la feuille de route par les comportements livrés. La première étape est le runtime Android gouverné : comprendre une demande, choisir une action prise en charge, afficher l’état, demander la permission utile, obtenir l’approbation proportionnée, permettre l’arrêt et produire un résultat visible. Les capacités actuellement disponibles de FoneClaw renforcent cette étape avec l’assistant flottant, le panneau compact, l’attachement de l’écran actuel, la continuité entre Home et l’assistant flottant, l’arrêt partagé, la récupération de permissions et les actions rapides. Pour voir comment une intention devient action vérifiable dans le produit actuel, Contrôle du téléphone par agent IA : ce qu’un agent Android doit vraiment faire complète cette feuille de route avec des cas pratiques.

La deuxième étape approfondit l’intégration système. Le futur FoneClaw Agent OS donnera davantage de durabilité à l’état de tâche, rapprochera préférences et mémoire de l’appareil, rendra les permissions plus contextuelles et reliera naturellement voix, boutons et écran. L’utilisateur parlera pour demander, pressera pour invoquer, confirmer ou arrêter, puis consultera l’écran pour inspecter une preuve ou reprendre une action. Cette interaction doit réduire les détours sans perdre la qualité du jugement humain au moment important.

La troisième étape développe la plateforme d’Agent Plugins. Les plugins deviennent des contrats de service : capacité déclarée, origine vérifiable, permissions lisibles, données limitées, sortie structurée, erreurs explicables, récupération prévue. Les applications compatibles, les services en ligne, les capacités locales et les workflows professionnels peuvent alors coexister autour de l’agent personnel. Le téléphone cesse d’être seulement un lieu de navigation ; il devient un lieu de composition contrôlée.

La quatrième étape porte cette architecture dans un futur téléphone FoneClaw avec FoneClaw Agent OS. Ce téléphone est notre destination produit : un appareil où l’agent personnel est l’interface principale, où la voix exprime l’intention, où les boutons physiques donnent la fiabilité de l’invocation et de l’arrêt, où l’écran sert à vérifier, et où les plugins de service étendent les capacités dans un cadre signé, limité et observable.

Les critères de progrès restent simples et mesurables. La tâche aboutit-elle à un résultat utile ? La permission arrive-t-elle au moment pertinent ? L’utilisateur peut-il interrompre ? La récupération indique-t-elle une reprise claire ? Les données transmises au service restent-elles limitées à l’action ? Les plugins sont-ils déclarés, fiables et vérifiables ? Le résultat laisse-t-il une trace compréhensible ? Chaque version de FoneClaw avance sur ces points : invocation, contexte, permissions, contrats de plugins, récupération et intégration système. C’est ainsi que nous passons de l’agent Android actuel au FoneClaw Agent OS.