Ton ePub est valide. Kobo s’en fiche, c’est Adobe qui décide.

Tu passes des heures à produire un ePub propre. Tu valides avec EPUBCheck, l’outil de référence de l’IDPF : zéro erreur, zéro warning. Tu testes dans Calibre, dans Apple Books — ça tourne nickel. Tu uploades sur Kobo Writing Life. Et là, surprise : la police est écrasée, la mise en page explose, ou pire, le fichier est refusé à l’ingestion sans explication exploitable.

C’est exactement le cas qu’André Klein a documenté dans son article « Your ePub Is Fine » : un ePub techniquement conforme à la spec ePub 3, qui passe tous les validateurs disponibles, mais qui se retrouve massacré ou rejeté sur Kobo. La cause pointée du doigt : Adobe Digital Editions (ADE), le moteur de rendu embarqué par Kobo pour les livres distribués avec DRM. Un moteur qui a ses propres règles, souvent non documentées, et qui s’en fiche totalement de ce que dit le W3C.

Ce qui est particulièrement agaçant, c’est que le problème n’est pas dans ton fichier. L’ePub est valide. La spec est publique et claire. Mais entre la spec et le lecteur final, une couche opaque contrôlée par Adobe décide unilatéralement de ce qui « passe » ou pas. On a déjà vécu ça avec IE6 et les CSS. Vingt ans plus tard, même scénario, autre secteur — et toujours aussi peu drôle.

ePub : une spec ouverte, des implémentations en ordre dispersé

ePub est un format de livre numérique maintenu par le W3C depuis la fusion avec l’IDPF en 2017. Dans les grandes lignes, un fichier ePub 3 est une archive ZIP contenant du HTML5, du CSS, des métadonnées OPF et un manifest. C’est du web encapsulé dans un conteneur normalisé. La spec est publique, lisible, et EPUBCheck permet de valider qu’un fichier la respecte. Jusque-là, rien d’opaque.

Le problème, c’est que « conforme à la spec » ne signifie pas « s’affiche correctement partout ». Chaque lecteur implémente le rendu à sa façon. Apple Books utilise WebKit. Thorium Reader utilise Readium. Kindle convertit l’ePub en son propre format propriétaire avant affichage. Et Kobo, pour les livres avec DRM Adobe, délègue le rendu à ADE. Résultat : un même fichier peut s’afficher parfaitement dans trois lecteurs et s’effondrer dans le quatrième.

Cette fragmentation rappelle furieusement le web des années 2000, où chaque navigateur interprétait le CSS à sa façon et où les développeurs passaient autant de temps à contourner les bugs IE qu’à écrire du code réel. Le web s’en est sorti grâce à la pression des standards et à la concurrence entre moteurs. Le monde du livre numérique, lui, n’a pas encore trouvé sa sortie de secours.

Adobe Digital Editions : le moteur qui vit dans le passé

Adobe Digital Editions est le moteur de DRM et de rendu qu’Adobe fournit aux libraires numériques sous licence. Il gère le chiffrement des fichiers via le standard ADEPT, mais aussi leur affichage. Et c’est là que tout se complique : ADE est vieux, peu maintenu, et basé sur un moteur de rendu HTML/CSS qui date grossièrement de l’époque où Firefox 3 était considéré comme moderne.

ADE ne supporte pas CSS Grid. Son support de Flexbox est partiel et imprévisible. Des propriétés CSS3 parfaitement banales peuvent faire craquer l’affichage. Des features ePub 3 valides — JavaScript embarqué, polices WOFF2, media overlay — sont soit ignorées, soit sources d’erreurs silencieuses. Et le pire : Adobe ne publie pas de profil de conformité officiel pour ADE. Tu découvres les limites en les heurtant, ou en lisant les retours d’expérience de gens qui y ont laissé quelques heures avant toi.

ADE ne lit pas la spec. ADE lit ce qu’Adobe a décidé de lire — et Adobe ne t’a pas demandé ton avis.

Ce qui est documenté, c’est une liste empirique accumulée par la communauté des publishers indépendants sur les forums Kobo Writing Life et les blogs spécialisés. Pas une documentation officielle. Des notes de bas de page rédigées par des gens qui ont souffert. C’est artisanal, et c’est problématique pour un composant qui est au cœur d’une chaîne de distribution représentant des millions d’euros de transactions annuelles.

Kobo coincé dans sa propre chaîne DRM

