J'ai écrit deux bouquins (enfin trois, ça dépend comment on compte)
Le premier, Apache Maven pour Pearson, a été mon premier pas dans le monde de l'édition. J'ai découvert le template word imposé par l'éditeur, le long travail de marquage du texte pour générer l'index. Bref, la rédaction n'est qu'une petite partie du travail au final. Nous (Arnaud et moi, co-auteurs) travaillions avec un partage Dropbox, ce qui a permis d'aller assez vite dans la mise au point du contenu. Le travail a été très supérieur à ce que j'estimais, aussi - au vue du gain financier - il est clair qu'on fait ce genre d'exercice pour la gloire, pas pour la fortune.
Nous n'avions qu'un seul interlocuteur, ça c'est donc suffisamment bien passé pour que nous plongions une seconde fois. Cette seconde édition a eu lieu pendant un jeu de chaise musicales chez Pearson et donc un manque de suivi assez désastreux. Bref, la seconde édition est sortie sans aucune intention de faire un v3 - encore faudrait-il qu'il y ai de quoi d'ailleurs vu le contenu des nouveautés de Maven 3.1, mais c'est un autre débat.
Je me suis lancé dans un autre livre, plus court et en Anglais, pour Packt. Il s'agit d'un livre sur CloudBees, guide du développeur, donc en plein dans mon sujet. Packt ne m'épargne pas le template maison, bien pire que celui déjà lourd de Pearson. J'en pleure encore. Je suis secondé d'un relecteur non technique chargé de valider mon english pas très fluent et de corriger la mise en forme. Il a tenté de m'expliquer 10 fois les règles fort intéressantes de formatage des textes, mais j'ai autre chose à faire donc je lui ai laissé le plaisir de le faire pour moi - après tout, lui est salarié de Packt, moi je fais ça sur le temps libre que j'arrive à trouver.
La revue des chapitres est sensée se faire par échange de mails. Bienvenu en 2013. J'ai pu imposer un dropbox, surtout que les relecteurs techniques sont sans surprise mes collègues de CloudBees. Ca limite les dégâts, mais au final je passe quelques heures à approuver des changements de style dans le doc.
Accessoirement, Packt impose un planning ultra serré, un chapitre par semaine, je suis donc à 8 semaines de dépassement :P Ils m'ont aussi envoyé de nombreux formulaires word pour indiquer mes coordonnées, ma bio, mes références, et dernièrement un document "très urgent" visant à fournir au marketing des phrases type pour faire la promo du livre. Super, après avoir fait le boulot de la PAO, voilà que je dois faire celui du marketing. A ce rythme ils vont me demander de livrer les bouquins moi-même.
Bref, je ne suis pas prêt de replonger, et je vous déconseille l'expérience si vous êtes tenté de faire connaitre votre projet open-source ou de mettre en avant votre expertise. Pour le gains financier ridicule par rapport au travail, préférez une doc en markdown ou n'importe quel autre format léger, avec un bon script d'export PDF et auto-publiez-vous. Un exemple parfait amha est le livre Pro Git, hébergé sur GitHub ce qui n'a pas empêché APress de le publier.
3 commentaires:
APress m'a imposé ses templates Microsoft Word et un relecteur technique pitoyable (le précédent avant quitté la boite). A chaque révision, le doc Word prenait 5Mo... et à chaque upload sur leur Sharepoint il fallait croiser les doigts et bruler des pattes de lapin. Ils m'ont supprimé 2 pages (que je vais mettre sur mon blog perso) car je parlai de l'Iran et je viens d'apprendre que 2 mois après la publication, ils ont fait une bourde sur le code barre du livre et doivent le réimprimer.
La presse va mal, l'édition va mal... et ça se sent. Ils sont en sous effectif, un turn over important, de nouveaux challenges, des marges ridicules... Nous sommes en train de vivre les dernières décennies de l'édition telle que nous la connaissons.
C'est dommage pour eux, mais après ma mauvaise experience (et je vois que je ne suis pas le seul), je vais plutôt me lancer dans l'auto-édition...
Merci pour ton article. Interessant d'avoir ton retour à plus d'un titre.
D'abord parce que Packt m'a contacté il y a quelques temps pour écrire un bouquin sur Robot Framework (alors que l'audience est limité est que je n'en suis qu'un utilisateur lambda). Je n'avais pas sentis le truc et n'avais pas donné suite. Tu me confirmes que j'ai bien fait.
Ensuite, le sujet de l'édition m'interesse car j'ai bossé de l'autre côté de la barrière, à savoir comme éditeur chez Micro Application il y a une dizaine d'année. Et ce que l'on proposait comme formule de travail était semblable à ce que tu es en train de vivre (template Word par exemple, et échange de mail pour la collaboration). Mais bon, en 10 ans ça aurait pu évoluer dans ce monde, mais ça n'est pas trop le cas.
Ceux qui semblent bien bouger et reflechir sur le sujet sont OReilly. Il y a eu un article interessant sur le sujet " re-inventing publishing" il y a peu de temps qui pourrait t'interesser: http://radar.oreilly.com/2013/08/shakespeare-and-the-myth-of-publishing.html
Et donc, pour rebondir aussi sur le message d'Antonio ("dernières décennies de l'édition"), tu la verrais comment l'édition de demain en tant qu'auteur ? S'auto-publier est une réponse. On perd le côté "correcteurs" que peut apporter un éditeur (mais après tout, tout le monde pourrait corriger ton texte un peu comme on fix un bug sur un projet open source).
Quid du modèle économique ? On renonce à gagner un peu de sou avec son travail ?
Quid du du caractère "gravé dans le marbre" du bouquin ? On y renonce et on part sur une formule ou le livre est continuellement mis à jour ?
Est ce que l'on pourrait/devrait avoir des outils qui permettent d'écrire le livre à plusieurs main de façon très souple ?
Si t'as un avis sur ces points, ça m'interesse.
Je n'ai pas le don de voyance pour te dire ce que sera l'édition de demain ...
quelques pistes:
- le rôle de correcteur de l'éditeur est purement sur la forme, et essentiellement sur la forme nécessaire à leur chaine de PAO. Aucune remarque pertinente sur le fond.
- une énorme difficulté sur un ouvrage informatique est la rapidité avec laquelle les choses changent. Le livre à peine ébauché, les infos sont partiellement obsolètes. De ce point de vue une version purement online est plus simple à maintenir, mais c'est au final un autre usage.
- modèle économique ... pour gagner l'équivalent de l'écriture d'un bouquin fait quelques heures sup. L'auteur n'a rien à gagner si ce n'est un peu de renommée, ce qui est finalement plus facile avec un bon blog ou un tutoriel en ligne.
- l'outillage d'écriture est clairement un élément important. Si on pouvait rédiger un bouquin via du markdown sur github, je suis convaincu que les ouvrages à 6,8, 12, 40 mains seraient plus fréquents
Ce que je crois que les éditeurs n'arrivent pas à prendre en considération les outils collaboratifs modernes. Au lieu de s'y plier, il imposent leur chaine de production aux auteurs. Ca ne semble pourtant pas si compliqué de produire un PDF ...
Enregistrer un commentaire