Consultation en internationalisation : Corriger les problèmes actuels, planifier la suite
Vous savez déjà que l'i18n, c'est compliqué. J'en ai vu les symptômes : des mises en page RTL qui s'effondrent, du texte allemand qui déborde des boutons, des réponses d'API dans la mauvaise langue, et des traductions qui se désynchronisent quelques semaines après le lancement. Je ne vends pas de solutions miracles. Je vous aide à démêler le désordre spécifique dans lequel se trouve votre équipe — et à mettre en place des systèmes qui ne tomberont pas en panne de la même façon.
« On aurait dû prévoir ça plus tôt »
Le coût architectural que vous payez actuellement
Vous avez lancé en anglais. Ça a marché. Puis vous avez ajouté le français « juste pour la landing page ». Et maintenant vous êtes là parce que :
Votre base de code contient des vérifications lang= éparpillées dans 47 fichiers
Les chefs de produit demandent « on peut faire de l'A/B testing sur les textes ? » et l'équipe technique répond « pas sans tout réécrire »
Vous avez trois flux de traduction différents et aucun ne fonctionne de manière fiable
Ce que j'ai vu planter :
- Des équipes qui passent plus de 6 mois à intégrer l'i18n après coup dans une app Next.js parce que les chaînes étaient codées en dur dans les composants
- Des fichiers de traduction qui se désynchronisent parce que les développeurs ne savent pas quel fichier mettre à jour
- Des périodes de « gel de la localisation » avant les versions, car personne ne fait confiance au pipeline de traduction.
- Refus de modifier le moindre contenu traduit parce que le workflow est trop pénible
Comment je peux vous aider :
- Des stratégies de refactoring qui vous permettent d'adopter l'i18n de manière incrémentale (je n'exige pas de « tout arrêter et tout réécrire »)
- Conception de processus pour garder les traductions à jour sans bloquer le développement.
- Audits d'architecture pour identifier où votre approche actuelle va échouer au-delà de 10 langues
L'i18n, c'est de l'architecture, pas une fonctionnalité. Essayer de l'ajouter après coup, c'est comme vouloir creuser un sous-sol alors que la maison est déjà construite.
Je vous aide à creuser ces fondations — ou à déterminer si vous en avez vraiment besoin.
RTL fait tout planter
Votre interface n'a pas été pensée pour l'arabe, l'hébreu ou l'ourdou
Vous avez activé dir="rtl" et vous avez vu votre mise en page exploser :
Ce que j'ai constaté :
- Des design systems de plus de 200 composants dont seulement 12 gèrent correctement RTL
- Des équipes qui utilisent float: left au lieu des propriétés logiques, créant des bugs RTL à chaque nouvelle fonctionnalité
- Des popovers et des modales qui nécessitent des surcharges RTL spécifiques à chaque composant
- Des frameworks qui prétendent « prendre en charge RTL » mais ne font qu'inverser la direction de mise en page, cassant au passage la logique de placement
Comment je peux vous aider :
- Migration vers les propriétés logiques CSS (margin-inline-start au lieu de margin-left)
- Des audits de design systems pour détecter les mines RTL avant la mise en production
- Des conseils adaptés à chaque framework (Tailwind, shadcn, MUI) pour un style pensé d'abord pour RTL
Corriger manuellement les bugs RTL dans chaque composant n'est pas viable. Je rends le support RTL systématique, plutôt qu'un combat permanent.
« Le texte allemand a cassé notre bouton »
Une interface qui n'a pas été conçue pour la traduction
L'anglais passe. L'allemand, non. Votre design partait du principe que :
Puis vous avez traduit en allemand, en finnois ou en thaï et vous avez découvert :
Boutons tronqués en plein mot
Tableaux avec défilement horizontal sur chaque ligne
Du texte qui se replie en blocs illisibles
Le texte non latin est tronqué car les conteneurs ont des largeurs fixes
Domaines d'intervention :
- Modèles d'interface élastiques qui s'adaptent à la longueur du contenu
- Planification du budget de caractères (savoir que l'allemand s'allonge de 30 % et que le thaï n'utilise pas d'espaces)
- Des systèmes de typographie qui gèrent CJK, l'arabe et le devanagari sans rien casser
Je vous aide à concevoir une interface qui résiste à la traduction — avant que vous n'ayez payé pour 10 000 mots inutilisables.
Pas besoin d'un cours magistral sur l'importance de l'i18n. Ce qu'il vous faut, c'est quelqu'un qui a débogué des popovers RTL à 2 h du matin, qui s'est battu avec l'équipe produit sur les budgets de caractères, et qui a conçu des pipelines de traduction qui fonctionnent vraiment.
Les pièges que personne ne vous a signalés
Retours d'expérience d'équipes qui sont passées par là
Ce ne sont pas des théories. Ce sont des choses qui ont planté en production :
L'enfer de la pluralisation
Anglais : « 1 item » contre « 2 items »
Polonais : « 1 przedmiot » / « 2 przedmioty » / « 5 przedmiotów » (3 formes de pluriel)
Arabe : 6 formes de pluriel
Votre logique count === 1 ? 'item' : 'items' ne fonctionne plus.
Le chaos des dates et heures
Vous avez formaté les dates avec toLocaleDateString(). Puis des utilisateurs au Japon ont vu « 2025年2月9日 » dans vos exports CSV… et Excel a planté.
Incohérence linguistique de l'API
Votre frontend demande le français. Votre API renvoie l'anglais parce que le jeton d'authentification ne transporte pas la locale. Résultat : une interface en langues mélangées et les utilisateurs pensent que c'est un bug.
Test de pseudo-locale
Vous n'avez pas testé avec [Ţĥîś îś ţéśţ ţéẋţ ţĥàţ éẋþàñðś 30 %] avant de passer en production. Maintenant, votre site polonais est inutilisable.
L'hypothèse invisible
Vous pensiez que seules les chaînes de caractères avaient besoin d'être traduites. Puis vous êtes tombés sur les dates, les nombres, les devises, le tri, la recherche — tout a un comportement propre à chaque locale.
Domaines d'intervention :
- Implémentation d'ICU MessageFormat (gestion des pluriels, du genre et du contexte)
- Modèles i18n pour les API (négociation de langue, stratégies de repli)
- Des processus d'assurance qualité qui détectent ces problèmes avant les agences de traduction.
Le workflow, c'est le plus difficile
Comment garder 8 langues synchronisées quand vous livrez tous les jours ?
La tech, vous maîtrisez. Maintenant, c'est le processus qui bloque :
Les développeurs fusionnent du code contenant de nouvelles chaînes en anglais. Les traductions prennent 2 semaines de retard. Les utilisateurs se retrouvent avec une interface à moitié traduite.
Vous ne savez pas quelles chaînes de caractères peuvent être supprimées sans risque (sont-elles utilisées ? traduites ? en cours de traitement par une agence ?)
Le produit veut mettre à jour le texte. Personne ne sait si changer « Submit » en « Send » va casser 12 langues.
Les fichiers de traduction restent désynchronisés de la production pendant des semaines entières.
Questions que les équipes me posent :
Ce que j'ai vu planter :
- Des fichiers de traduction versionnés dans Git qui divergent des chaînes en production
- Avertissements « Ne touchez pas au fichier espagnol » parce que personne ne sait ce qu'on peut modifier sans risque
- Fonctionnalités lancées en anglais, puis traduites 6 mois plus tard (voire jamais)
Domaines d'intervention :
- Conception du pipeline de traduction (quand utiliser les bibliothèques i18n, un TMS ou l'IA)
- Workflows Git pour garder les chaînes source et les traductions à jour
- Automatisation qui bloque les PR si de nouvelles chaînes ne sont pas marquées pour traduction
La technique, ça se résout. Le flux de travail, c'est lui le vrai frein. Je conçois des flux qui ne demandent pas d'efforts surhumains pour être maintenus.
Les équipes avec lesquelles j'ai travaillé
Produits internationaux, expertise régionale
LINE (Japon, Taïwan, Thaïlande)
Plateforme de messagerie présente sur 3 marchés clés d'Asie de l'Est. J'ai travaillé sur des problématiques propres à la gestion des caractères CJK, à l'intégration dans l'écosystème de la plateforme et aux différences d'attentes en matière d'expérience utilisateur entre le Japon, Taïwan et la Thaïlande.
KakaoTalk (Corée du Sud)
Plateforme de messagerie dominante en Corée. Prise en compte des exigences produit propres au marché coréen, notamment les attentes en matière de registre de langue dans l'interface utilisateur et les besoins d'intégration à la plateforme.
Change.org (196 pays, plus de 20 langues prioritaires)
Plateforme mondiale de pétitions, où la rapidité et la qualité du contenu sont toutes deux essentielles. Contribution à l'optimisation du flux de traduction pour du contenu politique et social généré par les utilisateurs sur des marchés variés.
Airbnb (plus de 220 pays, plus de 60 langues)
Place de marché mondiale avec des exigences complexes en internationalisation (i18n). Conseil sur les défis liés à la confiance et à la sécurité en contexte multilingue, ainsi que sur l'adaptation culturelle des concepts de la plateforme selon les marchés.
Intercom (plus de 30 langues, SaaS B2B mondial)
Plateforme de communication client au service de grandes entreprises internationales. J'ai travaillé sur l'internationalisation du produit pour les outils de support en temps réel et la localisation de la base de connaissances.
Lilith Games (Chine, Japon, Corée, États-Unis, UE)
Éditeur de jeux mobiles dont les jeux sont distribués dans le monde entier. Prise en charge des défis propres à chaque marché en matière de localisation de contenu et d'exigences régionales des plateformes.
Marchés sur lesquels j'ai lancé des produits :
Asie de l'Est (Japon, Corée, Chine) :
Typographie CJK, intégration à l'écosystème de la plateforme, prise en charge du texte vertical
Asie du Sud-Est (Thaïlande, Vietnam, Indonésie) :
Prise en charge multi-script, attentes des utilisateurs orientées mobile
MENA (régions arabophones) :
Contraintes de mise en page RTL, registre formel ou familier, adaptation culturelle du contenu
Europe :
24 langues officielles, lancements de produits dans plusieurs pays.
Amériques :
Variantes linguistiques régionales (espagnol latino-américain vs espagnol d'Espagne, portugais brésilien), marchés bilingues
J'ai vu ce qui fonctionne et ce qui échoue sur ces marchés — pas en théorie, mais en livrant des produits sur lesquels de vrais utilisateurs comptent.
Corrigeons les problèmes actuels
Pas besoin d'un cours magistral sur l'importance de l'i18n. Ce qu'il vous faut, c'est quelqu'un qui a débogué des popovers RTL à 2 h du matin, qui s'est battu avec l'équipe produit sur les budgets de caractères, et qui a conçu des pipelines de traduction qui fonctionnent vraiment.
Revue de l'architecture et de la stratégie (1 à 2 semaines) :
Je vous indique ce qui posera problème quand vous ajouterez vos 3 prochaines langues, et combien ça coûtera de corriger
Accompagnement au lancement sur le marché (4 à 8 semaines) :
Vous vous lancez au Japon/MENA/EU et vous cherchez des experts qui l'ont déjà fait
Partenariat continu :
Conseil intégré à mesure que vous passez de 2 à 20 langues
Je ne fais pas de théorie. Je fais du triage, des roadmaps, et je livre.