Kobo n’est pas une petite startup : c’est une marque appartenant à Rakuten, avec des millions de liseuses en circulation. Ils ont clairement les moyens de développer ou d’intégrer un moteur de rendu plus récent — et d’ailleurs, pour les ePubs sans DRM ou via leur programme Kobo Plus, ils utilisent un moteur plus moderne qui supporte mieux ePub 3. Le problème se concentre spécifiquement sur les livres distribués via l’écosystème Adobe ADEPT.

Et là, Kobo est structurellement bloqué. Abandonner Adobe ADEPT impliquerait de renégocier des accords avec des centaines d’éditeurs dont toute la chaîne de distribution repose sur ce standard. C’est un problème de migration à grande échelle, avec des enjeux contractuels qui dépassent largement la question technique. La situation ressemble à ces projets où une application métier sur mesure se retrouve dépendante d’une API tierce non maintenue : tu absorbes la dette technique de quelqu’un d’autre, et personne ne peut débrancher facilement.

Les pièges concrets qui font rager ADE

Voici ce qui revient le plus souvent dans les rapports de la communauté. Ce n’est pas exhaustif — ADE a une capacité infinie à te surprendre — mais c’est ce qui cause 80 % des problèmes signalés :

• Polices WOFF2 : ADE préfère nettement les formats OTF ou TTF embarqués. WOFF2 est le standard web moderne, mais ADE peut les ignorer silencieusement.
• CSS variables : les custom properties (--ma-variable: value) ne sont pas supportées. Elles sont ignorées, ce qui casse toute la cascade qui en dépend.
• IDs en double dans le HTML : EPUBCheck ne les signale pas toujours comme erreur critique, mais ADE peut les traiter comme fatals.
• JavaScript embarqué : ADE le bloque ou l’ignore. Si ta mise en page repose sur du scripting, c’est mort.
• SVG inline : support partiel et imprévisible. Mieux vaut les référencer comme images externes avec une balise <img>.
• Namespaces XML non standards : certains outils d’export (InDesign notamment) génèrent des attributs xmlns qu’ADE digère mal.

Cette liste est empirique parce qu’Adobe ne publie pas de profil de conformité officiel. Tu navigues à vue, et la communauté open source fait le travail de documentation qu’Adobe devrait faire lui-même. Pour quelqu’un qui gère de la vente de livres numériques en ligne, ignorer ces contraintes en amont, c’est garantir des allers-retours douloureux avec les équipes de distribution.

Produire un ePub robuste sans y laisser sa santé mentale

La bonne nouvelle : on peut produire des ePubs qui tiennent sur Kobo sans trop de contorsions — à condition d’adopter une approche défensive dès le départ. L’idée de base : viser la compatibilité ePub 2 pour le CSS, même si ton fichier est déclaré ePub 3. ADE est beaucoup plus à l’aise avec ce sous-ensemble réduit.

Concrètement : CSS simple (font, margin, padding, text-align, line-height — les classiques), polices OTF ou TTF obfusquées selon la spec ePub, structure HTML5 sémantique mais sobre, et zéro JavaScript. Du côté des outils, Sigil reste une référence pour l’édition manuelle avec accès direct au code source. Pandoc génère des ePub 3 propres depuis Markdown. Et EPUBCheck doit absolument faire partie de ton pipeline si tu gères du volume — une erreur de validation silencieuse peut traîner des semaines sans CI.

Qui contrôle vraiment le standard dans la pratique ?

L’article d’André Klein touche à quelque chose de plus profond que les bugs d’ADE. Il pointe une tension fondamentale entre les standards ouverts et les implémentations qui font la loi sur le terrain. La spec ePub est ouverte, maintenue par le W3C, et EPUBCheck est open source. Mais si le moteur de rendu dominant sur la principale plateforme de distribution ne respecte pas ce standard, alors c’est le moteur qui définit le standard réel — pas le W3C.

C’est la même dynamique qu’avec Internet Explorer : la spec du WHATWG était publique, mais pendant des années, c’est la politique de Microsoft qui dictait ce que les développeurs pouvaient ou ne pouvaient pas utiliser dans la pratique. Le web s’en est sorti grâce à Chrome, Firefox et à la mort progressive d’IE. Dans le monde ePub, on attend encore cet équivalent.

Mon pari : ça bougera quand Amazon et Apple — qui ont leurs propres moteurs et n’ont aucun intérêt à maintenir la dépendance à Adobe — pèseront assez fort sur l’écosystème. Amazon a récemment ouvert Kindle à l’ePub natif. Apple Books supporte ePub 3 correctement depuis des années. Kobo suit sur ses propres titres. La pression monte, même si c’est lent. En attendant, tu fais du CSS comme en 2010 pour les livres DRM Adobe, et tu fais semblant que c’est une contrainte normale. Ce n’est pas une contrainte normale.