Une stack Portainer, PostgreSQL, Airbyte, Metabase et n8n en conteneurs Docker centralise ingestion, stockage, reporting et automatisation à coût maîtrisé (réf. : documentations officielles Docker, PostgreSQL et Airbyte). Suivez la suite pour déployer une « business‑in‑a‑box » réplicable et économique.
Pourquoi déployer Portainer ?
Portainer simplifie l’administration et la supervision des conteneurs via une UI légère et des contrôles d’accès, il doit être le premier outil d’une pile self‑hosted.
Je recommande Portainer parce qu’il rassemble l’essentiel : visibilité, gestion et délégation sans nécessiter une équipe d’infra dédiée.
- Fonctions clés : Interface graphique pour voir et contrôler conteneurs, images et nœuds.
- Health et logs : Visualisation des logs et états de santé (health checks) pour diagnostiquer rapidement.
- Volumes et réseaux : Gestion des volumes persistants et des réseaux Docker pour faciliter les sauvegardes et l’isolation.
- Templates et stacks : Modèles d’apps et gestion des stacks Docker Compose pour déployer des applications reproductibles.
- Orchestration : Support de Docker Swarm, d’un agent Kubernetes léger et d’Azure Container Instances (ACI) pour monter en capacité.
Je préconise l’installation dès le départ afin que vous puissiez déléguer des tâches simples (redémarrer un service, visualiser un log, restaurer un volume) à des non‑techs en limitant les droits.
- Sécurité : Activer l’authentification unique ou local, forcer HTTPS via un reverse proxy (Traefik/Nginx), créer des comptes restreints et sauvegarder les stacks régulièrement.
- Bonnes pratiques : Ne pas exposer l’API Docker directement, limiter l’accès au socket /var/run/docker.sock, utiliser des comptes avec le principe du moindre privilège.
Déploiement minimal en Docker :
docker volume create portainer_data
docker run -d -p 9000:9000 -p 9443:9443 --name portainer --restart=always \
-v /var/run/docker.sock:/var/run/docker.sock \
-v portainer_data:/data \
portainer/portainer-ce:latest
Exemple Docker Compose minimal :
version: "3.8"
services:
portainer:
image: portainer/portainer-ce:latest
ports:
- "9000:9000"
- "9443:9443"
volumes:
- /var/run/docker.sock:/var/run/docker.sock
- portainer_data:/data
restart: unless-stopped
volumes:
portainer_data:
- Exploitation : Sauvegarder régulièrement le volume portainer_data (dump ou copie), surveiller l’état du conteneur et exporter les stacks en YAML.
| Fonction | Commande exemple | Remarque |
| Créer volume | docker volume create portainer_data | Volume pour configs et stacks |
| Lancer Portainer | docker run … portainer/portainer-ce:latest | Ports par défaut 9000 (HTTP) / 9443 (HTTPS) |
| Compose | docker-compose up -d | Pratique pour versionner la config |
Sources : documentation officielle Portainer https://docs.portainer.io/ et documentation Docker https://docs.docker.com/.
Pourquoi choisir PostgreSQL ?
PostgreSQL offre une base relationnelle fiable, ACID et extensible qui sert de source de vérité pour transactionnel et analytique léger.
PostgreSQL assure l’ACID (Atomicité, Cohérence, Isolation, Durabilité), ce qui garantit l’intégrité des transactions critiques pour votre application.
- Raisons techniques : Indexation avancée (B-tree, GiST, GIN), types JSONB pour stocker et interroger des données semi-structurées, et extensions puissantes comme PostGIS (géospatial) ou pg_cron (planification).
- Définition utile : JSONB est un format binaire JSON optimisé pour les requêtes; GIN est un index adapté aux recherches sur JSONB et texte.
- Extensibilité : Possibilité d’ajouter fonctions, types et moteurs de stockage, ce qui évite des bricolages applicatifs coûteux.
Quand PostgreSQL suffit pour analytics : Pour des analyses ad hoc, agrégations et rapports sur des volumes modérés (dizaines à quelques centaines de millions de lignes), PostgreSQL est souvent suffisant.
Quand prévoir un entrepôt dédié : Si vous avez des requêtes analytiques massives, des besoins d’indexation colonne optimisée ou des pipelines ELT à grande échelle, un entrepôt (Snowflake, BigQuery, Redshift) devient pertinent.
- Volumes et backups : Utiliser pg_dump pour sauvegarde logique (idéal pour migrations et petits jeux de données), pg_basebackup pour sauvegarde physique complète, et snapshots de volumes pour restaurations rapides au niveau bloc.
- Restauration : pg_restore reconstitue schémas et données depuis pg_dump; la restauration physique via basebackup est plus rapide mais moins flexible.
version: "3.8"
services:
db:
image: postgres:15
container_name: postgres_app
environment:
- POSTGRES_USER=appuser
- POSTGRES_PASSWORD=StrongPassw0rd
- POSTGRES_DB=appdb
volumes:
- pgdata:/var/lib/postgresql/data
ports:
- "5432:5432"
volumes:
pgdata:
name: pgdata_app
- Conseils de persistance : Toujours utiliser volume nommé ou mount réseau, éviter le storage ephemeral du container, surveiller I/O.
- Sécurité et permissions : Créer utilisateurs avec privilèges minimaux, activer TLS si exposition réseau, appliquer firewall et limiter accès au port 5432.
- Recommandations PME : Pour une application web classique prévoir 4–16 GB RAM pour PostgreSQL, 2–4 vCPU, disque 50–200 GB selon données; pour analytics léger monter à 32–64 GB RAM et SSD performant.
| Sauvegarde rapide | pg_dump (logique) ou snapshot de volume | Avantage : flexibilité et granularité |
| Restauration complète | pg_basebackup ou restauration snapshot | Avantage : rapidité et consistance à l’octet |
Documentation PostgreSQL : https://www.postgresql.org/docs/
Bonnes pratiques sauvegarde : https://www.postgresql.org/docs/current/backup.html
Comment centraliser les sources avec Airbyte ?
Airbyte permet d’extraire et de charger automatiquement des données de multiples SaaS vers PostgreSQL via connecteurs maintenus, réduisant le coût de développement de pipelines.
J’utilise Airbyte comme bus de données simple: il gère les connecteurs sources, les destinations, un scheduler et des transformations basiques (ELT = Extract, Load, Transform).
- Rôle d’Airbyte : Connecteurs sources pour extraire (API, fichiers, bases), destinations pour charger (Postgres, data warehouses), scheduler pour exécuter des jobs et transformations légères (normalisation, mapping).
- Connecteurs utiles pour une PME : CRM (Salesforce, HubSpot), Facturation (Stripe, QuickBooks), Publicité (Google Ads, Facebook Ads), Tableurs (Google Sheets). Ces connecteurs réduisent la dette d’ingénierie.
- Fonctionnement ELT courant : Extraction incrémentale (seulement les nouvelles lignes), Chargement brut dans Postgres pour historisation, Normalisation ensuite via SQL/DBT pour éviter les pertes d’historique.
- Déploiement Docker : Déployer via Docker Compose en reliant Airbyte à PostgreSQL, exposer volumes pour config et données, définir variables d’environnement pour la connexion DB et les secrets.
- Gestion des secrets et quotas API : Stocker mots de passe et tokens hors du repo (Vault, AWS Secrets Manager, ou variables d’environnement sécurisées). Configurer backoff et limites côté connecteur pour respecter les quotas API des SaaS.
- Scalabilité et limites : Airbyte scale horizontalement en multipliant les workers; la charge CPU/RAM dépend des connecteurs et du volume. Prévoir de tester la parallélisation des jobs et limiter les threads si l’API source impose des quotas.
- Sauvegarde et restauration : Sauvegarder la base Postgres et les volumes Airbyte (config/données). Utiliser l’export/import de configuration fourni par Airbyte pour restaurer les jobs et connecteurs.
version: '3.8'
services:
postgres:
image: postgres:13
environment:
- POSTGRES_USER=airbyte
- POSTGRES_PASSWORD=changeme
- POSTGRES_DB=airbyte
volumes:
- postgres_data:/var/lib/postgresql/data
airbyte-server:
image: airbyte/server:latest
environment:
- DATABASE_URL=postgresql://airbyte:changeme@postgres:5432/airbyte
depends_on:
- postgres
volumes:
- airbyte_config:/data
airbyte-worker:
image: airbyte/worker:latest
depends_on:
- airbyte-server
volumes:
postgres_data:
airbyte_config:
| Vérifier sauvegarde régulière de Postgres |
| Tester incrémental et full refresh sur chaque connecteur |
| Valider stockage sécurisé des secrets (Vault/Secrets Manager) |
| Contrôler quotas API et backoff configurés |
| Surveiller consommation CPU/RAM et augmenter workers si besoin |
Documentation officielle: https://docs.airbyte.com
Comment obtenir des tableaux de bord simples avec Metabase ?
Metabase fournit une BI simple et rapide pour créer questions, graphiques et dashboards connectés à PostgreSQL sans coder.
Cas d’usage pour PME : Suivre KPIs financiers et opérationnels en temps réel, automatiser rapports hebdomadaires envoyés par e‑mail et permettre l’exploration ad‑hoc par les équipes produit et ventes.
- KPIs : Visualiser marge, churn, ARPA et pipeline commercial avec quelques cartes et segments simples.
- Rapports hebdo : Export CSV/PDF programmés via tâches externes ou via API pour diffusion automatique.
- Exploration ad‑hoc : Donner aux analystes des « questions » sauvegardées et des collections organisées.
Connexion à PostgreSQL : Je recommande d’utiliser PostgreSQL comme base de données d’application pour Metabase afin d’assurer transactions, verrouillage et migrations fiables et reproductibles.
Déploiement Docker : Utiliser Docker Compose pour lier Metabase à PostgreSQL. Metabase expose par défaut le port 3000. Fournir les variables d’environnement MB_DB_TYPE, MB_DB_HOST, MB_DB_PORT, MB_DB_DBNAME, MB_DB_USER, MB_DB_PASS vers la DB Metabase.
version: '3.7'
services:
db:
image: postgres:13
environment:
POSTGRES_DB: metabase
POSTGRES_USER: metabase
POSTGRES_PASSWORD: metabase_pass
volumes:
- metabase_db_data:/var/lib/postgresql/data
metabase:
image: metabase/metabase:latest
ports:
- "3000:3000"
environment:
MB_DB_TYPE: postgres
MB_DB_HOST: db
MB_DB_PORT: 5432
MB_DB_DBNAME: metabase
MB_DB_USER: metabase
MB_DB_PASS: metabase_pass
depends_on:
- db
volumes:
metabase_db_data:
Sécurité : Activer SSO si vous avez un fournisseur d’identité (SAML/OAuth). Placer Metabase derrière un reverse proxy (Nginx ou Traefik) pour gérer HTTPS et HSTS. Gérer les permissions via les collections et rôles pour limiter l’accès aux datasets sensibles.
Bonnes pratiques dashboards : Échantillonner les gros jeux de données pour les visualisations temps réel lourdes, définir un intervalle de refresh raisonnable (ex. 1–15 minutes selon besoin), et configurer des alertes basiques par segment ou seuil via les « pulses » ou via intégration externe.
Maintenance : Versionner les migrations, effectuer des sauvegardes régulières de la base Metabase (pg_dump), tester les restaurations et appliquer les mises à jour hors heures de pointe.
| Variable / Port | Description / Valeur |
| MB_DB_TYPE | Type de DB (postgres) |
| MB_DB_HOST | Hôte DB (ex. db) |
| MB_DB_PORT | Port DB (5432) |
| MB_DB_DBNAME | Nom de la DB Metabase (metabase) |
| MB_DB_USER | Utilisateur DB |
| MB_DB_PASS | Mot de passe DB |
| Port Metabase | 3000 (exposé et reverse‑proxy possible) |
Comment automatiser workflows avec n8n ?
N8n orchestre automatisations et intégrations entre vos outils (email, CRM, facturation, Google Sheets) via workflows visuels et exécutions programmées.
J’utilise n8n pour sa simplicité : construction visuelle no/low‑code et catalogue riche de nodes facilitent l’intégration rapide sans équipes d’ingénierie lourdes.
- Pourquoi adapté aux PME : J’obtiens des automatisations rapides avec peu de code, coûts réduits et maintenance simplifiée.
- Architecture recommandée : J’associe n8n à PostgreSQL pour persistance des workflows, des exécutions et des credentials, ce qui évite la perte d’état et facilite la scalabilité.
- Déploiement Docker Compose : J’utilise un service n8n connecté à un Postgres central, avec variables d’environnement essentielles pour l’auth et les webhooks.
- Sécurité : J’active l’authentification basique, j’expose n8n derrière HTTPS via reverse proxy (Traefik/Nginx) et je stocke les credentials chiffrés en base.
- Cas concrets : J’automatise la création de lead depuis un formulaire web vers le CRM, j’envoie une notification Slack et j’insère l’enregistrement dans Postgres.
- Surveillance et reprise : J’active les logs, les retries intégrés des nodes, et j’ajoute une surveillance externe (Prometheus + Alertmanager) pour relancer ou alerter sur les échecs.
# Exemple Docker Compose minimal pour n8n + Postgres
version: "3.7"
services:
postgres:
image: postgres:14
environment:
POSTGRES_USER: n8n
POSTGRES_PASSWORD: n8npass
POSTGRES_DB: n8n
volumes:
- pgdata:/var/lib/postgresql/data
n8n:
image: n8nio/n8n:latest
ports:
- "5678:5678"
environment:
DB_TYPE: postgres
DB_POSTGRESDB_HOST: postgres
DB_POSTGRESDB_PORT: 5432
DB_POSTGRESDB_DATABASE: n8n
DB_POSTGRESDB_USER: n8n
DB_POSTGRESDB_PASSWORD: n8npass
N8N_BASIC_AUTH_ACTIVE: "true"
N8N_BASIC_AUTH_USER: "admin"
N8N_BASIC_AUTH_PASSWORD: "securepassword"
WEBHOOK_TUNNEL_URL: "https://hooks.example.com"
depends_on:
- postgres
volumes:
pgdata:
| Variable | Rôle / Recommandation |
| N8N_BASIC_AUTH_ACTIVE | Activer l’authentification basique en production (true). |
| N8N_BASIC_AUTH_USER / PASSWORD | Utiliser des identifiants forts et les stocker dans un secret manager. |
| WEBHOOK_TUNNEL_URL | Fixer si vous exposez les webhooks via un tunnel ou proxy externe. |
| DB_* | Configurer PostgreSQL central pour persistance et sauvegardes régulières. |
| Recommandation Webhook | Limiter l’exposition des webhooks, valider les signatures et utiliser HTTPS public via reverse proxy. |
Prêt à assembler cette stack Docker pour votre business ?
La combinaison Portainer, PostgreSQL, Airbyte, Metabase et n8n en conteneurs Docker couvre ingestion, stockage, reporting et automatisation sans frais SaaS récurrents élevés. En suivant des bonnes pratiques de volumes, backups et sécurité vous obtenez une solution réplicable, économique et maintenable. Bénéfice concret : moins de silos, décisions plus rapides et contrôle des coûts pour votre entreprise.
FAQ
A propos de l’auteur
Franck Scandolera — expert & formateur en Tracking avancé server‑side, Analytics Engineering, Automatisation No/Low Code (n8n) et intégration de l’IA en entreprise. Responsable de l’agence webAnalyste et de l’organisme Formations Analytics. Références : Logis Hôtel, Yelloh Village, BazarChic, Fédération Française de Football, Texdecor. Disponible pour aider les entreprises : contactez‑moi.
⭐ Analytics engineer, Data Analyst et Automatisation IA indépendant ⭐
- Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…
Mon terrain de jeu :
- Data Analyst & Analytics engineering : tracking avancé (GTM server, e-commerce, CAPI, RGPD), entrepôt de données (BigQuery, Snowflake, PostgreSQL, ClickHouse), modèles (Airflow, dbt, Dataform), dashboards décisionnels (Looker, Power BI, Metabase, SQL, Python).
- Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
- Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.






