À l'intérieur des quatre pipelines de traduction qui alimentent InterMIND

L'ancienne page /product/overview/how-it-works sur mind.com a plusieurs versions majeures de retard. Elle décrit un « moteur de traduction » unique comme le font la plupart des pages de vendeurs — une grande flèche partant de « vous parlez » vers « 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 exécute 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 un moteur.

Voici la réponse actualisée à la question « comment ça marche ».

En complément : « Combien de langues prenez-vous en charge ? » couvre ce que chaque pipeline couvre (24 / 24 / 30 / 17). Cet article couvre ce que chaque pipeline fait — et pourquoi il a sa propre logique.

Pourquoi « un seul moteur pour tout » est un mensonge

Une plateforme de réunion en direct a au moins quatre tâches à accomplir 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 participant dans sa propre langue. La contrainte difficile est la latence.
2. Texte de chat en temps réel — messages courts, rapides, avec préservation des modifications, des citations et de la structure HTML.
3. Notes partagées en temps réel — saisie collaborative caractère par caractère, avec une hiérarchie structurelle (listes, titres, cases à cocher) qui doit survivre à la traduction.
4. Fichiers documentaires asynchrones — un PDF de 40 pages déposé dans le chat. Pas de budget de latence. La contrainte difficile est la fidélité — formatage, tableaux, numéros de page, police.

Vous pouvez construire un appel LLM géant qui essaie de faire les quatre. Nous avons essayé. Il est mauvais pour les quatre. Le budget de latence pour la voix signifie que le modèle ne peut pas réfléchir ; le budget de fidélité pour les documents signifie que le modèle doit réfléchir. Une modification de chat nécessite un diff dans la langue du participant ; un PDF de 40 pages nécessite une préservation du formatage qu'aucun modèle de streaming de jetons ne vous offre.

Nous en exécutons donc quatre. Voici chacun d'entre 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 son propre casque, avec un délai suffisamment court pour garder un contact visuel possible.

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

Comment l'audio circule réellement

Quelques éléments qu'il vaut la peine de nommer explicitement :

• L'ASR s'exécute dans le navigateur de l'orateur, pas sur un serveur central. Nous utilisons le Mind SDK localement ; cela économise un aller-retour et nous donne la transcription en langue source avec le délai le plus faible possible avant même que la traduction ne puisse commencer.
• La traduction n'est pas un simple 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 en arabe n'est ouverte. Le pool supprime les connexions inactives après cinq minutes. C'est pourquoi une réunion à quatre langues coûte la même chose qu'une réunion à quarante langues, dans la limite des personnes réellement présentes — nous ne traduisons jamais vers des langues qu'aucun participant n'écoute.
• La synthèse vocale est par participant. Chaque participant reçoit sa propre piste audio traduite, mixée sur la vidéo de l'orateur original. Ils ne regardent pas une « réunion traduite » maîtresse — 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 un casque et entendre des langues différentes.

Pourquoi cela compte lorsqu'une réunion dérape

Dans un appel de 60 minutes avec huit langues, les choses tournent mal de manières intéressantes : les WebSockets se coupent, l'ASR retranscrit temporairement mal 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 : un problème audio chez un participant n'affecte pas les sept autres, car le moteur de traduction n'a jamais produit « la traduction » en premier lieu — il en a produit huit, en parallèle, et seule celle qui est affectée doit se rétablir.

Le moteur lui-même est le nôtre, hébergé sur notre propre infrastructure. Nous n'acheminons pas la voix en temps réel via des LLM tiers à usage général. Le budget de latence les élimine ; le critère de la résidence des données les élimine 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 principal, Claude Sonnet 4 en secours). La distribution complète — médiane, p10, p90, min, max, taille de l'échantillon — est 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 retraductions.

Le budget : Rapide, mais pas en moins d'une seconde. Un message de chat peut prendre une demi-seconde pour apparaître dans une autre langue sans que personne ne s'en soucie. Ce dont les gens se soucient, c'est de savoir si la traduction est correcte et si les modifications ont du sens.

