Configuration IDE pour le prompt engineering
📍 In One Sentence
Cursor et VS Code avec Continue.dev sont les deux IDEs qui couvrent la plupart des besoins de prompt engineering des développeurs, avec Cursor pour les workflows API cloud et Continue.dev pour les exigences open source et modèles locaux.
💬 In Plain Terms
Choisissez l'IDE où vous passez déjà le plus de temps. Si vous utilisez TypeScript ou Python et appelez des APIs cloud, Cursor ajoute le moins de friction. Si vous devez exécuter des modèles localement ou avez des exigences open source, VS Code avec Continue.dev est le bon choix.
Deux IDEs couvrent la plupart des besoins de prompt engineering des développeurs : Cursor (intégration IA native, prompts comme citoyens de première classe) et VS Code avec Continue.dev (open source, prise en charge de modèles locaux). Le choix dépend de votre langage principal et de vos exigences d'accès aux modèles.
Cursor traite les fichiers de prompt nativement — vous pouvez référencer, modifier et tester des prompts directement dans l'éditeur aux côtés de votre code d'application. Il a une intégration native avec les APIs compatibles OpenAI et supporte bien TypeScript et Python.
VS Code avec Continue.dev est open source, prend en charge les modèles locaux via Ollama et fonctionne avec tout écosystème de langage. Continue.dev fournit la complétion et la modification de prompts dans l'éditeur. Utilisez VS Code + Continue.dev pour les exigences open source ou si vous devez exécuter des modèles localement.
💡 Cursor pour la vitesse d'itération
Cursor permet d'exécuter Claude 4.6 Sonnet directement sur les fichiers de prompt depuis l'éditeur. Cela réduit le cycle écriture-test de minutes à secondes pour les équipes utilisant déjà Cursor pour le code.
La boucle de test locale
La boucle de test de prompt locale comporte 4 étapes : écrire le prompt, le tester sur 3 entrées représentatives, comparer avec la baseline et committer si ça passe. Cette boucle devrait prendre moins de 30 secondes avec Promptfoo configuré localement.
Étape 1 : Écrire ou modifier le prompt dans votre IDE. Étape 2 : Exécuter le prompt sur 3 entrées représentatives — une entrée typique, un cas limite et une qui a précédemment causé une défaillance. Étape 3 : Comparer la sortie avec la baseline. Étape 4 : Si la qualité se maintient ou s'améliore, committer avec un message conventionnel.
Pour configurer Promptfoo pour la boucle locale : installer avec `npm install -g promptfoo`, créer un `promptfooconfig.yaml` dans la racine du projet avec 3 cas de test et un évaluateur LLM-as-judge. Exécuter `promptfoo eval`. Le temps de configuration total est inférieur à 15 minutes.
⚠️ La comparaison de baseline n'est pas optionnelle
Sans comparaison à une baseline, un prompt qui se dégrade sur les cas limites peut quand même "réussir" si le seuil absolu est suffisamment bas. Toujours comparer à la dernière version déployée.
Stocker les prompts dans le contrôle de version
Stocker les prompts en tant que fichiers `.txt` ou `.ts` dans un répertoire `/prompts` à la racine du dépôt. Versionner les prompts dans Git donne les mêmes avantages que versionner du code : historique complet, blame, rollback et révision basée sur les PR.
Convention de nommage : `tâche-version.txt` — par exemple `support-client-v3.txt`, `brouillon-email-v1.txt`. Utiliser des numéros de version séquentiels, pas des dates. Déplacer les prompts retirés dans `/prompts/archive/` plutôt que de les supprimer.
Format de commit pour les modifications de prompts : utiliser les commits conventionnels. Ajouter des tags Git pour chaque version déployée avec succès en production : `prompts/tâche/version`.
📌 Les prompts sont du code
Traiter les fichiers de prompt avec la même discipline que les fichiers de code : revue PR, auteurs nommés, versionnage sémantique et ne jamais supprimer — déplacer dans /prompts/archive/ à la place.
Gates CI/CD pour les prompts
Ajouter un workflow GitHub Actions qui exécute Promptfoo ou Braintrust à chaque pull request et fait échouer le build si le taux de réussite descend en dessous d'un seuil. Commencer le seuil à 85% et augmenter à 95% après 3 mois de tests stables.
Structure du workflow GitHub Actions : créer `.github/workflows/prompt-test.yml` avec un job qui se déclenche sur `pull_request`, installe Promptfoo, exécute `promptfoo eval --config promptfooconfig.yaml` et échoue si le code de sortie est non nul.
Stratégie de seuil : commencer à 85% pour permettre une certaine variance tout en détectant les régressions majeures. Après 3 mois de tests stables sans faux échecs, augmenter à 95%. Ajouter le job prompt-test comme vérification de statut requise dans les paramètres de protection de branche.
Monitoring en production des prompts
Journaliser les entrées et sorties de prompt, exécuter un scoreur de qualité sur chaque réponse et configurer des alertes pour des baisses de score de qualité supérieures à 10% sur une fenêtre glissante de 24 heures. Monitorer tous les prompts traitant des données utilisateur.
Ce qu'il faut journaliser : identifiant et version du prompt, nom du modèle, nombre de tokens d'entrée et de sortie, latence en millisecondes et un score de qualité. Pour les prompts traitant des données personnelles, journaliser un hash de l'entrée plutôt que l'entrée brute.
Options de scoring de qualité : Braintrust fournit un évaluateur cloud avec scoring par réponse et tableaux de bord. Pour une approche auto-hébergée, exécuter un appel LLM-as-judge léger sur un échantillon de 10% des réponses. Déclencher une alerte si le score de qualité moyen chute de plus de 10% par rapport à la moyenne mobile sur 7 jours.
Erreurs courantes dans les workflows de prompt pour développeurs
❌ Écrire des prompts directement dans le code de l'application
Why it hurts: Les prompts codés en dur ne peuvent pas être versionnés, testés ou modifiés sans un déploiement complet
Fix: Stocker les prompts comme fichiers séparés dans un répertoire /prompts. Les charger à l'exécution.
❌ Tester uniquement localement, jamais en CI/CD
Why it hurts: Les tests locaux sont sautés sous pression ; les gates CI/CD sont obligatoires
Fix: Ajouter une étape de test Promptfoo à GitHub Actions. Bloquer la fusion si le taux de réussite descend sous 85%.
❌ Pas de monitoring en production
Why it hurts: La qualité des prompts se dégrade après le déploiement sans visibilité
Fix: Journaliser le taux de réussite par prompt par jour. Alerter si le taux chute de 5% semaine après semaine.
❌ Tester sur un seul modèle
Why it hurts: Un prompt qui fonctionne sur GPT-4o peut échouer sur Claude 4.6 Sonnet
Fix: Exécuter la suite de tests contre au moins 2 modèles en CI/CD.
Points clés
- Utiliser Cursor pour TypeScript/Python avec des APIs cloud. Utiliser VS Code + Continue.dev pour les modèles locaux ou les exigences open source.
- La boucle de test locale comporte 4 étapes : écrire, tester sur 3 entrées représentatives, comparer avec la baseline, committer si ça passe. Objectif : moins de 30 secondes avec Promptfoo.
- Stocker les prompts en tant que fichiers .txt ou .ts dans /prompts. Convention tâche-version.txt. Tagger les versions déployées en production dans Git.
- Ajouter un gate CI/CD GitHub Actions qui fait échouer le build si le taux de réussite descend en dessous de 85%. Augmenter à 95% après 3 mois de tests stables.
- En production, journaliser identifiant du prompt, modèle, nombre de tokens, latence et score de qualité. Alerter sur des baisses de score de qualité supérieures à 10% sur 24 heures.
Questions fréquentes
Quel IDE est le meilleur pour le prompt engineering ?
Cursor est recommandé pour les développeurs qui travaillent principalement en TypeScript ou Python et veulent une intégration IA native. VS Code avec Continue.dev est recommandé si vous avez besoin de la prise en charge de modèles locaux ou d'exigences open source.
Comment stocker les prompts dans le contrôle de version ?
Stocker les prompts comme fichiers .txt ou .ts dans un répertoire /prompts. Convention : tâche-version.txt. Utiliser les commits conventionnels. Ajouter des tags Git pour chaque version déployée.
Comment mettre en place un gate CI/CD pour les prompts ?
Ajouter un workflow GitHub Actions qui exécute Promptfoo à chaque PR. Faire échouer le build si le taux de réussite descend sous 85% — augmenter à 95% après 3 mois de tests stables.
Que faut-il journaliser pour le monitoring en production ?
Journaliser les entrées (ou leur hash si DCP), réponses, latence, tokens et score de qualité. Conserver les logs 30 jours minimum.
Comment stocker les prompts dans un référentiel Git ?
Stocker chaque prompt comme fichier texte dans `/prompts/thème/`. Nommer : `classify-intent-v2.txt`. Ajouter un frontmatter YAML avec version, auteur, date, modèle et description.
Qu'est-ce qu'un gate CI/CD pour les prompts ?
Un gate CI/CD est une étape de test automatisée qui bloque la fusion si le taux de réussite descend sous le seuil (typiquement 85%). Utiliser `npx promptfoo eval --threshold 0.85` dans GitHub Actions.
Quel IDE est le meilleur pour le prompt engineering ?
Cursor est le meilleur IDE pour le prompt engineering car il permet d'exécuter Claude 4.6 Sonnet directement sur les fichiers de prompt. VS Code avec Continue.dev est une bonne alternative pour les équipes open source.