What is it like to write a technical book?

Ce que c'est que d'écrire un livre technique

Comme vous le savez probablement, j'ai récemment fini d'écrire un livre avec d'autres co-auteurs. J'ai pris des notes tout au long de ce travail et j'avais envie de décrire le processus pour ceux qui envisagent aussi d'écrire un livre.

Je pense qu'il est important d'être objectif ; mon propos ici est d'aider de futurs auteurs à découvrir ce à quoi ils doivent s'attendre, et tout n'est pas fabuleux. J'espère que je n'aurai l'air d'être rancunier envers personne, ni d'essayer de rabaisser des gens. J'ai beaucoup à dire sur ce qui s'est bien ou mal passé et sur les effets, positifs ou négatifs, que ça a eu sur le processus.

Excusez l'aspect décousu de cet article. J'aurai aimé mieux l'écrire, mais il y a beaucoup à dire et il faut beaucoup de travail pour écrire un aussi long article de façon structurée.

Peter Zaitsev m'a contacté il y a environ un an pour me demander si j'aimerais l'aider à écrire un livre. Dans les premiers temps, l'idée était que j'écrirais quelques appendices et que j'aiderais à faire des écrits de Peter et Vadim quelque chose digne d'un livre ; je devais être une sorte d'éditeur technique idéalisé. A cette époque, je ne connaissais pas encore son identité, mais je savais qu'il devait y avoir un quatrième auteur.

Quand Peter m'a contacté, je me suis renseigné sur le planning, la structure du livre et ce qui était déjà réalisé. À ce moment-là, le plan était très vague : des têtes de chapitres et des titres, avec une phrase ou deux pour expliquer la structure à quelques endroits. Le plan était en partie calqué sur celui de la première édition et les chapitres sur les tests de performance, les optimisations, l'indexation et les optimisations des requêtes étaient partiellement écrits.

Le planning avait à vrai dire déjà dérapé, car le livre était supposé être prêt pour la relecture technique en juin 2007. La proposition était de revoir le planning pour que tout aille en revue technique en octobre 2007. Je ne sais pas quand Peter a réellement commencé à écrire son livre ; Andy Oram a passé des années à chercher des auteurs pour la seconde édition et je pense que Peter avait commencé quelque temps avant que je n'embarque sur le navire. Il a ensuite ajouté Vadim et Arjen à l'équipe, mais il était clair qu'il serait impossible de tenir le planning originel.

J'ai demandé à l'éditeur de m'envoyer le contrat et j'y ai jeté un coup d'œil. Il était plutôt vague. Les responsabilités et les échéances intermédiaires n'étaient pas définies. J'ai demandé à l'un de mes amis qui avait écrit un livre pour Apress de me faire part de ses impressions. Je lui ai demandé à quoi je devais m'attendre si je me lançais dans cette aventure. Il m'a décrit un processus défini très précisément ; son contrat détaillait quelles étaient ses responsabilités et quelles devaient être les étapes menant à la publication du livre, qui devait réaliser chaque étape ainsi que leur ordre de réalisation. Si son co-auteur ne parvenait pas à achever ses chapitres, il n'en était pas responsable. Le contrat de O'Reilly, à l'opposé, était vraiment vague. J'ai retourné la question dans ma tête et je me suis dit que le planning proposé était amusant, j'ai donc décidé de me lancer dans ce projet en faisant fi du mauvais contrat.

J'ai négocié le statut d'auteur complet, plutôt que d'être uniquement mentionné dans les remerciements , comme cela était prévu à l'origine par l'équipe de O'Reilly qui prévoyait que je ne ferais pas beaucoup de travail. En effet, j'ai jugé que pour bien réaliser ce travail il me faudrait beaucoup de temps. J'en ai parlé à mon chef à Rimm-Kaufman Group et il m'a entièrement soutenu et m'a accordé de réduire mon temps de travail. Je suis revenu vers O'Reilly et je leur ai demandé d'avoir une avance sur les ventes plus significative pour me permettre de couvrir la perte de revenu liée à mon passage à mi-temps et je l'ai obtenue. J'ai signé le contrat et je me suis mis au travail. En fait, j'ai certainement commencé à travailler d'abord.

L'industrie des publications techniques travaille probablement de différentes façons, et je ne suis pas expert dans ce domaine, mais ce qui m'a le plus surpris est le fait qu'en général, dans le monde technique, vous n'écrivez pas un livre avant de chercher un éditeur qui l'imprimera. Non, cela fonctionne dans l'autre sens. En général, ils font une étude de marché, décident qu'il existe un besoin pour un livre sur un sujet et commencent à chercher des gens qui seraient compétents pour l'écrire. J'imagine que cela doit être un défi, en particulier pour une seconde édition lorsque les auteurs de la première édition ne souhaitent plus y être associés.

Le processus

Pour réussir à faire imprimer un livre il ne s'agit pas juste d'écrire et d'expédier le manuscrit, ce n'est pas aussi simple. Nous avons rédigé une première version, puis l'avons envoyée à l'éditeur, faite circuler entre nous, rédigé un nouveau brouillon, ré-édité, ad nauseum. Puis le livre a dû passer par la relecture technique et nous avons reçu des commentaires et des révisions à faire ; il a donc fallu revoir et éditer encore une fois ; puis ré-écrire et ainsi de suite. Au bout du compte, le livre a réussi à obtenir l'approbation éditoriale finale et est enfin "parti en production". Si vous pensiez que le travail était achevé... détrompez-vous, c'est encore loin d'être terminé. Le manuscrit devait encore passer entre les mains du réviseur de production, de l'éditeur de production, d'un artiste professionnel, du correcteur d'épreuves, du contrôle qualité, retour au correcteur d'épreuves pour finir avec l'indexation et un dernier contrôle qualité suivit d'une ultime révision avant de finalement partir à l'impression. Chacune de ces étapes m'a demandé beaucoup de travail.

Collaboration et Outils

Nous étions géographiquement assez dispersés, de la Californie à Londres, l'Ukraine, la Virginie et l'Australie. La collaboration ressemblait à ce que vous pouvez imaginer : nous ne nous sommes jamais rencontrés face à face, même si nous nous sommes envoyés beaucoup d'e-mails et que nous organisions une conférence téléphoniques VOIP hebdomadaire (à 6h30 du matin pour mon fuseau horaire, très tard dans la nuit pour celui de Arjen). Nous nous sommes servis du dépôt Subversion que O'Reilly a mis à notre disposition pour stocker les chapitres, les illustrations, etc. Et nous avons utilisé OpenOffice.org pour écrire les chapitres. Cela me convenait très bien ; j'avais peur, lorsque j'ai commencé, que nous utilisions Word. Je n'aime aucun type de traitement de texte, mais OO.org me convenait bien mieux que Microsoft Word.

4 Schema Optimization and indexing (ch04-Schema_Optimization.odt)

  * Baron has written nearly everything.
  * Baron is waiting for feedback on one section.
  * Baron moved redundant material to other chapters.
  * Peter has reviewed and commented.
  * Baron reviewed Peter's comments and revised.
  * Baron reviewed for EXPLAIN appendix.
  * Sent to TR Jan 2nd.
  * Baron rewrote completely.
  * Baron reviewed for grammar and readability.
  * Peter reviewed again.
  * Baron reviewed Peter's comments and revised.
  * Baron revised as per Sheeri.
  * Baron revised as per Igor.
  * Andy edited again.
  * Baron revised.

