Tester et déboguer une action

La règle d’or

Ne laissez jamais une action servir vos clients sans l’avoir testée au moins une fois. Une action mal configurée peut envoyer des e-mails aux mauvais destinataires, créer des tickets erronés ou polluer vos outils. Cinq minutes de test évitent une journée de nettoyage.

Une action est active dès sa création : faites le test sur la page de création, avant de cliquer sur Créer. Pour une action existante, le test ne marche que si l’action est active (interrupteur Action active allumé) : une action désactivée répond « Action non trouvée ou désactivée ».

Tester l’action

Étape 1 — Ouvrir le test

• Nouvelle action : en bas de la page Nouvelle action : …, section Test.
• Action existante : Compétences › Mes actions › Modifier, onglet Réglages, section Test.

Pour une nouvelle action, choisissez d’abord le Connecteur (section Configuration) : le test l’utilise.

Étape 2 — Remplir les valeurs

Cliquez sur Tester l’action. Un champ s’affiche pour chaque information que le modèle attend (par exemple summary et description pour un ticket JIRA). Remplissez-les comme le ferait l’agent :

• E-mail : utilisez votre propre adresse (pas une fausse) — vous saurez si quelque chose arrive vraiment.
• Texte : « Test depuis Sens Ai, à ignorer ».
• Listes (par exemple des labels) : séparez les valeurs par des virgules.

Les champs à collecter ne font pas partie du test.

Étape 3 — Lancer

Cliquez sur Lancer le test. Sens Ai exécute réellement l’action et affiche :

• Succès ou Échec ;
• le code HTTP renvoyé par l’outil (par exemple « HTTP 201 ») ;
• la durée en millisecondes ;
• le résumé du résultat (par exemple « Ticket SUPPORT-412 créé. ») ou le message d’erreur.

Vous pouvez lancer jusqu’à 20 tests par minute.

Étape 4 — Vérifier dans l’outil cible

Le test n’est pas réussi tant que vous n’avez pas vu le résultat dans l’outil destinataire :

• pour un ticket JIRA : le ticket existe-t-il dans votre projet ?
• pour un e-mail : est-il arrivé dans votre boîte (et pas dans les indésirables) ?
• pour Slack : le message est-il dans le bon canal ?

Si la réponse est « non » ou « pas exactement ce que je voulais », ajustez la configuration et relancez le test.

Enfin, faites un essai complet depuis l’entrée Test du menu de gauche : demandez à l’agent ce qu’un client demanderait, et vérifiez qu’il utilise bien l’action.

Lire les journaux d’exécution

Sens Ai garde la trace des exécutions déclenchées par l’agent.

Le journal d’une action

Compétences › Mes actions › Modifier, onglet Journal (« Exécutions de cette action »). Les plus récentes d’abord, 20 à la fois (Charger plus) ; Actualiser recharge la liste.

Le journal de toutes les actions

Compétences › onglet Journaux : les colonnes Date, Action, Statut, Durée et Résumé, pour toutes les actions de l’agent.

Les réservations de Gérer des RDV ont leur propre journal, sur la page de la compétence.

Ce qu’on voit

Pour chaque exécution :

• la date et l’heure ;
• le statut : Succès, Échec ou Expiration ;
• la durée ;
• le résumé : le résultat (« Ticket SUPPORT-412 créé. ») ou l’erreur, par exemple « HTTP 401: … » suivi du début de la réponse de l’outil.

Bientôt disponible. Vous pourrez filtrer le journal (échecs seulement, période) et ouvrir le détail d’une exécution : requête envoyée, réponse reçue, conversation d’origine.

Les erreurs courantes et leurs causes

Le code HTTP apparaît au début du résumé (« HTTP 401: … »), dans le journal comme dans le résultat du test.

Erreur 401 — « Unauthorized »

L’outil ne reconnaît pas votre authentification.

Causes typiques :

• clé mal copiée (espace en trop, caractère manquant) ;
• clé révoquée ou expirée ;
• pour un Webhook générique : mauvais Type d’authentification, ou Bearer saisi dans la Valeur d’authentification alors que le type bearer l’ajoute déjà (voir Webhook générique — recettes).

Action : régénérez la clé chez l’éditeur, mettez à jour le connecteur, retestez.

Erreur 403 — « Forbidden »

L’authentification est valide, mais le compte n’a pas le droit de faire ce qu’on lui demande.

Causes typiques :

• permissions insuffisantes sur la clé ;
• ressource qui appartient à un autre utilisateur ou projet ;
• quota dépassé chez l’éditeur (rare).

Action : vérifiez les permissions de la clé chez l’éditeur.

Erreur 404 — « Not Found »

L’adresse ou la ressource visée n’existe pas.

Causes typiques :

• faute dans l’URL du connecteur ;
• ressource inexistante (projet JIRA supprimé, ticket introuvable, type d’événement Calendly désactivé).

Action : vérifiez la configuration du connecteur et de l’action.

Erreur 400 ou 422 — requête refusée

La requête est arrivée, mais son contenu n’est pas accepté (champ obligatoire manquant, valeur invalide).

Causes typiques :

• un réglage de l’action ne correspond pas à votre outil (par exemple un Type de ticket qui n’existe pas dans votre projet JIRA) ;
• une valeur hors de la liste autorisée.

Action : lisez la suite du résumé — l’outil y indique généralement le champ en cause.

Erreur 429 — « Too Many Requests »

L’éditeur limite le nombre d’appels et vous l’avez dépassé.

Action : si c’est rare, ignorez. Si c’est récurrent, voyez avec l’éditeur pour augmenter votre quota.

Erreurs 500 à 503 — erreurs serveur

L’outil distant a planté ou est indisponible. Ce n’est pas votre configuration.

Action : l’action n’est pas relancée automatiquement. Surveillez la page d’état de l’éditeur (status.atlassian.com pour JIRA, etc.), puis réessayez.

Statut « Expiration »

L’outil n’a pas répondu dans les 10 secondes.

Causes typiques : serveur surchargé, traitement trop long côté serveur.

Action : vérifiez que l’adresse répond, et raccourcissez le traitement côté serveur (par exemple en répondant tout de suite et en traitant ensuite).

Un outil qui n’a pas pu être joint du tout (adresse inconnue, connexion refusée) donne un Échec, avec le message « Service injoignable (échec de la connexion) ».

Le connecteur est en « Erreur »

Le test du connecteur a reçu un refus certain de vos identifiants : les actions qui s’y rattachent sont suspendues, l’agent ne les utilise plus. Corrigez le connecteur dans Intégrations › Mes connecteurs, puis Tester : un test réussi le remet en Actif (voir Connecteurs et authentification).

L’agent n’utilise jamais l’action

Vérifiez dans l’ordre :

1. l’action est Active (interrupteur dans Mes actions) ;
2. son connecteur est Actif (page Intégrations) ;
3. les limites d’exécution ne sont pas atteintes ;
4. le Nom de l’action dit clairement ce qu’elle fait — et, au besoin, une règle de réponse oriente l’agent vers elle (voir Règles de sécurité et règles de réponse).

Étape suivante

Si plusieurs actions échouent en même temps, c’est probablement un problème côté outil ou un changement de son API : consultez la page d’état de l’éditeur. Pour comprendre les connecteurs : Connecteurs et authentification.