Constat du bug

Lors d'une série de tests personnels, l'auteur a observé que chaque fois qu'une vidéo YouTube était fermée puis rouverte, le lecteur reprenait environ 20 secondes avant le point d'arrêt initial. Le phénomène se reproduit après une simple fermeture de l'onglet (Ctrl+W) suivie d'une réouverture (Ctrl+Shift+T), ainsi qu'après la fermeture du navigateur complet. Le même checkpoint, lorsqu'il est chargé via l'application Android, se comporte correctement, indiquant une divergence entre le client web et le client mobile.

Mécanisme de restauration des timestamps

Le lecteur YouTube stocke le point de reprise dans un « checkpoint » persistant, probablement dans le stockage local du navigateur. Chaque réouverture déclenche une lecture du checkpoint, mais le code client applique une correction de ‑20 secondes avant de transmettre la valeur au lecteur vidéo. Cette correction apparaît systématique : trois réouvertures successives entraînent trois décalages de 20 secondes, confirmés par l'observation d'une dérive cumulative.

Analyse du code client et différences plateforme

En utilisant les DevTools de Chrome (F12), l'auteur a localisé la fonction de « seek » responsable du saut de timestamp. Le script JavaScript est fortement obfusqué, ce qui rend le suivi du flux d'exécution difficile. Pour contourner cette barrière, un script Tampermonkey a été injecté : il intercepte chaque appel de seek et consigne le passage de from → to dans la console. Le fragment suivant illustre l’interception :

document.addEventListener('yt-player-seek', e => {
  console.log(`Seek ${e.detail.from} -> ${e.detail.to}`);
});

Le journal montre systématiquement un appel de seek avec une valeur cible inférieure de 20 secondes au checkpoint stocké. En comparant le comportement du client web avec celui de l'application Android, il apparaît que le mobile récupère le timestamp brut depuis le serveur, alors que le client web applique la correction locale, probablement pour compenser un problème de synchronisation perçue.

Implications et limites

Le bug révèle une logique de récupération de position qui n’est pas homogène entre les plateformes. Cette incohérence peut entraîner une perte de contenu pour les utilisateurs qui s’appuient sur la fonction de reprise automatique du navigateur. Le fait que le code soit obfusqué empêche une identification précise du module responsable, limitant la capacité à proposer un correctif sans accès au dépôt interne de Google. De plus, l’analyse repose sur un seul environnement (Chrome sous Windows) ; d’autres navigateurs ou configurations pourraient présenter des comportements différents. Enfin, l’utilisation de scripts tiers comme Tampermonkey expose le processus de débogage à des risques de sécurité, notamment si le script est exécuté sur des pages non fiables.