Le bureau n'a jamais eu son T9 : pourquoi, et comment les LLM pourraient y remédier

Nous rédigeons nos textes professionnels surtout sur ordinateur : courriels, documentation, tickets, code, commentaires de code. Pourtant, la correction automatique intelligente est restée sur le téléphone. Là-bas, le mot est réparé pendant la frappe, alors que sur PC l'utilisateur trouve une ligne ondulée rouge et un menu contextuel au clic droit.

L'écart est visible depuis que les smartphones ont reçu des claviers tactiles, soit depuis plus d'une quinzaine d'années. Une analyse récente sur Habr revient sur la question : pourquoi le bureau n'a pas appris davantage, et peut-on y remédier avec des LLM. Nous examinons ci-dessous les causes et ce que les modèles de langage changent réellement.

La publication d'origine en RSS ne donne qu'un chapeau ; ce qui suit s'appuie donc sur l'architecture de saisie bien connue et sur l'état du marché.

Pourquoi le téléphone a la correction automatique et pas le PC

Sur un smartphone, le clavier est une application. Il voit les coordonnées de chaque toucher, la probabilité de toucher les touches voisines et le contexte de la phrase saisie. La correction automatique 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 du propriétaire.

Sur le poste de bureau, le tableau est 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 pas de 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 selon chaque OS, et cela casse souvent dans les champs protégés.

Vient aussi la question de la confiance. Un programme qui lit tout ce qui est tapé 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

La correction automatique classique repose sur un dictionnaire et des statistiques de n-grammes. Elle corrige bien les fautes de frappe dans un mot, mais comprend mal le contexte : elle ne distingue pas « ложить » de « класть » (deux formes russes) d'après le sens de la phrase et trébuche 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 la correction automatique d'iOS à un modèle de type transformeur, et macOS propose désormais des suggestions de suite intégrées. Les grands acteurs sont donc prêts à l'amener sur le bureau, même s'ils le font pour l'instant avec prudence et surtout pour un nombre limité de langues.

Le changement principal tient à la taille. Des 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 portable sans cloud. Cela lève une partie du problème de confidentialité : le texte ne quitte pas la machine. Restent la latence et les ressources.

Les repères pour un tel outil se présentent ainsi :

• 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, quantifié ;
• fonctionnement hors ligne, sans envoi de texte à un serveur ;
• prise en charge du russe, avec ses cas et son ordre des mots libre, où les modèles faibles se trompent davantage ;
• réglage d'exceptions pour les mots de passe, le terminal et le code.

Que faire en pratique

Si vous avez besoin dès maintenant d'une correction intelligente sur PC, trois voies sont praticables. Première : utiliser la vérification orthographique et stylistique du navigateur et des suites bureautiques. Elle ne remplace pas le T9, mais couvre une partie des besoins. Deuxième : 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 : si vous développez de tels produits, commencez par des scénarios étroits, comme 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 ne touche pas. Et comment il se comporte en russe, pas seulement en anglais. Le T9 de bureau reste une niche, mais les obstacles techniques sont nettement moins nombreux qu'il y a quelques années.