Reçu de vérification Claude Code : build, URL publique, CTA et captures

Pourquoi créer un reçu de vérification

Claude Code peut modifier un article, une page produit ou un lien de conversion très vite. Le risque n’est pas la modification elle-même, mais le moment où un diff plausible donne l’impression que tout est terminé. Pour un contenu public, surtout s’il mène vers un PDF gratuit, un produit Gumroad ou une demande de consultation, un build local ne suffit pas. La page publique peut encore servir une ancienne version, le CTA peut viser le mauvais produit, et une traduction peut casser le bouton sur mobile.

Le “reçu de vérification” est une courte note de preuve. Il dit quels fichiers ont changé, pourquoi ils ont changé, quelle commande a été lancée, quelle URL publique a été ouverte, quel CTA a été testé, quelles captures ont été gardées et quels risques restent. Ce n’est pas un document lourd. C’est le minimum pour que la prochaine session ne dépende pas d’un souvenir vague.

Ce workflow complète le triage des erreurs de build, la checklist de review et la checklist de permissions. Le premier sert quand la preuve échoue, le deuxième quand le diff doit être relu, le troisième quand l’agent demande trop d’accès.

Modèle de reçu de vérification

Copiez ce modèle dans un commentaire de PR, une note de publication ou le prompt final envoyé à Claude Code. La règle est simple : écrire des observations, pas des impressions. “Ça semble correct” ne prouve rien. “npm.cmd run build a réussi”, “le h1 public contient le titre attendu” et “le CTA ouvre la page Gumroad” sont des preuves.

Verification Receipt

Scope:
- changed files:
- user-facing behavior:
- out of scope:

Diff summary:
- what changed:
- why it changed:
- what should not change:

Proof commands:
- git status --short:
- git diff --stat:
- npm.cmd run build:

Public URL checks:
- article URL:
- expected h1:
- canonical:
- no fallback page:

Revenue and CTA checks:
- free PDF CTA:
- Gumroad product link:
- consultation link:
- thanks page or next step:

Screenshot checks:
- desktop screenshot:
- mobile screenshot:
- visible CTA:
- text overflow or broken layout:

Remaining risk:
- risk 1:
- risk 2:
- risk 3:

La ligne “out of scope” évite qu’une simple amélioration d’article devienne une refonte de navigation ou une mise à jour de dépendances. La ligne “what should not change” protège le slug, le canonical, l’auteur, la date de publication, les liens produit et la route de consultation. Ces éléments ne se voient pas toujours dans la lecture rapide, mais leur casse coûte cher.

Exemple concret : build, URL publique, CTA et captures

Commencez par la preuve locale. Vérifiez que les fichiers modifiés sont bien ceux prévus, regardez la taille du diff, puis lancez le build. Sur Windows, npm.cmd évite des différences de résolution de commande.

git status --short
git diff --stat
cd site
npm.cmd run build

Ensuite, vérifiez l’URL publique. HTTP 200 n’est pas suffisant : une page fallback peut répondre 200. Cherchez des chaînes propres à la page, comme le h1, une phrase du corps et le nom du CTA.

const checks = [
  {
    url: "https://claudecode-lab.com/fr/blog/claude-code-verification-receipt-workflow/",
    mustInclude: ["Reçu de vérification", "Modèle de reçu", "Gumroad"],
  },
  {
    url: "https://claudecode-lab.com/en/products/",
    mustInclude: ["Claude Code", "Products"],
  },
  {
    url: "https://claudecode-lab.com/fr/training/",
    mustInclude: ["consultation"],
  },
];

for (const check of checks) {
  const res = await fetch(check.url, { redirect: "follow" });
  const html = await res.text();
  const missing = check.mustInclude.filter((text) => !html.includes(text));
  console.log(check.url, res.status, missing.length === 0 ? "ok" : `missing: ${missing.join(", ")}`);
}

Terminez par une preuve visuelle. Le texte peut être présent alors que le bouton est trop long, qu’un bloc de code dépasse ou que le CTA final perd son contexte. Avec Playwright, gardez une capture desktop et une capture mobile.

import { chromium } from "playwright";
import { mkdir } from "node:fs/promises";

const outDir = "tmp-verification/claude-code-verification-receipt-workflow";
await mkdir(outDir, { recursive: true });

const browser = await chromium.launch();
const page = await browser.newPage({ viewport: { width: 1440, height: 1100 } });
await page.goto("https://claudecode-lab.com/fr/blog/claude-code-verification-receipt-workflow/", {
  waitUntil: "networkidle",
});
await page.screenshot({ path: `${outDir}/desktop-fr.png`, fullPage: true });

