Feuille de route de FoneClaw OS : agent Android, Meydo C1 et futur téléphone IA

Ce que FoneClaw est aujourd’hui

La Feuille de route de FoneClaw OS : notre chemin vers le téléphone IA agentique commence par le produit que nous livrons déjà. Aujourd’hui, FoneClaw est un agent téléphonique Android. L’utilisateur formule une intention, un modèle configuré aide à comprendre et planifier, puis FoneClaw route la tâche vers des outils Android pris en charge. Les étapes sensibles restent visibles : permission utile, approbation, progression, arrêt, retry, récupération et vérification du résultat.

Cette base actuelle rassemble l’assistant flottant, le contexte d’écran à la demande, la continuité des tâches, les approbations, l’arrêt et la récupération de permissions. Les informations produit les plus récentes ajoutent aussi une meilleure organisation de l’Information Inbox, des workflows Memo plus pratiques, des améliorations d’interface et un travail de fiabilité autour des interactions longues. Nous décrivons ces éléments comme capacités utilisateur, sans les transformer en annonce de système d’exploitation livré.

Ce point de départ nous sert de laboratoire réel. Un agent téléphone ne réussit pas parce qu’il répond bien dans une bulle ; il réussit quand il peut porter une tâche dans Android sans perdre l’utilisateur. Une demande comme « prépare un rappel depuis cette notification » exige du contexte, une action prise en charge, une permission, un aperçu et un état final lisible. Notre page Contrôler un téléphone Android avec un agent IA : intention, confirmation et vérification détaille cette boucle actuelle entre modèle, outil et résultat.

La destination reste plus large : un FoneClaw Agent OS basé sur AOSP et un futur téléphone FoneClaw. Mais notre méthode est volontairement graduelle. Nous faisons d’abord fonctionner les comportements essentiels sur Android, puis nous portons les leçons vers une intégration plus profonde.

Le jalon Meydo C1 : matériel, DroiClaw et FoneClaw préinstallé

Le jalon actuel à ajouter à cette feuille de route est le Meydo C1. Son architecture doit être nommée précisément : Meydo C1 est le matériel, DroiClaw est le système principal, et FoneClaw est préinstallé comme application système. Cette formulation décrit un jalon de distribution et d’intégration. Elle garde séparés le téléphone, son système principal et notre application d’agent Android.

La page Meydo C1 présente un téléphone IA de poche en précommande, tandis que l’article officiel Meydo consacré à DroiClaw situe DroiClaw comme fondation système de la direction produit Meydo. Dans ce contexte, la place de FoneClaw est celle d’une application système préinstallée : l’utilisateur peut accéder plus directement à notre agent Android sur un appareil conçu autour d’usages IA compacts.

Ce jalon compte parce qu’il rapproche FoneClaw d’un environnement plus intégré, sans confondre intégration et propriété du système. Une application système peut réduire la friction de découverte, simplifier certains parcours de configuration et rendre l’expérience plus cohérente dès la prise en main. Les règles d’exécution restent néanmoins celles qu’un agent téléphone sérieux doit respecter : compte, connectivité, région, services disponibles, permissions Android, confirmation et portée des actions prises en charge.

Pour les lecteurs qui veulent les caractéristiques, le statut de précommande, le prix à vérifier et le détail d’architecture du C1, nous gardons cette analyse sur Meydo C1 : téléphone agent IA, DroiClaw et FoneClaw préinstallé. Ici, le C1 sert à clarifier une étape de notre chemin : FoneClaw se distribue aussi dans un format système préinstallé, pendant que FoneClaw Agent OS demeure notre direction de long terme.

Cette distinction rejoint la définition d’un téléphone agentique. Le guide Téléphone à IA agentique : définition, tests et rôle de FoneClaw aide à juger le C1, FoneClaw actuel et le futur OS avec les mêmes critères : contexte, action, approbation, preuve de résultat et récupération.

Ce qu’un déploiement comme application système nous apprend

Une préinstallation comme application système apporte une leçon importante : plus l’agent est proche du téléphone, plus la responsabilité produit augmente. L’utilisateur attend moins de configuration, un accès plus rapide et des workflows plus faciles à retrouver. En retour, nous devons rendre l’identité active, les permissions, les approbations, la récupération, le routage du modèle et la disponibilité des services plus lisibles.

Nous avons déjà vu cette règle dans FoneClaw sur Android. Lorsqu’un utilisateur lance une tâche depuis l’assistant flottant, attache l’écran actuel, demande une action de calendrier, consulte une notification ou crée un mémo, l’agent doit garder l’état de tâche cohérent. Le fait d’être plus intégré ne doit jamais rendre l’action plus obscure. Au contraire, la proximité système doit améliorer ce que l’utilisateur peut inspecter : quelle donnée est utilisée, quel outil est appelé, quelle permission manque, quel résultat a été produit.

Les sujets d’identité et de traçabilité deviennent centraux. Un agent personnel doit savoir quel compte agit, quelle source a fourni le contexte, quel service reçoit une donnée, et quelle décision revient à l’utilisateur. Pour approfondir cette discipline, notre guide Identité, permissions et traces d’audit pour agents IA sur téléphone explique pourquoi l’action mobile demande une preuve compréhensible, pas seulement une réponse générée.

La préinstallation aide à réduire la friction, mais elle ne remplace pas les limites utiles. Les permissions Android, l’isolation des capacités, les confirmations proportionnées et les reprises après blocage restent des fondations de confiance. Pour éviter de mélanger intégration système et autorité illimitée, Sandbox d’agent IA et permissions du téléphone : pourquoi les limites restent essentielles détaille comment un agent peut agir tout en gardant des frontières lisibles.

