Pinky donne à Claude le contrôle d'un vrai téléphone via MCP — les paiements uniquement avec votre feu vert

Si vous avez déjà développé une application mobile, vous connaissez le principal calvaire : il faut la tester à la main. Taper, faire défiler, repérer un bug, retourner dans l'éditeur. Des agents de codage comme Claude Code et Cursor gèrent depuis longtemps le terminal et le navigateur, mais ils n'atteignaient pas le téléphone. Le projet Pinky tente d'y remédier : il met un véritable smartphone entre les mains de l'agent via le protocole MCP.

Ce qui est annoncé exactement

D'après un post sur X de @xiaoanlab, le schéma est le suivant. Pinky joue le rôle de serveur MCP auquel se connectent Claude Code ou Cursor. Par son intermédiaire, l'agent reçoit l'image de l'écran d'un appareil réel et peut interagir avec lui. La prise en charge d'iPhone et d'Android est annoncée. Il ne s'agit pas d'un émulateur mais d'un téléphone physique, et la différence est importante : sur du vrai matériel apparaissent des bugs absents du simulateur, des caprices de l'appareil photo et des notifications push jusqu'au comportement des boîtes de dialogue système.

Un exemple simple. Vous demandez à l'agent : « Ouvre l'application, passe l'inscription et vérifie que l'onboarding s'affiche après la connexion. » Auparavant, un tel scénario devait être décrit dans des tests d'interface avec Appium ou XCUITest, puis corrigé à chaque modification de la mise en page. Ici, l'agent regarde l'écran comme un humain et prend ses décisions au fil de l'eau.

La question centrale : qui garde la main sur le bouton

Donner à un modèle de langage l'accès à un téléphone revient à lui donner accès aux applications bancaires, aux messageries et à la messagerie électronique. C'est pourquoi le plus intéressant dans cette annonce n'est pas le simple tap sur l'écran, mais le modèle de sécurité. Selon l'auteur, les paiements, les virements, les suppressions et les installations d'applications exigent un « autoriser » explicite de la part d'un humain. Les banques, les portefeuilles et les gestionnaires de mots de passe sont apparemment bloqués par défaut, mais cette phrase est tronquée dans le post et la formulation exacte ne peut pas être vérifiée.

Il est souligné séparément que les règles sont appliquées de manière stricte dans la passerelle Pinky. C'est un point essentiel. Si l'interdiction ne réside que dans le prompt système, on peut la contourner par injection : un texte malveillant à l'écran convaincra le modèle qu'il peut payer. Si, en revanche, la vérification se situe au niveau d'un proxy entre l'agent et l'appareil, le modèle ne peut physiquement pas envoyer de commande dangereuse sans confirmation, quelle que soit la façon dont on le persuade. C'est le même principe qui, en production, empêche de donner à un agent un accès direct à la base de données et impose une couche de permissions entre les deux.

Limites et que faire

Commençons par ce que nous ignorons. La source est unique : un court post comptant 88 vues, dont le texte est coupé au milieu d'une phrase. Il n'y a ni documentation, ni prix, ni données de latence, ni informations sur la manière dont l'accès à l'iPhone est mis en œuvre. Sous iOS, ce n'est pas trivial en raison du caractère fermé du système, et l'auteur ne donne aucun détail. On ignore si tout fonctionne en local ou si l'écran part vers des serveurs tiers. Pour tester des applications contenant des données d'utilisateurs, c'est critique.

Il existe aussi des limites générales. Un agent qui pilote l'interface à partir de captures d'écran est plus lent et moins déterministe que des tests scriptés. Confirmer manuellement chaque action dangereuse évite les catastrophes, mais tue l'autonomie. Et toute politique « stricte » ne vaut que par l'exhaustivité avec laquelle elle recense les actions dangereuses.

La conclusion pratique est brève. Les développeurs d'applications mobiles ont intérêt à suivre cette piste et, si le projet publie son code, à l'essayer sur un téléphone de test dédié, sans comptes personnels, et non sur leur appareil principal. Les product managers doivent garder à l'esprit que l'interface mobile deviendra bientôt accessible aux agents comme le web, et que votre application devra être compréhensible non seulement pour les humains. Les fondateurs doivent regarder le pattern lui-même : une passerelle de politiques entre le modèle et l'appareil devient une couche de produit à part entière, et un business pourrait très bien se bâtir autour.