Les bonnes pratiques Salesforce Prompt Builder ne commencent pas par une formule de prompt. Elles commencent par un contrat : entrée autorisée, sortie attendue, cas de refus, preuve de qualité et procédure de rollback.
Un template modifié peut changer une réponse client, un champ généré ou une décision en aval. Il doit donc être gouverné comme une configuration de production.
Choisir le template à partir du contrat de sortie
Le type de template doit correspondre à l’usage prévu. Sales Email, Field Generation et Flex n’imposent pas le même contrat de sortie ni la même intégration en aval.
Avant le choix, documentez :
- qui invoque le template ;
- quelles données entrent ;
- quel format sort ;
- où la sortie est affichée ou enregistrée ;
- quels contrôles s’exécutent avant toute action ;
- que faire si le contexte manque ou se contredit.
Flex n’est pas « meilleur » parce qu’il est plus libre. Il est approprié lorsque l’équipe possède et teste la structure de sortie dont elle a besoin.
Réduire le contexte au nécessaire
Ajouter des champs n’améliore pas mécaniquement la réponse. Le contexte supplémentaire peut introduire des données obsolètes, des contradictions, une exposition inutile et une consommation plus élevée.
Commencez par les champs nécessaires au critère d’acceptation. Ajoutez une source uniquement lorsqu’un test montre qu’elle améliore un comportement défini.
Data Graphs et Calculated Insights peuvent fournir un contexte agrégé lorsque l’organisation utilise Data 360 et que le cas d’usage le justifie. Ils ne sont pas requis pour chaque template. Une donnée CRM simple, à jour et autorisée peut être suffisante.
Écrire pour les cas où le contexte manque
Chaque template doit définir le comportement lorsque :
- un champ est vide ;
- deux sources se contredisent ;
- l’utilisateur n’a pas accès à la donnée ;
- la demande sort du périmètre ;
- la sortie ne respecte pas le format attendu ;
- le modèle ne peut pas produire une réponse fondée.
Le refus contrôlé est une sortie valide. Une réponse fluide mais non fondée ne l’est pas.
Construire un jeu de tests versionné
Le jeu de tests doit couvrir cas normaux, valeurs limites, données manquantes, langues, contenu sensible, tentatives de contournement et changements de configuration.
Pour chaque cas, stockez l’entrée, le contexte résolu, les critères d’acceptation et le résultat. Évitez une comparaison mot à mot si plusieurs formulations sont valides ; testez plutôt structure, faits autorisés, champs obligatoires et interdictions.
Prompt Performance Metrics est documenté comme une fonctionnalité beta qui utilise Data 360 Calculated Insights et peut augmenter la consommation de crédits. Cette télémétrie peut compléter l’analyse. Elle ne remplace pas un jeu de tests contrôlé ni un release gate.
Versionner et prévoir le rollback
Un changement de template doit avoir un propriétaire, une raison, une version, un lot de tests et un plan de retour arrière. Le déploiement doit rester séparé de l’activation lorsque le risque le justifie.
Journalisez également les dépendances : Flow, Action, champ généré, UI, intégration ou processus qui consomme la sortie. Sans ce graphe, une amélioration locale peut créer une régression ailleurs.
Le rollback ne consiste pas seulement à restaurer le texte précédent. Il faut aussi identifier les sorties déjà enregistrées ou les actions déclenchées pendant la période affectée.
Mesurer ce qui compte
Les métriques dépendent du cas d’usage :
- conformité au format ;
- taux de refus correct ;
- faits non fondés ;
- corrections humaines ;
- réouvertures ou reprises ;
- coût par exécution ;
- latence ;
- incidents d’accès ou de données sensibles.
Définissez la méthode et le baseline avant de changer le template. N’inventez pas un pourcentage universel attribuant la qualité au prompt ou aux données.
Points clés
- Définir le contrat de sortie avant de rédiger les instructions.
- Injecter uniquement le contexte nécessaire et autorisé.
- Tester explicitement les données manquantes, contradictions, refus et attaques.
- Utiliser les métriques beta comme télémétrie complémentaire, pas comme preuve unique.
- Versionner templates, dépendances, critères de test et procédure de rollback.