Utiliser Subversion avec des fichiers binaires n'est pas idéal. Par défaut, Subversion ne verrouille pas les fichiers lorsqu'ils sont édités, il était donc possible d'éditer le même fichier au même moment et comme les fichiers OO.org sont binaires, il n'était pas possible de les fusionner. Nous avons donc défini la propriété svn:needs-lock sur les fichiers, de façon à ce qu'une seule personne puisse les éditer à une instant donné. Même si cela pourrait paraître problématique, le travail ne manquait pas et je ne pense pas qu'il y ait eu plus d'une fois ou deux où quelqu'un a dû attendre qu'une autre personne libère le verrou sur un fichier. Chaque chapitre était dans un fichier différent. Nous avions également quelques fichiers de méta-données indiquant l'avancement, les éléments à faire, etc. Voici un exemple tiré de notre fichier Statut:

4 Optimisation du schéma et index (ch04-Schema_Optimization.odt)

  * Baron a à peu près tout écrit.
  * Baron attend un retour pour une section.
  * Baron a déplacé des éléments en doublons dans d'autres chapitres.
  * Peter a relu et commenté.
  * Baron a relu les commentaires de Peter et les a pris en compte.
  * Baron a relu pour l'appendice EXPLAIN .
  * Envoyé à la revue technique le 2 janvier.
  * Baron a tout réécrit.
  * Baron a relu pour la grammaire et la lisibilité.
  * Peter a relu de nouveau.
  * Baron a relu les commentaires de Peter et les a pris en compte.
  * Baron a corrigé suivant les remarques de Sheeri.
  * Baron a corrigé suivant les remarques de Igor.
  * Andy a de nouveau édité.
  * Baron a fait des corrections.

Il s'agit de l'état final du fichier ; au cours de notre progression, nous avions des sous-sections dans ce fichier texte indiquant les étapes suivantes, qui devait faire quoi, etc. Évidemment, à différents moments, chaque section se voyait attribuer une étiquette disant quelque chose comme "ébauche finale terminée", alors qu'avec le recul elle n'était probablement achevée qu'à 25%.

Mais revenons en aux outils : en fait, vous pouvez comparer et fusionner des fichiers depuis OO.org, mais c'est assez rudimentaire. OO.org était énervant à plusieurs titres ; beaucoup de bogues se mettent en travers du chemin. Certains sont simples, comme la façon qu'a la boîte de dialogue "rechercher-remplacer" de ne pas se souvenir d'une recherche à l'autre que vous voulez utiliser des expressions régulières. D'autres sont plus sérieux et font planter le programme, par exemple lorsque vous appliquez une définition de style. O'Reilly possède une maquette qui contient des macros vous aidant à formater des choses avec les styles qu'ils veulent ; ainsi, ils sont ensuite capables de convertir les fichiers dans leurs propres formats. Ces macros sont plutôt maladaroites et à de maintes reprises leur utilisation ne s'est pas déroulée sans encombres. J'ai appris certains trucs pour mieux les utiliser ; finalement, j'ai trouvé différentes barres d'outils et boîtes de dialogue dans Writer et j'ai réussi à les faire fonctionner à peu près comme je le voulais, ce qui m'a permis de rédiger comme je l'entendais. Mais il restait encore beaucoup de choses agaçantes, comme l'impossibilité d'avoir une vue globale. Je ne suis pas sûr que OO.org puisse créer un sommaire automatique d'une façon ou d'une autre mais, de toute façon, les styles personnalisés de O'Reilly n'étaient pas reconnus comme étant des niveaux de titre pour apparaître dans cette vue du plan.

Au départ, quand Andy éditait des fichiers, il y mettait des commentaires en utilisant la fonctionnalité de Commentaire. Cela ne fonctionnait pas correctement. Les fonctionnalités de commentaire et de relecture de OO.org, tout du moins dans cette version, sont horribles. Trouver des commentaires dans un texte était extrêmement difficile, il semblait n'y avoir aucun lien entre l'ordre des commentaires et l'ordre dans lequel ils apparaissent dans le texte. Et une fois que je les avais trouvés, je ne pouvais en fait pas les lire, parce que l'interface ne faisait pas de retour à la ligne, je ne pouvais donc voir que quelques mots à la fois. J'ai donc rapidement convaincu Andy de mettre ses commentaires dans le texte plutôt. Il activa le "Suivi des modifications", qui fonctionne plutôt bien et il ne me restait plus qu'à les relire et à les accepter.

Au début, je pensais que je ferais de la relecture et de l'édition, pas que j'écrirais de nouvelles choses. J'ai donc commencé en activant le suivi des modifications. Mais cela rendait le programme vraiment très lent et je trouvais que a) j'écrivais plus que je n'éditais et b) lorsque j'éditais, je faisais fondamentalement de la ré-écriture. Je l'ai donc désactivé. À quelques occasions j'ai eu peur de perdre le sens originel, mais demander aux autres auteurs de relire mes changements prenait trop de temps. Les autres auteurs avaient tant de travail à faire qu'au final, nous avons juste réussi à obtenir que Peter écrive le plan initial, relise ce que j'écrivais à partir de ça et, dans certains cas, le relise une deuxième fois. J'ai dû faire face à cette réalité et proposer une autre méthode : extraire les morceaux pertinents qui nécessitaient vraiment, vraiment d'être relus et les mettre dans des e-mails, ce qui représentait beaucoup moins de travail pour les autres auteurs pour les parcourir et y répondre, mais qui me donnait plus de travail personnel.

D'autres choses ont également fortement réduit ma productivité : vous ne pouvez pas afficher deux pages à la fois et voir/éditer deux parties du document en même temps, etc, etc, etc. J'insérais des illustrations et elles disparaissaient lorsque quelqu'un d'autre ouvrait et sauvegardait le fichier. Finalement, je m'en suis sorti. Le plus important était que le travail se fasse.

Relire, ré-écrire et recommencer de zéro

Le livre était une seconde édition. Donc, techniquement, nous relisions et mettions à jour la première édition.

En fait, nous n'avons pas conservé grand chose de la première édition, juste quelques passages, la plupart des titres et la structure générale. Je veux être prudent sur la façon dont je dis ça, car je ne veux pas critiquer la première édition, mais il était évident que notre travail était de la rendre meilleure. J'ai entendu des gens dire qu'ils aimaient la première édition et d'autres dire qu'ils pensaient qu'elle n'allait pas assez en profondeur (Espérons que la seconde édition les satisfera).)

J'ai en fait réalisé que, à part pour le sommaire, j'ai préféré, si possible, ne pas me reporter au contenu de la première édition. Le travail de ré-écriture est beaucoup plus exigeant que de repartir de zéro, à moins que les changements soient vraiment minimes. À quelques endroits, nous pensions que les changements ne seraient que d'ordre cosmétique mais nous sous-estimions presque à chaque fois l'ampleur de la tache. Oups!

À la base, Peter et Vadim devaient rédiger le contenu et moi je devais le réécrire/l'éditer (suppléé dans cette tâche par Arjen dans certain cas), puis Peter devait le relire et Andy l'éditer et nous devions continuer ainsi jusqu'à ce que ce soit terminé. J'ai rapidement réalisé que ça n'allait pas fonctionner. Ré-écrire représente beaucoup plus de travail que juste écrire à partir d'un plan détaillé. Je l'ai chronométré plusieurs fois et j'ai découvert qu'il fallait environ 4 fois plus de temps pour ré-écrire et peaufiner le texte que pour simplement écrire les paragraphes.

