# Dépannage et FAQ | Docs - nodulz

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

Language: fr

Partez d’une exécution précise. Relevez son statut, le premier nœud en échec, son message et les données qu’il a reçues. Un problème de livraison du déclencheur et un problème de traitement n’ont pas le même point de départ.

## Aucune exécution n’apparaît

1. Vérifiez que le workflow est publié et que vous avez republié les changements du déclencheur.
2. Pour un webhook, reprenez l’URL affichée par le nœud, la méthode HTTP et l’authentification configurées. Vérifiez la réponse reçue par l’appelant.
3. Pour un événement fournisseur, vérifiez que le bon événement est activé et que le service peut joindre l’instance. Consultez son historique de livraison s’il en propose un.
4. Pour une planification, vérifiez le mode, les jours et le fuseau horaire dans la [fiche du nœud](/docs/nodes/schedule).

Un payload simulé dans l’éditeur ne teste pas ces conditions de livraison. Si le workflow fonctionne avec ce payload, concentrez la recherche sur le déclencheur et la connexion externe.

## Le webhook répond mais une étape a échoué

Le mode de réponse immédiate renvoie une réponse avant la fin du traitement. Retrouvez l’exécution dans l’historique et vérifiez son statut final. Si l’appelant a besoin du résultat métier, configurez un mode de réponse qui attend ce résultat ; consultez [Webhook](/docs/nodes/webhook) et [Réponse webhook](/docs/nodes/webhook_response).

## Une expression est vide ou null

Vérifiez successivement :

1. **La forme de l’entrée** : `input.email` pour un payload manuel simple, souvent `input.body.email` pour un webhook JSON.
2. **Le nom technique** : utilisez celui proposé par le mapping, par exemple `nodes.http1`, pas un nom de service deviné.
3. **La sortie réelle** : avec **Corps uniquement**, `nodes.http1.body.id` peut devenir `nodes.http1.id`.
4. **La branche exécutée** : un nœud dans une branche non parcourue ne fournit pas de sortie.
5. **Le périmètre du test** : un test isolé ne prouve pas que les étapes amont ont été exécutées avec les mêmes données. Relancez la chaîne concernée.

Consultez les diagnostics d’expression dans les logs et le [guide des données](/docs/expressions). Un défaut facultatif avec `??` peut être utile ; il ne remplace pas la validation d’un champ obligatoire.

## Le nœud reçoit du texte au lieu d’un objet ou d’un nombre

Dans Modifier les champs, `120` est du texte et `{{ 120 }}` est un nombre. Une expression seule peut conserver un objet ou une liste ; une valeur mêlant texte et expression devient une chaîne.

Les variables créées par ce nœud sont textuelles. Pour conserver le type, utilisez sa sortie `nodes.set1.<champ>`. Si la source contient réellement une chaîne JSON, utilisez [Parse JSON](/docs/nodes/parse_json) et sa propriété `parsed`.

## Une condition prend la mauvaise branche

Ouvrez la sortie du [IF](/docs/nodes/if) : `conditions` montre la valeur lue, l’opérateur, la valeur comparée et le résultat de chaque condition. `result` montre leur combinaison finale.

Vérifiez le chemin du champ, les majuscules et espaces pour une égalité de texte, et le choix **AND** ou **OR**. Les comparaisons `gt`, `gte`, `lt` et `lte` sont numériques ; une valeur vide n’est pas une preuve de validité numérique. Vérifiez aussi que les connexions partent de la bonne sortie **vrai** ou **faux**.

## La boucle ne traite qu’un lot ou utilise le mauvais élément

Vérifiez que la source pointe sur la liste voulue et que l’action répétée part de la sortie **Boucle**, pas de **Terminé**. Avec `batchSize: 1`, le nœud expose l’élément dans `item`. Avec des lots plus grands, `item` peut être une liste.

