Scribe et Word : un flux de révision aller-retour via le docx

Scribe et Word : un flux de révision aller-retour via le docx

Quel que soit l’outil qu’un auteur utilise pour écrire, Microsoft Word reste, en 2026, le « format intermédiaire » le plus courant dans les flux de travail d’édition et de publication. Les éditeurs acquéreurs, les rédacteurs, les agents littéraires, les co-auteurs, les processus de révision internes des maisons d’édition traditionnelles — la plupart traitent encore le .docx comme la lingua franca. Même si vous écrivez en Markdown depuis des années, même si vous prévoyez de vous auto-éditer et de contourner les canaux traditionnels, dès que votre pipeline implique une autre personne, le docx est difficile à éviter. « Word » dans cet article couvre également les outils comparables capables de lire et d’écrire le docx — LibreOffice Writer, Apple Pages, Google Docs, WPS — leur modèle de collaboration et les limites du docx sont partagés.

Catalpas Atelier Scribe ne vise pas à remplacer Word, et n’essaie pas de rivaliser avec les fonctionnalités de collaboration de Word. Dans ce pipeline, Scribe possède « le côté auteur : la prose et le livre fini », et Word, du côté de l’éditeur, possède « les commentaires, les révisions, le suivi du processus ». Les deux côtés échangent le manuscrit via le docx. La question n’est pas « quel outil » — c’est « quand est-ce que je confie le manuscrit au docx, et quand est-ce que je le récupère ? »

La réalité : les collaborateurs n’acceptent que le docx

Pour les auteurs indépendants, accepter cela coûte moins cher que de lutter contre. Même lorsque l’éditeur avec qui vous travaillez est techniquement compétent et pourrait en principe lire le Markdown, au moment où vous êtes réellement en phase de révision, ce dont il a besoin n’est pas une capacité de lecture — c’est l’ensemble du rituel de collaboration Suivi des modifications + Commentaires construit autour de Word. Markdown n’a pas de système de révision visuelle aussi mature. Les marqueurs de style CriticMarkup peuvent fonctionner dans un petit cercle, mais ils ne peuvent pas offrir « je veux que mon éditeur acquéreur lise toutes les révisions de mon livre en deux heures ».

Donc, le flux de travail réaliste ressemble généralement à ceci : vous écrivez le corps du texte dans Scribe, organisez les chapitres et effectuez des révisions locales ; lorsque le manuscrit a besoin d’un passage de révision, vous exportez un docx ; l’autre personne travaille dessus dans Word (ou LibreOffice, Pages, Google Docs) avec le suivi des modifications et les commentaires, puis vous le renvoie ; vous retournez dans Scribe et « traduisez » ses révisions dans le corps du texte. Chaque aller-retour implique une conversion de format, donc la question devient : comment rendre cette conversion aussi peu coûteuse que possible ?

Le pont docx : ce qui traverse, ce qui se perd

Quand Scribe exporte un docx (et quand vous importez un docx révisé par quelqu’un d’autre dans Scribe), le sort de plusieurs types de contenu mérite d’être connu à l’avance.

La structure et les titres de chapitres restent relativement fidèles — la correspondance Titre 1 / Titre 2 est stable des deux côtés. Cela signifie que quand quelqu’un réorganise des chapitres ou renomme des titres dans Word, Scribe le détectera au retour.

Les paragraphes du corps du texte et le formatage de base (gras, italique, citations) survivent également à l’aller-retour. Mais l’espacement des paragraphes, la hauteur de ligne et la taille de police sont des propriétés que les contrôles de composition typographique au niveau du projet de Scribe gèrent — elles ne devraient pas être modifiées manuellement dans le docx. Une fois qu’elles le sont, elles seront soit remplacées par la composition de Scribe au retour, soit créeront des incohérences locales. Lorsque vous remettez le docx, dites explicitement à l’éditeur : « Ne modifiez que le texte et la structure — la composition est unifiée de mon côté. »

Le suivi des modifications est l’élément le plus précieux de ce pipeline — il vous indique exactement quel paragraphe a été modifié, ce qui a été ajouté, ce qui a été supprimé, par qui et quand. Du côté de Scribe, conservez le docx retourné comme « fichier de référence », parcourez les révisions une par une, décidez d’accepter ou de rejeter, et appliquez-les manuellement dans Scribe. N’essayez pas de fusionner automatiquement — aucun outil actuel ne préserve le suivi des modifications sans perte à travers un aller-retour Markdown ↔ docx, et les quelques minutes économisées au départ ne compenseront pas le temps passé à résoudre les problèmes plus tard.

