Continuous Localization — Le guide pour les équipes produit
La localisation est souvent traitée comme une étape à part : on développe, on traduit, on déploie. Ce modèle en cascade génère des délais, des frictions, et une dette de traduction qui s'accumule sprint après sprint.
La localisation continue (continuous localization) est une approche différente : les traductions s'intègrent dans le flux de développement, de la même façon que les tests automatisés ou les déploiements CI/CD. Chaque modification du code source déclenche automatiquement la mise à jour des traductions.
Ce guide explique pourquoi, comment, et avec quels outils mettre en place ce modèle dans votre organisation.
Pourquoi le modèle traditionnel ne fonctionne plus
Q : Qu'est-ce que le modèle de localisation en cascade ?
Le modèle classique ressemble à ça :
Développement → Freeze → Export → Traduction → Import → QA → Déploiement
Chaque étape attend la précédente. La traduction est un goulot d'étranglement qui bloque ou ralentit les releases.
Q : Quels sont les problèmes concrets de ce modèle ?
Délais de release. Les équipes attendent les traductions avant de déployer, ou déploient avec des clés manquantes. Les deux options sont mauvaises.
Coût de contexte. Quand un traducteur reçoit des chaînes plusieurs semaines après leur écriture, le contexte est perdu. La qualité en souffre.
Accumulation de dette. En mode agile avec des releases fréquentes, les traductions ne suivent jamais. Chaque sprint ajoute des clés non traduites.
Friction organisationnelle. Les développeurs, les PM et les traducteurs travaillent dans des systèmes différents, avec des processus de handoff manuels.
Les principes de la localisation continue
Q : Qu'est-ce que la localisation continue concrètement ?
La localisation continue repose sur quatre principes :
1. Les traductions font partie du pipeline de déploiement. Comme les tests, comme le lint, comme le build — la traduction est un step automatisé, pas une étape manuelle externe.
2. Le fichier source est la source de vérité. Il n'y a qu'un seul endroit où les chaînes sont définies. Les fichiers traduits sont générés, pas maintenus manuellement.
3. Les mises à jour sont incrémentales. On ne traduit pas tout à chaque release. On traduit uniquement les clés nouvelles ou modifiées.
4. La validation humaine reste possible, mais n'est pas un goulot. Les traductions IA sont disponibles immédiatement. La révision humaine s'intègre dans le workflow sans bloquer le déploiement.
Mettre en place la localisation continue
Étape 1 : Structurer votre fichier source
Q : Comment structurer ses fichiers de traduction pour la localisation continue ?
La règle de base : un seul fichier source dans votre langue principale, organisé par namespaces fonctionnels.
// messages/fr.json (ou en.json si votre langue source est l'anglais)
{
"nav": {
"home": "Accueil",
"pricing": "Tarifs",
"docs": "Documentation"
},
"auth": {
"login": "Se connecter",
"register": "Créer un compte",
"logout": "Déconnexion"
},
"dashboard": {
"projects": {
"empty": "Aucun projet pour l'instant.",
"count": "{count, plural, =0 {Aucun projet} =1 {1 projet} other {# projets}}"
}
}
}
Ce fichier est la seule chose que votre équipe maintient manuellement. Tout le reste est généré.
Étape 2 : Brancher la synchronisation GitHub
Q : Comment déclencher les traductions automatiquement sur chaque push ?
Avec Jason, la configuration prend moins de 15 minutes :
- Connectez votre repository GitHub dans Jason
- Indiquez le chemin de votre fichier source
- Choisissez vos langues cibles
- Jason génère un webhook URL à ajouter dans GitHub
À partir de là, chaque push qui modifie votre fichier source déclenche automatiquement :
- Détection des clés nouvelles ou modifiées
- Génération des traductions IA
- Ouverture d'une Pull Request sur votre repo
Étape 3 : Intégrer dans le CI/CD
Q : Comment intégrer les traductions dans un pipeline CI/CD existant ?
Pour les équipes qui veulent un contrôle plus fin, l'API Jason et le CLI permettent d'intégrer les traductions dans vos workflows GitHub Actions ou autres outils CI.
# .github/workflows/translate.yml
name: Translate on source change
on:
push:
paths:
- 'messages/fr.json'
jobs:
translate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Trigger Jason translation
run: |
curl -X POST https://api.[DOMAINE]/v1/translate \
-H "Authorization: Bearer ${{ secrets.JASON_API_KEY }}" \
-H "Content-Type: application/json" \
-d '{"project": "mon-projet", "langs": ["en", "es", "de"]}'
Étape 4 : Définir le workflow de validation
Q : Comment gérer la validation humaine sans créer un goulot ?
La clé est de découpler la traduction du déploiement. Deux approches :
Approche merge-first : les traductions IA sont mergées automatiquement. L'équipe révise asynchronement et ouvre des PRs correctives si nécessaire. Convient aux équipes qui font confiance à la qualité IA et veulent déployer rapidement.
Approche review-first : la PR de traduction passe par un reviewer avant d'être mergée. Le reviewer utilise le dashboard Jason pour approuver, modifier ou rejeter des clés individuellement. Convient aux produits où la qualité linguistique est critique (secteur médical, juridique, financier).
Continuous Localization à grande échelle
Q : Comment les grandes équipes organisent-elles leur workflow de localisation ?
Les organisations matures adoptent généralement un modèle en trois niveaux :
Niveau 1 — Automatisation complète pour les clés de faible risque (labels UI, messages d'erreur génériques, notifications). La traduction IA est mergée directement.
Niveau 2 — Révision légère pour les contenus marketing et les onboarding flows. Un reviewer valide dans le dashboard Jason avant le merge.
Niveau 3 — Traduction humaine pour les contenus à fort enjeu juridique ou réputationnel. Les traducteurs professionnels travaillent sur les clés marquées comme prioritaires.
Q : Jason peut-il gérer plusieurs équipes produit avec des projets différents ?
Oui. Jason permet de créer autant de projets que nécessaire, d'assigner des langues par projet, et d'inviter des membres d'équipe ou des traducteurs avec des permissions granulaires.
Q : Est-ce que la localisation continue fonctionne pour des applications mobile ?
Oui. Le principe est le même. Les formats diffèrent selon la plateforme (iOS utilise .strings, Android utilise strings.xml), mais Jason supporte les formats courants et la logique de synchronisation reste identique.
Métriques pour mesurer votre maturité
Q : Comment savoir si sa localisation continue fonctionne bien ?
Quatre indicateurs à suivre :
Translation lag : délai entre le merge d'une clé source et sa disponibilité dans toutes les langues. En localisation continue, ce délai devrait être inférieur à 24h.
Coverage rate : pourcentage de clés traduites dans chaque langue. L'objectif est 100% en permanence.
Review backlog : nombre de traductions en attente de validation. Un backlog qui grossit signale soit un problème de qualité IA, soit un processus de review trop lourd.
Missing key incidents : nombre de fois où une clé manquante est détectée en production. En localisation continue bien configurée, ce chiffre devrait être zéro.
En résumé
La localisation continue n'est pas une fonctionnalité, c'est une pratique d'ingénierie. Elle consiste à traiter les traductions comme du code : versionnées, automatisées, intégrées au pipeline de déploiement.
Les équipes qui adoptent ce modèle arrêtent de gérer des traductions. Elles déploient des produits multilingues.