Auteurs potentiels, notez bien ce point: La "touche finale" représente largement plus de travail que le processus initial, gratifiant, de coucher les mots sur le papier. Vous pouvez réduire votre travail d'environ 75% si vous travaillez sur un plan de plus en plus détaillé, longtemps après le moment où vous pensiez que vous deviez commencer à "écrire". C'est en tout cas ce qui ressort de mon expérience.

Après un peu de réflexion, j'en ai conclu que cela était dû au fait que la ré-écriture ressemble un peu à un exercice de rétro-ingénierie puis de recompilation. Voici un exemple pour illustrer mon propos :

De bonnes performances dépendent à la fois d'un schéma et d'un index optimal. Optimiser les paramètres du serveur peut améliorer les performances de quelques pourcents à plusieurs facteurs, mais optimiser un schéma conçu médiocrement et mal indexé peut améliorer les performances de plusieurs ordres de magnitude.

Ce paragraphe n'est pas très clair, mais il n'est pas non plus totalement incompréhensible. Que faire pour l'arranger ? Eh bien, voyons un peu ça... vous devez trouver ce qui est bon et ce qui est mauvais là-dedans. Qu'est-ce qui est flou ? Je pense que "de quelques pourcents à plusieurs facteurs" n'est vraiment pas très clair. Qu'est-ce que nous essayons de dire là ? Zoom arrière : quel est l'objet de tout ce paragraphe ? Je dirai que les éléments principaux de ce paragraphe sont a) vous avez besoin d'avoir à la fois un schéma optimal et d'une indexation optimale ; b) les réglages peuvent donner un peu d'amélioration, mais le schéma vous en donne beaucoup plus. Maintenant, nous allons essayer de trouver comment dire cela de façon succincte et de déterminer ce qu'il faut garder et ce qu'il faut enlever. Le texte qui est finalement arrivé à l'impression est celui-ci :

Optimiser un schéma conçu médiocrement et mal indexé peut améliorer les performances de plusieurs ordres de grandeur. Si vous avez besoin de hautes performances, vous devez concevoir votre schéma et vos index autour des requêtes spécifiques que vous effectuerez.

   Generosity can be Unwise

Ça change, hein ? 4 à 6 révisions séparent ces deux versions. Voici un autre avant/après :

    La Générosité peut manquer de Sagesse.

Une erreur courante est de supposer que puisque l'espace consommé pour de petites chaînes de caractères est le même pour VARCHAR(10) et VARCHAR(200), vous pouvez simplement définir la longueur maximale à une valeur plus grande. En fait, cela pénalisera fortement les performances, car les chaînes de caractères sont souvent allouées en interne comme un objet de taille fixe. Ainsi VARCHAR(200) occupera plus de place en mémoire, en particulier pour les tris ou les opérations qui utilisent des tables temporaires en mémoire. Il en va de même pour le tri des fichiers qui utilise des tables temporaires sur le disque. La meilleure stratégie est d'allouer l'espace dont vous avez réellement besoin.

   Generosity Can Be Unwise

   Storing the value ‘hello’ requires the same amount of space in a VARCHAR(5) and a VARCHAR(200) column. Is there any advantage to using the shorter column?

… et après :

    La Générosité peut manquer de Sagesse

    Stocker la valeur 'bonjour' nécessite la même quantité d'espace dans une colonne VARCHAR(5) que dans une colonne VARCHAR(200). Existe-il un avantage à utiliser une colonne plus petite ?

En fait, il y a un gros avantage. La colonne la plus grande peut utiliser beaucoup plus de mémoire, car MySQL alloue souvent des blocs de mémoire de taille fixe pour gérer les valeurs en interne. C'est particulièrement préjudiciable pour classer ou pour des opérations qui utilisent des tables temporaires en mémoire. La même chose se produit avec le classement des fichiers qui utilise des tables temporaires sur le disque. La meilleure stratégie est d'allouer uniquement l'espace dont vous avez réellement besoin.

Cette étape est extrêmement laborieuse. Vous pensiez peut-être qu'il appartient à l'éditeur de faire ce travail mais dans ce cas précis c'est principalement moi qui l'ai fait, pas l'éditeur. Si je ne m'y étais pas collé, soit a) l'éditeur ne l'aurait pas fait et j'aurais eu une tonne de travail de relecture sur les modifications (ce n'est pas une mince affaire) soit b) le livre aurait été de moins bonne qualité.

En conséquence de quoi nous avons rapidement abandonné l'idée que Peter et Vadim écriraient le premier brouillon et que je prendrais le relai à partir de là. Les quelques chapitres déjà écrits de cette façon nous ont demandé une quantité de travail démente et j'ai dû y revenir encore et encore. J'ai finalement demandé à Peter d'écrire un plan détaillé contenant les points importants et des fragments d'idées. C'était une base beaucoup plus saine pour rédiger. Je lui demandais essentiellement de remplir de façon itérative le plan pour moi. Avec le recul, je pense que c'était un moyen plus efficace d'écrire ce type de contenu à l'organisation hierarchique complexe (je ne pense toutefois pas que ce soit une bonne solution pour écrire une narration complexe ; cette approche n'est pas universelle).

Je ne retrouve plus de copie de ce plan brut, mais je pense que vous avez compris l'idée.

Par contre si le plan n'était pas suffisamment détaillé pour qu'on puisse commencer à l'exploiter nous nous exposions à beaucoup de travail supplémentaire. Par exemple, nous avions initialement regroupé les chapitres sur la réplication, le redimensionnement, la haute disponibilité, etc. Cela ne paraissait pas incongru, mais c'était parce que nous n'en avions pas assez détaillé la structure. Après avoir commencé à lui donner de la consistance, il nous est clairement apparu que ce serait un chapitre monstrueux et nous l'avons séparé en plusieurs morceaux, encore du travail supplémentaire. Nous avons également supprimé le chapitre "Les bases" de la première édition et nous avons fini par supprimer ou déplacer beaucoup de contenu qui n'était pas à la bonne place ou qui était dupliqué. Tout cela nous a demandé toujours plus de travail.

Éviter de tomber dans l'excès de détails vous sera très profitable pour écrire un livre tel que celui-ci dont la hiérarchie est très organisée. N'écrivez pas de la prose. A l'instant où vous commencez à écrire des phrases, vous commencez à structurer vos pensées, ce qui vous amène à crée des relations complexes entre les mots, les phrases et les paragraphes. Les démêler et les remettre ensuite en ordre est parfois violent. Il y eut des fois où je regardais quelque chose en sachant que c'était horrible mais il m'était impossible de trouver une autre formulation. J'avais des œillères car je me focalisais sur ce qui était déjà là.

Si pour certains passages les phrases s'enchaînaient logiquement, il nous est souvent arrivé de devoir remanier l'ordre des paragraphes, voire l'ordre des pages. Si dans un premier temps le texte formait un ensemble cohérent, après quelques modifications, la suite logique des phrases qui conférait justement au texte cette cohérence était perdue. Nettoyer cela était très difficile. Je conseille aux auteurs potentiels de prévoir beaucoup de tripatouillage sur le plan, donc Faites un plan beaucoup plus détaillé que prévu. Réarranger des morceaux de chapitre est beaucoup plus simple quand ils sont encore sous forme de points.

