Automatiser la vérification des conversions avant publication avec Claude Code

Un matin, j’ouvre mon outil d’analyse et je reste figé. L’article publié la veille fait trois fois mon trafic habituel. Et pourtant : zéro inscription au PDF gratuit, zéro clic sur le produit. Un article qui « buzze » mais qui ne génère pas un seul centime.

En cherchant, la cause s’est révélée ridicule. Le bouton d’inscription en bas d’article pointait encore vers une vieille page produit fermée six mois plus tôt. Pire, la version anglaise basculait en plein milieu sur du texte anglais mal placé, et les lecteurs étrangers décrochaient là. Le corps de l’article était bien écrit, mais je perdais tout dans les dernières lignes.

Depuis, j’ai séparé complètement « écrire l’article » et « vérifier qu’il est publiable ». Cette seconde tâche, si je la fais à la main à chaque fois, je finis toujours par la zapper. Alors je la confie à Claude Code, sous forme de routine fixe. Aujourd’hui je vous livre tout le contenu, prêt à copier-coller.

Points clés

• Quand le trafic monte mais pas les inscriptions, la cause est presque toujours une erreur qu’on aurait repérée avant publication : lien mort, vieille page produit, corps de texte resté en anglais.
• Fixez 9 points à contrôler avant publication, vérifiez-les toujours dans le même ordre, et les oublis chutent radicalement.
• Ce que vous confiez à Claude Code : ouvrir la page et vérifier mécaniquement chaque point. Le choix du bouton vedette, lui, reste humain.
• Réduire à un seul bouton d’inscription par article suffit à ne plus perdre le lecteur et à enchaîner sur l’action suivante.
• Garder une trace écrite de ce qui a été vérifié vous permet de retracer plus tard « sur quelle base j’ai publié ».

Définir les 9 points à contrôler avant publication

Dire « vérifie bien » ne déclenche aucune action, ni chez l’humain ni chez l’IA. Vérifier, c’est dérouler une liste de points concrets. Voici les 9 que j’ai figés.

#	Point à vérifier	Ce qu’on regarde
1	La page s’ouvre	Le serveur renvoie-t-il un 200 (pas un 404 ni un 500) ?
2	Le titre est correct	Le grand titre en haut de page correspond-il au titre de l’article ?
3	URL canonique	L’URL canonique pointe-t-elle bien vers l’article lui-même ?
4	Image à la une	L’image s’affiche-t-elle (pas une vieille image, pas d’absence d’image) ?
5	Langue du corps	Chaque version est-elle rédigée dans sa langue dès le début ?
6	Annonce du PDF gratuit	Le bouton d’inscription existe-t-il et son lien est-il actif ?
7	Lien produit	Le lien pointe-t-il vers la page produit voulue (pas un autre produit) ?
8	Parcours vers la page conseil	Le lien mène-t-il bien à la page de consultation ?
9	Affichage mobile	Y a-t-il un défilement horizontal (un débordement) ?

Les points clés sont le 3 et le 7. Si l’URL canonique pointe vers la page d’accueil ou un autre article, le moteur de recherche considère cette page comme la référence, et votre article ne récolte aucune valeur. L’inversion de lien, elle, arrive surtout dans les articles fabriqués par copier-coller.

Ce qu’on confie à l’IA, ce qu’on décide soi-même

Mélanger les deux mène à l’accident. Traçons la ligne clairement.

Ce qu’on confie à Claude Code, ce sont les vérifications qu’on peut trancher mécaniquement. Ouvrir la page, lire le titre, récupérer la destination d’un lien, voir si l’image s’affiche, contrôler la mise en page en largeur mobile. Ces tâches sont fastidieuses pour un humain, et quand c’est fastidieux on saute : on les fait donc exécuter par l’IA à chaque fois.

Ce qu’on décide soi-même, ce sont les parties qui demandent du jugement. Quel bouton mettre en vedette dans cet article. Si la formulation du texte sonne naturel. Si on n’oriente pas vers un vieux produit. Et la décision finale : « cet article est-il vraiment publiable ? ». Confier cela en bloc à l’IA fait sortir des articles aux liens valides mais au contenu décalé.

Le critère en cas de doute est simple. Ce qui a une réponse unique va à l’IA, ce qui touche au goût ou à la stratégie reste humain. Savoir si un lien renvoie un 200 a une réponse unique : à l’IA. Choisir lequel des trois boutons mettre en avant relève de la stratégie : à l’humain.

Le gabarit d’instruction à copier-coller

Voici l’instruction à coller telle quelle dans Claude Code. Remplacez seulement le nom du dépôt et les URL à vérifier par les vôtres.

Pour chacune des URL suivantes, exécute le contrôle avant publication.
Vérifie que la page s'ouvre en 200, que le grand titre correspond au titre de l'article,
que l'URL canonique pointe vers le même article, que l'image à la une s'affiche,
que le corps du texte est rédigé dans sa langue, que le bouton d'inscription au PDF gratuit est actif,
que le lien produit mène à la page produit voulue, que le lien vers la page conseil est correct,
et qu'aucun défilement horizontal n'apparaît en largeur mobile.

