Le vrai coût de l'i18n : code maison vs plateforme

L’internationalisation a toujours un coût. La vraie question n’est pas « combien coûte une plateforme ? » mais « combien coûte déjà mon i18n maison — et où ce coût se cache-t-il ? ». La plupart des équipes sous-estiment le second parce qu’il n’apparaît sur aucune facture : il se paie en heures d’ingénierie, en bugs de production et en marchés atteints trop tard.

Faisons l’analyse honnêtement, chiffres et temps à l’appui — sans FUD. Le but n’est pas de conclure « achetez toujours », mais de vous donner un cadre pour décider. Les montants ci-dessous sont illustratifs : adaptez-les à vos taux et à votre contexte.

Le coût visible : construire son i18n maison

Au départ, un i18n maison paraît trivial — un fichier JSON et une fonction t(). Mais une vraie chaîne de localisation suppose bien plus :

• extraction des textes et chargement par namespace ;
• pluriels et règles ICU par langue ;
• interpolation, fallback de langue, détection de locale ;
• formats régionaux (dates, nombres, devises) ;
• gestion du sens d’écriture (RTL).

Pour une équipe compétente, cette base représente déjà 5 à 10 jours d’ingénierie. À 600 € la journée, on est entre 3 000 et 6 000 € avant d’avoir traduit le moindre mot. C’est le coût visible — et c’est le plus petit.

Les coûts cachés

C’est ici que le budget dérape, parce que ces postes ne s’arrêtent jamais.

• La maintenance. Le système maison doit suivre les montées de version du framework, les nouveaux cas limites, les nouvelles langues. Comptez 1 à 3 jours par mois, indéfiniment.
• Le workflow de traduction ad hoc. Sans plateforme, ce sont les développeurs qui exportent des fichiers, les envoient aux traducteurs, réimportent, résolvent les conflits. Du temps d’ingénieur dépensé en logistique, pas en produit.
• L’outillage glossaire et QA. Garder un vocabulaire cohérent, détecter les clés manquantes avant la production, valider les traductions : autant d’outils qu’il faut bâtir ou recoller à la main.
• La distribution. Dès qu’on veut corriger sans redéployer, il faut gérer un CDN, le cache, le versioning, le rollback — tout un projet à lui seul.
• Le support multi-framework. Une base maison pensée pour React ne se réutilise pas telle quelle en mobile ou sur un autre framework. On la réécrit.
• Les bugs de production. Une clé manquante ou une devise erronée au moment du paiement, c’est une conversion perdue et un ticket de support. Difficile à chiffrer, douloureux à encaisser.
• Le time-to-market. Chaque nouvelle langue qui prend des semaines au lieu de jours, c’est un marché qu’un concurrent atteint avant vous.
• La dette et le bus factor. Le système maison finit compris par une seule personne. Le jour où elle part, le coût explose.

Mettre des chiffres dessus

Modélisons une première année pour une application à plusieurs langues, en évolution active. Chiffres illustratifs, à ajuster :

Poste	i18n maison (an 1)	Plateforme (an 1)
Construction initiale	5–10 j (3 000–6 000 €)	Intégration : 1–2 j
Maintenance	1–3 j/mois (≈ 10 000 €+)	Incluse
Workflow + glossaire + QA	À bâtir (var.)	Inclus
Distribution CDN / versioning	À bâtir + héberger	Inclus
Abonnement	—	Coût annuel connu
Total visible an 1	≈ 13 000–20 000 €+	Intégration + abonnement

Le maison n’est pas « gratuit » : son coût est simplement différé et diffus. La plateforme transforme un coût variable et imprévisible (du temps d’ingénieur) en un coût fixe et prévisible (un abonnement), tout en libérant les développeurs pour le produit.

Un exemple chiffré

