J'affine mon clone rédactionnel à 80-95 %

Après un premier round de tests à froid, puis une méthode structurée qui a porté la fidélité du clone rédactionnel à 80 %, ce troisième épisode change de registre : au lieu d'un article de blog, la demande porte sur un email de vente. Le résultat révèle une limite importante de la méthode précédente, avant de la corriger.

Pourquoi un clone entraîné sur des articles de blog échoue-t-il sur un email de vente ?

Jusqu'ici, le projet Claude dédié au clone rédactionnel ne contenait que des articles de blog. Sur la demande d'un email de vente classique (puces promesses, plusieurs accroches, appel à l'action), le résultat est mitigé : les accroches proposées sont plutôt bonnes, mais le corps du texte tombe dans un entre-deux bancal. N'ayant aucun exemple de texte de vente dans sa matière, Claude finit par inventer son propre style vendeur générique plutôt que d'imiter fidèlement le style personnel fourni. Les tics reconnaissables reviennent aussitôt.

La leçon est simple mais facile à sous-estimer : une feuille de style ne suffit pas si le matériau de référence ne correspond pas au registre demandé. Un style analysé à partir d'articles de blog ne se transpose pas automatiquement à de la copie de vente, qui obéit à des codes différents (urgence, structure en puces, appel à l'action explicite).

Comment corriger ce décalage de registre sans tout mélanger ?

La tentation évidente serait d'ajouter une sélection d'emails de vente aux fichiers permanents du projet. Mais ajouter ce fichier au projet risquerait de mélanger tous les styles (blog et vente) dans une seule base, avec un résultat confus qui n'imite ni vraiment l'un ni vraiment l'autre.

La solution retenue est plus fine : fournir le fichier d'emails de vente ponctuellement, dans la conversation du rédacteur concerné, avec une consigne du type « inspire-toi de la structure de cet email de vente et mélange-la avec mon style habituel ». Le résultat reste net, parce que les deux sources ne sont jamais mélangées dans la même base permanente : la structure de vente vient du modèle fourni ponctuellement, la voix vient du style personnel déjà installé dans le projet.

Quelle amélioration ce changement apporte-t-il concrètement ?

Nette amélioration sur ce test : des accroches précises, dont l'une, raccourcie et retravaillée, a été utilisée telle quelle pour un email réellement envoyé. Le corps de texte est jugé nettement meilleur, avec très peu de retouches nécessaires. Un seul problème résiduel : une phrase de structure appartenant au script source a fuité dans le texte de vente final, sans y avoir sa place. Point de vigilance à généraliser : toujours vérifier qu'aucun contenu « méta » de la source (une instruction, une référence au format d'origine) ne se glisse dans un texte destiné à un autre usage.

Comment passer de 80 % à 95 % de fidélité ?

La dernière étape reste manuelle : reprendre le texte généré et le retoucher légèrement, suppression des tirets cadratins remplacés par des virgules, fusion des phrases hachées en construction « trois temps » en phrases plus fluides, quelques reformulations personnalisées. Peu de changements suffisent quand le texte de base est déjà proche de la cible.

Les cinq pourcents restants correspondent aux mêmes tics récurrents (tirets, phrases hachées) : plutôt que de les corriger à la main à chaque nouvelle génération, l'étape suivante logique consiste à les bannir directement par consigne dans les instructions du rédacteur, pour ne plus avoir à y revenir.

Un outil plus simple peut-il parfois faire mieux qu'un projet complet ?

NotebookLM, testé en parallèle sur le même exercice (une courte description de module), sans aucun fichier de style ni instruction élaborée, seulement le transcript brut d'une vidéo comme source, donne un résultat jugé « bluffant » et utilisé tel quel, sans modifier un seul caractère. La différence de fond entre les deux outils explique ce résultat : NotebookLM ne s'appuie que sur la source fournie, sans y mélanger de style générique, contrairement à Claude ou ChatGPT, qui ont tendance à injecter leur propre patte stylistique par-dessus la matière fournie.

Conclusion pratique : quand la source elle-même porte déjà la bonne voix (un contenu naturel, parlé, déjà proche du style recherché), un outil qui n'ajoute rien au-delà de cette source peut surpasser une configuration plus lourde. Le choix entre les deux dépend donc moins de la puissance de l'outil que de la nature de la source disponible.

Une astuce transversale à retenir

Demander à ChatGPT de rédiger ou d'améliorer lui-même le prompt qu'on s'apprête à utiliser, plutôt que de rester bloqué sur sa propre formulation : une IA peut souvent mieux cerner et formuler une intention qu'on a du mal à exprimer clairement soi-même.

Deux outils, deux usages complémentaires se dessinent au fil de cette série : un projet complet (matière, feuille de style, rédacteurs dédiés par registre) pour la plupart des formats, et un outil plus léger quand la source elle-même incarne déjà la voix recherchée. Il reste des tics à éliminer : l'exploration continue dans le prochain épisode pour tenter de les faire disparaître par consigne plutôt que par retouche manuelle.

Ce module fait partie de L'Atelier Geekpratique, une bibliothèque de systèmes pratiques mise à jour chaque semaine.