refactor: renommer 10_n8n_nodes_a_risques → 10_n8n_risques_et_vigilance

Alignement sur la convention de nommage uniforme des fichiers de risques.
Mise à jour de toutes les références (index, instructions, templates, zone tampon).

10_n8n_risques_et_vigilance.md

@@ -0,0 +1,80 @@
+# 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 : 2025-12-19
+
+---
+
+## 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.
+
+---
+
+## 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)
+
+---
+
+## 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