await page.setViewportSize({ width: 390, height: 1200 });
await page.screenshot({ path: `${outDir}/mobile-fr.png`, fullPage: true });

await browser.close();
console.log(`screenshots saved to ${outDir}`);

En inspectant les captures, regardez le premier écran, le premier bloc de code, une section au milieu et le CTA final. Les articles enrichis échouent souvent non pas par manque de contenu, mais par surcharge visuelle, retours à la ligne malheureux ou liens trop serrés sur mobile.

Cas 1 : enrichir un article trop léger

Quand un article est trop mince, l’objectif n’est pas d’ajouter du volume artificiel. Il faut rendre la page utile. Ici, le lecteur doit repartir avec une définition claire du reçu, un modèle copiable, des commandes de build, une vérification d’URL publique, une vérification de CTA, une méthode de capture et des erreurs concrètes à éviter.

Le reçu de cette amélioration doit noter les sections ajoutées, les liens internes, les liens externes, les blocs de code et les risques restants. Il doit aussi vérifier que le chemin commercial reste naturel : PDF gratuit pour installer l’habitude, Gumroad pour les modèles et le guide de configuration, consultation si le lecteur doit transformer cette pratique en règle d’équipe.

Cas 2 : modifier un CTA ou un lien produit

Un CTA paraît petit, mais il influence directement l’inscription, l’achat ou la demande de conseil. Ne notez pas seulement “CTA modifié”. Notez le libellé, le href, le titre de la page cible et l’action attendue après le clic.

Pour un PDF gratuit, vérifiez que la promesse est claire et que la page suivante explique bien quoi faire. Pour Gumroad, vérifiez le nom du produit, le début de la description et l’alignement avec l’article. Pour une consultation, vérifiez que le passage est logique. Dans un article sur Claude Code, la consultation devient naturelle quand il est question de règles de review, permissions, déploiement et revenus.

Cas 3 : publier plusieurs langues

La localisation ne doit pas être vérifiée uniquement depuis l’anglais. Une expression comme “verification receipt” doit être expliquée comme une preuve de publication, pas comme un reçu de paiement. Le français, l’espagnol ou l’allemand peuvent allonger les CTA. Le japonais ou le coréen peuvent demander une phrase plus courte pour rester naturel. Chaque langue mérite une lecture du début, du modèle, des échecs et du chemin vers les ressources.

Les captures aident à repérer les erreurs que la source ne montre pas : bouton sur deux ou trois lignes, bloc de code trop large, dernière section trop commerciale, lien de consultation peu clair. Pour un contenu qui soutient une activité, ces détails ne sont pas décoratifs.

Échecs fréquents et parades

Premier échec : considérer HTTP 200 comme une publication. Vérifiez le h1, le canonical et une phrase unique du corps.

Deuxième échec : s’arrêter au build. Le build prouve que la source compile, pas que la production sert la bonne version.

Troisième échec : vérifier qu’un lien existe sans ouvrir la destination. Un CTA fait partie du comportement utilisateur.

Quatrième échec : oublier les captures. Sans image, la vérification mobile devient une promesse impossible à auditer.

Cinquième échec : demander à Claude Code “vérifie” sans format. Donnez le modèle et exigez commandes, URLs, CTA, captures et risques.

Ressources, Gumroad et consultation

Si vous travaillez seul, commencez par le cheatsheet gratuit Claude Code pour fixer les commandes et les réflexes quotidiens. Quand le même besoin revient, utilisez les templates de prompts et le Setup Guide pour rendre CLAUDE.md, les hooks et les permissions répétables.

Si vous publiez en équipe des articles, pages de vente ou formulaires de consultation, la vérification devient une règle d’exploitation. Il faut décider qui regarde l’URL publique, où vont les captures, quels CTA protègent le revenu et quels échecs bloquent une publication. La consultation est alors une suite naturelle : elle sert à concevoir ces règles avant qu’une page cassée ne coûte des prospects.

• Cheatsheet gratuit Claude Code
• 50 templates de prompts Claude Code
• Claude Code Setup Guide
• Produits
• Consultation

Ce que j’ai vérifié pour cet article

J’ai séparé la preuve locale, l’URL publique, les CTA et les captures dans un workflow en forme de reçu. Le résultat pratique est simple : l’article ne se contente plus de dire “vérifiez”, il montre quoi vérifier, comment le prouver et comment garder le chemin vers PDF gratuit, Gumroad et consultation cohérent.