Prompts Claude Code/Codex pour débutants : 5 modèles pratiques

Point de départ : un bon prompt est un brief de travail clair

Quand Claude Code ou Codex produit une réponse confuse, le problème n’est pas toujours que l’agent “code mal”. Le prompt ne lui a peut-être pas donné assez de limites. Un prompt n’est pas une formule magique. C’est un brief de travail pour un agent de développement : quoi modifier, quoi ne pas toucher, ce qui compte comme terminé, quelles preuves de vérification fournir et ce que la personne suivante doit savoir.

Ce guide pour débutants transforme cette idée en 5 modèles pratiques : périmètre, contexte du dépôt, critères d’acceptation, preuves de vérification et passation. Ils fonctionnent pour corriger un bug, ajouter une petite fonctionnalité, générer un article, auditer un dépôt ou préparer une review. Le but n’est pas d’écrire des phrases sophistiquées. Le but est de réduire les suppositions.

Les détails des produits changent, donc gardez les sources officielles à portée de main. Commencez par Claude Code overview, Claude Code memory et Claude Code settings. Pour Codex et les workflows OpenAI liés au code, utilisez le OpenAI code generation guide. Si vous découvrez encore l’outil, lisez aussi le guide de démarrage Claude Code et les bonnes pratiques CLAUDE.md.

Les 5 modèles

Modèle	Sens simple	Risque si absent
Périmètre	La frontière de la tâche	L’agent modifie des fichiers sans rapport
Contexte du dépôt	Règles et exemples existants	Le résultat ignore les conventions locales
Critères d’acceptation	La définition de terminé	Vous et l’agent n’avez pas le même standard
Preuves de vérification	Ce qui prouve que la vérification a eu lieu	Le travail s’arrête à “c’est implémenté”
Passation	Note courte pour la session suivante	Personne ne sait pourquoi le changement existe

Les critères d’acceptation sont les conditions concrètes à respecter avant d’accepter un changement. Les preuves de vérification sont le reçu : commandes exécutées, écrans vérifiés, tests manuels ou limites explicitement non vérifiées. La passation permet à vous-même demain, à un collègue ou à un autre agent de reprendre sans relire toute la conversation.

Modèle 1 : fixer un périmètre étroit

Un prompt faible commence trop large.

Améliore cette application et rends-la meilleure.

Ce prompt ne dit pas si l’agent peut toucher à l’UI, l’API, les tests, le texte, le schéma de base de données, les dépendances ou le déploiement. Claude Code et Codex peuvent deviner, mais chaque supposition ajoute du risque.

Utilisez plutôt :

Modifie uniquement site/src/content/blog-fr/5-tips-for-better-prompts.mdx.
Objectif : rendre l'article plus utile pour les débutants Claude Code/Codex.

Autorisé :
- title, description, updatedDate et tags dans le frontmatter
- corps de l'article

Ne pas modifier :
- heroImage
- slug
- autres articles
- configuration de build

C’est particulièrement important pour un site monétisé. Une réécriture trop large peut supprimer par erreur des liens internes, des CTA produit ou des attributs d’analytics. Un périmètre clair donne de l’espace à l’agent sans transformer une mise à jour d’article en refonte globale.

Pour une phase d’exploration, soyez encore plus strict :

Lis les fichiers liés et propose seulement un plan. N'édite rien pour l'instant.
Liste les fichiers que tu changerais, la raison et la commande de vérification pour chacun.

L’erreur courante consiste à demander “regarde d’abord” tout en autorisant les modifications. Dans un dépôt inconnu, séparez exploration et implémentation.

Modèle 2 : donner le contexte du dépôt

Claude Code/Codex peut lire les fichiers, mais il ne connaît pas automatiquement votre priorité business, vos choix de style ou vos erreurs passées. Le contexte du dépôt explique “comment on travaille ici”.

Ce site utilise Astro content collections pour des articles MDX localisés.
Utilise site/src/content/blog-fr/claude-code-productivity-tips.mdx comme référence de qualité.

Contexte du projet :
- Les articles doivent être des tutoriels evergreen pratiques, pas de fins résumés IA.
- Inclure au moins 3 cas d'usage concrets.
- Inclure des liens officiels externes et des liens internes.
- Préserver le chemin de conversion : /fr/thanks/, /en/products/, /en/training/.
- Garder un frontmatter valide.

