← Tous les articles
scribe · epub · pdf · Workflow · alternatives 8 min

Exporter EPUB et PDF imprimable depuis une seule source : le flux de travail mono-fichier pour l'auteur indépendant

L'EPUB et le PDF imprimable suivent des logiques de mise en page différentes, mais le manuscrit ne devrait exister qu'une seule fois. Voici un chemin qui garde la source unique et les sorties multiformes.

Exporter EPUB et PDF imprimable depuis une seule source : le flux de travail mono-fichier pour l’auteur indépendant

Le livre numérique contre l’imprimé n’est plus un choix exclusif dans l’écosystème indépendant. En 2026, une stratégie de publication courante consiste à diffuser les deux simultanément — le livre numérique via KDP, Apple Books, Kobo Writing Life et autres ; l’imprimé via KDP Print, IngramSpark ou une imprimerie locale. Deux formes couvrent différents lecteurs, différents contextes d’achat, différents prix ; ensemble, elles constituent la distribution complète d’un auteur indépendant.

Scribe single-source EPUB and PDF export
Catalpas Atelier Scribe · One source, two outputs

Mais l’EPUB et le PDF imprimable suivent des logiques de mise en page très différentes. L’EPUB est redimensionnable — les lecteurs ajustent la taille de la police, l’interlignage et la largeur de lecture, et le texte se recompose selon l’appareil. Le PDF imprimable est une mise en page fixe — les positions des caractères, le nombre de lignes, les débuts de chapitres et les relations gauche/droite de chaque page sont prédéterminés. « Nouveau chapitre à chaque page » dans l’EPUB doit devenir « nouveau chapitre à chaque page, commençant sur une page de droite » dans l’imprimé ; une image qui peut être de n’importe quelle proportion dans l’EPUB doit tenir compte du fond perdu et de l’espace colorimétrique dans l’imprimé.

Cette différence pousse de nombreux auteurs vers une voie à « double source » : écrire un .docx dans Word ou Scrivener, exporter et convertir en EPUB via Calibre, et faire simultanément la version imprimée dans Vellum, Atticus ou InDesign. En cours de projet, vous devrez peut-être réviser le manuscrit et synchroniser les modifications entre les deux versions. À court terme, cela fonctionne ; à long terme, chaque révision doit être synchronisée deux fois, et la divergence n’est qu’une question de temps.

Une voie plus sensée est source unique + modèle parallèle : un fichier texte unique (généralement Markdown ou .docx) est la source faisant autorité ; le livre numérique et l’imprimé ont chacun leurs propres modèles de composition qui rendent à partir de cette source. Vellum et Atticus ont promu ce modèle dans la scène indépendante anglophone (bien que leurs formats source diffèrent) ; il est moins courant dans la scène éditoriale chinoise. Nous abordons ci-dessous quatre aspects de cette approche.


Le coût des sources doubles : la divergence n’est qu’une question de temps

La plupart des auteurs ne ressentent pas le coût pendant le premier livre — pendant les deux ou trois mois précédant la publication, maintenir les deux fichiers en parallèle n’est pas difficile. Le coût apparaît après la publication du livre.

Un lecteur signale une coquille dans une section — vous retournez réviser, corrigez le .docx, mais le projet Vellum n’est pas mis à jour ; au prochain réimpression, vous découvrez que la correction n’a pas été prise en compte. Ou vous voulez faire une deuxième édition avec une nouvelle préface — la préface va dans le projet imprimé, mais la source EPUB n’est pas synchronisée, et les lecteurs du livre numérique voient encore l’ancienne version. Ce piège des « deux versions désynchronisées » est récurrent pour les auteurs indépendants lors de multiples réimpressions ou d’opérations à long terme.

Le coût le plus subtil est le fardeau psychologique. Chaque fois que vous envisagez une révision, votre cerveau doit suivre « corriger à deux endroits », et cette friction élève silencieusement le seuil pour « changer une ligne ». Avec le temps, cela supprime le polissage continu du manuscrit.


Source unique + modèle parallèle : garder la source unique

Une voie plus robuste consiste à compresser le manuscrit en une seule source faisant autorité, les versions ebook et imprimée étant chacune rendues via leurs modèles. Markdown a des avantages structurels ici :

  • C’est du texte brut, ouvrable par n’importe quel éditeur ;
  • Sa structure (chapitres, emphase, listes) est sémantique, et les modèles peuvent rendre différentes formes à partir des mêmes sémantiques ;
  • C’est léger, facile à versionner et à synchroniser.

Le flux de travail ressemble approximativement à ceci :

  1. Écrivez en Markdown, un fichier .md par chapitre, et mettez les métadonnées du projet (titre, auteur, ISBN, page de copyright) dans un fichier YAML.
  2. Choisissez un modèle d’ebook — définissez les polices, l’interlignage, les styles de paragraphe, les styles de page d’ouverture de chapitre — rendez l’EPUB 3.
  3. Choisissez un modèle d’impression — définissez le format de rognage, les marges, le côté de reliure, les polices (qui peuvent différer de l’ebook), le CMJN — rendez le PDF imprimable.
  4. Lors des révisions, modifiez uniquement la source Markdown — les deux sorties se mettent à jour lors du prochain rendu.

Le but n’est pas « d’utiliser Markdown » — c’est que les modèles absorbent les besoins différenciés de l’EPUB et de l’impression, de sorte que l’auteur n’a pas à modifier le manuscrit lui-même pour chaque sortie.


Gestion de version : épingler chaque publication