Arrivé à un certain point, quand le texte commence à s'accumuler, il devient difficile de s'y retrouver. Plus d'une fois je me suis dit : "J'ai écrit quelque chose à propos de ça quelque part" et à le chercher, mais sans être capable de mettre la main dessus. Plus tard, en éditant un autre chapitre, je tombais sur ce que je cherchais, mais je n'arrivais alors plus à me souvenir où j'en avais besoin. Parfois, j'utilisais différents mots à deux endroits, il était donc impossible de retrouver les deux passages à partir d'un seul mot-clé. Nous avons eu beaucoup de doublons à certains moments et ça nous a posé beaucoup de problèmes. Une partie de nos soucis venait du fait que le livre était organisé de façon hiérarchique et que le vieux problème de la hiérarchie unique commençait à nous créer des ennuis. Certains passages auraient leur place à plusieurs endroits du livre, mais ils peuvent seulement apparaître une fois. Les réglages du serveur et les variables de statut en sont un bon exemple. Devons-nous en parler dans le chapitre sur les réglages du serveur ou dans celui où nous montrons comment interpréter les variables de statut ? Ils auraient leur place dans chacun des deux chapitres et nous n'avons finalement pu éviter quelques recouvrements. Régler ce problème nous a demandé beaucoup de travail. Je ne sais pas comment l'atténuer, à part grâce une bonne vue du plan, ce qui manque dans OO.org.

Des recherches approfondies ont souvent été nécessaires. Parfois, un coup d'œil au manuel MySQL (qui n'est pas toujours juste, donc tout devait être vérifié) était suffisant. Mais nous avons aussi souvent dû lire le code source ou contacter l'auteur d'un programme. A l'occasion nous devions également lancer de longs tests ou des tests de performance.

Ce que j'en retiens ? Les recherches peuvent être interminables. Vous essayez de comprendre quelque chose, vous attendez la réponse d'un pauvre programmeur qui reçoit des milliers d'e-mails... ça n'en finit jamais.

Voici un exemple : qu'est-ce que avgrq-sz signifie réellement dans iostat ? L'explication du manuel est plutôt déroutante, elle le définit comme étant "La taille moyenne (en secteurs) des requêtes qui ont été envoyées au périphérique." Pour découvrir ce que cela signifie réellement j'ai dû lire les sources de iostat, les sources du noyau et la documentation du noyau. Cela m'a pris beaucoup de temps. Puis j'ai pu confirmer mes découvertes auprès de l'auteur de iostat.

Nous avons effectué beaucoup de recherches sur les fonctionnalités avancées de MySQL, comme les procédures stockées, le cache de requêtes, etc. Et beaucoup (beaucoup !) dans InnoDB. Nous voulions particulièrement apprendre comment ces fonctionnalités interagissent entre elles. Par exemple, comment InnoDB interagit avec le cache de requêtes ? La documentation à ce sujet est muette. Nous avancions très lentement.

Nous avons aussi réalisé beaucoup de tests de performances. Les tests de performances sont très gourmands en temps également.

Prévoyez d'allouer plus de temps à la recherche que vous ne le pensiez initialement. Jay Pipes m'a dit de prévoir d'avancer au rythme d'environ une demi-page par jour et cela me semble raisonnable lorsque vous devez vérifier la majeure partie des informations contenues dans une page.

Écrire clairement

Travailler avec l'éditeur a été une expérience enrichissante. Je savais que mon écriture était (et est toujours) largement perfectible, mais je ne savais pas quels étaient mes plus gros défauts. J'étais fermement décidé à ce que ce livre soit clair et facile à comprendre, pas facile à faire quand il s'agit d'un livre vraiment pointu et complexe, mais c'est alors plus important encore.

J'ai créé par conséquent un ensemble d'heuristiques pour m'aider à repérer les passages pouvant poser problème. L'outil n'était pas parfait mais il m'a beaucoup aidé. J'ai créé un fichier texte avec des expressions fréquentes afin les dénicher dans le texte. Une fois ces expressions identifiées je réfléchissais à une meilleure formulation.

   Things belong in multiple places, but they can only go in one place.

   Things belong in multiple places, but they can go in only one place.

Le mot "seulement" en est un bon exemple. J'ai le défaut de mal l'employer et je n'en étais pas conscient. Les corrections fréquentes d'Andy ont fait ressortir mes faiblesses et j'ai ajouté le mot "seulement" à mon fichier d'expressions fréquentes. Voici un exemple de ma mauvaise utilisation de ce mot :

Certains passages auraient leur place à plusieurs endroits du livre, mais ils peuvent seulement apparaître une fois.

(Hmmm, c'est une phrase que j'ai écrite dans ce post !) La phrase correcte aurait été :

Certains passages auraient leur place à plusieurs endroits du livre, mais ils ne peuvent apparaître qu'une seule fois.

Passive voice:

 (were|was|is|are|has been|be)( [a-zA-Z]+)? [a-zA-Z]+ed\>

 Repeated words:

 \<([a-zA-Z]+) +\1\>

 Confusing possessives:

 the ([a-zA-Z]+) of the

 Things to look out for:

 while|since|\<using|in order|of course|whether|allow|ensure|only|as (we|you)|without saying|obviously|clearly|needless|again,

 Finding pseudo-cross-references:

 ((Figure|Table) [0-9])|TODO|XREF|MARK_

 An awkward phrase that showed up a lot:

 \<by [a-zA-Z]+ing\>

A la fin, mon fichier d'expressions régulières ressemblait à cela:

Voie passive:

 (were|was|is|are|has been|be)( [a-zA-Z]+)? [a-zA-Z]+ed\>

Mots répétés:

 \<([a-zA-Z]+) +\1\>

Confusion de possessif:

 the ([a-zA-Z]+) of the

Choses à chercher:

 while|since|\<using|in order|of course|whether|allow|ensure|only|as (we|you)|without saying|obviously|clearly|needless|again,

Chercher des pseudo-références-croisées :

 ((Figure|Table) [0-9])|TODO|XREF|MARK_

Une expression bizarre qui apparaît souvent :

 \<by [a-zA-Z]+ing\>

Ces expressions m'ont aidé à corriger des constructions comme "la maison qui appartient à Jean", qui peut se dire de manière plus concise : "la maison de Jean". Ou encore, une expression fréquente dans le contenu que nous avons conservé : "En utilisant mysqldump, vous pouvez décharger les données" devient "Vous pouvez décharger les données avec mysqldump" (Grâce à la dernière ligne du fichier je peux détecter ce genre de "lourdeur"). Je souhaitais que mes phrases soient simples et claires : "qui fait quoi pour faire quoi". C'est un bon test à mon avis, si vous ne pouvez pas répondre à ces questions après avoir lu une phrase c'est qu'elle n'est pas suffisamment claire. J'ai essayé d'utiliser des mots plus courts lorsque c'était possible : "donner la possibilité de" peut souvent être remplacé par "permettre", et comme bonus, cela transforme souvent une expression en un seul mot : "Ces réglages vous donnent la possibilité de..." devient "Ces réglages vous permettent de..."

