Ce que le shipping de DIALØGUE m'a appris sur les produits AI multilingues
DIALØGUE prend en charge 7 langues, mais le vrai travail multilingue n'était pas de traduire des strings. C'était de corriger les dates locales selon l'audience, de garder une cohérence TTS, de réparer les dérives de langue dans l'UI et de décider où la qualité compte assez pour ralentir.
L'une des choses les plus séduisantes que l'AI nous permet de faire aujourd'hui, c'est d'ajouter des langues rapidement. Je le sais parce que je continue à le faire. J'ai ajouté 5 langues à DIALØGUE en 48 heures, puis j'ai traduit l'intégralité de mon archive de blog en 10 langues en 4 jours.
Ces posts parlaient de la vitesse. Celui-ci parle de tout ce que la vitesse ne couvre pas.
La traduction est la partie la plus facile à montrer en démo, et la plus dangereuse à surestimer.
La machine peut faire passer du texte d'une langue à une autre à une vitesse stupéfiante. Ça ne veut pas dire que le produit semble natif pour autant. D'après mon expérience, le vrai travail multilingue apparaît à quatre endroits : le temps, la voix, les systèmes d'UI et le comportement de fallback. C'est là qu'un produit commence soit à paraître réfléchi, soit à paraître faux.
Voilà à quoi ça ressemblait dans la pratique :
| Translation Work | Product Work | |
|---|---|---|
| Ce que ça couvre | Strings, copy, labels | Dates, layout, voix, fallbacks |
| Qui remarque quand c'est faux | Reviewers bilingues | Chaque utilisateur dans cette locale |
| Comment l'AI aide | Génère les traductions vite | Ne sait pas juger le fit au niveau produit |
| Effort pour corriger | Retraduire le string | Redessiner le composant |
| Quand on le découvre | En code review | Après qu'une personne utilise réellement l'app |
Le premier bug n'était pas une traduction. C'était le temps.
L'un des fixes qui m'a rendu ça évident n'avait rien à voir avec le copy.
Pour les shows récurrents, DIALØGUE génère les titres d'épisode automatiquement. La version la plus évidente a l'air inoffensive : le nom du show plus la date du jour.
Ça semble sans danger jusqu'au moment où ton audience est à Tokyo et que ton serveur pense encore en Californie.
Si une auditrice japonaise ouvre un daily show alors qu'on est déjà le 14 mars à Tokyo, mais que le titre affiche encore le 13 mars parce que c'est ce que croit le serveur, le produit paraît immédiatement off. Pas cassé. Juste négligent.
J'ai donc fini par modifier les titres d'épisode pour qu'ils utilisent la date locale de l'audience, dans la locale et le fuseau horaire de l'audience, et non le défaut du serveur.
C'est un petit détail d'implémentation. Et c'est précisément le point.
Les produits multilingues ne sont pas seulement une affaire de mots. Ce sont aussi des produits de contexte.
Une langue sans contexte local n'est souvent qu'une version plus polie du faux.
Leçon 1 : La voix fait partie du produit
Ça est devenu beaucoup plus clair à mesure que je suis entré plus profondément dans DIALØGUE.
Le produit est construit autour du dialogue, du pacing, de la personnalité et de l'audio. Ça relève la barre de qualité bien plus haut qu'une interface SaaS classique.
Quand j'ai ajouté de nouveaux templates, j'ai vite appris que le support multilingue ne consistait pas simplement à :
- traduire le nom du template
- traduire le copy de la landing page
- shipper
Pour un template, j'ai dû réfléchir à tout ça :
- host profiles
- audience profiles
- dialogue guides
- voice instructions pour le TTS
- conventions de nommage localisées selon la langue
Ce travail existait en anglais, mais il avait aussi besoin de versions japonaises et vietnamiennes, parce que l'alchimie entre les hosts fait partie du produit, pas d'une couche cosmétique posée par-dessus.
Si ton produit génère du contenu, la voix n'est pas une décoration. La voix est une infrastructure.
Quelque chose peut être grammaticalement correct et quand même sembler mort.
Je l'ai senti de manière particulièrement nette avec les variantes de Chinese, et avec le contenu spoken plus largement. Le mandarin standard peut être techniquement correct et tout de même paraître trop formel dans un certain contexte. Un rythme conversationnel décontracté en anglais peut sonner bureaucratique lorsqu'on le pousse dans une langue produit trop littérale dans une autre langue. Une blague qui marche dans un marché peut devenir une exposition plate dans un autre.
C'est pour ça que je tiens autant maintenant aux tone guides et aux host profiles. Pas parce que je veux que chaque output sonne "branded". Mais parce que le voice drift est l'une des façons les plus rapides de rendre un produit AI multilingue générique.
Et le générique coûte cher.
Leçon 2 : La longueur de l'UI est un problème produit, pas un problème de traduction
Ça a l'air mineur jusqu'à ce que tu shippes une vraie app.
Ensuite, c'est partout.
Quand j'ai localisé l'app iOS DIALØGUE, il ne s'agissait pas juste de traduire quelques écrans. C'est devenu 253 strings à travers 7 langues.
Et même là, le travail n'était pas terminé.
J'ai dû recâbler les input components pour que le sélecteur de langue de l'app contrôle réellement la langue de l'UI de manière cohérente. Placeholders, buttons, pricing labels, status text, tout. Sinon, on obtient le problème de l'app à moitié traduite :
- un écran respecte la langue sélectionnée
- un autre affiche encore un placeholder en anglais
- les status labels restent dans la langue d'origine
- l'app supporte techniquement plusieurs langues, mais l'expérience ne les supporte pas vraiment
Un button propre en anglais devient maladroit en allemand. Une ligne de pricing bien compacte passe à la ligne en français. Un settings label percutant se comporte différemment en japonais.
Si ton workflow de localization s'arrête à la génération du texte, tu découvriras ces problèmes bien trop tard, et d'une manière assez embarrassante.
C'est pourquoi je pense de plus en plus que le travail multilingue doit être traité comme un système produit complet :
- copy
- layout
- spacing
- truncation rules
- component behavior
- screenshot QA
La machine peut générer les mots. Il faut quand même que quelqu'un ouvre le Simulator.
Leçon 3 : Le comportement de fallback révèle la maturité réelle du produit
C'est encore plus important dans les produits audio que dans les produits texte.
L'un des fixes DIALØGUE les plus utiles que j'ai faits récemment avait l'air ennuyeux vu de l'extérieur : du TTS thresholding et de la cohérence par segment.
Le whole-script TTS gate initial était trop optimiste. Les podcasts longs dépassaient la vraie limite d'entrée, gaspillaient plusieurs retries ratés avant de fallback. Sur certains runs, ça signifiait environ 12 secondes de latence évitable avant que le système se corrige lui-même.
C'est agaçant en anglais.
Dans des flows multilingues, c'est pire, parce que la cohérence de la voix est déjà plus difficile à tenir.
Le fix n'était pas "utiliser un meilleur modèle". Le fix, c'était du product work :
- baisser le threshold pour la synthèse whole-script
- faire passer les épisodes longs en mode per-segment plus tôt
- ajouter des opening / middle / closing guidance pour l'énergie de chaque segment
- transmettre quelques lignes du dialogue précédent comme continuity context pour que le segment suivant ne donne pas l'impression d'un nouveau show
Ça, c'est du fallback behavior. Ça, c'est de la maturité.
Si une voix TTS spécifique à une langue sonne faux, qu'est-ce qu'il se passe ? Si une réponse générée mélange les langues, qu'est-ce qu'il se passe ? Si un untranslated error message apparaît au milieu d'un flow localisé, qu'est-ce qu'il se passe ? Si un script long dépasse la model limit, qu'est-ce qu'il se passe ?
Ce sont ces moments-là qui disent si le support multilingue est une feature ou une foundation.
Les utilisateurs pardonnent souvent quand le système essaie clairement d'aider. Ils pardonnent beaucoup moins quand le produit paraît négligent.
Leçon 4 : Savoir quand la couverture n'en vaut pas la peine
La question business n'est pas : "Est-ce que je peux supporter une langue de plus ?"
Elle est :
- est-ce que cette langue va débloquer un usage réel ou une distribution réelle ?
- est-ce que je peux maintenir une quality bar crédible à la fois dans l'UI et dans l'output ?
- est-ce que je peux gérer les failure cases sans créer de support debt ?
Si la réponse est non, alors ce que tu lances n'est pas une capability multilingue. C'est une surface multilingue. Et une surface sans qualité affaiblit la confiance en silence.
Leçon 5 : Les produits multilingues ont besoin de leur propre couche d'evals
C'est peut-être mon plus grand takeaway à la fois de DIALØGUE et de mon archive de blog.
On ne peut pas juger la qualité multilingue au simple instinct, surtout à l'échelle.
Il faut des checks explicites :
- comportement des dates et fuseaux horaires selon la locale
- cohérence terminologique
- UI overflow
- fallback language rules
- cohérence TTS d'un segment à l'autre
- dérive des hosts / de la personnalité
- qualité de l'output dans de vrais user flows
Autrement dit, les produits multilingues ont besoin d'evals eux aussi.
Et c'est là, je pense, que les AI builders peuvent se faire piéger. On devient fascinés par tout ce que le modèle peut produire, et on passe moins de temps à définir durablement ce que veut dire "bon".
À petite échelle, ça reste gérable.
À plus grande échelle, ça devient dangereux.
Là où j'en suis aujourd'hui
Je suis plus optimiste que jamais sur les produits AI multilingues.
L'AI change vraiment l'economics. Elle élargit réellement ce qu'une personne seule ou une petite équipe peut shipper. Elle rend possibles des ambitions produit qui auraient paru irréalistes il n'y a pas si longtemps.
Mais elle relève aussi le niveau d'exigence du product judgment.
Parce qu'une fois que l'expansion linguistique devient facile, la qualité devient le différenciateur. Et la qualité, dans les produits multilingues, ne vient pas de la traduction seule. Elle vient du contexte, de la voix, du fit de l'interface, des fallbacks, des review loops, et d'une définition très honnête de ce que veut réellement dire "assez natif".
C'est ce que DIALØGUE m'a appris. Plus tu supportes de langues, plus tu fais en réalité du product management, que tu l'appelles comme ça ou non.
Si ton produit est vraiment multilingue, le travail ne s'arrête pas quand les strings sont traduits. C'est là que le vrai travail commence.
Si tu veux voir le résultat de cette manière de penser, DIALØGUE est déjà live en 7 langues. Et je soupçonne que la couche multilingue va continuer à m'apprendre de nouvelles leçons à mesure que plus de gens l'utiliseront. Généralement les leçons un peu humiliantes.
Si toi aussi tu construis des produits multilingues, j'aimerais vraiment savoir : quel a été le moment où tu as compris que le bug le plus difficile n'avait rien à voir avec la traduction ?
Cheers, Chandler
Questions fréquentes
Quelle est la partie la plus difficile dans la construction d'un produit AI multilingue ?
Pas la traduction. L'AI gère cette partie remarquablement bien aujourd'hui. Le plus difficile, c'est tout ce qui entoure la traduction : le formatage conscient des fuseaux horaires, la cohérence de la voix à travers les segments TTS, les UI components qui cassent selon la longueur des strings, et le fallback behavior quand quelque chose échoue dans une locale spécifique. Ce sont des problèmes produit, pas seulement des problèmes de langue.
Est-ce que je devrais ajouter plus de langues à mon produit AI ?
Seulement si tu peux maintenir la qualité. Chaque langue ajoutée crée un travail produit continu : layout QA, voice tuning, formatage des dates et des nombres propre à la locale, et fallback paths. Si ton produit dépend de la nuance et du generated content, comme les podcasts, l'écriture longue ou le conversational AI, la barre est plus haute que pour une simple interface transactionnelle.
Comment tester des features AI multilingues ?
En construisant une couche d'evals explicite. Pour DIALØGUE, ça veut dire vérifier les dates propres à chaque locale, la cohérence TTS entre les segments, l'UI overflow dans les 7 langues et la dérive de personnalité dans les dialogues générés des hosts. On ne peut pas se reposer sur l'instinct quand on supporte plus de deux ou trois langues. La surface est trop grande pour être spot-checkée à la main.
Est-ce que l'AI rend la localization plus facile ou plus difficile ?
Les deux. L'AI rend la traduction initiale beaucoup plus rapide et moins chère. Mais elle crée aussi une fausse sensation de complétude. Les mots sont justes, donc on croit que le produit est prêt. Le vrai travail, contexte, voix, fit UI, fallbacks, demande encore du jugement humain. L'AI a relevé le floor de la couverture multilingue, mais le plafond reste le product craft.
