Un template Prompt Builder se comporte comme de la configuration de production. Modifiez-le, et un e-mail client, un champ généré ou la réponse d’un agent changent avec lui, parfois sans qu’aucune mise en production n’ait été revue. Le sponsor ou le responsable admin n’a pas à écrire de prompts. Il doit savoir qui possède chaque template, ce qu’il peut lire, comment il a été testé, qui peut le modifier et ce que l’on dit aux utilisateurs de sa sortie.
Un propriétaire par template, et un par source de contexte
Chaque template a besoin d’un propriétaire métier pour sa sortie et d’un propriétaire admin pour sa configuration. Le responsable des opérations commerciales décide de ce qu’un template Sales Email peut dire ; le responsable du service client décide du contenu de la synthèse d’un Case. Le propriétaire admin tient la version, les droits et la mise en production.
Les données de contexte ont aussi besoin d’un propriétaire. Chaque champ de fusion, liste associée, Flow ou classe Apex qui alimente un template est une dépendance, et son propriétaire est la personne qui sait si la donnée est à jour. Un template qui charge quinze champs a quinze dépendances. Demandez la liste, et demandez que chaque source soit justifiée : on ne l’ajoute que lorsqu’un test montre qu’elle améliore un comportement défini. Un contexte plus riche apporte aussi des valeurs périmées, des contradictions et une exposition plus large, et il n’améliore pas la réponse par défaut.
Gardez des templates à usage unique. Un template qui « résume l’historique du compte, suggère les prochaines actions et identifie les risques » est trois templates sous un seul nom. Séparez-le, pour que chaque partie ait un propriétaire et un jeu de tests. Notez ensuite qui consomme la sortie : un Flow, une action, un champ généré, une page, un agent. Un template Flex appelé par un agent lie les deux. Revenez en arrière sur le template sans la configuration de l’agent qui l’appelle, ou l’inverse, et le comportement ne correspond plus à ce qui a été testé.
Ce qu’un template a le droit de lire
Quand j’enseigne ADX201, le module sécurité repose sur une idée : un utilisateur voit ce que son profil, ses permission sets et le partage lui permettent. Un template lit des enregistrements pour le compte de quelqu’un ; la question de gouvernance est donc de savoir avec quels droits il résout ses données. Exigez la réponse pour chaque source. Un champ de fusion, un Flow et une classe Apex ne s’exécutent pas forcément avec les mêmes droits, et une démo lancée par un administrateur ne montrera pas la différence.
Ensuite, testez. Exécutez le template en sandbox avec un utilisateur qui ne doit pas voir un champ donné, et vérifiez que la sortie ne le révèle pas. Tenez une courte liste de champs qu’aucun template ne doit fusionner, quels que soient les droits de l’utilisateur.
Regardez où la sortie atterrit. Un template Field Generation qui résume des notes restreintes dans un champ visible par davantage de personnes republie ce contenu auprès du public de ce champ. Une fois stockée, la sortie suit les règles d’accès du champ qui la contient, quelles que soient celles de ses sources.
Un jeu de tests validé avant la mise en production
Un template passe en production sur un jeu de tests, et trois bons exemples n’en font pas un. Le jeu couvre les cas normaux, les champs vides, les sources qui se contredisent, un utilisateur sans accès, une demande hors périmètre, du contenu sensible et des tentatives de contourner les instructions. Pour chaque cas, stockez l’entrée, le contexte résolu et les critères d’acceptation : structure, faits autorisés, champs obligatoires, contenu interdit. Plusieurs formulations peuvent être valides, donc les critères ne reposent pas sur une comparaison mot à mot.
Le propriétaire métier valide les cas et les résultats attendus avant la mise en production, pas après avoir lu les sorties. Un refus contrôlé compte comme une réussite. Un champ généré qui indique « Non identifié » quand la transcription d’un appel ne nomme aucun irritant est une sortie correcte, et une valeur que l’on pourra requêter pour retrouver les enregistrements à revoir par un humain. Une réponse fluide sans fondement est un échec.
Prompt Performance Metrics est documenté comme une fonctionnalité beta qui s’appuie sur Data 360 Calculated Insights et peut augmenter la consommation de crédits. Traitez-le comme une télémétrie à côté du jeu de tests. Il ne remplace pas le point de contrôle de mise en production.
Versions, rythme des releases et droit de modifier en production
Chaque changement de template a un propriétaire, une raison, une nouvelle version, une exécution des tests et un retour arrière. Revenir en arrière ne se limite pas à restaurer le texte précédent : il faut identifier les sorties enregistrées et les actions déclenchées pendant que la version fautive était active.
Alignez les revues sur le calendrier de releases que l’org suit déjà. Salesforce publie trois releases par an, et un template validé au printemps peut se comporter autrement après la release suivante sans que personne ne l’ait modifié. Je refais chaque exercice avant une session de formation pour la même raison. Le jeu de tests mérite le même passage après chaque release, pas seulement après une modification.
Les modifications en production suivent le chemin de toute autre métadonnée : changement en sandbox, test, déploiement. Tenez une liste courte et nominative des personnes qui peuvent créer et modifier des templates. Exécuter un template et le modifier sont deux droits distincts, et la plupart des utilisateurs n’ont besoin que du premier.
Les réglages de l’Einstein Trust Layer et ce que l’on dit aux utilisateurs
Les réglages de l’Einstein Trust Layer s’appliquent à tous les templates : leur propriétaire est le propriétaire de la plateforme, et un changement à ce niveau passe par la même revue. Demandez à les voir dans Setup plutôt que sur une diapositive, et vérifiez au moins ces points :
- le masquage des données : quels types de données sont masqués avant qu’un prompt ne quitte Salesforce, et quelles fonctionnalités le réglage couvre ;
- la piste d’audit : les prompts et les réponses sont-ils stockés, combien de temps, et qui peut les lire ;
- la détection de toxicité : les scores sont-ils enregistrés, et qui revoit les sorties signalées.
Les utilisateurs doivent savoir ce qu’est la sortie et ce qu’elle n’est pas. C’est un brouillon généré à partir de champs nommés. Ce n’est ni un fait vérifié, ni un engagement commercial, ni un avis juridique. Dites-leur quoi vérifier avant d’enregistrer ou d’envoyer, et comment signaler une mauvaise sortie pour qu’elle parvienne au propriétaire du template. Pour un texte destiné à un client, la personne qui l’envoie en reste responsable.
À vérifier
- Chaque template actif a-t-il un propriétaire métier et un propriétaire admin nommés ?
- Le propriétaire admin peut-il lister toutes les sources de contexte d’un template et dire avec quels droits chacune s’exécute ?
- Le propriétaire métier a-t-il validé le jeu de tests avant la dernière release ?
- Combien de personnes peuvent modifier des templates en production, et sont-elles nommées ?
- Quand les réglages du Trust Layer ont-ils été revus pour la dernière fois, et par qui ?
- Les utilisateurs savent-ils quoi vérifier avant d’enregistrer ou d’envoyer une sortie ?