Prenons un SaaS qui passe de 1 à 4 langues sur 12 mois, avec une équipe produit qui ajuste des textes chaque semaine. En maison : 8 jours de construction, puis 2 jours/mois de maintenance et de logistique de traduction, plus un mini-projet CDN à mi-année pour cesser de redéployer à chaque correction. On atteint vite 30+ jours d’ingénierie sur l’année, soit l’équivalent d’un développeur mobilisé plus d’un mois — sur de la plomberie, pas sur le produit.

La même année avec une plateforme : 2 jours d’intégration, puis l’essentiel du travail de traduction porté par des non-développeurs dans un workflow dédié. Le coût d’ingénierie tombe à une poignée de jours ; le reste devient un abonnement prévisible. Même si l’abonnement n’est pas nul, le temps d’ingénieur récupéré le couvre généralement plusieurs fois — et c’est sans compter les bugs évités.

Trois erreurs de calcul fréquentes

En comparant build et buy, trois biais faussent presque toujours le verdict en faveur du maison :

1. Ne compter que la construction initiale. C’est le plus petit poste. La maintenance et la logistique, étalées sur des années, pèsent bien plus lourd.
2. Oublier le coût d’opportunité. Le temps passé à maintenir un i18n maison est du temps qui ne va pas au produit. Ce n’est pas neutre : c’est une fonctionnalité non livrée.
3. Ignorer le risque. Un bug de localisation en production, ou le départ de la seule personne qui comprend le système, sont des coûts réels — rares, mais chers. Une plateforme les mutualise.

Quand le maison suffit

Soyons justes : le DIY est parfois le bon choix.

• Une ou deux langues, contenu stable. Si vos textes bougent peu et que vous n’ajoutez pas de marché, un simple t() maison fait le travail. N’ajoutez pas de plateforme pour le plaisir.
• Pas d’équipe de traduction. Si les développeurs traduisent eux-mêmes, le workflow n’a pas de valeur ajoutée.
• Projet figé ou interne. Un outil interne sans enjeu de conversion ni de croissance ne justifie pas l’investissement.

La règle : si votre i18n ne change presque jamais, le coût caché reste faible.

Quand une plateforme se rentabilise

À l’inverse, le calcul bascule vite dès que l’un de ces facteurs apparaît :

• plusieurs langues et l’intention d’en ajouter ;
• des corrections fréquentes de texte ;
• des traducteurs non-développeurs qui ont besoin d’un vrai workflow ;
• plusieurs frameworks ou plateformes (web + mobile) ;
• une sensibilité aux clés manquantes en production (e-commerce, paiement) ;
• un time-to-market qui compte sur de nouveaux marchés.

Dans ces cas, la plateforme se rembourse souvent en quelques mois rien qu’en temps d’ingénieur récupéré — sans compter les bugs évités et les marchés atteints plus tôt.

Comment décider

Une grille simple en trois questions :

1. Mon i18n va-t-il changer souvent ? Si oui, le coût caché du maison grimpe.
2. Qui traduit, et avec quel outil ? Si ce ne sont pas les développeurs, un workflow a de la valeur.
3. Combien de marchés et de frameworks à 12 mois ? Plus le chiffre est élevé, plus la plateforme se rentabilise.

Si vous répondez « rarement / les devs / un seul » : restez en maison. Si vous répondez « souvent / des traducteurs / plusieurs » : faites le calcul, il penche presque toujours du même côté.

Faites le calcul

Le piège du i18n maison, ce n’est pas qu’il soit mauvais — c’est qu’il paraît gratuit. Son coût est juste invisible, étalé sur des mois de temps d’ingénieur et quelques bugs bien sentis. Le poser noir sur blanc suffit, le plus souvent, à trancher.

C’est le pari de Sonenta : transformer ce coût diffus en un coût prévisible et rendre les développeurs à leur produit. Notre page tarifs chiffre le côté « buy » ; le côté « build », lui, vit déjà dans vos feuilles de temps. Et si le verdict penche vers « buy » alors que vous tournez déjà sous i18next, la bascule est plus douce qu’on ne le croit — voir migrer depuis i18next.