Le navigateur peut traduire votre application maintenant. Voici ce qu'il ne peut pas faire.

En juin 2026, la question « ai-je vraiment encore besoin d'un outil de traduction ? » a pris un nouveau tranchant. Le 2 juin, Microsoft a annoncé que Microsoft Edge 148 embarque une API Translator intégrée, appuyée sur des modèles sur l'appareil couvrant plus de 145 langues, gratuite et privée. Chrome de Google a la même API stable depuis Chrome 138 (juin 2025), aujourd'hui pour 37 langues et variantes. Deux des navigateurs les plus utilisés au monde peuvent désormais traduire n'importe quelle page, localement, gratuitement.

Il vaut donc la peine de poser la question honnêtement : si le navigateur traduit votre application gratuitement, avez-vous encore besoin d'un système de gestion de traduction ?

La réponse courte : le navigateur traduit, le TMS gouverne. Ils ne se disputent pas le même travail. Cet article est la version honnête du pourquoi, avec une recette exécutable qui met le navigateur au travail comme repli sanctionné pendant que vos traductions restent gouvernées.

Ce que le navigateur fait réellement, et fait bien

Rendons à César ce qui est à César. L'API Translator intégrée est une très belle pièce d'ingénierie de plateforme, et la démonstration est courte. Détectez la fonctionnalité, vérifiez que la paire de langues est disponible, créez un traducteur, traduisez :

// Amélioration progressive : ne s\'exécute que là où l\'API existe.
if ('Translator' in self) {
  const pair = { sourceLanguage: 'en', targetLanguage: 'fr' }

  const availability = await Translator.availability(pair)
  // 'unavailable' | 'downloadable' | 'downloading' | 'available'

  if (availability !== 'unavailable') {
    const translator = await Translator.create({
      ...pair,
      monitor (m) {
        m.addEventListener('downloadprogress', (e) => {
          console.log(`Téléchargement du modèle : ${Math.round(e.loaded * 100)}%`)
        })
      }
    })

    const out = await translator.translate('Where is the nearest bus stop?')
    console.log(out) // "Où est l'arrêt de bus le plus proche ?"

    translator.destroy() // libérer le modèle une fois terminé
  }
}

C'est tout. Le modèle d'une paire de langues se télécharge une fois, puis reste disponible d'un site à l'autre, et l'API fonctionne de la même manière dans Edge (documentée ici), y compris une variante translateStreaming() pour une sortie jeton par jeton. Ce que vous obtenez est réel :

• Instantané. Après le téléchargement unique du modèle, la traduction se fait localement sans aller-retour réseau.
• Gratuit. Pas de clés d'API, pas de facturation au caractère, pas de quota.
• Privé. Le texte ne quitte jamais l'appareil et n'est pas collecté pour entraîner des modèles.
• Hors ligne. Une fois le modèle téléchargé, il fonctionne sans connexion.

Pour « une visiteuse arrive sur une page dans une langue que vous n'avez jamais livrée et veut quand même la lire », c'est excellent. C'est la version moderne, sur l'appareil, de la barre de traduction, accessible à votre code. Si c'est votre besoin, utilisez-la et arrêtez de lire ici.

Mais c'est un besoin différent de celui d'exploiter un produit localisé. Voici où passe la ligne.

La faille de gouvernance

Un système de gestion de traduction n'est pas dans le métier de transformer une chaîne en une autre. Il est dans le métier de faire de la traduction un processus contrôlé, vérifiable et livrable, à l'échelle d'une équipe et dans la durée. L'API du navigateur ne fait rien de tout cela, par conception, et il vaut la peine d'être concret plutôt que méprisant sur ce qui manque exactement.

Pas de clés, pas de structure. L'API traduit une chaîne que vous lui passez. Elle n'a aucune idée que cette chaîne est checkout.pay_now, qu'elle vit dans le namespace checkout, qu'elle a une variante au pluriel ou qu'elle a déjà une traduction française approuvée qui vous a coûté de l'argent. Elle traduit du texte, pas votre modèle de contenu. Tout ce qui vient après « nous avons un catalogue structuré de clés » n'existe tout simplement pas ici.

