Skip to main content
Vous préférez le dashboard ? Cette même fonctionnalité est disponible dans Simulations (/dashboard/simulations), y compris la génération de scénarios par IA — consultez Simuler un appel. Cette page couvre l’approche programmatique.
Itérer sur un agent IA implique d’itérer sur son prompt, ses outils et sa façon de gérer les cas limites. L’API test-calls exécute de vrais appels (bot à bot ou boucle SIP) sur un agent à l’aide d’un prompt de scénario que vous fournissez — chaque exécution génère un véritable journal d’appel avec transcription, évaluation et facturation, afin de voir précisément comment l’agent se comporte et ce qu’il coûte. Utilisez-la pour :
  • Des tests de fumée avant le déploiement après chaque modification du prompt
  • Des suites de régression intégrées à la CI (branchez le webhook test-call.completed → faites échouer le build si le score baisse)
  • Tester les limites de concurrence sous contrainte

Exécution unique : un seul test

Champs : La réponse est un objet d’exécution d’appel de test avec status="queued". Interrogez-le jusqu’à ce que status devienne completed ou failed ; une fois call_id défini, récupérez la transcription via GET /v1/calls/{call_id}/transcript.

Lots : scénarios en parallèle

Exécutez N scénarios simultanément — utile pour les suites de régression qui couvrent chaque cas limite connu en parallèle :
La réponse contient une liste run_ids d’identifiants d’exécutions enfants. Récupérez le statut du lot :
run_count est limité à 20 ; stagger_seconds espace les lancements pour éviter de surcharger l’agent (0–60 s).

L’intégrer à la CI

Créez une suite de contrôle de version sur la page Simulations (/dashboard/simulations) — sélectionnez l’agent, ajoutez des scénarios manuellement ou cliquez sur Générer des scénarios avec l’IA pour les rédiger à partir du prompt de l’agent (avec un passage facultatif sur les cas limites), puis regroupez-les dans une suite. Une suite fige ses scénarios et son agent, ainsi qu’un taux de réussite minimal et une règle facultative exigeant zéro échec critique. Les exécutions réussies deviennent la référence acceptée ; les transitions ultérieures de réussite à échec sont renvoyées comme régressions. Utilisez une clé API d’organisation dans votre CI. Ce script déclenche la suite, interroge son état jusqu’à ce que la notation et la comparaison soient terminées, puis se termine avec un code différent de zéro sauf si le verdict est pass :
POST /v1/orgs/{org_id}/suites/{suite_id}/run renvoie 202 avec l’ID d’exécution. GET /v1/orgs/{org_id}/suites/{suite_id}/runs/{run_id} renvoie status, verdict, pass_rate, critical_failure_count et la liste de référence regressions. Les deux endpoints associent l’organisation de l’URL à l’organisation de la clé API.

Modèles

Corpus de régression par prompt

Conservez un fichier JSON de tuples {name, scenario_prompt, expected_outcome}. À chaque modification du prompt, exécutez l’ensemble complet par lot ; comparez les transcriptions et les notes avec l’exécution précédente.

Test smoke par version

Un seul lot de cinq scénarios de parcours nominal à exécuter après chaque déploiement. Sensible à la latence, conservez donc stagger_seconds: 0.

Benchmarking de la latence

Exécutez des scénarios identiques sur différents niveaux de produit (spark, bolt, storm-base). Comparez les scores call.graded et duration_seconds de chaque journal d’appel obtenu.

Étapes suivantes

Référence des appels de test

Chaque paramètre de requête, code d’état et format de lot.

Notation par IA

Notez automatiquement chaque exécution de test pour suivre la qualité dans le temps.

Rapports de problème

Signalez des tests spécifiques pour examen humain.

Webhook test-call.completed

Transmettez les résultats à votre CI / Slack / PagerDuty.