Diagnostiquer un incident avec l’IA
Financement et utilisation de l’IA
IA incluse utilise des crédits REDA. Votre propre IA utilise le compte fournisseur de votre organisation, facturé directement par ce fournisseur. La licence définit un mode pour toute l’organisation. Dans les deux cas, REDA AI gouverne les outils et actions configurés dans Salesforce. Configurer la licence et les comptes IA.
Avec un compte client, le modèle choisi détermine les niveaux de raisonnement approfondi et les capacités disponibles. Vérifiez les niveaux et avertissements du sélecteur AI Account ; tous les fournisseurs ne prennent pas en charge les mêmes combinaisons. Les outils administratifs et le traitement documentaire utilisent la connexion par défaut de l’organisation. Configurer le choix par défaut et tester le parcours.
Fonctionnement
Le journal d’incidents peut enregistrer des exceptions Apex, erreurs d’appel, problèmes de validation ou de configuration signalés par les parcours REDA AI. Le détail technique disponible, notamment la trace, le contexte, la classe et la méthode, sert de point de départ au diagnostic.
L’assistant explique le message et propose des hypothèses et corrections. Vous pouvez contester une conclusion, ajouter un fait vérifié ou demander des précisions. Une formulation assurée du modèle ne constitue pas une preuve de la cause réelle.
Un échange avec des questions de suivi
Le premier appel prépare une analyse à partir des informations de l’incident. Les questions suivantes permettent d’orienter le diagnostic, par exemple :
- « Quelle configuration pourrait provoquer cette erreur précise ? »
- « Les autorisations au niveau des champs peuvent-elles être en cause ? »
- « Quel paramètre de l’agent faut-il vérifier pour ce comportement ? »
- « Pourquoi le message de la règle de validation n’est-il pas parvenu à l’utilisateur ? »
Chaque échange traité par le modèle consomme des crédits selon le volume envoyé et reçu. Une question ciblée peut améliorer le diagnostic, sans garantir un coût faible ni une réponse plus exacte.
Déroulement
-
Ouvrir l’incident
Ouvrez l’incident depuis Journaux d'incidents d'IA ou un lien Salesforce autorisé.
-
Vérifier la disponibilité au lancement
Après le lancement, le parcours vérifie l’activation du système, la licence et le solde de crédits. Un blocage ou une erreur est affiché si ces contrôles échouent. Ne supposez pas que le bouton est systématiquement désactivé à l’avance ni qu’un interrupteur indépendant de diagnostic est vérifié.
-
Lancer Déboguer avec l'IA
Le premier appel rassemble le message, la classe, la méthode, la trace et les informations de contexte prévues, puis les transmet au modèle. Il ne charge pas automatiquement le texte des messages de la conversation d’origine.
-
Examiner le premier résultat
Le panneau présente l’explication, la cause proposée et les étapes recommandées. Comparez-les à l’erreur et à la configuration réellement utilisées.
-
Poser des questions de suivi
Saisissez une question dans Suivi. Le parcours transmet l’historique disponible de cette session de diagnostic et la question. L’historique envoyé est limité aux 20 derniers messages avant l’ajout de la question ; les détails initiaux de l’incident ne sont pas reconstruits et réinjectés intégralement à chaque échange.
-
Conserver les conclusions vérifiées
Lorsque vous souhaitez conserver les résultats, utilisez Enregistrer dans les notes de résolution. Cette action remplace les notes existantes par les réponses de l’assistant de la session, pas uniquement par sa dernière réponse. Relisez-les et préservez d’abord les notes utiles déjà présentes ; vous pouvez aussi rédiger une synthèse vérifiée directement dans le champ.
Données transmises au diagnostic
La préparation initiale utilise les éléments suivants, lorsqu’ils sont accessibles et renseignés :
- Informations de l’incident — Type, message, contexte, gravité, classe, méthode, ligne et trace. Le numéro de ligne des classes du package est masqué dans ce parcours. Le statut et les notes de résolution sont lus pour certains affichages de l’interface, mais ne sont pas intégrés automatiquement au prompt initial décrit.
- Configuration actuelle de l’agent lié — Nom affiché, canal, extrait du personnage limité à 300 caractères et objets de contexte par défaut. Cette configuration peut avoir changé depuis l’incident.
- Prompts de l’agent — Jusqu’à cinq prompts actifs directement liés sont sélectionnés, avec des extraits de 150 caractères. Des prompts provenant des attributions résolues peuvent compléter cette sélection selon la version et la configuration ; ce n’est pas l’intégralité garantie du prompt historique de l’agent.
- Outils actifs sélectionnés — Jusqu’à dix définitions liées à l’agent, avec leur type et description. La sélection ne prouve pas la liste exacte chargée lors de l’échec passé.
- Rapport de détection de conflits — Résultats disponibles du contrôle de configuration décrit ci-dessous.
- Contexte de conversation — Canal, objet et identifiant de contexte de la conversation liée, sans ses messages.
- Historique du diagnostic — Lors des questions suivantes, les échanges de cette session sont transmis dans la limite de chargement ; ils ne remplacent pas les preuves originales.
Le contrôle de configuration applique des règles déterministes. Il peut alimenter le prompt avec des motifs détectés, mais ne prouve pas toutes les contradictions de sens entre prompts et n’explique pas nécessairement la cause de l’incident. Le modèle peut aussi formuler ses propres hypothèses. Si ce contrôle facultatif échoue, le diagnostic peut continuer sans cet enrichissement ; tenez compte de cette limite.
Le parcours ne charge pas le texte des messages de la conversation d’origine. Si leur formulation est importante, consultez-les vous-même ou utilisez le débogueur de conversations. Évitez d’ajouter des informations sensibles inutiles : un masquage visible dans le panneau ne prouve pas que tous les contenus transmis au modèle ont été anonymisés.
Périmètre des conseils
Les instructions du diagnostic orientent les réponses vers votre configuration et vos composants modifiables : agents, prompts, outils, flux, validations, autorisations et code Apex personnalisé. Elles demandent de ne pas reconstituer les détails internes du package géré. Il s’agit d’une consigne au modèle, pas d’une garantie absolue sur toutes ses réponses.
Les recommandations doivent porter sur des changements que vous pouvez vérifier et appliquer dans votre organisation. Pour un défaut supposé du package, rassemblez les preuves et contactez l’assistance au lieu de traiter une explication générée comme une lecture du code interne.
Enregistrer les résultats
L’action enregistre les réponses de l’assistant dans Notes de résolution. Il n’existe pas de champ séparé réservé à cette analyse ; il s’agit du même emplacement que les notes rédigées par un administrateur.
L’enregistrement remplace les notes existantes. Il ne les complète pas automatiquement. Préservez les commentaires précédents ou rédigez manuellement une synthèse qui distingue constats vérifiés, hypothèses et prochaines étapes. L’action fournie concatène les réponses de l’assistant, sans les questions de suivi de l’utilisateur.
Lors de cet enregistrement, un incident au statut Nouveau passe automatiquement à Enquête. Les statuts déjà Enquête, Résolu ou Licencié, libellé fourni pour Dismissed, sont conservés. L’analyse seule ne marque pas l’incident comme résolu.
- Les lecteurs autorisés peuvent ensuite consulter les notes sans relancer le modèle.
- Vous pouvez reprendre une synthèse vérifiée dans une procédure ou une demande d’assistance, selon les règles de partage applicables.
- Un nouveau diagnostic repart d’une nouvelle session et ne réinjecte pas automatiquement les notes sauvegardées dans son prompt. Ajoutez les faits nécessaires de manière ciblée si vous reprenez une investigation.
Coût en crédits
Chaque échange est une opération de modèle, avec d’éventuelles nouvelles tentatives techniques. Le coût dépend du contexte effectivement envoyé, de l’historique conservé et de la sortie produite. Le panneau présente les crédits enregistrés pour les résultats reçus ; examinez aussi les transactions et messages d’erreur en cas d’interruption.
Le premier appel comprend les détails préparés de l’incident. Les suivis utilisent l’historique de diagnostic et la nouvelle question, sans reconstruire tout ce contexte à chaque fois. Ils ne sont donc pas toujours moins chers : un historique long ou une sortie détaillée peut augmenter la consommation. Consignez les enseignements réutilisables dans une procédure pour éviter de répéter inutilement les mêmes analyses.
Avec IA incluse, un dépassement du délai d’appel peut entraîner la pénalité documentée de 20 crédits. Avec votre propre IA, REDA ne déduit aucune allocation de crédits ; la facturation relève de votre fournisseur. Vérifiez l’utilisation enregistrée et l’erreur avant de réessayer. Un dépassement de délai ne permet pas, à lui seul, d’en déterminer la cause.
Le budget de réponse dépend du paramètre Debugger Max Output Tokens, dont la valeur par défaut documentée est 3 000. Ce nom technique reste inchangé. Si le diagnostic est tronqué, précisez la question ou faites vérifier ce budget et les réglages de raisonnement applicables. Une capacité de sortie accrue peut augmenter la consommation ; ne modifiez pas automatiquement le budget de l’agent ayant produit l’incident.
Différences avec le débogueur de conversations
- Débogueur de conversations — Examine des extraits de messages, outils et configuration pour proposer une analyse structurée d’un résultat inattendu.
- Diagnostic d’incident avec l’IA — Part des informations d’un incident technique et permet une discussion avec des questions de suivi.
Choisissez le parcours correspondant aux preuves disponibles. Les deux peuvent se compléter lorsqu’une conversation présente à la fois une erreur enregistrée et un résultat métier inattendu.
Limites du diagnostic
- Il n’applique pas les corrections. Les conseils doivent être vérifiés ; vous décidez des modifications autorisées de configuration ou de code.
- Il ne reproduit pas l’échec. Pour valider une correction, refaites un test représentatif et contrôlez son résultat, pas uniquement l’absence d’un nouvel incident.
- Il ne résout pas automatiquement l’incident. L’analyse seule ne change pas le statut. L’enregistrement des réponses peut faire passer Nouveau à Enquête ; vous marquez Résolu après vérification selon votre procédure.
- Il n’est pas un outil d’inspection du package. Ses consignes limitent les explications aux changements possibles dans votre organisation ; les affirmations sur l’implémentation interne ne doivent pas être considérées comme vérifiées.
Bonnes pratiques
Précisez progressivement : utilisez la première réponse comme point de départ, puis confrontez ses hypothèses à des faits et questions ciblés.
Conservez les conclusions utiles : relisez les réponses avant de remplacer les notes et distinguez les hypothèses des corrections testées.
Décrivez l’échange concerné : si le texte d’une demande est nécessaire, fournissez uniquement l’extrait utile et autorisé, avec le résultat attendu. Le diagnostic d’incident ne l’a pas chargé automatiquement.
Demandez une vérification de configuration : par exemple « Quel paramètre de mon agent, flux ou code personnalisé pourrait expliquer ce résultat ? ». Évitez de demander au modèle d’inventer le contenu du package ; une réponse inutile peut tout de même consommer des crédits.
Complétez avec le débogueur de conversations si nécessaire : lorsqu’un incident et un écart de comportement se combinent, rapprochez les deux analyses des mêmes preuves. Deux avis générés ne remplacent pas un test de la cause proposée.
Questions fréquentes
C’est un échange avec suivi. Le premier appel utilise les informations préparées de l’incident. Les questions suivantes transmettent l’historique de cette session, limité aux 20 derniers messages avant ajout de la nouvelle question. Le contexte initial complet de l’incident n’est pas réinjecté automatiquement à chaque tour.
Le parcours vérifie la disponibilité lors du lancement : activation du système, licence et crédits, puis accès aux données et résultat des appels. Examinez le message affiché. Ne supposez pas qu’un bouton grisé prouve à lui seul une licence expirée ou qu’un interrupteur indépendant de diagnostic est nécessaire.
Ses instructions lui demandent de ne pas reconstituer l’implémentation du package et de se concentrer sur votre configuration ou code personnalisé. Une réponse du modèle ne constitue pas une preuve du code géré ; adressez un défaut supposé à l’assistance avec les éléments observés.
Dans Notes de résolution. L’action concatène les réponses de l’assistant et remplace le contenu précédent. Elle fait passer Nouveau à Enquête et conserve les autres statuts. Préservez les notes existantes et relisez le contenu avant l’enregistrement.
Non, il n’existe pas de prix fixe d’un crédit par échange. Les appels traités consomment un montant dépendant des données envoyées, de la sortie et des règles applicables. Le panneau indique les crédits enregistrés pour les réponses ; certains échecs d’appel peuvent aussi entraîner une pénalité.
Le parcours s’appuie sur l’enregistrement d’incident, qu’il provienne d’un chat interne, d’un widget externe, d’un e-mail ou d’une automatisation. Les données et liens disponibles peuvent varier ; l’accès, la licence, les crédits et la configuration restent nécessaires.
Indiquez les faits qui contredisent la proposition, par exemple « J’ai déjà vérifié ce champ » ou « Le même appel réussit avec ce profil ». Demandez une autre hypothèse et vérifiez-la par un test ciblé. Relancer ou préciser une question ne garantit pas une conclusion correcte.
Pour continuer
Consultez Journaux d’incidents IA pour les champs de l’enregistrement, ou Débogueur de conversations pour une analyse centrée sur les messages et le résultat de l’échange.