Comment je couvre 95% de la population mondiale from day one
#5 - Ou comment utiliser l'IA pour parler au monde entier
Buenos dias !
Bienvenue dans cette 5ème édition de Founder Naked.
Cette semaine, je t’explique comment j’ai utilisé l’IA (mais pas que) pour traduire automatiquement 100% du contenu de mon app, et adresser environ 95% de la population mondiale dès le lancement.
Je t’explique comment j’ai fait, et comment tu peux le refaire.
Si ce n’est pas déjà le cas, tu peux aussi :
Me suivre sur Linkedin, où je publie des posts complémentaires,
Découvrir les services que je propose, notamment dans le secteur de la finance…
… mais pas encore découvrir Licorn, ma nouvelle boîte.
Allez, GO !
Au programme
Le coût historique de la traduction
Les capacités actuelles de l’IA et de Google Trad
Mon choix de tout traduire tout de suite
Comment j’ai implémenté cela
Comment reproduire cela
Combien cela coûtait jusqu’alors de traduire son contenu
Ma première expérience pro était pour Saint-Gobain en 2012. Je travaillais sur une nouvelle génération de fours pour fondre la roche et fabriquer de l’isolant thermique. On faisait toute la R&D à Paris, et on installait le four pilote en Roumanie.
Je m’occupais alors du transfert de savoir-faire des équipes françaises vers les équipes roumaines, et je devais donc concevoir et traduire (faire traduire, car je ne parle pas Roumain 😅) le contenu de formation.
Pas simple !
Cela reposait, et cela repose toujours (car j’ai regardé ce qui était toujours d’actualité avant de construire mon propre système) :
Sur un logiciel de gestion des traductions, qui permet de “router” les traductions ;
Et sur des agences de traduction, plus ou moins grosses, spécialisées ou généralistes, qui gèrent souvent des freelances, pour traduire le contenu.
Concrètement, pour un paragraphe donné, cela fonctionne comme ceci :
On lui attribue un identifiant unique,
On lui associe sa traduction en Français (ou autre langue d’origine),
Ensuite on le fait traduire, en gardant cette même clé,
Et enfin, la nouvelle traduction est automatiquement associée, ce qui permet de “switcher” facilement de langue, pour un même contenu.
L’avantage de ce système, c’est la qualité de la traduction : tu as souvent un natif du pays, qui comprend très bien les subtilités de la langue, qui se charge de la traduction.
L’inconvénient principal, c’est le coût : un logiciel qui a pignon sur rue, coûte plusieurs centaines à plusieurs milliers d’euros par mois ; et la traduction, qui dépend du volume à traduire et des langues, coûte un multiple de cela.
Un autre inconvénient, c’est le temps : de mémoire chez Saint-Gobain, avec les aller-retours et les corrections, il nous avait fallu 2 mois pour traduire quelques dizaines de pages du Français vers le Roumain.
Bref, on comprend vite pourquoi personne ne s‘amusait jusqu’alors, à traduire tout de suite son contenu ou son site dans des dizaines de langues.
Les outils actuels à disposition, notamment IA
Depuis quelques années l’IA a rabattu les cartes. Je n’aimerais d’ailleurs pas être une agence de trad ou un logiciel de gestion de traductions en ce moment. Certains vont se réinventer et intégrer l’IA ; d’autres vont essayer de conserver leur revenus et leur mode opératoire historique, et probablement y laisser leur peau.
Aujourd’hui tu as, à mon sens, 3 grandes familles de traduction automatisée par API1 :
Google Translate, qui dispose depuis longtemps d’API pour traduire plus de 130 langues, de façon très rapide. C’est top pour le contenu UGC2 ;
DeepL, un poil plus cher, mais qui traduit de façon très qualitative pour la plupart des langues européennes ;
L’IA, et notamment OpenAI, pour leur coût imbattable, mais il faut maîtriser le prompt et le contexte.
Pour te donner quelques chiffres, histoire que tu visualises de quoi on parle :
10 millions de caractères (à peu près 5 pages Word ou 15 pages web) traduits via Google coûte environ $200,
via DeepL ≈ $250, plus qualitatif, mais moins bonne couverture hors EU et moins rapide (API et moteur de traduction plus lents),
via GPT-4o-mini ≈ $7.5, mais il faut vraiment travailler son contexte et sa logique de traduction pour que la qualité soit acceptable. Et sinon il y a d’autres modèles plus puissants mais plus chers, à choisir selon le besoin.
Tu vois donc que l’IA rabat les cartes en termes de coût, même s’il faut pas mal itérer pour arriver à un résultat satisfaisant.
Alors Google et DeepL existaient déjà, et il y avait déjà la barrière tech qui faisait que pas mal de contenu marketing étaient de toute façon traduits par des agences.
Mais maintenant les outils “informatisés” — IA, Google ou DeepL — s’intègrent directement dans les outils du quotidien : slides Powerpoint ou Figma, maquettes InDesign, documents Word… La barrière à l’entrée a donc sauté sur de nombreux cas d’usage.
Et côté IA type GTP-4o-mini, la marche en termes de coût est devenue tellement importante, versus une traduction '“classique”, qu’elle ouvre un nouveau champ des possibles, et qu’elle oblige à se reposer des questions, et à remettre en question nos usages.
Pourquoi je pense que cela vaut désormais le coup de tout traduire tout de suite, quand on vise l’international
Je vois 3 raisons à cela :
Parce que c’est possible de le faire. Et comme c’est possible, d’autres vont le faire, et donc pourquoi pas toi ?
Parce que tu peux adresser des marchés qui ne sont pas surchargés / qui sont encore sous-adressés.
Parce qu’aujourd’hui, on peut repenser tout un process et investir sur la tech, pour moins cher que ce qu’une traduction “classique” nous aurait coûté.
Pour le côté tech, j’explique dans les parties suivantes comment j’ai fait et comment tu peux refaire pareil. Je me permets donc de m’attarder 2 minutes sur l’opportunité de marché 👇
Investir sur des marchés sous-exploités
Pour que tu comprennes les enjeux, voici un chiffre :
50% du web est en anglais. C’est LA langue dominante.
Et donc forcément, si les anglophones, qui ne représentent “que” 18% de la population mondiale, pèsent 50% du contenu sur le web, c’est que d’autres langues pâtissent de cet écart :
Les Chinois représentent 14% de la population mondiale, mais seulement 1% du web,
Les langues arabes, 6% de la population, seulement 1% du web,
etc.
On a ainsi de nombreux pays dynamiques, en dehors de l’occident transatlantique, qui sont encore très loin d’être “couverts” par le web, alors que la population navigue, utilise des smartphones, bref, consomme le web. Et les assistants IA qu’ils utilisent consomment également le web.
Il y a bien sûr un sujet de rentabilité de marché, qu’il faut calculer. Mais ces quelques chiffres amènent à mon sens déjà la base : il est temps de se reposer la question de la traduction, et des marchés que l’on peut adresser. Car les choses ont changé.
Comment j’ai implémenté la traduction au sein de Licorn
J’ai essayé ici de “traduire” ce que j’ai fait pour le plus grand nombre, que tu sois technique ou non. Alors forcément certains termes et technologies parleront plus aux développeurs, mais les grands principes resteront, je pense, compréhensibles de toutes et tous.
Car c’est finalement là l’essentiel : on s’en moque presque un peu des détails techniques, puisqu’avec l’IA on peut désormais presque tout faire. Par contre, il est essentiel de comprendre ce que l’on fait, pourquoi, et comment.
Mon organisation en “locales”
J’ai testé pas mal de choses sur 2025 pour la traduction. J’ai commencé petit, puis au fur et à mesure de mes tests, j’ai élargi ma base de langues à traduire.
J’avais globalement, sur ce sujet, une obsession : adresser la plus grande part de la population mondiale, sans exploser mes coûts. Et en itérant, je me suis rendu compte d’un principe important :
Différents pays peuvent parler la même langue,
mais en réalité il existe beaucoup de nuances.
Certains parlent réellement la même langue,
certains ont des mots et des unités différents,
alors que d’autres sont trop éloignés
pour considérer la même traduction.
Et les spécificités de chaque produit introduisent également un biais dont il est important de tenir compte.
Pour ma part c’est la cuisine : différents pays et cultures, bien que parlant la même langue sur le papier, utilisent des termes totalement différents pour la même chose. Ou tout simplement le nom des ingrédients n’est pas le même.
Il en est sorti de cette réflexion, une division de mes locales3 en 3 niveaux :
Les locales primaires, celle que je traduis de zéro ;
Les locales secondaires, que je traduis à partir d’un pivot primaire, pour les adapter à leurs spécificités culturelles ;
Les locales “alias”, qui ne sont qu’une simple copie d’une autre locale.
Par exemple, mon espagnol des Etats-Unis n’est pas du tout le même que mon espagnol du reste de l’Amérique. Je considère que ce n’est pas la même langue.
A l’inverse, en Amérique du Sud, j’utilise certains clusters, en fonction des spécificités régionales. Et lorsque c’est possible, je ne traduis pas et j’utilise un alias pour certains pays, pour économiser.
Ma logique de traduction
Je ne vais pas trop m’attarder dessus, pour éviter de rentrer dans des détails techniques. Ce qu’il faut retenir : j’ai séparé dans une logique dédiée, toute la façon de traduire. Pas l’orchestration des traductions. Non, juste la façon dont je “demande” à tel ou tel fournisseur de traduire tel ou tel texte.
Comment je traduis le contenu de mon site marketing et avec qui ?
Comment je traduis le contenu UGC et avec qui ?
Comment je traduis des recettes de cuisine et avec qui ?
etc.
Et toutes ces logiques sont découpées en petits bouts, testées, et me permettent d’avoir MA logique de traduction qui est spécifique et adaptée à MON business.
Je te donne un aperçu de mon organisation ci-dessous :
## 📁 Organisation des dossiers du package Translator
packages/translator/src/
├── 📄 index.ts # 🎯 API PUBLIQUE
│ └── Exports + fonctions helper
├── 🧬 core/ # 🎯 LOGIQUE COMMUNE (shared)
│ └── base-translator.ts └── Cache + Glossaires + Providers
├── 🔧 translator/ # 🎯 TRADUCTION SIMPLE (fine-tuned)
│ └── translator.ts └── Hérite de core
├── ⚙️ engine/ # 🎯 TRADUCTION CMS 3-PHASE (volume)
│ ├── engine.ts └── Hérite de core/ + 3-phase logic
│ ├── types.ts └── Types Engine (EngineTranslationResult)
│ ├── index.ts └── Exports Engine
│ └── __tests__/
│ └── engine.test.ts └── Tests Engine 3-phase
├── 🔌 providers/ # 🎯 APIS TRADUCTION (OpenAI, DeepL, Google)
│ ├── base/ └── Interface commune (TranslationProvider)
│ ├── openai/, deepl/, google/ └── Implémentations spécifiques
│ └── factory.ts └── Création providers
├── 🎚️ quality/ # 🎯 SÉLECTION QUALITÉ/PROVIDER
│ ├── levels.ts └── Cheap/Balanced/Premium
│ └── router.ts └── Sélection intelligente
├── 🌍 locale/ # 🎯 OPTIMISATION 210 LOCALES
│ ├── classifier.ts └── Primary/Adaptation/Alias
│ └── adaptation.ts └── Adaptations culturelles
├── 🔧 utils/ # 🎯 UTILITAIRES TECHNIQUES
│ ├── nested-object.ts └── Paths complexes (ingredients[0].name)
│ └── __tests__/ └── Tests utils
├── 💾 cache/ # 🎯 PERFORMANCE (Redis + Memory)
│ └── index.ts └── Cache multicouche
└── 📚 glossaries/ # 🎯 QUALITÉ (dictionnaires métier)
├── data/ └── Termes culinaires/techniques/marque
└── processor.ts └── Application glossairesSi tu as des questions, tu peux me les poser en commentaire 👇
Mes 2 workflows de traduction
Enfin, j’orchestre mes processus de traduction sur des outils dédiés, pour tenir notamment la charge et “scaler”.
J’ai testé au fil du temps plusieurs approches :
Au début j’ai fait tourner les traductions depuis mes serveurs : je gérais directement les appels aux API de traduction. Mais cela introduisait de la latence, et cela ne pouvait pas tenir la charge.
Je suis ensuite passé sur des Edge Functions, c’est-à-dire que je déclenchais la traduction côté base de données, pour ne pas impacter mon applicatif. Mais là aussi, cela ne pouvait pas tenir une montée en charge importante.
Enfin, j’ai fini par passer sur un orchestrateur dédié, qui fait tourner mon code de traduction (mon “translator”) dans le cloud, et qui encaisse quasi toute la charge. Il peut “scaler” indépendamment de mes applications.
Je suis pour ma part sur Inngest, mais il en existe d’autres.
Tout le contenu destiné aux clients → 210 locales
Comme tout est organisé ailleurs dans des “packages” dédiés, gérer mes traductions devient super simple. C’est pour cela que j’ai pu itérer facilement et tester différentes façons de faire et différents outils.
Ainsi pour traduire mes 210 locales, qui couvrent tous mes utilisateurs cibles, je lance ce simple bout de code :
```typescript
import { inngest } from '@repo/workflows'
// Envoyer event de traduction
await inngest.send({
name: 'payload/translate',
data: {
collection: 'recipes',
documentId: 'chocolate-cake-123',
fields: [
{ name: 'title', sourceValue: 'Gâteau au chocolat', type: 'text' },
{ name: 'description', sourceValue: 'Un délicieux...', type: 'textarea' }
],
sourceLocale: 'fr-FR',
targetLocales: ['en-US', 'es-ES', ...], // 210 locales
domain: 'recipe',
quality: 'balanced',
startedAt: Date.now()
}
})
```Et l’interface Inngest me permet de suivre toutes les étapes du workflow :
Plan → Classification, coûts, temps estimés,
Traduction de chaque locale primaire,
Adaptation de chaque lot associé à chaque locale primaire,
Copie des alias gratuits,
Write-back dans le CMS.
Traduction “on-demand” pour l’interne en FR+EN
Indépendamment de ce process, je traduis un certain nombre de choses pour l’interne. Je pars du principe que l’on travaille en Français et/ou en Anglais, et que tout ce qui est interne chez Licorn doit être traduit dans ces deux langues.
J’ai donc pour cela un process bien plus simple et compact. J’utilise toujours Inngest pour gérer le tout, mais cela n’exécute pas la logique complète autour des locale. Cela traduit “juste” ce que j’ai demandé : anglais et français. Si c’est une source française, cela ne traduit que l’anglais ; si c’est un message dans une autre langue, cela me le traduit en français et en anglais.
```typescript
// Trigger SQL envoie event automatiquement
await inngest.send({
name: 'supabase/translate',
data: {
table: 'survey_responses',
recordId: 'uuid-123',
fields: [
{ name: 'question_1', sourceValue: 'Je suis très satisfait...', type: 'text' }
],
sourceLocale: 'fr',
targetLocales: ['fr', 'en'], // FR+EN uniquement
domain: 'ugc',
quality: 'cheap',
startedAt: Date.now()
}
})
```Etapes du workflow de traduction :
Traduction en Anglais et/ou Français (2 locales),
Write-back dans le CMS.
Comment t’en inspirer pour construire ta propre usine de traduction
Bon, évidemment, ce n’est pas avec ce que je t’ai donné que tu vas pouvoir recopier texto ce que j’ai fait pour Licorn. Quoi que… avec l’IA maintenant, si tu lui passes tout ça en contexte…
Mais c’est justement là mon point : je t’ai donné les éléments de contexte, les tests que j’ai faits, et les conclusions auxquelles je suis arrivé sur la traduction. Après il faut l’adapter à ton métier, à ton application, à ce que tu souhaites en faire.
Je dirais que ce qu’il faut avant tout, d’autant plus à l’heure du “vibe coding”, c’est s’assurer de la robustesse de ce que l’on construit. Car l’IA, c’est le Far West : tous les matins les grands de l’IA peuvent nous débrancher un modèle, ou un nouveau venu peut complètement casser les codes.
Il faut donc que ce que l’on construit soit le plus agnostique possible de leurs lubies, et pour cela, rien de mieux que de séparer les responsabilités de tout ce que l’on fait. Et de simplement se connecter / se coupler aux modèles IA pour envoyer une requête, qu’on aura auparavant formatée ailleurs, de notre côté.
Et après, pour tenir la charge, j’ai parlé d’Inngest, mais tu as aussi Trigger.dev, ou d’autres encore. Normalement si tu fais bien ton “truc”, tu peux en changer facilement.
Le mot de la fin
Désolé pour les non-techs. J’ai essayé de faire de mon mieux pour vulgariser, mais le sujet restait technique, mais j’espère intéressant.
Mon objectif est d’expliquer ce que je construis et comment je le fais. Je parle de tout, y compris de comment je vis mon aventure entrepreneuriale et comment tenir sur la durée quand on monte une boîte.
Je fais du “Build in public” sans bullshit, sincère.
Si cela te parle, je t’invite à t’abonner et à partager cette newsletter avec ton entourage.
Bonne semaine !
Yoann
API = Application Programming Interface, autrement dit une façon d’échanger de l’information de façon structurée, entre deux systèmes informatiques.
UGC = User Generated Content, autrement dit le contenu produit par les utilisateurs d’une application, comme les discussions sur un forum, ou les commentaires en bas d’un article, par exemple.
Locale = couple langue-pays, utilisé pour identifier un contenu à destination d’une langue et d’un pays en particulier. Par exemple fr-FR pour le français en France, en-US pour l’anglais aux Etats-Unis, ou es-US pour l’espagnol aux Etats-Unis.