Au cœur des quatre pipelines de traduction qui font tourner InterMIND

L'ancienne page /product/overview/how-it-works sur mind.com a plusieurs versions majeures de retard. Elle décrit un unique « moteur de traduction » comme le font la plupart des pages éditeurs — une grande flèche allant de « vous parlez » à « ils entendent ». Cette image était déjà une simplification il y a deux ans. Aujourd'hui, elle est fausse.

La vérité, c'est qu'InterMIND fait tourner quatre pipelines de traduction distincts, chacun résolvant un problème différent avec un moteur différent, un budget de latence différent et une enveloppe de qualité différente. Ils partagent un sélecteur de langue. Ils ne partagent pas de moteur.

Voici la réponse mise à jour à la question « comment ça marche ».

Article compagnon : « Combien de langues prenez-vous en charge ? » couvre ce que chaque pipeline prend en charge (24 / 22 / 30 / 12). Cet article-ci couvre ce que chaque pipeline fait — et pourquoi il constitue sa propre brique.

Pourquoi « un seul moteur pour tout » est un mensonge

Une plateforme de réunion en direct doit accomplir au moins quatre tâches simultanément, et elles tirent dans des directions incompatibles :

1. Voix en temps réel — audio en entrée, audio traduit en sortie, en moins d'une seconde, chaque auditeur dans sa propre langue. La contrainte dure, c'est la latence.
2. Texte de chat en temps réel — messages courts, rapides, avec modifications, citations et structure HTML préservée.
3. Notes partagées en temps réel — saisie collaborative caractère par caractère, avec hiérarchie structurelle (listes, titres, cases à cocher) qui doit survivre à la traduction.
4. Fichiers de documents asynchrones — un PDF de 40 pages déposé dans le chat. Aucun budget de latence. La contrainte dure, c'est la fidélité — mise en forme, tableaux, numéros de page, police.

On peut construire un gros appel LLM unique qui essaie de faire les quatre. Nous avons essayé. Il est mauvais sur les quatre. Le budget de latence de la voix empêche le modèle de réfléchir ; le budget de fidélité des documents exige qu'il réfléchisse. Une modification de chat exige un diff dans la langue du lecteur ; un PDF de 40 pages exige une préservation du format qu'aucun modèle en streaming de tokens ne vous offre.

Donc nous en faisons tourner quatre. Voici chacun d'eux.

Pipeline 1 : traduction vocale en temps réel

Le problème : un participant parle français. Un autre participant a rejoint en allemand, un troisième en portugais brésilien, un quatrième en japonais. Chacun doit entendre l'orateur dans sa propre langue, dans sa propre oreille, avec un délai assez court pour que le contact visuel reste possible.

Le budget : moins d'une seconde de bout en bout. Au-delà de ~1,2 seconde, la conversation casse — les gens commencent à parler par-dessus la traduction, et la réunion glisse vers « passons simplement à l'anglais ».

Comment l'audio circule réellement

Quelques points qui méritent d'être nommés explicitement :

• La reconnaissance vocale (ASR) tourne dans le navigateur de l'orateur, pas sur un serveur central. Nous utilisons Mind SDK localement ; cela évite un aller-retour et nous donne la transcription en langue source avec le délai le plus court possible avant même que la traduction ne commence.
• La traduction n'est pas un seul fan-out. Nous maintenons un pool de connexions WebSocket vers notre moteur de traduction, une par langue cible présente dans la salle. Si trois participants ont choisi l'allemand, l'allemand partage une connexion. Si personne n'a choisi l'arabe, aucune connexion arabe n'est ouverte. Le pool ferme les connexions inactives au bout de cinq minutes. C'est pourquoi une réunion à quatre langues coûte la même chose qu'une réunion à quarante langues, à concurrence des personnes effectivement présentes — nous ne traduisons jamais vers des langues qu'aucun participant n'écoute.
• La synthèse vocale est par auditeur. Chaque participant reçoit sa propre piste audio traduite, mixée sur la vidéo originale de l'orateur. Ils ne regardent pas une « réunion traduite » maître — ils regardent la même réunion, avec leur canal audio personnel traduit dans la langue qu'ils ont choisie. C'est pourquoi deux personnes dans la même pièce physique peuvent chacune brancher leurs écouteurs et entendre des langues différentes.

