Localisation continue : comment garder les traductions synchronisées avec votre base de code

Localisation continue : comment garder les traductions synchronisées avec votre base de code

TL;DR / Points clés

• La localisation continue traite la traduction comme une étape de pipeline permanente, et non comme une tâche ponctuelle au moment de la release — de la même façon que CI/CD traite les tests et le déploiement.
• Les workflows de traduction par lots s'effondrent à mesure que les cadences de release s'accélèrent : les chaînes deviennent obsolètes, les conflits de merge s'accumulent, et les traducteurs perdent le contexte.
• Un pipeline de localisation continue fonctionnel comporte six étapes : changement de code, extraction de chaînes, déclenchement de la traduction, révision, merge et déploiement. Chaque étape peut être automatisée à des degrés divers.
• Les patterns d'intégration clés diffèrent dans la façon dont ils déclenchent la synchronisation : webhooks depuis votre VCS, commandes CLI push/pull dans les étapes CI, observateurs de fichiers pour le développement local, et livraison OTA/CDN pour les mises à jour sans redéploiement.
• Aucun outil unique ne résout chaque partie de ce problème. La bonne configuration dépend de votre cadence de release, du nombre de langues, du workflow des traducteurs, et de l'importance des mises à jour over-the-air pour votre produit.

Qu'est-ce que la localisation continue ?

La localisation continue est la pratique d'intégrer la traduction dans votre cycle de développement logiciel comme un processus continu et automatisé, plutôt que comme une étape manuelle qui se produit une fois par cycle de release.

Pour comprendre pourquoi cela est important, considérez le contraste avec l'approche traditionnelle — souvent appelée traduction par lots ou traduction en cascade. Dans un workflow par lots, un développeur termine une fonctionnalité, un chef de produit collecte toutes les nouvelles chaînes dans une feuille de calcul ou un export, un responsable de la localisation les soumet aux traducteurs (internes ou externes), les traductions reviennent des jours ou des semaines plus tard, un développeur les importe, et la release attend que la dernière locale soit terminée. Ce cycle fonctionnait raisonnablement bien quand les logiciels étaient livrés trimestriellement. Il s'effondre quand les équipes livrent chaque semaine ou chaque jour.

L'analogie avec CI/CD est directe. Avant l'intégration continue, les développeurs travaillaient sur des branches longue durée, l'intégration se produisait tardivement, et le coût des conflits de merge augmentait avec le temps. CI a poussé l'intégration plus tôt et plus fréquemment, réduisant considérablement ce coût. La localisation continue fait de même pour les traductions : au lieu d'accumuler des changements de chaînes sur un sprint et de les réconcilier au moment de la release, chaque changement de code déclenche immédiatement le pipeline de traduction.

Cette approche est parfois appelée localisation shift-left — le même concept « shift left » appliqué aux tests, où détecter les problèmes plus tôt est moins coûteux que de les détecter plus tard. Une chaîne qui entre dans le pipeline de traduction le jour où elle est écrite est traduite avec tout le contexte, sans pression de carnet de commandes, et sans risque de bloquer la release. Une chaîne qui entre dans le pipeline la veille de la release est traduite sous pression, souvent sans contexte, souvent dans un lot avec 400 autres chaînes, et souvent incorrectement dès la première fois.

La localisation continue ne signifie pas que chaque chaîne est traduite et livrée en quelques heures. La traduction automatique peut combler ce manque pour la vitesse, avec une révision humaine qui suit. Ce que cela signifie structurellement, c'est que le pipeline est toujours en fonctionnement : les nouvelles chaînes affluent automatiquement, les files d'attente des traducteurs sont mises à jour de façon incrémentielle, et les traductions retournent dans la base de code ou la couche de livraison sans qu'un humain orchestre chaque transfert.

Pourquoi la traduction par lots s'effondre

La traduction par lots n'est pas intrinsèquement mauvaise — pour les projets qui livrent rarement ou qui gèrent un petit nombre de chaînes, c'est une approche raisonnable. Mais pour les équipes d'ingénierie qui utilisent des pipelines CI/CD, les workflows par lots créent quatre modes de défaillance spécifiques.

