Concevez une application web pour gérer les workflows de traduction : données de locale, relectures, vérifications QA et releases. Comprend modèle de données, UX et intégrations.
La gestion de la localisation, c’est le travail quotidien consistant à faire traduire, relire, approuver et livrer les textes de votre produit (et parfois les images, les formats de date, les devises et les règles de formatage) — sans casser la build ni embrouiller les utilisateurs.
Pour une équipe produit, l’objectif n’est pas de « traduire tout ». C’est de garder chaque version linguistique exacte, cohérente et à jour au fur et à mesure que le produit évolue.
La plupart des équipes partent avec de bonnes intentions et finissent avec un bazar :
Une application utile supporte plusieurs rôles :
Vous construirez un MVP qui centralise les chaînes, suit le statut par locale et supporte la relecture et l’export basiques. Un système plus complet ajoute l’automatisation (sync, vérifications QA), un contexte enrichi et des outils comme le glossaire et la mémoire de traduction.
Avant de dessiner des tables ou des écrans, décidez de ce dont votre appli de gestion de localisation est réellement responsable. Un périmètre serré rend la première version utilisable — et vous évite de tout reconstruire plus tard.
Les traductions n’habitent presque jamais à un seul endroit. Notez ce que vous devez supporter dès le jour 1 :
Cette liste vous évite une approche « un workflow pour tout ». Par exemple, le contenu marketing peut nécessiter des approbations, tandis que les chaînes UI ont besoin d’itération rapide.
Choisissez 1–2 formats pour le MVP, puis étendez. Options courantes : JSON, YAML, PO, CSV. Un choix pratique pour un MVP : JSON ou YAML (pour les chaînes d’app), plus CSV uniquement si vous dépendez déjà des imports par tableur.
Soyez explicite sur des exigences comme les formes plurielles, les clés imbriquées et les commentaires. Ces détails impactent la gestion des fichiers de locale et la fiabilité des imports/exports futurs.
Définissez une langue source (souvent en) et fixez le comportement de fallback :
Décidez aussi ce que signifie « terminé » par locale : 100% traduit, relu ou déployé.
Pour le MVP, concentrez‑vous sur le processus de relecture et le workflow i18n basique : créer/éditer des chaînes, assigner du travail, relire et exporter.
Planifiez des ajouts futurs — captures d’écran/contexte, glossaire, bases de mémoire de traduction, et intégration de traduction automatique — mais ne les construisez pas tant que votre workflow principal n’a pas été validé avec du contenu réel.
Une appli de traduction réussit ou échoue sur son modèle de données. Si les entités et champs sous‑jacents sont clairs, tout le reste — UI, workflow, intégrations — devient plus simple.
La plupart des équipes couvrent 80 % de leurs besoins avec un petit jeu de tables/collections :
en, en-GB, pt-BR).checkout.pay_button).Modélisez explicitement les relations : un Project a plusieurs Locales ; une Key appartient à un Project ; une Translation appartient à une Key et une Locale.
Ajoutez un statut à chaque traduction pour que le système guide les humains :
draft → in_review → approvedblocked pour les chaînes qui ne doivent pas être publiées (revue juridique, contexte manquant, etc.)Conservez les changements de statut comme événements (ou une table d’historique) pour pouvoir répondre plus tard à « qui a approuvé ceci et quand ? ».
Les traductions ont besoin de plus que du simple texte. Capturez :
{name}, %d) et si elles doivent correspondre à la sourceAu minimum, conservez : created_by, updated_by, horodatages, et une courte change_reason. Cela accélère les relectures et renforce la confiance quand les équipes comparent ce qui est dans l’appli vs ce qui a été publié.
Les décisions de stockage vont façonner l’UX d’édition, la vitesse d’import/export, le diffing et la confiance au moment de la livraison.
Row‑per‑key (une ligne DB par clé par locale) est idéal pour les tableaux de bord et workflows. Vous pouvez facilement filtrer « manque en français » ou « besoin de relecture », assigner des propriétaires et calculer l’avancement. L’inconvénient : reconstituer un fichier de locale pour l’export nécessite de grouper et ordonner, et il faudra des champs pour chemins de fichiers et namespaces.
Document‑per‑file (stocker chaque fichier de locale comme document JSON/YAML) correspond bien à la façon dont les dépôts fonctionnent. C’est plus rapide à exporter et plus simple pour maintenir le formatage identique. Mais rechercher et filtrer devient plus compliqué, sauf si vous maintenez aussi un index des clés, statuts et métadonnées.
Beaucoup d’équipes utilisent un hybride : row‑per‑key comme source de vérité, plus des snapshots de fichiers générés pour l’export.
Conservez l’historique des révisions au niveau de l’unité de traduction (clé + locale). Chaque changement doit enregistrer : ancienne valeur, nouvelle valeur, auteur, horodatage et commentaire. Cela rend les relectures et rollbacks simples.
Séparément, suivez les snapshots de release : « ce qui a exactement été publié dans v1.8 ». Un snapshot peut être un tag pointant vers un ensemble cohérent de révisions approuvées à travers les locales. Cela empêche des éditions tardives d’altérer silencieusement une build publiée.
Ne traitez pas « pluriel » comme un simple booléen. Utilisez ICU MessageFormat ou les catégories CLDR (ex. one, few, many, other) afin que des langues comme le polonais ou l’arabe ne soient pas contraintes aux règles anglaises.
Pour le genre et autres variations, modélisez‑les comme variantes du même key (ou message) plutôt que des clés ad hoc séparées, afin que les traducteurs voient le contexte complet.
Implémentez une recherche en texte intégral sur la clé, le texte source, la traduction et les notes développeur. Associez‑la à des filtres correspondant au travail réel : statut (nouveau/traduit/revu), tags, fichier/namespace, et manquant/vide.
Indexez ces champs tôt — la recherche est la fonctionnalité utilisée des centaines de fois par jour.
Une appli de gestion de localisation commence souvent simple — téléverser un fichier, éditer des chaînes, le télécharger. Elle se complique quand vous ajoutez plusieurs produits, de nombreuses locales, des releases fréquentes et un flux d’automatisation permanent (sync, QA, TA, relectures).
La façon la plus simple de rester flexible est de séparer les responsabilités dès le départ.
Une configuration courante et scalable : API + UI web + jobs en arrière‑plan + base de données :
Cette séparation vous aide à ajouter des workers pour les tâches lourdes sans réécrire toute l’appli.
Si vous voulez aller plus vite sur la première version fonctionnelle, une plateforme de prototypage comme Koder.ai peut vous aider à esquisser l’UI (React), l’API (Go) et le schéma PostgreSQL à partir d’un spec structuré et de quelques itérations en chat — puis exporter le code source quand vous êtes prêt à posséder le repo et le déploiement.
Gardez votre API centrée sur quelques ressources clés :
checkout.button.pay).Concevez des endpoints qui servent l’édition humaine et l’automatisation. Par exemple, la liste de clés doit accepter des filtres comme « manquant dans la locale », « changé depuis », ou « nécessite relecture ».
Traitez l’automatisation comme du travail asynchrone. Une queue gère typiquement :
Rendez les jobs idempotents (sécurisés au retry) et enregistrez des logs par projet pour que les équipes puissent s’auto‑diagnostiquer.
Même les petites équipes peuvent générer de grands jeux de données. Ajoutez pagination pour les listes (clés, historique, jobs), mettez en cache les lectures fréquentes (stats de locale par projet) et appliquez des limites de débit pour protéger les endpoints d’import/export et les tokens publics.
Ce sont des détails ennuyeux mais essentiels pour éviter que votre TMS ne ralentisse au moment de l’adoption.
Si votre appli stocke des chaînes sources et l’historique des traductions, le contrôle d’accès n’est pas optionnel — c’est ce qui empêche les modifications accidentelles et rend les décisions traçables.
Un jeu simple de rôles couvre la plupart des équipes :
Traitez chaque action comme une permission pour pouvoir évoluer. Règles communes :
Cela colle bien à un système TMS tout en restant flexible pour des contractuels.
Si l’entreprise utilise Google Workspace, Azure AD ou Okta, SSO réduit le risque de mots de passe et facilite le offboarding. Email/mot de passe peut convenir aux petites équipes — imposez juste des mots de passe forts et des flux de reset.
Utilisez des sessions courtes et sécurisées (cookies HTTP‑only), protection CSRF, limitation de débit et 2FA quand possible.
Enregistrez qui a changé quoi et quand : éditions, approbations, changements de locales, exports et mises à jour de permissions. Associez le log à une fonctionnalité “undo” via l’historique des versions pour rendre les rollbacks sûrs et rapides (voir /blog/plan-storage-and-versioning).
Votre UI est l’endroit où le travail de localisation se réalise réellement. Priorisez les écrans qui réduisent les allers‑retours et rendent le statut évident d’un coup d’œil.
Commencez par un tableau de bord qui répond rapidement à trois questions : qu’est‑ce qui est fait, qu’est‑ce qui manque et qu’est‑ce qui est bloqué.
Affichez l’avancement par locale (pourcentage traduit, pourcentage relu), plus un compte clair de « chaînes manquantes ». Ajoutez un widget file de relecture qui met en avant les éléments en attente d’approbation et un fil « changements récents » pour que les relecteurs repèrent les éditions risquées.
Les filtres comptent plus que les graphiques : locale, zone produit, statut, assigné et « changé depuis la dernière release ».
Un bon éditeur est côte‑à‑côte : source à gauche, cible à droite, avec le contexte toujours visible.
Le contexte peut inclure la clé, le texte de l’écran (si disponible), les limites de caractères et les placeholders (ex. {name}, %d). Incluez l’historique et les commentaires dans la même vue afin que les traducteurs n’aient pas besoin d’un écran « discussion » séparé.
Rendez le workflow de statut en un clic : Draft → In review → Approved.
Le travail de localisation est souvent « beaucoup de petits changements ». Ajoutez une sélection multiple avec actions comme assigner à un utilisateur/équipe, changer le statut, et exporter/importer pour une locale ou un module.
Gérez les actions en masse par rôle (voir /blog/roles-permissions-for-translators si vous en parlez ailleurs).
Les traducteurs intensifs vivent dans l’éditeur des heures durant. Supportez la navigation clavier complète, des états de focus visibles et des raccourcis comme :
Supportez aussi les lecteurs d’écran et un mode contraste élevé — l’accessibilité accélère le travail pour tout le monde.
Une appli de gestion de localisation réussit ou échoue sur son workflow. Si les gens ne savent pas quoi traduire ensuite, qui a pris une décision ou pourquoi une chaîne est bloquée, vous aurez des retards et une qualité inégale.
Commencez par une unité de travail claire : un ensemble de clés pour une locale dans une version spécifique. Permettez aux chefs de projet (ou leads) d’assigner par locale, fichier/module et priorité, avec une date d’échéance optionnelle.
Rendez les assignations visibles dans une boîte « Mon travail » qui répond à trois questions : ce qui est assigné, ce qui est en retard et ce qui attend d’autres personnes. Pour les grandes équipes, ajoutez des signaux de charge (nombre d’items, estimation du nombre de mots, dernière activité) afin que les assignations soient justes et prévisibles.
Créez un pipeline de statut simple, par exemple : Untranslated → In progress → Ready for review → Approved.
La relecture doit être plus qu’un check binaire. Supportez des commentaires inline, des suggestions d’édition et approuver/rejeter avec raison. Quand un relecteur rejette, conservez l’historique — n’écrasez pas.
Cela rend la relecture auditable et réduit les erreurs répétées.
Le texte source changera. Quand cela arrive, marquez les traductions existantes comme Needs update et affichez un diff ou un résumé « ce qui a changé ». Conservez l’ancienne traduction comme référence, mais empêchez sa réapprobation sans décision explicite.
Notifiez sur les événements qui bloquent le travail : nouvelle assignation, demande de relecture, rejet, échéance approchant et changement source affectant des chaînes approuvées.
Rendez les notifications actionnables avec des liens profonds comme /projects/{id}/locales/{locale}/tasks pour que les gens résolvent les problèmes en un clic.
La gestion manuelle des fichiers est la cause principale de dérive : traducteurs sur des chaînes obsolètes, développeurs oubliant de tirer les mises à jour, releases livrant des locales à moitié finies.
Une bonne appli traite l’import/export comme un pipeline reproductible, pas comme une tâche ponctuelle.
Supportez les chemins courants que les équipes utilisent réellement :
À l’export, permettez de filtrer par project, branch, locale et statut (ex. « approved only ») pour éviter que des chaînes partiellement relues ne fuient en production.
La sync ne marche que si les clés restent cohérentes. Décidez tôt comment les chaînes sont générées :
checkout.button.pay_now), protégez‑les des renommages accidentels.Votre appli doit détecter quand le texte source a changé mais pas la clé, et marquer les traductions comme needs review plutôt que de les écraser.
Ajoutez des webhooks pour automatiser la sync :
main → importer les chaînes source mises à jour.Les webhooks doivent être idempotents (sécurisés au retry) et produire des logs clairs : ce qui a changé, ce qui a été sauté et pourquoi.
Si vous implémentez cela, documentez la configuration end‑to‑end la plus simple (accès repo + webhook + export PR) et liez‑la depuis l’UI, par exemple : /docs/integrations.
La QA de localisation transforme une simple application d’édition en un système qui prévient les bugs en production. L’objectif est d’attraper les problèmes avant que les chaînes ne soient publiées — surtout ceux qui n’apparaissent que dans une locale donnée.
Commencez par des vérifications qui peuvent casser l’UI ou briser le formatage :
{count} présent en anglais mais absent en français, ou formes plurielles incohérentes).% errant dans les chaînes printf, messages ICU mal formés).Traitez ceux‑ci comme « blocage de release » par défaut, avec un message d’erreur clair et un pointeur vers la clé et la locale exactes.
Ceux‑ci n’empêchent pas toujours l’app de fonctionner, mais dégradent la qualité et la cohérence de la marque :
Un texte peut être correct et sembler pourtant inapproprié. Ajoutez un moyen de demander contexte par capture d’écran par clé (ou d’attacher une capture à une clé) pour que les relecteurs vérifient la troncature, les retours à la ligne et le ton dans l’UI réelle.
Avant chaque release, générez un résumé QA par locale : erreurs, avertissements, chaînes non traduites et principaux coupables.
Facilitez l’export ou le lien interne (ex. /releases/123/qa) pour que l’équipe ait une vue unique « go/no‑go ».
Ajouter un glossaire, une mémoire de traduction (TM) et la traduction automatique (TA) peut accélérer énormément la localisation — mais seulement si l’appli les traite comme des aides et non comme un contenu « prêt à publier ».
Un glossaire est une liste curatée de termes avec leurs traductions approuvées par locale (noms de produit, concepts UI, phrases légales).
Stockez les entrées comme terme + locale + traduction approuvée + notes + statut.
Pour l’appliquer, ajoutez des vérifications dans l’éditeur :
La TM réutilise des segments approuvés précédemment. Gardez‑la simple :
Considérez la TM comme un système de suggestion : les utilisateurs peuvent accepter, éditer ou rejeter les correspondances, et seules les traductions acceptées doivent réalimenter la TM.
La TA sert pour des brouillons et des arriérés, mais ne doit pas être la sortie finale par défaut.
Rendez la TA optionnelle par projet et par job, et routez les chaînes remplies par TA via le processus normal de relecture.
Les équipes ont des contraintes différentes. Permettez aux admins de choisir des fournisseurs (ou de désactiver la TA), fixer des limites d’usage et sélectionner quelles données sont envoyées (ex. exclure les clés sensibles).
Logguez les requêtes pour la visibilité des coûts et l’audit, et documentez les options dans /settings/integrations.
Une appli de localisation ne doit pas seulement « stocker des traductions » — elle doit aider à les livrer en sécurité.
L’idée clé est une release : un snapshot figé des chaînes approuvées pour une build spécifique, afin que ce qui est déployé soit prévisible et reproductible.
Traitez une release comme un bundle immuable :
Cela vous permet de répondre : « Qu’avons‑nous livré dans v2.8.1 pour fr‑FR ? » sans supposer.
La plupart des équipes veulent valider les traductions avant que les utilisateurs les voient. Modélisez les exports par environnement :
Rendez l’endpoint d’export explicite (par ex. /api/exports/production?release=123) pour éviter les fuites accidentelles de texte non relu.
Le rollback est plus facile quand les releases sont immuables. Si une release introduit un problème (placeholders cassés, terminologie erronée), vous devez pouvoir :
Évitez « éditer la production en place » — ça brise les traces d’audit et complique l’analyse des incidents.
Remarque : cette approche « snapshot + rollback » cadre bien avec les plateformes de build modernes. Par exemple, Koder.ai inclut snapshots et rollback comme workflow natif pour les apps que vous générez et hébergez, ce qui est un bon modèle mental quand vous concevez des releases immuables.
Après le déploiement, exécutez une petite checklist opérationnelle :
Si vous affichez l’historique des releases dans l’UI, incluez une vue simple « diff vs release précédente » pour que les équipes repèrent vite les changements risqués.
La sécurité et la visibilité font la différence entre un outil utile et un outil en lequel les équipes ont confiance. Une fois le workflow en place, sécurisez‑le et commencez à le mesurer.
Appliquez le principe du moindre privilège par défaut : les traducteurs ne devraient pas pouvoir changer les paramètres projet, et les relecteurs ne doivent pas accéder à la facturation ou aux exports réservés admin. Rendre les rôles explicites et traçables.
Stockez les secrets en sécurité. Gardez les identifiants DB, clés de signature webhook et tokens tiers dans un gestionnaire de secrets ou des variables d’environnement chiffrées — jamais dans le repo. Faites tourner les clés régulièrement et quand quelqu’un quitte l’équipe.
Les backups ne sont pas optionnels. Automatisez les sauvegardes de la base et du stockage d’objets (fichiers de locale, attachments), testez les restaurations et définissez les politiques de rétention. Un « backup qui ne se restaure pas » n’est qu’un coût de stockage.
Si les chaînes peuvent contenir des contenus utilisateur (tickets de support, noms, adresses), évitez de les stocker dans le système de traduction. Préférez des placeholders ou des références, et nettoyez les logs des valeurs sensibles.
Si vous devez traiter ce texte, définissez des règles de rétention et des restrictions d’accès.
Suivez quelques metrics représentant la santé du workflow :
Un tableau de bord simple + export CSV suffit pour démarrer.
Une fois la fondation stable, envisagez :
Si vous comptez proposer cela comme produit, ajoutez un chemin de montée en gamme clair et un call‑to‑action (voir /pricing).
Si votre objectif immédiat est de valider le workflow rapidement avec des utilisateurs réels, vous pouvez aussi prototyper le MVP sur Koder.ai : décrivez les rôles, le flux de statuts et les formats d’import/export en mode planning, itérez sur l’UI React et l’API Go via le chat, puis exportez la base de code quand vous êtes prêt à la durcir pour la production.
Une application web de gestion de la localisation centralise vos chaînes et gère le flux de travail autour d’elles — traduction, relecture, approbations et export — afin que les équipes puissent publier des mises à jour sans clés cassées, placeholders manquants ou statut flou.
Commencez par définir clairement :
pt-BR → pt → en)Un périmètre restreint évite le piège du « un seul workflow pour tout » et rend le MVP utilisable.
La plupart des équipes couvrent le workflow de base avec :
Capturez des métadonnées qui évitent les erreurs en production et réduisent les allers‑retours :
Ça dépend de votre optimisation :
Une approche courante est hybride : row‑per‑key comme source de vérité, plus des snapshots de fichiers générés pour les exports.
Utilisez deux niveaux :
Cela évite que des éditions silencieuses modifient ce qui a déjà été livré et facilite le debug des incidents.
Commencez par les rôles qui reflètent le travail réel :
Concentrez l’API sur quelques ressources clés :
Projects, Locales, Keys, TranslationsEnsuite, rendez les endpoints de listage filtrables pour les tâches réelles, par exemple :
Exécutez les travaux longs de façon asynchrone :
Rendez ces jobs idempotents (sécurisants au retry) et conservez des logs par projet pour faciliter le diagnostic par les équipes.
Priorisez les vérifications qui empêchent une UI cassée :
{count}, %d) et couverture des plurielsTraitez‑les comme bloquants de release par défaut, et ajoutez des avertissements moins stricts pour la cohérence du glossaire et la ponctuation.
draft → in_review → approved)Si ces entités sont bien modélisées, les écrans, permissions et intégrations deviennent plus simples à construire et maintenir.
created_by, updated_by, horodatages, raison du changement)Cela transforme un simple éditeur en un système digne de confiance pour les équipes.
Définissez des permissions par action (éditer la source, approuver, exporter, gérer les locales) pour pouvoir faire évoluer le système sans casser les workflows.
Cela sert à la fois l’édition humaine via l’UI et l’automatisation via CLI/CI.