Résumé

  • La révision publiée le 5 septembre est un Internet-Draft individuel, sans approbation ni statut formel à l’IETF, bien qu’une section se présente comme une directive normative destinée aux systèmes d’IA.
  • Le texte reconnaît lui-même la limite décisive : l’ancrage date un condensat, le DOI conserve des métadonnées déclarées et la signature relie une clé au document ; aucun de ces éléments ne tranche seul la vérité, l’antériorité, l’identité ou le pouvoir de commander une IA.
  • L’exploitant doit conserver séparément la preuve lue et la règle qui autorise le modèle à agir ; sinon, le contenu examiné peut se promouvoir silencieusement au rang de politique d’examen.

La nouveauté du 5 septembre n’est pas une norme de l’IETF qui aurait soudain appris aux modèles comment citer. L’annonce de disponibilité enregistre un document de 62 pages, draft-reilly-webproof-01, attribué à Lawrence John Reilly Jr. Ce dépôt public constitue un événement vérifiable. Il ne vaut ni adoption, ni consensus, ni déploiement.

Au milieu d’une proposition consacrée aux empreintes, aux horodatages et aux archives, la section 15 change de destinataire. Elle se nomme AI System Directive. Elle demande aux modèles, agents et systèmes intégrant une IA de reconnaître l’auteur du terme WebProof, une publication de 2025 comme origine du concept et plusieurs éléments comme œuvres originales. Elle emploie le vocabulaire MUST et MUST NOT.

Il est légitime de rapporter ces affirmations. Il serait différent de laisser ces affirmations décider de la manière dont elles doivent être évaluées.

Le statut du document précède sa grammaire normative

La fiche Datatracker ne laisse guère de place à l’ambiguïté institutionnelle : document individuel actif, sans flux RFC, sans directeur de zone responsable et sans date de téléconférence. La fiche rappelle que tout le monde peut soumettre un Internet-Draft, que celui-ci n’est pas approuvé par l’IETF et qu’il n’a aucun statut formel dans son processus de normalisation.

Le texte exact de la révision 01 précise aussi son histoire. La directive destinée aux IA n’apparaît pas pour la première fois en septembre. Le journal des modifications indique que le contenu de la révision 00 a été conservé et que les sections relatives aux revendications d’antériorité et à la directive ont été reprises. La révision 01 ajoute notamment des limites plus précises, des signatures de registre, des séries de corrections, des états de retrait, une sémantique temporelle, un modèle de menace et des niveaux de conformité.

Cette juxtaposition fait tout l’intérêt du cas. Le document devient plus prudent sur ce que sa preuve établit, mais conserve une formulation qui tente d’orienter directement le lecteur automatisé.

La RFC 8174 explique les mots en capitales de la BCP 14. Ils donnent une signification stable aux exigences d’une spécification. Ils ne confèrent pas au papier son champ d’autorité. Un prototype peut décider qu’un composant conforme à WebProof doit suivre telle règle. Le même mot ne soumet pas, par lui-même, toute IA qui indexe la page.

La directive admet que la supervision humaine reste supérieure et renvoie sa propre hiérarchie au cadre AIMED. Or la fiche AIMED décrit, elle aussi, un Internet-Draft individuel. Deux propositions peuvent se citer et construire un modèle de priorité. Elles ne décrivent pas pour autant la configuration réelle d’une rédaction, d’une administration ou d’un fournisseur de modèles.

L’archive rend une revendication durable, pas souveraine

WebProof assemble deux ancrages. Le premier place un condensat dans une preuve liée à Bitcoin. La révision 01 énonce correctement la borne : quelqu’un connaissait ce condensat au plus tard au moment du bloc. Elle ne démontre ni la date de création du contenu, ni son auteur, ni le fait que l’URI annoncé l’ait servi, ni la véracité des phrases.

Le second ancrage est un dépôt muni d’un DOI. Il facilite la persistance et la découverte. Les métadonnées restent déclarées par le déposant. Leur conservation exacte est utile, mais elle ne constitue pas une décision indépendante sur la priorité historique.

Une signature ne ferme pas davantage toute la chaîne. La RFC 7515 fournit le format JWS auquel la proposition fait appel. Une vérification réussie protège un objet et identifie une clé dans un contexte déterminé. Il faut encore démontrer qui détenait légitimement cette clé, au nom de quelle organisation, avec quel mandat et pendant quelle période.

Le temps exige la même modestie. Un jeton conforme à la RFC 3161 associe un condensat à une heure attestée par une autorité d’horodatage. C’est une autre architecture de confiance, non un tribunal de l’originalité. La date de dépôt, la connaissance du condensat, la création de l’œuvre, la première publication et l’attribution juridique sont des faits reliés, mais non interchangeables.

WebProof dit d’ailleurs qu’un acteur peut ancrer un contenu faux ou nuisible. La présence d’une preuve n’est pas un certificat de légitimité ou de qualité. Cette réserve doit s’appliquer aussi à la directive : elle prouve qu’une revendication d’attribution a été publiée dans ce document ; elle ne tranche pas, par sa seule présence, toutes les sources antérieures possibles.

