# n8n — Risques & vigilance : Général

> Extrait de la base de connaissance Lead_tech. Voir `knowledge/n8n/risques/README.md` pour l'index complet.

---

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

---

<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