Le desktop sans T9 : pourquoi, et comment les LLM pourraient y remédier

Nous écrivons l'essentiel de nos textes de travail sur ordinateur : e-mails, documentation, tickets, code, commentaires de code. Pourtant, l'autocorrection intelligente est restée sur le téléphone. Là-bas, le mot est réparé pendant la frappe ; sur PC, l'utilisateur doit se contenter d'une ligne ondulée rouge et d'un menu contextuel accessible par clic droit.

Cet écart existe depuis que les smartphones ont reçu des claviers tactiles, soit plus de quinze ans. Une analyse récente publiée sur Habr remet la question sur la table : pourquoi le desktop n'a-t-il pas fait mieux, et peut-on y remédier avec des LLM ? Nous détaillons ci-dessous les causes et ce que les modèles de langage changent réellement.

Le flux RSS de la publication originale ne contient qu'un chapô ; la suite s'appuie donc sur l'architecture de saisie, bien connue, et sur l'état du marché.

Pourquoi le téléphone a eu l'autocorrection, et pas le PC

Sur un smartphone, le clavier est une application. Il connaît les coordonnées de chaque toucher, la probabilité d'avoir touché les touches voisines et le contexte de la phrase saisie. L'autocorrection y est une nécessité : le doigt est plus gros que la touche, et sans elle, écrire est impossible. Le développeur du clavier contrôle toute la couche de saisie. Il peut donc substituer des mots, modifier les précédents et apprendre des habitudes de l'utilisateur.

Sur desktop, c'est l'inverse. Le clavier physique est plus précis, les erreurs sont généralement moins nombreuses et le besoin n'est pas criant. De plus, le texte atterrit dans des navigateurs, des IDE, des messageries, des terminaux et des suites bureautiques, chacun avec son propre moteur de texte. Il n'existe aucun point unique où intercepter la saisie et modifier proprement un mot. Il faut passer par les API d'accessibilité ou par des hooks au niveau du système. C'est fragile, différent d'un OS à l'autre, et cela échoue souvent dans les champs protégés.

Vient aussi la question de la confiance. Un programme qui lit tout ce que l'on tape ressemble par définition à un keylogger. Pour des données professionnelles, c'est un obstacle sérieux : juristes et équipes de sécurité interdiront volontiers un tel outil.

Ce que changent les modèles de langage

L'autocorrection classique repose sur un dictionnaire et sur des statistiques de n-grammes. Elle corrige bien les fautes de frappe à l'intérieur d'un mot, mais comprend mal le contexte : elle ne distingue pas « ложить » de « класть » d'après le sens de la phrase et bute sur le jargon professionnel. Un modèle de langage examine la phrase entière et évalue quel mot convient. Apple a déjà fait passer l'autocorrection d'iOS à un modèle de type transformer, et macOS a reçu des suggestions de continuation intégrées. Les grands acteurs sont donc prêts à amener cela sur desktop, même s'ils avancent pour l'instant avec prudence et surtout pour un nombre limité de langues.

Le principal changement tient à la taille. Les modèles de quelques milliards de paramètres, par exemple de la classe Phi-3-mini avec 3,8 milliards, tournent déjà sur un ordinateur portable sans cloud. Cela résout une partie du problème de confidentialité : le texte ne quitte pas la machine. Restent la latence et les ressources.

Voici les repères pour un tel outil :

• latence de la suggestion : de l'ordre de 100 ms, faute de quoi elle prend du retard sur la frappe ;
• taille du modèle : de quelques centaines de millions à quelques milliards de paramètres, en version quantifiée ;
• fonctionnement hors ligne, sans envoi du texte à un serveur ;
• prise en charge du russe, avec ses cas et son ordre des mots libre, où les modèles faibles se trompent plus souvent ;
• configuration d'exceptions pour les mots de passe, le terminal et le code.

Que faire concrètement

Si vous voulez dès maintenant une correction intelligente sur PC, trois voies sont praticables. Première option : utiliser la vérification d'orthographe et de style du navigateur et des suites bureautiques. Elle ne remplace pas le T9, mais couvre une partie des besoins. Deuxième option : installer un outil local fondé sur un petit modèle et le tester sur vos propres textes, en surveillant la latence et son comportement dans l'IDE et le terminal. Troisième option : si vous développez ce type de produits, commencez par des scénarios ciblés, par exemple la correction dans une seule application ou un seul champ, et ne passez qu'ensuite au niveau du système.

Quel que soit votre choix, vérifiez trois points. Où le texte est traité : en local ou dans le cloud. Quelles applications l'outil laisse intactes. Et comment il se comporte en russe, pas seulement en anglais. Le T9 sur desktop reste pour l'instant une niche, mais les obstacles techniques sont nettement moins nombreux qu'il y a quelques années.