Quels Docker containers pour une petite entreprise ?

Une pile de 5 Docker containers auto‑hébergés (Portainer, PostgreSQL, Airbyte, n8n, Metabase) centralise ingestion, stockage, automatisation et reporting tout en réduisant les coûts SaaS. Découvrez une pile minimale prête à déployer et les bonnes pratiques pour la sécuriser et l’intégrer.

Pourquoi installer Portainer

Portainer simplifie la gestion des containers en offrant une interface visuelle pour superviser conteneurs, volumes, réseaux et logs.

Portainer accélère les opérations quotidiennes sans sacrifier la robustesse. Il centralise la visualisation des ressources, permet des redémarrages d’applications sans SSH, et gère des stacks Docker Compose directement depuis l’interface. Voici pourquoi c’est pertinent pour une petite entreprise :

Explication rapide des bénéfices principaux avant la liste.

• Accès en lecture seule disponible pour les équipes non-opérationnelles afin de limiter les risques tout en partageant l’observabilité.
• Redémarrage et gestion des containers sans SSH, ce qui réduit la surface d’erreur et les droits d’accès nécessaires.
• Gestion des stacks (fichiers Docker Compose) pour déployer la pile complète en une opération, facilitant la reproductibilité.
• Contrôle des logs et des performances depuis une interface unique, réduisant le temps de diagnostic.

Architecture recommandée.

• Exécution en mode standalone sur l’hôte Docker pour simplicité et accès direct au socket Docker (sauf contraintes de sécurité).
• Placement derrière un reverse proxy (Traefik ou Nginx) pour gérer TLS, redirection et virtual hosts.
• Activation du TLS pour l’interface Portainer et segmentation sur un réseau de management dédié.

Étapes d’installation pratiques (exemples).

Exemple : docker run –name portainer -p 9000:9443 -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce

Exemple Compose : version: ‘3.3’\nservices:\n portainer:\n image: portainer/portainer-ce\n ports:\n – « 9000:9443″\n volumes:\n – /var/run/docker.sock:/var/run/docker.sock\n – portainer_data:/data

Configuration des comptes et rôles.

Créer un compte administrateur initial, puis des utilisateurs standard et readonly ; utiliser équipes et rôles pour limiter l’accès aux environnements (prod/staging).

Intégrer LDAP/AD ou OIDC si disponible pour centraliser l’authentification.

Bonnes pratiques de sécurité.

• Activer 2FA pour les comptes admin si possible.
• Limiter l’accès réseau à Portainer via firewall et VLANs.
• Tenir l’image Portainer à jour et limiter l’exposition du socket Docker.

Déploiement de la pile complète.

Importer le fichier Docker Compose dans Stacks → Ajouter stack, renseigner variables et registry credentials, puis Déployer. Utiliser les mises à jour « Recreate » ou « Pull latest » depuis l’UI pour orchestrer les upgrades.

Port	Volume	Rôle
9000/9443	portainer_data	Interface et configuration
—	/var/run/docker.sock	Accès Docker API

Pourquoi choisir PostgreSQL

PostgreSQL fournit une base fiable ACID pour transactions et analyses légères.

PostgreSQL convient comme base transactionnelle et comme entrepôt analytique pour une petite structure grâce à son MVCC (Multi-Version Concurrency Control) garantissant l’atomicité, la cohérence, l’isolation et la durabilité des transactions. Extensions natives (JSONB, partitionnement, index GIN/BRIN) permettent d’ingérer des données semi-structurées et d’exécuter des requêtes analytiques légères sans basculer vers un entrepôt dédié.

Pour les volumes Docker, deux approches possibles :

• Host path (chemin sur l’hôte) : Permet un accès direct aux fichiers pour les sauvegardes manuelles et la récupération, mais est lié à l’hôte (moins portable).
• Named volume (volume nommé Docker) : Plus portable et mieux géré par Docker, recommandé pour la simplicité et l’isolation; prévoir une stratégie de sauvegarde car le contenu n’est pas visible directement sur l’hôte.

Recommandations de ressources selon taille :