Des expressions comme "bien sûr" m'indiquent en général que j'ai été paresseux. "Bien sûr" veut en fait dire "c'est évident, mais je le dis quand même". Alors pourquoi l'écrire ? Mais le plus souvent "bien sûr" est un raccourci pour dire "Je crois cela, mais je ne sais pas pourquoi, et c'est difficile à expliquer, alors je laisse juste entendre que c'est évident et que vous ne devriez pas me demander de l'expliquer". Beaucoup d'autres expressions dans ma liste relèvent simplement de mauvaises habitudes que j'ai acquises. J'utilise par exemple beaucoup "afin de" alors qu'il est plus court de dire "pour".

Mon père m'a fait remarquer mon penchant pour les doubles négations "N'y a-t-il pas quelqu'un ?" devrait en faite se dire "N'y a-t-il personne ?". Parfois j'en faisais trop et je m'emmêlais les pinceaux, le correcteur devait alors démêler mes contres-sens.

La voie passive est absolument à proscrire, elle trouble le lecteur. Même si celui-ci ne s'en rend pas forcément compte, sa compréhension et ce qu'il retient s'en trouvent affectés. Voici un exemple que j'ai trouvé grâce à mon expression régulière : "Pour certaines organisations, ce problème est résolu par une combinaison de" devient "Certaines organisations résolvent ce problème par une combinaison de". Lorsque la voie passive est utilisé par l'auteur la clarté des phrases est dégradée comme rarement (Vous êtes censé rire).

Même si vous croyez bien écrire, préparez-vous à mettre votre égo de côté. Un éditeur parviendra toujours à améliorer votre production.

Après avoir appliqué mes heuristiques pour m'aider à trouver mes points faibles, j'ai jugé que je pouvais faire encore mieux. Je suis programmeur Perl, pas vrai ? Exact. J'ai donc récupéré quelques modules sur CPAN, écrit un petit programme qui extrait le texte des fichiers et le nettoie un peu, puis qui effectue une analyse des phrases dans les fichiers. J'ai utilisé plusieurs métriques standards de lisibilité pour analyser les phrases individuellement et les paragraphes entiers ; Flog, Flesch, et Flesh-Kincaid. Mais ils n'étaient pas suffisamment bons et l'algorithme de césure n'était pas suffisamment au point pour mesurer correctement le nombre de syllabes. Je me suis donc tourné vers le système ultime pour faire des césures dans la langue anglaise : TeX. Il intègre des règles de césures de façon extrêmement juste, avec toutes sortes de cas particuliers. ("Les thé-rapeutes qui prêc-hent la nu-it" est un exemple classique de mauvaise césure.) J'ai découpé les phrases en syllabes avec un programme personnalisé pour connecter Perl aux routines de césure de TeX à travers un autre module CPAN, puis j'ai classé les phrases et les paragraphes par nombre de syllabes. J'ai ensuite combiné toutes ces métriques et j'ai créé un rapport indiquant quelles étaient les pires parties. Je me suis alors penché sur les 30 phrases obtenant le plus mauvais score. J'ai ainsi détecté beaucoup de problèmes.

Ce travail s'est révélé essentiel. Il m'a aidé à renouveler mon point de vue sur ce texte que je contemplais depuis des mois et j'ai vraiment pu y déceler les passages de moins bonne qualité. Mais ce n'était pas encore suffisant. Je vous en dirai plus dans la prochaine partie.

Du concept à la réalisation

Le processus détaillé pour qu'un chapitre puisse être envoyé à la revue technique ressemble à ça :

• Faire le plan
• Refaire le plan
• Remplir le plan
• Faire un premier jet
• L'envoyer aux autres auteurs pour relecture
• Corriger
• Envoyer à l'éditeur
• Corriger
• Répéter, répéter, répéter ...

C'est en gros ce qu'il faut faire pour réussir à obtenir un manuscrit prêt à être envoyé à la revue technique. Chaque chapitre a été inspecté par l'éditeur ou son adjoint au moins trois fois avant d'être revu par Peter au moins une ou deux fois. Les relectures de Peter étaient exhaustives (et exténuantes) et elles nous ont parfois donné beaucoup de fil à retordre car nous ne savions pas toujours comment les intégrer. Souvent nous n'allions pas assez dans les détails pour lui et il nous fallait alors ré-écrire certaines parties ou définir un nouveau plan (vous voyez quand je vous disais qu'il faut détailler vraiment méticuleusement le plan avant de commencer à rédiger ?). Chacune de ces étapes prenait également beaucoup de temps, car ça demandait aussi beaucoup de travail à Peter. Il faisait tout en même temps : beaucoup de conseil sur site, le déménagement de toute sa famille aux États-Unis et ce tout continuant à faire tourner Percona. Honnêtement, je ne sais pas comment il a réussi.

À la "fin" de ce processus, les chapitres étaient raisonnablement complets au niveau des fonctionnalités mais de larges sections étaient marquées du tampon "A FAIRE", car en attente d'un des auteurs, d'un appel à Heikki ou à quelqu'un d'autre (ce que nous appelions un "appel au réseau de connaissances externes") ou d'un test de performance. Pourtant, il fallait bien que les choses aillent à la revue technique à un moment ou à un autre. À ce moment-là, le processus était le suivant :

• Envoyer à la revue technique
• Continuer à travailler
• Recevoir des commentaires
• Corriger, attendre, attendre, attendre
• Recevoir des commentaires d'un autre relecteur, corriger de nouveau et recommencer jusqu'à ce que ce soit terminé

Chacun a une vie bien remplie et nous n'avons pas pu envoyer les premiers chapitres à la relecture technique avant les vacances, le pire moment pour demander à quelqu'un de se lancer dans la relecture. Et il y avait tant à faire que je ne pouvais pas attendre que tous les retours de la relecture technique reviennent pour commencer à corriger. En conséquence, je recevais des commentaires de Sheeri et je devais les mettre en accord avec les modifications que j'avais effectuées d'après les observations de Roland et alors les commentaires de Pascal arrivaient et je me retrouvais à 2h du matin à me demander : "Mais pourquoi est-ce qu'il me dit ça ! Je l'ai déjà corrigé !". Cette réaction était causée par mon état de fatigue et par le temps passé à travailler sur ce livre, elle n'était pas liée à l'estime que j'accordais à Pascal.

Nous n'avons pas clairement indiqué aux relecteurs qu'ils étaient censés relire, pas faire de l'édition. J'essaierai de ne pas répéter cette erreur. Certains des relecteurs ont passé beaucoup de temps à corriger la grammaire et le style. Malheureusement ils perdaient leur temps, le contenu était de trop mauvaise qualité pour que l'on se préoccupe du style et de la grammaire (et le style est la responsabilité de l'auteur et de l'éditeur, pas celle des relecteurs techniques). Et comme il est impossible de fusionner les changements de chacun des 5 relecteurs je ne pouvais pas me contenter d'accepter leurs modifications. J'ai dû ouvrir chaque fichier séparément et faire le travail manuellement à coup d'aller-retours entre leurs versions et la mienne. Les modifications elles-mêmes apportaient beaucoup de compléments qui devaient également être vérifiés ; le moment était vraiment mal choisi pour faire autre chose que de donner un avis d'expert (au niveau de l'organisation générale, par exemple). L'étape de relecture technique consiste simplement à détecter des erreurs factuelles ou des choses qui sont techniquement ambigües ou discutables. Comme vous le verrez, l'étape d'édition intervient bien plus tard.

