globalize rejoint le Nimdzi Language Technology Radar

Nimdzi a vérifié globalize.now et l’a référencé sur son Language Technology Radar, le catalogue de produits de technologie linguistique du cabinet d’analyse. globalize.now est une infrastructure de localisation propulsée par l’IA, et Nimdzi la classe à deux endroits : la localisation pour développeurs et les outils LLM dédiés à la localisation. Cet article présente ce qu’est le Radar, la place de globalize dans celui-ci et pourquoi la localisation native au code est devenue une catégorie à part entière.

Qu’est-ce que le Nimdzi Language Technology Radar ?

Le Radar est une base de données vivante de technologies linguistiques, tenue par Nimdzi Insights. Il a remplacé l’ancien Language Technology Atlas, un état des lieux annuel du marché, par un catalogue mis à jour en continu. L’édition 2026 recense plus de 1 100 produits issus de 756 entreprises.

Les produits sont regroupés en onze catégories, des systèmes de gestion de la traduction et de la traduction automatique à la reconnaissance vocale et aux systèmes d’interprétation. Plusieurs catégories comptent des sous-catégories, et un produit apparaît là où s’inscrit son offre principale, pas partout où l’une de ses fonctionnalités pourrait s’étendre.

Comment un outil est-il vérifié ?

Une entreprise soumet ses données, et les chercheurs de Nimdzi les vérifient à partir d’informations publiques, d’échanges avec l’éditeur et de leur propre utilisation des outils. Le référencement est gratuit. Nimdzi affirme n’accepter aucune commission pour influencer les listings, les classements ou les avis, ce qui donne du poids à un référencement auprès des acheteurs.

Pour globalize, cela a signifié une série de questions de l’équipe du Radar avant que le profil ne soit marqué comme complet. Sur quels modèles et moteurs tourne la traduction. Si les contrôles qualité fonctionnent en dehors de la plateforme. Comment les corrections sont reprises dans les traductions futures. Les catégories reflètent ces réponses, pas une autodescription.

Où se situe globalize sur le Radar ?

globalize apparaît dans deux catégories.

Systèmes de gestion de la traduction, localisation pour développeurs. Cette sous-catégorie regroupe les outils conçus pour les équipes d’ingénierie plutôt que pour les équipes de traducteurs. La différence tient à l’endroit où le travail se fait. Un TMS classique est un espace de travail distinct, dans lequel les chaînes sont synchronisées dans les deux sens. globalize travaille dans le repo : le résultat est une pull request avec des fichiers de locales, pas un export depuis un dashboard.

Grands modèles de langage, outils LLM dédiés à la localisation. globalize utilise des modèles de langage pour la traduction et pour une seconde passe de revue qui vérifie le sens, les placeholders, les termes du glossaire et le respect du guide de style dans chaque langue. Cette catégorie réunit les outils où le modèle est appliqué spécifiquement au travail de localisation, pas à un chat généraliste.

Vous pouvez consulter le profil sur le site de Nimdzi.

Pourquoi la localisation pour développeurs est-elle une catégorie à part ?

Parce que les personnes qui livrent les chaînes ont changé. Il y a quelques années, une équipe produit confiait ses textes à un responsable localisation, qui les passait dans un TMS et rendait des fichiers. Aujourd’hui, un fondateur solo livre un mardi une app Next.js construite avec Cursor ou Lovable et la veut en japonais pour vendredi. Il n’y a pas de responsable localisation, et personne ne veut d’un dashboard de plus à garder synchronisé.

Ce changement crée un besoin différent.

classic TMS:  code  →  export strings  →  TMS workspace  →  translators  →  import files  →  code
globalize:    code  →  push  →  translated pull request  →  merge

