L’architecture logicielle ne s’arrête pas au framework web. Pour mes projets, j’aime garder une infrastructure simple, lisible et reproductible. Mon socle repose principalement sur trois briques : Docker, PostgreSQL et n8n.
L’objectif n’est pas d’empiler des outils. Chaque composant possède une responsabilité précise.
1. Docker : des environnements reproductibles
Docker me permet de décrire les services nécessaires au projet plutôt que de dépendre de la configuration de chaque machine.
Un environnement peut regrouper :
services:
api:
build: ./api
postgres:
image: postgres:16
n8n:
image: n8nio/n8n
Le détail change selon le projet, mais le principe reste identique : chaque service est isolé et sa configuration peut être versionnée.
Cela réduit fortement le fameux :
« Ça fonctionne chez moi. »
2. PostgreSQL : le cœur des données
J’utilise PostgreSQL comme base relationnelle par défaut pour les applications métier.
Je profite notamment :
- des transactions ;
- des contraintes d’intégrité ;
- des index ;
- des relations ;
- des fonctionnalités JSONB lorsque certaines données sont flexibles ;
- d’un écosystème ORM mature.
Laravel peut utiliser Eloquent, Django son ORM, et une application TypeScript peut utiliser Prisma ou Drizzle. La base reste la même : un stockage central et fiable.
3. n8n : automatiser sans alourdir l’API
Toutes les opérations ne doivent pas devenir une route backend.
L’envoi d’un email, une synchronisation CRM, une notification Slack ou le traitement d’un webhook peuvent être orchestrés dans n8n.
L’API conserve alors les responsabilités critiques tandis que n8n gère les processus périphériques.
Une séparation que j’apprécie
Frontend
│
▼
Backend API ───────► PostgreSQL
│
└───────────────► n8n
│
┌────────────┼────────────┐
▼ ▼ ▼
Email Slack CRM
Le backend reste la source de vérité. n8n devient une couche d’orchestration.
Exemple : création d’une commande
Une application peut envoyer :
POST /api/orders
Le backend valide la commande et l’enregistre dans PostgreSQL.
Ensuite, il peut déclencher un webhook n8n :
{
"event": "order.created",
"orderId": 8421
}
n8n peut alors :
- récupérer les informations de la commande ;
- envoyer l’email de confirmation ;
- notifier Slack ;
- synchroniser un CRM ;
- enregistrer le résultat du workflow.
L’API n’a pas besoin de connaître les détails de chaque intégration.
Pourquoi cette architecture reste légère
Je ne transforme pas chaque fonction en microservice.
J’utilise plutôt :
- un backend principal ;
- une base PostgreSQL ;
- des workflows n8n pour l’automatisation ;
- Docker pour l’exécution.
Cette approche garde une architecture compréhensible tout en permettant d’ajouter progressivement des automatisations.
Le point important : la fiabilité
n8n ne doit pas devenir une boîte noire.
Pour les workflows importants, je prévois :
- des identifiants d’événements ;
- de l’idempotence ;
- des logs ;
- des retries contrôlés ;
- des alertes en cas d’échec ;
- une stratégie pour les exécutions partielles.
L’objectif est simple : automatiser sans perdre le contrôle du système.