La preuve surtout que tu parles bien d’une nouvelle frontière qui reste largement à explorer. Le Web de ses dernières années nous a tellement habitué à utiliser des listes (blogs, RSS, lifestream, status updates, aggregated feeds…) que beaucoup y ont vu l’horizon indispensable de la présentation de données. Ils commettent une erreur excusable mais bien réelle : voir le Web de demain dans celui d’aujourd’hui.

Les listes et les tags sont au fond un moyen très rudimentaire d’organiser, de manipuler et de présenter des données. Ce moyen correspond aux capacités techniques du Web de la décennie 2000, mais certainement pas à ceux de la décennie qui s’ouvre aujourd’hui!

Quand tu dis que “la part de l’échange de don­nées entre machines  dépassera pro­ba­ble­ment assez vite celle des échanges homme-machine” en fait… c’est déjà le cas depuis longtemps :). Et de fait la question cruciale du bénéfice du web des données c’est aussi la partie visible de l’iceberg. La partie invisible étant, certes indispensable, mais a très peu de valeur pour 99,9% des internautes.

Je suis d’accord sur le fait “qu’un paquet de don­nées dont le sens, l’utilisation ou l’interactivité poten­tielle ne seraient por­tés que par l’*aspect du rendu* rédui­rait d’autant son péri­mètre de dif­fu­sion, et donc d’utilisation” et c’est d’ailleurs ce que je pousse dans l’article: l’indépendance entre données et visualisations. Les deux sont séparés, tu as donc à la fois accès aux données brutes et à une, voir plusieurs visualisations (donc pas de détérioration des données originales).

Pour ce qui est de l’accessibilité, c’est un sujet très intéressant qu’il faudrait creuser. Mais dans la mesure où 99.9% des sites web ne valident pas le WCAG, on ne peut espérer qu’une amélioration :)

Pour ce qui est de la structuration des données, je ne pense pas que cela passe par un enrichissement des languages de présentation existants. Il suffit de jeter un oeil à l’utilisation de RDFa ou des microformats, pour se rendre compte que l’échange de données brutes (type RDF) a (avis personnel) plus d’avenir. Et d’ailleurs le choix de HTML5 (vs XHTML2) montre bien la volonté d’accentuer le rôle de l’HTML pour présenter des données (plutôt que de les structurer).

Je prendrai le temps de tout relire à fond mais je trouve que la question cruciale de la *présentation* n’est pas tout à fait posée comme elle doit l’être. Le web ce n’est pas (ou pas fondamentalement) des données *présentées* (à quoi elles ressemblent pour l’utilisateur), mais des données *structurées*. Donc je ne partage pas entièrement ton “c’est la visualisation de ces données qui permettra petit à petit de profiter de toute la richesse que le web a à nous offrir” de conclusion. Ne serait-ce que parce que la part de l’échange de données entre machines — échange totalement invisibles à l’homme dans le cadre de l’internet des objets (RFID, etc) — dépassera probablement assez vite celle des échanges homme-machine.

Ensuite, en théorie un même paquet de données resterait utilisable quel que soit l’user-agent utilisé (écran, vocal, mobile, client3D, etc.) si la façon dont celles-si sont structurées est porteuse de sens. A l’inverse, un paquet de données dont le sens, l’utilisation ou l’interactivité potentielle ne seraient portés que par l’*aspect du rendu* réduirait d’autant son périmètre de diffusion, et donc d’utilisation. En gros, plus des données ont *besoin d’être rendues d’une certaine façon et sous une certaine forme* pour être utilisables, moins elles sont utilisables… C’est à la fois tout l’enjeu pratique et immédiat de l’accessibilité et de l’interopérabilité (le “web universel”) et tout l’enjeu théorique futur du web “3quelquechose” entre internet des objets, internet des données et internet des applis.

Seulement voilà, une des grandes questions reste que l’interaction entre données issues d’outils et de producteurs différents ne sera massivement possible qu’à la condition qu’elles soient produites à partir de langages normés structurants… Or la quasi-totalité du contenu web d’aujourd’hui s’appuie sur un *langage de présentation* à très faible valeur structurante : HTML et sa sémantique rudimentaire. Faut-il d’abord tuer HTML ?