Structure d’un bon prompt

8.1 Structure d’un bon prompt 🧱

Définition simple

Un bon prompt est une demande claire, contextualisée et suffisamment contrainte pour que Copilot comprenne ce que tu veux produire.

Un prompt faible dit :

Fais un truc.

Un bon prompt dit :

Fais cette tâche précise, dans ce contexte précis, avec ces contraintes précises, et explique le résultat.

Structure recommandée

Un bon prompt contient souvent 6 éléments :

1. Objectif
2. Contexte
3. Entrée ou code concerné
4. Contraintes
5. Format attendu
6. Critères de validation

Template générique

[Objectif]

Contexte :
[Explique le projet, le fichier, le framework, la règle métier]

Tâche :
[Ce que Copilot doit faire]

Contraintes :
- [ce qu’il doit respecter]
- [ce qu’il ne doit pas changer]
- [ce qu’il doit éviter]

Format attendu :
[code, plan, explication, tests, tableau, diff...]

Validation :
[tests à ajouter, edge cases, comportement attendu]

Exemple mauvais prompt ❌

Refactor this.

Problème :

• trop vague ;
• pas d’objectif ;
• pas de contrainte ;
• pas de limite ;
• risque de modifier le comportement ;
• pas de demande de tests.

Bon prompt ✅

Refactor the selected TypeScript function to improve readability.

Constraints:
- Do not change the public function signature.
- Preserve the current behavior.
- Do not introduce new dependencies.
- Keep error messages unchanged.

After refactoring:
- Explain what changed.
- Suggest Jest tests for edge cases.

Pourquoi c’est mieux ?

• objectif clair : améliorer la lisibilité
• périmètre clair : fonction sélectionnée
• contraintes claires : signature, comportement, dépendances
• validation : tests et explication

Exemple orienté sécurité 🔐

Mauvais prompt :

Make this secure.

Bon prompt :

Review the selected Express route for security issues.

Focus on:
- authentication
- authorization
- input validation
- SQL injection
- sensitive data in logs
- error messages

Return:
- risks found
- severity
- explanation
- recommended fix

Exemple orienté tests 🧪

Mauvais prompt :

Write tests.

Bon prompt :

Generate pytest unit tests for the selected function.

Cover:
- valid input
- empty input
- invalid input
- boundary values
- expected exceptions

Constraints:
- Do not modify production code.
- Follow the style of the existing test file.
- Explain why each test is useful.

Cadrer avec un rôle

Le role prompting demande à Copilot d’adopter un point de vue d’expert. Il cadre la perspective : quels risques regarder, quel vocabulaire employer.

Act as a security reviewer.
Review the selected Express route for authentication and input validation issues.
Return severity, explanation, and a recommended fix.

Le rôle ne remplace ni l’objectif, ni le contexte, ni les contraintes, ni le format attendu, ni la validation : « Act as a senior engineer. Fix this. » reste un prompt vague. Il ne forme pas un septième élément, il cadre les six autres.

Microsoft Learn résume les bases en « 4 Ss » : Single (une seule tâche, donc l’objectif), Specific (explicite, donc contraintes et format), Short (concis, sans bruit) et Surround (fichiers ouverts et noms parlants, donc le contexte). Ce sont les mêmes idées, sous d’autres noms.

8.2 Donner un objectif clair 🎯

Définition

L’objectif est ce que tu veux vraiment obtenir.

Copilot ne doit pas deviner si tu veux :

• comprendre ;
• corriger ;
• refactorer ;
• optimiser ;
• sécuriser ;
• tester ;
• documenter ;
• migrer ;
• planifier.

Exemple vague ❌

Improve this code.

“Improve” peut vouloir dire :

• plus rapide
• plus lisible
• plus sécurisé
• plus court
• plus typé
• plus moderne
• plus testable

Copilot peut choisir une direction qui n’est pas la tienne.

Exemple clair ✅

Improve the readability of the selected function without changing its behavior.

ou :

Optimize this function for performance while preserving the same output for all existing test cases.

ou :

Make this endpoint safer by adding input validation and authorization checks.

Exemple comparatif

Objectif flou

Fix the API.

Objectif clair

Fix the bug where the API returns 500 when the request body is missing the optional filters field.
Preserve the response format.
Add a test for the missing filters case.

Objectifs fréquents avec Copilot

Comprendre

Explain this function step by step.
Identify inputs, outputs, side effects, and edge cases.

Corriger

Find the root cause of this failing test and propose the minimal fix.

Refactorer

Refactor this function to reduce duplication while preserving behavior.

Tester

Generate unit tests covering normal cases, invalid inputs, and edge cases.

Sécuriser

Review this code for authentication, authorization, injection, and sensitive logging issues.

Planifier

Create an implementation plan before modifying code.

Which prompt is most effective for improving code quality without changing behavior?

Improve this code.

Refactor the selected code to improve readability and reduce duplication without changing behavior. Keep the public API unchanged and suggest tests.

8.3 Ajouter des contraintes 🧷

Définition

Les contraintes sont les règles que Copilot doit respecter.

Elles évitent que Copilot parte dans une mauvaise direction.

Types de contraintes utiles

Contraintes techniques

• Use TypeScript strict mode.
• Use pytest.
• Use JUnit 5 and Mockito.
• Use async/await.
• Do not use new dependencies.

Contraintes de comportement

• Preserve current behavior.
• Do not change the public API.
• Keep response format unchanged.
• Maintain backward compatibility.

Contraintes sécurité

• Do not hardcode secrets.
• Validate external input.
• Use parameterized queries.
• Apply least privilege.

Contraintes de scope

• Modify only the selected function.
• Do not edit tests yet.
• Do not change database schema.
• Do not modify files outside src/.

Contraintes de format

• Return only the code.
• Return a step-by-step plan.
• Return a table of risks.
• Include explanation and tests.

Exemple sans contraintes ❌

Add authentication to this API.

Copilot pourrait :

• choisir une mauvaise librairie ;
• modifier trop de fichiers ;
• stocker un secret en clair ;
• changer les réponses API ;
• ignorer les tests ;
• introduire un flow non désiré.

Exemple avec contraintes ✅

Add authentication middleware to this Express API.

Constraints:
- Use the existing JWT verification utility in auth/jwt.ts.
- Do not introduce new dependencies.
- Do not change existing route handlers unless required.
- Return 401 for missing or invalid tokens.
- Return 403 for valid tokens without required role.
- Add Jest tests for both cases.

Exemple cloud/dev

Mauvais prompt :

Create an IAM policy for this app.

Bon prompt :

Create a least-privilege AWS IAM policy for this service.

The service only needs to:
- read objects from s3://app-prod-reports/*
- write logs to CloudWatch Logs

Constraints:
- Avoid wildcard actions.
- Avoid wildcard resources.
- Explain each permission.