Pourquoi cela compte quand une réunion dérape

Dans un appel de 60 minutes avec huit langues, les choses cassent de manière intéressante : des WebSockets tombent, l'ASR transcrit mal temporairement un nom propre, le réseau d'un participant devient instable. L'architecture ci-dessus est ce qui nous permet d'isoler les défaillances : l'audio d'un auditeur qui bafouille n'affecte pas les sept autres, parce que le moteur de traduction n'a jamais produit « la traduction » au singulier — il en a produit huit, en parallèle, et seule celle qui est touchée doit se rétablir.

Le moteur lui-même est le nôtre, hébergé sur notre propre infrastructure. Nous ne faisons pas transiter la voix en temps réel par des LLM généralistes tiers. Le budget de latence les exclut ; l'histoire de la résidence des données les exclut pour les clients régulés qui s'en soucient réellement.

Ce que nous publions sur la qualité vocale : /benchmark exécute le pipeline vocal de production sur des phrases FLORES-200 pour chaque paire de langues publiée, chaque mois. Le juge est nommé (Gemini 2.5 Flash en principal, Claude Sonnet 4 en repli). La distribution complète — médiane, p10, p90, min, max, taille d'échantillon — figure sur la page. Voir la méthodologie pour ce que ces chiffres mesurent et ne mesurent pas.

Pipeline 2 : traduction de chat en temps réel

Le problème : chaque message de chat dans la réunion, traduit pour chaque participant dans sa propre langue, au moment où il est envoyé. Plus les modifications — et les modifications doivent ressembler à des modifications, pas à des re-traductions.

Le budget : rapide, mais pas sous la seconde. Un message de chat peut prendre une demi-seconde à apparaître dans une autre langue sans que personne ne s'en soucie. Ce qui compte pour les gens, c'est que la traduction soit correcte et que les modifications aient du sens.

Ce que fait réellement le pipeline de chat

Chaque message passe par le même moteur de traduction que le pipeline vocal — mais avec un pré- et post-traitement différents :

• La structure HTML est préservée. Le chat prend en charge le texte riche (paragraphes, listes, citations, gras, italique). Nous convertissons en texte brut pour le modèle, traduisons, puis ré-enveloppons le résultat dans les balises d'origine. Le modèle ne voit jamais le HTML — il voit de la prose propre.
• Les citations sont traduites indépendamment. Si vous répondez à un message et le citez, le bloc [QUOTE]…[/QUOTE] et le nouveau contenu sont traduits comme des unités séparées, de sorte que le modèle ne peut pas confondre les deux.
• Les longs messages sont découpés. Nous découpons aux frontières de paragraphes à 1 000 caractères par segment. Chaque segment fait l'objet de son propre appel de traduction. Nous ne donnons pas au modèle des romans de 4 000 caractères d'un seul coup — les modes de défaillance (troncature, paragraphes perdus, coupures en plein milieu de phrase) sont trop laids.
• La traduction est paresseuse. Nous utilisons un IntersectionObserver : un message n'est traduit que lorsqu'il défile dans le viewport de l'auditeur. Changer de langue dans un canal de longue durée rejouait autrefois chaque appel d'API de traduction depuis l'historique. Plus maintenant.

La partie intéressante : les modifications comme diffs

En v1.2, nous avons changé le comportement des modifications de chat pour les lecteurs dans une autre langue. L'ancien comportement était : quelqu'un modifie un message, nous re-traduisons l'ensemble, vous voyez un paragraphe tout neuf et devez repérer ce qui a bougé.

Le nouveau comportement :

1. Le message d'origine avait déjà été traduit dans votre langue.
2. Quand l'expéditeur modifie, nous re-traduisons la nouvelle version.
3. Nous calculons le diff entre votre traduction précédente et votre nouvelle traduction, dans votre langue.
4. Nous affichons ce diff en ligne — de la même manière que Git vous montre ce qui a changé.

