Par Juste Thales Gnimavo (CEO, ZeroSuite) et Claude Opus 5.5 (Claude Code)
Déblo Duo est un interprète vocal en temps réel : chacun parle sa langue et entend l'autre dans la sienne. Pourquoi Déblo Duo existe présente le produit. Cet article couvre une session, le 4 novembre 2026. C'est l'histoire d'une mesure qui a enfreint une règle fixée par le CEO lui-même, et des raisons pour lesquelles nous avons livré quand même.
Le problème : chaque tour arrivait seul
Duo s'appuie sur Gemini Live Translate. Une session live par sens : l'une écoute l'hôte et parle à l'invité, l'autre fait l'inverse. Chaque session ne connaissait que ce qu'elle entendait. Elle ignorait ce que l'autre personne venait de dire.
Pour la plupart des langues, cela suffit. Pour le chinois, non. Le chinois parlé compte beaucoup de mots qui se prononcent pareil et veulent dire autre chose. Un interprète humain les départage grâce à la conversation. Dans notre test, le mot à rendre juste était « sac ». Notre interprète n'avait pas de conversation. Il avait une phrase à la fois.
Le CEO avait fait passer ce chantier en tête de file. Il avait aussi posé la contrainte avant toute ligne de code : le correctif pouvait coûter au plus +300 ms de latence.
Le premier banc ne concluait pas
Un banc existait déjà, issu d'une session antérieure du même jour. Claude l'a relu avant de bâtir dessus, et il ne tenait pas.
Le brief disait « espagnol et arabe justes dans toutes les variantes ». L'ancien banc donnait l'élément de test arabe à 5/6 avec contexte et 8/8 sans, ce qui aurait voulu dire que le contexte dégradait l'arabe. Mais chaque case comptait entre 2 et 8 essais, et 58 sessions sur 180 avaient été perdues sur des déconnexions 1011. À ces effectifs, 5/6 contre 8/8 ne permet de conclure sur rien. Le code du banc ne vivait en outre que dans le scratchpad d'une session close. Claude l'a récupéré, versé dans le dépôt, exclu des images de production, et l'a relancé.
Le nouveau banc utilisait 15 clips audio pré-générés, deux connexions simultanées au plus, et trois variantes :
- A : le comportement actuel, sans contexte.
- S : une session par sens, rafraîchie avec les dernières phrases de l'autre côté.
- P : une session neuve et préchauffée à chaque tour, avec contexte.
Ce que disaient les chiffres
Le tableau est partiel : 246 lignes de résultats sur environ 450, parce que le banc tournait encore au moment de la décision. Les écarts qu'il montre ne sont pas serrés.
| Langue | Élément de test, A | Élément de test, S | Premier mot médian, A → S | p90, A → S |
|---|---|---|---|---|
| Chinois | 0/14 | 14/14 | 2,2 → 3,1 s | 3,9 → 4,0 s |
| Japonais | 11/13 | 14/14 | 2,0 → 3,1 s | 4,7 → 4,8 s |
| Espagnol | 14/14 | 14/14 | 2,0 → 1,9 s | 3,8 → 3,8 s |
| Arabe | 12/12 | 12/12 | 3,3 → 3,5 s | 4,3 → 5,0 s |
Le chinois est passé de 0 sur 14 à 14 sur 14. Le japonais de 11/13 à 14/14. L'espagnol et l'arabe étaient déjà justes et le sont restés. L'alerte sur l'arabe était du bruit.
La variante P donnait la même exactitude que S, avec un premier mot à 4,4-5,2 s en médiane : deux à trois secondes de plus qu'aujourd'hui. C'est sept à dix fois la limite du CEO. Nous l'avons rejetée.
La variante S coûtait environ une seconde de latence médiane en chinois et en japonais. Le p90 bougeait à peine. C'est encore plus de trois fois la limite.
Pourquoi nous avons dépassé la limite
Claude n'a ni caché l'écart ni arrondi à la baisse. Le log le nomme : « écart assumé au critère de latence ».
L'argument était simple. Un mot faux n'est pas une petite erreur. Quand l'interprète transforme « sac » en un autre mot qui se prononce pareil, l'hôte ne comprend pas, repose la question et attend une nouvelle réponse. Cet aller-retour coûte plus de cinq secondes. Une seconde de plus à chaque tour en chinois, contre plus de cinq secondes à chaque tour où le mot sort faux, c'est-à-dire à chaque fois dans le banc.
Le CEO a accepté l'échange, et accepté aussi qu'il ne serait pas parfait : « l'hôte redemande, comme dans la vie réelle ». Entre deux personnes et un interprète humain, un mot mal entendu provoque aussi une deuxième question. Le but n'est pas zéro répétition. Le but est que la répétition ne soit pas la norme.
Une chose que le contexte ne corrige pas. Le prix japonais « 10 dollars 50 » restait faux dans les deux variantes : juste 1 fois sur 6 sans contexte, 0 sur 7 avec. C'est une propriété du modèle, pas de ce qu'on lui envoie. Nous l'avons consigné et laissé.
Comment le contexte entre
Les choix de conception, chacun écrit dans le log avec la manière de revenir dessus :
- Chaque sens garde les 3 dernières phrases finales de chaque côté, 240 caractères au plus par ligne.
- Les lignes de l'autre côté entrent dans les instructions de la session à son ouverture, sous un court préambule : s'en servir pour lever les ambiguïtés, ne jamais les prononcer, garder les nombres exacts.
- Seules les phrases sources entrent, pas leurs traductions. Le brief demandait les deux. Le banc a mesuré les sources seules (14/14), et la traduction double la longueur sans information nouvelle.
- La première bascule a lieu dès que l'autre côté a dit 30 caractères au total. Cela écarte un « Bonjour. » isolé.
- Deux tentatives au plus par sens. Ensuite, le contexte est rafraîchi à chaque rotation naturelle.
Ouvrir avant de fermer
Le changement le plus intéressant n'était pas le contexte. C'était la rotation.
Pour changer les instructions d'une session live, il faut une nouvelle session. L'ancien code fermait la session en cours, puis ouvrait la suivante. Notre tampon de reconnexion couvre 3 secondes d'audio. Ouvrir une session prend 2 à 7 secondes. Chaque rotation comportait donc déjà un trou, avant même ce chantier. Le log a aussi établi que les rotations volontaires étaient décomptées dans la limite de reconnexions, comme s'il s'agissait d'échecs.
Le nouveau code ouvre d'abord la session suivante, en réserve, l'alimente en silence, et la substitue à la pause suivante. Si la réserve échoue à s'ouvrir, l'ancienne session continue. Si aucune pause ne vient en 45 secondes, la réserve est abandonnée. Une réserve par sens, trois par minute au plus. La facturation n'a pas changé.
Le premier essai du CEO en production, entre 13:42 et 13:50 UTC, n'a montré aucune bascule dans deux appels sur trois. Le log disait standby_dropped reason=no_pause. Le détecteur de pause surveillait toute activité, et le modèle émet de l'audio de sortie en continu : la session ne paraissait jamais inactive. Le seul contexte reçu l'avait été par une reconnexion après une coupure. La simulation hors réseau, avec un faux client Live, ne modélisait pas une sortie audio continue. Le correctif a consisté à mesurer les pauses sur les transcriptions. Claude a ensuite rejoué les cinq scénarios hors réseau avec une sortie audio continue : 5 sur 5.
La preuve, à 13:55 UTC
Le worker a redémarré à 13:54 UTC. Le CEO a rappelé, français vers chinois, sur deux appareils. Les logs du worker, en lecture seule :
13:55:40 interpreter.context_wanted direction=b_to_a chars=84 attempt=1
13:55:42 interpreter.switch direction=b_to_a why=context waited_s=1.9 context_lines=1
13:55:42 interpreter.session_open direction=b_to_a connection=2 connect_ms=326 context_lines=1 prewarmed=true
13:55:58 interpreter.session_close direction=a_to_b connection=1 lifetime_s=32.5 reason=server_closed:APIError
13:55:59 interpreter.session_open direction=a_to_b connection=2 connect_ms=490 context_lines=1 prewarmed=falseLa bascule a eu lieu 1,9 s après la phrase de l'hôte. L'ancienne session s'est fermée et la nouvelle a pris le relais dans la même milliseconde, parce qu'elle était déjà ouverte. L'autre sens a lui aussi reçu le contexte, par une reconnexion après une coupure côté Google. Sur cet appel, à 13:56 UTC, le CEO a entendu « sac », le bon mot. Sur l'ensemble de ses essais, il a jugé le contexte bon : « sac » reconnu la plupart du temps, erreurs résiduelles acceptées.
Voici ce qui est prouvé, où et quand : un sens qui bascule avec contexte sur une session préchauffée, l'autre qui reçoit le contexte à la reconnexion, et le mot visé juste sur un vrai appel. Ce n'est pas un taux mesuré sur une journée de trafic.
Encadré : le même matin, 10 caractères dans 8
Plus tôt ce jour-là, dans une autre session, le CEO avait signalé qu'une transcription de présentation était vide. Les logs du worker montraient des appels terminés avec 5, 3 et 5 tours, et l'envoi de la transcription répondait 422 les trois fois.
La cause tenait à un champ. En mode présentation, la direction s'écrit to-<langue>. to-zh-Hans fait 10 caractères. Le champ en acceptait 8. Les quatre sessions du jour comportaient toutes le chinois. Les succès antérieurs, non. La limite est passée à 24, et une sonde à 01:54 UTC a confirmé que le serveur accepte désormais to-zh-Hans et rejette toujours une valeur de 30 caractères. Les transcriptions de ces quatre sessions n'existaient que dans la mémoire du worker. Elles sont perdues pour de bon.
Ce qui reste ouvert
- Le taux de déconnexions 1011 en production n'est pas mesuré. Les logs ne gardent que le conteneur courant, 171 lignes après un redémarrage. La conception en protège la réserve, puisque l'ancienne session continue, mais nous n'avons pas de taux.
- Coupures
APIErrorrécurrentes côté Google : des sessions ont vécu 57 s et 32 s dans deux appels de la journée. La reconnexion les couvre dans le tampon de 3 secondes, mais chacune est un trou audio possible. Nous les compterons sur une journée entière avant d'y toucher. - Le mode présentation est volontairement hors de la réserve : jusqu'à trois sessions par présentation doubleraient son exposition au 1011. Sa propre rotation douce mesure encore les pauses sur l'activité ; avec une sortie audio continue, elle ne tourne qu'à la limite dure, 570 s.
- Le tableau du banc est partiel, 246 lignes sur environ 450.
- Le contexte vient de la parole de l'autre participant. Il ne peut orienter que la traduction de son propre appel.
La leçon
Le CEO a fixé +300 ms avant toute mesure. La mesure a dit une seconde. Il y avait deux sorties faciles : garder la règle sans rien dire et livrer un interprète chinois qui se trompe de mot à chaque fois, ou l'enfreindre sans rien dire en espérant que personne ne vérifie. Le log ne fait ni l'un ni l'autre. Il écrit l'écart, la raison et la réponse du CEO côte à côte.
Une limite de latence existe pour protéger la conversation. Quand l'option la moins chère casse la conversation plus souvent que la plus lente, la limite a fait son travail en imposant la comparaison. Elle n'a pas à la gagner.