philippe-defleur

La visioconférence est déjà un système temps réel complexe.

Lorsque l’on ajoute la reconnaissance vocale, la traduction, la génération de voix, plusieurs langues et plusieurs participants connectés depuis des réseaux différents, le problème devient beaucoup plus intéressant.

Je suis ingénieur backend et fondateur de Voicli, une plateforme de visioconférence multilingue accessible depuis le navigateur, avec traduction vocale en temps réel et sous-titres traduits.

En développant ce produit, j’ai rapidement compris qu’une traduction vocale en direct ne se résume pas à :

parole → texte → traduction → voix

Le véritable défi consiste à faire fonctionner toutes ces étapes ensemble de manière suffisamment rapide et prévisible pour que deux personnes aient encore l’impression d’avoir une conversation naturelle.


Une traduction différente pour chaque participant

Dans une conversation classique entre deux langues, le problème semble simple : traduire de la langue A vers la langue B.

Mais une réunion multilingue peut contenir plusieurs participants.

Imaginons trois personnes :

- une parle français ;
- une parle coréen ;
- une parle ukrainien.

Lorsque la personne française parle, les deux autres participants n’ont pas nécessairement besoin de la même sortie.

L’un veut entendre la traduction en coréen.
L’autre veut l’entendre en ukrainien.

Un troisième participant pourrait même préférer conserver la voix originale et uniquement lire des sous-titres.

La traduction devient donc un problème spécifique à chaque auditeur.

Le système doit connaître non seulement la langue du locuteur, mais également la langue que chaque participant souhaite recevoir.


La latence est aussi importante que la précision

Lorsqu’on parle de traduction par intelligence artificielle, on pense souvent d’abord à la qualité de la traduction.

Dans une conversation en direct, la latence est pourtant tout aussi importante.

Une traduction excellente qui arrive huit secondes après la phrase originale rend rapidement la conversation pénible.

Plusieurs étapes introduisent du délai :

1. capture de l’audio ;
2. détection et reconnaissance de la parole ;
3. compréhension du contexte ;
4. traduction ;
5. génération de la voix traduite ;
6. transport réseau ;
7. lecture du résultat dans le navigateur.

Optimiser uniquement le modèle de traduction ne suffit donc pas.

Il faut observer toute la chaîne.

J’ai également constaté qu’un délai légèrement supérieur mais relativement stable est souvent moins gênant qu’une latence qui varie constamment.


Les interruptions compliquent énormément le problème

Les conversations humaines ne sont pas propres.

Les gens s’interrompent, commencent une phrase avant que l’autre personne ait terminé ou parlent simultanément.

Dans une visioconférence classique, cela est normal.

Pour un système de traduction vocale, deux voix qui se superposent peuvent créer beaucoup plus de problèmes : reconnaissance simultanée, traductions concurrentes et lecture de plusieurs voix traduites.

C’est pourquoi le produit lui-même doit parfois guider le comportement des utilisateurs.

Parler chacun son tour, utiliser des phrases relativement courtes et laisser une petite pause peut améliorer considérablement le résultat.

C’est une leçon intéressante des produits IA temps réel : toutes les améliorations ne viennent pas nécessairement d’un meilleur modèle. L’UX et le comportement utilisateur font aussi partie de l’architecture du système.


Voix originale, traduction vocale ou sous-titres ?

Les utilisateurs n’attendent pas tous la même chose.

Certains veulent entendre uniquement la traduction.

D’autres veulent conserver la voix originale parce que le ton, l’émotion et l’intonation transmettent également de l’information.

D’autres préfèrent simplement lire des sous-titres.

Nous avons donc dû penser la traduction comme plusieurs modes de communication plutôt qu’une seule fonction.

Cette flexibilité est particulièrement importante dans les réunions professionnelles, où comprendre les mots ne représente qu’une partie de la communication.


Pourquoi le navigateur ?

Voicli fonctionne directement dans un navigateur web.

C’est un choix produit, mais il a des conséquences techniques.

Une application web dépend notamment :

- des permissions du microphone et de la caméra ;
- de WebRTC ;
- des différences entre navigateurs ;
- des conditions réseau ;
- de la configuration audio de l’appareil.

Une application native donne davantage de contrôle.

Mais le navigateur présente un avantage important : réduire la friction.

Lorsqu’un commercial invite un client international ou qu’un recruteur invite un candidat, demander d’installer un logiciel inconnu constitue déjà une barrière supplémentaire.

Un lien est beaucoup plus simple.


L’état du système doit être visible

Un autre enseignement concerne l’interface.

Les systèmes temps réel peuvent avoir besoin de quelques secondes pour se synchroniser.

Une connexion peut être momentanément perdue.
Le canal de traduction peut se reconfigurer.
Un participant peut changer de langue.

Si l’interface cesse simplement de produire une traduction, l’utilisateur ne sait pas ce qui se passe.

Nous utilisons donc différents états visibles : prêt, synchronisation, attente, reconfiguration, reconnexion ou problème.

Cela ne réduit pas directement la latence, mais améliore fortement la perception de fiabilité.

Dans un système temps réel, expliquer ce que fait le système fait partie de l’expérience.


21 langues créent aussi un problème de localisation

Voicli prend actuellement en charge 21 langues :

arabe, chinois, néerlandais, anglais, français, allemand, hébreu, hindi, indonésien, italien, japonais, coréen, polonais, portugais, roumain, russe, espagnol, thaï, turc, ukrainien et vietnamien.

Ajouter une langue n’est pas seulement une question de modèle de traduction.

Il faut aussi gérer :

- la traduction de l’interface ;
- les langues de droite à gauche ;
- les différences de terminologie ;
- la longueur des textes ;
- la ponctuation ;
- la qualité réelle des traductions.

Une traduction automatique peut être grammaticalement correcte tout en étant sémantiquement fausse.

Par exemple, le mot anglais « minutes » peut signifier une durée ou un compte rendu de réunion. Sans contexte suffisant, une traduction automatique peut choisir le mauvais sens.

La localisation nécessite donc sa propre validation.


La partie la plus importante n’est finalement pas toujours technique

En tant qu’ingénieur, j’ai commencé par penser surtout à l’architecture, aux WebSockets, à l’audio, aux modèles IA et à la latence.

Mais construire le système n’est qu’une partie du travail.

Il faut aussi répondre à des questions comme :

- Qui rencontre réellement ce problème ?
- Dans quelles situations la barrière linguistique est-elle suffisamment importante pour changer les habitudes ?
- Les utilisateurs veulent-ils une voix traduite ou seulement des sous-titres ?
- Quelle latence est acceptable ?
- Dans quels marchés ce problème est-il le plus fréquent ?

Aucune de ces questions ne peut être résolue uniquement avec du code.

Il faut parler avec des utilisateurs réels.


Conclusion

La traduction vocale en temps réel n’est pas simplement un problème de modèle d’intelligence artificielle.

C’est un problème de système.

Navigateur, transport audio, reconnaissance vocale, traduction, génération de voix, routage, WebSockets, latence et comportement humain doivent fonctionner ensemble.

Chaque composant peut fonctionner correctement alors que l’expérience globale reste mauvaise.

C’est précisément ce qui rend ce type de produit intéressant à construire.

Le but final n’est pas simplement de traduire une phrase.

Le but est de permettre à deux personnes qui ne parlent pas la même langue d’avoir malgré tout une véritable conversation.

Pour ceux qui souhaitent voir le produit sur lequel je travaille :
Voicli – visioconférences multilingues avec traduction vocale en temps réel