# Exécutions et logs | Docs - nodulz

Source: https://nodulz.com/fr/docs/executions

Language: fr

Une exécution correspond à un lancement du workflow. Pour vérifier une automatisation, cherchez à la fois un statut final correct et le résultat attendu : le bon destinataire, les champs créés et l’absence d’effet indésirable.

## Lire le statut

- `pending` : l’exécution attend son traitement.
- `running` : le traitement est en cours.
- `paused` : le traitement attend une reprise, par exemple après une attente ou une demande d’approbation.
- `success` : l’exécution s’est terminée sans échec technique remonté au moteur.
- `failed` : une erreur a fait échouer l’exécution.
- `cancelled` : l’exécution a été annulée.

`success` ne garantit pas à lui seul un résultat métier. Un IF peut avoir pris une branche inattendue, et un nœud HTTP peut être configuré pour accepter les statuts d’erreur. Vérifiez les sorties et la cible réelle.

## Tester une étape

Un test isolé sert à examiner une configuration. Une exécution de chaîne vérifie aussi la préparation des données amont. Une exécution complète permet de vérifier les branches et le comportement d’ensemble.

Après un changement de mapping, relancez les étapes qui produisent les données, puis le consommateur. Vérifiez :

1. L’entrée reçue correspond au cas testé.
2. La sortie contient le champ et le type attendus.
3. Les expressions du nœud suivant lisent cette sortie réelle.
4. La destination de test contient le résultat attendu si une action externe a eu lieu.

Un test peut envoyer un message ou modifier des données si vous lancez une action réelle. Utilisez des accès et des destinations de test pour ces vérifications.

## Lire une erreur

Partez du premier nœud en échec dans l’ordre d’exécution. Relevez son message exact, puis comparez sa configuration et les données reçues. Les étapes suivantes non exécutées sont souvent une conséquence de cet échec.

Pour une intégration, vérifiez ensuite l’identifiant, les droits sur la ressource et la réponse du service. Pour une expression vide, vérifiez la structure et les noms techniques avant de changer le service appelé. Le [dépannage par symptôme](/docs/troubleshooting) aide à choisir le bon contrôle.

## Réessais et workflow de secours

Les paramètres du workflow permettent de stopper, de réessayer le workflow complet ou le nœud échoué, ou de lancer un autre workflow publié du même propriétaire. Les réessais du nœud sont épuisés avant la politique globale. Les tests de nœud et les exécutions partielles ignorent cette politique.

Choisissez le périmètre en fonction des effets déjà réalisés :

- **Nœud échoué** : évite de rejouer volontairement toute la chaîne, mais le service peut avoir effectué l’action avant qu’une réponse soit perdue.
- **Workflow complet** : rejoue aussi les étapes précédentes, y compris les écritures déjà réussies.
- **Workflow de secours** : permet de notifier ou traiter l’incident sans transformer l’exécution d’origine en succès.

Le workflow de secours reçoit l’exécution en échec dans `input.payload.execution` et les informations de l’appelant dans `input.source`. Il démarre sans attendre sa fin ; l’exécution d’origine reste en échec.

> [!WARNING] Un réessai ne remet pas les services à zéro
>
> Un paiement, un message ou une écriture déjà effectué n’est pas annulé par l’échec du workflow. Vérifiez l’état du destinataire et prévoyez une clé d’idempotence ou un contrôle de doublon avant de réessayer.

## Approbation des outils d’agent

Un outil avec `requireApproval: true` suspend le workflow. Dans l’historique, une personne autorisée examine l’action et ses arguments, puis choisit **Approuver et reprendre** ou **Refuser et reprendre**. Un refus est transmis au modèle sans exécuter l’action refusée. La reprise restaure les messages et les outils déjà terminés, y compris après redémarrage.

Chaque appel protégé demande sa propre décision. Cette pause nécessite un workflow complet, hors boucle, appel inline ou agent imbriqué. Pour répondre à une approbation, reprenez l’exécution concernée au lieu de lancer une nouvelle exécution complète.

## Déclencheurs externes

Après publication, provoquez un événement réel et retrouvez l’exécution correspondante grâce à l’heure, au type de déclencheur et à un identifiant de test présent dans les données. Vérifiez sa fin et le résultat dans le service cible.

Un test avec payload simulé valide uniquement le traitement de cet exemple. Il ne vérifie pas le réseau, l’authentification entrante, les abonnements aux événements ou l’horaire planifié. Un webhook en réponse immédiate peut aussi répondre avant la fin du workflow.

## Conservation de l’historique

Les offres prévoient des droits de conservation et de détail des exécutions. Consultez [Tarifs et licences](/docs/pricing) et votre offre active pour connaître les valeurs applicables. Pour une demande de support, relevez les informations nécessaires pendant qu’elles sont disponibles, en retirant les secrets et données personnelles.

## Pour aller plus loin

- [Fonctionnalités - nodulz](https://nodulz.com/fr/product/overview)
- [Catalogue des nœuds - nodulz](https://nodulz.com/fr/product/catalog)
- [Serveur MCP - nodulz](https://nodulz.com/fr/product/mcp)
- [Tarifs - nodulz](https://nodulz.com/fr/pricing)
- [Cas d’usage et automatisations - nodulz](https://nodulz.com/fr/use-cases)
- [Choisissez ce que vos workflows peuvent faire. - nodulz](https://nodulz.com/fr/compare)
- [Documentation - nodulz](https://nodulz.com/fr/docs)