Les simulations vous permettent de valider les procédures Fin, de renforcer la confiance dans votre automatisation et de détecter les problèmes avant qu'ils n'affectent vos users. En modélisant des conversations complètes, les simulations aident votre équipe à gérer des scénarios à fort volume ou complexes, tels que les annulations et les remboursements, avec certitude.

Conçues pour remplacer les vérifications manuelles chronophages, les simulations vous aident à identifier les problèmes ou les changements progressifs dans le comportement de Fin à mesure que votre logique métier évolue.

Accéder aux simulations

Les simulations se trouvent dans le panneau de test d'une procédure. Pour y accéder :

Ouvrez la procédure que vous souhaitez tester.
Cliquez sur Test dans le coin supérieur droit de la zone de travail.
Sélectionnez l'onglet Simulations dans le panneau de droite.

Remarque : L'accès aux simulations nécessite la permission « Can manage workspace data ». Si le bouton Simulations ne répond pas, vérifiez que cette permission est activée pour votre rôle dans Paramètres > Workspace > Teammates.

Les simulations contournent la correspondance d'intention. Contrairement à l'aperçu ou aux conversations en direct, les simulations ne vérifient pas vos instructions « When to use this Procedure », elles supposent que la procédure a déjà été déclenchée et l'exécutent directement. Cela rend les simulations idéales pour tester la logique d'exécution isolément.

Important :

Aperçu montre l'expérience complète côté client, l'utiliser pendant que votre procédure est active peut exposer des messages à de vrais users.
Simulations exécutent la procédure en arrière-plan sans sortie visible pour les users, ce qui en fait le moyen le plus sûr de valider la logique avant la mise en production. Utilisez Aperçu pour des vérifications rapides ; utilisez Simulations avant chaque publication.

Créer une simulation

Vous pouvez créer une simulation de deux façons : en utilisant des suggestions générées par AI pour un démarrage rapide, ou en définissant manuellement le scénario pour un contrôle total.

Simulations générées par AI : Utilisez-les pour couvrir rapidement des scénarios clients courants ou attendus basés sur vos instructions. Fin AI génère des tests « prêts à l'emploi » pour vous faire gagner du temps.

Simulations manuelles : Utilisez-les lorsque vous avez besoin d'un contrôle précis des données, de cas limites spécifiques ou de branches particulières dans votre logique.

Simulations générées par AI

Basé sur vos instructions, Fin AI générera des tests de démarrage pour vous aider à créer rapidement des simulations « prêtes à l'emploi ».

Ouvrez l'onglet Simulations dans le panneau de droite de votre procédure.
Sous Suggested for these instructions, examinez la liste des scénarios proposés (par exemple, « Demande d'annulation complète »).
Cliquez sur l'icône Lecture à côté d'une suggestion pour l'exécuter instantanément.
Une fois une simulation créée ou acceptée parmi les suggestions, elle apparaîtra dans votre liste. Vous pouvez ensuite cliquer sur Exécuter tout pour lancer toutes vos simulations enregistrées en une seule fois.

Simulations créées manuellement

Vous pouvez également créer une simulation de zéro pour tester des cas limites spécifiques basés sur les instructions de la procédure.

Dans l'onglet Simulations, cliquez sur + Nouveau.
Nom de la simulation : Donnez un titre clair à votre simulation.
Simuler en tant que : Choisissez un user ou une marque spécifique pour tester la personnalisation. Vous pouvez sélectionner dans une liste déroulante de vrais users dans votre workspace.
Message d'ouverture du client : Saisissez le premier message envoyé par le client (par exemple, « J'ai besoin d'aide avec ma commande »). Vous pouvez également joindre une image, comme une capture d'écran d'une erreur, pour tester comment Fin gère le contexte visuel.
Détails supplémentaires : Fournissez des indications concernant la situation du client ou les actions spécifiques qu'il a entreprises.

Sélectionnez un canal

Les simulations vous permettent de sélectionner le canal que Fin utilisera pour cette simulation, afin que vous puissiez tester le comportement de Fin. Utilisez le menu déroulant du canal pour basculer entre Messenger et Email avant d'exécuter votre simulation.

Remarque : Fin se comporte différemment selon le canal. Dans Email, Fin agrège plusieurs informations en une seule réponse plutôt que d'envoyer plusieurs messages. Les directives et le ciblage de contenu peuvent également être configurés par canal - par exemple, les réponses Email peuvent adopter un ton plus formel ou inclure une introduction spécifique.

Définir les données disponibles

La section Données client disponibles pour Fin vous permet de définir les données auxquelles Fin a accès pendant le test. Cela garantit que vous testez avec des valeurs de données précises plutôt que de vous fier à des descriptions vagues.

Heure de la simulation : Utilisez ceci pour définir « quand » le scénario se déroule. Définir une date et une heure spécifiques vous permet de tester une logique sensible au temps, comme vérifier si un client est dans une fenêtre de remboursement de 30 jours.
Attributs et connecteurs de données : Cette section se remplit automatiquement avec les attributs référencés dans votre procédure. Mettez à jour ces valeurs (par exemple, définissez People.Plan sur « Pro ») pour tester différents résultats de branchement.

Remarque : Pour garantir que votre simulation s'exécute avec précision, placez les données en fonction du moment où Fin doit « savoir » :

Utiliser les attributs : Si Fin est censé déjà connaître l'information au début de la conversation (par exemple, le Plan actuel du client ou la date d'inscription).
Utiliser les détails supplémentaires : Si l'information doit être fournie par le client pendant la conversation (par exemple, le client fournit son « Order ID » dans une réponse ultérieure). Cela vous permet de tester si Fin capture et stocke correctement cette donnée dans un attribut.