• Micro (1–5 utilisateurs) : 1 vCPU, 1–2 Go RAM.
• Petite (5–50 utilisateurs) : 2 vCPU, 4–8 Go RAM.
• Moyenne (50–200 utilisateurs ou analytics réguliers) : 4+ vCPU, 8–32 Go RAM; ajouter IOPS disque élevées.

Stratégies de sauvegarde simples :

• pg_dump pour dumps logiques réguliers (sauvegardes horaires/journalières selon SLA).
• Copies de volumes ou snapshot de disque pour restaurations rapides (sauvegarde cohérente avec pg_stop_backup/pg_start_backup ou pg_basebackup pour sauvegardes physiques).
• Archiver WAL pour restauration point-in-time si besoin.

Gestion des connexions et chiffrement :

• Utiliser pgbouncer comme proxy léger pour pooler les connexions et réduire la charge mémoire par connexion.
• Activer SSL/TLS pour le transport (certificat serveur). Pour le chiffrement au repos, préférer le chiffrement disque (LUKS) ou chiffrement applicatif (pgcrypto) car PostgreSQL communautaire n’a pas de TDE natif.

Exemple de service docker-compose :

version: '3.8'
services:
  postgres:
    image: postgres:15
    environment:
      - POSTGRES_PASSWORD=ChangeMeStrongly
    volumes:
      - pgdata:/var/lib/postgresql/data
    networks:
      - internal
volumes:
  pgdata:
networks:
  internal:
    internal: true

Règles de sécurité réseau : isoler le conteneur sur un réseau Docker interne, n’exposer le port 5432 qu’aux bastions/clients autorisés, et appliquer des règles de firewall pour bloquer tout accès public.

Port	Volume	Utilité
5432	pgdata	Données PostgreSQL / stockage persistant
—	WAL archive	Archivage WAL pour PITR
5432 (interne)	—	Accès applicatif via pgbouncer

À quoi sert Airbyte

Airbyte automatise l’ELT en extrayant des SaaS et sources variées puis en chargeant dans une destination centrale comme PostgreSQL.

ELT signifie Extract, Load, Transform, c’est‑à‑dire que l’on extrait les données, on les charge dans un lac ou entrepôt, puis on transforme là‑dessus. Je place Airbyte en tant que couche d’ingestion dans la pile : il gère les connecteurs source, propose des transformations basiques (normalisation, typage, filtrage) et écrit vers une destination comme PostgreSQL.

Scénarios typiques pour une PME :

• Récupérer les contacts et opportunités d’un CRM (Salesforce, HubSpot) pour alimenter un tableau de bord financier.
• Synchroniser des lignes de facturation depuis un ERP pour centraliser l’analyse des revenus.
• Collecter les événements marketing (Google Analytics, Facebook Ads) vers PostgreSQL pour croisement client.

Architecture Docker recommandée :

• Exécuter Airbyte en container avec volumes persistants pour jobs et données temporaires.
• Utiliser la base interne PostgreSQL pour démarrages rapides, ou mieux, connecter une PostgreSQL externe (haute disponibilité, sauvegarde gérée).

Étapes pratiques pour configurer un connecteur source et une destination Postgres :

• Créer la Source → Choisir le connecteur → Saisir les identifiants (API key / OAuth) → Tester la connexion.
• Créer la Destination → Choisir PostgreSQL → Fournir host, port, database, user, password et schema → Tester la connexion.
• Créer la Connexion → Mapper les flux (streams), sélectionner le mode de réplication (incremental vs full_refresh), planifier la cadence.

Gestion des identifiants/Secrets :

• Préférer Docker secrets ou un coffre (HashiCorp Vault) pour stocker mots de passe API et DB plutôt que variables d’environnement en clair.

Calendrier et surveillance :

• Planifier la synchronisation via l’UI (ou API) en minutes/heures/jours selon le besoin.
• Surveiller l’historique des jobs, activer notifications (Slack/email) et définir retries/backoff pour les échecs.

Exemple d’activation d’un connecteur :

