Juger globalement d'un format comme ePub est un exercice délicat. Les problématiques qu'il soulève sont de tout ordre: stratégique, éditorial, financier, technologique, technique. Et il y a d'un coté l'approche théorique, de l'autre l'expérience et l'usage, quelquefois à l'opposé.ePub est théoriquement idéal. Il est ouvert, indépendant, conciliant le PDF, l'XML et l'HTML, avec l'ambition de gérer les feuilles de style évoluées et de garantir l'essentiel de ce que le livre électronique demande: interopérabilité, recomposition à la volée, gestion des collections, des auteurs, des contributeurs, attributs de l'ouvrage. Associé à Flash, à des logiciels de consultation évolués, à des plates-formes innovantes telle WebKit, il peut offrir des possibilités de création et d'interactivité sans limite.
La réalité est un peu différente.
Les implémentations d'ePub, ses spécifications, ou ses compléments souvent indispensables sont propriétaires (Flash, DRM, pour ne citer que les principaux), comme le sont certains composants concurrents des architectures d'Apple, par exemple. ePub est également supposé assurer l'interopérabilité. Mais ceux qui pratiquent XML, langage supposé commun, savent bien qu'il y a autant de versions de documents que de "tags" inventés par les éditeurs, et que les moteurs de rendu doivent les prendre en compte au risque de ne rien afficher ou imprimer correctement. La protection des œuvres est complexe, car elle passe par le PC, les éditeurs préfèrent ne pas en utiliser ou bien passer par un système de cryptage qu'ils contrôlent.
Si ePub peut prétendre assurer une continuité éditoriale avec le passé, les compositions qu'il permet sur PC comme sur iPhone ou tablettes sont limitées à la fois pour le texte et les tableaux, mais plus encore pour les systèmes qui ne disposent pas de Flash. Concernant les productions interactives, rich média et innovantes, les auteurs et éditeurs sur iPhone, e-paper et Nintendo DS n'ont pas attendu pour développer leurs propres formats. Cela a toujours été le cas dans l'histoire des médias: la rupture est nécessaire quand l'expérience utilisateur (développeur, composeur, diffuseur, lecteur) est en jeu.
ePub profite peu, pour l'instant, des avancées technologiques majeures (chargement progressif pour les telecom, animation et interaction sans Flash). Il n'est pas prévu qu'il en supporte d'autres, comme la communication de contenus isolés de dispositifs à dispositifs, ou l'écriture. Le mariage que permettrait ePub entre PDF et HTML n'est-il pas en voie d'être réglé, et mieux encore, par les plates-formes innovantes et ouvertes qui utilisent un moteur de rendu complet de type WebKit, Gecko, etc? Ce qui signifierait que l'HTML de dernière version serait lu correctement; que les feuilles de style CSS seraient proprement interprétées; y compris les légères animations permises par le dernier standard CSS3 ou la gestion de fontes typographiques issues de la page (ou du livre) et non pas du reader; et surtout que chaque document s'afficherait de la même façon d'un appareil à l'autre, car ces moteurs-là ne cessent de concourir à être le plus standard possible et le plus proche des recommandations de la W3C.
L'usage d'ePub est restreint sur les petits dispositifs comme les tablettes à base d'encre électronique, car les processeurs, les drivers, les managers ne sont pas prévus pour de telles prouesses (recomposition à la volée, donc césure, gestion des tables, des insécables, etc). Un simple livre format poche est aujourd'hui mieux composé et plus commode sur papier classique! Certains dispositifs vont intégrer des processeurs lents, pour être flexibles et économes, leurs ressources seront encore plus limitées.
Déjà, le format PDF de base n'est géré correctement que par très peu de plates-formes légères, il manque souvent l'essentiel comme les signets et il faut plusieurs secondes sur certaines pour ouvrir une seule page d'un document volumineux (quand on peut l'ouvrir). Les readers ePub sur iPhone imposent de diviser les documents pour que les opérations de chargement et de transformation soient supportables, et encore.
Alors, le risque à vouloir promouvoir uniquement ePub et même PDF sur les dispositifs à base d'encre électronique serait que le support lui-même soit déprécié par la mauvaise expérience lecteur alors qu'il permet des avancées considérables pour le livre et la presse.
Alors, ePub or not ePub?
Mais est-ce une question? A l'instar de RTF, ePub pourrait co exister avec les plus récents formats interactifs. Ou servir dans des étapes intermédiaires de production ou de diffusion. Si ePub n'est pas le "standard" d'un bout à l'autre de la chaîne, il peut être nécessaire pour certains documents, sur certaines plates-formes, à des niveaux spécifiques de la chaîne de production, et pour certains acteurs du marché.
La question ne se joue-t-elle pas entre des formats bien plus légers qui assurent un rendu impeccable sur des plates-formes légères, et un format HTML, CSS, javascript, etc. complet pour des tablettes avec un moteur de rendu -lui aussi- complet de type WebKit, Gecko... etc.? ePub pourrait être l'un d'entre eux, décrivant un site web à télécharger et à lire comme un livre sous forme de package. Il intégrerait les feuilles de style CSS3, les polices de caractères, les scripts, etc. Il serait lisible par un navigateur web utilisant un moteur propre comme le WebKit, Gecko.
Les expérimentations et les déploiements ne peuvent attendre, et au contraire de la musique, la diversité du livre et des plates-formes est telle qu'on ne peut imaginer qu'un seul standard puisse satisfaire tous les projets. Les créateurs de programmes et de contenus ont besoin de formats qui répondent aux attentes des lecteurs, des éditeurs, des diffuseurs, et qui soient en phase avec les possibilités technologiques. Faute d'en trouver aujourd'hui, ils en créent ou en adaptent. ePub sera sans doute l'un des futurs standards, mais quelle place aura-t-il parmi ceux qui ne manqueront pas d'émerger? La compétition s'annonce serrée, le débat est ouvert.
