Vous avez un blog qui avance trop lentement, et un modèle de langue qui écrit un article en deux minutes. La tentation est de brancher l'un sur l'autre. J'ai construit ce que j'appelle une machine de contenu IA, et ce que j'en retiens tient en peu de mots : le modèle est la partie facile. Le travail se fait avant qu'il écrive, et dans ce que la relecture humaine garde après.
Ce blog est écrit avec cette machine, et je préfère le dire tout de suite puisque vous vous poseriez sans doute la question. Je décris ici comment la chaîne est organisée, ce qu'elle bloque, où je place la relecture, comment une correction devient une règle, et ce que Google écrit sur le sujet dans sa documentation.
01Ce que j'appelle une machine de contenu
C'est une suite d'étapes, et chacune laisse une trace écrite : un calendrier des sujets, un brief, la rédaction, un contrôle automatique, la publication, la version anglaise, puis un récapitulatif. Une seule de ces cases est confiée au modèle. Le reste ressemble à de la direction de projet : décider ce qu'on publie, pour qui, avec quelles preuves, et vérifier que c'est bien ce qui est en ligne.
Le principe qui tient le tout est simple : l'outil porte ce qui se vérifie, la rédaction garde ce qui se juge. Compter les mots, repérer un chiffre sans source ou un lien mort, c'est le travail d'un programme. Choisir l'angle, juger si un exemple tient debout, c'est le mien.
Le même moteur tourne sur plusieurs sites avec le même découpage. Chez Moonworkers, ma propre entreprise de logiciel de paie, la machine publie deux articles par jour. Les étapes ne changent pas d'un site à l'autre, les règles si : elles vivent dans un fichier de configuration propre à chaque site.
02Ce que Google dit vraiment du contenu écrit avec l'IA
J'entends souvent deux idées opposées : « Google détecte et pénalise l'IA » et « Google s'en moque ». Sa documentation est plus précise que les deux. Dans ses conseils sur le contenu généré par IA, Google écrit que l'IA peut être utile pour faire des recherches sur un sujet et pour structurer un contenu original. Il ajoute que générer beaucoup de pages sans apporter de valeur aux utilisateurs peut enfreindre sa règle sur le contenu de masse.
Cette règle figure dans ses règles relatives au spam : le contenu de masse, ce sont de nombreuses pages produites d'abord pour manipuler le classement, et non pour aider les gens. L'outil n'est pas en cause. L'intention et le résultat le sont.
Deux autres points de la même page m'ont fait changer ma façon de relire. Google rappelle que les modèles ne vont pas chercher des faits, ils prédisent une suite de mots probable, et qu'il faut donc vérifier les faits avant publication. Il précise que cette vérification vaut aussi pour les titres, les méta-descriptions, les données structurées et les textes alternatifs des images. Ce sont justement les champs qu'on oublie de relire, et mon contrôle les relit tous.
Enfin, sa page sur le contenu utile et fiable pose trois questions : qui a écrit, comment, et pourquoi. Elle conseille d'expliquer le recours à l'automatisation quand un lecteur pourrait se demander comment le texte a été produit. D'où la phrase de mon introduction.
03Tout se joue avant que le modèle écrive
Un modèle à qui l'on demande « écris un article sur le recrutement » produit un texte moyen, plausible, sans rien dedans que le lecteur ne trouverait ailleurs. Ce n'est pas un défaut du modèle : on ne lui a rien donné d'autre.
Un brief qui refuse d'avancer
Avant la rédaction, chaque sujet a un fichier de brief, et une commande le valide. Tant qu'il manque quelque chose, elle répond « BRIEF REFUSÉ » avec la liste des manques. Sur ce blog, il faut au minimum :
- un lecteur décrit et une promesse rédigée, pas le texte d'exemple du gabarit ;
- un angle d'au moins 60 caractères, tiré de ce que j'ai réellement fait ;
- trois mots-clés secondaires et quatre questions réelles, chacune avec sa provenance ;
- quatre sources lues, dont deux institutionnelles, chacune avec l'affirmation qu'elle soutient ;
- trois liens internes vers des pages qui existent vraiment.
Le point sur l'angle fait la différence. Il ne peut s'appuyer que sur une liste fermée de faits déjà publiés. Si le sujet demande un vécu qui n'y figure pas, l'article passe « en attente » avec une note pour moi, au lieu d'être écrit. Une anecdote inventée est pire qu'un article sans anecdote.
Limiter le modèle à ce qu'on lui donne
Mon prompt de rédaction n'est pas un long texte libre. Le modèle reçoit, dans l'ordre, les références à lire (la voix, les faits utilisables, la structure, les règles), puis le brief validé, puis des exemples de phrases qui sonnent juste et faux. C'est proche de ce que recommandent Hannah Moran et Christian Ryan, d'Anthropic, dans leur atelier Prompting 101 : la tâche et le rôle d'abord, le contenu fourni, des instructions détaillées, des exemples, puis un rappel final. Ce rappel sert à éviter les hallucinations : ne pas inventer un détail absent des données, et renvoyer à la donnée source à chaque affirmation factuelle.
La documentation d'Anthropic sur la réduction des hallucinations va dans le même sens : autoriser le modèle à dire qu'il ne sait pas, le restreindre aux documents fournis, lui faire appuyer chaque affirmation sur une citation. La même page prévient que ces techniques réduisent les erreurs sans les supprimer. C'est la raison d'être du contrôle qui suit.
04Où placer la relecture humaine
Relire « à la fin » ne suffit pas. Je place trois points de contrôle, parce que chacun attrape des erreurs différentes.
Avant la rédaction : valider le dossier
C'est la relecture la plus courte et celle qui fait gagner le plus de temps. Le sujet mérite-t-il un article ? L'angle repose-t-il sur un fait réel ? Les sources sont-elles sérieuses et lues ? Un dossier faible donne un article à réécrire. Mieux vaut le bloquer à ce stade.
Après la rédaction : le gate, puis mon jugement
Une commande relit l'article contre son brief et rend un verdict rouge, orange ou vert. Un seul rouge bloque : tiret cadratin, « En conclusion », lien externe absent du registre de sources, nom interdit, lien mort. L'orange signale ce qui peut être légitime, un chiffre sans source dans le même paragraphe ou un mot à surveiller, et l'article ne part qu'avec une justification écrite de chaque point. Je relis ensuite la voix : est-ce que ça ressemble à moi, ou à n'importe quel texte généré ?
Après la mise en ligne : regarder comme un visiteur
L'article part en ligne avec le statut « à relire », et je le passe à « Relu » une fois lu sur le site. La vérification se fait sur la page publique, pas dans le formulaire du CMS : un site peut sembler normal à l'équipe connectée et être cassé pour les visiteurs, à cause d'un cache. Je vérifie donc comme un visiteur : la page répond, l'image s'affiche avec son texte alternatif, les liens mènent quelque part. C'est la même logique que la recette avant mise en production.
05Transformer chaque correction en règle écrite
Une correction faite à la main sert une fois. Écrite comme une règle, elle sert à tous les articles suivants.
Sur une mission, une correctrice relisait les articles et renvoyait ses remarques. Plutôt que de corriger texte par texte, j'ai transformé ses retours en règles écrites dans le pipeline. Qu'une remarque faite une fois n'ait plus à être refaite, et que son regard aille vers ce qu'aucune règle ne sait voir.
Ces règles vivent dans la configuration, pas dans le prompt. Une règle rappelée dans un prompt s'oublie ; une règle dans la config bloque. La mienne contient deux listes de tournures : une rouge, pour les formules d'appel et le jargon de consultant qui signent un texte généré, et une orange, pour les adjectifs gonflés, qui devient rouge au-delà de deux occurrences. D'autres règles restent du jugement : un exemple tient-il debout, un conseil est-il honnête ? Pour noter une règle, j'utilise ce format :
``` Règle : ce qui est attendu, en une phrase. Pourquoi : la correction qui l'a fait naître. Contrôle : automatique ou relecture. ```
La ligne « pourquoi » compte. Six mois plus tard, c'est elle qui permet de décider si la règle sert encore. Et quand on modifie les règles, des articles de test volontairement mauvais doivent toujours sortir rouges : sinon, on a affaibli le contrôle sans le voir.
06Ce que la machine ne fait pas bien
Elle ne sait pas ce que vous avez vécu. Sans faits fournis, elle écrit ce que tout le monde écrit, et c'est exactement le type de page que Google décrit comme sans valeur ajoutée.
Elle ne supprime pas le travail humain, elle le déplace. Le temps gagné sur la rédaction part dans la préparation des briefs, la lecture des sources et la relecture. Si personne n'a ce temps, je déconseille de monter une machine : mieux vaut deux articles par mois écrits avec soin que quarante que personne n'a relus.
Elle pousse à forcer. En mode automatique, la pression de finir pousse à inventer une source ou à justifier un orange qu'on ne saurait pas défendre. Ma règle : un article qui ne passe pas honnêtement est abandonné, avec une note, et le sujet revient « à faire ». Je préfère couper un sujet faible que le publier parce que la machine peut le faire.
07Par où commencer
Le goulot d'une production de contenu n'est pas toujours l'écriture. Parfois c'est la mise en ligne, faite à la main. Dans ce cas, j'automatise la publication avant de produire plus. Pour démarrer lundi :
- Listez dix sujets, et pour chacun ce que vous avez vécu dessus. Ceux qui n'ont rien dans la deuxième colonne attendront.
- Écrivez le brief type d'un article, et la commande qui le refuse quand il est incomplet.
- Décidez ce que le contrôle automatique bloque et ce que vous gardez en relecture.
- Après les trois premières corrections, écrivez les trois premières règles.
- Automatisez la mise en ligne et le suivi, par exemple avec un reporting SEO qui part seul, puis seulement augmentez le rythme.
C'est l'une des choses que je mets en place dans mes services d'automatisation et de contenu. Si vous voulez monter la vôtre, on peut en parler.