Prompt de rédaction d'article : ce que je donne au modèle,couche par couche

Quand on me montre un prompt de rédaction d'article, il ressemble souvent à ceci : « Agis en tant que rédacteur web SEO. Écris un article de 1 500 mots sur [sujet], avec des H2, une FAQ et une conclusion. » Le texte qui sort est propre, bien découpé, et identique à celui que produit n'importe qui avec la même demande. Il faut ensuite le reprendre presque entièrement.

Ce blog est écrit avec ma machine de contenu, et celle de Moonworkers, mon entreprise, publie deux articles par jour. Je n'y utilise pas de long prompt libre. Le modèle reçoit un dossier à lire, un brief validé, des exemples, et c'est un contrôle automatique qui vérifie ensuite ce qui se mesure. Voici comment je compose ce prompt, couche par couche, avec un modèle que vous pouvez recopier.

01Pourquoi le prompt « rédacteur SEO » donne des textes interchangeables

Un rôle et un sujet ne disent presque rien au modèle. Il ne sait pas qui signe, à qui il parle, ce que vous avez vécu, ni quelles sources ont été lues. Il comble donc avec ce qui est le plus probable. La documentation de Google le formule simplement : les modèles génératifs ne récupèrent pas de faits, ils prédisent une suite de mots probable, d'où les inexactitudes (Google Search Central). Un texte probable est un texte moyen.

Anthropic propose un test tout simple : montrer votre prompt à un collègue qui ne connaît pas la tâche et lui demander de le suivre. S'il est perdu, le modèle le sera aussi (Anthropic, documentation de Claude). Un collègue à qui l'on dit « écris un article SEO sur les prompts » vous poserait dix questions. Le modèle, lui, ne les pose pas : il devine.

Le second problème est plus sournois. Ce qu'il ne sait pas, le modèle l'invente de façon crédible : une anecdote client, un chiffre rond, une citation. Sur un blog signé de mon nom, une anecdote fausse est pire qu'un article sans anecdote.

02Ce que mon modèle lit avant d'écrire

Avant la première ligne, le modèle lit des fichiers de référence. Ce sont toujours les mêmes, et ce sont eux qui font la différence entre deux articles, bien plus que la formulation de la demande.

Les références fixes

• La voix : qui parle, à qui, sur quel ton. Pour moi : première personne, humble, concret, des phrases qu'on dirait à voix haute en réunion.
• La liste fermée des faits utilisables : ce que j'ai fait, sur quels projets, ce qui a raté. Rien en dehors de cette liste. Une autre liste recense les chiffres « à confirmer », qui ne s'utilisent pas.
• La structure d'un article : frontmatter, intertitres, longueur des paragraphes, où vont les liens.
• Les règles : confidentialité (aucun client nommé), humilité, sources.

Le brief validé

Ensuite vient le brief de l'article, sous forme résumée : mot-clé, lecteur, promesse, angle, budget de mots, plan, questions réelles, sources lues avec ce que chacune soutient, liens internes. Ce brief a été validé par une commande qui répond « BRIEF REFUSÉ » tant qu'il manque quelque chose : sur ce blog, au moins 4 questions réelles avec leur provenance, 4 sources lues dont 2 institutionnelles, 3 liens internes. J'en parle plus longuement dans mon article sur la machine de contenu et la relecture humaine.

L'ordre compte. La documentation d'Anthropic conseille de placer les documents longs en haut du prompt et la demande à la fin, ce qui améliore la qualité des réponses jusqu'à 30 % dans leurs tests sur des entrées complexes (Anthropic, documentation de Claude). Je ne mesure pas ce gain sur mes articles, mais j'ai repris l'ordre.

03Le prompt de rédaction, couche par couche

Dans sa conférence « Prompting 101 », l'équipe Applied AI d'Anthropic décrit la structure qu'elle recommande quand on envoie une tâche en un seul message : la tâche et le rôle en tête, puis le contenu, des instructions détaillées pas à pas, des exemples, et à la fin un rappel de ce qui compte le plus. Elle ajoute un contexte de ton : rester factuel, ne pas deviner quand on ne sait pas (Anthropic, Prompting 101, vidéo YouTube). Ma machine suit à peu près ce schéma.

1. Les références, balisées

Je sépare chaque bloc par une balise. La documentation de Claude recommande les balises XML quand un prompt mélange instructions, contexte, exemples et entrées, pour que le modèle ne confonde pas les uns avec les autres (Anthropic, documentation de Claude).

2. Le brief résumé

Le brief arrive juste après, toujours au même format, pour que le modèle le garde sous les yeux pendant la rédaction.

3. Des exemples oui et non

C'est la couche qui m'a le plus servi. Une phrase qui sonne juste, et une qui sonne faux :

• Oui : « Sur une intégration entre un ERP et un site marchand, la spécification a bougé presque à chaque réunion. Je l'ai fait évoluer version après version, pour que tout le monde parle du même document. »
• Non : « Fort de vingt ans d'expérience, j'aide les entreprises à réussir leur virage numérique grâce à une approche unique. »

Anthropic note que les exemples sont l'un des moyens les plus fiables d'orienter le format, le ton et la structure, et en conseille trois à cinq, variés pour que le modèle n'en retienne pas un tic involontaire.