Remarque : Les connecteurs de données n'utilisent pas de données users en direct dans les simulations. Au lieu d'appeler votre système externe, Fin utilise les valeurs de test que vous définissez dans la section Données client disponibles pour Fin. Assurez-vous d'avoir rempli vos champs de connecteur de données avec les valeurs que vous souhaitez que Fin utilise pendant le test — sinon le connecteur renverra des résultats vides.

Évaluer le comportement de Fin

Définissez les critères qui doivent être vrais pour que le test réussisse. Cliquez sur + Ajouter un critère et sélectionnez :

Réponse de Fin : Spécifiez ce que Fin doit (ou ne doit pas) dire pendant la conversation.
Attributs : Vérifiez si un attribut a été défini, n'a pas été défini, était égal à, ou n'était pas égal à une valeur spécifique.
Connecteur de données : Vérifiez si un connecteur est déclenché, n'est pas déclenché, ou est déclenché exactement X fois.
Résultat de l'instruction : Vérifiez si la conversation a atteint une conclusion spécifique, comme la fin, le transfert à un coéquipier, ou d'autres résultats comme le passage à une autre procédure.

Une fois configuré, cliquez sur Enregistrer.

Remarque : Lorsque vous cliquez sur Enregistrer, Fin utilise l'AI pour examiner votre formulaire de simulation. Si les instructions sont floues ou si les critères de réussite sont incohérents, vous verrez des recommandations pour améliorer le test et obtenir des résultats plus précis.

Meilleures pratiques pour la couverture de simulation

Pour tirer le meilleur parti des simulations, structurez votre suite de tests autour de ces principes :

Testez une branche par simulation. Si votre Procedure comporte des Conditions ou des sous-procédures avec plusieurs chemins, créez une simulation distincte pour chaque branche. Cela crée un filet de sécurité contre les régressions — si une modification future casse un chemin spécifique, vous le détecterez immédiatement.
Couvrez à la fois les chemins de succès et d’échec pour les Data Connectors. Exécutez une simulation où votre connecteur renvoie des données valides, et une autre où il ne renvoie rien ou échoue. Cela vérifie que votre logique de secours (par exemple, une étape @Condition gérant une réponse vide) fonctionne correctement.
Exécutez toutes les simulations avant de publier les modifications. Après avoir modifié une Procedure, cliquez sur Run all pour réexécuter toute votre suite avant la mise en production. Toute simulation qui échoue nouvellement signale une régression introduite par votre modification.
Utilisez des noms de simulation descriptifs. Nommez chaque simulation d’après le scénario qu’elle représente (par exemple, « Remboursement complet — dans les 30 jours » ou « Annulation — commande non trouvée »). Cela facilite l’identification du test couvrant chaque chemin lors de la revue des résultats.