Ainsi, quand « review by Tuesday » devient « review by Thursday » en anglais, votre collègue qui lit en espagnol voit martes → jueves surligné, pas un paragraphe re-traduit qu'il doit relire.

Cela a exigé de traiter le pipeline de chat comme un cache à état par auditeur, et non comme un point d'entrée de traduction sans état à la demande. Les documents et la voix n'en ont pas besoin. Le chat, si.

Pipeline 3 : traduction des notes partagées en temps réel

Le problème : l'hôte ouvre un panneau de notes partagées et commence à taper. Chaque participant voit les notes dans sa langue, caractère par caractère, avec la structure du document — titres, listes imbriquées, listes à cocher, blocs de code — intacte.

Le budget : le même que le chat (~une demi-seconde), mais avec deux contraintes supplémentaires :

• L'objet à traduire change en cours de traduction. L'hôte est encore en train de taper. Un système naïf qui traduit « tout le document » à chaque frappe produit du scintillement et brûle le budget d'API. Nous traduisons à la granularité de l'unité modifiée, pas du document entier.
• La structure doit survivre. Si vous demandez à un modèle de traduction de traduire un blob markdown avec trois listes imbriquées, vous récupérez quelque chose qui ressemble à l'original mais avec une hiérarchie subtilement aplatie, des éléments renumérotés ou une indentation déplacée. Nous ne laissons pas le modèle voir le blob entier.

En quoi le pipeline de notes diffère du chat

La préservation structurelle est la chose principale. Nous traduisons chaque élément de liste indépendamment plutôt que comme un seul document. Le modèle voit :

« Revue de conformité — livrables Q2 »

— pas :

« # Plan de projet\n## Trimestre\n- Revue de conformité — livrables Q2\n- Notation des fournisseurs\n - Fournisseurs de niveau 1… »

Le document enveloppant — le <ul>, les titres, l'indentation — est reconstruit côté client en utilisant la même structure que le document d'origine, chaque nœud terminal étant remplacé par sa traduction. Le modèle n'a jamais l'occasion d'« améliorer » la hiérarchie.

Les notes utilisent également le même modèle de diff par auditeur que les modifications de chat : si l'hôte change une ligne, les auditeurs dans d'autres langues voient les mots modifiés surlignés, pas un paragraphe tout neuf.

Pipeline 4 : traduction de documents asynchrone

Le problème : quelqu'un dépose un PDF de 40 pages, un document Word, une présentation PowerPoint ou une feuille Excel dans le chat. Chaque participant peut demander une copie dans sa propre langue. Le fichier traduit doit ressembler à l'original — mêmes polices, mêmes tableaux, mêmes numéros de page, mêmes en-têtes, mêmes graphiques à leur place.

Le budget : aucune contrainte de temps réel. Une minute, ça va. Deux minutes, ça va. La contrainte est la fidélité — si le PDF traduit ne ressemble pas à l'original, le destinataire n'y fera pas confiance.

Pourquoi ce pipeline ne partage pas de moteur avec la voix

Un LLM généraliste, même très bon, vous rendra un texte traduit d'un document. Il ne vous rendra pas un PDF traduit avec la même mise en page. Le modèle n'a aucune notion de « saut de page qui doit s'aligner sur la source » ou de « cellule de tableau qui doit garder sa largeur de colonne ».

Pour cette surface, nous utilisons directement l'API Document de DeepL. Elle est conçue pour traduire des fichiers en tant que fichiers, pas de la prose extraite de fichiers. DeepL prend en charge :

• PDF (avec préservation de la mise en page)
• DOCX, DOC
• PPTX
• XLSX

Le document est téléversé dans le pipeline de DeepL, traduit côté serveur avec la mise en forme intacte, et retourné dans le même format. Nous téléversons ensuite le résultat vers notre stockage objet et le faisons remonter dans le chat sous forme de pièce jointe téléchargeable.

Combien cela coûte et pourquoi nous ne le cachons pas

DeepL facture un minimum de 50 000 caractères par document — environ un dollar américain par fichier sur le palier Pro, que le document fasse une page ou trente. Nous absorbons ce coût plutôt que de facturer par fichier ; il apparaît dans l'usage de traduction de la réunion sous la forme de caractères facturés, convertis en unités-mots qui correspondent à la manière dont le reste du produit rapporte l'activité de traduction.

