Qu'est-ce que la localisation continue ? Définition, workflow, et ce que cela ne veut pas dire

La localisation continue est un workflow de traduction dans lequel les chaînes nouvelles et modifiées passent automatiquement et en continu de la base de code aux personnes ou aux systèmes qui les traduisent, en parallèle du développement, et dans lequel les traductions approuvées sont livrées à l'application en production sans nouvelle version. C'est le pendant, pour la localisation, de l'intégration continue et de la livraison continue : au lieu d'un transfert de traduction avant chaque version, la traduction est un processus qui tourne en permanence, et une correction de traduction n'attend jamais un déploiement.

Ce billet est la définition : ce que le terme signifie, ce qu'il ne signifie pas, les quatre étapes que toute mise en œuvre comporte, en quoi il diffère du workflow par lots qu'il remplace, et ce qu'il ne résout pas. La partie produit, la façon dont Locize le met en œuvre et les équipes qui travaillent ainsi sont sur la page de localisation continue.

Ce que la localisation continue signifie, et ce qu'elle ne signifie pas

Le mot « continu » est emprunté à dessein à l'intégration continue et à la livraison continue. Dans ces pratiques, le code est intégré et livré par petits incréments, tout le temps, au lieu de gros lots avec un gel avant chacun. La localisation continue applique la même idée à la traduction : l'unité de travail est la chaîne, pas la version, et le pipeline fait passer les chaînes du code aux traducteurs puis aux utilisateurs sans attendre une coupure.

Trois lectures du terme sont assez souvent fausses pour être explicitées :

• Cela ne veut pas dire « tout traduire avec l'IA et livrer ». La traduction automatique et l'IA sont la raison pour laquelle la première ébauche n'attend plus ; ce qui est publié reste décidé par des contrôles et une relecture. Un pipeline qui pousse une sortie de modèle non relue en production est continu et non gouverné, la combinaison derrière la dérive terminologique et le message d'erreur insultant occasionnel.
• Cela n'impose pas d'abolir les fichiers de traduction. Certaines configurations continues n'ont aucun fichier de langue dans le dépôt parce que l'application charge les traductions à l'exécution ; d'autres génèrent les fichiers en CI et les commitent. Les deux sont continues si rien n'attend un transfert manuel.
• Cela ne supprime pas le besoin d'un glossaire, d'un workflow de relecture ou de contrôles qualité. Cela les rend plus importants, parce que plus de chaînes circulent plus vite.

Localisation continue contre localisation par lots

Un workflow par lots a une forme reconnaissable. Le développement atteint une coupure. Quelqu'un exporte les chaînes qui ont changé, ou toutes, dans des fichiers ou un tableur. Les fichiers partent chez les traducteurs, en interne ou en agence. Des jours ou des semaines plus tard ils reviennent, quelqu'un les importe, règle ce qui s'est cassé entre-temps, et les traductions partent avec le prochain déploiement. Chaque étape est une attente, et la fonctionnalité terminée le jour de la coupure sort dans sa langue par défaut uniquement.

Un workflow continu supprime la coupure. Les chaînes sont détectées au moment où les développeurs les écrivent. La traduction se fait pendant que la fonctionnalité est encore en construction. Un point de contrôle de relecture décide ce qui est prêt. La livraison ne dépend pas d'un déploiement. Les effets visibles pour une équipe d'ingénierie : la traduction cesse d'être une dépendance bloquante pour les versions, et un libellé faux en polonais est corrigé en quelques minutes plutôt qu'à la prochaine version. L'effet visible pour une équipe de localisation : le travail arrive en flux au lieu d'arriver en tas.

Les quatre étapes d'un workflow de localisation continue

Toute mise en œuvre, quel que soit l'outillage, comporte les quatre mêmes étapes.

1. Détecter : les chaînes quittent le code automatiquement

Un développeur écrit un appel de traduction avec une nouvelle clé et une valeur par défaut. Soit une étape d'extraction statique en CI lit les appels et signale les clés, soit l'application en cours d'exécution signale une clé la première fois qu'elle l'affiche (dans i18next, c'est l'option saveMissing). Personne n'exporte rien ; la clé existe dans le système de traduction avec son texte par défaut avant même que la pull request soit fusionnée.

2. Traduire : personnes, machines et IA travaillent pendant que le développement continue

Les nouvelles clés reçoivent une première ébauche par traduction automatique ou IA, avec le glossaire et le guide de style du projet comme contexte, pour qu'aucune langue ne soit vide pendant que la fonctionnalité est en cours. Traducteurs et relecteurs travaillent sur les mêmes clés dans un éditeur qui montre la source, le contexte et la terminologie. Le développement n'attend pas cette étape, et cette étape n'attend pas une version.