Ces apprentissages alimentent directement notre feuille de route. FoneClaw Agent OS devra intégrer plus profondément sans rendre le contrôle plus flou. C’est le vrai test d’un système agentique.

La destination : Agent OS basé sur AOSP et futur téléphone FoneClaw

Notre destination produit reste un FoneClaw Agent OS basé sur AOSP et un futur téléphone FoneClaw conçu autour d’un agent personnel sur l’appareil. AOSP donne une fondation ouverte pour les réalités d’un téléphone : matériel, permissions, sécurité, connectivité, applications, notifications, comptes et services système. FoneClaw ajoute la logique agentique : intention, contexte, politique d’action, outils gouvernés, approbations, mémoire inspectable et récupération.

Cette destination est un travail de plateforme. Elle ne consiste pas seulement à placer un chatbot plus visible dans le système. Elle demande une architecture où l’agent peut être invoqué naturellement, recevoir un contexte limité au besoin, composer des capacités, respecter les règles de chaque action et rendre le résultat vérifiable. Dans notre vision, la voix exprime l’intention, les boutons physiques peuvent invoquer, confirmer ou arrêter, et l’écran sert à relire les preuves, les destinataires, les fichiers, les réglages et les changements proposés.

Le futur FoneClaw Agent OS devra aussi organiser les Agent Plugins. Une application traditionnelle se parcourt. Un Agent Plugin expose une capacité de service avec entrées, sorties, permissions, erreurs et reprise. L’agent personnel peut alors composer des capacités autour de la tâche : créer, vérifier, transformer, classer, envoyer, planifier ou récupérer. Chaque capacité doit rester déclarée et observable, car l’utilisateur doit comprendre ce qui agit en son nom.

Pour relier cette direction à une architecture technique plus complète, Fondation d’un agent de système d’exploitation : les trois couches qu’un agent IA de téléphone doit maîtriser présente les couches contexte, action et gouvernance. Notre feuille de route reprend cette logique dans un produit concret : partir de l’agent Android actuel, apprendre avec des intégrations comme le C1, puis construire vers une base système plus profonde.

Cette vision avance sans date artificielle. Les jalons doivent prouver des capacités : invocation fiable, permissions contextuelles, arrêt immédiat, plugins signés, mémoire contrôlable, résultats visibles et récupération robuste.

Mesurer la feuille de route par étapes vérifiables

Nous mesurons la progression par états livrés, pas par étiquette. La première étape est l’application Android actuelle : elle permet déjà des actions prises en charge avec état visible, approbations et récupération. La deuxième étape est la distribution plus intégrée, comme la préinstallation de FoneClaw en application système sur Meydo C1. La troisième étape vise une intégration plus profonde avec le système. La quatrième porte la direction FoneClaw Agent OS et futur téléphone FoneClaw.

Chaque étape doit être jugée par des preuves utilisateur. L’agent comprend-il la demande ? Le contexte vient-il d’une source claire ? L’action est-elle prise en charge ? La permission arrive-t-elle au bon moment ? L’utilisateur peut-il interrompre ? Le résultat est-il visible ? La reprise explique-t-elle quoi faire quand Android, un service ou une app bloque l’exécution ?

Cette lecture évite d’attendre un futur appareil pour tester la valeur actuelle. Elle évite aussi de donner à une préinstallation plus de sens qu’elle n’en porte. Un jalon d’intégration est utile lorsqu’il rend l’expérience plus accessible, mais il doit être évalué sur des actions réelles. Pour comparer les choix entre appareil dédié, téléphone existant et agent Android, Appareil IA vs smartphone : faut-il acheter un wearable IA ou utiliser un agent Android ? aide à décider par usage, écran, batterie, portabilité et gestion quotidienne.

Le fil conducteur reste constant : FoneClaw progresse vers un système agentique en renforçant d’abord les comportements que l’utilisateur peut vérifier aujourd’hui.

Choisir une route actuelle sans attendre toute la feuille de route

Le lecteur n’a pas besoin d’attendre la fin de la feuille de route pour choisir une route utile. Si vous voulez tester FoneClaw sur un téléphone Android que vous possédez déjà, commencez par les capacités actuelles, les permissions et les workflows pris en charge. La page Fonctionnalités FoneClaw présente les 100+ built-in tools pour les actions Android supportées, et Télécharger FoneClaw indique les routes d’accès disponibles au moment de l’installation.

Si vous voulez un appareil compact pensé pour des usages IA rapides, le Meydo C1 offre une autre route actuelle : matériel Meydo, système principal DroiClaw, FoneClaw préinstallé comme application système. Le statut de précommande, le prix, la destination, les taxes, les accessoires et la livraison doivent être vérifiés sur les pages Meydo au moment de décider. Notre page Meydo C1 : téléphone agent IA, DroiClaw et FoneClaw préinstallé garde les détails pratiques à jour dans une lecture dédiée.

Pour les deux routes, commencez par une tâche réversible : créer un mémo, résumer un écran, préparer un rappel, ouvrir une navigation ou vérifier une notification. Observez l’état, la permission, l’approbation, l’arrêt et le résultat final. C’est ainsi que nous voulons que FoneClaw soit évalué : non pas comme une promesse abstraite d’OS, mais comme une progression concrète vers un téléphone où l’agent personnel devient une interface fiable.

La vision finale reste ambitieuse : un FoneClaw Agent OS basé sur AOSP et un futur téléphone FoneClaw. Le chemin actuel est déjà utile : agent Android gouverné, distribution plus intégrée, apprentissage produit, puis responsabilités système plus profondes.

Sources : cet article s’appuie sur la feuille de route FoneClaw actuelle, les pages publiques FoneClaw de fonctionnalités et de téléchargement, la page produit Meydo C1 et l’article Meydo consacré à DroiClaw.