Une erreur de 0,3 seconde peut compromettre quatre projets payants
Un écart d'arrondi de 0,3 seconde entre deux sources de vérité a coûté à un développeur son premier client payant : quatre projets échoués. Une partie du système stockait la durée à 3983 secondes, tandis qu'une autre la mesurait entre 3982,699 et 3982,788 secondes. La barrière de qualité rejetait chaque repère dépassant la limite certifiée, même si elle fonctionnait parfaitement. Le client n'a reçu ni sous-titres, ni explication, ni solution — seulement quatre échecs identiques.
Le coût caché des hypothèses d'arrondi
La cause racine n'était ni un code instable ni des conditions de course, mais un décalage déterministe entre deux autorités pour un même nombre. L'aperçu du navigateur arrondissait la durée du projet à la seconde près, tandis qu'un processus secondaire mesurait le média avec une précision milliseconde. La génération des repères utilisait la valeur arrondie, mais la certification de livraison s'appuyait sur la mesure fiable. Le dernier repère dépassait systématiquement la limite de 212 à 301 millisecondes, déclenchant le même rejet à chaque fois. La correction fut simple : déclarer la mesure fiable du média comme unique source de vérité pour la génération, la composition, l'assurance qualité, la certification, l'export et les relances.
Des limites non définies favorisent les hypothèses les moins coûteuses
L'erreur plus profonde était une hypothèse tacite : « la langue du script est la langue de l'audio ». Le système n'avait jamais défini ce qui devait se produire lorsqu'un client chargeait un script traduit synchronisé avec l'audio original. Dans ce cas, un doublage japonais de 66 minutes nécessitait des sous-titres chinois alignés sur la parole. Sans décision produit claire, l'implémentation supposait que le script reflétait la langue de l'audio, décodait l'audio japonais comme du chinois, et produisait des sous-titres sans rapport. L'utilisateur n'avait commis aucune erreur : la décision produit avait ignoré la frontière entre l'audio source et le texte cible.
La qualité est une décision produit, pas une vérification finale
La barrière de qualité a fait exactement ce pour quoi elle avait été conçue : rejeter les sorties non sûres avant qu'elles n'atteignent le client. Pourtant, ce client a perdu quatre projets. L'enseignement est clair : la qualité n'est pas la vérification finale qui écarte les mauvaises sorties ; c'est la limite d'entrée à laquelle vous vous engagez, l'autorité que vous accordez à chaque donnée, et les états d'échec que vous anticipez. Dans des pipelines où un seul chiffre erroné peut entraîner des échecs répétés, le contrat doit être : une donnée, une source, et une décision produit pour chaque cas limite.
Pourquoi cela compte
Cet incident montre comment un écart d'arrondi apparemment minime peut provoquer des échecs répétés pour des clients payants, même lorsque chaque barrière se comporte correctement. Cela souligne que la qualité doit être intégrée au produit dès le départ — et non ajoutée en fin de processus. Pour les équipes construisant des pipelines mêlant timing, alignement et langue, les enjeux sont clairs : définissez vos limites d'entrée, choisissez une source de vérité unique, et traitez chaque hypothèse comme une décision produit avec des modes d'échec explicites. L'alternative est un système qui « fonctionne » en rejetant le travail, tout en échouant ses utilisateurs.
Source : DEV Community. Synthèse éditoriale assistée par IA — TechnoExpress.