Intelligence Artificielle angularforall.com

- Prompt Engineering : obtenir les meilleures réponses IA

Ia Prompt-Engineering Chatgpt Claude Productivite Llm Prompts-Avances Few-Shot Chain-Of-Thought Role-Prompting Ia-Generative Openai Anthropic Best-Practices
Prompt Engineering : obtenir les meilleures réponses IA

Apprenez à écrire des prompts efficaces pour les LLM : structure, contexte, contraintes, format de sortie et techniques de raffinement pour des résultats précis.

Anatomie d'un prompt efficace — les 5 composantes

Un prompt performant n'est pas une phrase complexe — c'est un cadre structuré qui donne au modèle les informations nécessaires pour répondre précisément. Les 5 composantes couvrent les besoins de 95% des cas.

ComposanteDescriptionObligatoire ?
RôleQui doit être le modèle (expert, formateur, revieweur...)Recommandé
ContexteStack technique, contraintes projet, niveau de l'audienceOui
TâcheCe qui est attendu, explicite et mesurableOui (obligatoire)
ContraintesTon, longueur, ce qu'il ne faut PAS faireRecommandé
Format de sortieJSON, liste, tableau, code, étapes numérotéesRecommandé
# Exemple complet avec les 5 composantes

RÔLE: Tu es un senior développeur Angular 19 spécialisé en accessibilité.

CONTEXTE: Application Angular 19 avec Angular Material.
La cible est une équipe de 5 devs, dont 2 juniors.
Le projet doit être conforme RGAA (accessibilité française).

TÂCHE: Explique comment implémenter un composant de dialog modal
accessible (focus trap, Escape, aria-labelledby, aria-describedby).

CONTRAINTES:
- Code uniquement avec Angular CDK Dialog (pas MatDialog)
- TypeScript strict mode activé
- Pas de dépendances npm tierces
- Max 80 lignes de code

FORMAT: 1) Explication courte du pourquoi (3 lignes max)
         2) Code complet avec commentaires d'accessibilité
         3) Liste de vérification manuelle (6 items max)

Techniques fondamentales — Zero-shot, Few-shot, Chain-of-Thought

Zero-shot — demande directe sans exemple

# Zero-shot : le modèle répond sans exemple préalable
# Efficace pour les tâches standards bien couvertes par l'entraînement

"Génère un schéma SQL pour une table 'orders' avec colonnes :
id (UUID), customer_id (FK), status (enum), total (decimal 10,2),
created_at, updated_at. PostgreSQL 16 avec indexes appropriés."

Few-shot — guider avec des exemples

# Few-shot : fournir 2-5 exemples avant la vraie demande
# Idéal pour homogénéiser le format ou le style de réponse

"Convertis ces noms de propriétés snake_case en camelCase.

Exemples:
user_id → userId
first_name → firstName
created_at → createdAt

À convertir:
order_reference
shipping_address_line_1
payment_method_type"

Chain-of-Thought (CoT) — forcer le raisonnement étape par étape

# Chain-of-Thought : demander de réfléchir à voix haute avant de conclure
# Réduit drastiquement les erreurs sur les tâches complexes

"Analyse ce bug Angular et résous-le étape par étape.

Code:
@Component({
  template: '{{ user.name }}'
})
class UserComponent {
  user: User; // Pas initialisé
}

Erreur: TypeError: Cannot read properties of undefined (reading 'name')

Raisonne d'abord sur les 3 causes possibles, élimine-les une par une,
puis fournis la solution avec le code corrigé."
Chain-of-Thought avec "Pense étape par étape" : simplement ajouter "Réfléchis étape par étape avant de répondre" améliore la précision de 20-40% sur les tâches analytiques selon les benchmarks de recherche (GSM8K, BBH).

Prompts pour la génération de code fiable

La génération de code nécessite des contraintes spécifiques pour éviter le code générique, non testé ou incompatible avec le projet.

