ITEM 19 · ÉCHEC TRANSPORT
Reformulation sous contrainte de format
LLM-360 v1.0 · calibration v1 · runner v0.1 · 19 septembre 2026, 05:58
Les faits mesurés
- code HTTP
- 504
- temps écoulé
- 301.7 s
- moment de l'échec
- avant le flux
- saut réseau
- passerelle → fournisseur
- streaming reçu
- non
- délai client
- 300 s
- octets reçus
- 0
- facturation
- non confirmée
La trajectoire
- 1
Requête émise
La tâche est envoyée à la passerelle. Horodatage enregistré.
- 2
Attente
Aucun octet reçu. Le flux ne s'ouvre jamais.
- 3
Délai client dépassé
300 secondes atteintes côté harnais.
- 4
Réponse 504
Reçue à 301.7 s. Le corps est vide.
- 5
Classement
echec_transport — compte en voie V4, jamais en voie V1.
Pourquoi ce classement, et pas un autre
Cet item ne dit rien de la qualité du modèle
Zéro octet a été reçu. Le modèle n'a peut-être même jamais été sollicité : l'échec s'est produit avant l'ouverture du flux, sur le saut réseau entre la passerelle et le fournisseur.
Le compter comme une mauvaise réponse serait une calomnie statistique. Le retirer de l'échantillon serait un mensonge par omission : un utilisateur réel aurait attendu 301 secondes pour rien.
Il compte donc dans la voie V4 — Fiabilité technique, et nulle part ailleurs. La voie V1 — Justesse l'ignore entièrement.
Reproduire cet item
Les trois versions sont affichées en haut de cette page. Avec elles, le même item peut être rejoué à l'identique — par nous, ou par vous.
Contester ce résultat
Un client peut demander une réexécution contradictoire, à la même version de protocole, de suite et de harnais, et y assister. Les deux résultats sont alors publiés côte à côte.