Doubao ouvre progressivement l’automatisation des applications mobiles, tandis que les grandes plateformes refusent l’accès

Une période de préavis de 30 jours s’achève, mais de grandes applications restent inaccessibles

Le 14 octobre, Doubao Phone Assistant a annoncé qu’il ouvrirait progressivement l’accès à l’automatisation de l’écran pour les applications tierces, à l’issue d’une période de préavis public de 30 jours concernant son protocole d’exécution de l’automatisation de l’écran (SAEP). Les développeurs peuvent toujours refuser cet accès après la période de préavis, et l’assistant n’interviendra pas sur les applications qui ont explicitement rejeté l’automatisation.

La liste des refus comprend de nombreux services qui rendraient un assistant téléphonique utile au quotidien. Parmi les applications de l’écosystème Alibaba figurent Taobao, Tmall, Cainiao, Alipay, DingTalk et Ele.me. Celles de l’écosystème Tencent incluent WeChat, QQ, Honor of Kings et League of Legends: Wild Rift. La liste mentionne aussi Meituan, Pinduoduo, Kuaishou, Xiaohongshu, Zhihu, China Merchants Bank et Industrial and Commercial Bank of China.

Il s’agit donc d’une extension de l’accès, et non d’un contrôle sans restriction du téléphone. Le nouveau mécanisme remplace l’obligation temporaire pour les développeurs d’accepter activement l’automatisation par une ouverture progressive des applications éligibles, sauf refus ou restrictions définies par leurs développeurs. Les règles de sécurité du système, l’autorisation de l’utilisateur et les contrôles propres à chaque application restent applicables.

Doubao indique que les développeurs peuvent soumettre un refus à tout moment et que la plateforme leur répondra sous trois jours ouvrés. Cet engagement de réponse ne garantit pas que chaque demande sera mise en œuvre dans ce délai. L’annonce précise que les opérations concernées seront rapidement désactivées, sans fixer de délai universel distinct pour leur mise en œuvre.

Pour les utilisateurs, la question concrète est de savoir quelles étapes d’une tâche l’assistant peut accomplir. Une application peut être entièrement inaccessible, une page sensible peut être bloquée ou l’utilisateur peut devoir reprendre la main pour effectuer l’action finale. Le SAEP prévoit des mécanismes pour ces trois situations.

Qu’est-ce qui change après la période de préavis ?

Pendant la période de préavis public, Doubao a limité l’automatisation aux applications système, aux applications ByteDance et aux services tiers ayant expressément accepté de participer au SAEP ou par échange officiel de courriels. Par défaut, l’assistant n’intervenait pas sur les autres applications.

Après cette période, les applications dont les développeurs n’ont soumis aucun refus par les canaux officiels et qui n’ont défini aucune règle de désactivation peuvent bénéficier progressivement de l’accès. En septembre, la présentation du projet précisait que cette ouverture dépendrait des niveaux de risque et ne serait pas déclenchée simultanément pour toutes les applications.

Cette distinction compte pour comprendre l’échec d’une tâche. Avant le 14 octobre, une application pouvait être inaccessible simplement parce que son développeur n’avait pas donné son accord explicite. Depuis cette date, l’accès peut toujours échouer en raison d’un refus, d’une restriction portant sur une page, d’une vérification d’identité, d’une demande de confirmation de l’utilisateur ou des propres contrôles de sécurité de l’application.

La version grand public de l’assistant a été lancée le 14 septembre, avec la fonction de commande du téléphone en version bêta. Les autres fonctions, notamment les services intelligents de Doubao, l’aide aux achats, les résumés d’enregistrements et les tâches professionnelles, sont indépendantes de l’autorisation d’une application externe donnée à l’automatisation de l’écran.

Les étapes qui ont mené au 14 octobre

Ce changement de politique fait suite à de précédents conflits entre la commande automatisée du téléphone et les systèmes de sécurité des applications. En décembre 2025, le premier aperçu technologique du téléphone Doubao s’est heurté à des problèmes de connexion sur WeChat, à des vérifications sur Taobao et à des applications bancaires qui interrompaient les connexions ou les paiements après avoir détecté un environnement à risque.

Le lancement grand public qui a suivi a instauré une procédure officielle de déclaration avant l’élargissement de l’accès. Les principales étapes sont les suivantes :