• Ajouter Source « Salesforce » → Entrer client_id, client_secret, refresh_token → Tester.
• Ajouter Destination « PostgreSQL » → Entrer host, port, db, user, password → Tester.
• Créer Connection → Sélectionner les streams « Account, Opportunity » → Mode incremental → Cadence 1h → Lancer initial sync.

Snippet docker-compose minimal :

version: "3.8"
services:
  airbyte:
    image: airbyte/airbyte:latest
    ports:
      - "8000:8000"
    volumes:
      - ./airbyte/data:/data
      - ./airbyte/jobs:/tmp/airbyte_local
    environment:
      - AIRBYTE_ROLE=server

Connecteur	Cadence recommandée	Impact stockage
CRM (Salesforce, HubSpot)	1h–6h	Modéré (logs + incremental)
Facturation / ERP	1h–24h	Faible à modéré (dépend des lignes)
Marketing (GA, Ads)	15min–1h	Élevé (événements fréquents)

Comment automatiser les flux avec n8n

n8n orchestre des automatisations low‑code pour déclencher synchronisations, notifier des équipes et enrichir des données.

J’oriente n8n comme le cœur de la couche d’orchestration: il reçoit des triggers (webhooks, CRON, files), exécute des workflows et intègre des services (Airbyte pour les ETL, Postgres pour le stockage, Slack/Email pour les notifications).

J’illustre trois cas concrets pour une PME: lancer une sync Airbyte après réception d’un webhook de fichier CSV, enrichir chaque enregistrement (API d’enrichissement externe) puis insérer les données en Postgres, et envoyer une alerte Slack/Email en cas d’échec.

J’indique la configuration Docker recommandée: persistance du dossier /home/node/.n8n monté sur un volume pour conserver workflows et credentials; variables d’environnement pour la connexion à la DB (DB_TYPE, DB_POSTGRESDB_HOST, DB_POSTGRESDB_DATABASE, DB_POSTGRESDB_USER, DB_POSTGRESDB_PASSWORD); setting de base URL (WEBHOOK_URL) pour que les webhooks externes soient valides derrière un reverse proxy.

J’aborde la sécurité: protéger l’UI par un token (N8N_BASIC_AUTH_ACTIVE et N8N_BASIC_AUTH_USER/N8N_BASIC_AUTH_PASSWORD), stocker les credentials chiffrés via un N8N_ENCRYPTION_KEY, limiter les IPs du reverse proxy (allowlist) et utiliser HTTPS avec certificats.

J’expose une haute disponibilité légère: activer les retries dans les nodes, utiliser l’option « Execution Persistence » (pour relancer des exécutions), et prévoir un petit orchestrateur (docker-compose + restart: unless-stopped) plutôt qu’un cluster complet pour une PME.

J’explique pas à pas un workflow type: Webhook reçoit POST -> Condition vérifie la validité/format -> Appel API Airbyte via node HTTP pour lancer un job de sync -> Boucle sur résultats et enrichit les enregistrements -> Insert en masse en Postgres via node Postgres -> En cas d’erreur, envoyer message Slack et email d’alerte.

version: "3.7"
services:
  n8n:
    image: n8nio/n8n:latest
    restart: unless-stopped
    ports:
      - "5678:5678"
    volumes:
      - n8n-data:/home/node/.n8n
    environment:
      - N8N_HOST=example.com
      - WEBHOOK_URL=https://example.com/
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_PORT=5432
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=n8n
      - DB_POSTGRESDB_PASSWORD=strongpassword
      - N8N_ENCRYPTION_KEY=verystrongkey
      - N8N_BASIC_AUTH_ACTIVE=true
      - N8N_BASIC_AUTH_USER=admin
      - N8N_BASIC_AUTH_PASSWORD=secret
volumes:
  n8n-data:

Triggers courants	Exemples d’actions	Points de monitoring
Webhook, CRON, File watch	Lancer Airbyte, enrichir données, insert Postgres, notifier Slack/Email	Durée des workflows, taux d’échecs, retries, files d’attente Airbyte

Comment visualiser vos données avec Metabase

