Le problème : prompt vague, code vague
Imaginez que vous demandez à un architecte : "Construis-moi une maison." Sans préciser le nombre de pièces, le terrain, le budget, le style... vous obtiendrez quelque chose, mais probablement pas ce que vous vouliez.
Avec l'IA, c'est pareil. La qualité de la réponse dépend directement de la qualité de la question. Un prompt vague produit du code générique. Un prompt structuré produit du code qui correspond exactement à votre besoin.
Voici un exemple concret :
Mauvais prompt
Fais-moi un formulaire de contact
Bon prompt (CRTSE)
Mon projet est un site vitrine PHP 8 pour un artisan plombier. Tu es un développeur senior spécialisé sécurité web. Crée un formulaire de contact avec validation côté serveur, protection CSRF et anti-spam honeypot. Code PSR-12, gestion d'erreurs complète. Voici la structure actuelle de mon HTML : [exemple]
Le premier prompt produit un formulaire HTML basique sans validation. Le second produit du code production-ready avec sécurité intégrée. Même IA, résultat radicalement différent.
Le framework CRTSE
Le framework CRTSE est une méthode simple pour structurer vos prompts. Cinq lettres, cinq éléments, zéro improvisation :
Les 5 éléments en détail
Contexte : Décrivez votre projet, votre stack technique, et vos contraintes. L'IA n'a aucune idée de votre environnement si vous ne lui dites pas. Un site WordPress et une API Node.js n'appellent pas le même code.
Rôle : Donner un rôle à l'IA change radicalement la qualité de sa réponse. "Tu es un développeur senior PHP spécialisé en sécurité" produit du code très différent de "tu es un assistant". Le rôle déclenche les bons réflexes : un expert sécurité pense aux injections SQL, un expert UX pense à l'accessibilité.
Tâche : Soyez spécifique et atomique. Une tâche = un prompt. Ne demandez pas "crée-moi un site complet" mais "crée la fonction de validation du formulaire de contact". Plus la tâche est précise, plus le résultat est utilisable.
Standards : Précisez vos exigences de qualité : gestion d'erreurs, conventions de code, tests, commentaires. Sans standards, l'IA produit du code qui marche mais qui n'est pas maintenable.
Exemples : Montrez votre style de code existant. L'IA reproduit ce qu'elle voit. Si vous lui donnez un exemple avec des noms de variables en français et des commentaires JSDoc, elle fera pareil.
L'erreur du prompt unique
Le piège classique : tout demander en un seul prompt. "Crée-moi une application de gestion de tâches complète avec authentification, base de données, API REST et interface."
Résultat ? Du code superficiel qui ne gère aucun cas limite. L'IA produit un prototype, pas une application.
La bonne approche : découper en tâches atomiques. Chaque prompt = une fonctionnalité précise, un fichier, une fonction. Vous gardez le contrôle, vous comprenez chaque morceau, et vous pouvez itérer sur chaque partie indépendamment.
Règle d'or : si votre prompt fait plus de 10 lignes, c'est qu'il essaie de faire trop de choses. Découpez-le.
The problem: vague prompt, vague code
Imagine asking an architect: "Build me a house." Without specifying the number of rooms, the land, the budget, the style... you will get something, but probably not what you wanted.
With AI, it is the same. The quality of the answer directly depends on the quality of the question. A vague prompt produces generic code. A structured prompt produces code that matches your exact needs.
Here is a concrete example:
Bad prompt
Make me a contact form
Good prompt (CRTSE)
My project is a PHP 8 brochure site for a plumber. You are a senior developer specialized in web security. Create a contact form with server-side validation, CSRF protection, and honeypot anti-spam. PSR-12 code, complete error handling. Here is my current HTML structure: [example]
The first prompt produces a basic HTML form with no validation. The second produces production-ready code with built-in security. Same AI, radically different result.
The CRTSE framework
The CRTSE framework is a simple method to structure your prompts. Five letters, five elements, zero improvisation:
The 5 elements in detail
Context — Describe your project, your tech stack, and your constraints. The AI has no idea about your environment unless you tell it. A WordPress site and a Node.js API do not call for the same code.
Role — Giving the AI a role radically changes the quality of its response. "You are a senior PHP developer specialized in security" produces very different code from "you are an assistant". The role triggers the right reflexes: a security expert thinks about SQL injections, a UX expert thinks about accessibility.
Task — Be specific and atomic. One task = one prompt. Do not ask "create me a complete site" but "create the validation function for the contact form". The more precise the task, the more usable the result.
Standards — Specify your quality requirements: error handling, code conventions, tests, comments. Without standards, the AI produces code that works but is not maintainable.
Examples — Show your existing code style. The AI reproduces what it sees. If you give it an example with French variable names and JSDoc comments, it will do the same.
The single-prompt mistake
The classic trap: asking for everything in one prompt. "Create me a complete task management app with authentication, database, REST API and interface."
Result? Superficial code that handles no edge cases. The AI produces a prototype, not an application.
The right approach: break it into atomic tasks. Each prompt = one precise feature, one file, one function. You keep control, you understand each piece, and you can iterate on each part independently.
Golden rule: if your prompt is more than 10 lines, it is trying to do too many things. Break it up.
Copiez ce prompt amélioré dans Claude et comparez avec le prompt basique 'Fais-moi un formulaire de contact' :
Contexte : Je développe un site vitrine en PHP 8 pour un artisan plombier. Le site utilise Bootstrap 5 et jQuery. Rôle : Tu es un développeur senior PHP spécialisé en sécurité web. Tâche : Crée un formulaire de contact avec nom, email, téléphone et message. Ajoute la validation côté serveur, la protection CSRF et un honeypot anti-spam. Standards : Code PSR-12, gestion d'erreurs avec try/catch, commentaires en français. Exemple : Voici comment je nomme mes variables : $user_name, $user_email (snake_case).
Sans relire le prompt copié plus haut : à quoi servent les lettres R (Rôle) et E (Exemples) de CRTSE, et pourquoi changent-elles concrètement le code produit ?
Rôle (« tu es un dev senior spécialisé sécurité ») oriente les réflexes du modèle (un expert sécurité pense CSRF, injections) au lieu de produire un code passe-partout. Les Exemples montrent ton style réel (nommage, conventions) : l'IA reproduit ce qu'elle voit, donc le code revient cohérent avec ta base au lieu d'imposer un style étranger.Un collègue te montre le prompt qu'il s'apprête à envoyer à l'IA. Ton rôle de relecteur : l'accepter tel quel ou le rejeter, et dire pourquoi.
Tu es un développeur senior PHP expert en sécurité.
Crée-moi toute l'authentification de mon site :
inscription, connexion, mot de passe oublié, vérification
email, rôles admin/user, et la base de données qui va avec.
Code propre et sécurisé.Rôle est bon, mais la Tâche n'est pas atomique : il demande inscription, connexion, reset, vérification email, rôles ET le schéma de base, le tout en un prompt. C'est exactement l'erreur du prompt unique : tu obtiendras un prototype superficiel qui ne gère aucun cas limite. Manquent aussi le Contexte précis (stack, version, framework existant) et un Exemple de style. Le bon réflexe : un prompt par brique (d'abord « crée la fonction d'inscription avec hachage du mot de passe et validation »), puis itérer.Le prompt ci-dessous est trop vague. Réécrivez-le en utilisant le framework CRTSE. Votre prompt doit contenir au moins : un contexte (projet/stack), un rôle, une tâche précise, des standards de qualité, et un exemple.
Sans remonter dans la leçon : que veulent dire les cinq lettres de CRTSE, dans l'ordre ?
C = Contexte (ton projet et ta stack), R = Rôle (l'expert que l'IA doit incarner), T = Tâche (une seule action, précise et atomique), S = Standards (qualité, conventions, tests), E = Exemples (ton style de code existant). L'idée clé : un prompt structuré produit du code adapté, un prompt vague produit du code générique.Vous savez maintenant structurer un prompt propre. Mais un bon prompt ne sert à rien si l'IA ignore tout de votre projet : la prochaine leçon, le context engineering, montre comment lui fournir le bon contexte (fichiers, conventions, contraintes) pour qu'elle réponde juste.
Leçon 2 : Context engineering →