Résumé

  • RFC 9649 décrit un conteneur WebP interopérable, mais la validité du fichier ne certifie ni la vérité des métadonnées, ni la conservation de la provenance, ni le spectacle réellement vu.
  • Les blocs inconnus doivent être ignorés par les lecteurs et préservés par les auteurs lorsqu’ils ne veulent pas les modifier : ne pas comprendre, conserver et approuver sont trois actes distincts.
  • Une preuve exploitable relie l’objet reçu, l’inventaire ordonné des blocs, la version et les limites du décodeur, les pixels et images décodés, la dérivée produite et le rendu final.

Le temps du fichier n’est pas toujours le temps de l’écran

RFC 9649 stabilise la description publique de WebP et son enregistrement comme image/webp. Le format RIFF peut transporter une image VP8 avec pertes, un flux sans pertes, de la transparence, un profil colorimétrique, une animation, des données EXIF ou XMP et des blocs propres à une application. Cette frontière commune est précieuse : un producteur et un lecteur indépendants peuvent s’accorder sur la manière de retrouver un canevas.

Mais l’animation révèle immédiatement la limite de cet accord. Une trame porte une position, des dimensions, une durée, un mode de fusion et une règle d’effacement. La durée est exprimée en millisecondes ; pourtant, une valeur nulle, et souvent une valeur inférieure ou égale à dix millisecondes, reste soumise à l’interprétation de l’implémentation. De nombreux lecteurs imposent un minimum. La couleur d’arrière-plan est elle aussi un indice plutôt qu’un ordre universel.

Le fichier fournit donc une instruction temporelle, pas une observation complète. Pour affirmer ce qu’une personne a vu, il faut connaître le logiciel, sa version, sa normalisation des durées, sa gestion des couleurs, le fond de composition, les conditions de lecture et, si l’enjeu le justifie, une capture du résultat. Dire seulement « l’animation est conforme » efface la décision prise par le lecteur.

L’ordre obligatoire ne couvre pas toute la garde

Le format étendu sépare deux régimes. Les blocs nécessaires à la reconstruction et à la correction colorimétrique suivent un ordre défini. Selon le contenu, on rencontrera notamment VP8X, ICCP, ANIM, ANMF, ALPH, VP8 ou VP8L. Un lecteur doit échouer si les éléments indispensables à la reconstruction sont mal ordonnés.

Les métadonnées et les blocs inconnus ne suivent pas exactement cette route. EXIF, XMP et les extensions applicatives peuvent être placés hors de l’ordre de reconstruction. Un bloc inconnu peut apparaître en fin de fichier ou dans la charge d’une trame animée. Le lecteur doit pouvoir l’ignorer ; l’auteur doit le préserver dans son ordre d’origine sauf intention explicite de le modifier.

Cette dissymétrie protège l’extension future. Un logiciel ancien peut afficher un fichier plus récent sans prétendre comprendre ce qu’il ne connaît pas. Un outil d’édition peut modifier les pixels sans détruire par accident une information réservée à une autre application. Elle crée aussi une obligation de preuve. Ignorer ne veut pas dire déclarer sans danger. Préserver ne veut pas dire valider. Supprimer ne veut pas dire neutraliser sans conséquence.

Un service de transformation devrait donc enregistrer trois choix : les blocs qu’il interprète, ceux qu’il transporte sans les interpréter et ceux qu’il supprime ou réécrit. Le hachage du fichier final identifie le résultat ; il ne raconte pas ces choix.

Une métadonnée est une assertion, pas un témoin assermenté

WebP peut embarquer EXIF et XMP. RFC 9649 indique qu’il ne devrait exister qu’un bloc de chaque type. Si plusieurs blocs apparaissent, un lecteur peut ignorer tous ceux qui suivent le premier. Cette règle apparemment modeste suffit à produire des histoires différentes : un outil retient le premier bloc, un second reconstruit un bloc canonique, un troisième retire toute métadonnée. Chacun peut rendre la même photographie.

La spécification Exif de la CIPA définit une structure ; les spécifications XMP d’Adobe fournissent un modèle extensible et des modes d’incorporation. Aucune structure ne transforme mécaniquement un nom d’auteur, une date, un lieu, un appareil ou une chaîne de droits en fait authentifié. La source de l’assertion, sa signature éventuelle et la continuité de sa garde demeurent des questions externes.

Les couches de réalité de Lu Heng donnent ici une méthode. Les octets stockés, les champs analysés, la provenance déclarée, les pixels décodés et la conviction du lecteur sont voisins, mais non interchangeables. Une information exacte peut disparaître lors d’une conversion qui préserve l’apparence. Une information fausse peut survivre à toutes les copies. La présence n’est pas la vérité ; l’absence après traitement n’est pas la preuve que rien n’existait.

La transparence ne supprime pas la couleur

Le flux sans pertes restitue des valeurs ARGB, y compris la couleur d’un pixel dont l’alpha vaut zéro. Ce pixel ne contribue normalement pas à l’image composée, mais ses composantes rouge, verte et bleue existent toujours.