Côté développement, le besoin se décompose en deux parties. D’abord, la codebase doit être prête pour la localisation, ce qui est rarement le cas des apps générées par IA. Elles arrivent avec des chaînes codées en dur dans les composants, sans clés ni fichiers de locales. globalize s’en charge une fois pour toutes dans l’app, lorsque vous connectez le dépôt. Ensuite, chaque modification ultérieure doit être traduite sans que personne ait à y penser. Après la configuration, chaque push contenant du texte nouveau ou modifié revient sous forme de pull request avec les traductions, relues par la passe IA et prêtes à être fusionnées.

globalize est-il donc un TMS ?

Non, même si Nimdzi classe la sous-catégorie pour développeurs sous sa rubrique TMS. globalize se place entre votre bibliothèque i18n et votre moteur de traduction. Des bibliothèques comme next-intl et i18next servent les traductions au runtime, et globalize continue de fonctionner avec celle que vous utilisez déjà. Les systèmes de gestion de la traduction comme Lokalise et Crowdin gèrent les workflows de traducteurs. globalize produit et maintient les clés et les fichiers de locales : une équipe sans traducteurs n’a donc aucun besoin de cette couche de workflow. Si vous comparez les deux approches, la comparaison avec Lokalise détaille les différences.

Que fait concrètement globalize dans un repo ?

Il se connecte à GitHub ou GitLab, analyse le repo et met en place l’i18n si l’app en a besoin, en poussant la modification sur une branche que vous relisez. Si l’app utilise déjà next-intl, react-i18next, i18next ou Lingui, il conserve cette configuration et se contente de traduire.

À partir de là, trois événements déclenchent un job de traduction, tous configurables par vos soins.

1. Un push contenant du texte nouveau ou modifié sur une branche surveillée.
2. Une pull request, si vous activez cette option.
3. Un job manuel depuis le dashboard.

Chaque job ne traduit que ce qui est nouveau ou modifié. Les chaînes déjà présentes dans la mémoire de traduction sont réutilisées et ne sont pas refacturées. Votre glossaire et vos guides de style par langue s’appliquent à chaque job, et la passe de revue signale tout ce qui nécessite un humain avant d’atteindre votre branche par défaut. Le résultat arrive sous forme de pull request qui ne touche que vos fichiers de locales.

Les formats couvrent le web et le mobile, notamment JSON, gettext PO, XLIFF, YAML, ARB pour Flutter, les catalogues de chaînes Apple et les ressources de chaînes Android. La tarification est par espace de travail, sans frais par utilisateur ; la page des tarifs détaille les offres en vigueur.

Pourquoi un référencement par un cabinet d’analyse compte-t-il pour un développeur ?

Pour la plupart des développeurs, cela ne change pas grand-chose. Vous jugerez globalize sur la première pull request, et l’essai gratuit est là pour ça. Le référencement compte surtout pour deux autres profils.

Le premier : les équipes qui ont un responsable localisation. Un responsable localisation qui évalue des outils lit Nimdzi, et un profil indépendant et vérifié lui indique que le produit existe, fonctionne comme décrit et se range dans une catégorie qu’il connaît. La discussion est plus courte qu’après une démo à froid.

Le second : les acheteurs qui quittent un TMS classique. Les équipes qui abandonnent Lokalise ou Phrase pour une approche native au code veulent s’assurer que l’alternative est réelle avant de migrer un catalogue en production. Un référencement sur le Radar est l’un des rares signaux de ce marché que l’éditeur ne peut pas rédiger lui-même.

Et ensuite ?

Nimdzi propose aussi un TMS Feature Explorer, un profil fonctionnalité par fonctionnalité pour chaque outil, et la fiche globalize est en cours. Une fois en ligne, elle montrera, point par point, ce que globalize couvre et ce qu’il ne couvre volontairement pas, comme les éditeurs pour traducteurs et la gestion des prestataires, qui sortent du périmètre d’un outil natif au code.

En attendant, le plus rapide pour vous faire une idée est de l’essayer sur votre propre code. Connectez un repo, laissez globalize faire la configuration, puis lisez la première pull request traduite.