Stratégie de test : chemin heureux, chemin à risque et cas limites

Une suite de simulation bien équilibrée couvre trois types de scénarios. Ensemble, ils vous donnent la confiance que votre Procedure fonctionne correctement dans des conditions normales, gère les échecs avec élégance, et ne casse pas lorsque les clients se comportent de manière inattendue.

Chemin heureux
Le chemin heureux représente le flux idéal et ininterrompu — un client qui fournit exactement les bonnes informations et remplit toutes les conditions pour que Fin complète la Procedure avec succès. Commencez toujours par là. Si le chemin heureux échoue, déboguer des chemins plus complexes devient beaucoup plus difficile.
Exemple : Un client demande un remboursement dans le délai de 30 jours, possède un ID de commande valide, et le Data Connector renvoie les détails de sa commande. Fin traite le remboursement et le confirme en une seule passe.
Chemin à risque
Les chemins à risque testent les scénarios les plus susceptibles de mal tourner en production — typiquement lorsque des données externes manquent, que les conditions ne sont pas remplies, ou qu’une branche de secours doit s’activer. Ce sont les tests qui protègent vos clients contre des réponses incorrectes ou incomplètes.
Exemples : Le Data Connector ne renvoie aucune commande (testez que Fin demande au client son ID de commande). Le client est hors délai de remboursement (testez que Fin communique la bonne politique et propose le bon transfert). Un attribut est vide lorsqu’une étape Condition l’évalue (testez que le chemin de secours de Fin s’active correctement).
Cas limites
Les cas limites couvrent des entrées inhabituelles ou en conditions limites qui sont techniquement valides mais rares. Ces tests sont particulièrement importants pour les Procedures avec une logique sensible au temps, des seuils numériques, ou des entrées clients en texte libre.
Exemples : Un client demande un remboursement exactement au jour 30 (la limite de la période). Un client envoie un message d’ouverture ambigu pouvant correspondre à plusieurs intentions. Un client fournit son ID de commande dans un format inattendu ou inclut du texte supplémentaire à côté.

Astuce : Utilisez des noms de simulation descriptifs pour indiquer à quelle catégorie appartient chaque test — par exemple, « Remboursement — chemin heureux », « Remboursement — commande non trouvée (risque) », ou « Remboursement — jour limite 30 (limite) ». Cela facilite la détection rapide des lacunes dans votre couverture.

Exécution et revue des résultats

Une fois que vous lancez un test, il apparaît dans le panneau Tests à droite avec un indicateur de statut :

En cours d’exécution : Le test est en cours d’exécution active.
Réussi : Le test a été exécuté et a satisfait tous les critères de succès définis.
Échoué : Le test a été exécuté mais n’a pas satisfait les critères de succès définis.
En file d’attente : Le test a été initié mais attend que la simulation précédente se termine avant de s’exécuter.

Pour enquêter sur un résultat, cliquez sur Voir la conversation. Cela ouvre la transcription complète des échanges entre le client simulé et Fin, facilitant la compréhension du déroulement et des raisons d’un succès ou d’un échec.

Débogage d’une Simulation échouée

Lorsqu’une simulation est marquée Échoué, la transcription disponible via Voir la conversation contient tout ce dont vous avez besoin pour identifier la cause racine. Voici comment la lire efficacement :

Réflexions de Fin
À chaque étape de la conversation, développez le raisonnement de Fin pour voir comment il a interprété le message du client, quelle étape de la Procedure il exécutait, et quelle décision il a prise. Si Fin a pris un chemin inattendu, ses réflexions vous montreront généralement où son interprétation a divergé de votre intention. Cherchez les étapes où l’interprétation d’un attribut ou d’une condition par Fin ne correspond pas à ce que vous attendiez.
Événements de conversation
Les événements de conversation apparaissent en ligne dans la transcription et montrent des actions de bas niveau telles que les mises à jour d’attributs, les appels aux Data Connectors, et les déclencheurs de transfert. Utilisez-les pour vérifier que les bons connecteurs se sont déclenchés au bon moment et que les attributs ont été définis aux valeurs attendues avant chaque étape de branchement.
Localisation de l’échec
Recoupez ce que vous voyez dans les réflexions de Fin et les événements de conversation avec vos critères de succès définis. Un schéma courant est une étape Condition qui évalue vers la mauvaise branche — typiquement parce qu’un attribut était vide ou avait une valeur inattendue. Vérifiez votre configuration Données client disponibles pour Fin pour vous assurer que tous les attributs requis étaient remplis avant l’exécution de la simulation.