Ce que fait réellement le pipeline de chat

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

• La structure HTML est préservée. Le chat prend en charge le texte enrichi (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 épurée.
• 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 distinctes, de sorte que le modèle ne peut pas confondre les deux.
• Les longs messages sont découpés. Nous divisons aux limites des paragraphes à 1 000 caractères par morceau. Chaque morceau correspond à son propre appel de traduction. Nous ne donnons pas des romans de 4 000 caractères au modèle en une seule fois — les modes d'échec (troncature, paragraphes perdus, coupures en plein milieu d'une phrase) sont trop disgracieux.
• La traduction est paresseuse. Nous utilisons un IntersectionObserver : un message n'est traduit que lorsqu'il défile dans la fenêtre d'affichage du participant. Changer de langue dans un canal de longue durée exigeait auparavant de rejouer chaque appel à l'API de traduction depuis l'historique. Ce n'est plus le cas.

La partie intéressante : les modifications sous forme de diffs

Dans la v1.2, nous avons modifié le comportement des modifications de chat pour les participants dans une autre langue. L'ancien comportement était : quelqu'un modifie un message, nous retraduisons le tout, vous voyez un nouveau paragraphe et devez repérer ce qui a bougé.

Le nouveau comportement :

1. Le message original a déjà été traduit dans votre langue.
2. Lorsque l'expéditeur modifie, nous retraduisons 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, lorsque « review by Tuesday » devient « review by Thursday » en anglais, votre collègue qui lit en espagnol voit martes → jueves surligné, et non un paragraphe retraduit qu'il doit relire.

Cela a exigé de traiter le pipeline de chat comme un cache stateful par participant, et non comme un endpoint de traduction à la demande stateless. 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 volet 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 de contrôle, blocs de code — intacte.

Le budget : Identique au chat (~une demi-seconde), mais avec deux contraintes supplémentaires :

• L'élément en cours de traduction change en cours de traduction. L'hôte est toujours en train de taper. Un système naïf qui traduit « tout le document » à chaque frappe produit un scintillement et épuise le budget de l'API. Nous traduisons à la granularité de l'unité modifiée, et non du document entier.
• La structure doit survivre. Si vous demandez à un modèle de traduction de traduire un bloc 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 bloc entier.

Comment le pipeline de notes diffère du chat

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

« Revue de conformité — livrables T2 »

— et non :

"# Plan de projet\n## Trimestre\n- Revue de conformité — livrables T2\n- Évaluation des fournisseurs\n - Fournisseurs Tier 1..."

L'enveloppe du document — le <ul>, les titres, l'indentation — est reconstruite côté client en utilisant la même structure que celle du document original, chaque nœud feuille é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 participant que les modifications de chat : si l'hôte change une ligne, les participants dans d'autres langues voient les mots modifiés surlignés, et non un nouveau paragraphe.

Pipeline 4 : Traduction asynchrone de documents

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 à la même place.

Le budget : Aucune contrainte de temps réel. Une minute, c'est bien. Deux minutes, c'est bien. La contrainte est la fidélité — si le PDF traduit ne ressemble pas à l'original, le destinataire ne lui fera pas confiance.

Pourquoi ce pipeline ne partage pas le même moteur que la voix

Un LLM général, même un 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 avec la source » ou de « cellule de tableau qui doit conserver sa largeur de colonne ».

Pour cette surface, nous utilisons directement la DeepL Document API. Elle est conçue spécifiquement pour traduire des fichiers en tant que fichiers, et non de la prose extraite de fichiers. DeepL gère :

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

Le document est téléchargé vers le pipeline de DeepL, traduit côté serveur avec un formatage intact, et renvoyé dans le même format. Nous téléchargeons ensuite le résultat vers notre stockage d'objets et le remontons dans le chat en tant que fichier téléchargeable.

Ce que cela coûte et pourquoi nous ne le cachons pas

