OpenClaw sur mobile quatre mois plus tard : simple télécommande ou véritable nœud d’agent IA ?

À son lancement fin juin 2026, l’arrivée d’OpenClaw sur iOS et Android avait tout d’une version précipitée. Les premières applications étaient difficiles à appairer, leur interface manquait de finition et les utilisateurs Android signalaient de nombreux dysfonctionnements.

Quatre mois plus tard, le constat doit être largement révisé. Les applications ont reçu plusieurs refontes, l’appairage a été repensé et les capacités mobiles ont considérablement progressé. OpenClaw ne se contente plus d’afficher une conversation sur un téléphone : il peut désormais utiliser le smartphone comme interface opérateur et, avec les autorisations appropriées, comme véritable nœud d’exécution.

Cette évolution rend le projet plus utile, mais également beaucoup plus sensible du point de vue de la sécurité.

Les critiques de juillet sont-elles encore valables ?

L’article publié en juillet décrivait correctement l’état initial des applications. OpenClaw venait de proposer ses premiers clients officiels pour iPhone et Android, mais l’expérience restait rudimentaire, particulièrement sur la plateforme de Google.

Depuis, le projet a multiplié les versions. La mise à jour 2026.7.1 a notamment amélioré l’installation, la navigation, les conversations, les pièces jointes, la voix et la récupération après une perte de connexion. La version 2026.8.1, présentée comme OpenClaw 2.0, a ensuite reconstruit une grande partie de l’expérience mobile.

Au 3 novembre 2026, la dernière version du projet publiée sur GitHub est la 2026.10.10. Elle ajoute encore de nouvelles capacités aux nœuds mobiles : informations système, photos, contacts, calendrier et données de mouvement sur Android, ainsi qu’un mécanisme de présence en arrière-plan authentifié sur iOS.

Le développement reste néanmoins très actif. Une semaine communautaire consacrée aux applications mobiles se déroule du 2 au 8 novembre 2026 pour tester les usages réels et traiter les problèmes restants. Il serait donc excessif de considérer ces applications comme définitivement stabilisées.

L’application mobile n’héberge pas l’agent

OpenClaw mobile ne fonctionne pas comme ChatGPT, Claude ou une application d’assistant classique. L’application ne contient pas à elle seule l’agent, ses outils et ses connexions.

Le cœur du système reste l’OpenClaw Gateway, installé sur un ordinateur, un serveur personnel ou une machine virtuelle. Cette passerelle gère notamment :

les fournisseurs de modèles ;
les conversations et leur mémoire ;
les agents et leurs outils ;
les automatisations ;
les plugins et les canaux de communication ;
les autorisations d’exécution ;
les appareils associés.

L’application mobile se connecte à ce Gateway. Si le serveur est arrêté ou inaccessible, une grande partie des fonctionnalités devient indisponible.

Cette architecture conserve l’un des principaux intérêts d’OpenClaw : l’utilisateur garde le contrôle de sa passerelle, de ses configurations et d’une partie importante de ses données. En contrepartie, il doit assurer lui-même l’hébergement, les mises à jour, l’accès distant et la sécurité de l’ensemble.

Deux connexions pour deux rôles différents

Les applications mobiles cumulent deux fonctions qui doivent être distinguées.

L’interface opérateur

La connexion opérateur permet d’utiliser OpenClaw depuis le téléphone :

envoyer des messages ;
consulter les conversations ;
choisir un agent ou un modèle ;
suivre l’avancement d’une tâche ;
répondre aux questions de l’agent ;
examiner une demande d’autorisation ;
approuver ou refuser l’exécution d’une commande ;
consulter certains fichiers de l’espace de travail ;
gérer certaines fonctions du Gateway.

Selon le niveau d’accès accordé, le téléphone devient donc une véritable console d’administration mobile.

Le nœud mobile

La connexion de type node fonctionne dans l’autre sens. Le smartphone met certaines de ses capacités à la disposition du Gateway.

L’agent peut alors demander au téléphone de réaliser une action ou de lui fournir une information, à condition que la fonctionnalité soit activée et que le système d’exploitation ait accordé l’autorisation correspondante.

Le téléphone n’est plus seulement l’écran de l’agent : il devient l’un de ses périphériques.