Astuce : Après avoir identifié la cause, ajustez votre Procedure ou la configuration de la simulation et cliquez sur Run sur la même simulation pour retester immédiatement. Vous n’avez pas besoin de créer une nouvelle simulation — celle existante conserve sa configuration.

Limites d’utilisation des simulations

Il y a une limite au nombre de simulations que vous pouvez exécuter chaque mois. Cette limite est appliquée au niveau de l’espace de travail et se réinitialise le premier jour de chaque mois civil.

Chaque espace de travail reçoit une allocation mensuelle de simulations. Cette allocation est basée sur le segment de volume de conversation de votre espace de travail, les clients plus importants recevant des allocations plus élevées.

L’allocation de simulations est basée sur le volume de conversation de votre espace de travail dans Intercom.

Nous assignons votre espace de travail à un segment en utilisant le nombre de conversations du dernier mois civil.
Votre segment est réévalué chaque mois et votre allocation reflétera le volume de conversation le plus récent de votre mois précédent.
Si votre volume de conversation augmente ou diminue, votre allocation de simulations peut changer lors du prochain cycle mensuel.

Segment de volume de conversation	Limite de simulations par mois
Moins de 1K	50
1K–15K	200
15K–100K	350
100K–1M	1000
1M+	2500

Surveillance de votre utilisation

Pour vous aider à gérer vos tests, Fin fournit des indicateurs visuels dans l’onglet Simulations :

Alerte d’utilisation

Lorsque votre espace de travail atteint 80 % de sa limite mensuelle, une bannière d’avertissement jaune apparaît. Elle affiche votre utilisation actuelle (par exemple, « 85/100 ») et vous rappelle quand la limite sera réinitialisée.

Limite atteinte

Une fois que vous atteignez 100 % de votre limite mensuelle, un message d’erreur rouge s’affiche. Vous ne pourrez plus lancer de simulations jusqu’au début du mois suivant.

Remarque : Si vous atteignez votre limite, vous pouvez toujours consulter les résultats et transcriptions des simulations précédentes en cliquant sur Voir la conversation, mais les boutons Exécuter et Tout exécuter seront désactivés.

FAQ

Les simulations interagissent-elles avec mes API en direct ou des données externes ?

Non. Contrairement à l’outil Aperçu, les simulations ne sollicitent pas les API réelles ni les systèmes externes (comme Shopify ou Stripe). Il est impossible de lire ou de modifier des données dans une API externe pendant une simulation. Cela garantit que vous pouvez tester la logique en toute sécurité sans impacter les données réelles.

Pourquoi utiliser les Simulations plutôt que les tests manuels ?

Les simulations vous permettent de valider les Procedures à grande échelle et d’assurer que Fin fonctionne de manière fiable dans des scénarios complexes et à haut risque — contrairement aux tests manuels, qui conviennent mieux aux vérifications rapides ou aux revues de configuration. Exécuter des Simulations avant chaque lancement vous aide à détecter tôt les comportements inattendus.

Que se passe-t-il si une Simulation échoue ?

Une Simulation échouée peut être examinée en détail — ouvrez la conversation simulée pour comprendre pourquoi Fin n’a pas agi comme prévu, ajustez votre Procedure, puis relancez la Simulation sans impact pour les clients.

Pourquoi ma simulation est-elle marquée « Échouée » alors que Fin a résolu le problème avec succès ?

Une Simulation marquée « Échouée » malgré la résolution du problème par Fin signifie généralement que vos Critères de réussite sont trop stricts. Par exemple, si vous exigez que Fin « Demande un ID de commande », mais que Fin est assez intelligent pour trouver l’ID automatiquement, le test échouera car Fin a sauté la question. Mettez à jour vos critères pour vous concentrer sur le résultat final (par exemple, « Procedure terminée ») plutôt que d’imposer des étapes intermédiaires spécifiques.