Retards de release. Lorsque la traduction est un prérequis pour la livraison, et que la traduction est une tâche par lots déclenchée après le gel des fonctionnalités, le calendrier de release est contraint par le débit des traducteurs. Les équipes qui livrent en continu ne peuvent pas accepter une étape de localisation qui prend cinq jours ouvrables. La release est soit livrée sans chaînes traduites (avec la langue source en substitution, souvent l'anglais), soit elle attend — aucune des deux options n'est acceptable à grande échelle.

Obsolescence des traductions. Dans un modèle par lots, les chaînes sont souvent exportées depuis une base de code qui a déjà évolué. Au moment où les traductions arrivent, les chaînes elles-mêmes peuvent avoir changé — un libellé de bouton a été reformulé, un écran a été redesigné, une fonctionnalité a été supprimée. Les traducteurs travaillent à partir d'un instantané obsolète. Le résultat est des traductions qui ne correspondent pas au produit en production, ou un travail de traduction qui doit être abandonné et repris.

Conflits de merge dans les fichiers de traduction. Lorsque plusieurs développeurs travaillent en parallèle et que les fichiers de traduction résident dans le dépôt (en JSON, YAML, XLIFF ou similaire), les modifications simultanées de ces fichiers produisent des conflits de merge. Contrairement aux conflits dans la logique applicative, les conflits dans les fichiers de traduction sont fastidieux et sujets aux erreurs à résoudre : deux branches ont toutes les deux ajouté de nouvelles clés, supprimé une clé, renommé une clé différemment. Plus le lot est grand, pires sont les conflits.

Friction développeur-traducteur. Dans un workflow par lots, le transfert entre développeur et traducteur est un processus manuel, souvent asynchrone, qui repose sur des conventions qui s'effondrent sous la pression du temps. Les développeurs oublient d'exporter. Les traducteurs reçoivent des fichiers sans contexte. Les clés sont renommées entre l'export et l'import. Les imports écrasent les modifications apportées directement par les traducteurs. Aucun de ces échecs n'est catastrophique individuellement — mais ils s'accumulent. Au fil du temps, la friction pousse les équipes à déprioritiser la qualité de la localisation, et la dette de localisation s'accumule de la même façon que la dette technique.

Le pipeline de localisation continue

Un pipeline de localisation continue fait passer les changements de chaînes par six étapes. Le pipeline est déclenché par un changement de code, et non par une décision humaine. Chaque étape produit une sortie déterministe que l'étape suivante peut consommer sans intervention manuelle.

Changement de code
    |
    v
Extraction de chaînes
    |
    v
Déclenchement de la traduction
    |
    v
Traduction (MT + révision humaine)
    |
    v
Merge dans le dépôt (ou push vers CDN)
    |
    v
Déploiement (ou mise à jour OTA, si basé CDN)

Étape 1 : Changement de code. Un développeur ajoute, modifie ou supprime une chaîne traduisible dans la base de code. Avec une bonne configuration i18n, cela signifie mettre à jour un fichier clé-valeur (JSON, YAML, XLIFF) ou ajouter une référence de clé dans le code qui se résout au moment de l'exécution.

Étape 2 : Extraction de chaînes. Le pipeline identifie quelles chaînes sont nouvelles, modifiées ou supprimées en comparant l'état actuel avec l'instantané d'extraction précédent. Cela est généralement géré par la CLI de l'outil de localisation ou un script CI. La sortie est un diff des changements de chaînes — non pas un export complet de toutes les chaînes, mais seulement le delta. Les outils qui calculent des exports complets à chaque exécution au lieu de diffs créent un travail de traducteur inutile et rendent plus difficile la priorisation des nouvelles chaînes.

Étape 3 : Déclenchement de la traduction. Les chaînes nouvelles et modifiées sont envoyées au système de gestion de traduction (TMS). Cela peut se produire via un webhook (un événement VCS déclenche un appel API vers le TMS), une étape CI (une commande CLI pousse le diff de chaînes après un build réussi), ou un observateur de fichiers (en développement, un agent local surveille les changements de fichiers et se synchronise en continu). Le déclenchement doit être automatique — exiger qu'un humain initie cette étape réintroduit le problème des lots.

Étape 4 : Traduction. Les traducteurs (humains ou machines, ou une combinaison) travaillent sur les nouvelles chaînes dans le TMS. Les systèmes bien conçus fournissent des captures d'écran, le contexte du composant, des limites de caractères, et les chaînes adjacentes pour aider les traducteurs à produire des traductions précises sans allers-retours. La traduction automatique peut produire des premiers brouillons automatiquement ; les réviseurs humains se concentrent sur l'exactitude, la voix de la marque, et les corrections sensibles au contexte.

Étape 5 : Merge. Les traductions terminées sont repoussées vers le dépôt sous forme de pull request ou committées directement sur une branche de traduction, selon votre modèle de gouvernance. Pour les plateformes OTA-capables, cette étape pousse les chaînes traduites vers un CDN ou un endpoint API — contournant entièrement le dépôt pour le chemin de livraison.

Étape 6 : Déploiement. Pour la livraison basée sur des fichiers, les traductions sont bundlées dans le prochain build et déployées avec l'application. Pour la livraison basée sur CDN, les traductions sont déjà disponibles en live à la périphérie — l'application les récupère à la prochaine requête sans nouveau déploiement.

Le principe de conception critique est que les étapes 2 à 5 doivent être entièrement automatisées pour le contenu traduit par machine, avec la révision humaine comme couche optionnelle qui améliore la qualité mais ne bloque pas la livraison. La révision humaine doit être asynchrone : publiez d'abord la traduction MT, remplacez-la par la traduction révisée quand elle est prête.

Patterns d'intégration

La façon dont vous connectez votre base de code à votre pipeline de traduction détermine la quantité de ce qui précède qui peut réellement être automatisée. Il existe quatre patterns d'intégration principaux, chacun avec des compromis différents.

Webhook VCS. Votre plateforme d'hébergement de dépôt (GitHub, GitLab, Bitbucket) envoie un événement HTTP au TMS lorsqu'un commit ou une pull request est créé. Le TMS analyse la charge utile, identifie quels fichiers ont changé, extrait les nouvelles chaînes, et les met en file d'attente pour traduction. Cela ne nécessite aucune modification de votre pipeline CI et fonctionne même sur des branches avant qu'elles ne fusionnent dans main. La limitation est que le TMS doit comprendre votre format de fichier et la structure du projet — la configuration se fait côté TMS, pas dans votre base de code.

Étape CI (CLI). Votre pipeline CI comprend une étape qui exécute la CLI du TMS pour pousser les nouvelles chaînes et optionnellement tirer les chaînes traduites. C'est le pattern le plus flexible car le script s'exécute dans votre environnement CI avec un accès complet au contexte de build. Le marketplace GitHub Actions et GitLab CI incluent des actions officielles ou maintenues par la communauté pour la plupart des principales plateformes TMS. Le compromis est que vous devez gérer la version de la CLI, les credentials d'authentification comme secrets, et l'ordre des étapes push/pull par rapport aux étapes de build.

Observateur de fichiers. Un daemon local surveille vos répertoires de fichiers de traduction et synchronise les modifications avec le TMS en temps réel pendant que vous écrivez du code. C'est principalement un outil d'expérience développeur : les traducteurs voient les nouvelles chaînes dans les secondes qui suivent leur ajout par un développeur, plutôt que d'attendre une exécution CI. Ce n'est pas adapté comme mécanisme de pipeline de production car cela dépend d'un développeur ayant le daemon en fonctionnement et nécessite une configuration locale cohérente dans toute l'équipe.

OTA / Livraison CDN. Plutôt que de committer les chaînes traduites dans le dépôt et de les bundler dans un déploiement, l'application récupère les traductions au moment de l'exécution depuis un CDN ou une API. Les mises à jour des traductions sont immédiatement disponibles mondialement sans nouveau build ou déploiement. Ce pattern nécessite que l'application soit conçue pour le chargement de traductions au moment de l'exécution — ce qui est standard dans la plupart des bibliothèques i18n modernes — et introduit une dépendance d'exécution sur le CDN. C'est le pattern le plus opérationnellement agile pour les chaînes d'interface utilisateur.

La plupart des configurations de production combinent les patterns : une étape CI (ou webhook) pour garder le TMS synchronisé avec la base de code, plus la livraison CDN pour les mises à jour de chaînes qui ne nécessitent pas un nouveau déploiement.

Capacités clés à rechercher

Toutes les plateformes de localisation ne supportent pas la vraie localisation continue. Lors de l'évaluation des outils, ce sont les capacités qui déterminent si une plateforme peut réellement être intégrée dans un pipeline CI/CD plutôt qu'utilisée comme un portail de traduction manuel.

Détection automatique des chaînes nouvelles et modifiées. La plateforme doit identifier les changements de chaînes automatiquement à partir d'un diff de fichier ou d'un événement VCS, sans nécessiter un export manuel. Les plateformes qui nécessitent d'exporter un fichier complet et de le réimporter à chaque changement ne sont pas conçues pour les workflows continus.

Contexte pour les traducteurs. Les traducteurs qui travaillent sur des chaînes individuelles en isolation produisent des traductions de moins bonne qualité que les traducteurs qui peuvent voir où une chaîne apparaît dans l'interface. Les meilleures plateformes acceptent des captures d'écran, des métadonnées de composants, ou l'édition en contexte qui montre la chaîne rendue dans le produit réel. Sans contexte, les chaînes courtes comme « Enregistrer », « Voir », ou « Annuler » sont régulièrement mal traduites car leur signification est ambiguë hors contexte.

Support des branches. Si votre équipe utilise des branches de fonctionnalités, votre plateforme de localisation doit supporter des branches de traduction qui reflètent vos branches VCS. Les chaînes sur une branche de fonctionnalité doivent être traduisibles avant que la branche ne fusionne dans main — sinon les traductions sont toujours en retard sur le code d'au moins un cycle de merge.

Pseudo-localisation pour les tests. La pseudo-localisation remplace les caractères dans les chaînes source par des caractères latin étendus visuellement similaires pour simuler du texte traduit sans traduction réelle. Elle détecte les bugs de mise en page — dépassement de texte, libellés tronqués, hypothèses de largeur codées en dur — tôt dans le développement, avant que les vraies traductions ne soient disponibles. Une plateforme qui supporte la génération automatique de pseudo-locale permet les tests d'interface utilisateur dans n'importe quelle locale à n'importe quel stade du développement.

Mises à jour over-the-air (OTA) sans redéploiement. Pour les applications où livrer un nouveau build pour mettre à jour une traduction est trop lent ou trop coûteux — applications mobiles, applications desktop, ou applications web à haute fréquence — la livraison OTA est essentielle. La plateforme doit servir les traductions depuis un cache edge distribué mondialement avec une faible latence et une invalidation automatique du cache lorsque les traductions sont publiées.

Mémoire de traduction et application de la cohérence. La mémoire de traduction réutilise les chaînes précédemment traduites entre les projets et les contextes, réduisant l'effort des traducteurs et améliorant la cohérence. L'application de la cohérence signale les chaînes qui correspondent à un terme précédemment traduit mais qui ont été traduites différemment — détectant la dérive terminologique dans un grand projet.

Pièges courants

Les pipelines de localisation continue introduisent des modes de défaillance spécifiques qui sont distincts des problèmes de workflow manuel. Voici les plus courants.

Sur-automatiser sans couche QA. Les pipelines de traduction automatique entièrement automatisés peuvent livrer des traductions à grande vitesse. Ils peuvent aussi livrer des traductions incorrectes à grande vitesse. La traduction automatique sans révision humaine est appropriée pour les outils internes et les chaînes d'interface de faible importance. Pour les textes marketing orientés clients, les mentions légales, les messages d'erreur, ou tout ce qui reflète la voix de la marque, une étape de révision humaine n'est pas optionnelle. Concevez votre pipeline de sorte que les traductions MT soient publiées immédiatement comme solution de repli, avec les traductions révisées par des humains qui les remplacent de manière asynchrone — ne bloquez pas la publication sur la révision humaine, mais ne traitez pas MT comme final pour tout le contenu.

Ignorer le contexte pour les traducteurs. Automatiser le transfert des chaînes sans automatiser le transfert du contexte crée un pipeline rapide qui produit des traductions de mauvaise qualité. Une clé de chaîne comme checkout.button.primary sans capture d'écran, description, ni limite de caractères dit presque rien à un traducteur. Intégrez la livraison du contexte dans votre pipeline dès le début — il est beaucoup plus difficile de le retrofitter.

Casser la mémoire de traduction avec les renommages de clés. La mémoire de traduction associe les traductions aux chaînes source ou aux clés de chaînes, selon la plateforme. Lorsque les développeurs renomment des clés — par exemple, changer user.save_button en profile.save_changes — le TMS traite souvent cela comme une clé supprimée et une nouvelle clé non traduite. Tout le travail de traduction précédent pour cette chaîne est perdu de la TM. Établissez une politique de renommage de clés : soit traitez les renommages de clés comme une opération deprecated-and-create (en conservant l'ancienne clé jusqu'à confirmation des traductions), soit utilisez un TMS qui suit l'identité des chaînes à travers les changements de clés en utilisant un hash de contenu plutôt que le nom de la clé seul.

Ne pas gérer les clés supprimées. Lorsqu'une chaîne est supprimée de la source, la plupart des plateformes laissent ses traductions dans le TMS indéfiniment. Au fil du temps, cela crée des traductions orphelines qui gaspillent le stockage, confondent les traducteurs, et rendent inexact le reporting sur la complétude des traductions. Mettez en place un cycle de purge régulier — via un script CI ou une règle d'automatisation TMS — qui supprime les traductions pour les clés qui n'existent plus dans la source.

Traiter toutes les locales de la même façon. Différentes locales ont des vitesses de traduction différentes en fonction de la disponibilité des traducteurs, de la complexité de la paire de langues, et des exigences de révision. Un pipeline qui bloque le déploiement jusqu'à ce que toutes les locales aient terminé la traduction sera fréquemment bloqué par la locale la plus lente. Concevez votre pipeline pour déployer avec les locales traduites qui sont prêtes et se replier sur la langue source pour les locales qui ne le sont pas — avec une alerte lorsqu'une locale tombe en dessous d'un seuil de complétude que vous définissez.

Outils qui supportent la localisation continue

Voici les outils les plus couramment utilisés dans les pipelines de localisation continue pilotés par l'ingénierie. Chacun a des forces honnêtes et des limites réelles.

Crowdin CLI. Le client en ligne de commande de Crowdin s'intègre étroitement avec GitHub, GitLab, et Bitbucket via des intégrations natives et le support des webhooks. Il supporte les branches, dispose d'une large bibliothèque de formats de fichiers (JSON, YAML, XLIFF, Android XML, iOS Strings, et bien d'autres), et offre une mémoire de traduction robuste. L'intégration CI est bien documentée. Limitations : le modèle de branches peut être difficile à configurer pour les monorepos complexes, et la livraison OTA nécessite la fonctionnalité Crowdin OTA disponible sur les plans de niveau supérieur.

Transifex. Transifex bénéficie d'un support d'intégration CI/CD de longue date via sa CLI et ses webhooks. Il a introduit « Live Translation » pour la livraison OTA basée sur le web — un snippet JavaScript qui intercepte les nœuds de texte et les remplace par du contenu traduit depuis un CDN. Cette approche fonctionne sans aucune modification du processus de build de l'application, ce qui est utile pour les équipes qui ne peuvent pas facilement modifier le pipeline de build. L'approche Live a des compromis de performance car elle opère au niveau du DOM.

Lokalise CI. Lokalise dispose d'une intégration forte avec GitHub Actions et GitLab CI, d'un workflow contributeur bien conçu pour la révision des traductions, et supporte OTA via ses SDKs pour iOS, Android, et web. Son support des branches est plus élaboré que la plupart des concurrents. L'éditeur web dispose d'un bon support du contexte basé sur les captures d'écran. Lokalise est généralement positionné sur le marché mid-to-enterprise avec une tarification qui le reflète.

Phrase CLI (anciennement Phrase Strings). Phrase (anciennement Memsource et PhraseApp, maintenant sous une marque unifiée) dispose d'une CLI complète, d'un fort support XLIFF (utile pour les équipes avec des agences de traduction professionnelles qui préfèrent les workflows XLIFF), et de fonctionnalités matures de mémoire de traduction et d'assurance qualité. Il est particulièrement fort dans les workflows d'agences de traduction professionnelles. Son intégration CI est solide mais nécessite plus de configuration que Crowdin ou Lokalise pour l'automatisation native VCS.

Better i18n. Better i18n adopte une approche developer-first avec une CLI, des SDKs React/Next.js/Vue/Svelte, et une livraison basée CDN via le réseau edge de Cloudflare. Son modèle OTA signifie que les mises à jour de traduction sont disponibles mondialement dans les secondes suivant la publication — sans déclencher un nouveau build ou déploiement. Il supporte les traductions assistées par IA pour les premiers brouillons et est orienté vers les équipes d'ingénierie qui souhaitent gérer les traductions proches de la base de code. Son intégration CI est simple via la CLI. Début 2026, il est à un stade plus précoce que Crowdin, Lokalise, ou Phrase, avec un ensemble de fonctionnalités plus restreint dans des domaines tels que les workflows XLIFF et l'SSO enterprise.

FAQ

Q : Peut-on utiliser la localisation continue si nos traducteurs ne sont pas techniques ?

Oui. L'automatisation du pipeline est du côté de l'ingénierie. Les traducteurs interagissent uniquement avec l'interface web du TMS, où ils voient les chaînes dans un éditeur de traduction — pas des fichiers YAML ou des commandes Git. L'automatisation gère l'extraction des chaînes du code, leur envoi au TMS, et le merge des traductions en retour. L'expérience des traducteurs est largement déterminée par la qualité de l'éditeur TMS et le contexte que vous fournissez, pas par les mécaniques du pipeline.

Q : Comment gérer les branches de fonctionnalités qui n'ont pas encore fusionné ?

La plupart des plateformes TMS supportent des branches de traduction qui reflètent les branches VCS. Vous configurez un mapping de branches — par exemple, les branches de fonctionnalités correspondant à feat/* se synchronisent avec les branches TMS correspondantes. Les traducteurs peuvent travailler sur les chaînes d'une branche de fonctionnalité avant qu'elle ne fusionne. Lorsque la branche fusionne dans votre VCS, la branche TMS fusionne aussi, et les traductions sont conservées. Cela nécessite un TMS qui supporte explicitement les branches — ce que tous ne font pas.

Q : Les traductions doivent-elles résider dans le dépôt ou dans le TMS ?

Idealement les deux. Le dépôt est la source de vérité pour les chaînes source (les chaînes que les développeurs écrivent). Le TMS est la source de vérité pour les chaînes traduites. Votre pipeline synchronise entre les deux : les chaînes source vont du dépôt vers le TMS, les chaînes traduites vont du TMS vers le dépôt (ou vers un CDN). Stocker les chaînes traduites uniquement dans le dépôt sans TMS rend difficile la contribution des non-développeurs. Les stocker uniquement dans le TMS sans synchronisation vers le dépôt rend difficile la reproduction déterministe des builds.

Q : Comment mesurer la santé de notre pipeline de localisation ?

Suivez ces quatre métriques : couverture de traduction (pourcentage de chaînes source avec une traduction par locale), délai de traduction (temps entre l'ajout d'une chaîne à la source et la publication de sa première traduction), backlog de révision (nombre de chaînes traduites par machine en attente de révision humaine), et taux de clés orphelines (traductions dans le TMS pour des clés qui n'existent plus dans la source). Un pipeline sain a une couverture élevée, un délai faible, un backlog de révision gérable, et un taux de clés orphelines quasi nul.

Q : Quelle est la configuration minimale viable de localisation continue pour une petite équipe ?

Pour une équipe de deux à cinq ingénieurs livrant un produit web : une seule étape CI qui exécute la CLI du TMS pour pousser les nouvelles chaînes source à chaque merge dans main, la traduction automatique activée pour les premiers brouillons, et une session hebdomadaire de révision des traducteurs pour les chaînes les plus visibles par les clients. Cela seul élimine la traduction par lots bloquante pour les releases et la plupart des conflits de merge. La livraison OTA et le support des branches peuvent être ajoutés plus tard à mesure que le produit et le workflow des traducteurs mûrissent.

Conclusion

La localisation continue est l'extension logique de la pensée CI/CD à la couche de traduction de votre produit. L'insight fondamental est que la traduction n'est pas un jalon de release — c'est une étape de pipeline. Lorsque les chaînes sont extraites, transmises aux traducteurs, révisées, et mergées automatiquement dans le cadre de votre flux de développement normal, les coûts qui rendent la localisation pénible dans les workflows par lots — retards de release, traductions obsolètes, conflits de merge, friction développeur-traducteur — sont réduits à des problèmes d'ingénierie avec des solutions d'ingénierie.

Le pipeline décrit dans cet article n'est pas hypothétique. Les équipes de sociétés livrant dans des dizaines de locales en font tourner des variantes en production. Les spécificités varient — quel TMS, quel système CI, si la livraison OTA est dans le périmètre, combien de révision humaine est nécessaire — mais la structure est cohérente : automatiser le travail mécanique, fournir le contexte pour le travail humain, et traiter la complétude des traductions comme une métrique continue plutôt qu'une porte de release binaire.

Commencez par le changement à moindre friction disponible pour votre équipe : une étape CI qui pousse les nouvelles chaînes vers votre TMS à chaque merge sur la branche main. De là, ajoutez le support des branches, la livraison du contexte, les mises à jour OTA, et les vérifications automatisées de qualité de façon incrémentielle. Chaque couche réduit la friction et améliore la qualité sans nécessiter une reconstruction complète du pipeline.

L'objectif est un workflow de localisation invisible pour les développeurs — un dans lequel livrer dans une nouvelle locale est un changement de configuration, pas un projet.

Références

[^1]: Martin Fowler, "Continuous Integration," martinfowler.com, https://martinfowler.com/articles/continuousIntegration.html

[^2]: W3C Internationalization Working Group, "Internationalization Best Practices for Spec Developers," W3C Working Group Note, https://www.w3.org/TR/international-specs/

[^3]: OASIS XLIFF Technical Committee, "XLIFF Version 2.1," OASIS Standard, https://docs.oasis-open.org/xliff/xliff-core/v2.1/os/xliff-core-v2.1-os.html

[^4]: GitHub Actions documentation, "Events that trigger workflows," https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows

[^5]: GitLab CI/CD documentation, "GitLab CI/CD pipeline configuration reference," https://docs.gitlab.com/ee/ci/yaml/

[^6]: Unicode CLDR Project, "Unicode Common Locale Data Repository," https://cldr.unicode.org/

[^7]: IETF BCP 47, "Tags for Identifying Languages," https://www.rfc-editor.org/rfc/rfc5646

[^8]: Crowdin documentation, "CLI tool," https://developer.crowdin.com/cli-tool/

[^9]: Lokalise documentation, "CI/CD integrations," https://lokalise.com/blog/continuous-localization/

[^10]: Phrase documentation, "Phrase Strings CLI," https://support.phrase.com/hc/en-us/articles/5784095916188

Dernière mise à jour : mars 2026