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

L'ancienne page /product/overview/how-it-works sur mind.com est obsolète de plusieurs versions majeures. Elle décrit un « moteur de traduction » unique comme le font la plupart des pages de fournisseurs — 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é 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 de moteur.

C'est la réponse mise à jour à « comment ça marche ».

À lire également : « Combien de langues prenez-vous en charge ? » couvre ce que chaque pipeline couvre (23 / 23 / 30 / 17). Cet article couvre ce que chaque pipeline fait — et pourquoi il est une entité propre.

Pourquoi « un seul moteur pour tout » est un mensonge

Une plateforme de réunions 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 entrant, audio traduit sortant, 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 des modifications et des citations et la structure HTML préservée.
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. Aucun budget de latence. La contrainte difficile est la fidélité — formatage, tableaux, numéros de page, police.

Vous pouvez construire un seul 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 format 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 sa propre oreillette, avec un délai suffisamment court pour garder le contact visuel possible.

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

Comment l'audio se déplace réellement

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

• L'ASR s'exécute sur le serveur multimédia. L'audio de l'orateur voyage via WebRTC vers notre propre moteur — l'API Mind sur OVH, en France — et y est reconnu, sur le même serveur qui porte l'appel ; le navigateur se contente d'envoyer l'audio et de recevoir les mots en retour. Pas de fournisseur de reconnaissance vocale distinct et pas de saut supplémentaire avant que la traduction puisse commencer. (Les notes vocales du chat sont l'exception : leur conversion parole-texte s'exécute sur Azure AI Speech, le service vocal de la passerelle AI par défaut.)
• La traduction n'est pas un simple fan-out. Le moteur traduit par langue cible présente dans la salle, et non par participant : la traduction vers une langue commence lorsque le premier auditeur la demande, trois participants ayant choisi l'allemand partagent une même traduction en allemand, et si personne n'écoute en arabe, rien n'est traduit en arabe. C'est pourquoi une réunion à quatre langues coûte la même chose qu'une réunion à quarante langues, dans la limite des participants réellement présents — nous ne traduisons jamais vers des langues qu'aucun participant n'écoute.
• La synthèse vocale est propre à chaque participant. 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î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 salle physique peuvent chacune brancher des écouteurs et entendre des langues différentes.

Pourquoi c'est important quand une réunion tourne mal

Dans un appel de 60 minutes avec huit langues, les choses cassent de manières intéressantes : les WebSockets se coupent, l'ASR transcrit mal temporairement un nom propre, le réseau d'un participant devient saccadé. 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 affectée doit se rétablir.

Le moteur lui-même est le nôtre, hébergé sur notre propre infrastructure. Nous ne routons pas la voix en temps réel via des LLMs généralistes tiers. Le budget de latence les exclut ; l'exigence de résidence des données les exclut pour les clients régulés à qui cela importe réellement.

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

Pipeline 2 : Traduction du 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 de l'envoi. Plus les modifications — et les modifications doivent ressembler à des modifications, pas à de nouvelles traductions.

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 des pré- et post-traitements 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 renvoyons 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 constitue son propre appel de traduction. Nous ne fournissons 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 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 champ de vision du participant. Changer de langue dans un canal de longue durée avait autrefois pour effet de rejouer chaque appel à l'API de traduction depuis l'historique. Ce n'est plus le cas maintenant.

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 changé.

Le nouveau comportement :

1. Le message d'origine avait 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 l'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 (avec état) par participant, et non comme un point de terminaison translate-on-request (traduction à la demande) sans état. Les documents et la voix n'ont pas besoin de cela. 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 :

• Ce qui est traduit change en cours de traduction. L'hôte tape encore. Un système naïf qui traduit « le document entier » à chaque frappe produit du 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 obtenez en retour 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 :

« Examen de conformité — livrables Q2 »

— et non :

"# Plan de projet\n## Trimestre\n- Examen de conformité — livrables Q2\n- Notation des fournisseurs\n - Fournisseurs de Tier 1..."

Le document enveloppant — la balise <ul>, les titres, l'indentation — est reconstruit 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 modifie 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 en 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 de moteur avec la voix

Un LLM généraliste, même un très bon, vous remettra un texte traduit d'un document. Il ne vous remettra 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 l'API DeepL Document directement. 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é au 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 pièce jointe 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 le plan Pro, qu'il y ait une page ou trente pages dans le document. 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 manière dont le reste du produit rapporte l'activité de traduction.

Nous avons choisi DeepL pour cette surface parce que traduire des fichiers en tant que fichiers est exactement la tâche pour laquelle il a été conçu — nous n'avons pas essayé d'en construire un meilleur. L'inverse n'est pas vrai — DeepL n'exécute pas de pipeline vocal en direct du type que nous avons construit 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 23 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 figure également sur cette liste, et c'est l'une des langues supplémentaires : il est retiré du sélecteur en temps réel tant que sa qualité vocale est inférieure à notre seuil, et ses scores par paire restent publics sur /benchmark — c'est ce chiffre qui le ramènera. L'asymétrie va dans l'autre sens 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 francophone à 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. Le raisonnement se trouve dans le post sur le nombre de langues.

Là où les pipelines se rencontrent

Les quatre pipelines ne s'exécutent pas isolément. 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 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 téléchargement.
• 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 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 pour la traduction de chat, mais traité par lots.

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

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 vs. 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 et ne faisons pas semblant que cela a fonctionné — le sélecteur de fichiers signale le manque au lieu de le cacher.
• Pas de « nous traduisons en 200 langues ». Notre moteur en émet 24. Les interfaces en direct en proposent 23, les documents 30 — et au lieu d'un seul chiffre flatteur pour le marketing, la qualité par paire qui doit se tenir face à un audit 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 n'importe laquelle des 23 langues du produit. Le même pipeline qui est évalué sur /benchmark.
• Voir le benchmark — qualité par paire et par mois sur du trafic réel. Chaque paire dans le sélecteur, forte ou faible, avec un lien profond disponible.
• Lire la méthodologie — ce que sont les chiffres, ce qu'ils ne sont 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 — nombre d'utilisations 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.