Fin s’arrête en cours de simulation. Pourquoi se bloque-t-il ?

Fin s’arrête souvent s’il rencontre une « impasse » dans vos instructions, comme vérifier une variable qui s’avère vide (par exemple, People.signed_up). Si vous n’avez pas indiqué à Fin quoi faire en cas de données manquantes, il s’arrêtera. Assurez-vous que vos instructions prévoient un plan de secours, par exemple : « Vérifiez si la variable a une valeur. Si elle est vide, demandez la date au client. »

Où dois-je saisir des données de test comme « Dates d’inscription » ou « Historique des commandes » ?

Les données de test comme les dates d’inscription ou l’historique des commandes doivent être saisies dans la section Données client disponibles pour Fin de la configuration de la simulation — pas dans le message d’ouverture du client ni dans les champs Détails supplémentaires, car Fin pourrait les manquer. Saisissez des valeurs exactes (par exemple, 2024-06-01) dans les Attributs ou Variables spécifiques que vous testez.

Mon outil fonctionne en conditions réelles, mais échoue en simulation. Pourquoi ?

Les simulations ne récupèrent pas de données réelles depuis des systèmes externes, donc votre Data Connector ne renverra pas de résultats en direct comme dans une conversation réelle. Si votre connecteur fonctionne en conversation réelle mais échoue en simulation, c’est probablement parce que les valeurs de retour attendues n’ont pas été définies dans la section Données client disponibles pour Fin. Ajoutez les données que votre connecteur renverrait normalement comme valeurs de test, puis relancez la simulation.

Les Simulations sont-elles facturées séparément des Procedures ?

Les Simulations sont incluses avec les Procedures et ne sont pas facturées séparément. Vous n’aurez pas de frais supplémentaires pour l’exécution des simulations.

Pourquoi devrais-je tester ma Procedure par Email ?

Tester votre Procedure par Email valide un comportement spécifique au canal qui diffère de Messenger. Par Email, Fin agrège plusieurs informations en un seul email au lieu d’envoyer plusieurs messages. Les Consignes et le Contenu peuvent aussi être ciblés sur des canaux spécifiques — par exemple, les réponses Email peuvent être configurées pour utiliser un ton plus formel ou inclure une introduction spécifique. Simuler des conversations Email vous permet de valider ce comportement et de déployer Email en toute confiance.

Pourquoi y a-t-il une limite sur les exécutions de Simulation ?

Chaque exécution de simulation nécessite des ressources pour générer des prédictions IA précises. Nous fournissons une allocation mensuelle pour vous permettre de tester vos Procedures librement pour les cas d’usage standard tout en évitant que des usages extrêmes ne génèrent des coûts excessifs.

Puis-je simuler une sous-procedure indépendamment ?

Non. Les sous-procedures n’ont pas leur propre panneau de simulation et ne peuvent pas être exécutées isolément. Pour tester une sous-procedure, lancez une simulation sur la Procedure parente et configurez le scénario pour que le chemin d’exécution atteigne la sous-procedure — en définissant le message client, les attributs et les détails supplémentaires pour déclencher la branche spécifique qui l’appelle.

Si vous avez plusieurs sous-procedures dans la même parente, créez une simulation distincte pour chacune, chaque simulation couvrant le scénario qui mène à l’appel de cette sous-procedure.

Mon Data Connector renvoie des résultats vides en simulation. Que dois-je faire ?

Des résultats vides du Data Connector en simulation sont généralement causés par des données de test manquantes. Les simulations ne récupèrent pas de données en direct depuis des systèmes externes — vous devez définir les valeurs que votre Data Connector doit renvoyer dans la section Données client disponibles pour Fin de la configuration de la simulation. Vérifiez que vous avez rempli les champs Data Connector pertinents avec les valeurs de test que vous souhaitez que Fin utilise.

Si vous testez intentionnellement le chemin « le connecteur ne renvoie rien », c’est un comportement attendu — et exactement ce que vous devez tester. Assurez-vous que votre Procedure a une étape de secours @Condition qui gère les réponses vides du connecteur :

Si le connecteur renvoie vide même pour un user avec des données réelles, vérifiez que votre contact test a un external_id valide correspondant à l’identifiant client de votre système externe.

Exécutez des simulations pour les procédures Fin