4. La demande, courte, avec ses raisons

La demande vient en dernier, et elle est courte. J'explique le pourquoi des consignes qui restent : la documentation d'Anthropic montre qu'une consigne motivée se généralise mieux qu'un « JAMAIS » en majuscules. Voici le squelette, à adapter. Chaque bloc va entre deux balises, dans cet ordre :

• <voix> : qui parle, à qui, sur quel ton, en dix lignes au plus ;
• <faits_autorises> : la liste fermée de ce que l'auteur a fait, et de ce qui a raté ;
• <structure> : le format du fichier, les intertitres, la longueur des paragraphes ;
• <regles> : confidentialité, humilité, un chiffre égale une source dans le même paragraphe ;
• <brief> : mot-clé, lecteur, promesse, angle, budget, plan, questions, sources lues et leur apport, liens internes ;
• <exemples> : une phrase <oui> qui sonne comme l'auteur, une phrase <non> qui sonne comme une plaquette.

Puis la demande elle-même, en quelques lignes :

⟶ À RETENIRRédige l'article du brief, à la première personne, dans le budget de mots. N'utilise que les faits de <faits_autorises> et les sources du brief : l'article est signé par une vraie personne, une anecdote inventée lui ferait du tort. Si une section demande un vécu absent de la liste, formule-la en général.

Remarquez ce qui n'y est pas : pas de rôle de « rédacteur SEO », pas de liste de mots interdits, pas de nombre de H2. Ces règles existent, mais elles vivent ailleurs.

04Ce que je retire du prompt pour le confier à un contrôle

Une règle rappelée dans un prompt s'oublie. Une règle écrite dans une configuration, et vérifiée par un outil, bloque. C'est le principe qui tient toute ma machine : l'outil porte ce qui se vérifie, la rédaction garde ce qui se juge.

Après la rédaction, une commande relit l'article contre son brief et rend un verdict rouge, orange ou vert. Elle vérifie, entre autres :

1. le budget de mots et le nombre d'intertitres ;
2. une liste de tics d'écriture générée, dont le tiret cadratin et les formules de conclusion toutes faites, qui sont rouges ;
3. la présence de la première personne et d'un ancrage dans la pratique ;
4. les noms de clients et les montants facturés, bloqués partout, titre et FAQ compris ;
5. qu'aucun pourcentage ne traîne sans sa source dans le même paragraphe ;
6. que chaque lien externe figure au registre des sources lues, et que chaque lien interne existe.

Les retirer du prompt a deux effets. Le prompt raccourcit, et le modèle se concentre sur ce qu'on ne peut pas mesurer : l'angle, la justesse, le ton. Et une règle qui ne marche pas se corrige à un seul endroit. Sur une mission, les retours d'une correctrice sont devenus des règles écrites dans la configuration, plutôt que des corrections faites à la main article après article.

Google va dans le même sens. Il demande de vérifier l'exactitude de tout contenu généré avant publication, y compris le titre, la méta-description et les textes alternatifs (Google Search Central). Et ses règles sur le spam visent la production de nombreuses pages sans valeur pour le lecteur, quelle que soit la façon dont elles sont créées (Google Search Central, règles concernant le spam). Le prompt n'est qu'une partie de la réponse.

05Les limites de la méthode

Elle coûte du temps avant le premier article. Écrire la voix, la liste de faits et la configuration demande bien plus de temps que n'importe quel prompt. Pour un article par mois, je ne le ferais pas : un bon brief rempli à la main et une relecture attentive suffisent.

Elle ne crée pas de matière. Si la liste de faits est maigre, les articles le seront aussi, juste mieux écrits. Quand un sujet demande un vécu que je n'ai pas, l'article passe « en attente » au lieu d'être écrit. Les questions d'auto-évaluation de Google le rappellent : le contenu apporte-t-il une analyse originale, une expérience acquise en utilisant le produit ou le service (Google Search Central, contenus utiles) ? Aucun prompt ne fabrique cela.

Et elle ne remplace pas la relecture. Mes articles partent en ligne avec un statut « à relire », et je les relis sur le site. Le contrôle attrape ce qui se mesure ; il ne voit pas qu'un paragraphe est juste mais ennuyeux, ou qu'un exemple tombe à côté. Le goulot se déplace aussi : sur un projet, il n'était pas l'écriture mais la mise en ligne, ce que je raconte dans l'article sur l'automatisation de la publication.

06Par où commencer avec votre prochain article

Inutile de construire une machine pour commencer. Pour le prochain article :

1. écrivez dix lignes sur la voix (qui signe, pour qui, sur quel ton) et gardez-les dans un fichier ;
2. listez ce que vous avez réellement fait sur le sujet, et interdisez au modèle d'en sortir ;
3. lisez trois ou quatre sources vous-même et notez ce que chacune soutient ;
4. ajoutez une phrase oui et une phrase non ;
5. relisez le résultat avec une liste de vérifications écrite, et transformez chaque correction récurrente en règle.

Si vous voulez voir comment je cadre ce type de contenu dans Claude au quotidien, j'en parle dans Claude en marketing. Les projets où j'ai mis cela en place sont dans le portfolio, et la façon dont je travaille est décrite sur la page services. Si votre production de contenu ressemble au premier prompt de cet article, on peut en parler.