Template de prompt pour une nouvelle feature

RÔLE: Tu es senior développeur [STACK].
Tu respectes les conventions du projet décrit ci-dessous.

CONTEXTE PROJET:
- Framework: [Angular 19 / React 18 / Vue 3]
- Gestionnaire d'état: [Signals / Zustand / Pinia]
- Tests: [Jest + Testing Library]
- Style: [SCSS modules / Tailwind / Bootstrap 5]
- Conventions importantes: [ex: tout service injecté dans le constructeur, pas en field injection]

CONTRAINTES:
- TypeScript strict mode (pas de 'any' implicite)
- Aucun import de lib non listée dans package.json
- Code commenté seulement sur les parties non évidentes
- Pas de console.log dans le code final

TÂCHE: [Description précise de la feature]

LIVRABLE:
1. Arborescence des nouveaux fichiers
2. Code complet de chaque fichier
3. Tests unitaires pour la logique métier
4. Points d'intégration à vérifier manuellement

Prompt pour un code review automatisé

RÔLE: Tu es un revieweur senior spécialisé en sécurité web et performance.

TÂCHE: Analyse le code ci-dessous et identifie les problèmes.

FORMAT DE SORTIE (JSON strict):
{
  "critical": [{"line": 0, "issue": "", "fix": ""}],
  "warning": [{"line": 0, "issue": "", "fix": ""}],
  "suggestion": [{"line": 0, "issue": "", "fix": ""}]
}

CRITÈRES D'ANALYSE:
- Sécurité : injections, XSS, exposition de secrets
- Performance : N+1 queries, boucles inefficaces, mémoire
- Maintenabilité : couplage fort, fonctions trop longues
- TypeScript : any implicite, cast dangereux

CODE À ANALYSER:
[COLLER LE CODE ICI]

Prompts pour la revue et la correction de code

# Débogage guidé — fournir tout le contexte nécessaire
"Ce code Node.js crash avec l'erreur suivante. Identifie la cause racine
et propose un fix minimal qui ne change pas l'API publique.

ERREUR: UnhandledPromiseRejection: Cannot read properties of undefined

STACK TRACE:
[COLLER LE STACK TRACE]

CODE (fichier complet):
[COLLER LE CODE]

CONTEXTE:
- Node.js 20 LTS
- L'erreur se produit seulement sous charge (>100 req/s)
- Le code fonctionnait correctement avant le dernier déploiement"
# Refactor guidé — contraindre le scope du changement
"Refactorise cette fonction pour la rendre plus lisible et testable.

CONTRAINTES STRICTES:
- Ne pas changer la signature de la fonction (inputs/outputs)
- Ne pas introduire de nouvelles dépendances
- Conserver la compatibilité avec Node.js 18+
- Les tests existants doivent toujours passer

OBJECTIF: réduire la complexité cyclomatique (actuellement 12, cible ≤ 5)

FONCTION:
[COLLER LE CODE]"

Roleplay et persona — quand ça améliore les résultats

Assigner un rôle précis améliore la qualité des réponses en activant un "mode" spécialisé du modèle. Mais le rôle doit être spécifique et pertinent — un rôle vague n'aide pas.

# Rôles efficaces vs inefficaces

# INEFFICACE — trop vague
"Tu es un expert en développement"

# EFFICACE — spécifique + contexte
"Tu es un ingénieur SRE chez une startup fintech avec 500k utilisateurs.
Tu es obsédé par la résilience des systèmes distribués.
Ton équipe travaille avec Kubernetes, ArgoCD et Prometheus."

# EXEMPLES DE RÔLES TRÈS EFFICACES:
# "Tu es un architecte TypeScript qui maintient des codebases de 500k LOC"
# "Tu es un spécialiste RGPD qui doit valider des implémentations techniques"
# "Tu es un développeur Angular qui fait des code reviews pour des juniors"
# "Tu es un DBA PostgreSQL qui optimise des requêtes sur des tables de 100M lignes"