Metabase fournit des tableaux de bord BI simples et rapides à connecter à PostgreSQL.

Pourquoi choisir Metabase pour une petite entreprise ? Rapidité de mise en oeuvre et interface accessible permettent d’obtenir des insights en heures plutôt qu’en semaines. Questions SQL pour les analystes et mode « Point‑and‑Click » pour les équipes non techniques offrent une double vitesse d’adoption. Je recommande Metabase quand vous avez besoin de dashboards opérationnels sans usine à gaz BI.

Connexion sécurisée à Postgres exige un compte en lecture seule dédié. Créez un user PostgreSQL avec seulement les droits SELECT sur les schémas nécessaires. Limitez l’accès réseau au seul host Metabase via votre réseau privé ou des règles de pare‑feu. Activez la rotation de mot de passe et stockez les identifiants dans un vault (ex : HashiCorp Vault, AWS Secrets Manager).

Exemples de tableaux de bord utiles pour une PME :

• Tableau récapitulatif Ventes : Chiffre d’affaires quotidien, panier moyen, top produits.
• Tableau Churn : Taux de rétention par cohorte, churn mensuel et causes identifiées.
• Tableau Acquisition : Coût par canal, conversion funnel, LTV estimée.

Déploiement Docker simple : lancez Metabase en service Docker avec un volume pour persister l’application et configurez les vars DB pour pointer vers votre PostgreSQL readonly. Ajoutez un reverse proxy (Nginx ou Traefik) devant Metabase et terminez par TLS (Let’s Encrypt ou certificat d’entreprise).

Bonnes pratiques de gouvernance des données : organisez les dashboards en collections thématiques, appliquez des permissions fines (lecture/édition), documentez chaque question (description, owner), et archivez les anciennes vues.

Étapes rapides pour créer un dashboard simple :

• Connectez Metabase à Postgres avec le user readonly sécurisé.
• Créez une « Question » via l’interface (ou en SQL) pour les ventes du mois.
• Enregistrez la Question et créez un Dashboard.
• Ajoutez la Question au Dashboard et configurez un filtre date.
• Partagez la collection avec l’équipe concernée et définissez les permissions.

version: '3.8'
services:
  metabase:
    image: metabase/metabase:latest
    restart: unless-stopped
    environment:
      MB_DB_TYPE: postgres
      MB_DB_DBNAME: your_db
      MB_DB_PORT: 5432
      MB_DB_HOST: db.example.internal
      MB_DB_USER: metabase_ro
      MB_DB_PASS: securepassword
    volumes:
      - metabase-data:/metabase-data
    networks:
      - internal
  reverse-proxy:
    image: traefik:latest
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./traefik.yml:/traefik.yml
    networks:
      - web
      - internal
volumes:
  metabase-data:
networks:
  web:
  internal:

Service	Ports	Volumes	Rôle	Usage recommandé
metabase	3000 (interne)	metabase-data	Application BI	Dashboard, questions, stockage des métadonnées
reverse-proxy (Traefik/Nginx)	80, 443 (externe)	Certs/Config	TLS, routage	Terminaison TLS, redirection vers Metabase
postgres (existant)	5432 (interne)	DB volumes gérés	Source de données	User readonly pour Metabase, accès restreint

Prêt à centraliser vos données et réduire vos coûts avec une pile Docker self‑hosted ?

Une pile minimaliste de cinq containers — Portainer, PostgreSQL, Airbyte, n8n et Metabase — couvre ingestion, stockage, automatisation et reporting pour une petite entreprise. Ce choix open‑source réduit les coûts SaaS, donne la maîtrise des données et facilite les flux automatisés. En suivant les bonnes pratiques de volumes persistants, backups et sécurisation réseau, vous gagnez autonomie opérationnelle et agilité. Bénéfice concret : centraliser vos données pour prendre des décisions plus rapides et moins coûteuses.

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 de formation Formations Analytics. Références : Logis Hôtel, Yelloh Village, BazarChic, Fédération Française de Football, Texdecor. Dispo pour aider les entreprises => contactez moi.