Les commentaires sont similaires — traitez les commentaires du docx comme une « liste de tâches » du côté de Scribe, parcourez-les, modifiez la prose dans Scribe et archivez le docx original une fois terminé. Les commentaires n’ont pas besoin de — et ne devraient pas — vivre dans le projet Scribe à côté du corps du texte.

Ce qui se perd : les tableaux complexes, les objets incorporés (formules, graphiques, SmartArt), les zones de texte, les styles personnalisés. La plupart des manuscrits de fiction n’utilisent pas ces éléments. Si vous écrivez de la non-fiction avec beaucoup de figures, vous devrez convenir avec l’éditeur dès le départ : « laissez les figures de côté pour l’instant, révisez seulement la prose », pour éviter d’avoir à réinsérer les figures à chaque cycle.

Contrôle de version entre les cycles de révision

Lorsque vous effectuez deux ou trois cycles de révision aller-retour, la nomination des fichiers et l’archivage comptent plus qu’il n’y paraît. Une approche fiable :

• Lors de l’export de Scribe vers l’éditeur : nomdulivre_v0.3_vers-editeur_AAAA-MM-JJ.docx
• Quand l’éditeur le renvoie : nomdulivre_v0.3_de-editeur_AAAA-MM-JJ.docx
• Après avoir terminé le traitement, faites passer la version dans le projet Scribe à v0.4 et commencez le cycle suivant

Le but n’est pas d’avoir de jolis noms de fichiers — c’est qu’à tout moment vous puissiez répondre à « quelle version l’éditeur a-t-il en ce moment ? » et « y a-t-il une divergence de version entre nous ? » La version la plus récente de la prose vit toujours dans le projet Scribe — les fichiers docx sortants sont des instantanés, les fichiers docx entrants sont des instantanés porteurs de retours, mais aucun des deux n’est la source de vérité.

Deuxième règle : quand le retour de l’éditeur arrive, ne plongez pas immédiatement dans Scribe. Lisez d’abord le docx retourné, portez un jugement sur chaque révision et commentaire (accepter / rejeter / discuter), puis reportez les décisions dans Scribe en une seule fois. C’est beaucoup plus rapide que « lire le docx et éditer Scribe en même temps », et cela réduit la dérive de version.

Quand quitter le côté Word : la connaissance retourne dans Markdown

Une dernière décision : quand arrêter de passer par le pont docx ?

Si vous vous auto-éditez et que vous êtes encore en phase de brouillon personnel, vous n’avez pas besoin du premier cycle du tout — écrivez jusqu’au bout dans Scribe, relisez-vous, révisez, publiez l’EPUB et le PDF imprimable. Le docx ne vaut son coût que lorsque vous avez « besoin qu’une autre personne regarde le manuscrit et accepte ses modifications ».

Si vous avez déjà effectué deux ou trois cycles de révision de fond et de copie, la phase de verrouillage final doit revenir entièrement du côté de Scribe : à partir de maintenant, chaque modification se fait uniquement dans le projet Scribe, plus d’« envoi d’un autre docx pour validation ». Chaque aller-retour introduit un peu de risque de formatage et de composition, et en phase pré-impression, il n’y a aucune raison de continuer à le prendre.

Quand devriez-vous ignorer complètement Word ? Quand le collaborateur accepte lui-même la collaboration Markdown (un petit nombre d’éditeurs techniques, des groupes d’écriture soudés) et ne dépend pas du rituel du suivi des modifications — à ce moment-là, vous pouvez communiquer les modifications via git diff ou la comparaison de versions intégrée de Scribe, plus légère que les allers-retours docx. Mais évaluez honnêtement les habitudes réelles de l’autre personne. Ne laissez pas « j’aimerais qu’ils utilisent Markdown » l’emporter sur « c’est ainsi qu’ils travaillent réellement ».

Ouvrir Scribe pour voir comment il s’associe au flux de travail docx de votre éditeur ou collaborateur →

Vous pourriez aussi aimer lire

• Le hub collaboration Scribe — le point d’entrée pour les flux de travail avec d’autres outils d’écriture, de prise de notes et de révision
• Scribe versus Microsoft Word : comparaison côte à côte — si vous préférez partir d’une comparaison d’outils