Tester et déboguer une action

La règle d’or

Ne mettez jamais une action en production sans l’avoir testée au moins une fois en mode manuel. Une action mal configurée peut envoyer des e-mails à de mauvais destinataires, créer des tickets erronés, polluer votre CRM. Cinq minutes de test évitent une journée de nettoyage.

Test manuel

Étape 1 — Lancer le test

Votre bot → Actions → cliquez sur l’action → bouton Tester cette action.

Étape 2 — Remplir les paramètres

Une fenêtre s’ouvre avec un formulaire reprenant tous les paramètres que l’action attend. Remplissez-les comme si vous étiez un client :

• E-mail : utilisez votre propre e-mail (pas une fausse adresse) — vous saurez si quelque chose arrive vraiment.
• Description : « Test action depuis Sens-AI, à ignorer ».
• Autres champs : valeurs réalistes mais clairement marquées comme test.

Étape 3 — Lancer

Cliquez sur Exécuter. Sens-AI envoie la requête et affiche le résultat :

• Statut HTTP (200 = succès, 4xx = erreur du client, 5xx = erreur serveur).
• Corps de la réponse retournée par votre serveur.
• Message de retour que le bot dirait au client en situation réelle.
• Temps d’exécution.

É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 bien dans votre Jira ?
• Pour un e-mail : est-il arrivé dans votre boîte de réception ?
• Pour un contact CRM : est-il dans la liste ?

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

Lire les logs d’exécution

Pour les actions qui tournent en production, Sens-AI conserve un historique des exécutions.

Y accéder

Votre bot → Actions → cliquez sur l’action → onglet Historique.

Ce qu’on voit

Pour chaque exécution :

• Date et heure.
• Conversation source (avec un lien vers la conversation où l’action a été déclenchée).
• Statut : Réussie / Échouée / En attente.
• Durée d’exécution.
• Détails : cliquez pour voir la requête envoyée, la réponse reçue, et le message servi au client.

Filtres utiles

• Échecs uniquement — pour repérer les actions qui plantent.
• Période — analyser les 7 derniers jours, le mois en cours, etc.

Les erreurs courantes et leurs causes

Erreur 401 — « Unauthorized »

Le serveur refuse car il ne reconnaît pas votre authentification.

Causes typiques :

• Clé API mal copiée (espace en trop, caractère manquant).
• Clé révoquée ou expirée.
• Mauvais format dans l’en-tête (Bearer au lieu de Bearer xxx).

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é.
• Tentative d’accès à une ressource qui appartient à un autre utilisateur.
• Quota dépassé côté éditeur (rare mais possible).

Action : vérifiez les permissions de la clé chez l’éditeur, ajustez si besoin.

Erreur 404 — « Not Found »

L’URL appelée n’existe pas.

Causes typiques :

• Faute dans l’URL (typo, mauvais chemin).
• L’API a changé de version (v1 → v2).
• La ressource ciblée n’existe pas (ex. : créer un ticket dans un projet qui a été supprimé).

Action : vérifiez la documentation à jour de l’API.

Erreur 422 — « Unprocessable Entity »

La requête est bien formée, mais son contenu n’est pas accepté par le serveur (souvent un champ obligatoire manquant ou une valeur invalide).

Causes typiques :

• Un champ obligatoire n’est pas dans le corps de la requête.
• Une valeur n’est pas dans la liste autorisée (ex. : statut « Urgent » au lieu de « High »).
• Format de date incorrect.

Action : regardez la réponse du serveur — elle indique généralement quel champ pose problème. Ajustez le corps de la requête.

Erreur 429 — « Too Many Requests »

L’éditeur limite le nombre d’appels par minute / par heure. Vous l’avez dépassé.

Causes typiques :

• Beaucoup de conversations simultanées qui déclenchent la même action.
• Limite gratuite de l’API atteinte.

Action : si c’est rare, ignorez. Si c’est récurrent, contactez l’éditeur pour augmenter votre quota, ou mettez en place un système de file d’attente côté votre serveur.

Erreur 500-503 — Erreurs serveur

Le serveur distant a planté ou est indisponible. Pas votre faute.

Action : Sens-AI réessaie automatiquement 2 fois avec un délai. Si toutes les tentatives échouent, le client reçoit un message neutre du type « Désolé, je n’arrive pas à effectuer cette opération en ce moment. ». Surveillez les outages côté éditeur (page status.atlassian.com pour Jira, etc.).

Timeout (« Délai dépassé »)

Le serveur n’a pas répondu en moins de 30 secondes.

Causes typiques :

• Serveur surchargé.
• Action qui demande beaucoup de calcul côté serveur.

Action : optimiser le traitement côté votre serveur, ou si vraiment ça ne peut pas être plus rapide, contactez-nous pour augmenter le timeout sur votre tenant.

Astuce : un canal de logs dédié

Pour les actions critiques, on recommande d’envoyer une copie de chaque exécution dans un canal de logs (Slack, Discord, e-mail). Comment :

1. Créez une seconde action « Logger » qui envoie un message à votre canal.
2. Modifiez votre action principale pour qu’elle inclue à la fin un appel à « Logger ».

Vous avez ainsi une trace en temps réel de ce qui se passe, sans avoir à fouiller dans les logs Sens-AI.

Étape suivante

Si plusieurs actions ratent en même temps : c’est probablement un problème côté serveur ou un changement d’API. Voir aussi : Dépannage général (et les autres pages de la section Dépannage).