Le flux Atom de YouTube annonçait 95 vues, la page en affichait 118
Mesures réelles — 30 lectures du même document, deux sources croisées
Le flux Atom d'une chaîne YouTube donne les compteurs de vues sans session ni clé d'API. J'ai mesuré ce qu'il vaut comme source : douze lectures en quarante-cinq secondes rendent des valeurs contradictoires pour la même vidéo, puis trente lectures consécutives rendent zéro résultat utilisable. Et au même instant, la page de la vidéo affichait 19 % de vues en plus.
Le flux https://www.youtube.com/feeds/videos.xml?channel_id=... porte, pour chaque vidéo d'une chaîne, une balise <media:statistics views="N">. Pas de session, pas de clé d'API, pas de quota déclaré, six kilo-octets. C'est la source évidente pour suivre ses propres vues par programme, et c'est celle que j'utilisais.
Elle n'est pas fiable, et sa façon d'échouer est pire que de tomber en panne : elle répond, avec un chiffre trop bas. Le 18 septembre 2026 à 05:15 UTC, pour la même vidéo au même instant, le flux annonçait 95 vues quand la page de la vidéo en affichait 118. Sur une seconde vidéo, 6 contre 12.
Ce que je mesure, et ce que je ne mesure pas
Je n'ai aucun accès à une valeur de référence : le chiffre « vrai » vit dans YouTube Studio, derrière une session. Je ne mesure donc pas l'exactitude du flux. Je mesure sa cohérence interne — ce qu'il répond à la même question posée plusieurs fois de suite — et son accord avec une seconde source indépendante.
C'est suffisant pour trancher : une source qui se contredit elle-même ne peut pas être plus exacte que sa propre dispersion.
Premier symptôme : deux valeurs pour la même vidéo, à quatre secondes d'intervalle
Douze lectures du même document, quarante-cinq secondes, même User-Agent :
| résultat | |
|---|---|
| Code HTTP | 200 douze fois sur douze |
| Taille de la réponse | 6 118 octets douze fois sur douze |
| Vidéo A | 95 vues, douze fois sur douze |
| Vidéo B | 2 vues sept fois, 5 vues cinq fois, sans motif |
La taille de la réponse ne trahit rien, les deux valeurs tenant sur un seul caractère. Deux documents de poids identique, servis avec le même code, portent deux chiffres différents pour la même vidéo. Sans la colonne « taille », on croirait avoir reçu deux documents différents ; on a reçu deux fois le même, avec deux contenus.
Pourquoi un réessai ne répare pas ça
Mon premier garde-fou réessayait tant que le flux arrivait vide — un cas réel, mesuré la veille : 1 609 octets, HTTP 200, en-tête de chaîne complet, zéro <entry>. Une réponse vide n'est pas une mesure à zéro, et le réessai était le bon correctif pour ce cas.
Il ne voit pas une réponse qui arrive avec un chiffre différent. Une lecture unique tombe sur la valeur d'un cache au hasard, et sept fois sur douze c'était la plus basse. Le script écrivait la valeur sur laquelle il tombait.
Deuxième symptôme : trente lectures, zéro utilisable
Le même jour à 05:12 UTC, trente lectures, quatre secondes d'intervalle, même User-Agent :
| résultat | |
|---|---|
| Lectures utilisables | 0 sur 30 |
| HTTP 404 | 29 |
| HTTP 500 | 1 |
| Temps de réponse | 19 à 70 ms |
Dix-neuf millisecondes, c'est un rejet immédiat, pas un dépassement de délai. Et la dégradation avait été monotone sur deux heures : 2 lectures perdues sur 6, puis 4 sur 6, puis 30 sur 30.
Ce que j'ai vérifié avant d'accuser qui que ce soit
Deux requêtes, pas plus — on ne diagnostique pas une saturation en la nourrissant.
Le corps du 404 est le 404 générique de Google, celui à l'image du robot. Aucun HTTP 429, aucun message de quota, nulle part. La limitation de débit n'est donc pas établie ; elle est seulement plausible. Et comme j'avais moi-même fait une trentaine de requêtes en deux minutes, mon propre volume reste un facteur que je ne peux pas écarter — je l'écris parce que c'est l'hypothèse qui m'accuse.
Une page YouTube ordinaire répondait HTTP 200 en 465 ms depuis la même machine, au même moment. Ce n'est donc pas l'adresse IP qui est bloquée : c'est ce point d'accès qui ne répond plus. Un point d'accès qui alterne 200-sans-contenu, 404 et 500 ressemble à une infrastructure qui bat, pas à une route retirée proprement.
La découverte qui compte : la seconde source donnait plus
En cherchant par quoi remplacer le flux, j'ai regardé la page de la vidéo. Elle porte un champ numérique :
"originalViewCount":"118"Ce n'est pas le libellé affiché ("118 vues", avec une espace insécable et une dépendance à la langue servie) : c'est un entier, et il est là pour être lu.
| vidéo | flux Atom | page de la vidéo | écart |
|---|---|---|---|
| A | 95, figée depuis plus d'une heure | 118 | −19 % |
| B | 6 | 12 | −50 % |
Le flux ne se contentait pas de tomber : il servait des valeurs fausses par le bas. Les paliers que je voyais dans ma série — 22 vues sur trois relevés couvrant 2 h 04, puis 71 sur cinq relevés couvrant 2 h 46, puis 95 — n'étaient pas des plateaux d'audience. C'étaient des durées de vie de cache. Je le soupçonnais ; une source indépendante l'a établi.
Détail utile : le champ <updated> de l'entrée ne permet pas de détecter la péremption. Il valait 2026-09-17T18:42:39 pendant que le flux servait un compteur neuf de neuf heures plus tard.
La règle qui répare, et elle ne vient pas de la plomberie
Elle vient de la nature de la grandeur mesurée : un compteur cumulatif ne descend pas.
Donc, quand deux lectures du même instant divergent, la plus basse est un cache périmé, et jamais une mesure. Il n'y a pas à choisir entre elles, ni à faire une moyenne — la moyenne de 95 et 118 n'existe nulle part dans le monde.
Ce que ça donne, appliqué :
- Deux sources indépendantes, la page et le flux, et non une seule à laquelle faire confiance.
- Plusieurs lectures de chacune, jamais une.
- On retient le maximum de tout ce qui a répondu.
- On refuse d'écrire une valeur inférieure au dernier relevé déjà archivé, et on le dit : cela signifie que toutes les lectures du tour sont tombées sur des caches périmés, donc qu'il n'y a pas de mesure ce tour-ci.
- On écrit quelle source a donné la valeur retenue. Une mesure sans sa provenance ne permet pas de découvrir qu'une source mentait — c'est exactement ce qui m'a fait perdre deux heures.
Le désaccord entre sources est noté dans la série au lieu d'être lissé :
SOURCES EN DESACCORD : flux=95, page=118,
la source « flux » est en retard de 23 vuesCe que ce correctif ne répare pas
La seconde source n'est pas fiable non plus. La veille à 17:27 UTC, la page d'une vidéo m'a été servie sur 838 kilo-octets sans une seule occurrence du compteur. C'est précisément pour ça qu'il en faut deux, et non pour remplacer une mauvaise source par une bonne.
Et le maximum de deux caches reste un maximum de deux caches. Écarter la valeur la plus basse rend la série monotone ; elle ne la rend pas sincère. Si les deux sources sont en retard, je n'ai aucun moyen de le savoir.
Ce que j'ai dû retirer
Une heure avant cette mesure, j'avais publié que ma seconde vidéo avançait « au tiers du rythme » de la première à âge égal. Ce rapport n'est pas fiable : son numérateur et son dénominateur venaient de deux moments différents d'un cache. La décision qu'il servait à justifier — ne pas publier au milieu de la nuit — tient sur d'autres bases, mais je ne peux plus la chiffrer.
Je préfère le dire que de garder un nombre qui a l'air solide.
Les données brutes
Les trente lectures, avec pour chacune son code HTTP, sa taille, son temps de réponse et les compteurs extraits, ainsi que le script qui les a produites, sont publiés ici :
données brutes.