Un système de vérification de noms échoue silencieusement lorsqu'il compare des chaînes écrites dans des scriptes différents, comme « Владимир Путин » contre « Vladimir Putin ». Les méthodes classiques telles que la distance d'édition, les codes phonétiques ou BM25 sont inefficaces car elles reposent sur des caractères communs ou des hypothèses basées sur l'alphabet latin. Ce problème affecte quotidiennement les bases de données migratoires, les dossiers médicaux et les pipelines de conformité financière. Une nouvelle approche résout ce défi en entraînant un transformateur compact directement sur des octets UTF-8 bruts, sans tokenisation préalable ni détection de scripte. L'équipe a obtenu un taux de rappel moyen (MRR) de 0,775 et un taux de rappel à 10 (R@10) de 0,897 sur huit scriptes non latins, réduisant l'écart de performance entre les requêtes latines et non latines par un facteur de dix par rapport aux meilleures solutions traditionnelles. La difficulté majeure réside dans l'incompatibilité des ensembles de symboles et l'absence de contexte sémantique pour les noms propres. La romanisation n'est pas une fonction univoque ; un seul caractère chinois ou coréen peut avoir plusieurs transcriptions phonétiques valides. L'équipe a construit un jeu de données massif de 4,67 millions de paires positives en quatre étapes. Après un échantillonnage stratifié de 2 millions d'entités depuis Wikidata, un modèle de langage a généré des variantes phonétiques en latin, avant que des modèles de traduction n'aient créé des translittérations en arabe, russe, chinois, japonais, hébreu, hindi, grec et coréen. Le modèle utilisé est un encodeur à six couches avec environ quatre millions de paramètres. Il traite les données comme une séquence d'octets bruts. Cette approche élimine le problème des termes hors vocabulaire et offre un alphabet universel de 256 symboles. L'entraînement utilise une perte InfoNCE couplée à une méthode d'extraction de contre-exemples difficiles (hard negatives) via ANCE. Cette technique reconstruit périodiquement une indexation pour identifier et intégrer des noms phonétiquement proches mais désignant des personnes différentes, ce qui affine la précision du modèle. Les résultats montrent que le modèle surpasse largement les systèmes classiques, qui échouent souvent sur les requêtes trans-scriptes. L'écart de performance entre les scriptes latins et non latins est passé de 0,94 à 0,096. Bien que le modèle excelle sur les scripts ayant des conventions de romanisation stables comme l'arabe ou le russe, il présente des limites sur le chinois et le coréen. Cette difficulté s'explique par l'ambiguïté intrinsèque de la romanisation dans ces langues et par le fait que les données d'entraînement ne couvrent pas la variation orthographique interne des scriptes cibles. De plus, la quasi-totalité des paires d'entraînement étant générées par des IA, il existe un risque de biais systémique non détecté par les données de référence restantes. Pour le déploiement, l'indexation HNSW est recommandée car elle offre une latence cinq fois inférieure à la recherche exacte sans perte de rappel significative. Les auteurs concluent que la tokenisation au niveau des octets est un outil sous-utilisé pour les tâches multilingues et que les modèles de langage constituent une engine de données viable pour la correspondance d'entités à ressources limitées. Les données du projet et le code source sont disponibles publiquement.