Table des matières
Il y a une conversation qui se produit dans presque toutes les startups autour de la Série A. Quelqu'un regarde les analyses et remarque que 30 % des inscriptions proviennent de pays non anglophones. Le produit est uniquement en anglais. Le churn de ces cohortes est brutal. Le responsable engineering dit : « nous devons internationaliser ».
Ensuite l'estimation revient : six mois minimum.
Cette estimation est presque toujours exacte, et presque toujours évitable.
Le Vrai Coût de l'i18n Rétroactif
Selon CSA Research, 87 % des consommateurs n'achèteront pas depuis un produit uniquement en anglais lorsque des alternatives existent dans leur langue. Le marché de la localisation a atteint 6,27 milliards de dollars en 2023 et continue de croître. Ce ne sont pas des chiffres de niche — ils représentent un plafond sur votre marché adressable que vous avez discrètement installé dans votre base de code.
La raison pour laquelle l'intégration rétroactive est coûteuse n'est pas parce que l'internationalisation est techniquement difficile. C'est à cause de la façon dont les applications sont construites sans i18n en tête :
- Littéraux de chaînes éparpillés dans 200 composants
- Formatage des dates et des nombres codé en dur selon les conventions américaines
- Colonnes de base de données dimensionnées pour le texte en anglais
- Mise en page droite-à-gauche jamais envisagée
- Contenu structuré autour des suppositions grammaticales de l'anglais
- Gestion des fuseaux horaires liée à une seule région
Chacun de ces points est peu coûteux à corriger dès le premier jour. Chacun est pénible à démêler au mois 18, quand la base de code compte 40 000 lignes et quatre ingénieurs qui ont chacun construit sur les suppositions d'origine.
L'estimation de six mois n'est pas pour ajouter des traductions. C'est pour auditer et réécrire les parties de votre application qui ont été construites sans i18n en tête. La traduction représente 20 % du travail. Les 80 % restants, c'est de l'archéologie.
Quand Devriez-Vous Réellement Internationaliser ?
Cette question comporte deux parties : quand rendre votre architecture prête pour i18n, et quand livrer réellement plusieurs langues.
Architecture : Le premier jour, toujours.
Le coût de la construction avec la compatibilité i18n dès le départ est d'environ deux heures de configuration. Vous ne traduisez rien. Vous n'embauchez pas de traducteurs. Vous prenez simplement des décisions qui ne ferment pas de portes.
- Externalisez vos chaînes dans des fichiers de ressources au lieu de les coder en dur
- Utilisez une bibliothèque de date/heure compatible avec les paramètres régionaux (Luxon, date-fns avec support des paramètres régionaux, Temporal)
- Choisissez une approche de formatage des nombres qui encapsule
Intl.NumberFormat - Laissez de l'espace dans votre interface utilisateur pour l'expansion du texte (l'allemand peut être 30 % plus long que l'anglais)
- Stockez les paramètres régionaux comme préférence utilisateur dès le début
Ce n'est pas une optimisation prématurée. Ce n'est pas du gold-plating. C'est la même raison pour laquelle vous utilisez des variables d'environnement pour les valeurs de configuration que vous pourriez vouloir modifier — vous n'anticipez pas un besoin spécifique, vous évitez un piège spécifique.
Livrer des traductions : Après avoir reçu un signal.
Vous n'avez pas besoin de livrer le français le premier jour. Vous devez être prêt à le faire. La décision d'investir réellement dans une deuxième langue doit être guidée par les données :
- Vous constatez des inscriptions organiques depuis un marché cible
- Une conversation de vente l'exige pour conclure un accord
- Vous entrez sur un marché où la pénétration de l'anglais est faible
- Une cohorte de clients avec une langue spécifique churne à un taux plus élevé
Quand ce signal apparaît, « prêt pour i18n » signifie que vous pouvez livrer une deuxième langue en une semaine, pas en six mois.
Le Piège du Calendrier à 3 Mois
Voilà comment les équipes se font prendre : elles savent qu'elles ont besoin d'i18n, elles ne veulent pas mal le faire, alors elles planifient un « projet i18n correct ». Elles l'estiment à trois mois. Cette estimation comprend :
- Audit des chaînes existantes
- Construction d'un pipeline de traduction
- Intégration d'un système de gestion des traductions
- Coordination avec un fournisseur de traduction
- QA dans tous les paramètres régionaux
Pendant que le projet est en planification, la feuille de route continue d'avancer. Le projet de trois mois est sans cesse déprioritisé parce qu'il ne livre pas de fonctionnalités. Au moment où il est finalement priorisé, c'est un projet de cinq mois parce que la base de code a grandi.
Le piège est de traiter l'i18n comme une migration big-bang. L'alternative est de le traiter comme une fondation que vous posez de manière incrémentale, en commençant par l'architecture.
La Configuration i18n Minimale Viable
Voici à quoi ressemble « prêt pour i18n » en pratique pour une application React ou Next.js au stade seed. Cela coûte deux heures à mettre en place et zéro surcharge continue jusqu'à ce que vous soyez prêt à traduire.
Étape 1 : Choisissez une approche d'externalisation des chaînes.
Ne codez pas en dur les chaînes d'affichage. Au minimum, mettez-les dans des fichiers JSON. Mieux encore : utilisez une solution typée dès le départ.
// Mauvais — chaîne codée en dur
<button>Get started for free</button>
// Mieux — externalisée, même si c'est uniquement l'anglais pour l'instant
// messages/en.json
{
"cta.getStarted": "Get started for free"
}
// Composant
const t = useTranslations();
<button>{t('cta.getStarted')}</button>
Vous n'avez pas encore besoin d'une plateforme de traduction. Un fichier JSON par paramètre régional, même si c'est uniquement l'anglais, suffit. L'habitude d'utiliser t() plutôt que des chaînes en ligne est ce qui compte.
Étape 2 : Formatage compatible avec les paramètres régionaux dès le premier jour.
// Mauvais — formatage américain codé en dur
const formatted = `$${price.toFixed(2)}`;
const date = new Date(ts).toLocaleDateString('en-US');
// Bon — compatible avec les paramètres régionaux
const formatted = new Intl.NumberFormat(locale, {
style: 'currency',
currency: 'USD'
}).format(price);
const date = new Intl.DateTimeFormat(locale, {
dateStyle: 'medium'
}).format(new Date(ts));
Quand vous ajoutez un second paramètre régional plus tard, le formatage fonctionne simplement. Pas de grep-and-replace dans 80 fichiers.
Étape 3 : Concevez en tenant compte de l'expansion du texte.
Laissez de l'espace dans votre interface utilisateur. Utilisez du CSS qui se dégrade élégamment quand le texte s'allonge. Évitez les largeurs fixes en pixels sur les conteneurs de texte. Cela ne coûte rien en conception mais économise de l'argent réel en QA quand vous livrez l'allemand.
Étape 4 : Stockez les paramètres régionaux comme attribut utilisateur de première classe.
Même si vous livrez une seule langue, stockez preferred_locale dans votre modèle utilisateur. Quand vous ajoutez une deuxième langue, vos utilisateurs existants ont déjà une préférence de paramètre régional stockée. Vous ne migrez pas un schéma sous des données en direct.
Erreurs Courantes des Startups
« Nous ajouterons i18n quand nous en aurons besoin. » Le moment où vous en avez besoin est le moment où vous n'avez pas le temps de le faire correctement. Le signal qui déclenche la décision — un client majeur nécessitant le français, une initiative régionale de go-to-market — arrive toujours avec de l'urgence.
Construire un pipeline de traduction personnalisé. La gestion des traductions est un problème résolu. Une solution personnalisée coûte des semaines à construire et des mois à maintenir. Utilisez des outils qui existent déjà.
Traiter la localisation comme de la simple traduction. La langue représente 20 % de la localisation. La monnaie, les formats de date, les formats d'adresse, les exigences légales, le support RTL, les conventions UX spécifiques aux paramètres régionaux — ce sont les 80 % restants. Une chaîne traduite dans une mise en page cassée reste une expérience cassée.
Donner aux traducteurs un accès direct aux fichiers JSON. Les traducteurs humains ne doivent jamais éditer le JSON manuellement. Le taux d'erreur est élevé et le cycle de retour est lent. Ils ont besoin d'une interface utilisateur conçue pour le travail de traduction, avec du contexte, des limites de caractères et l'application de la cohérence terminologique.
Supposer que l'ordre des mots en anglais se généralise. Concaténer des chaînes traduites avec l'interpolation de chaînes JavaScript se casse dans les langues avec des structures grammaticales différentes. Utilisez le format de message ICU pour tout ce qui contient des variables.
// Mauvais — suppose l'ordre des mots en anglais
t('welcome') + ' ' + userName + '!'
// Bon — format ICU, le paramètre régional peut réordonner les tokens
t('welcome', { name: userName })
// en: "Welcome, {name}!"
// ja: "{name}さん、ようこそ！"
Un Cadre de Décision
Utilisez ceci pour décider où vous en êtes et quoi faire :
| Étape | Architecture i18n | Traductions actives |
|---|---|---|
| Avant le produit | Mettre en place des chaînes externalisées, un formatage compatible avec les paramètres régionaux | Non |
| Avant PMF | Maintenir la fondation, ne pas encore traduire | Non |
| Après PMF, avant Série A | Si vous voyez un signal international, traduire les 2 premières langues | Peut-être |
| Série A+ | Traiter la localisation comme une exigence produit | Oui |
L'insight clé : la décision d'architecture et la décision de traduction sont indépendantes. Prenez la décision d'architecture maintenant. Prenez la décision de traduction quand les données vous le disent.
La Liste de Contrôle Pratique
Avant d'écrire un autre composant, passez en revue ceci :
- Les chaînes sont externalisées (non codées en dur dans JSX/templates)
- Le formatage des dates utilise des APIs compatibles avec les paramètres régionaux
- Le formatage des nombres et des devises utilise
Intl.NumberFormat - Le modèle utilisateur a un champ
locale - Les mises en page de l'interface testées avec un texte 30 % plus long
- Pas de concaténation de chaînes avec des parties traduisibles
- Format de message ICU utilisé pour les chaînes avec des variables
- Pluralisation gérée correctement (pas seulement ajouter « s »)
Cocher tout cela prend deux heures. En manquer un à l'échelle coûte des semaines.
À Quoi Cela Ressemble en Pratique
Quand vous êtes prêt à livrer réellement plusieurs langues, le flux de travail passe de « fouille archéologique » à « projet de traduction ». Vous avez besoin de :
- Un moyen d'exporter les chaînes sources aux traducteurs
- Un processus de revue pour les traductions
- Un pipeline de déploiement qui met à jour les chaînes sans déploiement de code
- La livraison en temps réel du bon paramètre régional à chaque utilisateur
Chez Better i18n, nous avons construit une plateforme autour de ce problème spécifique — des SDKs type-safe pour React, Next.js, Vue et Svelte, des flux de travail de traduction basés sur Git pour que les traductions passent par une revue comme le code, et la livraison CDN pour que vous puissiez mettre à jour les traductions sans redéploiement. Le niveau gratuit sur notre page de tarification est dimensionné pour les équipes en phase précoce qui souhaitent construire la fondation sans engagement budgétaire. Si vous voulez voir comment les pièces techniques s'assemblent, la page pour les développeurs présente l'image complète.
La réécriture de six mois n'est pas inévitable. C'est le résultat d'une décision de deux heures différée trop longtemps.