Découvrez Lingo.dev v1.0

Toutes les équipes de localisation connaissent ce scénario. Des traducteurs peu familiers du produit se trompent sur les termes de marque. Les wrappers de LLM n’ont aucune mémoire d’une requête à l’autre. Après quelques releases, la terminologie dérive — et personne ne s’en aperçoit, parce que les scores de qualité holistiques affichent 0,95 puis passent à autre chose.

Nous avons mesuré l’écart. Injecter le contexte du glossaire au moment de l’inférence réduit les erreurs terminologiques de 17 à 45 % chez cinq fournisseurs de LLM et sur cinq langues européennes. Nous appelons cela la retrieval augmented localization (RAL). Les LLM ont franchi le seuil de qualité nécessaire à la traduction en production — mais uniquement avec le bon pipeline de contexte. Sans cela, chaque requête isolée devient une nouvelle occasion de dérive terminologique. Chez Lingo.dev, après avoir fourni l’infrastructure de localisation utilisée pour traduire plus de 200 millions de mots pour des clients comme Mistral, Solana, SoSafe et Cal.com, nous avons construit v1.0 autour de cette approche.

Moteur de localisation#

Un moteur de localisation est une API de traduction avec état sur Lingo.dev — une implémentation de la RAL qui conserve le contexte métier d’une requête à l’autre. Configurez-le une fois, utilisez-le partout :

• Modèles — choisissez n’importe quel modèle du catalogue OpenRouter. Classez les modèles par langue avec des chaînes de secours : lorsque le modèle principal n’est pas disponible, le moteur bascule vers le suivant sans interrompre la requête.
• Glossaire — associez les termes source à leurs traductions cibles pour chaque paire de langues. Le moteur injecte les termes correspondants dans chaque requête. Lorsque le moteur de Cal.com rencontre "Workspace", le glossaire le résout avant même que le LLM ne génère le moindre token — aucun onboarding des traducteurs nécessaire.
• Voix de marque — définissez le ton et le registre pour chaque langue. Formel pour les contenus juridiques en allemand, conversationnel pour le marketing japonais, technique pour la documentation en anglais.
• Instructions — définissez des règles par langue pour des cas précis : règles d’élision en français, conventions orthographiques en portugais, guillemets allemands, préférences italiennes en matière d’anglicismes.

Le moteur a de la mémoire. Chaque terme du glossaire, chaque règle de voix de marque, chaque instruction est conservé d’une requête à l’autre. La première traduction effectuée avec un nouveau moteur part de zéro. La millième bénéficie de tout ce que l’équipe a configuré depuis le premier jour. Dans les workflows CI/CD basés sur les diffs, chaque build ne retraduit que ce qui a changé. C’est cette persistance du moteur qui empêche la dérive terminologique — la même dérive qui affecte autant les traducteurs humains que les wrappers de LLM sans état.

Testez vos configurations dans le playground avant leur mise en production. Essayez une chaîne, comparez d’une langue à l’autre, puis déployez quand le résultat est le bon.

Comment l’intégrer#

Trois modes d’intégration. Même moteur, même contexte, même qualité :

CLI — pointez vers votre dépôt et traduisez toutes les langues configurées en une seule commande :

npx lingo.dev@latest run

CI/CD — l’intégration GitHub ouvre une pull request avec les chaînes traduites à chaque push. Relisez les traductions dans le diff, puis fusionnez quand tout est prêt. Aucun relais. Aucune attente d’une équipe externe.

API — appelez le moteur directement depuis votre code backend :

curl -X POST https://api.lingo.dev/process/localize \
  -H "X-API-Key: $LINGO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "engineId": "eng_abc123",
    "sourceLocale": "en",
    "targetLocale": "es",
    "data": {
      "welcome": "Welcome to the future of payments",
      "cta": "Get started"
    }
  }'

Chaque requête est journalisée : modèle utilisé, tokens consommés, statut du fallback, termes du glossaire appliqués, instructions détectées. Le tableau de bord des rapports met en avant le volume de mots, la consommation de tokens, les principales langues, la couverture du glossaire et les taux de changement, afin que vous puissiez voir exactement quels termes sont appliqués et où des manques de couverture subsistent.

Liberté de modèle#

