Essais

Un essai exécute le brouillon d’un workflow sur des données réelles — un vrai mail de vos boîtes, un corps JSON que vous écrivez, ou le dernier élément d’un service connecté —, mais sans ses effets : rien n’est envoyé, déplacé, écrit ni publié. Les lectures, en revanche, sont réelles, et les modèles d’IA sont réellement appelés. Un essai montre exactement ce que ferait le workflow, étape par étape, avec les données que produit chaque étape.

Les essais sont l’outil de construction d’un workflow. Le workflow n’a pas besoin d’être publié, et un essai ne modifie jamais la version publiée.

Lancer un essai

Dans l’éditeur, un essai part de :

• Tester le workflow, dans l’en-tête : exécute tout le brouillon. Pendant l’essai, le bouton affiche « Essai en cours… ».
• Tester sur un déclencheur (sur le canvas ou dans sa fiche), ou « Tester avec ce mail » pour un déclencheur mail : exécute les branches de ce déclencheur.
• Tester jusqu’ici sur n’importe quel nœud (dans sa fiche, dans le menu du canvas, ou avec le raccourci Mod+Entrée) : exécute seulement ce nœud et ceux dont il dépend, puis s’arrête. Utilisez-le pour vérifier une étape sans exécuter le reste du graphe.

Avant chaque essai, l’éditeur enregistre le brouillon. Si l’enregistrement échoue, l’essai ne part pas : « L’essai n’est pas parti : le brouillon n’a pas pu être enregistré. »

Ce qui bloque un essai. Un brouillon qui a des erreurs bloquantes ne peut pas être essayé : l’onglet Essai affiche « L’essai n’est pas parti : le brouillon a des erreurs bloquantes » et la liste des nœuds à corriger — cliquez une ligne pour ouvrir le nœud. Les avertissements ne bloquent pas. Un nœud désactivé ne peut pas être la cible de « Tester jusqu’ici », pas plus qu’un nœud fournisseur de modèle (il ne s’exécute jamais seul : branchez-le sur un nœud IA).

Quel déclencheur. Quand le brouillon a plusieurs déclencheurs, seules les branches du déclencheur depuis lequel vous testez s’exécutent. S’ils sont de natures différentes (un déclencheur mail et un déclencheur webhook, par exemple), choisissez-le sous « Tester depuis ». Les déclencheurs désactivés restent testables.

Sur quoi porte un essai

Chaque sorte de déclencheur demande une entrée différente :

Déclencheur	Entrée de l’essai
Mail reçu, Lancement manuel	le mail d’essai actif, un vrai mail de l’une de vos boîtes
Webhook reçu	un corps d’essai : le JSON qu’un appelant enverrait, placé sous data.webhook
Appelé par un workflow	un corps d’essai : le JSON que transmettrait un workflow appelant, placé sous data.input
MyNotary — événement, Yousign — événement, Notion — événement	un corps d’essai, placé sous la clé propre au déclencheur (data.mynotary, data.yousign, data.notion)
Ligne Airtable modifiée, Entrée Notion modifiée	le service est réellement interrogé et la ligne ou l’entrée la plus récente est utilisée ; rien à fournir
Planification	rien : l’exécution est rejouée maintenant, sans entrée

Un corps d’essai est limité à 256 Ko, comme un vrai appel de webhook. « Remettre l’exemple » rétablit le corps d’exemple.

Pour les déclencheurs par sondage, l’essai ne déplace jamais la position du déclencheur : ce que montre l’essai sera quand même traité par les vraies vérifications une fois le workflow publié. Si l’interrogation du service échoue (connexion révoquée, base supprimée), l’essai rapporte la vraie raison au lieu de tourner à vide. Si rien n’est trouvé, l’essai s’exécute avec des données vides.

Le mail d’essai

Pour les déclencheurs mail, un essai rejoue un vrai mail de vos boîtes — y compris l’historique importé à la connexion de la boîte. Choisissez-le dans la fenêtre Mail d’essai :

