Dossier · document 3
Comment l'application est faite, comment son dictionnaire est fabriqué à partir des jeux du ZLS, et comment les chiffres de qualité sont obtenus. Y compris ce qui n'est pas mesuré et devrait l'être.
Document public · septembre 2026 · version 11.6.0 de l'application
| Nature | Un Input Method Editor Android, c'est-à-dire le composant système qui remplace le clavier, plus un service de correction orthographique déclaré séparément |
| Langage | Kotlin, sans dépendance externe pour le moteur |
| Compatibilité | Android 5.0 (API 21) à Android 16 (API 36) |
| Taille | Environ 7,7 Mo installés, dont 16,6 Mo de données compressées à 7 Mo |
| Réseau | Aucune permission réseau déclarée. L'application fonctionne en mode avion |
| Tests | 209 tests unitaires exécutés à chaque intégration, dont plusieurs lisent les fichiers de données réellement livrés |
Rien n'est saisi à la main. Chaque fichier de données est produit par un script versionné, à partir de sources publiques identifiées, et l'intégration continue le régénère à chaque livraison.
Les jeux du ZLS sur data.public.lu, plus deux corpus universitaires. Les URL ne sont pas codées en dur : les scripts demandent à l'API de data.public.lu la ressource la plus récente, parce que le ZLS republie chaque trimestre sous un chemin horodaté.
Six programmes Python découpent, comptent, élisent la casse de chaque forme, construisent les n-grammes et écrivent directement dans les données de l'application, avec des sauvegardes horodatées.
L'intégration continue refuse de construire l'application si un fichier tombe sous un seuil de volume, change de forme, ou perd son attribution. Une régression silencieuse des données est le risque principal de ce genre de projet.
Le moteur essaie cinq voies, dans cet ordre, et s'arrête à la première qui donne un résultat :
Une décision de conception qui mérite d'être signalée : la barre reste vide quand le modèle ne sait pas. Mesuré sur le corpus, quand le contexte est reconnu le mot juste figure dans les trois premières suggestions 18,6 % du temps. Quand il ne l'est pas, les stratégies de repli plafonnent à 2 à 4 %. Des suggestions justes une fois sur vingt-cinq, habillées exactement comme celles qui sont justes une fois sur cinq, coûtent plus qu'une barre éteinte. Le clavier se tait donc 12 % du temps, et c'est un choix, pas une panne.
C'est la partie la plus facile à truquer dans ce genre de projet, et donc celle qu'il faut exposer le plus complètement.
Une part de corpus mise de côté vient des mêmes articles, de la même période et du même registre que ce qui reste à l'entraînement : elle flatte le modèle. Mesurée, elle annonce 23,9 % là où un jeu réellement indépendant donne 18,1 %. Cinq points d'écart, entièrement artificiels.
Le Méisproochegen Iwwersetzungskorpus du ZLS, dont le recouvrement avec les corpus d'entraînement n'est que de 6,84 %. Restent 10 038 segments inédits, soit 135 343 événements de frappe, contre 2 703 pour le seul autre jeu indépendant disponible. Le bruit statistique passe de ±0,8 point à ±0,1.
Ce corpus n'est jamais versé à l'entraînement, et c'est un arbitrage assumé : l'y ajouter ferait gagner environ 0,1 point de qualité et détruirait le seul jeu de contrôle honnête du projet.
| Mesure | Valeur | Définition |
|---|---|---|
| Couverture lexicale | 93,6 % | Part des mots du texte que le clavier connaît |
| Contexte reconnu | 87,8 % | Part des frappes pour lesquelles le modèle a une proposition |
| Mot juste dans les trois premiers | 18,1 % | Part des frappes remplaçables par un appui sur une suggestion |
La comparaison est faite casse repliée des deux côtés. Le script d'évaluation lit les fichiers embarqués dans l'application, pas une version de travail : le chiffre publié est celui que les utilisateurs obtiennent.
Puisque la question se posera (voir la page licences), elle a été tranchée par la mesure plutôt que par l'intuition. Un clavier entraîné uniquement sur les jeux du ZLS a été construit avec les mêmes seuils et évalué sur le même jeu de contrôle.
| Mesure | Version livrée | Variante CC0 |
|---|---|---|
| Formes du dictionnaire | 37 761 | 12 472 |
| Contextes de prédiction | 27 746 | 3 672 |
| Couverture lexicale | 93,6 % | 86,3 % |
| Contexte reconnu | 87,8 % | 73,9 % |
| Mot juste dans les trois premiers | 18,1 % | 14,0 % |
Le coût ressenti n'est pas le taux de réussite mais le silence : la barre resterait vide 26 % du temps au lieu de 12 %, soit deux fois plus souvent. Ce qui disparaîtrait du dictionnaire est identifiable : 15 % des occurrences, essentiellement des noms propres, des sigles (RTL, CSV, OGBL) et des variantes orthographiques que le LOD ne lemmatise pas (dass, tëscht, iwwert, mä).
À noter : la reconnaissance des mots et le correcteur orthographique ne seraient pas affectés, puisqu'ils reposent déjà entièrement sur le LOD, en CC0.
Un dossier qui ne signale aucune limite n'est pas crédible. Trois choses manquent, et aucune ne se règle sans utilisateurs :
Le code, les scripts de fabrication des données, les tests et la configuration d'intégration continue sont publics sur GitHub. Les mesures de cette page sont reproduites par un script du dépôt, qui lit les données embarquées et réécrit les chiffres publiés sur ce site.
La page Les corpus en chiffres présente le détail des sources, leur composition et leur recouvrement.