Contrôler le format de sortie — JSON, Markdown, XML

# Forcer JSON — pour l'intégration automatisée
"Analyse ce texte et retourne UNIQUEMENT un JSON valide (aucun texte avant ou après).
Format exact:
{
  \"intent\": \"question|task|feedback\",
  \"language\": \"fr|en\",
  \"urgency\": \"low|medium|high\",
  \"topics\": [\"string\"],
  \"summary\": \"string (max 100 chars)\"
}"

# Forcer un format de table Markdown
"Compare ces 4 bases de données en table Markdown.
Colonnes: Base de données, Use case idéal, Complexité d'installation,
Coût (free/paid), Scalabilité horizontale (oui/non).
Bases: PostgreSQL, MongoDB, Redis, Cassandra."

# Forcer XML pour un parseur existant
"Génère la configuration nginx pour un reverse proxy vers Node.js.
Retourne en XML strict:
<config><server_name /><upstream /><ssl enabled=\"\" /></config>"
Tip Claude API : pour forcer le JSON de manière fiable avec l'API Anthropic, commence la réponse du modèle avec { dans le champ assistant de la conversation — le modèle complète depuis ce point, garantissant un JSON valide.

Itération et raffinement — les 3 passes

# PASSE 1 : Génération initiale (version brouillon)
"Écris une fonction TypeScript qui valide un email."

# PASSE 2 : Critique — demander au modèle de s'auto-évaluer
"Relis ta réponse précédente et identifie :
1. Les edge cases non gérés (emails internationaux, sous-domaines, etc.)
2. Les regex potentiellement vulnérables au ReDoS
3. Ce qui manque pour être production-ready"

# PASSE 3 : Révision guidée par la critique
"En tenant compte de ta critique, réécris la fonction avec :
- Gestion des RFC 5321 et RFC 5322
- Protection ReDoS (pas de backtracking catastrophique)
- Tests unitaires pour les 10 cas limites identifiés
- Performance : capable de valider 10 000 emails/s"

Bibliothèque de prompts — gestion en équipe

# Structure recommandée pour un dépôt de prompts en équipe

prompts/
├── README.md              # Guide d'utilisation
├── code-review/
│   ├── security-audit.md  # Audit sécurité
│   ├── performance.md     # Review performance
│   └── typescript.md      # Review TypeScript strict
├── generation/
│   ├── angular-component.md
│   ├── api-endpoint.md
│   └── test-suite.md
├── debugging/
│   ├── crash-analysis.md
│   └── memory-leak.md
└── documentation/
    ├── jsdoc.md
    └── readme-generator.md

# Chaque fichier prompt contient :
# - Version (semver)
# - Modèle testé (claude-3.5-sonnet, gpt-4o...)
# - Score de qualité moyen (1-5)
# - Date de dernière validation
# - Exemples d'input/output

Erreurs courantes et anti-patterns

  • Prompt trop vague : "Améliore mon code" → sans critères, le modèle change ce qu'il ne faut pas changer
  • Pas de contexte stack : le modèle génère pour sa version de référence, pas la vôtre
  • Demandes multiples : combiner 5 tâches dans un prompt réduit la qualité de chacune — diviser en 5 prompts séquentiels
  • Ignorer le premier essai : souvent, la première réponse est un brouillon — itérer est standard, pas exceptionnel
  • Trop de contraintes contradictoires : "sois bref ET exhaustif" — choisir une priorité claire
  • Pas de format imposé : le modèle choisit un format arbitraire, difficile à parser ou réutiliser
Checklist avant d'envoyer un prompt :
  • Le contexte technique (stack, versions) est-il précisé ?
  • La tâche attendue est-elle explicite et mesurable ?
  • Le format de sortie est-il imposé ?
  • Les contraintes (ce qu'il ne faut PAS faire) sont-elles claires ?
  • Ai-je prévu une passe de critique/révision ?

Partager