Ce qu’OpenClaw peut utiliser sur un smartphone

Les capacités dépendent du système, de la version de l’application et des permissions choisies.

Fonction	iOS	Android
Chat et suivi des conversations	Oui	Oui
Mode vocal et dictée	Oui	Oui
Appareil photo	Oui	Oui
Capture ou partage de l’écran	Oui	Selon les fonctions disponibles
Localisation	Oui	Oui
Notifications OpenClaw	Oui	Oui
Transmission des notifications du téléphone	Limitée par iOS	Oui, en option
Photos récentes	Selon les permissions	Oui
Contacts et calendrier	Oui	Oui
Données de mouvement	Selon les capacités exposées	Oui
SMS et journal d’appels	Non accessibles de la même manière	Capacités de recherche documentées
Approbation de commandes	Oui	Oui
Consultation de fichiers de travail	Oui	Oui, en lecture seule

Sur Android, OpenClaw documente notamment des commandes permettant d’interroger les notifications, les applications installées, les photos, les contacts, le calendrier, le journal d’appels, les SMS et certaines données de mouvement. Leur disponibilité dépend du téléphone, des permissions et des réglages activés.

Sur iOS, les autorisations sont demandées progressivement lors de l’utilisation des fonctions concernées. Le système conserve également des restrictions plus fortes sur l’exécution en arrière-plan : les connexions et les fonctions vocales peuvent être suspendues lorsque l’application n’est plus active.

Pourquoi ces capacités changent la nature du projet

Un agent accessible depuis un téléphone peut déjà répondre à des questions ou demander l’approbation d’une commande. Un agent capable d’utiliser la caméra, la localisation, les notifications et le calendrier dispose d’un contexte beaucoup plus riche.

Il devient possible d’imaginer des scénarios comme :

photographier un équipement et demander à l’agent de l’identifier ;
dicter une instruction en déplacement ;
recevoir une demande d’approbation pour une opération lancée sur un serveur ;
interroger son calendrier avant de démarrer une automatisation ;
transmettre certaines notifications à un agent chargé de les classer ;
utiliser la localisation comme contexte d’une tâche ;
consulter le résultat d’un agent de développement sans ouvrir un ordinateur.

Ces usages sont puissants, mais ils rapprochent OpenClaw d’un assistant personnel disposant d’un accès privilégié à la vie numérique de l’utilisateur.

L’appairage devient une décision de sécurité

L’association du téléphone au Gateway s’effectue généralement à l’aide d’un QR code ou d’un code temporaire généré depuis l’interface de contrôle.

OpenClaw propose deux niveaux d’accès :

Full access, qui donne à l’application les fonctions administratives nécessaires pour contrôler largement le Gateway ;
Limited access, qui retire une partie de ces capacités.

L’accès complet est recommandé et présélectionné dans certains parcours d’appairage. Il est pratique pour administrer OpenClaw à distance, mais il transforme le téléphone en terminal particulièrement sensible. Une personne ayant accès à l’appareil déverrouillé pourrait potentiellement consulter les conversations, examiner les tâches et intervenir sur des autorisations en attente.

Le niveau limité est préférable lorsque le téléphone sert principalement au chat, à la voix ou à quelques capacités mobiles et qu’il n’a pas vocation à administrer toute l’installation.

Comment exposer le Gateway sans ouvrir une brèche

Sur le réseau local, le téléphone peut rejoindre un Gateway configuré pour écouter sur le LAN. Cette solution convient à un usage limité au domicile ou au bureau, à condition que le réseau soit considéré comme fiable et que l’authentification reste activée.

Pour l’accès à distance, la documentation recommande notamment Tailscale Serve. Cette méthode fournit une adresse sécurisée en https:// et wss:// sans exposer directement le port du Gateway sur Internet.

Une connexion distante correctement conçue devrait respecter plusieurs principes :

ne pas publier directement le port du Gateway sur Internet ;
utiliser une connexion chiffrée en wss:// ;
conserver une authentification par jeton ou mot de passe ;
examiner les rôles et les portées avant d’approuver un appareil ;
préférer un accès limité lorsque l’administration complète n’est pas nécessaire ;
révoquer les anciens appareils et codes d’appairage ;
maintenir le Gateway et l’application mobile à jour.