Sans ce contexte, vous pouvez obtenir un article propre mais mal aligné avec ClaudeCodeLab. Ici, le lecteur a besoin de prompts copiables, d’exemples d’échec, d’habitudes de vérification et d’une étape suivante naturelle vers la cheatsheet, les produits ou la formation.

Si vous répétez souvent le même contexte, placez la partie stable dans CLAUDE.md. Les astuces de productivité Claude Code montrent comment les règles projet, commandes sûres et habitudes de vérification réduisent les explications répétées.

Modèle 3 : écrire les critères d’acceptation avant de commencer

Les critères d’acceptation évitent la boucle “améliore encore”. Un prompt faible serait :

Rends cet article plus lisible et meilleur pour le SEO.

Lisibilité et SEO sont importants, mais ce n’est pas assez vérifiable. Décomposez-les :

Critères d'acceptation :
- Seul le fichier cible est modifié.
- La description fait 120 caractères ou moins.
- Chacun des 5 modèles contient un exemple Before/After.
- Il y a des modèles pour bugfix, nouvelle fonctionnalité et génération d'article.
- Les pièges et les moyens de les éviter sont concrets.
- Des liens officiels, liens internes et une CTA claire sont inclus.
- La réponse finale rapporte la vérification et les risques restants.

Pour une fonctionnalité, les critères doivent être plus techniques :

Critères d'acceptation :
- Le layout UI existant est conservé.
- Aucun type error TypeScript.
- Validation et états d'erreur visibles sont ajoutés.
- Au moins un test pertinent est ajouté ou mis à jour.
- Les résultats de npm test et npm run build sont rapportés.

Chaque point doit pouvoir être vérifié. Si l’agent ne peut pas le prouver, il doit le dire au lieu de prétendre que tout est validé.

Modèle 4 : demander des preuves de vérification

“Implémenté” ne suffit pas. Demandez un verification receipt.

À la fin, rends un verification receipt :

- Fichiers modifiés :
- Commandes exécutées :
- Résultats :
- Vérifications manuelles :
- Non vérifié :
- Risques restants :

Cette habitude repère beaucoup d’erreurs de débutant. Elle force aussi l’agent à dire quand une commande ne peut pas tourner parce que les dépendances manquent, que les tests sont trop lents ou qu’un service local n’est pas disponible. Vous pouvez alors juger le risque.

Ne résumez pas trop les erreurs. Ceci est faible :

Le build a échoué. Corrige.

Ceci est utile :

Commande :
npm run build

Erreur :
Type error: Property 'name' does not exist on type 'User | undefined'.
File: src/components/Profile.tsx:15:22

Demande :
Explique la cause probable, fais la plus petite correction sûre, puis relance npm run build.

Pour un workflow plus complet, lisez le guide verification receipt. Le format exact peut varier, mais la règle reste la même : ne terminez pas sans preuve.

Modèle 5 : demander une note de passation

Le travail avec un agent dépasse souvent une seule session. Une note de passation évite de tout redécouvrir.

À la fin, écris une handoff note avec :
- Objectif
- Ce qui a changé
- Ce qui n'a pas changé
- Résultats de vérification
- Fichiers à inspecter ensuite
- Risques ou décisions ouvertes

C’est utile pour les articles, le SEO, les tunnels de paiement et les dépôts d’équipe. Un diff montre ce qui a changé, mais explique rarement pourquoi une CTA a été placée dans telle section ou pourquoi une petite correction a été préférée à un gros refactor.

En équipe, reliez cette pratique aux règles de passation Claude Code. Un format stable rend les sessions IA plus faciles à relire.

Modèles à copier-coller

Modèle bugfix

Objectif :
  Corriger le bug avec le plus petit diff sûr.

Symptôme :
  Ce qui se passe :
  Comportement attendu :
  Comportement réel :

Étapes de reproduction :
  1.
  2.
  3.

Périmètre :
  Fichiers modifiables :
  Fichiers à ne pas modifier :

Contexte du dépôt :
  Implémentation similaire à suivre :
  Règles locales à préserver :

Critères d'acceptation :
  Expliquer les causes probables avant modification.
  Corriger la cause racine, pas seulement masquer le symptôme.
  Ajouter ou mettre à jour un test pertinent si possible.
  Rendre les preuves de vérification et le risque restant.

Modèle nouvelle fonctionnalité

Objectif :
  Ajouter une petite fonctionnalité en sécurité.

