12 — Actions Externes

1. Objectif métier

Connecter WASEL à vos outils tiers (CRM, ERP, ticketing, facturation, logistique) pour automatiser des actions métier depuis les conversations.

Objectifs pratiques:

éviter les doubles saisies,
récupérer des informations en temps réel,
exécuter des actions externes depuis un workflow client.

2. Qui utilise ce module (admin/operator)

admin: crée et gouverne les actions externes (accès, mapping, temps de réponse, messages de retour).
operator: exploite les résultats dans la relation client (suivi, confirmation, relance).

3. Prérequis

Avant de créer une action externe:

propriétaire métier identifié côté outil tiers,
scénario fonctionnel validé (ex: créer ticket, lire statut commande),
méthode d’authentification disponible,
dictionnaire des données d’entrée/sortie préparé,
stratégie de secours définie (message d’échec, bascule opérateur).

Contraintes importantes:

chaque action doit avoir une clé métier unique,
les informations d’accès sensibles doivent rester confidentielles,
le délai d’attente doit être adapté à l’usage client,
le résultat utile doit être mappé explicitement pour être réutilisable ensuite.

4. Procédure pas-à-pas (orientée actions produit)

Définir l’usage métier exact.

Exemple: “créer un ticket SAV” ou “récupérer le statut de livraison”.

Créer l’action externe avec une convention de nommage stable.

Nom compréhensible par l’équipe.
Clé fonctionnelle unique.

Choisir le mode de réponse opérationnel.

Synchrone: résultat immédiat au client.
Asynchrone: accusé de réception puis traitement différé.
Silencieux: pas de message automatique direct.

Configurer l’authentification.

Sélectionner le type adapté au système tiers.
Vérifier que tous les champs obligatoires sont fournis.

Définir les données d’entrée.

Mapper les informations depuis le contact, les données collectées en conversation, et les paramètres du scénario.
Prévoir des valeurs par défaut pour les champs non critiques.

Définir les données de sortie utiles.

Extraire les champs nécessaires (ex: identifiant ticket, statut, lien document).
Stocker ces valeurs pour les réutiliser dans les messages suivants.

Configurer les messages client.

message de succès,
accusé de réception (si asynchrone),
message d’erreur compréhensible.

Tester la chaîne complète.

cas nominal,
erreur d’authentification,
réponse lente,
réponse incomplète.

Mettre en production avec supervision.

Suivre les échecs les premiers jours.
Ajuster mapping, délai et messages selon les retours.

5. Scénarios concrets (minimum 2)

Scénario A (création ticket support):
- le client demande une assistance,
- l’action externe crée un ticket,
- l’identifiant ticket est réinjecté dans la réponse client.
Scénario B (statut commande):
- le client demande le suivi,
- l’action externe récupère le statut,
- la réponse client affiche un statut clair et actionnable.
Scénario C (envoi document):
- l’action externe retourne un lien de document,
- le document est envoyé au client dans la conversation.

6. Erreurs fréquentes et résolution

Problème: l’action échoue dès le lancement.
Causes fréquentes: authentification incomplète, clé inactive, paramètre obligatoire absent.
Résolution: vérifier d’abord l’accès, puis le mapping des entrées.
Problème: réponse incompréhensible pour l’équipe.
Cause fréquente: champs de sortie non mappés.
Résolution: définir explicitement les sorties utiles et leur nom métier.
Problème: délai trop long perçu par le client.
Cause fréquente: mode synchrone sur une opération lourde.
Résolution: passer en mode asynchrone avec accusé de réception.
Problème: données dynamiques non remplacées dans le message final.
Cause fréquente: variable absente ou mal nommée.
Résolution: harmoniser les noms de variables et retester avec un contact réel.

7. Bonnes pratiques et limites

Concevoir une action externe pour une seule finalité métier.
Utiliser des noms stables et explicites.
Garder des délais courts pour les interactions client en direct.
Prévoir systématiquement une voie de secours (message clair + relais opérateur).
Journaliser les erreurs avec contexte métier (pas de secret exposé).

Limites:

certaines méthodes d’authentification avancées ne sont pas adaptées à tous les contextes,
certains mécanismes de renouvellement automatique d’authentification nécessitent un traitement complémentaire selon votre architecture,
une sortie non mappée reste inutilisable pour les étapes suivantes,
une dépendance externe instable doit être traitée avec un plan de continuité.

8. Référence rapide (champs/statuts/modes)

Modes de réponse:

sync: résultat immédiat,
async: accusé immédiat + traitement différé,
none: aucune réponse automatique.

Authentification disponible:

none,
api_key,
bearer_token,
basic,
custom_header,
oauth2_client_credentials.

Sources de données d’entrée:

informations contact,
données collectées en conversation,
données de contexte temporaire,
paramètres fournis au moment de l’action,
valeurs fixes.

États d’exécution:

pending,
running,
success,
failed.