Il ne faut pas en déduire qu’un fichier précis contient un message caché. Il faut en déduire qu’« invisible » et « absent » sont deux propriétés différentes. Une opération ultérieure peut retirer l’alpha, poser l’image sur un fond inattendu, consulter les canaux colorés ou les transcoder autrement. Un contrôle de confidentialité limité à la vignette affichée peut manquer ce qu’un examen des octets ou des pixels décodés découvrirait.

Inversement, un optimiseur peut normaliser les couleurs sous les pixels transparents sans changer l’apparence. L’image reste visuellement identique, mais la matrice décodée n’est plus la même. Le mot « sans pertes » qualifie la reconstruction du codec spécifié ; il ne garantit pas que chaque intermédiaire conserve le conteneur original, ses métadonnées et ses extensions.

Un fichier valide peut rester dangereux à traiter

La section de sécurité de RFC 9649 énumère des risques concrets : dépassement d’entier, lectures ou écritures hors limites, données non initialisées, pointeurs nuls, épuisement de mémoire ou de disque et calcul prolongé. Les fichiers atteignent des navigateurs, des messageries et des serveurs de dépôt. Une erreur peut devenir exécution de code, fuite d’information, arrêt du processus ou déni de service.

WebP ne possède pas de mécanisme de contenu actif. Son traitement n’est pas pour autant passif. Les dimensions du canevas commandent l’allocation. Les trames multiplient l’état et le travail. Les codes préfixes, transformations et flux compressés pilotent un analyseur complexe. EXIF, XMP et les blocs spécifiques peuvent déclencher d’autres interpréteurs.

Il faut donc un reçu de sécurité séparé de l’acceptation syntaxique : bibliothèque et version, isolation du processus, plafonds de mémoire et de temps, dimensions et nombre de trames admis, interpréteurs de métadonnées appelés, erreur obtenue et dérivée éventuellement générée. Une organisation peut refuser un fichier conforme au nom de sa politique de ressources. Un lecteur tolérant peut afficher une partie d’un fichier incorrect. Aucun de ces comportements ne doit devenir silencieusement un verdict universel.

Composer un reçu octet–bloc–rendu

La première étape est la garde. Il faut hacher exactement l’objet reçu, noter sa taille, le type annoncé par le transport, le nom revendiqué et toute détection indépendante. Ensuite, parcourir les bornes RIFF sans déclarer encore l’objet sûr, puis relever pour chaque bloc le FourCC, le décalage, la taille annoncée, le bourrage et la position.

Chaque bloc reçoit une classe : nécessaire à la reconstruction, métadonnée reconnue, donnée applicative reconnue ou élément inconnu. L’opération indique ensuite si elle l’a compris, ignoré, préservé, supprimé, déplacé ou réécrit. En cas de doublon EXIF ou XMP, elle nomme la valeur retenue. Pour VP8X, elle conserve les dimensions et indicateurs ; pour l’animation, les rectangles, durées, modes de fusion et d’effacement.

Le décodeur s’exécute dans un environnement borné. Son identité, sa version et ses limites rejoignent le dossier. Selon le besoin, on hache les pixels ou chacune des trames. On note la gestion ICC, l’alpha, l’arrière-plan et la normalisation temporelle. Toute dérivée reçoit son propre hachage et un nouvel inventaire des blocs. L’expression « même image » ne remplace jamais cette comparaison.

Enfin, on observe la livraison : objet réellement récupéré, lecteur exécuté, trames jouées et résultat capturé. La primauté du code exécuté apporte la discipline finale. La grammaire enregistrée délimite les possibilités ; le programme exécuté et la sortie observée disent ce qui s’est effectivement produit.

Une petite norme, des décisions locales visibles

RFC 9649 n’a pas besoin de devenir une constitution de la provenance. Sa force est de borner les octets et la reconstruction communs. Le principe de spécification initiale minimale recommande précisément de normaliser l’interopérabilité nécessaire, puis de laisser les choix futurs et locaux nommés et révisables.

Une organisation peut retirer les métadonnées destinées au public. Une autre peut garder tous les blocs inconnus dans ses archives. Une troisième peut refuser les animations, imposer un canevas plus petit ou exiger un manifeste signé à côté du fichier. Ces politiques sont légitimes si leur version, leur auteur et leur effet sont observables. Elles deviennent un déplacement de pouvoir lorsqu’un simple libellé « optimisé » ou « nettoyé » cache la disparition d’une preuve.

La phrase de gouvernance doit rester étroite. RFC 9649 peut établir qu’une séquence d’octets respecte une grammaire WebP partagée. Elle ne peut établir qui a formulé les assertions embarquées, quelle donnée encore incomprise compte, si le décodeur a travaillé sans risque, si une transformation a préservé la garde ni ce qu’une personne a finalement vu. Ces conclusions appartiennent aux systèmes qui les prennent et aux reçus qu’ils savent produire.

Sources