Pour chaque URL, rapporte en une ligne en séparant les points réussis et les points échoués.
Ne valide pas un article au seul motif qu'il « s'ouvre en 200 ». S'il y a des points échoués,
indique aussi l'hypothèse de cause et quel fichier corriger.

Les deux dernières phrases sont le nerf. Si vous vous arrêtez à « ça s’ouvre en 200 = OK », vous laissez passer l’inversion de lien, l’erreur la plus fréquente. Faites toujours séparer les points échoués et exiger l’emplacement à corriger : vous enchaînez directement sur la correction.

Le script de décision prêt à l’emploi

La partie qui agrège les résultats et renvoie mécaniquement « publiable ou non » gagne à être du code, pour ne jamais flotter. Voici une version minimale qui tourne sous Node.js.

// Les 9 points à passer impérativement avant publication
const requiredChecks = [
  "la page s'ouvre en 200",
  "le grand titre correspond au titre de l'article",
  "l'URL canonique pointe vers le même article",
  "l'image à la une s'affiche",
  "le corps est rédigé dans sa langue",
  "le bouton d'inscription au PDF gratuit est actif",
  "le lien produit mène à la page produit voulue",
  "le lien vers la page conseil est correct",
  "aucun défilement horizontal en largeur mobile",
];

// On passe à "passed" le tableau des noms de points réussis
function summarizeSmokeResult(passed) {
  const missing = requiredChecks.filter((check) => !passed.includes(check));
  return {
    ok: missing.length === 0,
    missing,
    nextAction: missing.length === 0 ? "publier" : "corriger puis revérifier",
  };
}

// Exemple : seul le lien produit a échoué
const passed = requiredChecks.filter((c) => c !== "le lien produit mène à la page produit voulue");
const result = summarizeSmokeResult(passed);

console.log(result.ok ? "Publication OK" : "Publication NON");
console.log("Points échoués :", result.missing);
console.log("Action suivante :", result.nextAction);

En exécutant ce script, vous obtenez Publication NON, le nom des points échoués et l’action suivante. Dès qu’un seul point manque, ok passe à false : impossible de publier « à peu près OK » par accident. Il suffit de remplir le tableau passed avec le résultat de la vérification que l’IA a faite via l’instruction ci-dessus.

Trois situations où ça a vraiment payé

1. Les jours où je publie plusieurs articles Le jour où je sors trois articles d’un coup, la vérification devient vite bâclée. J’ouvre chaque article un par un en largeur mobile, je fais défiler jusqu’au titre, au début du corps et aux abords du bouton d’inscription. Si, dans une version autre qu’anglaise, le corps est resté en anglais, j’arrête la publication sur-le-champ. Plus le jour est propice au bâclage, plus la liste fixe est efficace.

2. Quand je remplace seulement le bouton d’un article populaire Même pour ne changer qu’un bouton en bas d’un article très lu, demander juste « cherche le composant concerné et corrige-le » est trop large. Je décide d’abord : quels fichiers on peut toucher, lesquels rester intouchables, quelles URL vérifier, quelle destination pour chaque lien. Rien que ça fait passer la vérification finale de « ça a l’air bien » à « avec cette preuve, je peux publier ».

3. Le contrôle qualité des articles multilingues Même si le réglage de langue de l’article est correct, un corps resté en anglais n’est pas de qualité publiable. Pour chaque langue, je regarde le grand titre, le début du corps et les abords des boutons, et je vérifie que le lecteur de cette langue sait quoi faire ensuite. Pour un lecteur français, la description du PDF gratuit, l’orientation vers le produit et l’invitation à la consultation doivent toutes se lire naturellement en français.

Pièges fréquents et comment les corriger

Piège 1 : déclarer « c’est publié » au seul motif que le build local passe Un build qui réussit en local ne garantit pas que la page en ligne s’affiche correctement. La correction : faire porter la vérification sur « la vraie page en ligne », pas sur « le résultat du build local ». Précisez aussi à l’IA : « ouvre l’URL publique et vérifie ».

Piège 2 : aligner tous les boutons d’inscription Mettre PDF gratuit, produit A, produit B et consultation à la même taille, et le lecteur ne sait plus lequel cliquer : au final il n’en clique aucun. La correction : un seul bouton vedette par article, le reste relégué en appoint discret.

Piège 3 : le lien pointe vers un autre produit « PDF gratuit » écrit, mais le clic mène à un produit payant : ça arrive souvent dans les articles copiés-collés. La correction : faire toujours récupérer la destination du lien (point 7) par l’IA, et vérifier à l’œil jusqu’à l’identifiant du produit.

Piège 4 : faire de grosses modifications sans plan de retour arrière Réécrire largement juste avant la publication et ne plus pouvoir revenir en arrière si ça casse, c’est le pire. La correction : limiter chaque intervention à un périmètre où vous pouvez préparer à l’avance « la procédure pour revenir en arrière si c’est bizarre ». Une intervention dont vous ne savez pas décrire le retour arrière est trop grosse pour ce passage-là.

FAQ