La cohérence terminologique ne devrait pas dépendre du fournisseur de LLM que vous utilisez. La RAL sépare la couche de cohérence — glossaire, voix de marque, instructions — du modèle qui exécute la traduction. Ce contexte enrichi oriente n’importe quel modèle vers un résultat fidèle au domaine. Remplacez GPT-5.4 par Claude Opus entre deux releases sans reconfigurer un seul terme du glossaire.

Cette séparation élimine aussi l’enfermement propriétaire. Les API de traduction sur modèles fermés lient le glossaire, les règles de style et la terminologie à un seul fournisseur. Une régression du modèle implique un ticket au support. Un meilleur modèle chez un autre fournisseur reste hors de portée. Sur Lingo.dev, le modèle n’est qu’un paramètre de configuration — la couche de cohérence, elle, reste en place quel que soit le modèle utilisé en dessous.

Lorsque nous avons testé cinq fournisseurs sur l’AI Act de l’UE, Mistral avec un glossaire de 72 termes (MQM 0,940, où 1,0 signifie sans erreur) a atteint un niveau proche de la qualité brute de Google (0,938). L’écart de coût, lui, est d’un ordre de grandeur. Un glossaire bien conçu réduit le niveau d’intelligence requis du modèle. À mesure que les glossaires gagnent en maturité, la plateforme signale quand un modèle moins coûteux permettrait d’atteindre le même seuil de qualité.

Évaluation de la qualité#

Corriger la dérive terminologique ne résout que la moitié du problème. L’autre moitié : les métriques de qualité standard sont incapables de la voir. Notre recherche a montré que les scores holistiques de qualité de traduction — ceux utilisés par les benchmarks et les classements — donnaient des scores identiques aux traductions brutes et aux traductions enrichies par glossaire, alors qu’une évaluation par dimension relevait 17 à 45 % d’erreurs terminologiques en moins. L’écart que la RAL comble est invisible pour la métrique que l’industrie utilise pour mesurer la qualité de la traduction.

Un problème qu’on ne peut pas mesurer est un problème qu’on ne peut pas corriger. Lingo.dev v1.0 inclut des évaluateurs IA — des contrôles qualité automatisés qui évaluent chaque traduction par dimension, et non à partir d’un seul score holistique. Définissez vos critères en langage naturel : "Tous les tags HTML sont-ils conservés ?" ou "Évaluez le naturel pour un locuteur natif." Un LLM indépendant évalue ensuite le résultat — si GPT-5.4 traduit, Claude Sonnet note, ce qui élimine le biais d’auto-évaluation.

L’évaluation inter-modèles, spécifique à chaque dimension, détecte ce que les scores holistiques ne voient pas : termes hallucinés, registre déplacé, placeholders cassés et dérive terminologique qui s’accumule silencieusement au fil des releases.

Ce que ça change#

Si vous utilisez déjà Lingo.dev — les outils CLI, CI/CD et MCP continuent de fonctionner comme avant. v1.0 ajoute la configuration du moteur : sélection du modèle, chaînes de secours, voix de marque, glossaires, évaluation de la qualité. Le tout par langue. Le tout depuis le tableau de bord. Zéro migration.

Si vous découvrez Lingo.dev — créez un compte développeur gratuit et obtenez un moteur de localisation préconfiguré. Première build traduite en 4 minutes avec la CLI, ou intégrez via l’API.

Votre prochaine release sera livrée dans chaque langue avec une terminologie cohérente. Le glossaire que vous construisez dès la première semaine applique chaque terme de marque dans chaque langue, à chaque build — le coût de configuration est absorbé en amont, pas multiplié à chaque traduction. Lorsqu’un développeur modifie un paragraphe, le pipeline CI ne retraduit que ce paragraphe — même moteur, même glossaire, même seuil de qualité. La traduction cesse d’être un relais. Elle devient une étape du build.

Lingo.dev v1.0 a été conçu pour les équipes d’ingénierie, les responsables localisation et les responsables produit qui ont besoin d’une localisation pensée comme une infrastructure. Les équipes qui préfèrent coordonner des traducteurs humains via des cycles de relecture manuels trouveront peut-être les plateformes de localisation traditionnelles plus adaptées.

Créez un compte développeur gratuit pour vous lancer, ou réservez une démo.

La RAL est à la localisation ce que le RAG est à la génération. Lingo.dev v1.0 est la plateforme pour l’exécuter.

Prochaines étapes#