3. Publier : un point de contrôle, pas un gel

Ce qui passe en ligne est décidé par chaîne, pas par version : contrôles automatiques des placeholders, des nombres, des balises et de la cohérence ; un score de quality estimation pour les ébauches générées par machine ; une relecture humaine pour les chaînes qui en ont besoin. Les versions ou les branches permettent à une équipe de préparer les traductions d'une fonctionnalité pas encore publique. Le point de contrôle remplace le gel : le train de livraison continue de rouler, et une traduction y monte quand elle est prête.

4. Livrer : l'application en production récupère les traductions

Les traductions approuvées atteignent les utilisateurs sans build : l'application les charge à l'exécution depuis un réseau de diffusion de contenu, avec une durée de cache qui équilibre fraîcheur et latence. Les équipes qui ont besoin de fichiers pour le rendu côté serveur ou des bundles hors ligne les téléchargent en CI comme artefacts générés. Dans les deux cas, une correction publiée dans l'éditeur est en ligne sans commit.

Comment les équipes mettent en œuvre la localisation continue aujourd'hui

• Synchronisation CI avec fichiers générés. L'extraction s'exécute dans le pipeline, une étape de synchronisation pousse les nouvelles clés vers le système de traduction et récupère les fichiers traduits, les fichiers sont commités ou téléchargés au build. Continu, avec les fichiers conservés pour les builds qui en ont besoin. La synchronisation par différence compte ici, pour qu'une pull request ne traduise que les clés qu'elle a ajoutées.
• Signalement à l'exécution et livraison via CDN. L'application signale les nouvelles clés pendant qu'elle tourne (limité au développement) et charge les traductions à l'exécution ; le dépôt ne contient aucun fichier de langue. La forme la plus directe du schéma, courante dans les applications monopages et mobiles.
• Un système de gestion de traduction au milieu. Les deux approches ci-dessus ont besoin d'un endroit où traducteurs, traduction automatique et IA rencontrent les clés, avec relecture, historique et publication. Le TMS est la moitié étapes 2 et 3 du workflow ; l'intégration CI ou à l'exécution est la moitié étapes 1 et 4.
• De l'IA en CI seulement. Un workflow qui extrait les clés et les traduit automatiquement au push, sans éditeur ni relecture. Continu selon la définition ci-dessus, et exactement la configuration visée par la section « ce que cela ne veut pas dire » : rien entre le modèle et la production. Ce qui y casse, et comment ajouter la couche manquante, est dans quand les traductions IA cassent.

Ce qu'il faut avant que cela fonctionne

• Les clés naissent dans le code. Si quelqu'un tape encore des clés dans un fichier ou un tableur, l'étape 1 est manuelle et tout ce qui suit l'attend.
• Une seule source de vérité. Les traductions vivent dans un système ; les fichiers, s'il y en a, en sont générés. Deux sources de vérité réintroduisent l'étape de fusion à laquelle les workflows par lots passent leur temps.
• Une politique de qualité écrite. Quels types de contenu peuvent partir sur une ébauche IA plus des contrôles automatiques, lesquels ont besoin d'une personne, lesquels sont retenus en propositions de relecture jusqu'à approbation. Un flux continu sans cette politique est un moyen plus rapide de livrer des erreurs.
• Un mécanisme de préparation. Des versions ou des branches, pour que les traductions de fonctionnalités non publiées ne passent pas en ligne trop tôt et qu'une version de production puisse être promue délibérément.
• Des contrôles sur l'ensemble du corpus. Placeholders, nombres, balises et cohérence entre clés doivent être vérifiés là où se trouvent toutes les chaînes, à chaque enregistrement, pas seulement sur un diff. La taxonomie est dans ce qui casse vraiment dans les traductions.
• Une mesure. Le seul chiffre qui dit si le workflow est continu : le délai entre l'écriture d'une chaîne et sa mise en ligne dans toutes les langues. S'il se mesure en cycles de version, le workflow est un workflow par lots avec de meilleurs outils.

Ce que la localisation continue ne résout pas

