01 · Exécution confirmée
Gemini affiche une confirmation de désactivation du Wi-Fi.
Sur mon Honor Magic V5 verrouillé, Gemini peut couper le Wi-Fi malgré mes restrictions. Mais une même demande peut aussi aboutir à une confirmation, un silence, un chargement, un refus ou une exigence de déverrouillage. Et certaines actions exécutées ne figurent pas dans mes conversations visibles.
L’essentiel · Actualisation 31 octobre 2026
01 — Mes restrictions. Sur mon téléphone verrouillé, l’accès manuel au Centre de contrôle est restreint. Gemini a néanmoins exécuté la coupure Wi-Fi sans authentification validée dans les essais documentés.
02 — Des issues différentes. Pour une demande similaire, j’observe des exécutions avec ou sans retour, un chargement prolongé, des refus, une demande de déverrouillage et un retour silencieux à l’écran de verrouillage.
03 — La traçabilité visible. Dans le test témoin du 14 octobre, la météo figure dans les conversations Gemini. La coupure Wi-Fi exécutée n’y figure pas. Le 21 septembre, une demande faite téléphone verrouillé apparaît d’abord dans « Récents », puis n’y figure plus après rechargement de la liste.
04 — Ma question. Comment comprendre et contrôler une action qui peut être exécutée, refusée ou rester sans réponse visible selon l’essai, et qui peut aussi être exécutée plus tard, au retour de la connexion, sans que je la répète ?
COMPLÉMENT DOCUMENTAIRE · 31 OCTOBRE 2026
Je ne constate pas seulement que Gemini peut désactiver le Wi‑Fi depuis mon écran verrouillé malgré les restrictions configurées. Je constate aussi des résultats différents pour cette demande : exécution confirmée, exécution sans confirmation, refus d’accès, demande de déverrouillage, chargement prolongé et retour silencieux à l’écran de verrouillage. Ces issues sont présentées séparément pour ne pas confondre l’action réelle, le message affiché et l’historique visible.
Gemini affiche une confirmation de désactivation du Wi-Fi.
Le Wi-Fi est coupé, sans retour d’action visible.
Dans la vidéo du 21 septembre ci-dessous (vers 12 h 10), le téléphone reste verrouillé du début à la fin : le visage puis l’empreinte ne sont pas reconnus et je ne saisis pas le code PIN. Gemini vient d’afficher « Désolé, un problème est survenu et je n’ai pas pu l’effectuer. » Je renouvelle la demande. Vers 0:40, l’icône Wi-Fi disparaît de la barre d’état alors que ce message d’échec est toujours affiché, puis « Connexion à Assistance Appareil… » apparaît. Aucune confirmation n’est donnée. Vers 0:48, Gemini affiche « Vérifiez votre connexion Internet, puis réessayez ».


Gemini déclare ne pas pouvoir modifier les paramètres de l’appareil.
La demande reste en chargement ; la capture finale montre la barre d’état sans pictogramme Wi-Fi.
Après ma demande de coupure du Wi-Fi depuis l’écran verrouillé, Gemini affiche l’écran de saisie du code PIN, sans réponse textuelle ni vocale constatée. Je quitte cet écran sans saisir le code, puis je relance la demande : lors de cette nouvelle tentative, l’action peut être exécutée.
Dans la même vidéo, juste avant, je demande sur l’écran verrouillé « Tu peux désactiver le wifi ». Gemini affiche « Un instant… ». Vers 0:22, la fenêtre de Gemini se ferme et je me retrouve sur l’horloge de l’écran de verrouillage : pas de réponse écrite ni vocale, pas d’action visible, pas de demande de déverrouillage. Quand je touche l’écran ensuite, c’est le clavier du code PIN habituel qui s’affiche ; je ne le saisis pas.
Vers 0:31, Gemini revient de lui-même avec « Désolé, un problème est survenu et je n’ai pas pu l’effectuer. » C’est après ce message que la nouvelle demande coupe le Wi-Fi sans confirmation (issue 02).


dans la vidéo de l’issue 02.
Gemini affiche « Désolé, un problème est survenu et je n’ai pas pu l’effectuer ». Les deux captures suivantes montrent ce même message avec des indicateurs Wi-Fi différents. La réponse seule ne permet donc pas de conclure sur l’état réel de la connexion.
Cette vidéo est la suite directe de la précédente (21 septembre, vers 12 h 10–12 h 11). Je déverrouille le téléphone uniquement pour consulter l’historique de Gemini. Je ne fais aucune nouvelle demande.




