Les claviers IA sont-ils sûrs ? Ce que votre clavier de téléphone voit

La plupart des claviers IA sont sûrs par défaut — et c'est le mot « défaut » qui fait tout le travail. Sur iOS, Apple exécute un clavier tiers dans un bac à sable isolé, sans aucun accès réseau. Sa documentation développeur est explicite. Sans Full Access, vos frappes vont uniquement vers l'app dans laquelle vous écrivez. Activez « Allow Full Access », et cette garantie tombe. Le clavier peut alors envoyer vos frappes vers un serveur. C'est exactement comme ça que fonctionne l'aide à l'écriture par IA dans le cloud. C'est aussi comme ça qu'un clavier nommé ai.type a exposé les données d'environ 31 millions d'utilisateurs en 2017. La règle tient en une phrase : sachez si l'interrupteur est actif, et pourquoi.

Un clavier voit chaque frappe — c'est sa fonction

Un clavier est l'app la plus privilégiée de votre téléphone. Ce n'est pas un défaut de conception. C'est le métier. Chaque message passe par lui. Chaque recherche aussi. Chaque champ de mot de passe. Chaque note tapée dans une app bancaire. Rien d'autre sur l'appareil n'occupe cette position.

La bonne question n'est donc jamais « est-ce que le clavier voit mon texte ». Il le voit, toujours. La vraie question est ailleurs. Peut-il envoyer ce texte quelque part ? Sur iOS, la réponse dépend d'un seul interrupteur.

« Allow Full Access » : l'interrupteur qui change tout

La documentation développeur d'Apple décrit le comportement par défaut sans ambiguïté. Un clavier personnalisé tourne dans un processus isolé, en bac à sable. Sa configuration par défaut bloque totalement l'accès réseau. Apple précise que les frappes vont alors uniquement vers l'app en cours de saisie. Elles ne peuvent pas repartir vers le serveur du développeur. Le clavier garde un lexique de mots courants pour la correction et les suggestions. Il n'a pas le micro. Il n'a pas le système de fichiers au-delà de son propre conteneur.

« Allow Full Access » est le réglage qui supprime cette garantie. Il se trouve dans les Réglages de l'iPhone. Le développeur, lui, l'active côté code via un indicateur nommé RequestsOpenAccess. Une fois que vous cochez, le clavier gagne de vrais pouvoirs.

• Il peut envoyer vos frappes et d'autres événements de saisie vers un serveur, pour traitement.
• Il peut atteindre la localisation et vos contacts, avec votre autorisation.
• Il partage un conteneur avec son app parente.
• En clair : vos frappes deviennent accessibles au développeur du clavier.

Cloud ou sur l'appareil : c'est là que l'IA change la donne

L'IA embarquée traite votre texte sur le téléphone. Rien n'est transmis. L'IA dans le cloud, c'est autre chose. Votre texte part vers un serveur, se fait traiter, puis revient. Ce trajet, c'est tout le risque. Il n'existe pas dans le premier cas.

Apple nomme l'attente des utilisateurs très clairement. Les gens veulent que leurs frappes arrivent dans le champ où ils écrivent. Pas sur un serveur. Pas dans une archive. Quand un clavier envoie bien des frappes à un serveur, Apple demande aux développeurs de ne pas les conserver. Le temps de renvoyer le texte, ou de livrer une fonction annoncée à l'utilisateur, et rien de plus.

Cette surface de transmission n'a rien de théorique. Le Citizen Lab a étudié en 2024 des claviers pinyin cloud de neuf fournisseurs. Huit sur neuf présentaient des failles permettant à un espion réseau de reconstituer les frappes. Un seul fournisseur utilisait correctement TLS, le chiffrement du transport. Les chercheurs estimaient jusqu'à un milliard d'utilisateurs potentiellement concernés. Leur conseil aux utilisateurs était direct : envisager un clavier qui fonctionne entièrement sur l'appareil.

Attention à la portée de cette étude. Elle visait une famille précise de claviers, pas le marché entier. La leçon voyage quand même. Le traitement dans le cloud crée une surface d'exposition que le traitement local n'a pas.