• Vos mails d’essai : jusqu’à 20 mails gardés pour ce workflow (« {count}/{max} mails gardés »). Ils sont conservés avec le workflow, vous les retrouvez plus tard.
• Un seul est actif à la fois — « c’est celui-là que « Tester » rejoue, toujours sans envoi réel ». Cliquez « Rendre actif » pour changer ; « Retirer de la liste » pour en retirer un.
• Ajouter un mail de votre boîte : cherchez dans le miroir (le filtre agit à partir de deux caractères), puis gardez le mail.
• Depuis le webmail, « Garder comme mail d’essai » ajoute le mail ouvert à la liste d’un workflow.

Si vous cliquez Tester sans mail d’essai actif, l’éditeur vous demande d’abord d’en choisir un (« Choisissez le mail d’essai actif avant de lancer un essai. »). Le mail doit appartenir à l’une de vos propres boîtes. Un mail supprimé du miroir disparaît de la liste.

Par l’API : GET et PUT /api/v1/workflows/:id/test-messages lisent et remplacent la liste ({ "messageIds": [ … ] }, 20 au plus).

Lire un essai

Chaque étape de l’essai affiche, sur le canvas et dans l’onglet Essai :

• son statut, la sortie qu’elle a prise (« Sortie : {port} ») et sa durée ;
• Données produites : les données publiées par l’étape, celles-là mêmes que les nœuds suivants lisent avec des expressions. Les données très volumineuses sont tronquées dans l’aperçu (« Données tronquées — trop volumineuses pour l’aperçu. ») ;
• ce que l’étape aurait fait : « Aurait : {description} » pour chaque effet retenu — par exemple le message qu’elle aurait envoyé, avec ses destinataires, ou la requête qu’elle aurait faite.

Les étapes apparaissent à mesure qu’elles se terminent. Un essai est aussi une entrée de l’onglet Exécutions du workflow, marquée comme essai (voir Retrouver les essais).

Les sorties épinglées

Épingler la sortie d’un nœud la fige : pendant un essai, le nœud épinglé n’est pas exécuté, et les nœuds suivants reçoivent la sortie épinglée comme si le nœud l’avait produite. Servez-vous-en pour :

• ne plus appeler à chaque essai un nœud lent ou coûteux (un modèle d’IA, un service extérieur) pendant que vous travaillez plus bas dans le graphe ;
• construire la fin d’un workflow avant que son début fonctionne, en écrivant la sortie à la main ;
• garder un cas précis (une catégorie, une valeur extraite) pour tester une branche.

Dans la fiche du nœud, après un essai, épinglez la sortie que le nœud vient de produire, ou écrivez-la à la main (« Écrire la sortie à la main ») : ce doit être un objet JSON, pré-rempli avec la sortie du dernier essai quand il y en a une. Un nœud épinglé porte la marque « Sortie épinglée » sur le canvas et « (non exécuté) » dans l’essai. Retirez l’épingle pour exécuter de nouveau le nœud.

Limites et règles :

• une sortie épinglée fait au plus 256 Ko de JSON et doit être un objet JSON ;
• une sortie issue d’un essai peut contenir des identifiants qui n’existent pas (un brouillon jamais créé) : l’éditeur prévient avant de l’épingler ;
• les épingles sont enregistrées avec le brouillon (le champ pins du document du workflow), mais une exécution réelle les ignore : seuls les essais s’en servent ;
• une épingle posée sur un nœud qui n’existe plus est ignorée.

Ce qui est réel et ce qui est seulement décrit

Pendant un essai, chaque nœud exécute son vrai code. Ce qui change, ce sont les services qu’il utilise : ceux qui agiraient sur le monde extérieur sont remplacés par des doublures qui décrivent l’action au lieu de la faire. En bref :