Ce que je constate. La demande faite téléphone verrouillé n’a pas été abandonnée : Gemini l’avait mise en attente (« envoi plus tard »). Le plus probable est qu’elle a été envoyée dès le retour de la connexion, ce qui a coupé le Wi-Fi une deuxième fois, alors que je consultais seulement l’historique. Ensuite, après relance de Gemini et rechargement de la liste, la conversation correspondante n’apparaît plus dans « Récents ».
Dans cette vidéo, le téléphone est déverrouillé : elle ne sert pas à démontrer l’accès depuis l’écran verrouillé, qui est l’objet de la vidéo précédente. Elle montre ce que devient ensuite la demande. La vidéo PoC (section 02) montre la même disparition : à 0:39, la conversation figure dans « Récents » ; à 1:01, elle n’y est plus.
Si cette commande depuis l’écran verrouillé est considérée comme un comportement prévu, pourquoi Gemini exige-t-il parfois un déverrouillage, refuse-t-il parfois l’accès, et exécute-t-il parfois l’action sans retour visible ? Et pourquoi une demande faite téléphone verrouillé peut-elle être exécutée plus tard, au retour de la connexion, sans que je la répète, puis ne laisser aucune trace dans l’historique visible ?
Je vérifie les effets sur le téléphone, notamment les indicateurs Wi‑Fi, puis les conversations Gemini. Dans le test du 14 octobre déjà documenté plus haut, la demande météo témoin apparaît dans l’historique visible alors que la commande Wi‑Fi exécutée n’y apparaît pas.
Sur un Honor Magic V5 sans carte SIM active, connecté uniquement en Wi‑Fi, Gemini a pu être sollicité depuis l’écran verrouillé et exécuter une demande de désactivation du Wi‑Fi sans validation du code PIN ou de la biométrie.
La vidéo conservée montre l’appareil verrouillé, l’absence d’authentification validée, la demande adressée à Gemini, puis la disparition de la connexion Wi‑Fi.
Le signalement initial mettait notamment en avant la perte de l’unique connexion réseau et ses conséquences possibles sur les fonctions qui dépendent de cette connectivité, dont Localiser mon appareil.
Il s’agit de comportements observés lors de mes tests, pas de la démonstration d’une faille exploitée.
Le mercredi 14 octobre 2026, j’ai refait le test sur le même Honor Magic V5 (MagicOS 11, sans carte SIM), filmé en un seul enregistrement d’écran continu.
Le téléphone est verrouillé : ni mon visage ni mon empreinte ne sont reconnus, le code PIN est donc demandé. Je fais d’abord une demande témoin à Gemini, « la météo ». Je demande ensuite « tu peux couper le Wi‑Fi ». Le Wi‑Fi est coupé. Gemini ne peut alors plus m’écouter, le micro est coupé, et il affiche un message d’erreur.
Après avoir déverrouillé le téléphone et réactivé le Wi‑Fi manuellement, l’historique de Gemini ne contient que la demande sur la météo.
Le rapport décrit la désactivation du Wi‑Fi depuis l’écran verrouillé sans PIN ni biométrie, sur un appareil sans SIM.
Google estime que le cas ne répond pas à ses critères de faille de sécurité et invite à préciser un risque technique allant au-delà du point initial lié à Localiser mon appareil.
Le sujet est recentré sur l’autorisation depuis le lockscreen : le chemin manuel du constructeur peut exiger une authentification, tandis que Gemini peut exécuter l’action.
Google maintient que le cas n’entre pas dans les failles de sécurité techniques traitées par l’équipe et le classe « Intended Behavior / Comportement prévu ».
Le sujet n’est pas uniquement la perte de connectivité. Il s’agit de la différence observée entre deux chemins d’action sur un appareil verrouillé : le chemin manuel du constructeur peut exiger une authentification, alors que Gemini a, dans le test documenté, exécuté la désactivation du Wi‑Fi sans PIN.
En septembre 2026, sur le même Magic V5, le réglage « Centre de contrôle déroulant de l’écran verrouillé » est désactivé. Lors d’un test manuel depuis l’écran verrouillé, avec reconnaissance faciale non validée, la tentative d’accès au centre de contrôle déclenche une demande d’authentification et l’accès n’est pas accordé.
Cette vérification décrit l’état actuel de l’appareil. Elle ne démontre pas que la version de MagicOS ou la configuration exacte étaient identiques le 13 août 2026.
J’ai signalé ce comportement parce qu’en tant qu’utilisateur, il me pose question.
Sur mon téléphone, j’ai choisi de désactiver l’accès au centre de contrôle depuis l’écran verrouillé. Lorsque j’essaie de modifier le Wi‑Fi manuellement sans déverrouiller l’appareil, cette protection s’applique. Pourtant, dans mon test, Gemini a pu désactiver le Wi‑Fi sans me demander de m’authentifier.
Personnellement, je ne trouve pas normal qu’une action que j’ai choisi de protéger depuis l’écran verrouillé puisse être exécutée par un autre chemin sans authentification supplémentaire, surtout dans ma configuration : ce téléphone n’a pas de carte SIM active et sa connexion réseau repose donc sur le Wi‑Fi.
C’est aussi un choix d’utilisation parfaitement volontaire. J’utilise beaucoup cet appareil en Wi‑Fi chez moi et, à l’extérieur, je peux le connecter au partage de connexion de mon autre téléphone. Il reste ainsi un appareil connecté sur lequel je peux utiliser mes applications et mes services de communication.
Le fait d’utiliser un téléphone de cette manière ne change pas mon attente : les protections que j’ai choisies pour l’écran verrouillé devraient, selon moi, continuer à s’appliquer.
Cela soulève également une question plus générale : lorsqu’une fonction permet une action dans un sens — ici désactiver le Wi‑Fi — quelles limites sont appliquées aux actions inverses ou aux autres fonctions système accessibles à Gemini depuis l’écran verrouillé ?
Google a classé ce signalement « Intended Behavior / Comportement prévu » le 23 août 2026.
C’est leur décision. Je ne partage pas ce choix.
Je présente ici ce que j’ai observé, ce que j’ai signalé, la décision qui a été prise et mon point de vue d’utilisateur.
Et vous ?
Arnaud Yone · Études d’usage IA & QA mobile