• Décembre 2025 : le Nubia M153 introduit l’automatisation téléphonique de Doubao, avant que plusieurs grandes applications n’imposent des restrictions et des contrôles de sécurité.
• 14 septembre 2026 : l’assistant grand public lance la version bêta de la commande du téléphone et la période de préavis de 30 jours débute. Certains utilisateurs du M153 signalent la disparition de tâches automatisées jusque-là disponibles.
• 16 septembre : le Nubia NaviX Ultra arrive sur le marché avec l’assistant grand public. Les informations publiées présentent cette date comme celle de son lancement ou du début des ventes.
• 17 septembre : Doubao précise que les développeurs pourront toujours refuser l’automatisation après la période de préavis.
• 14 octobre : Doubao annonce la fin de la période de préavis et l’ouverture progressive de l’accès aux applications tierces éligibles.

Pour les utilisateurs déjà équipés, les restrictions de septembre ont pu donner l’impression d’une perte de fonctionnalités. Des témoignages font état de propriétaires de M153 qui ne pouvaient plus recourir à leurs tâches automatisées habituelles, comme réserver un trajet ou commander à manger. Ces restrictions découlaient des règles temporaires d’autorisation et ne prouvaient pas que tous les développeurs concernés avaient rejeté l’assistant.

Quelles applications ont refusé l’accès ?

La liste des refus du 14 octobre va au-delà d’Alibaba et de Tencent. Des informations publiées mentionnent également DeepSeek, WPS et Vipshop, ainsi que des applications de commerce, de réseaux sociaux, de banque et de services de proximité. Les applications de China Mobile, China Unicom et China Telecom auraient elles aussi refusé l’accès.

Ces restrictions concernent les Nubia M153 et Nubia NaviX Ultra. Leur importance tient moins au nombre brut d’applications qu’aux services qu’elles couvrent. Une tâche d’achat peut buter sur une plateforme de vente inaccessible, une tâche de communication s’arrêter sur une messagerie et une opération financière se heurter à la fois au refus du développeur et à des exigences distinctes de sécurité système.

Les descriptions publiées ne recensent pas de manière exhaustive toutes les applications accessibles et inaccessibles. Un article antérieur affirmait que 90 % des applications fréquemment utilisées prenaient progressivement en charge l’agent graphique de Doubao, sans préciser la méthode de mesure ni l’ensemble des applications comptabilisées. Ce chiffre ne permet pas d’établir la proportion d’applications accessibles selon les règles d’octobre.

En septembre, les descriptions des services pris en charge citaient Cao Cao Mobility, Qishui Music et Feishu Minutes. La présence d’un service dans une liste de prise en charge des commandes du téléphone ne signifie pas à elle seule que son développeur a réalisé toutes les étapes de l’intégration technique au SAEP. La prise en charge d’une tâche et l’adoption du protocole sont liées, mais distinctes.

Ce que contrôle réellement le SAEP

Le guide d’intégration officiel de Doubao présente le SAEP comme un protocole permettant aux applications Android de définir les limites d’action d’un agent graphique. Un agent graphique interprète une interface et effectue des actions comme cliquer sur des boutons ou saisir du texte, au lieu de s’appuyer uniquement sur l’interface logicielle dédiée d’une application.

Le guide indique que la prise en charge concerne ObricUI version 2.2 et ultérieure. Cela ne signifie pas que le SAEP fonctionne sur tous les téléphones Android. Les développeurs doivent vérifier si la fonction est présente et activée sur l’appareil visé. Si ce n’est pas le cas, leurs applications doivent continuer à s’appuyer sur leurs propres contrôles de sécurité.

Les restrictions s’appliquent à trois niveaux : App, pour l’ensemble de l’application ; Activity, pour un écran ou une page Android en particulier ; et Intent, pour une action métier telle que publier ou supprimer un contenu. Ici, le terme « intent » désigne l’objectif d’une opération, et non simplement le bouton visible sur lequel l’assistant intervient.

Cette structure permet à une application d’autoriser certaines formes d’assistance tout en protégeant les étapes sensibles. Elle peut interdire toute activité de l’agent au moyen de global_disable, empêcher les captures d’écran avec screenshot_disable ou bloquer les clics simulés et la saisie de texte avec input_disable. D’autres contrôles portent sur la modification de contenus, leur publication finale, leur suppression et les récompenses ou avantages promotionnels.

Toute action autorisée reste soumise à validation

Le guide officiel établit une distinction fondamentale entre l’autorisation accordée par une application et la décision finale du système. L’issue dépend de l’identité de l’agent et de son niveau de confiance, du socle de sécurité du système, des règles déclarées par l’application et de l’autorisation de l’utilisateur pour la tâche en cours.

Les applications ne peuvent pas assouplir le socle de sécurité du système. Si celui-ci impose un blocage ou une intervention de l’utilisateur, une application ne peut pas transformer cette issue en autorisation. En cas de conflit entre plusieurs règles applicables, la plus stricte prévaut. Si l’analyse de la politique échoue, le système applique la politique par défaut utilisable de l’application et consigne la raison.

