Tolky : traduction vocale temps réel native dans le navigateur pour le B2B
Tolky est un traducteur vocal temps réel dans le navigateur pour le néerlandais, le français, l'anglais, le turc, l'allemand et l'espagnol. Ouvrez un lien, parlez, recevez l'audio traduit — aucune installation d'application. Voici ce que nous avons livré et ce qui le rend possible.
Tolky est né d'une observation utilisateur : un généraliste à Anvers avec un néerlandais limité, un patient qui ne parle que turc, et dix minutes de durée de consultation. Aucune installation d'application, aucune création de compte, aucun appairage d'appareil ne pouvait avoir lieu dans cette salle. La traduction devait vivre dans un onglet de navigateur.
Ce que fait le produit
Tolky capture l'audio du microphone dans le navigateur, l'envoie à un modèle de traduction qui supporte la parole vers parole en faible latence, et restitue l'audio traduit via le navigateur. Aujourd'hui six langues : néerlandais, français, anglais, turc, allemand et espagnol. Le transport passe par WebSockets, le pipeline de capture passe par la Web Audio API, et le client complet est une application monopage sans dépendances natives.
Les deux problèmes difficiles
Latence qui survit à une vraie conversation
La latence n'est pas un nombre sur un dashboard — c'est la différence entre une conversation qui coule et une conversation qui hésite. Nous avons réglé la taille de trame audio sur un sweet spot que la worklet Web Audio peut restituer sans buffer, et nous négocions la session WebSocket une fois par conversation et jamais au milieu d'une émission. Les renégociations étaient de loin la plus grande source de latence perçue dans les premières versions.
Isolation capture / lecture
L'audio traduit ne doit pas revenir dans la boucle de capture. Nous avons séparé explicitement les étages d'amplification d'entrée et de sortie et bloqué la capture pendant les fenêtres de lecture. Faites-le mal et le modèle traduit sa propre sortie avec plaisir dans une boucle de rétroaction qui produit du non-sens après trois secondes.
Qui l'achète et pourquoi
Trois segments de clientèle ont signé les lettres d'intention early-access :
- Cabinets de médecine générale et hôpitaux. Traduction patient-soignant pendant les consultations. La contrainte produit est que l'appareil est celui que le comptoir tend au patient — un iPad de clinique, un téléphone personnel, un vieux laptop. Natif navigateur couvre les trois.
- Municipalités et CPAS/OCMW. Accueils, entretiens de service social et réunions parents-enseignants en école. La porte d'entrée achat est la conformité RGPD plus un DPA signé.
- Collaboration en entreprise. Équipes avec membership mixte en langues, surtout dans les régions frontalières (FR/BE/DE) où la traduction ad hoc signifiait auparavant tirer quelqu'un d'une réunion.
La posture de conformité qui a conclu les deals
Deux exigences contre-intuitives qui ont transformé les pilotes précoces en contrats signés :
- Inférence hébergée dans l'UE. Un SaaS qui fait tourner son app à Francfort mais appelle un modèle hébergé aux US n'est en aucune façon « hébergé dans l'UE » qui compte pour un DPO belge. Nous avons forcé le endpoint d'inférence dans une région UE dès le jour un.
- Un modèle de DPA signé, prêt sur demande. L'achat l'a demandé au premier entretien. Le modèle signé par le juridique et prêt à contre-signer faisait la différence entre un cycle de vente de 6 semaines et un de 4 mois.
Ce qui suit
La prochaine vague est la facturation par siège pour la couche B2B, des lexiques personnalisés pour le vocabulaire sectoriel (médical, juridique, éducatif), et un dashboard de reporting d'usage pour qu'un acheteur CPAS puisse démontrer la valeur à son auditeur. Le navigateur reste la plateforme ; c'est le workflow qui s'épaissit.