Q. Mon trafic a monté mais pas les inscriptions. Que regarder d’abord ? R. Regardez d’abord la destination du bouton d’inscription et la langue du corps. Un lien resté sur une vieille page produit, ou une version destinée aux lecteurs étrangers non traduite : ce sont les deux grandes causes. Cela correspond aux points 5, 6 et 7 du contrôle avant publication.

Q. Cette vérification est-elle nécessaire à chaque fois ? C’est pénible. R. À chaque fois, oui. C’est justement pour ça qu’on ne la fait pas à la main : on passe l’instruction de cet article à Claude Code et on la fait exécuter mécaniquement. Plus une vérification est pénible, plus on la saute les jours chargés. Et c’est précisément ces jours-là que l’accident arrive.

Q. Si je réduis à un seul bouton, je ne perds pas d’entrées vers mes autres produits ? R. Plus que le nombre d’entrées, ce qui compte c’est que le lecteur puisse en cliquer une sans hésiter. Quand on en aligne plusieurs, il n’arrive pas à choisir et décroche. Un bouton vedette, plus un ou deux liens d’appoint placés naturellement dans le texte : c’est le bon équilibre.

Q. Pourquoi l’URL canonique est-elle si importante ? R. Le moteur de recherche évalue comme « la référence » la page désignée par l’URL canonique. Si elle pointe vers un autre article ou la page d’accueil, c’est cette autre page qui est évaluée à la place de votre article, et le classement se concentre dessus.

Q. À quoi sert de garder un journal des vérifications ? R. À retracer plus tard « sur quelle base j’ai publié ». En cas de problème, vous isolez plus facilement où ça a coincé : corps, bouton, lien ou parcours conseil. Sans trace, vous devez tout revérifier de zéro à la prochaine opération.

Garder une trace en une page

Laisser une courte note après publication allège énormément la vérification suivante. Une forme comme celle-ci suffit.

- article : claude-code-revenue-smoke-test
- date de publication : 2026-06-14
- preuves vérifiées : URL publique, grand titre, URL canonique, image à la une, langue du corps, destination du bouton
- bouton vedette : lien produit (lecteurs autonomes)
- chiffres à suivre : PV, inscriptions PDF, clics produit, accès page conseil

Pour les chiffres aussi, ne jugez pas sur les seuls PV. Alignez sur la même date les inscriptions au PDF gratuit, les clics sur le produit et les accès à la page conseil. Confrontez le tout à une hypothèse : pour un article destiné aux débutants, ce sont les inscriptions PDF qui devraient monter ; pour un article traitant de réglages ou de permissions, les clics produit. Avec cette habitude, la publication quotidienne passe de « juste sortir un article » à « réparer ses parcours petit à petit ».

Cette ligne entre « vérification confiée à la machine » et « jugement décidé par l’humain » s’applique au-delà du seul contrôle des revenus. Pour la vue d’ensemble quand on n’est pas développeur, voyez Utiliser Claude Code sans être développeur ; pour les astuces qui accélèrent le travail quotidien, Conseils de productivité Claude Code. Et comme bien demander une vérification à l’IA exige des instructions précises, lisez aussi Techniques avancées de prompt Claude Code.

Le mécanisme sous-jacent — faire lire des fichiers ou vérifier des liens à l’IA — se vérifie dans la documentation officielle Claude. Quand vous sentez qu’un comportement a changé, consulter la source primaire d’abord reste, au final, le plus rapide.

Ce que j’ai constaté en l’essayant

J’ai fait tourner cette routine sur mon propre site pendant environ deux semaines. Ce que je voulais vérifier : « ce contrôle en 9 points réduit-il vraiment les oublis ? ».

Résultat, des problèmes qui passaient inaperçus du temps où je ne regardais que « la page s’ouvre en 200 » sont apparus, plusieurs. Concrètement : deux articles sur le point d’être publiés avec l’image à la une d’un autre article reprise telle quelle, un article dont le bouton d’inscription pointait vers un vieux produit, et un article dont la version anglaise basculait en plein milieu sur du japonais. Tous auraient été déclarés conformes au seul critère « s’ouvre en 200 ».

Ce qui a le plus payé, c’est la règle « un seul bouton d’inscription par article ». En réorganisant un article qui alignait PDF gratuit, produit et consultation au même poids autour d’un unique bouton vedette, le taux de clic sur le bouton a visiblement augmenté. J’ai constaté en chiffres que le lecteur agit davantage quand il a moins de choix.

À l’inverse, j’ai compris que cette vérification ne tient pas si elle reste manuelle. Les premiers jours je la faisais à la main, puis je l’ai allègrement sautée un jour chargé. Ce n’est qu’en la coulant dans une instruction et un script, déroulés toujours dans le même ordre, qu’elle s’est enfin ancrée.

Faire de la vérification ingrate d’avant publication un mécanisme : c’est l’assurance la moins chère pour convertir le trafic en revenus. Si vous voulez l’intégrer à la gestion d’un blog d’entreprise ou au flux de publication d’une équipe, on peut concevoir ensemble une routine adaptée à votre fonctionnement réel via la page formation et consultation.