Un livre peut avoir une date d'achèvement éditorial, une date de création du fichier, une date de publication de l'EPUB, une date de mise en vente et une date de dernière modification. Ces dates peuvent être proches, mais elles ne décrivent pas le même événement.

Les confondre conduit à des écarts difficiles à interpréter : l'EPUB indique septembre, la fiche commerciale annonce novembre, et le fichier a été corrigé en octobre. La bonne réponse n'est pas toujours de rendre les trois valeurs identiques.

En bref

Dans EPUB 3, dc:date sert à exprimer la date de publication de l'EPUB. dcterms:modified indique quand cette version du paquet a été modifiée pour la dernière fois. La date de mise en vente d'une plateforme peut être gérée dans les métadonnées commerciales et ne doit pas être copiée automatiquement dans l'un ou l'autre champ.

dc:date : la date de publication de l'EPUB

La spécification EPUB 3 réserve l'élément dc:date à la date de publication de la publication EPUB. Elle recommande une valeur conforme à ISO 8601 et n'autorise pas plusieurs éléments dc:date.

Exemple simple :

<dc:date>2026-11-20</dc:date>

Exemple avec une heure UTC :

<dc:date>2026-11-20T00:00:00Z</dc:date>

N'utilisez pas ce champ pour conserver toutes les étapes du projet. Une date de création du manuscrit, une réimpression ou une correction intermédiaire ont d'autres rôles et, si elles doivent être conservées, peuvent utiliser des propriétés spécialisées.

dcterms:modified : la version technique du paquet

EPUB 3 utilise dcterms:modified dans l'identifiant de version. La valeur représente la dernière modification de cette version de l'EPUB et suit une forme précise en UTC :

<meta property="dcterms:modified">2026-10-28T14:35:00Z</meta>

Cette valeur doit changer lorsque vous produisez une nouvelle version du paquet. Elle ne représente pas nécessairement une nouvelle parution commerciale.

Deux fichiers peuvent donc avoir le même identifiant de publication et des dates dcterms:modified différentes : ils représentent des versions successives de la même publication EPUB.

La date de mise en vente appartient au circuit commercial

La date à laquelle un livre devient achetable est souvent gérée par le distributeur, dans ONIX ou dans l'interface de la plateforme. Elle peut différer de la date inscrite dans l'EPUB :

  • le fichier est finalisé avant l'ouverture des ventes ;
  • une précommande est créée ;
  • un canal publie plus tard qu'un autre ;
  • une nouvelle version technique remplace le fichier sans changer la date de parution.

Une différence n'est donc pas automatiquement une erreur. Elle demande de comprendre ce que chaque champ est censé exprimer.

Formats à utiliser

Pour une date calendaire, utilisez :

  • 2026 si seule l'année est connue et si le contexte l'autorise ;
  • 2026-11 pour une précision au mois ;
  • 2026-11-20 pour une date complète ;
  • 2026-11-20T14:30:00Z pour un instant en UTC.

Pour dcterms:modified, utilisez la forme complète avec heure, secondes et Z.

Évitez :

  • 20/11/2026, ambigu pour une machine ;
  • Novembre 2026, non structuré ;
  • 2026-13-40, formellement impossible ;
  • une heure locale sans fuseau ;
  • une ancienne date recopiée après une correction du fichier.

Interpréter les résultats Prism

Format de date invalide

Corrigez la syntaxe sans modifier le sens. Si la source indique le 20 novembre 2026, écrivez 2026-11-20. Ne remplacez pas une date inconnue par une date inventée uniquement pour satisfaire le format.

dcterms:modified invalide

Générez un véritable horodatage UTC correspondant à la construction de la nouvelle version. Un export fiable de l'outil de production devrait le mettre à jour.

Date différente entre fiche et EPUB

Posez trois questions :

  1. la fiche décrit-elle une date de mise en vente ou la publication de l'EPUB ?
  2. le fichier contient-il une ancienne valeur devenue obsolète ?
  3. la différence est-elle une décision documentée ou un accident ?

Si les deux champs sont supposés décrire le même événement, choisissez la source de référence et alignez-les. S'ils décrivent des événements différents, ne forcez pas une identité artificielle : documentez la différence et vérifiez que chaque système reçoit la donnée appropriée.

Procédure de contrôle

  1. Inventoriez les dates présentes dans la fiche, l'EPUB et le calendrier commercial.
  2. Attribuez un sens explicite à chaque valeur.
  3. Vérifiez le format ISO de dc:date.
  4. Vérifiez la présence et la forme de dcterms:modified.
  5. Confirmez la date de mise en vente dans la source commerciale de référence.
  6. Corrigez uniquement les champs qui décrivent mal leur événement.
  7. Relancez EPUBCheck et conservez la date de génération de la version livrée.

Une cohérence sémantique, pas seulement visuelle

Deux dates identiques peuvent être fausses si elles désignent des événements différents. Deux dates différentes peuvent être correctes si l'une décrit la publication du fichier et l'autre l'ouverture commerciale. Le contrôle doit porter sur le sens.

Sources officielles