`input` reste l’entrée initiale : utilisez la sortie de la [boucle](/docs/nodes/loop_over_items) pour lire l’élément courant. Testez avec deux éléments distincts afin de repérer une action qui réutilise toujours le premier.

## L’identifiant n’est pas proposé ou l’accès est refusé

Vérifiez le type exact attendu par le nœud et le partage de l’identifiant avec le propriétaire du workflow. Des accès SMTP et IMAP, ou PostgreSQL et pgvector, ne sont pas interchangeables.

Si l’identifiant est sélectionné mais que l’opération échoue, relevez la réponse du service. Un problème d’authentification et un droit insuffisant nécessitent des corrections différentes. Le [guide des identifiants](/docs/credentials) donne l’ordre de vérification.

## Une requête HTTP renvoie une erreur

- **401 ou 403** : vérifiez le mode d’authentification, l’accès sélectionné et les permissions sur la ressource.
- **404** : vérifiez l’URL construite, l’identifiant de ressource et l’environnement appelé.
- **429** : vérifiez les limites du fournisseur et réduisez la cadence ; une relance immédiate en boucle peut aggraver le problème.
- **5xx ou délai dépassé** : vérifiez la disponibilité du service et les effets déjà produits avant de réessayer une écriture.

Le nœud [HTTP](/docs/nodes/http) échoue par défaut sur une réponse hors 2xx. Pour traiter volontairement un statut dans un IF, désactivez **Échouer sur les erreurs HTTP**, gardez **Inclure le statut** et désactivez **Corps uniquement**. Prévoyez une branche d’échec explicite : le succès technique du nœud ne signifie alors plus le succès de la requête.

## Une action a été exécutée deux fois

Comparez les identifiants d’exécution et d’événement. Déterminez si le fournisseur a livré deux événements, si vous avez relancé manuellement, ou si une politique de réessai a rejoué une étape déjà effectuée.

Avant une nouvelle relance, vérifiez l’état chez le destinataire. Utilisez une clé d’idempotence quand l’API la prévoit, ou une vérification du traitement déjà effectué à partir d’un identifiant métier stable. Le [guide des exécutions](/docs/executions) explique les différents périmètres de réessai.

## L’exécution reste en pause

Une pause peut correspondre à une attente prévue ou à une approbation d’outil d’agent. Ouvrez l’exécution pour voir la demande. Pour une approbation, vérifiez l’action et ses arguments, puis utilisez **Approuver et reprendre** ou **Refuser et reprendre** avec un compte autorisé.

Ne relancez pas tout le workflow pour répondre à une approbation : vous pourriez répéter les étapes précédentes. Consultez [Approbation des outils d’agent](/docs/executions#agent-tool-approval).

## L’agent échoue ou répond sans les données attendues

Vérifiez le modèle et l’identifiant sélectionnés, les ports des composants et les noms des outils. Un outil mentionné dans le prompt doit aussi être relié et configuré. Consultez la trace pour savoir s’il a réellement été appelé.

En cas de limite de tours ou de tokens, réduisez d’abord la tâche et le contexte, puis ajustez la limite concernée. `maxTokens` borne la sortie d’un appel ; `maxTotalTokens` borne l’usage cumulé de cet agent. Un budget total nécessite que le fournisseur retourne les informations d’usage.

Pour une recherche documentaire, inspectez les passages retrouvés et vérifiez que question et documents utilisent le même modèle d’embeddings et la même dimension. Le [guide des workflows](/docs/workflows#agents-and-document-retrieval) distingue indexation et question.

## Préparer une demande de support

Rassemblez le nom et la version de l’instance, l’heure de l’incident avec son fuseau, l’identifiant de l’exécution, le type du nœud, le message exact et les étapes de reproduction. Précisez le résultat attendu, le résultat obtenu et si l’incident concerne un test ou un événement réel.

Joignez un exemple minimal anonymisé. Retirez clés API, tokens, cookies, en-têtes d’authentification et données personnelles des payloads, captures et logs.

## 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)