Ce Prompt Vous Obtient des Revues de Code de Senior Engineer Depuis N'importe Quelle IA
Why this prompt matters
Generic 'review my code' prompts produce generic responses: vague suggestions, no line references, no prioritisation. This prompt enforces a specific output structure that separates critical bugs from architecture concerns from style improvements — the same mental model a senior engineer uses when reviewing a PR. The 'What's Done Well' section is intentional: it keeps the feedback calibrated and makes it easier to act on criticism when you also know what to preserve.
What we use it for
Developers who want high-quality code review feedback without blocking on a colleague's availability. Works for any language or framework — paste the function, class, or diff and get structured, specific feedback in seconds.
Prompt
You are a senior software engineer with 15+ years of experience across production systems. Review the following code as if you were doing a thorough pull request review. Structure your feedback exactly as follows: **Critical Issues** (bugs, security vulnerabilities, data loss risks, race conditions): For each: state the line number, explain precisely why it's a problem, and show the corrected code. **Architecture Concerns** (things that will cause problems at scale or make the code hard to maintain): 1–3 observations about structural decisions that should be reconsidered. Be specific about the failure mode. **Improvements** (performance, readability, maintainability — things that don't change behaviour but make the code better): Practical, specific suggestions. Reference line numbers. Show before/after where relevant. **What's Done Well**: 2–3 specific things the author got right. Skip this section only if there is genuinely nothing positive to note. Rules: Be direct. Use line numbers. Show corrected code snippets — do not just describe the fix. Do not use phrases like "consider refactoring" or "you might want to" — say exactly what to change and why. [PASTE YOUR CODE HERE]
Demander à une IA de "review my code" produit à chaque fois le même résultat générique : une liste d'éléments à considérer, sans priorisation, sans références de lignes, et des conseils qui pourraient s'appliquer à n'importe quelle base de code. Le prompt ci-dessous résout ce problème en imposant la structure exacte qu'un senior engineer utilise lors d'une vraie revue de Pull Request.
Le prompt
You are a senior software engineer with 15+ years of experience across production systems. Review the following code as if you were doing a thorough pull request review. Structure your feedback exactly as follows:
**Critical Issues** (bugs, security vulnerabilities, data loss risks, race conditions):
For each: state the line number, explain precisely why it's a problem, and show the corrected code.
**Architecture Concerns** (things that will cause problems at scale or make the code hard to maintain):
1–3 observations about structural decisions that should be reconsidered. Be specific about the failure mode.
**Improvements** (performance, readability, maintainability — things that don't change behaviour but make the code better):
Practical, specific suggestions. Reference line numbers. Show before/after where relevant.
**What's Done Well**:
2–3 specific things the author got right. Skip this section only if there is genuinely nothing positive to note.
Rules: Be direct. Use line numbers. Show corrected code snippets — do not just describe the fix. Do not use phrases like "consider refactoring" or "you might want to" — say exactly what to change and why.
[PASTE YOUR CODE HERE]Comment l'utiliser
Remplacez [PASTE YOUR CODE HERE] par la fonction, la classe, le module ou le diff que vous souhaitez voir relire. Fonctionne mieux avec Claude Sonnet, GPT-4o et Gemini 2.5 Pro — tous disposent d'une fenêtre de contexte suffisante pour traiter des fichiers de quelques centaines de lignes sans nécessité de les découper.
Pour les fichiers volumineux, collez la section la plus critique (la fonction avec le bug, la nouvelle classe, la méthode modifiée) plutôt que le fichier entier. Si le contexte est important, ajoutez une brève description avant le code : "Ceci est un middleware Express.js en Node.js qui gère l'authentification. Le schéma de base de données pertinent est users(id, email, password_hash, role)."
Pourquoi la structure est importante
La structure en quatre sections correspond à la façon dont les ingénieurs expérimentés priorisent le feedback. Les Critical Issues sont bloquants — ils doivent être corrigés avant le merge. Les Architecture Concerns ne sont pas bloquants aujourd'hui mais le deviennent à l'échelle. Les Improvements sont pour la passe optionnelle. Séparer ces éléments empêche le mode d'échec courant des revues de code par IA où un détail de style reçoit le même poids qu'une vulnérabilité SQL injection.
L'instruction de montrer le code corrigé (pas seulement décrire la correction) est la contrainte la plus importante. Sans elle, les réviseurs IA ont tendance à pointer le problème — "la gestion des erreurs pourrait être améliorée ici" — sans vous dire quoi taper. L'exigence de code corrigé force la spécificité.
Adaptation pour des contextes spécifiques
Ajoutez du contexte en haut du prompt pour de meilleurs résultats : spécifiez le langage et le framework, l'environnement de déploiement (serverless, conteneurs, embarqué), les contraintes de performance ou les conventions d'équipe. Pour du code sensible à la sécurité, ajoutez "Portez une attention particulière à la validation des entrées, aux injections SQL, aux XSS et aux cas limites d'authentification" dans la section Critical Issues. Pour les chemins critiques en performance, ajoutez "la fonction est appelée 10 000 fois par seconde en production."
Le prompt fonctionne dans n'importe quel langage de programmation. Il a été testé sur Python, TypeScript, Go, Rust, Java et SQL avec des résultats cohérents sur les trois modèles frontière.