Après la relecture technique et encore de nombreux cycles d'édition-corrections, les chapitres étaient enfin prêt pour l'impression. Il est impossible de se préparer à la quantité de travail nécessaire pour enfin atteindre cette étape. Il faut dire aussi que nous ne partions pas sur de bonnes bases, je parle du contenu brut de Peter et Vadim, pas de la première édition. Il fallait dépêtrer un fourre tout hexadécimal mêlé à des fragments de blogs, le tout passé au filtre d'un obscurateur. Le paranormal s'en mêlait également : quand je reprenais un chapitre, que j'avais pourtant déjà marqué comme étant prêt pour la production, je retrouvais plein de notes "A FAIRE" qui m'avaient échappé. J'étais certain pourtant d'avoir tout corrigé ! Et souvent cela représentait beaucoup de travail. Je devais donc me résoudre à le ré-ouvrir, à accepter qu'il était encore loin d'être achevé.

Finalement, ils furent achevés. Nous les avons alors tous regroupés et envoyés à la production. Et pour la 99ème fois, j'ai annoncé à tout le monde que le livre était terminé. Comme j'avais tort...

À ce moment, et pour la première fois, je pensais avoir au moins une idée de la suite des évènements. Je savais que le livre passerait par un directeur de production et qu'ensuite il serait entre les mains d'une équipe qui le ferait passer par un programme de composition et qu'il arriverait finalement à l'impression. Mais là encore, personne n'a cru bon de m'informer, malgré mes demandes répétées. Quoi qu'il en soit, c'est toujours plus facile de regarder les choses avec du recul, voici donc la suite des évènements :

• Directeur de production
• Correction
• Retour au directeur de production
• Correction
• Envoi au reste de l'équipe de production

La directrice de production devait juste vérifier l'orthographe et la grammaire, n'est-ce pas ? C'est ce qu'on m'a dit en tout cas. Au lieu de ça, elle a scruté le livre avec tant de minutie que j'avais du mal à le croire. Et elle a proposé des changements majeurs à presque chaque paragraphe du livre. Elle a fait tellement de changements qu'il m'a fallu au moins un jour, parfois deux ou trois, pour corriger chaque chapitre. Cela représentait des semaines de travail que je n'avais pas vu venir, chaque week-end, chaque nuit, tout le temps, exactement comme lorsque j'écrivais. Et ces changements étaient nécessaires. Elle a trouvé chaque petite phrase ambigüe, chaque contradiction entre différentes parties du livre, des accolades fermantes manquantes dans les exemples de code, des paragraphes qui auraient dû se trouver dans d'autres chapitres, des phrases qui avaient besoin d'être déplacées, des virgules mal placées et beaucoup d'autres choses encore. Une machine d'édition parfaite. Voici un exemple :

Et n'oubliez pas que le rédacteur et le rédacteur adjoint avaient déjà parcouru environ cinq fois tout le contenu. Je ne m'attendais pas à autant de corrections à ce moment-là ; je pensais qu'il suffirait de corriger quelques virgules et apostrophes mal placées.