• Réel : la lecture du miroir et des pièces jointes, l’extraction de texte, les appels aux modèles d’IA, la lecture des tables, la recherche dans les espaces de fichiers et les agendas, la lecture des données d’intégration, la consultation du carnet.
• Seulement décrit : l’envoi, le brouillon, le classement et le marquage des mails ; toutes les requêtes HTTP de Requête HTTP et de Notifier, GET compris ; toute écriture dans une table, un espace de fichiers, un agenda, une feuille de calcul ou une intégration ; les signaux, les attentes et les approbations.

Chaque nœud déclare un effet (none, external_write ou send, voir Workflows). Il dit ce que le nœud peut faire hors du produit ; le tableau ci-dessous donne ce qui se passe réellement pendant un essai.

Nœud	Effet	Pendant un essai
Déclencheurs (trigger.*)	none	fournissent l’entrée décrite plus haut
ai.categorize, ai.extract, ai.summarize, ai.prompt, ai.compose	none	le modèle est réellement appelé (voir L’IA pendant un essai)
Fournisseurs de modèles (llm.*)	none	utilisés par le nœud IA sur lequel ils sont branchés
mail.compose	none	compose réellement le message ; rien n’est enregistré ni envoyé
mail.send	send	décrit : ni brouillon ni message ; l’étape dit ce qui aurait été enregistré ou envoyé
mail.move, mail.flag	external_write	décrit : le mail n’est pas touché
attachment.extract_text	none	réel : les pièces jointes sont lues
http.request	external_write	décrit, GET compris : rien ne sort du serveur ; l’étape rend le statut 200 et un corps vide {}
notify.send	external_write	décrit : rien n’est publié
table.find, table.list	none	réel : la table est lue
table.insert, table.update, table.upsert, table.delete, table.append_text	external_write	décrit : rien n’est écrit, mais la ligne est réellement recherchée quand le nœud en a besoin
google_drive.search, onedrive.search	none	réel
google_calendar.find_free, outlook_calendar.find_free	none	réel
google_drive.upload, google_drive.create_folder, onedrive.upload, onedrive.create_folder	external_write	décrit : rend des identifiants qui commencent par simulated
google_calendar.create_event, outlook_calendar.create_event	external_write	décrit : aucun évènement, personne n’est invité
google_sheets.append	external_write	décrit : rien n’est écrit
airtable.api, sharepoint.api, calendly.api, excel.api, notion.api, mynotary.api, yousign.api	external_write	mixte : les opérations de lecture s’exécutent réellement ; les opérations de création, modification, suppression, téléversement et envoi sont seulement décrites
flow.if, flow.switch, flow.stop, data.transform, date.compute	none	réel : ils ne font que calculer
flow.loop	none	n’exécute que les premières itérations (voir Les limites des essais)
flow.wait	none	n’attend pas : continue aussitôt, et ses données disent combien de temps il aurait attendu
flow.approval	none	ne demande rien à personne : prend aussitôt la branche « approuvé » et consigne la demande qu’il aurait envoyée
flow.signal	external_write	décrit : le signal n’est pas émis, aucune exécution réelle n’est donc réveillée ni annulée
workflow.call	none	le workflow appelé s’exécute réellement, lui aussi sous forme d’essai : ses propres effets sont décrits

Pour les nœuds d’intégration à plusieurs opérations, les pages des nœuds disent exactement quelles opérations sont lues pour de bon. Beaucoup de nœuds ajoutent aussi simulated: true à leurs données quand leur effet a seulement été décrit ; chaque page de nœud dit ce qu’il rend pendant un essai.

L’IA pendant un essai

Les nœuds IA appellent le vrai modèle pendant un essai, avec le fournisseur et le modèle qu’ils utiliseraient en exécution réelle : vous lisez la vraie catégorie, la vraie extraction, le vrai résumé ou le vrai brouillon. Conséquences :

