Jitsi Meet : pourquoi la transcription pour les dossiers médicaux électroniques nécessite Jigasi et Vosk

Jitsi Meet supporte la transcription, mais dans un vrai produit cela s'avère ne pas être un bouton dans l'interface, mais une couche d'infrastructure séparée. Dans le cas du remplissage automatique des dossiers médicaux électroniques après des consultations vidéo, cette couche s'est avérée être la plus laborieuse : il a fallu réunir Jigasi, XMPP/SIP, Vosk et du post-traitement par LLM.

Architecture Sous le Capot

L'idée basique de Jitsi semble simple que de la surface. L'appel vidéo lui-même est géré par le frontend Jitsi Meet, le serveur média Jitsi Videobridge, le gestionnaire de conférences Jicofo et la couche XMPP Prosody. Mais la transcription ne vit pas à l'intérieur d'un seul bouton dans l'interface.

Jigasi en est responsable — une passerelle séparée qui se connecte à la salle comme un participant ordinaire, reçoit l'audio des interlocuteurs et envoie le flux vers un service externe de reconnaissance vocale. Cela crée une fausse impression de simplicité au départ. C'est pour cela que la tâche passe rapidement du niveau « connecter une API » au niveau infrastructure.

Il ne suffit pas simplement d'activer une option dans l'UI, mais de coordonner plusieurs services, des connexions réseau et un backend STT séparé. Dans le cas analysé, ce backend était Vosk, exécuté sur WebSocket. L'approche en elle-même convient bien au traitement asynchrone après une consultation : le système n'a pas besoin de s'adapter à des latences strictes en temps réel, et le texte résultant peut être confortablement analysé après la fin de l'appel.

Où le Schéma Échoue

Le problème principal est que la transcription a plusieurs points de défaillance indépendants d'emblée. La configuration de Jigasi, les paramètres du frontend Jitsi Meet et la disponibilité du service STT doivent coïncider en même temps. Si une couche est mal configurée, le système échoue souvent sans erreur claire, mais ne fournit simplement pas le résultat attendu : le bot n'entre pas dans la salle, le fichier n'est pas sauvegardé ou le texte est trop faible pour un usage pratique. Sans regarder les logs, ces défaillances sont faciles à confondre avec du hasard.

«

Jigasi est une passerelle SIP avec transcription, pas l'inverse ».

• un compte XMPP séparé pour Jigasi dans Prosody : s'il y a une erreur avec lui, le bot transcripteur n'apparaîtra pas du tout dans la conférence ;
• permissions sur le répertoire avec les transcriptions : les sous-titres intermédiaires peuvent passer, mais le fichier final ne sera pas sauvegardé sur le disque ;
• choix du modèle STT : Vosk basique convient pour MVP, mais gère moins bien les termes médicaux, les noms de médicaments et les dosages ;
• détection de la fin de session : Jigasi écrit le texte final uniquement lorsque la salle est vraiment vide, mais le pipeline downstream a besoin d'un déclencheur fiable pour le traitement.

Une nuance distincte est la séparation des canaux pour sauvegarder et envoyer les résultats. Un ensemble de paramètres est responsable de l'enregistrement du texte final sur disque après la fin de la consultation, un autre de la transmission des fragments intermédiaires aux participants via XMPP. Pour un produit qui remplit les dossiers médicaux après coup, il est plus important d'obtenir de manière fiable le fichier final que d'afficher les sous-titres en temps réel. Sinon, l'étape suivante du traitement n'a rien à partir duquel commencer, et toute l'automatisation se bloque.

Du Texte au Dossier Médical

Même après avoir configuré avec succès Jitsi, la tâche ne s'arrête pas. La sortie de Jigasi est un dialogue brut avec horodatages : le médecin pose des questions, le patient répond, puis viennent les rendez-vous et recommandations. Pour un dossier médical, ce texte est pratiquement inutile dans sa forme originale, car le système a besoin non pas de répliques comme telles, mais d'entités structurées : plaintes, historique des symptômes, médicaments, dosages, régime d'administration et actions ultérieures.

Entre la reconnaissance vocale et le dossier médical subsiste une autre couche importante de transformations. C'est pourquoi une autre couche a été nécessaire au-dessus du STT — le traitement par LLM. Le modèle normalise le texte, corrige certaines erreurs de reconnaissance sur la base du contexte, et divise le résultat en champs compatibles avec les structures FHIR.

Après cela, les données vont à un formulaire frontend où le médecin vérifie et confirme l'enregistrement avant de le sauvegarder finalement dans le dossier médical. Un tel human-in-the-loop ici n'est pas une surcaution, mais une exigence obligatoire : dans un scénario clinique, on ne peut pas automatiquement inscrire des médicaments, des doses et des prescriptions dans le dossier sans révision. C'est là que la limitation du STT « bon marché » devient visible.

Si le modèle basique reconnaît mal le vocabulaire du domaine, toute le reste de la chaîne commence à dépenser des ressources pour corriger les erreurs. Pour une version production, des modèles Vosk plus lourds s'imposent, un moteur spécialisé comme Deepgram avec profil médical, ou une combinaison de STT et normalisation par LLM où le modèle de langage compense les erreurs de reconnaissance. Sinon, le coût des erreurs est déjà trop élevé au niveau du dossier médical.

Ce Que Cela Signifie

L'histoire de Jitsi Meet montre une chose simple : la transcription pour un produit IA appliqué est un sous-système séparé, pas une fonctionnalité cosmétique. Pour un MVP, un schéma asynchrone avec Jigasi et Vosk fonctionnera, mais pour la production en médecine, une mise au point précise de toute la pile est nécessaire, de bons logs, un contrôle de la fin de session et une couche de normalisation qui transforme une conversation en données adaptées aux dossiers médicaux. Plus le domaine est strict, plus l'illusion que tout se règle avec une seule case à cocher dans l'interface devient coûteuse.