Le guide décrit trois issues principales. ALLOW autorise la capacité système concernée, sans supprimer les exigences d’authentification de l’application ni celles relatives à l’autorisation de l’utilisateur. BLOCK interrompt l’action et ne doit pas inciter l’assistant à chercher un autre moyen de contourner la restriction. CALL_USER suspend l’automatisation en attendant une confirmation système ou une reprise en main manuelle.

Une confirmation ne s’applique qu’à l’étape précise présentée à l’utilisateur. Elle ne vaut pas autorisation générale pour toutes les actions suivantes. Les paiements, les transferts, l’authentification à un compte, la publication, la suppression et la modification des autorisations font partie des opérations sensibles pour lesquelles le système peut exiger une confirmation, une reprise en main par l’utilisateur ou un refus.

Une quatrième mention, CLARIFY, apparaît dans la documentation pour les demandes de clarification ou les contraintes moins strictes. Son sens précis et sa disponibilité dépendent du progiciel système visé. Le guide met également en garde les développeurs contre l’idée que l’ordre des règles App, Activity et Intent permettrait à une règle ultérieure d’annuler une restriction antérieure.

Les restrictions doivent être appliquées au-delà des promesses de l’assistant

La principale garantie technique du SAEP est que les restrictions doivent être appliquées aux points de contrôle du système et ne pas reposer uniquement sur la volonté de l’agent de s’y conformer. L’accès aux captures d’écran, la lecture via les services d’accessibilité, les clics et les saisies simulées sont censés passer par des circuits d’exécution contrôlés.

Le guide donne des exemples concrets. Une interdiction définie par une application peut empêcher l’application visée d’accéder à l’écran virtuel de l’agent. Une restriction sur les captures d’écran peut s’appuyer sur une couche d’affichage sécurisée. Les limites d’entrée peuvent bloquer les actions simulées dans le circuit de gestion des entrées d’Android.

Une réserve importante s’impose : l’application complète des restrictions portant sur les actions métier dépend de la version du système visé. Les développeurs ne doivent pas considérer que la déclaration de conformité d’un agent suffit à prouver qu’une restriction sur la publication, la suppression ou les récompenses est techniquement appliquée.

L’intégration de base recommandée consiste à intégrer une politique statique dans l’application. Le système la lit et la met en cache à l’installation ou à la mise à jour de l’application, sans que le processus de celle-ci ait besoin d’être en cours d’exécution. Des mises à jour dynamiques facultatives permettent de faire évoluer les règles selon le statut de l’utilisateur ou les conditions d’utilisation du service. Elles doivent utiliser des numéros de version croissants et, en cas d’échec d’une mise à jour, la politique valide précédente doit être conservée.

Les journaux d’audit fournissent une trace, avec des limites de conservation

Le protocole fournit aux applications des interfaces leur permettant de consulter les agents enregistrés et d’interroger les journaux d’audit relatifs à leur propre application. Les informations d’identité peuvent comprendre l’identifiant de l’agent, le nom du paquet, la signature, le type, le niveau de confiance et la version. L’enregistrement ne signifie pas, à lui seul, qu’un agent est autorisé à effectuer toutes les opérations métier.

Le système d’audit consigne à la fois la décision de la politique et le résultat réel de l’exécution. Les développeurs peuvent ainsi distinguer une action autorisée mais échouée d’une action rejetée suivie d’une tentative de contournement. Les enregistrements peuvent associer un agent à une session, une étape de tâche, une application cible, une page, un type d’action, une version de politique et un code expliquant la décision.

Le guide préconise une divulgation limitée : les journaux d’audit ne doivent contenir ni captures d’écran brutes, ni informations personnelles sensibles saisies par les utilisateurs, ni arborescences complètes des éléments de l’interface. Une application ne peut consulter que les journaux associés à son propre paquet, et non l’historique d’autres applications.

Les journaux sont stockés dans une zone sécurisée de l’appareil et conservés par défaut pendant 60 jours. Une suppression automatique est également déclenchée lorsque la base de données dépasse 100 Mo ou que le nombre d’enregistrements dépasse 100 000. Ces seuils constituent des déclencheurs distincts : sur un appareil très actif, les journaux les plus anciens peuvent donc être supprimés avant 60 jours. Les capacités réelles de consultation, d’exportation et de conservation dépendent de la version du système.