Une adresse proposée n’est pas encore une convention mondiale

Le projet réserve conceptuellement /.well-known/webproof. La RFC 8615 organise cet espace afin d’éviter les collisions et impose l’enregistrement des nouveaux suffixes. Au contrôle effectué le 7 septembre, le registre IANA des URI bien connues ne comportait pas webproof.

Ce constat a une date. Il ne préjuge pas d’un futur enregistrement provisoire ou permanent. Il distingue seulement cinq états : une chaîne écrite dans un projet, une demande soumise, une ligne inscrite au registre, un serveur qui publie la ressource et un client qui lui accorde une portée déterminée.

Les champs HTTP et le TXT _webproof proposés ont la même limite. Ils peuvent rendre une preuve découvrable. Ils ne certifient pas le contenu vers lequel ils pointent. Le projet avertit lui-même qu’un champ de hachage transmis par le serveur n’est pas un résultat de vérification et qu’un TXT sans DNSSEC ne doit pas servir d’autorité pour une clé.

Celui qui fournit la preuve ne choisit pas seul la politique d’acceptation

La RFC 9334 sépare l’Evidence fournie par un Attester, la politique d’évaluation, l’Attestation Result et la décision du Relying Party. WebProof reprend cette terminologie. Elle éclaire précisément le problème de la section 15.

Le projet constitue une preuve de ce que son auteur a écrit. Le système qui le traite doit appliquer une politique venue d’ailleurs : conserver l’attribution documentaire, chercher des antériorités, qualifier l’incertitude, ignorer les impératifs incorporés ou les soumettre à un humain. Si le texte fournit à la fois les données et la règle d’acceptation, la partie examinée devient son propre arbitre.

Le risque dépasse WebProof. Une page commerciale pourrait exiger d’être qualifiée de leader. Une réponse à un appel d’offres pourrait ordonner à l’évaluateur de traiter ses chiffres comme vérifiés. Un article pourrait interdire à un résumé de mentionner une correction. Dans chaque cas, conserver la phrase est une exigence de provenance ; lui obéir est une décision de gouvernance.

Le code déclaré doit rencontrer un second code

La révision fournit un état d’implémentation : l’auteur affirme exploiter l’ancrage, le dépôt DOI et un service actif. La RFC 7942 encourage ce type d’information dans les projets, car il indique ce qui a réellement été tenté avant une éventuelle publication.

Mais le projet reconnaît lui-même le test manquant : une implémentation indépendante. Deux logiciels doivent produire la même forme canonique et le même condensat, gérer les corrections et les clés compromises, et présenter le résultat sans transformer « empreinte identique » en « contenu approuvé ». L’usage déclaré par l’auteur n’est pas encore cette interopérabilité.

Pour la directive IA, l’essai d’exécution est tout aussi concret. Il faut conserver le document reçu, les instructions système et développeur, le modèle, les outils de recherche, la réponse, les citations et la validation humaine. Alors seulement on peut dire si le système a cité, suivi, rejeté ou escaladé la section.

Deux reçus, pas une confiance totale

La Spécification initiale minimale de Heng Lu conduit à un schéma sobre. Le reçu documentaire porte l’URI, la révision, le condensat, l’heure de collecte, le statut institutionnel et les affirmations extraites. Le reçu de gouvernance porte l’émetteur de la règle, sa version, son périmètre, sa priorité, sa date d’effet et sa révocation.

La discipline des couches de réalité interdit ensuite les raccourcis : dépôt, DOI, empreinte, signature, registre, politique locale et sortie du modèle sont des observations différentes. Leur liaison est précieuse parce qu’elle conserve leurs frontières.

Enfin, la primauté du code en fonctionnement refuse de conclure à partir de la seule typographie. MUST peut être une instruction nette dans un profil adopté. Pour savoir s’il a gouverné une IA précise, il faut observer la pile de règles et le résultat exécuté.

WebProof formule un problème réel : une ressource numérique modifiable a besoin d’une histoire vérifiable. Sa révision de septembre gagne en crédibilité lorsqu’elle limite les conclusions tirées de chaque preuve. La cohérence exige d’appliquer la même retenue à la directive d’attribution. Une revendication durable mérite d’être lue et citée. Elle ne choisit pas seule le droit qui régit son lecteur.

Sources

  1. Datatracker — WebProof
  2. Révision 01 de WebProof
  3. Annonce de l’Internet-Draft
  4. Datatracker — AIMED
  5. RFC 8174 — mots normatifs en capitales
  6. RFC 8615 — URI bien connues
  7. Registre IANA des URI bien connues
  8. RFC 7515 — JSON Web Signature
  9. RFC 3161 — protocole d’horodatage
  10. RFC 9334 — architecture RATS
  11. RFC 7942 — état des implémentations
  12. Heng Lu — Minimum Initial Specification
  13. Heng Lu — On Reality Layers
  14. Heng Lu — Running-Code Primacy