Résumé

  • Dans qlog, event_schemas fournit des indications aux outils ; la liste ne garantit pas que chaque type d'événement associé a été enregistré.
  • Un événement absent peut avoir été omis, remplacé, écrasé ou jamais capturé. Son absence n'est donc pas une preuve négative sans politique de collecte.
  • Une décision fiable doit joindre à la trace le profil de capture, la provenance temporelle, les pertes connues et une mesure indépendante du résultat.

Le contrôle interne avait posé une question apparemment simple : le serveur avait-il rejeté un paquet avant la fermeture de la connexion ? La trace déclarait le schéma QUIC dans event_schemas. Elle ne contenait aucun événement de rejet. Le rapport a donc conclu : aucun rejet n'a eu lieu.

La première phrase décrivait correctement le fichier. La seconde n'était pas contenue dans la preuve.

draft-ietf-quic-qlog-main-schema-14, daté du 6 juillet 2026, est un Internet-Draft actif du groupe QUIC, destiné à devenir une norme proposée. Il n'est pas encore un RFC. Il définit les briques communes de qlog : formats de fichiers, traces, événements, horodatages, points d'observation et mécanismes d'extension. Sa vocation est importante : permettre à des outils génériques de lire les journaux d'implémentations différentes, notamment quand le chiffrement rend l'observation externe insuffisante.

Mais le texte qualifie lui-même event_schemas d'indication. Une trace peut contenir un type provenant d'un schéma non annoncé. À l'inverse, tous les types appartenant à un schéma annoncé ne sont pas garantis dans la trace. L'outil ne doit considérer aucune de ces situations comme une erreur.

Cette règle protège l'extensibilité. Elle interdit aussi une pratique d'audit très répandue : transformer une liste de vocabulaires en bordereau de pièces.

Ce que l'URI permet réellement d'affirmer

Une URI de schéma permet d'associer un nom tel que quic:packet_sent à une définition stable de structure et de sens. Elle aide un analyseur à savoir quels champs chercher, quels types accepter et quelles extensions reconnaître. Elle réduit les collisions de noms et rend les traces échangeables.

Elle ne dit pas que le capteur était actif au moment voulu. Elle ne dit pas que le tampon n'a jamais débordé. Elle ne dit pas qu'un filtre de confidentialité a conservé la catégorie d'événement recherchée. Elle ne dit pas qu'une implémentation a choisi le même niveau de détail qu'une autre.

Les niveaux d'importance Core, Base et Extra ne constituent pas davantage une nomenclature d'exhaustivité. Les événements Core devraient être présents de façon générale, mais les outils ne devraient pas s'attendre à les trouver tous dans chaque trace. Pour limiter le coût ou protéger la vie privée, une implémentation peut préférer certains événements Base à un événement Core plus riche. Deux fichiers conformes peuvent donc raconter la même connexion avec des grains différents.

L'absence possède alors plusieurs causes possibles. L'événement n'a peut-être jamais eu lieu. Il a peut-être eu lieu avant le démarrage de la capture. Il a pu être écrasé dans un tampon circulaire, supprimé par la politique de taille, écarté pour confidentialité, remplacé par un événement moins détaillé ou perdu dans une étape d'export. Sans métadonnée sur ces mécanismes, la trace ne permet pas de choisir.

L'erreur explicite ne couvre pas les silences

qlog prévoit un objet TraceError. Lorsqu'une agrégation tente de retrouver ou convertir un fichier et échoue, elle peut inscrire l'erreur au lieu d'abandonner silencieusement l'entrée. C'est une bonne pièce de provenance : elle nomme une tentative et son échec.

Ce n'est pas une déclaration selon laquelle toutes les autres pièces attendues ont réussi. TraceError ne connaît pas les sources que l'opérateur n'a jamais inventoriées. Il ne signale pas automatiquement les événements écrasés à l'intérieur d'une trace valide. Il ne crée pas de marqueur à la place de chaque champ volontairement omis. L'absence de TraceError ne vaut donc pas certificat de dossier complet.

Une organisation qui souhaite utiliser qlog comme preuve doit ajouter son propre manifeste : sources attendues, fenêtres de collecte, résultats d'export, compteurs avant et après transformation, politique d'échantillonnage et état des tampons. Ce manifeste est une mesure d'exploitation proposée ici ; il ne faut pas l'attribuer au projet de norme.

Le temps n'efface pas l'incertitude

Une trace bien ordonnée peut renforcer à tort l'impression de totalité. Chaque événement porte un nombre, mais ce nombre peut être relatif à une époque ou à l'événement précédent. L'horloge peut être système—et donc sauter—ou monotone, auquel cas l'époque calendaire est inconnue. Une heure murale facultative donne une approximation du début, sans garantir une conversion sûre en date civile.

Le projet précise aussi que deux événements d'une même trace ne sont pas obligés d'utiliser le même format temporel. Les événements devraient apparaître par ordre croissant, mais les producteurs multithreads ou en continu peuvent nécessiter un post-traitement. Les outils ne doivent pas supposer que des horodatages issus de traces différentes sont cohérents, même lorsque le même terminal les a produites.

Le tri n'est donc pas une causalité. Une trace côté client, une autre côté serveur et une capture réseau peuvent chacune être localement exacte sans former une chronologie globale. Il faut connaître le point d'observation, le sens du flux, l'identité de la connexion, les fenêtres de capture et l'incertitude de chaque horloge. Sinon, l'ordre graphique est une commodité visuelle, pas un résultat d'enquête.

Les champs manquants doivent rester visibles comme inconnues

qlog accepte qu'un champ trigger précise le déclencheur d'un événement, lorsque la définition concrète le prévoit. Cette information est précieuse dans des systèmes parallèles, où les messages liés peuvent être éloignés dans le journal. Sans ce champ, la proximité ne suffit pas à établir la cause.

Le même principe vaut pour les données brutes. RawInfo peut conserver une longueur complète tout en supprimant ou tronquant les octets. La taille reste alors exploitable pour étudier l'encapsulation ; le contenu demeure inconnu. Déduire une requête, une autorisation ou une erreur applicative de la longueur seule reviendrait à réintroduire ce que la minimisation a précisément retiré.

Le tableau de bord doit donc représenter au moins quatre états distincts : événement observé ; événement attendu par une politique et explicitement non observé ; événement hors fenêtre ou perdu ; événement dont la politique de collecte est inconnue. Les réunir sous « absent » simplifie l'interface au prix du sens.

Passer d'un journal compatible à une preuve bornée

Avant d'autoriser une conclusion, le dossier d'exploitation devrait répondre à cinq questions. Quelle était la question posée avant la capture ? Quels événements et champs le profil devait-il conserver ? Quelles pertes la chaîne de traitement peut-elle mesurer ? Quel niveau d'incertitude temporelle et d'identité demeure ? Quelle observation indépendante confirme l'effet sur l'application ou le service ?

La réponse peut être modeste : « aucun rejet n'apparaît dans la fenêtre conservée, avec ce profil, et aucun compteur de perte connu n'a augmenté ». C'est moins spectaculaire que « aucun rejet », mais c'est falsifiable. Un autre enquêteur sait exactement quelle nouvelle preuve pourrait changer la conclusion.

La discipline rejoint un principe plus large : une spécification minimale commune donne aux implémentations un espace de décision local. qlog rend les traces lisibles sans imposer une capture universelle. La diversité qui en résulte n'est pas une licence pour les vendeurs d'inventer des faits. Elle oblige leurs outils à exposer la politique qui sépare l'événement possible de l'événement effectivement conservé.

Sources