• un appel d’essai coûte autant qu’un appel réel, et apparaît dans Usage et coûts de l’IA ;
• les quotas, les modèles refusés et les pannes du fournisseur font échouer l’essai comme ils feraient échouer une exécution réelle.

C’est seulement quand l’instance n’a aucun fournisseur d’IA configuré qu’un essai fabrique la sortie à la place (un texte fixe, ou des valeurs de remplissage de la forme attendue). L’étape l’indique alors : « IA sautée : aucune clé sur cette instance » — « La sortie a été fabriquée, ce n’est pas une réponse de modèle. » Configurez un fournisseur (voir Intégrations) pour obtenir de vraies réponses.

Les limites des essais

Point	Pendant un essai
Version	toujours le brouillon ; pour exécuter réellement la version publiée sur un mail, utilisez un lancement manuel
Boucles	seules les premières itérations s’exécutent : 3 par défaut, LOOP_SIMULATED_MAX_ITERATIONS (1 à 50). L’étape de boucle l’indique ; le nombre maximal d’éléments de l’instance ne s’applique pas
Sous-workflows	le workflow appelé exécute sa version publiée, sous forme d’essai ; une cible non publiée, en pause ou archivée fait échouer l’étape comme en exécution réelle. Les appels s’enchaînent sur trois niveaux au plus
Nouvelles tentatives	autant de tentatives qu’en exécution réelle, mais 2 secondes seulement entre deux tentatives
Délais d’expiration	les mêmes délais par étape qu’en exécution réelle
Workflow d’erreur	jamais lancé par un essai en échec
Rejeu	un essai ne se rejoue pas depuis la liste des exécutions : lancez un nouvel essai depuis l’éditeur
Un à la fois	l’éditeur exécute un essai à la fois ; un nouvel essai remplace le précédent dans l’onglet Essai
Priorité	les essais passent devant le travail réel dans la file, pour que l’éditeur réponde vite

Un essai ne vérifie pas si le workflow est en pause ou archivé, et ne compte pas comme une exécution réelle pour la règle « une exécution par mail et par version » : vous pouvez essayer le même mail autant de fois que vous voulez.

Retrouver les essais

Les essais sont conservés comme les exécutions réelles, et marqués comme tels :

• dans l’onglet Exécutions du workflow, filtrez avec « Essais et réelles », « Essais seulement » ou « Réelles seulement » ; les essais portent le badge « Simulée » ;
• sous Activité → Exécutions, le filtre « Type » affiche « Réelles » par défaut ; choisissez « Essais » ou « Réelles et essais » pour les voir. Un essai porte la marque « Essai » : « Un essai lancé depuis l’éditeur : aucun effet réel n’est parti. » ;
• le détail d’un essai indique « Simulée », là où une exécution réelle indique « Réelle — les effets sont partis ».

Par l’API, GET /api/v1/executions?simulated=true liste les essais, et POST /api/v1/workflows/:id/test en lance un. Son corps accepte messageId (déclencheurs mail), triggerData (corps d’essai), triggerNodeId (le déclencheur depuis lequel tester, requis quand les déclencheurs sont de natures différentes) et targetNodeId (« jusqu’ici »). La réponse est 202 avec l’exécution et les étapes planifiées ; les refus sont 422 workflow.not_publishable (erreurs bloquantes, avec la liste), 404 workflow.test_message_not_found, 400 workflow.trigger_required, 400 workflow.unknown_node, 400 workflow.node_not_executable et 502 workflow.trigger_poll_failed.

Combien de temps les essais sont conservés

Les essais, avec leurs étapes et leurs données, sont supprimés 7 jours après leur création. Le réglage d’instance SIMULATED_EXECUTIONS_RETENTION_DAYS change ce délai (1 à 365 jours). Les exécutions réelles suivent leur propre durée de conservation, décrite dans Exécutions.

Pages liées

• Exécutions
• Données et expressions
• Brouillon, version publiée et historique
• Workflows