Un blog écrit par l’API Claude : ce qui marche, à quelles conditions
Un blog peut être alimenté chaque jour par l’API Claude si les contrôles en aval sont verrouillés : source de premier rang obligatoire, liens vérifiés, anti-doublon de titre et typographie française. Chez Peechy, le brouillon est publié automatiquement 24 h plus tard, et une seule recherche web par article suffit.
Le contexte : notre propre blog, pas un cas client
Ce retour ne porte pas sur un client. C’est le blog de Peechy, et cet article a lui-même été produit par ce système. Le principe : un article par jour, rédigé par l’API Claude à partir d’un sujet, d’un angle et d’une recherche web sourcée. Il est enregistré en brouillon, puis passe en ligne 24 h plus tard sans action de ma part. Pendant ces 24 h, je peux relire, corriger ou bloquer. Claude fait partie de notre stack, et nous détaillons son usage dans notre stack IA chez Peechy.
Je ne publie aucun chiffre de trafic ni de coût ici : je n’ai rien de mesuré et sourcé à vous montrer, donc je n’en invente pas.
Le problème : publier tous les jours sans publier n’importe quoi
Écrire un article par jour avec un modèle est facile. Le difficile, c’est d’éviter quatre dérives :
- des affirmations sans source, ou sourcées sur un blog qui recopie un autre blog ;
- des liens cassés ou inventés ;
- deux articles qui disent la même chose avec des titres voisins ;
- une typographie qui trahit le texte généré (tirets cadratins, expressions toutes faites).
Côté Google, le cadre est clair. Pour apparaître comme lien de soutien dans les AI Overviews ou l’AI Mode, une page doit remplir deux conditions : être indexée et être éligible à un extrait. Un AI Overview désigne un encadré de réponse généré par l’IA, affiché par Google au-dessus des résultats de recherche classiques, avec des liens vers les pages qui l’appuient. Il n’y a pas d’autre exigence technique, et aucune optimisation spécifique n’est demandée source : Google Search Central, 2025. Les fondamentaux d’un contenu utile restent donc la base, et la vitesse de production n’en dispense pas. Nous creusons ce point dans AI Overviews en France : ce qui change.
La solution : cinq actions dans la chaîne
- Un brief fixe par article. Sujet, angle, catégorie, longueur cible, règles de style et liste fermée de liens internes autorisés. Le modèle ne choisit pas ses liens internes au hasard.
- Une recherche web sourcée. Elle fournit des URLs réelles, que l’article doit citer. Le RAG (génération augmentée par récupération) désigne cette méthode : on donne au modèle des documents trouvés avant la rédaction, au lieu de lui demander de répondre de mémoire.
- Un brouillon, jamais une publication directe. L’article est créé avec
draft: trueet une date de publication automatique à 24 h. Cette fenêtre sert de dernier filet de sécurité. - Des contrôles automatiques avant d’accepter le texte (tableau ci-dessous).
- Une régénération en cas d’échec, mais sans relancer la recherche (voir plus bas).
| Contrôle | Ce qu’il vérifie |
|---|---|
| Source de premier rang | Au moins une autorité publique ou une documentation d’éditeur citée |
| Liens vérifiés | Les URLs de la recherche répondent (une page disparue est écartée), les liens internes mènent à des articles existants |
| Sections citables | Réponse directe en tête, sections qui se comprennent seules |
| Anti-doublon | Titre et premier paragraphe comparés aux articles récents |
| Typographie française | Pas de tiret cadratin, pas d’expressions interdites |
L’erreur : relancer la recherche à chaque tentative
Au début, chaque contrôle raté déclenchait une nouvelle tentative complète. Et chaque tentative relançait aussi la recherche web. Un article qui échouait deux ou trois fois consommait donc plusieurs recherches et plusieurs rédactions, alors qu’une seule recherche suffisait.
C’était un défaut de conception, pas un défaut du modèle. Les contrôles qui échouent portent le plus souvent sur la rédaction : une définition manquante, une section sans source ni chiffre, un titre trop long. La matière, elle, ne change pas entre deux tentatives.
La correction tient en une règle : une seule recherche par article. Les résultats sont conservés et réinjectés tels quels à chaque nouvelle rédaction. La recherche n’est refaite que si ce sont les sources qui posent problème : trop peu de sources, ou aucune de premier rang. Une page disparue est simplement écartée avant la rédaction. Nous n’avons pas de mesure publiable de l’économie obtenue : le constat est qualitatif, la consommation est devenue prévisible.
Résultats : ce que le système garantit, et ce qu’il ne garantit pas
Ce que nous observons :
- les articles qui violent une règle sont refusés avant d’atteindre le brouillon ;
- une tentative ratée ne relance plus la recherche web, seulement la rédaction, et un petit défaut (titre trop long, définition manquante) se corrige par une retouche courte ;
- la relecture humaine reste possible pendant 24 h, et nous l’utilisons.
Ce que le système ne garantit pas : l’exactitude. Un contrôle vérifie qu’un lien existe et qu’une source de premier rang est citée, pas que le modèle l’a bien interprétée. Un script ne remplace pas un œil qui lit. Un article automatisé sans relecture ne doit pas être présenté comme fiable, et nous ne le présentons pas ainsi.
Le contexte éditorial va aussi dans ce sens. Google a élargi sa documentation en 2026 avec des sections sur le contenu « non banalisé » (non-commodity), et dit démentir plusieurs idées reçues sur l’« AEO/GEO » source : Google Search Central, mise à jour 2026. La fonction « Preferred sources » a été étendue le 27 mai 2026 à l’AI Mode et aux AI Overviews source : Google Search Central, 2026. Aucune recette de citation automatique n’existe. Pour la suite, voyez Être cité par ChatGPT et Perplexity : ce qui compte.
Ce qu’une PME peut en retenir
Vous n’avez pas besoin de notre pipeline pour appliquer ces principes. Voici ce qui se transpose à une PME qui veut automatiser une partie de son contenu :
- Fixez les règles avant d’écrire. Un brief avec des contraintes précises vaut mieux qu’un prompt libre. Écrire un bon prompt commence par là.
- Séparez la recherche de la rédaction. Cherchez une fois, rédigez autant de fois que nécessaire.
- Ne publiez jamais en direct. Un brouillon avec délai coûte une journée et évite une erreur publique.
- Automatisez les contrôles de forme, relisez le fond. Les liens, les doublons et la typographie se vérifient par script. L’exactitude se vérifie par une personne.
- Limitez le volume à ce que vous pouvez relire. Google met en garde contre la production de masse à faible valeur propre, et un rythme que personne ne contrôle y mène vite.
Si vous ne deviez retenir qu’une action : mettez un contrôle automatique avant la publication et un délai de relecture après, avant d’augmenter la cadence.
Faut-il relancer la recherche web quand un contrôle échoue ?
Pas quand l’échec porte sur la rédaction, ce qui est le cas le plus fréquent : conservez les résultats de la première recherche et régénérez seulement le texte. Relancez la recherche seulement si ce sont les sources qui manquent.
Peut-on publier automatiquement sans relecture ?
Techniquement oui, mais ce n’est pas notre choix. Nous gardons un brouillon pendant 24 h, parce qu’un contrôle automatique ne vérifie pas qu’une source est bien interprétée.
Un blog écrit avec l'IA peut-il apparaître dans les AI Overviews ?
Oui, à condition que la page soit indexée et éligible à un extrait dans Google Search. Aucune autre exigence technique n’est demandée source : Google Search Central, 2025.
Ce problème, Peechy s'en occupe
Plutôt que de tout gérer seul, confiez votre site à une agence qui s'occupe de tout, hébergement, sécurité, maintenance et corrections. Encore plus simple en abonnement : on règle les soucis avant même que vous les remarquiez.
Confier mon site à Peechy


