Si vous cherchez « best localization software » en ce moment, vous tomberez sur une douzaine d’articles rédigés par des éditeurs de solutions de localisation, chacun se plaçant lui-même en tête du classement. Ils comparent des fonctionnalités, listent les avantages et les inconvénients, puis concluent (sans surprise !) que vous devriez les choisir.

Nous n’allons pas faire ça. À la place, nous allons expliquer pourquoi toute cette catégorie s’attaque au mauvais problème, et ce à quoi ressemble vraiment la bonne solution.

La pile de localisation se divise en trois

Livrer une application multilingue en 2026 exige d’assembler trois systèmes complètement distincts :

1. Une bibliothèque d’i18n — gère l’extraction des chaînes, l’interpolation, la pluralisation et le routage des paramètres régionaux dans votre base de code. Elle restitue les traductions. Elle ne les produit pas.
2. Un système de gestion de la traduction (TMS) — stocke les fichiers de traduction, gère les workflows et coordonne les échanges. Il se situe entre votre code et vos traducteurs, mais ne fait pas la traduction.
3. Un fournisseur de services linguistiques (LSP) — les traducteurs humains, les agences ou les moteurs de traduction automatique qui produisent réellement le contenu traduit. Ils ne savent rien de votre code ni de votre TMS.

La bibliothèque ne sait rien de vos traductions. Le TMS ne sait rien de votre code. Le fournisseur de traduction ne sait rien ni de l’un ni de l’autre. Les relier entre eux demande des semaines de travail d’ingénierie au départ, puis engloutit des heures à chaque sprint pour synchroniser les fichiers, résoudre les conflits de fusion, déboguer les webhooks et garder sous surveillance un pipeline qui n’a jamais été conçu comme tel.

Ce que signifie réellement « de bout en bout »

General Translation n’est pas une bibliothèque. Ce n’est pas un TMS. C’est toute la chaîne, adoptée par des équipes à forte culture développeur chez Cursor, Cognition, Windsurf, Mintlify et ClickHouse.

• Bibliothèques open source pour développeurs : gt-next, gt-react et la prise en charge de React Native/Expo. Des SDK prêts à l’emploi avec une prise en charge complète de TypeScript.
• Une plateforme de traduction pensée d’abord pour l’IA qui comprend votre base de code, votre produit et votre terminologie. Pas une traduction automatique générique simplement ajoutée par-dessus.
• Locadex, l’agent IA : un ingénieur d’internationalisation automatisé qui analyse votre base de code, l’internationalise, crée les traductions et ouvre des pull requests à chaque push.

Développer à la fois la bibliothèque et le moteur de traduction rend la localisation dix fois plus facile. Pas d’export/import JSON, pas de gestion de fichiers, pas d’agences à coordonner. Les traductions passent directement de votre code source à la production.

Ce qui ne va pas avec les plateformes TMS traditionnelles

Les anciens systèmes de gestion de la traduction ont été conçus pour un monde d'avant l'IA. Ils reposent sur un workflow précis : le contenu est extrait de votre base de code, envoyé vers un tableau de bord, attribué à des traducteurs, relu, approuvé, exporté, puis réintégré. Ça fonctionne une partie du temps, mais c'est lent, coûteux et fragile.

Ils gèrent des fichiers, pas du code. Un TMS ingère vos fichiers de traduction (JSON, XLIFF, PO, etc.) et vous fournit des outils pour les gérer. Mais la véritable source de vérité, c'est votre base de code : vos composants, vos variables, votre hiérarchie d'interface. Gérer les fichiers sans comprendre le code signifie que le contexte se perd toujours en chemin.

La plupart des plateformes ont ajouté des fonctionnalités d'IA ou de traduction automatique ces dernières années, généralement en faisant passer les chaînes de caractères par des moteurs tiers de traduction automatique et en vous laissant choisir lequel utiliser. L'IA voit des chaînes isolées. Elle ne voit ni votre arborescence de composants, ni vos noms de variables, ni l'interface environnante. C'est pourquoi le résultat de la traduction automatique demande encore beaucoup de retouches.

Elles passent à l'échelle en ajoutant des personnes, pas en supprimant du travail. Le modèle économique des TMS repose sur la coordination de traducteurs humains — rôles, permissions, chaînes de relecture, workflows d'approbation. C'est nécessaire pour du contenu d'entreprise réglementé. Pour une équipe de développement qui déploie une application SaaS en 20 langues, c'est une pure surcharge.

Et les tarifs ? Plusieurs des plateformes les plus populaires imposent un échange avec l'équipe commerciale juste pour voir les prix. D'autres facturent par utilisateur, et la facture gonfle à mesure que votre équipe grandit. Des coûts imprévisibles compliquent la budgétisation de nouvelles langues.

Ce qui ne va pas avec les bibliothèques d’i18n autonomes

Les bibliothèques d’i18n populaires pour React et Next.js gèrent bien le rendu : interpolation, pluralisation, routage par paramètre régional, prise en charge des Server Components.

Mais elles ne traduisent rien.

Elles se contentent d’afficher ce que vous leur fournissez. Vous devez toujours :

• Extraire chaque chaîne à traduire dans des fichiers JSON
• Gérer un fichier distinct pour chaque paramètre régional
• Soit traduire ces fichiers manuellement, faire appel à des traducteurs ou intégrer un TMS
• Garder tous les fichiers en sync à mesure que votre base de code évolue

Avec 10 langues et 500 clés, cela fait 5 000 entrées à maintenir. Avec 50 langues, cela fait 25 000. La bibliothèque ne vous aide en rien sur ce point. Au mieux, elle se contente d’afficher ce que vous lui fournissez — soit seulement la moitié du problème.

Comment General Translation ferme la boucle

1. Installez et codez. Lancez l’assistant de configuration et entourez le contenu de composants <T>. Aucune extraction de clés. Aucun fichier JSON.

import { T } from 'gt-next';

export default function Home() {
  return (
    <T>
      <h1>Welcome to our app</h1>
      <p>This content is translated automatically.</p>
    </T>
  );
}

2. Développez. Les traductions apparaissent on-demand. Changez de langue et voyez immédiatement le résultat.

3. Déployez. Une commande génère toutes les traductions lors du build. Elles sont pré-générées, mises en cache et distribuées via CDN. Moins de 50 ms partout dans le monde. Voir le guide de déploiement →

4. Automatisez. Locadex surveille votre repo. Lorsque vous poussez votre code, il analyse les changements, internationalise le nouveau contenu, génère les traductions et ouvre une PR. Sans intervention humaine, sauf si vous le souhaitez. Dans ce cas, l’éditeur de traduction vous affiche les diffs côte à côte et vous permet de modifier le contenu avant ou après sa mise en ligne.

Pourquoi la plupart des IA de traduction se trompent

La plupart des IA de localisation traduisent les chaînes de caractères une par une, de manière isolée. « Apple » peut désigner le fruit ou l’entreprise. « Cell » peut faire référence à une cellule biologique ou à une cellule de feuille de calcul. Sans contexte, l’IA ne fait qu’une supposition.

L’IA de General Translation voit tout le contexte de votre base de code : hiérarchie des composants, noms de variables, interface environnante, glossaire produit. Le résultat est idiomatique sans retouche manuelle. Pour les cas limites, vous pouvez ajouter un contexte explicite directement dans le composant.

Une tarification qui s’adapte à l’usage, pas à la taille de votre équipe

GT propose une tarification à l’usage. Vous payez ce que vous traduisez. Pas de frais par utilisateur qui s’envolent à mesure que votre équipe s’agrandit. Aucun appel commercial nécessaire. Voir les tarifs complets →