Corriger, actualiser et maintenir son ebook

Master Prompt associé : MP34, exploiter les retours et préparer une nouvelle version.

Résultat attendu

Après ce guide, vous savez recueillir un retour après publication, le prioriser correctement, distinguer une simple coquille d’un changement majeur, tenir un journal des modifications complet, et remplacer proprement les fichiers distribués sans laisser une ancienne version accessible par erreur.

Le résultat est une nouvelle version corrigée, avec son journal de modifications complet et l’ancienne version archivée.

Ce qu’il faut avoir sous la main

Votre version publiée en G32, et un retour, réel ou simulé, qui signale un défaut ou une information devenue obsolète.

Un ebook publié n’est pas un objet figé

Une fois publié, un ebook continue d’exister dans le temps : une information peut devenir obsolète, une coquille peut être signalée par un lecteur, une méthode peut nécessiter une précision qui n’était pas évidente au moment de la rédaction. Traiter la publication comme un point final, sans prévoir de maintenance, expose l’ouvrage à vieillir silencieusement, sans que personne ne corrige ce qui doit l’être.

Quatre catégories de modification, quatre traitements différents

La coquille. Une erreur de forme sans conséquence sur le fond : une faute de frappe, un espace mal placé. Elle peut être corrigée rapidement, sans réexamen approfondi du passage concerné.

L’amélioration. Une clarification qui rend un passage plus compréhensible sans changer ce qu’il affirme. Elle mérite une vérification que la nouvelle formulation reste fidèle au sens d’origine.

L’information devenue obsolète. Un fait exact au moment de la rédaction mais qui a changé depuis, par exemple une référence à un outil ou une règle qui a évolué. Elle demande une recherche pour vérifier l’état actuel de l’information, avec la même rigueur que lors du fact-checking initial de G22.

Le changement majeur. Une correction qui modifie significativement une méthode, une recommandation, ou une partie substantielle du contenu. Il nécessite une nouvelle édition clairement identifiée, pas une simple retouche silencieuse, pour que les lecteurs de l’ancienne version comprennent qu’un changement important a eu lieu.

Confondre ces catégories conduit à deux excès symétriques : traiter une coquille comme s’il fallait rouvrir tout un chapitre, ou traiter un changement majeur comme une simple coquille pour éviter le travail d’une nouvelle édition.

Recueillir et prioriser un retour après publication

Un retour de lecteur après publication se traite avec la même rigueur que les retours de test déjà pratiqués en G21 : distinguer un blocage observé d’une préférence, avant de décider d’une correction. Un retour qui signale une erreur factuelle vérifiable mérite une priorité différente d’un retour qui exprime simplement une préférence de style.

Tenir un journal des modifications complet

Chaque modification apportée à l’ebook après sa publication doit être consignée dans un journal, avec les champs suivants : la version concernée, la date de la modification, la source du signalement (qui l’a repéré, ou quelle vérification l’a révélé), l’affirmation ou le passage concerné, la raison de la modification, son impact (coquille, amélioration, information obsolète, changement majeur), la nouvelle vérification effectuée si nécessaire, la confirmation d’un nouvel export réalisé, et la référence de l’ancienne version archivée.

Ce journal reprend et prolonge la logique déjà pratiquée pour l’identification de version en G30 : chaque version doit rester traçable, avec ce qui a changé et pourquoi.

Remplacer les fichiers distribués sans laisser d’ancienne version accessible

Publier une nouvelle version ne suffit pas si l’ancienne reste accessible par un lien oublié ou un cache non actualisé. Après toute correction, vérifiez que le lien de téléchargement principal pointe bien vers la nouvelle version, en suivant la même méthode de test depuis une session indépendante déjà pratiquée en G32.

L’ancienne version ne doit pas être supprimée sans trace : elle reste archivée, accessible pour vous en cas de besoin (par exemple pour comprendre ce qu’un lecteur ayant téléchargé une version antérieure a réellement lu), mais elle ne doit plus être la version proposée au téléchargement.

Exercice : simuler une erreur signalée, préparer la nouvelle version

Données de départ. Votre version publiée de G32.

Consigne. Simulez un retour de lecteur signalant un défaut, par exemple une information devenue obsolète dans un passage de votre manuscrit. Classez ce retour dans l’une des quatre catégories de ce guide. Préparez la correction correspondante, avec la vérification nécessaire selon sa catégorie. Complétez le journal des modifications. Nommez la nouvelle version et vérifiez que le chemin de téléchargement pointe vers elle, en suivant la méthode de G32.

Production attendue. Le retour simulé et sa catégorisation, la correction préparée, le journal des modifications complété, et la confirmation que le chemin de téléchargement mène à la nouvelle version.

Correction. Un exercice échoue si un changement majeur est traité comme une simple coquille, ou si le journal des modifications omet un champ requis.

Remédiation. Si vous hésitez entre deux catégories pour un retour donné, posez la question suivante : la correction change-t-elle ce que le lecteur comprendrait de la méthode enseignée ? Si oui, il s’agit au minimum d’une amélioration à vérifier, jamais d’une simple coquille.

Employer MP34 pour prioriser, pas pour décider seul de la correction

MP34, exploiter les retours et préparer une nouvelle version, déjà présenté en G21 pour les retours de test, s’applique ici aux retours reçus après publication. Fournissez-lui le retour reçu, la version actuelle, et vos contraintes du moment ; il aide à prioriser et à préparer un plan de correction, sans jamais appliquer la correction lui-même ni requalifier un retour à la baisse ou à la hausse.

Contrôlez que la procédure respecte la catégorie réelle de chaque modification et ne recommande jamais une simple retouche silencieuse pour un changement qui mériterait une nouvelle édition clairement identifiée.

Vérification des acquis

Toute correction après publication demande-t-elle le même niveau de vérification ? Non. Une coquille se corrige rapidement, tandis qu’une information obsolète ou un changement majeur demandent une vérification approfondie.

Un journal des modifications est-il facultatif pour une petite correction ? Non. Chaque modification, même mineure, doit être consignée pour rester traçable.

Une ancienne version doit-elle être supprimée définitivement après une correction ? Non. Elle reste archivée, mais ne doit plus être celle proposée au téléchargement.

• Le retour est correctement classé parmi les quatre catégories de modification.
• Le journal des modifications est complet, avec tous ses champs renseignés.
• Le chemin de téléchargement a été revérifié après la mise à jour.
• L’ancienne version reste archivée sans être accessible comme version principale.

Votre ebook sait maintenant vieillir sans se dégrader silencieusement. G42. Finaliser et défendre son projet ebook va rassembler l’ensemble du parcours dans un projet final complet.