Nous avons choisi DeepL pour cette surface parce que c'est le meilleur moteur de sa catégorie pour la traduction de documents spécifiquement. Nous ne prétendons pas en avoir construit un meilleur. L'inverse n'est pas vrai — DeepL ne fait pas tourner de pipeline vocal en direct du type de celui que nous avons construit pour les réunions. Problèmes différents ; outils différents. La version honnête de « ce qui propulse la traduction InterMIND » est « le bon moteur par pipeline » — pas « notre moteur, partout ».

Les langues que ce pipeline couvre et que la voix ne couvre pas

Le pipeline documentaire atteint 30 langues, contre 22 pour la voix. Les langues supplémentaires comprennent : bulgare, grec, estonien, indonésien, lituanien, letton, norvégien bokmål, slovaque, slovène — plus l'arabe, que nous masquons dans le sélecteur en temps réel parce que la qualité vocale ne passe pas notre barre mais que DeepL gère bien en tant que document.

Cette asymétrie est réelle. Elle signifie qu'un participant français en réunion peut demander le contrat PDF en estonien même s'il ne peut pas écouter la réunion en estonien. Nous le signalons dans le sélecteur plutôt que de lisser cela avec un chiffre unique. Le raisonnement est dans l'article sur le nombre de langues.

Là où les pipelines se rencontrent

Les quatre pipelines ne tournent pas en isolation. Une salle de réunion est l'endroit où ils se touchent, et les coutures comptent :

• Un message de chat avec une pièce jointe documentaire déclenche le pipeline de chat pour le texte et le pipeline documentaire pour le fichier. Le participant dans une autre langue voit le message traduit immédiatement et la traduction de la pièce jointe arriver de manière asynchrone sous forme téléchargeable.
• Une note partagée qui cite une ligne de transcription traverse notes ↔ voix. La transcription est ce que le pipeline vocal a produit pour la langue de l'expéditeur ; la traduction de la note produit une copie par auditeur de cette citation dans la langue de chacun, avec son attribution source préservée.
• Une transcription exportée après la réunion passe le pipeline texte de type chat sur la conversation complète, produisant un fichier par langue que les participants peuvent télécharger. C'est le même chemin de code que la traduction de chat, simplement traité par lots.

Le sélecteur de langue est un seul élément d'interface. L'infrastructure en dessous, c'est quatre pipelines qui se parlent.

Ce que nous ne cherchons délibérément pas à faire

• Pas de « modèle de traduction unifié ». Nous ne construisons pas un modèle unique qui fait voix, chat, notes et documents. Le compromis latence vs fidélité n'a pas de gagnant. Nous utilisons le bon moteur par surface.
• Pas de re-routage silencieux. Si la voix ne peut pas traduire en hindi aujourd'hui, nous ne basculons pas en silence vers le moteur documentaire en faisant semblant que cela a fonctionné. L'hindi est masqué du sélecteur sur les deux surfaces parce que le résultat sur l'une ou l'autre aujourd'hui n'est pas livrable.
• Pas de « nous traduisons en 200 langues ». Notre moteur en émet 24. Notre produit en livre 22 sur les surfaces en direct et 30 sur les documents. Le chiffre plus gros, plus vendeur, n'est que le plafond du moteur. Le chiffre produit, c'est ce qui passe effectivement la barre face à un auditeur.

Essayez par vous-même

• /demo — exécute le pipeline vocal en direct sur votre audio, dans n'importe laquelle des 22 langues du produit. Le même pipeline que celui qui obtient les scores de /benchmark.
• /benchmark — qualité par paire, par mois, sur du trafic réel. Inclut les paires que nous masquons délibérément du sélecteur, lien profond possible.
• /benchmark/methodology — ce que sont les chiffres, ce qu'ils ne sont pas, qui est le juge.

Quatre pipelines, quatre moteurs, une salle de réunion. Voilà le remplacement honnête de l'ancienne page how-it-works.

— The Mind.com Team