# Décisions techniques & architecture

Ce fichier documente les choix importants (format type ADR mais léger).

Objectifs :

- garder une trace du raisonnement
- éviter de reposer les mêmes questions
- assumer les compromis

Dernière mise à jour : 2025-12-19

---

## Format standard d’une décision

## <Titre>

- Date : YYYY-MM-DD
- Statut : Proposed | Accepted | Deprecated
- Périmètre : n8n | backend | infra | global

### Contexte

### Options envisagées

### Décision

### Justification

### Conséquences

---

## Workflows n8n complexes = mini-systèmes

- Date : 2025-12-19
- Statut : Accepted
- Périmètre : n8n

### Contexte

Certains workflows n8n dépassent le simple enchaînement de nodes et deviennent
de véritables systèmes applicatifs (orchestration, état, branches, retries, intégrations multiples).

### Options envisagées

- Traiter ces workflows comme de simples automatisations “low-code”
- Les considérer comme du code à part entière (discipline, patterns, doc, prudence sur upgrades)

### Décision

Les considérer comme du code.

### Justification

- Complexité réelle (logique, état, orchestration)
- Sensibilité aux versions n8n (upgrade-risk)
- Besoin de maintenabilité et de capitalisation

### Conséquences

- Prudence accrue lors des upgrades
- Documentation minimale mais ciblée
- Patterns explicitement identifiés et partagés
- On accepte d’utiliser du Code (JS) quand nécessaire