Le temps réel, sans rechargement

Parler à un assistant, c'est tenir un fil. Si chaque phrase repartait de zéro, la conversation perdrait sa mémoire immédiate et son rythme. Voici pourquoi nous avons choisi un canal toujours ouvert.

Une conversation n'est pas une suite de requêtes

L'architecture web classique repose sur des requêtes isolées : on demande, on reçoit, on raccroche. C'est parfait pour charger une page, mais inadapté à un échange vivant. Une conversation a une continuité : ce que tu viens de dire colore la réponse suivante, l'assistant peut parler en plusieurs temps, l'audio arrive par fragments. Traiter chaque phrase comme un formulaire indépendant aurait cassé ce naturel.

Un canal qui reste ouvert

Nous avons donc bâti l'échange sur un WebSocket : une connexion unique, ouverte le temps de la session, dans laquelle les messages circulent dans les deux sens. Le client envoie l'audio, le serveur renvoie le texte et la voix, sans rétablir la connexion à chaque tour. L'authentification se fait à l'ouverture, par un jeton transmis dès la poignée de main — ensuite, le tunnel est établi, et tout passe par lui.

L'audio comme un flux

Ce canal permet de traiter la voix comme un flux plutôt que comme un fichier. La réponse peut commencer à être jouée pendant qu'elle se génère encore, et le serveur sait s'adapter : si l'utilisateur a coupé le son, il n'envoie tout simplement pas la synthèse vocale, économisant un calcul inutile. Le même tuyau sert à tout — c'est ce qui rend l'échange fluide plutôt que saccadé.

Rester vivant malgré le réseau

Un canal ouvert a une fragilité : le réseau peut le couper. Une coupure de tunnel ne fait pas disparaître la mémoire ni la conversation en cours ; à la reconnexion, le fil reprend là où il s'était interrompu. Sur mobile, où l'on passe du Wi-Fi à la 4G en marchant, cette résilience n'est pas un détail : c'est la condition pour qu'un assistant vocal reste un compagnon de tous les instants.