DeepL facture un minimum de 50 000 caractères par document — soit environ un dollar américain par fichier sur l'offre Pro, qu'il s'agisse d'un document d'une page ou de trente. Nous absorbons ce coût plutôt que de facturer au fichier ; il apparaît dans l'utilisation de la traduction de la réunion sous forme de caractères facturés, convertis en unités de mots qui correspondent à la façon dont le reste du produit rend compte de l'activité de traduction.

Nous avons choisi DeepL pour cette surface parce que traduire des fichiers en tant que fichiers est exactement le travail pour lequel il a été conçu — nous n'avons pas essayé d'en construire un meilleur. L'inverse n'est pas vrai — DeepL n'exploite pas de pipeline vocal en direct de la manière que nous avons construite pour les réunions. Des problèmes différents ; des outils différents. La version honnête de « ce qui alimente la traduction InterMIND » est « le bon moteur par pipeline » — et non « notre moteur, partout ».

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

Le pipeline documentaire atteint 30 langues, contre 24 pour la voix. Les langues supplémentaires incluent : le bulgare, le grec, l'estonien, l'indonésien, le lituanien, le letton, le slovaque, le slovène. (L'arabe figurait autrefois dans cette liste lorsque sa qualité vocale était inférieure à notre seuil ; il se trouve maintenant dans le sélecteur en temps réel, avec ses scores par paire publics sur /benchmark comme pour toutes les autres langues. L'asymétrie s'inverse désormais pour l'hindi — en direct sur la voix, mais pas encore sur les fichiers.)

Cette asymétrie est réelle. Elle signifie qu'un participant français à une réunion peut demander le PDF du contrat en estonien même s'il ne peut pas écouter la réunion en estonien. Nous l'indiquons dans le sélecteur plutôt que de lisser cela avec un seul chiffre. L'explication se trouve dans le post sur le nombre de langues.

Là où les pipelines se rencontrent

Les quatre pipelines ne s'exécutent pas de manière isolée. Une salle de réunion est l'endroit où ils se rejoignent, et les coutures ont leur importance :

• Un message de chat avec une pièce jointe 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 en tant que fichier téléchargeable.
• Une note partagée qui cite une ligne de transcription croise 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 de cette citation par participant dans la langue de chacun, avec son attribution de source préservée.
• Une transcription exportée après la réunion exécute le pipeline de texte de type chat sur l'ensemble de la conversation, produisant un fichier par langue que les participants peuvent télécharger. Il s'agit du même chemin de code que la traduction de chat, simplement traité en lot.

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

Ce que nous ne tentons délibérément pas

• Pas de « modèle de traduction unifié ». Nous ne construisons pas un seul modèle qui gère la voix, le chat, les notes et les documents. Le compromis latence contre fidélité n'a pas de gagnant. Nous utilisons le bon moteur pour chaque surface.
• Pas de reroutage silencieux. Si le pipeline de fichiers ne peut pas traduire en hindi aujourd'hui, nous ne revenons pas discrètement au moteur vocal en prétendant que cela a fonctionné — le sélecteur de fichiers signale l'écart au lieu de le cacher.
• Pas de « nous traduisons en 200 langues ». Notre moteur en émet 24. Les surfaces en direct livrent les 24, les documents 30 — et au lieu d'un seul chiffre favorable au marketing, la qualité par paire qui doit se présenter devant un auditeur est publiée sur /benchmark, paires les plus faibles incluses.

Essayez-le vous-même

• Essayez la démo en direct — exécute le pipeline vocal en direct sur votre audio, dans l'une des 24 langues du produit. Le même pipeline qui obtient les scores sur /benchmark.
• Consultez le benchmark — qualité par paire et par mois sur du trafic réel. Chaque paire dans le sélecteur, forte ou faible, accessible via lien profond.
• Lisez la méthodologie — ce que les chiffres représentent, ce qu'ils ne représentent pas, qui est le juge.

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

— L'équipe Mind.com

Sources : DeepL — langues prises en charge, DeepL — compte d'utilisation et facturation (le minimum de 50 000 caractères par fichier), FLORES-200 ; faits internes des pipelines vérifiés par rapport au code livré, vérifié en août 2026.