OpenClaw limite automatiquement certaines connexions utilisant du ws:// non chiffré, précisément pour réduire l’exposition des jetons d’accès. Les connexions distantes sécurisées restent nécessaires pour bénéficier du profil opérateur complet.

Le risque ne vient pas uniquement du réseau

Même parfaitement chiffrée, une connexion ne protège pas contre toutes les erreurs.

Un agent peut recevoir une instruction malveillante depuis une page Web, un document, un e-mail ou une notification. Cette injection de prompt peut tenter de le convaincre d’utiliser ses outils ou d’accéder à des données qui n’étaient pas nécessaires à la tâche initiale.

L’ajout du smartphone augmente les conséquences potentielles :

exposition de données personnelles ;
collecte de notifications confidentielles ;
accès excessif au calendrier et aux contacts ;
utilisation inattendue de la caméra ou de la localisation ;
validation trop rapide d’une commande depuis une notification ;
mélange entre usages personnels et professionnels.

La documentation de sécurité d’OpenClaw recommande notamment de limiter les outils, d’utiliser des listes d’autorisation, de cloisonner les sessions, d’activer le sandboxing et d’appliquer des profils d’accès différents selon les agents.

Une configuration raisonnablement prudente

Pour une première utilisation mobile, une configuration défensive pourrait suivre ces règles :

installer le Gateway sur une machine dédiée ou correctement isolée ;
ne pas lui donner immédiatement accès à toutes les données personnelles ;
utiliser Tailscale Serve ou une autre terminaison TLS maîtrisée ;
commencer avec un accès opérateur limité ;
n’activer que les permissions mobiles nécessaires à un cas d’usage réel ;
utiliser une liste d’applications autorisées pour les notifications transmises ;
éviter de transférer les notifications bancaires, professionnelles ou d’authentification ;
conserver une validation humaine pour les commandes sensibles ;
séparer les agents personnels et professionnels ;
vérifier régulièrement les appareils appairés, les plugins et les journaux.

Sur Android, le transfert des notifications est désactivé par défaut. Il peut être limité à certaines applications, associé à des heures silencieuses et protégé par une limite de fréquence. Ces réglages sont préférables à un transfert global de toutes les notifications.

Les limites qui subsistent

Malgré les progrès, OpenClaw mobile ne vise pas encore le grand public.

L’utilisateur doit toujours comprendre plusieurs concepts techniques :

hébergement du Gateway ;
découverte réseau ;
authentification ;
TLS et WebSocket ;
appairage et rôles ;
compatibilité des protocoles ;
gestion des permissions ;
maintenance des versions.

L’application Android et le Gateway ne doivent pas nécessairement porter le même numéro de version, mais leurs protocoles doivent rester compatibles. Un appairage réussi ne garantit donc pas que toutes les fonctions marcheront avec n’importe quelle combinaison de versions.

Sur iOS, les contraintes du système limitent encore certaines fonctions en arrière-plan. Sur Android, le maintien de la connexion peut nécessiter un service au premier plan et sa notification persistante.

Enfin, les fonctionnalités évoluent très rapidement. Un comportement documenté aujourd’hui peut être corrigé, déplacé ou remplacé quelques versions plus tard.

OpenClaw mobile est-il enfin prêt ?

Pour un utilisateur à l’aise avec l’auto-hébergement, les réseaux privés et les permissions d’un agent, la réponse devient plutôt positive.

Les applications ne sont plus seulement des prototypes permettant d’envoyer quelques messages. Elles offrent une continuité réelle avec le Gateway, des commandes vocales, le suivi des tâches, des approbations et un ensemble croissant de capacités mobiles.

Elles ne constituent cependant pas encore une solution prête à installer pour le grand public. OpenClaw mobile reste la façade d’une infrastructure que l’utilisateur doit lui-même déployer, sécuriser et maintenir.

La véritable évolution depuis juillet n’est donc pas simplement que l’application possède une meilleure interface. C’est que le smartphone est devenu une composante du système agentique.

Cette transformation rend OpenClaw beaucoup plus intéressant — et impose de traiter chaque permission accordée au téléphone comme un accès potentiel à des données sensibles.