# Nodes n8n à risque / vigilance

Ce fichier recense les **nodes, fonctionnalités ou patterns n8n sensibles**,
c’est-à-dire susceptibles de provoquer :

- des bugs subtils,
- des comportements inattendus,
- des problèmes lors des upgrades.

Dernière mise à jour : 2026-03-09

---

## Index

- [Vigilance générale](#risque-n8n-vigilance-generale)
- [IF Node](#risque-n8n-if-node)
- [staticData (`$getWorkflowStaticData`)](#risque-n8n-staticdata)

---

<a id="risque-n8n-vigilance-generale"></a>
## Vigilance générale

- Différences de comportement entre n8n **cloud et self-hosted** (certains nodes, credentials, timeouts)
- **Expressions mal évaluées** : `{{ $json.field }}` peut retourner `undefined` silencieusement
- **Comportements implicites** des nodes : toujours tester les cas limites (null, tableau vide, erreur HTTP)

## Règles d’utilisation

- On documente uniquement des cas vus en vrai (ou très probables + signalés).
- Chaque entrée doit dire :
  - ce qui peut mal se passer,
  - comment on le voit (symptômes),
  - comment on le maîtrise (mitigation).
- Si c’est lié à une version : on note la version.

---

<a id="risque-n8n-if-node"></a>
## IF Node

### Risques

- Comparaisons ambiguës entre `null`, `undefined`, `""` et `false`
- Résultats surprenants si les types ne sont pas normalisés

### Symptômes

- Branche IF “inversée” par rapport à l’intuition
- Cas limites qui passent en prod mais pas en test

### Bonnes pratiques / mitigations

- Normaliser les données avant comparaison (string/number/bool)
- Tester explicitement `null` / `undefined`
- Logguer la valeur et le type en amont si doute

### Contexte technique

- Observé : (à compléter quand tu as un cas précis)
- n8n : (version à préciser)

---

<a id="risque-n8n-staticdata"></a>
## staticData (`$getWorkflowStaticData`)

### Risques

- Persistance entre exécutions (effet mémoire non voulu)
- Dépendance forte à l’`executionId` si on fait de l’agrégation
- Sensible aux upgrades n8n (comportements qui peuvent changer)

### Symptômes

- Données “fantômes” réutilisées
- Résultats incohérents entre exécutions
- Branches parallèles qui s’écrasent

### Bonnes pratiques / mitigations

- Toujours lier les données à `executionId`
- Nettoyer/reset explicitement à chaque run
- Documenter le pattern dès qu’il est utilisé
- Préférer un stockage externe si l’état devient critique (DB/Redis/etc.)

### Contexte technique

- Validé : oui (usage avancé)
- n8n : 1.121.2 / self-hosted / docker