L’ingénierie de prompts est du tâtonnement pour la plupart des équipes. Vous modifiez un prompt système, l’exécutez quelques fois, décidez que c’est « mieux au feeling » et passez à autre chose. Il n’y a pas d’historique de versions. Pas de moyen de comparer l’itération 14 à l’itération 11. Pas de boucle de feedback systématique connectant la qualité en production aux changements de prompts.
Nous avons construit le studio d’ingénierie de prompts pour corriger cela. C’est un panneau rétractable intégré directement dans l’éditeur de recettes — pas une page séparée, pas un outil différent. Cinq onglets se trouvent juste à côté de la zone de texte du prompt : Budget de tokens, Variables, Versions, Few-Shot et Optimiseur. L’itération se fait dans le contexte, pas dans un workflow déconnecté.
Suivi de version et comparaison de diff
Chaque changement de prompt crée une version dans une sous-collection Firestore. Chaque version stocke :
| Champ | Description |
|---|---|
| Numéro de version | Entier auto-incrémenté |
| Texte du template | Le template de prompt complet à ce point dans le temps |
| Score de similarité | 0-100 via distance de Levenshtein normalisée par rapport à la version précédente |
| Auteur | Qui a fait le changement |
| Journal des changements | Description libre de ce qui a changé et pourquoi |
Les métriques de qualité sont suivies par version : total d’exécutions, nombre de succès, nombre de pouces levés, nombre de pouces baissés, ratio de feedback et utilisation moyenne de tokens. Ces métriques sont mises en cache Redis avec un TTL de 5 minutes pour garder l’UI réactive sans surcharger Firestore à chaque ouverture du panneau.
La visionneuse de diff montre des comparaisons ligne par ligne entre deux versions quelconques. Les ajouts s’affichent en vert, les suppressions en rouge, avec des statistiques résumant combien de lignes ont changé. Les scores de similarité sont colorés : vert pour >= 90 % de similarité (ajustements mineurs), ambre pour >= 50 % (réécritures modérées) et rouge pour < 50 % (changements substantiels).
Le rollback est non-destructif. Restaurer une version précédente crée une nouvelle version avec l’ancien contenu — il n’écrase jamais l’historique. La version 15 peut être identique à la version 8, et c’est normal. La chaîne complète des changements est toujours préservée.
Visualisation du budget de tokens en temps réel
L’onglet Budget de tokens affiche un graphique à barres en temps réel montrant l’utilisation de la fenêtre de contexte au fur et à mesure que vous tapez. Cinq sections étiquetées décomposent où vont vos tokens :
| Section | Budget |
|---|---|
| Système | Surcharge de 200 tokens (cadrage du prompt système) |
| Glossaire | Plafond de 500 tokens |
| Few-Shot | Plafond de 2 000 tokens |
| Contexte RAG | Plafond de 4 000 tokens |
| Prompt utilisateur | Estimé à partir de la longueur du texte / 4 |
La visualisation est consciente du modèle. Sélectionnez Claude et la barre s’adapte à 200K tokens. Passez à GPT-4o et elle se recalibre à 128K. Passez à Gemini et elle s’étend à 1M. Les proportions changent en conséquence, rendant immédiatement évident quand un prompt qui tient confortablement dans la fenêtre de contexte d’un modèle est dangereusement serré dans un autre.
Trois niveaux d’avertissement se déclenchent automatiquement :
- >80 % d’utilisation — avertissement ambre, suggérant de réduire le contexte ou les exemples few-shot
- >90 % d’utilisation — avertissement rouge, indiquant un risque élevé de troncature
- <1 000 tokens restants pour la sortie — alerte explicite que le modèle n’aura pas assez de place pour générer une réponse utile
Les mises à jour sont anti-rebond à 500ms sur les frappes, donc le graphique reste réactif sans recalculer à chaque caractère.
Inspecteur de variables
L’onglet Variables détecte les références {{variable}} et {{fragment:name}} en temps réel pendant que vous modifiez le template de prompt. Chaque variable détectée est croisée avec le inputSchema de la recette et reçoit un des quatre statuts :
- Correspondante (vert) — La variable existe à la fois dans le template et le schéma. Tout est correctement câblé.
- Orpheline (ambre) — La variable apparaît dans le template mais n’est pas définie dans le schéma. Le prompt référence quelque chose qui n’aura pas de valeur à l’exécution.
- Inutilisée (rouge) — La variable est définie dans le schéma mais jamais référencée dans le template. Vous collectez une entrée qui ne mène nulle part.
- Fragment (bleu) — Une référence
{{fragment:name}}vers un fragment de prompt réutilisable.
Pour les variables correspondantes, l’inspecteur tire des valeurs d’exemple des données d’exécution historiques, pour que vous puissiez voir à quoi ressemblent les entrées réelles sans quitter l’éditeur. Cela détecte une classe courante de bugs : le schéma définit un champ comme companyName mais le template référence {{company_name}}.
Gestion d’exemples Few-Shot
L’onglet Few-Shot vous permet d’épingler des exécutions réussies comme exemples curatés. Chaque exemple épinglé a un champ de sortie modifiable — vous pouvez corriger ou affiner la réponse originale du modèle pour créer une démonstration de référence.
Le scoring de qualité détermine quels exemples remontent à l’exécution. Chaque exemple commence avec un score de base de 50. Un pouce levé ajoute 40 points. Un pouce baissé soustrait 30 points. Les scores de juges des évaluations de bakeoff sont pondérés également.
À l’exécution, le système supporte trois stratégies de récupération :
| Stratégie | Fonctionnement |
|---|---|
| Basée sur les feedbacks | Sélectionne les exécutions avec pouce levé, diversifiées pour éviter les exemples répétitifs |
| Récentes | Sélectionne les exécutions réussies les plus récentes |
| Similaires | Utilise la similarité cosinus via embeddings pour trouver les exécutions les plus proches de l’entrée actuelle |
Les exemples curatés épinglés ont toujours la priorité sur ceux récupérés dynamiquement. Ils sont injectés en premier, et le budget restant se remplit avec les exemples sélectionnés par stratégie.
Tous les exemples few-shot sont injectés dans le prompt comme blocs XML <few_shot_examples>, contraints à un budget de 2 000 tokens. Si vos exemples curatés dépassent le budget, le système tronque à partir des exemples les moins bien notés.
Optimiseur alimenté par IA
L’onglet Optimiseur fournit trois niveaux d’amélioration de prompts, allant du manuel au pleinement automatisé.
Niveau 1 : Analyse déclenchée par l’utilisateur
Cliquez sur « Analyser » et l’optimiseur tire les 50 dernières exécutions réussies de la recette, les répartit en catégories pouces levés et pouces baissés, et envoie la distribution à Claude Sonnet 4.6 pour une analyse structurée. Le modèle renvoie une liste de suggestions, chacune contenant :
| Champ | Description |
|---|---|
| Section | Quelle partie du prompt changer |
| Texte original | Le texte actuel du prompt dans cette section |
| Texte suggéré | Le remplacement proposé |
| Justification | Pourquoi ce changement devrait améliorer la qualité de la sortie |
| Confiance | Score 0-100 indiquant la certitude du modèle |
Vous revoyez chaque suggestion et choisissez Appliquer (remplacement en ligne dans l’éditeur) ou Test A/B (crée un bakeoff comparant le prompt actuel contre la suggestion en production).
Niveau 2 : Suggestions auto-déclenchées
Quand une recette accumule 5 ou plus évaluations négatives, l’optimiseur génère automatiquement 1-3 suggestions d’amélioration sans intervention de l’utilisateur. Celles-ci apparaissent comme un badge de notification sur l’onglet Optimiseur.
Ce niveau est limité à une fois par heure par recette pour éviter la fatigue de suggestions.
Niveau 3 : Affinement de dérive qualité
Ce niveau est déclenché par le système Quality Guard quand il détecte une dérive de la qualité de sortie d’une recette dans le temps. L’optimiseur analyse les 5 meilleures et 5 pires exécutions de la fenêtre de dérive, identifie les patterns de ce qui se dégrade et génère des changements de prompt ciblés.
Le niveau 3 peut aussi auto-déclencher des mini-bakeoffs — créant une comparaison A/B structurée entre le prompt actuel et la révision suggérée, routée vers le trafic de production en direct.
Les limites de fréquence gardent cela conservatif : les suggestions d’affinement sont limitées à une fois par 24 heures, et les bakeoffs auto-déclenchés à une fois par 7 jours.
Pourquoi c’est dans l’éditeur
Le Studio est un panneau, pas une page. C’est une décision de conception délibérée. L’ingénierie de prompts est itérative — vous changez une ligne, vérifiez le budget de tokens, jetez un œil au diff, lancez un test. Le changement de contexte entre outils séparés casse le flux.
Avec le Studio réduit, vous avez un éditeur propre. Avec le Studio déplié, chaque signal dont vous avez besoin — utilisation de tokens, santé des variables, historique de versions, exemples few-shot, suggestions d’optimisation — est à un onglet de distance.
Disponibilité
Le studio d’ingénierie de prompts est disponible sur les plans Pro et supérieurs. Le suivi de version, le budget de tokens et l’inspection de variables sont inclus dans Pro. La gestion few-shot et l’optimiseur alimenté par IA (les trois niveaux) sont disponibles sur Pro et Enterprise.
Explorez toutes les fonctionnalités sur la page des fonctionnalités ou commencez un essai gratuit.