• La qualité de traduction. Le flux n'est pas la qualité. La gouvernance terminologique, la relecture humaine et les contrôles qualité sont des couches séparées, et le flux continu augmente le coût de leur absence.
• Le contexte. Une chaîne qui arrive du code sans capture d'écran ni note reste ambiguë. La détection continue rend la capture de contexte plus importante, pas moins.
• Les contenus réglementés. Un texte qui informe le public sur des questions d'intérêt public peut relever de l'obligation de divulgation visible de l'article 50 du règlement européen sur l'IA (en vigueur depuis le 2 août 2026), sauf s'il a fait l'objet d'une relecture humaine documentée avec responsabilité éditoriale. Le workflow peut consigner cette relecture ; il ne peut pas décider quels contenus en ont besoin. L'explication de l'article 50 donne les détails, et rien de tout cela n'est un conseil juridique.
• Les petits projets lents. Deux langues que l'équipe lit, quelques versions par an : un processus par lots convient. La livraison à l'exécution vaut tout de même généralement la peine, parce qu'une correction de coquille sans déploiement est utile à toute taille.

Comment cela fonctionne dans Locize

Locize a été construit par l'équipe d'i18next autour de ce workflow précis, et les quatre étapes correspondent à quatre pièces :

• Détecter : saveMissing avec i18next-locize-backend signale les clés depuis l'application en cours d'exécution ; la CLI et les GitHub Actions le font depuis le pipeline, y compris la synchronisation par différence pour les pull requests.
• Traduire : la traduction automatique rédige les ébauches des nouvelles clés avec le glossaire et le guide de style comme contexte ; traducteurs et relecteurs travaillent dans l'éditeur.

De nouvelles clés arrivant du code et ébauchées dans chaque langue cible par la traduction automatique, marquées à relire

• Publier : les propositions de relecture et les marques « à relire » contrôlent ce qui passe en ligne, les versions et les branches le préparent, et les contrôles automatiques s'exécutent à chaque enregistrement.
• Livrer : les traductions approuvées sont publiées sur le CDN par défaut, avec un cache par version ; l'application les charge à l'exécution.

À quoi cela ressemble en pratique, avec la comparaison à un workflow par lots et les équipes qui livrent ainsi, est sur la page de localisation continue. La vue d'ingénierie de la même transition, comment un transfert par lots casse le déploiement continu et à quoi ressemble le pipeline câblé, est dans comment les workflows de traduction par lots cassent le déploiement continu.

Si vous voulez mesurer votre propre délai chaîne-vers-production : créez un projet, connectez un namespace, et chronométrez la prochaine clé du commit jusqu'à chaque langue.

Questions fréquentes

Qu'est-ce que la localisation continue ? Un workflow de traduction dans lequel les chaînes nouvelles et modifiées passent automatiquement et en continu de la base de code aux personnes ou aux systèmes qui les traduisent, en parallèle du développement, et dans lequel les traductions approuvées sont livrées à l'application en production sans nouvelle version. C'est le pendant, pour la localisation, de l'intégration continue et de la livraison continue.

En quoi la localisation continue diffère-t-elle de la localisation traditionnelle ? Dans un workflow par lots, les chaînes attendent : gel, export, traduction, import, redéploiement. En localisation continue, rien n'attend une coupure : les chaînes sont détectées au moment où elles sont écrites, traduites pendant que le développement continue, contrôlées par la relecture plutôt que par un gel, et livrées à l'exécution. La différence est l'endroit où les chaînes attendent entre le moment où elles sont écrites et celui où elles sont en ligne.

Que faut-il pour mettre en place la localisation continue ? Des clés qui naissent dans le code, un endroit où traducteurs, traduction automatique et IA y travaillent avec du contexte, un point de contrôle de relecture et de publication, et un chemin de livraison qui atteint l'application en production sans redéploiement, généralement un CDN. Le versionnage et les contrôles de cohérence sur l'ensemble du corpus sont les deux ajouts dont la plupart des équipes ont besoin ensuite.

La localisation continue signifie-t-elle une traduction IA sans relecture humaine ? Non. Continu décrit le flux, pas la politique de qualité. L'IA fournit la première ébauche pour que rien n'attende ; ce qui est publié est décidé par des contrôles, un score de quality estimation et une relecture humaine là où c'est nécessaire. Une sortie machine non relue poussée directement en production est continue et non gouvernée.

La localisation continue vaut-elle la peine pour une petite équipe ? Quand la traduction est une dépendance des versions : plusieurs déploiements par semaine, plus d'une poignée de langues, des non-développeurs qui modifient du texte, ou des corrections qui doivent partir plus vite que le cycle de version. Une petite équipe avec deux langues qu'elle lit elle-même peut garder un processus par lots ; la livraison à l'exécution vaut tout de même généralement la peine.