Détecteur de Langue IA

À propos du Détecteur de Langue IA

Notre Détecteur de Langue IA utilise l'apprentissage automatique avancé pour identifier automatiquement la langue de n'importe quel texte. Propulsé par des modèles linguistiques de pointe fonctionnant directement dans votre navigateur, il peut détecter plus de 20 langues avec une grande précision et des scores de confiance.

L'outil analyse votre texte à l'aide de l'IA et fournit non seulement la langue principale, mais aussi des possibilités alternatives avec des pourcentages de confiance. Tout fonctionne localement dans votre navigateur en utilisant Transformers.js, de sorte que votre texte reste totalement privé et ne quitte jamais votre appareil.

Ce détecteur de langue envoie-t-il mon texte à un serveur ?

Non. Le Détecteur de Langue IA s'exécute à 100% dans votre navigateur grâce à un modèle d'identification compact, statistique ou neuronal, chargé via WebAssembly. Votre texte n'est jamais téléversé, journalisé ni partagé avec un tiers — vous pouvez le vérifier en ouvrant les DevTools, en passant dans l'onglet Network et en confirmant qu'aucune requête ne part lorsque vous cliquez sur Détecter. L'outil est ainsi sûr pour des e-mails confidentiels, des brouillons fuités, des preuves juridiques ou tout contenu privé dont vous voulez seulement connaître la langue. Le modèle est téléchargé une seule fois à la première utilisation puis mis en cache local, donc les détections suivantes sont instantanées et entièrement hors ligne.

Quel modèle d'identification de langue est utilisé ?

Le backbone par défaut est une adaptation de FastText lid.176 de Facebook ou un hybride n-gramme + transformer équivalent hébergé sur Hugging Face (par ex. facebook/fasttext-language-identification ou papluca/xlm-roberta-base-language-detection). FastText lid.176 couvre 176 langues dans un modèle minuscule de 130 Mo et dépasse 95% de précision sur les textes de Wikipédia et Common Crawl. Les variantes XLM-RoBERTa couvrent environ 20 langues à haute ressource et franchissent 99% sur les entrées longues. L'outil choisit le FastText plus petit par défaut pour l'équilibre vie privée/vitesse, et affiche les 3 meilleurs candidats avec probabilités pour détecter les cas mixtes ou limites.

À quel point mon texte peut-il être court tout en restant correctement détecté ?

La précision dépend fortement de la longueur. À 5 mots ou moins, l'identification est réellement difficile — des chaînes courtes comme "hello world" ou des noms propres sont ambiguës même pour des humains. FastText lid.176 atteint environ 70% à 10 caractères, 85% à 50 et 95% au-delà de 200. Sous 20 caractères, le modèle confond souvent des parents proches comme espagnol vs portugais, norvégien vs danois ou indonésien vs malais. Pour de meilleurs résultats, collez au moins une phrase complète (50 à 100 caractères). Si votre entrée doit être courte, surveillez la liste des 3 meilleures plutôt que de croire la première — quand les deux premières probabilités se tiennent à moins de 10 points, considérez la prédiction comme incertaine.

Peut-il détecter des documents mélangeant plusieurs langues dans un même paragraphe ?

Le classifieur mono-étiquette par défaut ne renvoie que la langue dominante de toute l'entrée, ce qui est correct pour des paragraphes monolingues mais trompeur en cas d'alternance codique. Pour du texte mixte, passez en mode par phrase : l'entrée est découpée à la ponctuation et chaque phrase est détectée indépendamment. C'est en gros le fonctionnement d'outils ligne par ligne comme CLD3 (Compact Language Detector v3 de Google). La vraie détection de code-switching au niveau du jeton requiert un modèle d'étiquetage de séquence entraîné sur des corpus bilingues (LinCE, MULTI-CONER), plus lourd et non inclus par défaut. Pour du contenu bilingue généré par l'utilisateur, le mode par phrase capte la plupart des bascules.

Pourquoi se trompe-t-il parfois sur le chinois, le japonais et le coréen ?

La détection CJK est particulièrement délicate parce que les kanji japonais et les hanzi chinois partagent des milliers de caractères, et que le Hanja coréen apparaît dans les textes formels. Les heuristiques purement basées sur le caractère fonctionnent pour hiragana, katakana et hangul (uniques à chaque langue), mais un texte dominé par des caractères chinois peut être ambigu. FastText lid.176 regarde les n-grammes de caractères et les frontières de mots et atteint environ 97% par langue CJK individuelle avec assez de texte, mais une courte phrase japonaise en kanji seuls peut être confondue avec du chinois. Ajouter un seul caractère hiragana ou katakana incline résolument le modèle vers le japonais, donc les entrées plus longues sont presque toujours bien résolues.

Quelle différence entre FastText et un détecteur transformer comme XLM-RoBERTa ?

FastText représente chaque mot comme un sac de n-grammes de caractères qu'il moyenne dans un classifieur linéaire peu profond — c'est essentiellement une régression logistique sur des traits sous-mot, ce qui le garde minuscule (moins de 200 Mo) et extrêmement rapide (millions de mots par seconde sur CPU). XLM-RoBERTa est un transformer complet de 270M de paramètres pré-entraîné sur 100 langues et ajusté pour l'identification ; il est bien plus lent (environ 100x par jeton) et occupe 3 Go sur disque, mais il capte des indices contextuels que FastText rate, comme l'ordre des mots, la syntaxe et les emprunts rares. Pour la détection navigateur de paragraphes, FastText est le bon défaut — le plafond de précision sur du texte réel est déjà proche de 99% et l'économie de bande passante est énorme.

Puis-je faire tourner le détecteur avec accélération WebGPU ?

FastText lui-même ne profite pas du GPU car sa boucle interne est dominée par des recherches dans des hashtables creuses et de l'arithmétique entière, où CPU/WASM est déjà optimal. Les détecteurs à base de transformer (XLM-RoBERTa, Bert-base-multilingual) en profitent fortement — en WebGPU, détecter par lots 100 textes courts passe d'environ 8 secondes (WASM CPU) à moins d'1 seconde (GPU intégré). Transformers.js sélectionne automatiquement le backend WebGPU sur Chrome 113+ et Edge quand il est disponible, sinon il utilise WebAssembly avec SIMD. Pour la plupart des utilisateurs, FastText sur WASM est le meilleur choix ; passez à WebGPU + transformer seulement pour une précision maximale sur de longues entrées avec un navigateur récent.

Pourquoi le détecteur renvoie-t-il des codes ISO 639-1 comme "en" plutôt que "Anglais" ?

ISO 639-1 est la norme de codes à deux lettres maintenue par la Library of Congress et utilisée par à peu près tous les frameworks d'internationalisation (Content-Language HTTP, attribut lang HTML, Unicode CLDR, API locale du navigateur). C'est concis, non ambigu et adapté aux machines — "zh" est toujours le chinois, "ja" toujours le japonais, peu importe la langue d'affichage de l'application. Pour les langues sans code 639-1 (par ex. cebuano, sicilien), le modèle se rabat sur ISO 639-3 (trois lettres : "ceb", "scn"). L'outil affiche le code et le nom lisible dans la langue de votre UI. Si vous n'avez besoin que de l'étiquette humaine, la sortie JSON inclut les deux champs.