Pas d'état de relecture, pas de preuve d'approbation. Il n'existe aucune trace qu'un humain ait regardé la traduction française de votre politique de remboursement et l'ait validée. Cette trace n'est de plus en plus pas optionnelle : sous le règlement européen sur l'IA, le chemin qui maintient un contenu d'intérêt public traduit automatiquement hors de l'obligation de divulgation visible passe par une relecture humaine documentée, et une traduction produite à la volée dans le navigateur de la visiteuse n'a, par définition, aucune relecture attachée (nous avons traité cette obligation et l'exemption du flux de relecture séparément). La vérification de conformité ne peut pas se faire côté client après coup.

Pas de contrôle de terminologie ni de voix de marque. Votre produit l'appelle « espace de travail », pas « bureau », et votre ton est le tutoiement informel, pas le vouvoiement formel. Le modèle du navigateur ne connaît pas votre glossaire ni votre guide de style, et il n'existe aucun moyen de les lui transmettre : l'API Translator est un modèle de traduction scellé et spécialisé, pas un LLM que l'on peut instruire, elle n'a donc aucun canal de prompt ou d'instruction système par lequel injecter terminologie, ton ou mémoire de traduction. Chaque visiteuse peut obtenir un rendu légèrement différent, hors marque, du même bouton.

Pas de Quality Estimation. Quand le modèle se trompe sur une traduction, rien ne le signale. Il n'y a pas de score de confiance, pas d'acheminement des cas douteux vers un humain. La Quality Estimation et un flux de relecture sont précisément le filet de sécurité que la traduction sur l'appareil supprime.

Pas de fidélité de format. Pluriels, formes genrées, interpolation ({{count}} items, {{name}}), composants imbriqués dans une phrase : ce sont des problèmes d'i18n, pas des problèmes de traduction de phrase. Passez à un modèle une chaîne avec un espace réservé et vous pariez sur la survie de cet espace réservé au bon endroit. Les règles de pluriel ICU ne sont pas quelque chose qu'un appel de traduction au moment de l'affichage prend en compte.

Pas de SSR, pas de SEO. C'est le point majeur pour un site public. Le navigateur traduit le DOM après son rendu, dans le navigateur de la visiteuse. Les robots des moteurs de recherche, les aperçus de liens et votre propre rendu côté serveur ne voient que la langue d'origine. Une page traduite par le navigateur est, pour Google, une page non traduite. Vous ne pouvez pas vous classer sur un marché dont la langue n'existe jamais que côté client.

Lacunes de couverture mobile. Les API Translator et Language Detector de Chrome sont documentées comme réservées à l'ordinateur ; elles ne fonctionnent pas sur mobile. Une grande part de vos utilisateurs est sur téléphone, où tout ce mécanisme est actuellement absent.

Pas un standard établi. Seuls les deux navigateurs Chromium l'embarquent. Mozilla a enregistré une position négative sur la Web Translation API et poursuit une contre-proposition, et WebKit n'a pris aucune position. L'API est incubée au sein du W3C Web Machine Learning Working Group, ce qui signifie que sa forme peut encore changer. Bâtir une expérience centrale dessus aujourd'hui, c'est bâtir sur la préversion d'une seule famille de moteurs, pas sur la plateforme web.

Rien de tout cela ne rend l'API du navigateur mauvaise. Cela en fait une technologie d'affichage. L'erreur serait de traiter une technologie d'affichage comme une technologie de gestion de contenu.

L'architecture : le navigateur traduit, le TMS gouverne

Placez les deux là où ils doivent être et ils cessent de se concurrencer :

• Le cœur gouverné. Vos vraies traductions vivent dans un TMS : structurées par clé et namespace, traduites par IA et traduction automatique avec votre glossaire et votre guide de style comme contexte, notées par Quality Estimation, relues par des humains là où cela compte, versionnées, et livrées à chaque navigateur, chaque robot et chaque téléphone via un CDN. C'est le contenu que vous assumez, celui qui se classe, celui qu'un auditeur peut retracer.

• Le repli sanctionné. Pour les failles, les langues que vous n'avez pas encore livrées, la clé toute neuve mise en ligne il y a une heure, la langue de longue traîne que vous ne staffirez jamais, laissez le navigateur combler. Instantanément, gratuitement, pour les visiteurs dont le navigateur le peut. C'est une dégradation élégante, pas le produit.

L'astuce est de les brancher ensemble pour que le repli soit temporaire et auto-réparateur : chaque fois que le navigateur doit traduire quelque chose, ce fait devient un signal qui retourne vers le cœur gouverné et le fait traduire correctement pour la prochaine fois.

La recette : repli sur clé manquante d'i18next, auto-réparateur vers Locize

Voici cette boucle, concrètement, avec i18next et Locize. L'idée :

1. Une clé n'a pas de traduction dans la langue active. i18next affiche le texte source (son repli normal) et déclenche saveMissing.
2. saveMissing signale la clé à Locize, où la traduction automatique et la Quality Estimation se mettent au travail et un humain peut relire.
3. Pendant ce temps, pour les visiteurs sur un navigateur compatible, l'API Translator sur l'appareil traduit le texte de repli sur place, de sorte qu'ils voient immédiatement leur langue plutôt que l'anglais.
4. Au prochain publish, la traduction en bonne et due forme, relue, est dans Locize et sur le CDN. La clé existe désormais dans la langue cible, le repli ne se déclenche plus, et la traduction gouvernée a discrètement remplacé la supposition faite sur l'appareil.

D'abord le côté i18next. Le backend Locize signale les clés manquantes pour vous :

import i18next from 'i18next'
import { initReactI18next } from 'react-i18next'
import Backend from 'i18next-locize-backend'

i18next
  .use(Backend)
  .use(initReactI18next)
  .init({
    fallbackLng: 'en',
    saveMissing: true, // signaler à Locize les clés manquantes dans la langue active
    backend: {
      projectId: '<your-project-id>',
      version: 'latest',
      // Une clé d'API en écriture n'est nécessaire QUE pour SIGNALER les clés
      // manquantes. Ne la livrez jamais aux utilisateurs finaux. Voir les
      // réserves ci-dessous : signalez en dev/staging ou derrière votre propre
      // endpoint, pas dans le bundle client de production.
      apiKey: import.meta.env.DEV ? '<dev-only-api-key>' : undefined
    }
  })

Maintenant le repli au moment de l'affichage. Un petit hook lit une clé ; si i18next a dû se replier sur une autre langue, il demande au navigateur de traduire le texte de repli sur l'appareil, et le remplace dès qu'il est prêt :

import { useEffect, useState } from 'react'
import { useTranslation } from 'react-i18next'

// Combler une traduction manquante sur l'appareil, gratuitement, pendant que
// Locize fait traduire la clé pour de vrai. Pure amélioration progressive : là
// où l'API Translator est absente (mobile, Firefox, Safari), ceci renvoie
// simplement le texte de repli.
export function useGovernedT (key) {
  const { t, i18n } = useTranslation()

  // returnDetails nous dit quelle langue i18next a réellement utilisée.
  const details = t(key, { returnDetails: true })
  const target = i18n.language
  const source = details.usedLng        // la langue sur laquelle il s'est replié
  const fallbackText = details.res      // texte dans cette langue de repli
  const missingInTarget = !!source && source !== target

  const [onDevice, setOnDevice] = useState(null)

  useEffect(() => {
    setOnDevice(null)
    if (!missingInTarget) return
    if (typeof self === 'undefined' || !('Translator' in self)) return

    let cancelled = false
    ;(async () => {
      const pair = { sourceLanguage: source, targetLanguage: target }
      const availability = await Translator.availability(pair)
      if (availability === 'unavailable') return

      const translator = await Translator.create(pair)
      const translated = await translator.translate(fallbackText)
      translator.destroy()

      if (!cancelled) setOnDevice(translated)
    })().catch(() => { /* rester sur le texte de repli en cas d'erreur */ })

    return () => { cancelled = true }
  }, [key, source, target, fallbackText, missingInTarget])

  // Afficher la traduction sur l'appareil une fois prête, le texte de repli jusque-là.
  return missingInTarget && onDevice ? onDevice : fallbackText
}

Et dans un composant, il se lit comme n'importe quelle autre traduction :

function CheckoutButton () {
  const label = useGovernedT('checkout.pay_now')
  return <button className='btn-primary'>{label}</button>
}

Un checkout.pay_now tout neuf qui n'existe qu'en anglais va : afficher « Pay now » instantanément pour tout le monde, montrer « Payer maintenant » un instant plus tard pour une visiteuse sur Chrome ou Edge de bureau, et se signaler à Locize pour qu'en un cycle de publish chaque visiteuse, sur chaque navigateur, chaque téléphone et chaque robot, obtienne une traduction française relue et notée en qualité depuis le CDN. Le repli se répare tout seul.

Réserves honnêtes

• Chrome 138+ et Edge 148+ de bureau uniquement. Tous les autres (Firefox, Safari, chaque téléphone) obtiennent le texte de repli, ce qui est très bien, c'est tout l'intérêt de l'amélioration progressive. Ne laissez rien d'important dépendre du déclenchement du chemin sur l'appareil.
• Gardez la clé d'écriture hors du client. Signaler les clés manquantes nécessite un identifiant en écriture. Exécutez saveMissing en développement ou en staging, ou faites-le transiter par votre propre endpoint, plutôt que de livrer une clé d'API dans un bundle de production. La traduction sur l'appareil elle-même ne nécessite aucune clé et peut être livrée sans risque.
• C'est un palliatif, pas la traduction. La sortie sur l'appareil n'est ni relue, ni notée, ni conforme au glossaire. Elle vous offre une meilleure première impression pendant que la traduction gouvernée est produite. Ne la traitez jamais comme définitive.
• La première utilisation télécharge un modèle. La toute première traduction d'une paire de langues déclenche un téléchargement unique du modèle, de sorte que la première visiteuse d'une session voit le texte de repli un instant de plus. Le rappel monitor vous permet d'afficher la progression si vous le souhaitez.

Une note prospective, et juste une note : ce même câblage de clé manquante vers repli est la couture naturelle où les fonctionnalités de traduction à la demande ont tendance à croître, c'est donc un modèle utile à avoir en place, quel que soit l'avenir des API du navigateur. Aucune promesse, juste un bon point d'appui.

Où Locize entre en jeu

Le navigateur est un bon traducteur. Ce n'est pas un endroit pour gérer des traductions, et il n'a jamais cherché à l'être. Locize est le cœur gouverné dans lequel le repli se répare : clés et namespaces structurés, traduction IA automatique avec votre glossaire et votre guide de style, Quality Estimation sur chaque traduction IA, un flux de relecture et un historique complet pour les traductions que vous assumez, et une livraison CDN pour que le résultat atteigne chaque navigateur, chaque téléphone et chaque robot, pas seulement les visiteurs qui se trouvent sur Chromium de bureau.

Utilisez le navigateur pour ce en quoi il est vraiment bon, une traduction instantanée, gratuite et privée au moment de l'affichage, et gardez la gouvernance là où elle doit être.

Si vous voulez le cœur gouverné sous ce repli : créez un compte Locize gratuit, activez la traduction automatique et la Quality Estimation, et branchez saveMissing pour signaler vos clés manquantes. Le navigateur traduit. Votre TMS gouverne.