L'IA de Google ne sait pas épeler son propre nom : voici pourquoi cela ne sera pas corrigé de sitôt

Fin mai 2026, des utilisateurs ont découvert que la fonctionnalité AI Overview de Google commettait le genre de fautes d'orthographe que la plupart des humains ne font plus après le CP. Lorsqu'on lui demandait "Combien de 'p' y a-t-il dans le mot Google ?", l'IA répondait avec assurance "deux" (il n'y en a qu'un). Elle affirmait également que le mot "journalism" contenait deux 'd' et l'épelait "j-o-u-r-n-a-d-i-s-m" . Google a reconnu les erreurs un jour plus tard, déclarant que "compter à l'intérieur des mots est un défi connu pour les LLM, et nous travaillons à corriger ce problème particulier" .

Ces erreurs ne sont pas de simples bugs aléatoires. Elles résultent de la manière même dont tous les grands modèles de langage (LLM) traitent le texte — et révèlent un angle mort qui ne sera probablement pas corrigé de sitôt.

Le problème de la tokénisation : pourquoi les LLM ne lisent pas les lettres

Un humain perçoit un mot comme une séquence de lettres individuelles. Un LLM fonctionne de manière fondamentalement différente : il décompose le texte en tokens — des fragments qui peuvent être des mots entiers, des bouts de mots ou, parfois, des caractères isolés. Cette décomposition dépend d'un vocabulaire prédéfini, construit par un algorithme comme le Byte Pair Encoding (BPE) .

Ainsi, le mot "Google" pourrait être encodé en un seul token ["Google"], ou en deux tokens comme

["Go", "ogle"]

["G", "o", "o", "g", "l", "e"]

Cela crée deux problèmes qui se combinent :

D'abord, la couche d'embedding n'encode pas entièrement l'information au niveau du caractère. Les recherches montrent que ces couches stockent une information précise uniquement pour le premier caractère de chaque token ; au-delà, le niveau de détail se dégrade rapidement . Lorsqu'un modèle doit compter des lettres dans un token, il doit reconstruire la séquence à partir d'une représentation qui n'a jamais été conçue pour la conserver.

Ensuite, les tokéniseurs sont "largement aveugles à la structure interne des tokens". Une étude de 2024 sur Arxiv a inventé l'expression "la malédiction de la tokénisation" pour décrire cette vulnérabilité : les tokéniseurs sont intrinsèquement sensibles aux fautes de frappe et aux variations de longueur, et ignorent la composition interne des tokens eux-mêmes . Un mot comme "journalism" peut n'être qu'un seul token — le modèle n'a jamais appris à le décomposer en j-o-u-r-n-a-l-i-s-m. Alors, quand on lui demande de l'épeler, il devine.

Le résultat est ce que les utilisateurs ont vu avec l'AI Overview de Google : une IA capable de débattre de philosophie et d'écrire du code soutient avec assurance qu'il y a deux 'p' dans "Google" et exactement un 'r' dans "poop" .

Pourquoi est-il si difficile de résoudre ce problème ?

Si le problème vient de la tokénisation, la solution intuitive serait d'utiliser des modèles au niveau du caractère, qui « voient » chaque lettre. Cette approche existe — des modèles comme ByT5 opèrent directement sur des octets bruts — mais elle n'a pas été largement adoptée car elle rend l'exécution des modèles bien plus coûteuse .

Passer à un traitement caractère par caractère fait exploser la longueur des séquences d'un facteur estimé de 3 à 5 fois, ce qui augmente d'autant les coûts de calcul et rend beaucoup plus difficile pour le modèle l'apprentissage de dépendances à longue distance . Les tokéniseurs de sous-mots sont le compromis qui a rendu les LLM modernes viables : ils compressent le texte en vocabulaires de taille raisonnable tout en conservant suffisamment de sens pour une génération de texte fluide.

Les chercheurs s'accordent largement à dire qu'un tokenizer « parfait » n'existe probablement pas . Les tokéniseurs « produisent régulièrement des encodages non uniques » et créent un « décalage de représentation » qui est profondément architectural — pas un simple bug à corriger . Le compromis entre précision au niveau du caractère et fluidité sémantique semble fondamental à l'architecture des transformers.

Ce que ces erreurs révèlent sur les LLM

Les échecs en orthographe mettent en lumière plusieurs limites structurelles qui vont bien au-delà de l'AI Overview de Google.

Les LLM sont des machines à motifs, pas à manipulation de symboles. Compter des lettres est une tâche algorithmique triviale pour un ordinateur classique, mais les LLM n'exécutent pas d'algorithmes — ils prédisent le token suivant le plus probable en se basant sur des motifs statistiques présents dans leurs données d'entraînement . Lorsqu'on leur demande un compte de lettres, le modèle génère une réponse qui « sonne » probable, pas le résultat d'un comptage.

La confiance n'a aucun lien avec l'exactitude. L'IA a proposé "deux" avec une aisance grammaticale parfaite tout en étant objectivement fausse. C'est une marque de fabrique des « hallucinations » des LLM : des réponses confiantes et plausibles sans mécanisme de vérification interne. Google lui-même a reconnu en 2024 que si les AI Overviews "sont conçues pour n'afficher que des informations étayées par les meilleurs résultats web", elles peuvent encore mal interpréter les requêtes ou certaines nuances de langage .

L'angle mort est architectural, pas accidentel. Tous les grands LLM utilisant la tokénisation en sous-mots — y compris ceux d'OpenAI, Anthropic et Meta — présentent des faiblesses similaires sur les tâches au niveau du caractère, comme épeler un mot à l'envers, compter les lettres ou gérer les anagrammes . Augmenter la taille des modèles aide un peu, mais le biais persiste .

Pourquoi l'industrie ne considère pas cela comme une urgence

Ces échecs peuvent sembler embarrassants — une IA incapable d'épeler le nom de son entreprise —, mais l'industrie ne les traite pas comme une crise car la valeur inestimable des LLM est ailleurs.

La génération de texte fluide, le résumé, le raisonnement, la traduction, l'écriture de code — toutes ces capacités proviennent de l'aptitude du modèle à travailler au niveau sémantique, où l'abstraction par tokens est un avantage, pas un bug . La précision au niveau du caractère n'est tout simplement pas ce pour quoi ces architectures ont été conçues.

La solution pratique consiste à rediriger les questions d'orthographe et de comptage vers des logiciels traditionnels basés sur des règles, plutôt que de demander au LLM de les traiter. Plusieurs implémentations d'AI Overview tentent déjà de détecter et de déléguer ces requêtes, bien que les erreurs très visibles de mai 2026 montrent que cette détection reste imparfaite . Une étude distincte a révélé que l'AI Overview de Google répond de manière incorrecte aux demandes d'orthographe inversée dans 52 % des cas — et seuls 10 % des mots de trois syllabes ou plus ont été correctement inversés .

Google travaille à des correctifs pour les problèmes de comptage spécifiques qui ont été rendus publics . Mais pour quiconque comprend le compromis de la tokénisation, la vraie leçon n'est pas que Google a livré un produit buggé. C'est que l'architecture qui alimente la révolution de l'IA a un angle mort fondamental — et que personne n'a trouvé le moyen de le corriger sans sacrifier ce qui rend les LLM si précieux.