Transcrire la vidéo en direct, sous 300 ms

Le contexte : sous-titrer un flux vidéo pendant que l’orateur parle

Le produit devait afficher une transcription en direct d’un flux vidéo, mot à mot, pendant que l’orateur parle — avec une boucle de feedback IA qui corrige et enrichit le texte à la volée. L’enjeu n’était pas la qualité de transcription en différé (Whisper la résout déjà) mais la latence perçue : au-delà de ~400 ms, le sous-titrage « décroche » de l’image et devient inutilisable.

Le défi : streamer vers Whisper sans dépasser 400 ms de latence

• Streamer l’audio extrait de la vidéo vers Whisper par fenêtres glissantes, sans attendre la fin de chaque segment.
• Garder le serveur non bloquant sous charge : plusieurs sessions de transcription simultanées sur une seule instance.
• Pousser chaque mise à jour partielle vers le frontend sans polling.

L’approche : Rust (Actix, Tokio), fenêtres glissantes et SSE

J’ai construit le backend en Rust avec Actix et un runtime Tokio pour gérer l’I/O asynchrone. L’audio est découpé en fenêtres chevauchantes envoyées à Whisper ; les résultats partiels remontent au navigateur via Server-Sent Events (SSE), plus simples et plus robustes que des WebSockets pour un flux unidirectionnel serveur → client.

Côté React, le chat se met à jour de façon incrémentale à chaque événement SSE, avec une boucle de feedback IA qui réconcilie les segments partiels en texte stabilisé.

Le résultat : moins de 300 ms de bout en bout, sessions concurrentes

Une latence de bout en bout maintenue sous 300 ms, une seule instance Rust absorbant plusieurs sessions concurrentes, et une UI de transcription qui suit réellement le rythme de la parole.

Stack & rôle : Rust, Actix, Tokio, Whisper, React, Docker

Mission freelance (Paris, hybride). Backend Rust (Actix, Tokio, Python) et intégration Whisper côté conteneurs Docker ; frontend React / TypeScript / TailwindCSS avec transport SSE. Conception de l’architecture streaming de bout en bout.