Toutes les grandes entreprises auxquelles nous parlons se heurtent aux mêmes deux obstacles.
Le premier, c’est la taxe de coordination liée à la cohérence.
Votre application Android est développée par une équipe. Votre application web par une autre. Votre site marketing, votre documentation, vos outils internes – chacun relève d’une équipe différente, avec son propre rythme de release, ses propres relecteurs, son propre pipeline de déploiement.
Les outils historiques permettent de partager la mémoire de traduction et les glossaires entre projets. Des espaces de travail existent. Des ressources au niveau de l’organisation existent aussi. Mais partager ne veut pas dire imposer. Un terme dans le glossaire partagé est une suggestion au traducteur, pas une contrainte pour le modèle. La cohérence entre équipes devient alors une question de discipline. Quelqu’un maintient le glossaire aligné. Quelqu’un arbitre les conflits de terminologie métier entre équipes. Quelqu’un relance l’équipe qui traduit un call-to-action d’une manière pendant qu’une autre le livre autrement. La cohérence est possible. La maintenance, elle, est continue.
Au sein du projet de chaque équipe, la dérive s’amplifie encore. La mémoire de traduction maintient la cohérence tant que les segments ne changent pas. Dans une base de code refactorisée chaque semaine, les segments changent chaque semaine. Notre recherche RAL mesure la vitesse à laquelle la terminologie dérive lorsque le modèle ne dispose d’aucun contexte récupéré.
Le deuxième obstacle, c’est le coût du départ des outils qui génèrent cette taxe. Dans une entreprise, chaque dimension se multiplie : glossaires accumulés entre équipes, mémoire de traduction constituée en TMX et dans des formats propriétaires de fournisseurs d’un projet à l’autre, connecteurs branchés dans la CI de chaque équipe, viviers de traducteurs négociés via les achats, SSO intégré à l’IdP.
La migration ressemble à un programme d’ingénierie sur plusieurs trimestres qu’aucun responsable localisation n’a envie de porter.
Deux architectures répondent à la réalité des organisations multi-équipes.
L’une remplace la mémoire de traduction à l’échelle du projet par un moteur de localisation à l’échelle de l’organisation, qui récupère le contexte à l’inférence. Un glossaire, une voix de marque, et les applications de toutes les équipes s’appuient sur le même moteur de localisation.
L’autre remplace une migration menée par le client par un ingénieur en localisation forward-deployed de Lingo.dev, qui réalise la migration sur notre temps, pas sur le vôtre.
Ces deux modèles font déjà tourner tous les autres pans de votre infrastructure. Il est temps que la localisation rattrape enfin son retard.
Architecture n°1 : le moteur de localisation#
Moteur de localisation
Une API de traduction stateful que les équipes créent sur Lingo.dev, configurée à l’échelle de l’organisation. Chaque moteur de localisation conserve son propre glossaire, sa voix de marque, ses instructions spécifiques à la langue et sa chaîne de modèles hiérarchisée. À chaque requête, il récupère les termes de glossaire pertinents, les injecte dans la fenêtre de contexte du modèle avant la génération du premier token, puis évalue indépendamment le résultat une fois la génération terminée. La première traduction part sans contexte ; la millième bénéficie de tout ce qui précède.
Un moteur de localisation maintient la cohérence au niveau du terme, pas du segment. Il est défini à l’échelle de votre organisation, pas à celle du projet d’une équipe en particulier. Un glossaire, une voix de marque, et toutes les surfaces de toutes les équipes s’appuient sur le même moteur de localisation.
Une entrée de glossaire pour "Submit" s’applique sur chaque surface en espagnol : bouton, objet d’e-mail, infobulle. Équipe web ou équipe mobile, peu importe. La récupération fait correspondre le sens, pas les chaînes. Une seule entrée pour "Deploy" s’applique à "deploying", "deployment", "Deploy your app" – sans avoir à créer une entrée distincte pour chaque forme.
Une voix de marque est rattachée au moteur de localisation pour chaque langue. Chaque requête l’utilise.
Les instructions sont des règles distinctes, testables, définies pour une langue. Conventions d’abréviation, espaces insécables, guillemets : chaque élément peut être débogué séparément.
Une chaîne de modèles achemine chaque requête vers le modèle principal, avec des solutions de repli classées. Changez de fournisseur sans toucher au glossaire.
Un évaluateur IA s’exécute sur un modèle indépendant. Il évalue chaque requête au regard du glossaire et de chaque instruction séparément. Résultat pass/fail avec justification, suivi dans le temps.
| Enjeu | Outils à l’échelle du projet | Moteur de localisation à l’échelle de l’organisation |
|---|---|---|
| Portée de la cohérence | Par projet, par équipe | À l’échelle de l’organisation |
| Unité de cohérence | Segment complet, indexé par hash | Terme individuel, apparié sémantiquement |
| Résiste aux réécritures de la source | Non | Oui |
| Inter-apps, inter-équipes | Discipline ; les humains assurent l’alignement | Par architecture ; le moteur de localisation assure l’alignement |
| Mesure de la qualité | Contrôles basés sur des règles (balises, nombres) | Scoring LLM par requête |
| Flexibilité du modèle | Verrouillage chez un fournisseur | Chaîne hiérarchisée |
| Autorité sur la sortie | Latitude du traducteur | Le glossaire prime sur le modèle |
La dérive devient une réalité que vous pouvez mesurer, plutôt qu’un état de fait que vous absorbez. Le glossaire s’applique à chaque requête. L’évaluateur IA vérifie la conformité, requête par requête.
Le nom de ce mécanisme est retrieval augmented localization (RAL). À l’inférence, le moteur décompose l’entrée en expressions n-gram, les vectorise, puis effectue une recherche par similarité cosinus dans l’index vectoriel du glossaire. Les termes correspondants sont injectés dans la fenêtre de contexte du modèle avant la génération du premier token. C’est structurellement identique au RAG, appliqué à la traduction.
Dans une évaluation contrôlée menée sur plusieurs fournisseurs de LLM et plusieurs langues européennes, RAL a réduit les erreurs de terminologie de 17 à 45 %. Plus de 42 000 jugements de qualité appariés. p < 0.001 corrigé selon Holm-Bonferroni chez chaque fournisseur. Les scores de qualité holistiques, eux, n’ont pas du tout détecté l’écart.
Architecture n°2 : l’ingénierie de localisation forward-deployed#
Le deuxième obstacle, c’est la migration. Vous avez une stack qui fonctionne. Elle génère cette taxe, mais elle fonctionne. Le coût du remplacement – temps d’ingénierie, reprise des intégrations, réonboarding des traducteurs, migration des données historiques – dépasse systématiquement le coût de cette taxe.
C’est ce calcul qui explique pourquoi cette taxe continue d’être payée. Après avoir vu le même goulot d’étranglement freiner encore et encore des entreprises sérieuses, nous avons décidé d’absorber nous-mêmes la migration.
Quand Lingo.dev onboarde une entreprise, ce sont nos ingénieurs qui réalisent la migration. Pas comme une mission de services ajoutée par-dessus la licence. Comme le parcours d’onboarding par défaut.
Un ingénieur en localisation forward-deployed passe en revue votre glossaire, vos documents de voix de marque, la configuration de vos connecteurs, vos contrats de traducteurs. Il importe votre mémoire de traduction depuis TMX et votre glossaire, quel que soit son format historique. Rien n’est reconstitué. Il construit le moteur de localisation sur Lingo.dev avec votre terminologie préchargée. Il l’intègre à votre CI. Il fait passer votre vivier de traducteurs dans le pipeline asynchrone afin que les personnes en qui vous avez confiance restent dans la boucle.
C’est dans les organisations multi-équipes que cette architecture révèle tout son intérêt. Dans l’approche historique, aligner la terminologie entre équipes suppose N migrations synchronisées : chaque équipe reconstitue ses clés et sa TM dans son propre projet. Ici, le moteur de localisation n’est construit qu’une seule fois. Chaque équipe y connecte son application à son propre rythme. La cohérence inter-apps apparaît dès la première langue qui passe par le moteur, sans attendre que chaque équipe ait terminé sa migration.
Nos ingénieurs restent à vos côtés jusqu’à votre prochain déploiement en production, puis le suivant, jusqu’à ce que votre équipe interne prenne pleinement le système en main.
C’est ainsi que nous onboardons les clients enterprise.
Dès lors qu’une organisation multi-équipes livre chaque semaine, la traduction ne peut plus être un ticket achats entre acheteur et fournisseur. Elle doit avancer au même rythme que votre prochain déploiement en production, pas après. L’ingénierie forward-deployed est le modèle adopté par Palantir, Scale AI, Ramp et d’autres fournisseurs d’infrastructure pour onboarder des clients enterprise depuis plus de dix ans.
Il est temps que la localisation rattrape enfin son retard.
Audit
Un ingénieur Lingo.dev passe en revue vos dépôts source, votre mémoire de traduction existante (y compris les exports TMX), votre glossaire, vos connecteurs et vos contrats de traducteurs – dans chaque équipe qui gère une surface. Il établit un plan de migration avec séquencement et calendrier. Ce plan vous appartient.
Un moteur aligné sur votre niveau de qualité actuel
Nous configurons le moteur de localisation avec votre glossaire importé, votre voix de marque par langue et votre pipeline de traducteurs. Avant tout trafic de production, nous réalisons une comparaison côte à côte : le résultat de votre outil actuel face à celui du moteur, sur les mêmes chaînes, la même semaine. À vous de décider si le niveau de qualité est au rendez-vous.
Intégré à la CI de chaque équipe
Pas de rip-and-replace. Le moteur de localisation s’insère comme une étape dans le pipeline existant de chaque équipe. Flows de merge, flows de relecture, relecteurs : tout reste inchangé. Le moteur remplace simplement l’ancienne étape.
Bascule à votre rythme
Une équipe, une paire de langues pour commencer. Puis trois. Puis le reste. Vous choisissez l’ordre. Nous relançons la comparaison à chaque étape. Le rollback tient en un commit.
Transfert à votre équipe
Notre ingénieur transmet le système à votre équipe plateforme – documentation, runbooks et rotation d’astreinte que nous assurons jusqu’à la reprise complète par vos équipes.
Éléments de preuve#
Recherche. L’étude RAL : plus de 42 000 jugements de qualité appariés sur plusieurs fournisseurs de LLM et plusieurs langues européennes. p < 0.001 corrigé selon Holm-Bonferroni chez chaque fournisseur. La réduction des erreurs de terminologie va de 17 à 45 %.
La configuration plutôt que le choix du modèle. Nous avons constaté que sur Mistral, Gemini, Claude, GPT – n’importe quel modèle, associé à un bon glossaire, une bonne voix de marque et un bon contexte, produit de manière fiable des traductions prêtes à être livrées, de qualité de référence, pour une fraction du coût. Non pas parce que nous avons amélioré le modèle. À chaque requête, le moteur de localisation récupère par recherche de similarité les termes de glossaire correspondants, la voix de marque et les instructions de langue, puis les injecte dans la fenêtre de contexte du modèle avant la génération du premier token.
Échelle de production. Plus de 200 M de mots traduits sur la plateforme.
Clients de référence. Mistral, Solana, SoSafe, Cal.com.
Périmètre#
Lingo.dev accompagne des équipes de localisation de tous horizons — entreprises mono-produit, projets open source, équipes 100 % mobile, plateformes d’entreprise. L’architecture décrite ici est celle pensée pour les grandes organisations qui ont plusieurs équipes, déploient plusieurs applications et opèrent dans plus de 20 langues.
La suite#
La première étape, c’est un pilote de deux semaines. Une équipe, une paire de langues.
Un ingénieur en localisation intégré à vos équipes travaille aux côtés de votre responsable localisation et de votre lead engineering. Nous analysons votre workflow. Nous mettons en place un système de mesure pour vous permettre d’évaluer la qualité des traductions dans des langues que votre équipe ne maîtrise pas — des évaluateurs IA s’appuyant sur des modèles indépendants, qui notent chaque traduction à l’aune de votre glossaire et de vos règles. Cette notation s’inspire de MQM, le cadre de référence standard pour l’évaluation de la qualité des traductions.
Nous configurons le moteur de localisation à partir de votre glossaire et de vos documents de voix de marque. Nous le faisons tourner sur votre contenu source, en parallèle de votre outil actuel. Vous constatez l’écart, puis vous décidez.
Ensuite, nous planifions la migration des équipes et des langues restantes à votre rythme, pas au nôtre.
Échangez dès aujourd’hui avec nos experts en ingénierie de la localisation.