Doubao a par ailleurs indiqué privilégier le traitement des informations sensibles sur l’appareil. Son équipe affirme que les données devant être envoyées vers le cloud font l’objet d’un chiffrement supplémentaire en local et que la clé correspondante est détruite à la fin de la session. Il s’agit de pratiques de conception déclarées, et non d’une vérification indépendante établissant qu’elles s’appliquent à tous les usages déployés.

Le choix de l’utilisateur et le contrôle des développeurs restent en tension

Le SAEP offre aux développeurs un moyen structuré de refuser ou de limiter l’automatisation, mais ne tranche pas le débat juridique sur la nécessité pour un assistant agissant au nom de l’utilisateur d’obtenir une autorisation distincte de chaque application. Les règles de fonctionnement du protocole et le statut juridique de l’autorisation donnée par l’utilisateur sont deux questions différentes.

Ge Jiangqiu, professeur associé à la faculté de droit de l’université Fudan, estime qu’un agent assiste l’utilisateur ou agit en son nom, et que les effets juridiques de ses actions lui sont imputables. Wu Peicheng, chercheur à la faculté de droit Guanghua de l’université du Zhejiang, défend une approche fondée sur une autorisation unique de l’utilisateur. Il estime qu’exiger en plus l’autorisation des plateformes restreindrait les usages quotidiens et augmenterait les coûts du secteur.

Zhai Wei, directeur exécutif du Centre de recherche sur le droit de la concurrence à l’Université des sciences politiques et du droit de Chine orientale, aborde les échanges entre applications sous l’angle du contrôle des données personnelles par l’utilisateur, notamment de leur portabilité et de leur suppression. Huang Yinxu, professeur associé à la faculté de droit de l’université Renmin de Chine, estime de même qu’une autorisation valide du système ne devrait pas nécessiter des demandes répétées aux plateformes externes lorsque l’agent exécute fidèlement les instructions de l’utilisateur.

Il s’agit de positions universitaires, et non d’une décision de justice annulant les restrictions imposées par les développeurs. En pratique, l’approche annoncée par Doubao respecte les refus explicites. Dans les règles de fonctionnement de l’assistant, l’instruction de l’utilisateur ne prévaut donc pas sur l’interdiction d’une application.

À quoi les utilisateurs peuvent-ils s’attendre ?

La version du NaviX Ultra dotée de 12 Go de mémoire et de 512 Go de stockage était proposée à 5 999 yuans, avec un prix de départ de 5 499 yuans après subvention nationale. La réduction s’élève à 500 yuans, soit environ 8,3 % du prix affiché. L’achat de l’appareil ne garantit ni l’accès à toutes les applications ni l’exécution de toutes les tâches.

Les démonstrations de Doubao illustrent l’expérience visée : un assistant qui utilise une vue caméra pour trouver un meuble correspondant à des dimensions et à un budget donnés, ou qui commande un trajet à partir d’une adresse connue. Ces démonstrations présentent des usages prévus ; elles ne prouvent pas que tous les services de vente ou de transport les autorisent selon les règles actuelles.

Aucun calendrier détaillé n’a été annoncé pour l’ouverture de chaque application après le 14 octobre. Les informations publiées ne permettent pas non plus d’établir un taux d’acceptation définitif, un calendrier complet du déploiement ou une application technique uniforme de toutes les restrictions portant sur les actions métier dans les versions compatibles.

Le prochain test concret sera de vérifier si les utilisateurs obtiennent des explications prévisibles lorsqu’une tâche s’interrompt : refus du développeur, page protégée, règle de sécurité du système ou demande de confirmation personnelle. L’ouverture progressive élargit les possibilités de l’assistant, tandis que le SAEP en fixe les limites.

À retenir

• Le 14 octobre, Doubao a annoncé l’ouverture progressive de l’automatisation de l’écran pour les applications tierces, après une période de préavis de 30 jours.
• L’assistant n’interviendra pas sur les applications qui refusent explicitement l’accès.
• La liste des refus comprend de grands services d’Alibaba et de Tencent, des banques, des plateformes de vente et d’autres applications populaires.
• Les développeurs peuvent toujours refuser l’accès ; Doubao s’engage à leur répondre sous trois jours ouvrés.
• Le SAEP permet d’appliquer des restrictions à des applications entières, à des pages précises et à certaines actions métier.
• Les exigences de sécurité du système et l’autorisation de l’utilisateur restent nécessaires même lorsqu’une application permet l’automatisation.
• Le guide officiel indique qu’ObricUI 2.2 ou une version ultérieure est nécessaire, certaines capacités dépendant de la version visée.
• Aucun calendrier détaillé d’ouverture des applications n’a été annoncé.