Elle a repris le livre tout entier avec cette minutie (ce n'est pas une section particulièrement annotée ci-dessus, mais elle est représentative). Ses remarques ont été bénéfiques, mais que de travail supplémentaire par rapport à ce que je pensais devoir faire à cette étape !

Un autre fait aggravant était que le processus d'édition en production utilisait Microsoft Word. Je n'ai pas et je n'utilise pas Word. Cela aurait pu être sans importance, mais comme je l'ai déjà mentionné, la gestion des commentaires et des corrections est plutôt limitée dans OO.org. L'éditrice utilisait énormément les balises de commentaires pour expliciter ses questions. C'est précisément l'un des points faibles d'OO.org. J'ai donc fini par utiliser le portable de ma femme, qui a Word, pour corriger les fichiers. Cela m'a rappelé combien Word peut être bogué, je dirai même plus bogué que OO.org. Word a planté je ne sais combien de fois et les problèmes d'affichage et de formatage étaient tout simplement ridicules. Parfois des pages entières étaient perdues ou mélangées. Arrivé en fin de page, au milieu d'un paragraphe, en passant à la page suivante je me retrouvais avec un morceau de texte qui aurait dû se trouver bien plus loin dans le livre. En cliquant quelque part pour insérer une note ou éditer un changement le logiciel se mettait à paniquer et me renvoyait au début du fichier ; d'autres fois il plantait tout simplement. Tout ceci a rendu le processus beaucoup plus lent qu'il n'aurait dû l'être. Je n'en démordrai pas, un traitement de texte n'est absolument pas adapté à la rédaction d'un livre.

Mais finalement, je m'en suis sorti. Et alors, après tout cela, j'en avais vraiment fini. Vraiment ? Euh, non. À ce moment, j'ai enfin reçu le planning réel des étapes restantes.

• Révisions
• Relecture des révisions
• Inclusion des révisions
• Conversion
• Vérification des sources
• Lancement
• Contrôle Qualité 1 (QC1) / Correction des épreuves
• Création de l'index
• Inclusion des corrections issues de QC1 / Découpage en page
• Copie de la 4ème de couverture pour la Production/Conception
• QC2
• Inclusion des corrections issues de QC2
• Révision de l'index
• Estimation des pages : terminée
• Index final : terminé
• Envoi de la couverture à l'impression
• Ultime Contrôle Qualité
• Envoi du livre à l'impression
• Sortie du livre
• Sortie en magasin

Tout n'était plus de mon ressort, mais je devais rester impliqué dans de nombreuses étapes et tout cela s'est enchaîné en l'espace de quelques semaines. Devinez combien de ces étapes m'ont demandé beaucoup de travail.

Indice : à la cérémonie de remise des diplômes de mon frère je relisais encore l'index pour essayer de ne pas retarder davantage encore le planning. Et j'ai passé mes week-ends et mes soirées à corriger les épreuves et à m'assurer que tout était converti correctement pour la mise en page finale.

Et nous n'étions pas au bout de nos peines. L'illustrateur n'a commencé à dessiner les illustrations qu'après que les étapes de copie de production et de contrôle de qualité listées ci-dessus ont été achevées. Cela veut dire que, contrairement au texte, les illustrations n'ont pas subi 10 à 15 cycles de corrections, commentaires et améliorations. Cela a vraiment été fait à la dernière minute. Heureusement, l'illustrateur a été capable de faire un travail impressionnant à partir de pas grand-chose. Malheureusement, cela signifie aussi qu'une ou deux illustrations n'étaient pas géniales à mon goût, même s'il s'agissait de dessins vraiment professionnels. Je parle du contenu des illustrations, pas de la façon dont elles étaient dessinées. J'aurais aimé que certaines illustrations présentent les concepts plus clairement. J'ai essayé d'utiliser les illustrations pour montrer ce que le texte ne pouvait pas décrire convenablement ; une ou deux de ces illustrations auraient pu être meilleures. Hélas.

Le planning n'a pas été défini au départ, notre seul repère était l'objectif inaccessible d'envoyer le livre à la relecture technique en octobre. Sur cette partie je me montrerai un peu plus critique. Non pas que j'en veuille à qui que ce soit, mais je veux rendre compte de ce qui s'est mal passé.

Pour m'aider à comprendre le déroulement de la rédaction de ce livre j'ai posé beaucoup de questions à O'Reilly (c'est pour cela que j'écris tout ceci pour vous, au cas où personne ne vous le dirait non plus). C'était comme s'ils n'avaient jamais aidé personne à écrire un livre et qu'ils n'avaient aucune idée eux-mêmes de ce que ça impliquait. En conséquence, je n'avais aucun moyen de savoir ce qui était réaliste, ni évidemment que le planning était voué à l'échec. Les échéances ont été repoussées, repoussées et encore repoussées. A novembre, puis décembre, puis février et au final beaucoup plus loin. Chaque fois l'éditeur me disait qu'il pensait que nous étions dans les temps pour tenir le planning. Rappelez-vous, je ne savais pas si je devais le croire ou non. La quantité de travail à fournir m'étonnait chaque jour un peu plus : quand je pensais enfin voir le bout du tunnel, je découvrais en fait que j'en étais encore bien loin.

À vrai dire, je pense que tout le monde était scandalisé, y compris l'éditeur. Il ne savait pas que le plan était si peu développé (mais il l'aurait découvert par lui-même s'il avait fait l'effort de s'y intéresser de plus prêt !). À mesure que nous progressions, ce qui n'était au départ que des petits tirets s'étoffait : un paragraphe, une page voire une section. Le contrat initial prévoyait 384 pages ; finalement le livre en compte plus de 700 (et nous avons dû sacrifier pas mal de passages pour pouvoir le finir). En comparaison, je crois que le premier livre faisait 236 pages. Nous ne pensions pas qu'il deviendrait si gros.

Et encore, nous aurions pu faire bien mieux. J'ai par exemple demandé à l'éditeur d'envoyer les illustrations du chapitre 2 à l'artiste en février puis j'ai re-demandé et re-re-demandé. Il ne l'a pas fait et elles ont été faites à la dernière minute. J'ai demandé, re-demandé et re-re-demandé un contrat contre-signé. Je l'ai finalement obtenu environ six mois après, après l'avoir demandé peut-être douze ou quinze fois. Les avances étaient en retard, elles aussi. Plusieurs exemples relèvent d'une mauvaise gestion de projet du côté de O'Reilly. Il m'est apparu que l'éditeur était surchargé de travail. J'ai essayé de pallier à ça en faisant le boulot moi-même, mais vous devez savoir en quoi consiste le projet avant de pouvoir le gérer.

Le 20 décembre, l'éditeur m'a tenu les propos suivants : "Je veux ce livre à l'impression pour début février". Le 10 janvier : "Nous devons pouvoir lancer l'impression à la fin de ce mois." Le 17 janvier : "Il est possible que le livre ne soit pas imprimé pour la conférence MySQL. Comme je vous en ai déjà fait part, cette période n'est pas très chargée pour l'imprimerie, mais là, les délais sont vraiment très courts. Mais ne vous en faites pas si le livre n'est pas présent à la conférence : il le sera à Velocity, qui y est directement lié, et à l'OSCon."

Vous parlez d'une surprise ! En l'espace de 7 jours, le discours a complètement changé. Puis quelques jours plus tard, nous avons reçu un e-mail nous informant qu'O'Reilly avaient un paquet de titres en production auxquels ils ne s'attendaient pas et qu'ils ne seraient pas capable de s'occuper du notre avant longtemps. Sérieusement, comment pouvez-vous ne pas anticiper la mise en production de plusieurs livres, alors qu'ils étaient en cours depuis des mois voire des années ? J'en ai conclu qu'aucun de leurs titres ne bénéficie d'une bonne gestion de projet.

Soyons clair : ce n'est pas à cause de l'éditeur que le livre n'est pas sorti plus tôt. Un livre est comme un bébé: il est fini quand il est fini, pas avant. Ce que je veux dire par là c'est qu'à aucun moment du processus je n'ai eu la moindre idée de la distance nous séparant du but, et ce n'est pas faute d'avoir vraiment essayé de me renseigner.

Il m'arrivait d'aborder des sujets vraiment basiques lors de conversations avec l'éditeur, comme le nombre de pages atteint : il paraissait complètement surpris bien que je lui fournissais régulièrement un fichier avec la table des chapitres et le nombre de pages correspondantes. En mars, j'ai même reçu des e-mails qui disaient "Comme le nombre de pages est un peu supérieur à ce qui était attendu..." et puis "Vous avez raison à propos du nombre de pages ! Le réviseur m'a dit que les fichiers Word atteignent 600 pages sans la préface, l'index, l'avant-propos, etc." Je ne sais pas où sont passés tous mes e-mails mais il semble que tout ce que je leur disais atterrissait dans /dev/null. Ils étaient complètement largués sur l'état d'avancement du livre, mais ce n'était pas dû à un manque de communication de ma part.

Le choix des relecteurs techniques fut également source de frustration. Cette responsabilité n'a jamais été clairement définie. Je pensais (et je le crois encore) que c'était la responsabilité de la maison d'édition. J'ai demandé très tôt qu'ils trouvent des gens pour cela, mais ma requête est restée lettre morte. J'ai donc demandé encore et encore ; j'ai proposé une liste de personnes ; j'ai demandé à l'éditeur de les contacter ; je les ai contactés moi-même ; personne ne voulait décider à qui nous ferions appel ; j'ai finalement pris une décision et j'ai dit "OK, ces personnes X, Y et Z sont celles que je veux". Puis ensuite, j'ai attendu et après quelque temps, j'ai demandé où on en était sur ce sujet. J'ai reçu la réponse suivante : "peut-être que nous devrions discuter des personnes à qui nous voulons demander d'être relecteurs techniques". Plutôt frustrant, mais en fin de compte les chapitres étaient prêts, il fallait donc les envoyer aux relecteurs.

La maison d'édition a alors envoyé les chapitres à la liste des relecteurs techniques, mais apparemment sans leur avoir demandé s'ils allaient/pouvaient faire le travail. L'un d'eux, excédé, m'a écrit pour me demander ce qu'il se passait car il ne pouvait pas le faire à ce moment-là, il était trop occupé. J'en suis arrivé à devoir m'excuser auprès de certains de mes amis, parce que quelqu'un d'autre n'avait pas fait son boulot. J'en ai discuté avec d'autres auteurs et ils m'ont dit que leur maison d'édition sélectionnait les relecteurs techniques avant même que le projet ne commence et qu'ils n'avaient pas à s'en occuper eux-mêmes. Ce n'est pas ce qui s'est passé pour moi.

Retour au planning : au bout du compte, j'ai décidé de prendre le temps nécessaire et que toutes les prévisions que je recevais de la part de O'Reilly n'étaient que des prédictions. Mais j'aurai apprécié avoir une idée plus précise de ce dans quoi je me lançais. C'est à cela que servent l'expérience et la sagesse de l'éditeur, pas vrai ?

Combien de temps cela a pris ?

01 	27.83
02 	42.75
03 	84.28
04 	55.33
05 	69.42
06 	56.33
07 	36.67
08 	67.4
09 	48
10 	11.47
11 	64.22
12 	15.18
13 	30.07
14 	17.15
A 	0.97
B 	11.8
C 	11.67
D 	5
general 	143.22

J'ai utilisé Toogl pour mesurer le temps passé sur le livre. Je dirai que j'ai saisi environ 3/4 du temps passé dessus. J'ai mesuré le temps passé par chapitre. J'ai enregistré un peu moins de 800 heures de travail sur le livre ; cela fait donc au moins 1000 heures pour prendre en compte le temps que je n'ai pas mesuré correctement. C'est en gros équivalent à 6 mois de travail à temps plein. Voici une décomposition succincte des heures que j'ai réellement enregistrées pour chaque tâche/chapitre :

01 	27.83
02 	42.75
03 	84.28
04 	55.33
05 	69.42
06 	56.33
07 	36.67
08 	67.4
09 	48
10 	11.47
11 	64.22
12 	15.18
13 	30.07
14 	17.15
A 	0.97
B 	11.8
C 	11.67
D 	5
général 	143.22

J'ai donc fait mon travail habituel à mi-temps pendant plusieurs mois. C'est à dire que je travaillais, en théorie, 20 heures par semaine (mais probablement plutôt 50) sur le livre. Le reste du temps, je l'ai pris sur mes soirées et mes week-ends.

Ça prend beaucoup de temps, il n'y a pas moyen d'y échapper.

Beaucoup de choses m'ont surprises dans ce livre. Par exemple, les références croisées. J'ai essayé et essayé, mais je n'ai pas trouvé de moyen de les créer automatiquement. Au sein d'un même chapitre, pas de problème ; mais pas entre chapitres (est-ce que j'ai déjà mentionné que j'aurai aimé écrire en LaTeX ?). Cela veut donc dire que j'ai dû mettre en place une procédure pour les gérer et mettre un mot magique XREF dans le texte, comme ceci : "Voir le chapitre 10 pour plus d'information à ce propos. (XREF: optimisation de l'application)". Au final, rien n'était numéroté ni référencé automatiquement ; chaque référence croisée, illustration et table devait être vérifiée manuellement. Et à un moment, nous avons re-numéroté les chapitres, il a donc fallu tout recommencer, que de temps et d'efforts gâchés... Mais je ne voyais pas comment faire autrement ; il était trop tard pour arranger les choses.

Si vous envisagez d'écrire un livre, je vous conseillerais d'estimer au préalable le temps que cela va réellement vous prendre. Vous pouvez utiliser mon ratio nombre d'heures/page comme indicateur approximatif si vous le désirez, mais soyez conscient que a) je n'étais pas le seul auteur, donc le livre a représenté beaucoup plus que ces 1000 heures de travail et b) je suis peut-être un écrivain plus rapide que vous. N'essayez pas de faire une estimation à l'intuition, à moins que vous n'ayez écrit un livre auparavant. Un livre de 200 pages prendra beaucoup plus que deux fois le temps nécessaire à l'écriture d'un livre de 100 pages. Il existe une relation non-linéaire entre le nombre de pages et le travail nécessaire. Et les pages qui iront à l'impression nécessiteront beaucoup plus travail que pour votre thèse ou votre mémoire, croyez-moi. Quoiqu'il en soit, peu importe comment vous vous y prenez, essayez d'avoir une idée du nombre d'heures qui vous seront nécessaires. Visualisez maintenant mentalement où vous trouverez ces heures. Combien de temps pensez-vous vraiment pouvoir y consacrer les soirs et les week-ends ? N'oubliez pas que vous aurez encore à vous occuper des choses du quotidien comme payer les factures et laver la vaisselle.

Disposez-vous un endroit tranquille, isolé de toute distraction où vous pouvez travailler ? Ne soyez pas étonné de perdre 15 à 30 minutes chaque fois que vous serez interrompu. Ça peut paraître beaucoup, mais vous verrez que si vous êtes dérangés en pleine concentration vous vous montrerez rapidement irritable et impatient, c'est vrai pour moi en tout cas, et cette sensation est aussi déstabilisatrice que l'interruption elle-même : "Connais-toi toi-même". En fin de compte, je pense que l'état d'esprit de l'auteur influe grandement sur la vitesse d'écriture d'un livre.

Mais alors, pourquoi est-ce que je l'ai fait ?

Après tout ce travail, je plaisante souvent en disant que ce livre va probablement me rapporter des centaines de dollars. Récemment, j'ai fait quelques calculs approximatifs et j'ai découvert que ça allait me rembourser les avances sur droit d'auteur plus rapidement que ce que je ne pensais, mais je ne suis quand même pas près de gagner suffisamment d'argent grâce à mes droits d'auteur pour payer convenablement mon temps de travail. Je pense que si vous considérez le temps que j'y ai passé, j'ai travaillé pour moins que le salaire minimum. Quoiqu'il en soit, il ne s'agit pas de devenir riche ou d'entrer dans la liste des best-seller du New York Times.

Pour moi, ce livre était une chance de faire quelque chose que j'aime, écrire, et de partager/enseigner ce que je sais, ce qui est à mon avis une bonne chose à faire. Je me suis entrouvert une porte aussi ; si jamais l'envie d'écrire me prend à nouveau, je saurai à quoi m'attendre et j'espère pouvoir employer mon expérience à bon escient pour me faciliter les choses et pour négocier plus fermement en ma faveur. Mon nom devient connu et peut-être qu'il attirera des clients à mon cabinet de conseil. Tout cela est théorique bien sûr ; plus le livre se vend, plus il est probable que ces bonnes choses se produisent.

Ces jours-ci, puisque je suis un consultant très demandé, je considère aussi le livre comme un moyen d'aider les gens à s'aider eux-mêmes. J'ai bien trop de travail, mais les gens qui achètent et lisent ce livre recevront des conseils valant des milliers de dollars pour très peu d'argent. En d'autres termes, il propose une alternative aux personnes qui ont du temps mais pas d'argent. Ainsi, je peux me consacrer à ceux qui ont de l'argent mais pas de temps.

Conclusions

Cela a été un projet long et difficile qui m'a vraiment ouvert les yeux sur beaucoup de choses. Je savais un peu dans quoi je m'engageais, mais j'avais quand même des attentes irréalistes. Beaucoup d'expériences ont été enrichissantes, des expérience que je n'avais pas anticipées, surtout dans les domaines des compétences interpersonnelles, les gens ne se conformant pas nécessairement à ma conception idiote de ce qu'ils "devaient" faire. Le processus a été gratifiant et je le recommencerai ; mais pas tout de suite. Les gens qui ont vraiment dû encaisser sont ceux que j'ai privés de moments privilégiés, comme ma femme, ma famille et mes amis d'escalade ainsi que mon chef et mes collègues de travail.

Mais surtout je n'étais pas préparé au temps que ça allait me prendre. J'en ai suffisamment parlé.

Si j'écris un autre livre à l'avenir, je pense que je serai mieux préparé à ce qui m'attend et j'essaierai d'être sûr que cela se passe suivant mes conditions, pour pouvoir être le plus productif possible (par exemple, ne pas écrire un livre avec un traitement de texte). Je pense que cela est raisonnable car l'auteur réalise la plus grande part du travail, le processus doit donc clairement favoriser l'auteur. Enfin, je ferai attention à ce que les responsabilités et les plannings soient clairement et intelligemment définis. Tout ne peut pas être planifié parfaitement, mais au moins définir les étapes, qui les réalisera et, dans la mesure du possible, quand (beaucoup d'étapes peuvent être planifiées par rapport à la réalisation de tâches planifiées de façon imprécises, comme "lorsque les corrections de la relecture technique seront intégrées, l'éditeur réalisera la version éditée sous 14 jours"), et tout ceci sera couché noir sur blanc sur un papier avec une signature tout en bas.

À ceux qui envisagent d'écrire un livre : je vous encourage à le faire. J'espère que mes réflexions vous auront été utiles et que votre livre se finira bien.