Opus 4.7 est sorti hier 16 avril 2026. Parmi les ajustements à faire sur ses workflows, affiner ses prompts pour tirer le meilleur du modèle reste l’investissement le plus rentable. Voici 8 règles concrètes que j’applique au quotidien.
Règle 1 : le contexte avant la demande
Ordre qui marche : contexte, contrainte, demande. “Voici la codebase (contexte). Nous visons X (contrainte). Je veux que tu fasses Y (demande).”
L’ordre inverse (demande avant contexte) dilue l’attention sur la tâche. Sur 4.7 qui a un reasoning plus dense, la différence se voit.
Règle 2 : un critère d’acceptation explicite
“Fais X” est trop vague. “Fais X tel que Y est vrai, Z est respecté, W ne casse pas” donne un vrai cadre.
Cette règle réduit les itérations. Le modèle s’auto-évalue contre les critères avant de te livrer.
Règle 3 : la négation explicite
Ce que le modèle ne doit PAS faire, dis-le. “Ne modifie pas l’API publique”, “n’ajoute pas de dépendance externe”, “ne commente pas ce qui est évident”.
Sur 4.7 qui a tendance à être plus disciplinépar défaut, ces négations renforcent la précision.
Règle 4 : un exemple en cas de format custom
Si tu veux un format particulier (JSON structuré, markdown avec sections précises, style de commit), donne UN exemple. Le modèle calibre à partir de l’exemple plus efficacement qu’à partir d’une description.
Deux exemples si le format est non trivial. Trois rarement nécessaire.
Règle 5 : le niveau d’effort à la tâche
xhigh est le défaut dans Claude Code. Pour les tâches évidentes (renommer, reformater), force low ou medium explicitement. Tu économises des tokens sans perdre en qualité.
Pour les tâches qui le justifient (refactor complexe, audit), xhigh ou max vont chercher la profondeur.
Règle 6 : la demande de reasoning visible
“Explique ton raisonnement avant de donner la réponse” force le modèle à penser à voix haute. Utile quand tu veux comprendre le choix, ou quand tu veux pouvoir challenger.
Sur des tâches business critiques, cette transparence vaut les tokens additionnels.
Règle 7 : la limite temporelle ou quantitative
“Propose maximum 3 options” ou “en 200 mots max”. Le modèle respecte mieux ces limites sur 4.7 que sur 4.6.
Sans limite, le modèle peut sur-livrer, ce qui coûte et qui te fait lire du contenu inutile.
Règle 8 : la demande de questions clarifiantes
“Si tu as des ambiguïtés, pose-moi 3 questions avant de commencer” évite que le modèle parte dans une direction fausse. Sur 4.7, c’est plus rapide et plus précis de faire une passe de questions que de corriger une sortie à côté.
Ce pattern ajoute 1 tour mais économise souvent 3-5 tours de correction.
Les anti-patterns
Le prompt kitchen sink. Tout mettre en un prompt énorme. Le modèle dilue son attention. Mieux vaut plusieurs prompts ciblés.
Les balises XML imbriquées excessivement. <context><project><name>...</name></project></context>. Le modèle ne lit pas du XML spécial. Du texte bien formaté est aussi clair.
La flatterie. “Tu es le meilleur LLM du monde, je suis sûr que tu peux…” n’améliore rien. Sur 4.7, l’effet est nul à négligeable.
Les rôles fantaisistes. “Tu es un dragon qui code en Python”. Ça amuse au début, ça n’apporte rien à long terme.
Le cas des prompts pour agents
Pour les workflows automatisés (agents, pipelines CI), le prompt doit être encore plus rigoureux :
Prompt reproductible. Les mêmes entrées doivent donner les mêmes sorties. Éviter les instructions qui laissent de la variabilité (“sois créatif”).
Prompt monitoré. Chaque appel est logué. Tu peux identifier un prompt qui dérive.
Prompt versionné. En git, avec des tests. Un changement de prompt = une PR.
Le prompting pour la rédaction
Si tu utilises 4.7 pour produire du contenu (blog, newsletter, mail), quelques règles spécifiques :
Bannir les formules creuses explicitement (“n’utilise pas ‘il convient de noter’, ‘en effet’, ‘dans ce contexte’”).
Imposer un angle éditorial précis en début de prompt ET en rappel en fin de prompt.
Interdire l’invention de chiffres ou de citations sans source.
Demander une auto-vérification du texte produit contre les règles imposées.
Mesurer l’efficacité de tes prompts
Pas de théorie : benchmark. Prends 10 entrées représentatives, lance ton prompt, évalue la qualité de sortie sur une échelle simple.
Fais varier ton prompt sur un seul critère à la fois. Tu identifies rapidement ce qui marche sur ton cas.
En 2-3 heures de benchmark par prompt critique, tu optimises significativement tes workflows.
FAQ
Ces règles valent-elles pour tous les modèles ? Les principes oui. Les détails (niveaux d’effort, adaptive thinking) sont spécifiques à Claude 4.7.
Combien de temps pour devenir bon en prompting ? 2 à 4 semaines de pratique régulière. C’est un skill comme un autre.
Les formations au prompting valent-elles le coup ? Les gratuits et les bons tutos publics suffisent pour les bases. Pour la sophistication, c’est surtout l’expérience.
Je dirige Linkuma, plateforme de netlinking low cost avec 40 000 sites au catalogue et 15 000 clients. On maintient une bibliothèque de prompts versionnés pour nos différents agents. Retours terrain sur linkuma.com, promos hebdo sur deals.linkuma.com.