Un autre avantage du flux de travail à source unique est qu’il s’associe naturellement au contrôle de version. Placez le projet Markdown dans un dépôt Git, validez à chaque changement significatif et étiquetez chaque publication (v1.0, v1.1-correction, v2.0-révisé). Ainsi :

  • Vous pouvez revenir à n’importe quelle version historique à tout moment et regénérer l’EPUB et le PDF imprimable de cette version ;
  • Vous savez exactement quand chaque changement a été fait et pourquoi (message de validation) ;
  • Vous pouvez créer des branches pour différentes versions linguistiques, éditions régionales et éditions spéciales (relié, dédicacé) sans polluer le manuscrit principal.

Pour les auteurs prêts à passer un jour ou deux à apprendre Git, la stabilité que cette couche apporte dépasse de loin l’approche Word + nom de fichier daté. Si Git n’est pas pour vous, placer le projet Markdown dans Dropbox / iCloud / Google Drive vous donne une synchronisation de base et un retour en arrière historique — mais à une granularité plus grossière.


Catalpas Atelier Scribe : source unique + aperçu synchronisé

Catalpas Atelier Scribe est une application de bureau conçue autour de ce flux de travail. Sa position centrale est « source Markdown + modèles ebook et imprimé en parallèle + aperçu en direct ».

La source est Markdown dans un dossier Un fichier .md par chapitre, texte brut ouvrable par n’importe quel éditeur, compatible Git, reconnaissable par tout outil de synchronisation. Scribe ne verrouille pas le manuscrit dans une base de données propriétaire.

Volet d’écriture + aperçu double sortie en direct Le volet d’écriture de gauche est en Markdown ; le volet d’aperçu de droite bascule entre « aperçu ebook » et « aperçu imprimé » — même source, deux formes de sortie, avec des mises à jour de mise en page au niveau de la milliseconde par frappe. Cela raccourcit considérablement le cycle de retour par rapport à « exporter et vérifier le PDF ».

À partir de Plus : EPUB 3 + PDF niveaux de gris / RVB Plus débloque l’EPUB 3 (avec métadonnées de publication complètes, prêt pour KDP / Apple Books / Kobo) et le PDF niveaux de gris/RVB. La publication à double voie de la plupart des romans anglais et des œuvres de non-fiction générale est couverte par Plus.

Pro : CMJN + ICC + maîtres d’impression personnalisés + ruby Les projets avec des exigences d’impression plus élevées (livre relié, livres d’art, édition CJK, intérieurs couleur) nécessitent Pro : espace colorimétrique CMJN, gestion des couleurs ICC, maîtres d’impression personnalisés (pages en regard + basculement du côté de reliure + fond perdu + gouttière), import de polices personnalisées et ruby. Pro est à 79,99 $/an en tarif de lancement, 129,99 $/an en tarif normal.

Natif sur trois plateformes Windows, macOS et Linux ont tous des clients natifs ; les fichiers sont par défaut en stockage local, synchronisation cloud en option.


Une comparaison avec Vellum et Atticus

Vellum et Atticus incarnent tous deux la philosophie de conception « source unique, ebook et modèle d’impression parallèles », et ce sont des outils éprouvés dans la scène indépendante anglophone. Vellum offre des thèmes prédéfinis soigneusement conçus et une composition anglaise quasi parfaite ; Atticus est natif du web, facile à utiliser sur tous les appareils et en achat unique.

Ce qui les exclut de la liste des candidats sur ce chemin sont différentes limites :

  • Vellum est exclusivement macOS et ne supporte pas la composition verticale CJK ni le ruby ;
  • Atticus étant natif du web signifie que le manuscrit est hébergé dans le cloud, ne supporte pas la couleur d’impression CMJN et ne couvre pas le CJK vertical ;
  • Aucun des deux n’a une source ouverte en Markdown — l’export nécessite une conversion.

Scribe fait des compromis différents sur ces trois points : natif sur trois plateformes, CJK vertical disponible par défaut, source ouverte en Markdown. Il ne battra pas Vellum sur l’axe de l’expérience utilisateur Mac anglais — ce n’est pas son objectif. Il étend le flux de travail à source unique dans les scénarios que Vellum et Atticus ne couvrent pas.


Faire votre choix

La source unique + modèle parallèle est un flux de travail durable à long terme, mais tous les auteurs n’ont pas besoin de basculer immédiatement.

Si vous ne publiez qu’un seul livre et que Word + Vellum/Atticus fonctionne déjà, il n’y a aucune raison de forcer une migration « pour un flux de travail plus élégant ». Les bons outils n’ont pas besoin d’être remplacés.

Dans les cas suivants, le flux de travail Markdown à source unique peut être la meilleure solution :

  • Vous prévoyez de publier plusieurs livres et voulez que le coût de maintenance reste gérable ;
  • Vous appréciez la portabilité à long terme du manuscrit et ne voulez pas être enfermé dans un format propriétaire ;
  • Vous écrivez déjà en Markdown ;
  • Votre projet implique du CJK vertical ou du ruby, ce qui exclut Vellum et Atticus ;
  • Vous voulez utiliser Git pour un contrôle de version précis et la collaboration ;
  • Votre combinaison d’appareils couvre Windows, macOS et Linux.

Le meilleur flux de travail est « révisez une fois, mettez à jour les deux sorties ». Commencez par le niveau Gratuit, prévisualisez à la fois l’ebook et l’imprimé depuis la même source Markdown, et voyez si cela correspond à votre rythme.


Lectures complémentaires :

Essayez le même flux de travail dans Scribe — Gratuit pour commencer, tarif de lancement Pro verrouillé →