Résumé

  • Le W3C a annoncé le 24 septembre le rapport d’un atelier tenu les 20 et 21 juillet. Celui-ci recommande un groupe de travail consacré à ODRL 3.0, sans annoncer sa création officielle.
  • Le chantier proposé vise la conformité des logiciels qui traitent les politiques : des cas d’usage, des données d’entrée et des résultats attendus permettraient de comparer leurs comportements.
  • Les recommandations ne remplacent pas les deux spécifications ODRL 2.2, publiées comme recommandations du W3C en 2018, et ne constituent pas une certification déjà disponible.

Une autorisation écrite de façon identique peut produire deux réponses différentes si les systèmes ne traitent pas de la même manière une exception, une échéance ou la rencontre d’une permission et d’une interdiction. Pour l’organisation qui échange des droits entre plateformes, le problème n’est donc pas seulement de transporter le document. Il faut savoir ce que le destinataire pourra en conclure, dans quelles conditions, et avec quel degré de comparabilité.

C’est le fil le plus concret du rapport Future of ODRL, rendu public par le W3C le 24 septembre à la suite de l’atelier de Londres et en ligne. Le texte recommande de mieux formaliser la sémantique et de définir la conformité des logiciels qui consomment les politiques. Il cite notamment les moteurs d’application des règles, les systèmes de contrôle, les vérificateurs de conformité et les outils d’importation. La suite de tests envisagée relierait les exigences issues d’usages réels à des entrées et à des sorties attendues. Ce n’est pas une suite de tests que le W3C met déjà à disposition.

La nuance est importante, car ODRL ne part pas de zéro. Le modèle d’information 2.2 et le vocabulaire 2.2 sont des recommandations publiées en février 2018. Ils décrivent parties, actifs, permissions, interdictions, obligations et contraintes; le modèle prévoit aussi des éléments de composition et de résolution des conflits. Affirmer que la version actuelle n’aurait aucune sémantique effacerait ce socle. Le rapport juge plutôt insuffisamment normalisé le comportement des logiciels face à l’ambition nouvelle de faire circuler des politiques entre secteurs.

Un test sérieux devrait rendre explicite le contexte de la décision. Quelle politique et quel profil sont lus ? Quel acteur utilise quel actif, à quel moment ? Quelle règle prévaut si deux dispositions se heurtent ? Que doit produire le logiciel dans ce cas ? Ces questions reprennent l’idée d’entrées et de sorties définies dans le rapport; elles ne décrivent pas un format obligatoire déjà approuvé. Sans cette précision, un produit peut revendiquer la prise en charge d’ODRL parce qu’il en comprend la syntaxe, tandis qu’un autre revendique la même chose pour une évaluation beaucoup plus étendue.

Le rapport explore en conséquence une conformité modulaire, éventuellement à plusieurs niveaux. Un noyau limité pourrait suffire à certains usages simples; d’autres secteurs auraient besoin de contraintes, de profils et de correspondances plus riches. La promesse de compatibilité gagnerait alors à nommer le niveau et la famille de décisions testés. Sinon, une étiquette commune masque des lacunes opérationnelles. Cette conclusion est une lecture éditoriale des recommandations, non une règle déjà imposée par le W3C.

La procédure institutionnelle reste ouverte. Les présidents de l’atelier entendent rédiger une charte de groupe de travail et la présenter lors de TPAC 2026 à Dublin. Le rapport précise qu’il a été principalement préparé par un outil d’IA générative à partir des transcriptions, puis vérifié par les coprésidents. On peut citer ce document comme source publiée; on ne peut pas attribuer chaque formulation à un vote ou à chaque participant. La portée effective d’ODRL 3.0 dépendra de la charte et de futurs textes, pas du seul communiqué.

Sources