Fonctionnalité :
  Changement visible pour l'utilisateur :
  Changements API/base de données/config :

Contraintes :
  Préserver le style UI existant.
  Suivre les conventions actuelles de nommage et fichiers.
  Si un changement de design plus large est nécessaire, l'expliquer avant d'implémenter.

Critères d'acceptation :
  Inclure implémentation, types, états d'erreur, tests et verification receipt.

Modèle génération ou réécriture d’article

Objectif :
  Transformer ceci en article evergreen utile pour débutants.

Lecteur :
  Développeur solo ou petite équipe qui démarre avec Claude Code/Codex.

Éléments obligatoires :
  3 cas d'usage concrets ou plus.
  Exemples de prompts Before/After.
  Pièges spécifiques et corrections.
  Modèles copiables.
  Liens officiels, liens internes et CTA.

Critères d'acceptation :
  Description de 120 caractères ou moins.
  Frontmatter valide.
  Code fences équilibrés.
  Finir avec une courte auto-review.

Trois cas d’usage concrets

Le premier cas est un écran blanc après connexion. Ne dites pas seulement “corrige le dashboard”. Donnez les étapes de reproduction, le résultat attendu, l’erreur console réelle, les fichiers modifiables et les commandes de vérification. L’agent cherchera davantage la cause racine au lieu de cacher le symptôme.

Le deuxième cas est l’ajout d’un champ “type de demande” à un formulaire de lead. Un bon prompt nomme les options, par exemple training, consulting et other, la règle de validation, le contrat API, l’événement analytics et l’attente de test. La monétisation reste protégée et le diff reste petit.

Le troisième cas est la génération d’article. Pour ClaudeCodeLab, le prompt doit préciser la profondeur, les exemples concrets, les pièges, les liens officiels, les liens internes, la CTA et le paragraphe final sur le résultat réel du test. Cela évite le résumé IA générique.

Petite grille QA pour prompts

Avant d’envoyer, notez votre prompt sur 10.

Points	Axe	Question
0-2	Périmètre	Les fichiers modifiables et protégés sont-ils clairs ?
0-2	Contexte	Ai-je inclus exemples locaux, lecteur et objectif business ?
0-2	Acceptation	L’agent peut-il savoir quand la tâche est finie ?
0-2	Vérification	Ai-je nommé commandes ou contrôles manuels ?
0-2	Passation	Ai-je précisé quoi rapporter à la fin ?

Huit points ou plus suffisent souvent. Cinq ou moins signifie que l’agent doit compenser un manque de contexte humain.

Générateur de brief exécutable

Au lieu de demander simplement « améliore ça », créez toujours le même format de brief. Ce script produit prompt-brief.md; modifiez le chemin et les critères d’acceptation avant de le donner à Claude Code ou Codex, afin que le périmètre, les contraintes et la vérification soient explicites dès le départ.

cat > prompt-brief.md <<'EOF'
# Task brief for Claude Code / Codex

Goal:
- Improve one article or feature without changing unrelated files.

Scope:
- May edit: site/src/content/blog/example.mdx
- Do not edit: hero images, routes, unrelated articles, billing code.

Context to read first:
- AGENTS.md
- A similar high-quality article
- The target file

Acceptance criteria:
- The intro explains who the reader is and why this matters.
- The draft includes at least three concrete examples.
- Code or prompt templates are copy-pasteable.
- Pitfalls and verification steps are explicit.
- Internal links and a natural CTA are included.

Verification:
- npm run build
- node scripts/check-code-fences.mjs
- Read the changed file once as a reviewer.

Return:
- What changed
- Checks run
- Remaining risks
EOF

CTA : transformer ces modèles en workflow

Vous n’avez pas besoin de réécrire ces règles chaque jour. Commencez par la cheatsheet Claude Code gratuite pour les commandes quotidiennes et les habitudes sûres. Pour des packs de prompts et du matériel de setup prêt à l’emploi, consultez ClaudeCodeLab products. Si votre équipe doit cadrer CLAUDE.md, permissions, review policy, verification receipts et rollout, la page Claude Code training and consultation est le bon point d’entrée.

Après avoir utilisé ce workflow sur de vrais articles et pages ClaudeCodeLab, le plus grand gain est venu du périmètre, des critères d’acceptation et des preuves de vérification écrits avant la modification. Les notes de passation ont aussi réduit le temps de review le lendemain, car la raison de chaque CTA et lien restait visible.