Le prompt engineering pour développeurs n'est pas l'art d'écrire des phrases magiques. C'est l'art de donner à une IA les bonnes informations, dans le bon ordre, avec des critères de réussite vérifiables.
Un bon prompt ne garantit pas un bon code, mais il réduit fortement les réponses inutiles, les suppositions et les changements hors périmètre. Dans un workflow professionnel, c'est une compétence aussi concrète que savoir écrire un ticket clair.
1. Commencer par le résultat attendu
Un prompt efficace commence par l'objectif, pas par le contexte.
Mauvais exemple :
Voici mon projet, regarde ce que tu peux améliorer.
Meilleur exemple :
Ajoute une validation côté serveur pour empêcher la création d'un compte avec une adresse email déjà utilisée.
L'IA doit comprendre ce qui sera considéré comme terminé.
2. Définir le périmètre
Plus le périmètre est large, plus le résultat est risqué. Indique les fichiers concernés, les modules à éviter et les comportements à préserver.
Travaille uniquement dans le dossier src/auth.
Ne modifie pas le schéma de base de données.
Préserve l'API publique existante.
Cette précision limite les refactorisations inutiles.
3. Demander un plan avant le code
Pour une tâche non triviale, demande d'abord un plan. Cela permet de vérifier la compréhension avant modification.
Propose un plan court avant de modifier le code.
Liste les fichiers concernés et les tests à exécuter.
Un plan faible annonce souvent un résultat faible.
4. Donner un exemple d'entrée et de sortie
Les exemples réduisent les ambiguïtés.
Entrée : "Jean DUPONT"
Sortie attendue : "jean-dupont"
Les accents doivent être normalisés.
Pour les fonctions de formatage, parsing, validation ou transformation de données, c'est indispensable.
5. Forcer la prise en compte des erreurs
Les IA produisent souvent le chemin heureux. Demande explicitement les cas limites.
Inclue les cas d'erreur : entrée vide, valeur null, format invalide, doublon, timeout API.
Un code robuste se juge aussi à ce qu'il refuse.
6. Demander des tests ciblés
Un prompt de code sans tests est incomplet dès que la tâche touche un comportement réel.
Ajoute des tests unitaires pour le comportement nominal et trois cas d'erreur.
Ne modifie pas les snapshots existants sauf nécessité expliquée.
Les tests donnent à l'agent un signal de réussite objectif.
7. Séparer analyse et exécution
Pour un bug, ne demande pas immédiatement une correction. Demande d'abord une hypothèse.
Analyse cette erreur et donne les trois causes les plus probables.
Ne modifie aucun fichier pour l'instant.
Cela évite les corrections opportunistes qui masquent le vrai problème.
8. Encadrer le style de code
Les IA peuvent introduire un style différent du reste du projet. Indique la convention à suivre.
Respecte les patterns existants du projet.
N'ajoute pas de nouvelle dépendance.
Utilise les helpers déjà présents si possible.
Le meilleur code généré est celui qui ressemble à une contribution naturelle au dépôt.
9. Demander une justification du diff
Après génération, demande une explication courte des changements.
Résume les changements par fichier et explique comment les tester.
Cette étape facilite la revue humaine.
10. Utiliser l'IA pour critiquer son propre résultat
Une deuxième passe de revue peut détecter des oublis.
Relis ton changement comme un reviewer senior.
Cherche les bugs, régressions, problèmes de sécurité et tests manquants.
Il ne faut pas tout croire, mais c'est une bonne aide.
11. Donner des contraintes négatives
Dire ce qu'il ne faut pas faire est parfois aussi important que dire quoi faire.
Ne change pas l'UI.
Ne renomme pas les fonctions publiques.
Ne modifie pas la configuration globale.
Ne reformate pas les fichiers non concernés.
Les contraintes négatives réduisent le bruit dans les diffs.
12. Travailler en petits lots
Un prompt géant produit rarement un résultat maîtrisable. Découpe la tâche.
Exemple :
- analyser le module ;
- proposer le plan ;
- modifier la validation ;
- ajouter les tests ;
- relire le diff ;
- préparer la documentation.
Chaque étape devient contrôlable.
Conclusion
Le prompt engineering utile aux développeurs ressemble à une bonne spécification de tâche : objectif clair, contexte pertinent, contraintes, exemples, tests et validation.
La compétence clé n'est pas de parler à l'IA comme à une machine mystérieuse. C'est de collaborer avec elle comme avec un développeur rapide, mais parfois trop confiant.
FAQ
Faut-il écrire des prompts très longs ?
Pas forcément. Un prompt court mais précis vaut mieux qu'un long prompt rempli de contexte inutile.
Quel est le meilleur prompt pour générer du code ?
Il n'existe pas de prompt universel. Le meilleur prompt décrit le résultat attendu, le périmètre, les contraintes et les tests.
L'IA peut-elle écrire les tests elle-même ?
Oui, mais il faut relire les tests. Un test généré peut vérifier l'implémentation actuelle au lieu de vérifier le vrai comportement attendu.
Sources et lectures utiles
- GitHub Copilot documentation : Documentation officielle GitHub Copilot
- Cursor best practices : Cursor : bonnes pratiques pour les agents
- OpenAI Codex : Documentation OpenAI Codex cloud
