Google a effacé jusqu'à 80 % du trafic de sites qui publiaient du contenu IA en masse. C'est le motif scaled content abuse.
On voulait quand même automatiser la production d'articles. La question n'était donc pas « comment produire vite », mais « comment empêcher la machine de publier de la bouillie ».
Voilà l'architecture qu'on a retenue, et le morceau de code qui compte vraiment.
Le pipeline
Six étapes, chacune tenue par un agent Claude Code spécialisé avec son propre contexte :
1. Chasseur → mine les mots-clés (questions réelles, faible concurrence)
2. Cartographe → lit la page 1 Google, relève les questions traitées
3. Rédacteur → écrit selon un guide de voix versionné
4. Éditeur ⛔ → contrôle qualité, BLOQUE si en dessous du standard
5. Générateur → markdown → HTML + JSON-LD + sitemap + RSS
6. Publication → déploiement + ping IndexNow
L'étape 4 est la seule qui compte vraiment. Sans elle, on a juste une ferme de contenu qui se fait désindexer.
Le garde-fou, en code
L'erreur classique, c'est de demander à un LLM « est-ce que cet article est bon ? ». Un modèle qui juge sa propre production est complaisant.
On a donc mis un script déterministe. Pas d'IA, pas d'opinion, des mesures :
const R = {
minWords: 700, // en dessous = contenu mince
introMin: 250, introMax: 1400, // zone "answer-first"
minH2: 3, // structure
minFaq: 3, // schema FAQPage
titleMax: 70, // au-delà, Google tronque
descMin: 110, descMax: 175,
banned: [ // formules bannies par la charte
"dans le monde d'aujourd'hui",
"il est important de noter",
"en conclusion",
],
};
Et les vérifications qui font sortir le script en code 1 :
// frontmatter complet
for (const k of R.required)
if (!meta[k]) err(`frontmatter: "${k}" manquant`);
// substance réelle
const words = body.replace(/[#*>|_`\-]/g, ' ').split(/\s+/).filter(Boolean).length;
if (words < R.minWords)
err(`${words} mots (min ${R.minWords})`);
// liens internes valides — un lien mort et ça ne passe pas
for (const m of body.matchAll(/\]\((\/[a-z0-9-]+)\/\)/g))
if (!allSlugs.includes(m[1].slice(1)))
err(`lien interne cassé: ${m[1]}`);
// formules interdites
for (const b of R.banned)
if (body.toLowerCase().includes(b))
err(`formule interdite : « ${b} »`);
Le script de publication l'appelle en premier :
set -e
node check.mjs # ⛔ sort en 1 → tout s'arrête ici
node build.mjs
wrangler pages deploy dist --project-name=…
node indexnow.mjs
set -e + code de sortie 1 = la publication est structurellement impossible si un article ne passe pas. Pas de « on verra », pas d'exception.
Ce que le garde-fou a attrapé dès le premier passage
Sur nos trois premiers articles, écrits pourtant avec soin :
- 3 meta descriptions trop longues (180 à 214 caractères). Google les aurait tronquées. Invisible à l'œil nu, évident pour le script.
- Un lien interne cassé après un changement d'architecture d'URL.
Aucun humain relisant à 23h n'aurait vu ça.
Les pièges rencontrés
Le LLM juge mal son propre travail. D'où le script déterministe. L'IA écrit, le code mesure.
Le fuseau horaire. new Date('2026-07-17T00:00:00Z').toLocaleDateString('fr-FR') affichait le 16 juillet. Il faut forcer timeZone: 'UTC' — sinon toutes les dates de publication décalent d'un jour.
Le résidu de build. Un dossier oublié dans le répertoire de déploiement a mis en ligne un site entier au mauvais endroit. Depuis, le script de build est le seul à écrire dans ce dossier, et on vérifie son contenu avant chaque envoi.
Le calibrage des règles. La première version mesurait le « premier paragraphe » pour vérifier la réponse directe. Avec un style à paragraphes courts, elle criait au loup en permanence. On mesure maintenant le bloc entier avant le premier ##.
Ce que je retiens
La partie difficile n'était pas de faire écrire l'IA. C'est devenu trivial.
La partie difficile, c'est de rendre la médiocrité impossible à publier. Un seuil chiffré, un code de sortie, et la discipline de ne jamais le contourner.
L'autre chose : le volume ne va pas sur le domaine principal. Deux à trois articles par semaine, pas trente. Le volume part sur des plateformes à forte autorité — comme celle-ci. On automatise ce qu'on possède, on soigne à la main ce qu'on emprunte.
On est un studio de développement. On construit des applications sur mesure et on documente ce qu'on apprend en le faisant. Si l'architecture complète vous intéresse, elle est détaillée sur notre blog.
Top comments (0)