Et les champs de mot de passe ? La croyance à corriger

On lit souvent que les claviers sont interdits d'accès aux champs de mot de passe. Méfiez-vous de cette idée. La documentation développeur d'Android dit l'inverse. Un IME (input method editor, le nom technique du clavier sur Android) reçoit bien les champs de mot de passe. Google documente la variante de champ que l'IME doit gérer. Il demande aux développeurs de masquer le mot de passe dans la vue de saisie et dans les suggestions. Il leur demande aussi de ne pas stocker les mots de passe sur l'appareil. Ce sont des règles de conduite, pas un mur.

Android le dit d'ailleurs à voix haute. Quand vous activez un clavier tiers, le système vous prévient. Il vous annonce que la méthode de saisie peut collecter tout le texte que vous tapez. Il cite les données personnelles comme les mots de passe et les numéros de carte bancaire. Côté iOS, la garantie vérifiable d'Apple porte sur la permission, pas sur le type de champ. Fiez-vous donc à la frontière que vous pouvez contrôler. Cette frontière s'appelle Full Access.

ai.type, 2017 : ce qu'un clavier peut laisser fuir

L'histoire nous offre une illustration très nette. En décembre 2017, des chercheurs du Kromtech Security Center trouvent une base de données grande ouverte. Elle appartient à ai.type, un clavier tiers alors très populaire. Aucun mot de passe ne la protège. N'importe qui la trouvant pouvait la lire.

Deux détails méritent l'attention. La liste des apps installées incluait des applications bancaires et de rencontres. Et la presse a noté que la version sans abonnement collectait plus de données que la version payante, au service de la publicité ciblée. Des articles de l'époque décrivaient aussi une table de textes saisis. Nous nous en tenons aux chiffres que nous avons pu confirmer.

Côté droit européen, il n'y a aucune zone grise. Le RGPD définit la donnée personnelle à son article 4(1). Cela couvre toute information se rapportant à une personne identifiée ou identifiable. Le texte cite les données de localisation et les identifiants en ligne parmi ces identifiants. Le considérant 30 ajoute que les appareils et les applications fournissent leurs propres identifiants. Combinés à d'autres informations arrivant sur un serveur, ils permettent de profiler et d'identifier une personne. Le dump ai.type, c'est exactement ce scénario.

Un cadrage honnête s'impose. ai.type date de 2017 et ce n'est pas une actualité. Voyez-y une démonstration du risque structurel, pas un verdict sur un clavier vendu aujourd'hui.

Les bons réflexes, en six gestes

La marche à suivre est courte. Et elle a un mérite rare : les éditeurs de systèmes la recommandent eux-mêmes.

1. 1Privilégiez le clavier intégré de votre téléphone. C'est le réglage par défaut, et ce n'est pas un hasard.
2. 2Sur iOS, ouvrez Réglages > Général > Clavier. Regardez si « Allow Full Access » est actif, et demandez-vous ce qu'il vous apporte.
3. 3Préférez un clavier qui traite le texte sur l'appareil. C'est la recommandation du Citizen Lab lui-même.
4. 4Lisez la politique de confidentialité du clavier avant de lui faire confiance. Cherchez ce qui quitte le téléphone.
5. 5Ne tapez jamais de secrets dans un clavier auquel vous ne faites pas confiance : mots de passe, numéros de carte, codes de récupération.
6. 6Sur un téléphone partagé ou professionnel, restez sur le clavier d'origine.

Le clavier est la version la plus pure du problème qu'ONYRI Sanitize adresse : du texte quitte l'appareil pour être traité par un modèle. L'architecture d'Apple plaide déjà pour nous. Pas de réseau par défaut, et une permission que vous devez accorder en conscience. ONYRI Sanitize préserve cette frontière quand vous utilisez malgré tout un modèle dans le cloud. Le moteur détecte les données sensibles dans votre navigateur et les remplace par des jetons réversibles. Seul un texte anonymisé atteint le modèle. Le mapping ne quitte jamais votre machine. Vous obtenez l'aide de l'IA, et vos secrets restent les vôtres.