Déployer Dolibarr : DevOps Guide pratique en 2026

Introduction : Pourquoi une approche DevOps pour Dolibarr en 2026 ?

Dolibarr, l’ERP/CRM open source populaire, a traditionnellement été déployé via des méthodes manuelles ou des scripts basiques. En 2026, face à la montée en charge des businesses numériques, aux exigences de sécurité accrues et à la nécessité d’une disponibilité continue, une approche DevOps n’est plus une option, mais une nécessité.

Ce guide pratique vous explique comment industrialiser le déploiement, la gestion et la maintenance de Dolibarr en utilisant les outils et standards de 2026 : conteneurisation, orchestration, Infrastructure as Code (IaC), CI/CD avancé et observabilité.

📋 Prérequis & Philosophie

  • Philosophie : Tout est code (infrastructure, configuration, pipeline). Reproductibilité, immuabilité, automonitoring.

  • Stack technique cible (2026) :

    • Orchestration : Kubernetes (version stable >1.30) ou Docker Swarm pour des déploiements plus simples.

    • IaC : Terraform (pour le cloud) ou Crossplane ( Kubernetes-native).

    • CI/CD : GitLab CI/CD, GitHub Actions ou Jenkins X (avec review apps).

    • Conteneurs : Docker (avec BuildKit/containerd).

    • Stockage : Base de données managée (CloudSQL, RDS) ou PostgreSQL HA (Patroni) + stockage objet (S3/minIO) pour les documents.

    • Observabilité : Prometheus/Grafana (métriques), Loki (logs), Jaeger (traces).

    • Gestion de secrets : Vault externe ou secrets store natif de Kubernetes (avec rotation automatique).

🚀 Étape 1 : Conteneurisation Moderne de Dolibarr

La clé est de créer une image Docker légère, sécurisée et paramétrable.

Dockerfile optimisé (exemple) :

# Utiliser une image PHP-FPM alpine verified et à jour (ex: php:8.3-fpm-alpine3.19)

FROM ghcr.io/php/php:8.3-fpm-alpine AS base
# Installer les extensions PHP critiques pour Dolibarr (gd, intl, pdo_pgsql, opcache...)

RUN apk add --no-cache \

    libpng-dev \

    libjpeg-turbo-dev \

    freetype-dev \

    oniguruma-dev \

    libxml2-dev \

    postgresql-dev \

    && docker-php-ext-configure gd --with-freetype --with-jpeg \

    && docker-php-ext-install -j$(nproc) gd intl pdo_pgsql opcache
# Copier uniquement les fichiers de dépendances composer pour profiter du cache

COPY composer.json composer.lock /var/www/html/

RUN curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer \

    && composer install --no-dev --optimize-autoloader
# Copier le code source Dolibarr (préalablement cloné et vérifié)

COPY . /var/www/html
# Configuration PHP-FPM production

COPY docker/php-fpm.conf /usr/local/etc/php-fpm.d/zz-dolibarr.conf

RUN { \

        echo 'opcache.enable=1'; \

        echo 'opcache.memory_consumption=256'; \

        echo 'opcache.max_accelerated_files=10000'; \

        echo 'opcache.validate_timestamps=0'; \

    } > /usr/local/etc/php/conf.d/opcache-recommended.ini
# Utiliser un utilisateur non-root

RUN addgroup -g 1001 -Swww && adduser -u 1001 -Swww -Gwww

USER www
EXPOSE 9000

CMD ["php-fpm"]

Bonnes pratiques 2026 :

  • Multi-stage builds pour séparer build et runtime.

  • Scan de vulnérabilités (Trivy, Grype) dans le pipeline CI.

  • Signature d’images avec Cosign et adoption de sigstore.

  • Les secrets (clés API, mots de passe DB) ne sont jamais dans l’image. Injection via des variables d’environnement ou des volumes de secrets Kubernetes.

⚙️ Étape 2 : Définition de l’Infrastructure (IaC)

Option A : Kubernetes (Production scalable)

Fichier deployment.yaml simplifié :

apiVersion: apps/v1

kind: Deployment

metadata:

  name: dolibarr-app

spec:

  replicas: 3

  selector:

    matchLabels:

      app: dolibarr

  template:

    metadata:

      labels:

        app: dolibarr

    spec:

      containers:

      - name: dolibarr

        image: your-registry/dolibarr:prod-2026.1.0 # Image scannée et signée

        ports:

        - containerPort: 9000

        envFrom:

        - secretRef:

            name: dolibarr-secrets # Contient DB_HOST, DB_USER, etc.

        - configMapRef:

            name: dolibarr-config # Contient DOLIBARR_INSTALL_MODE, etc.

        readinessProbe:

          httpGet:

            path: /index.php

            port: 9000

          initialDelaySeconds: 30

          periodSeconds: 10

        resources:

          requests:

            memory: "512Mi"

            cpu: "250m"

          limits:

            memory: "1Gi"

            cpu: "500m"

        volumeMounts:

        - name: documents-storage

          mountPath: /var/www/html/documents

      volumes:

      - name: documents-storage

        persistentVolumeClaim:

          claimName: dolibarr-docs-pvc

---

apiVersion: v1

kind: Service

metadata:

  name: dolibarr-service

spec:

  selector:

    app: dolibarr

  ports:

  - port: 80

    targetPort: 9000

  type: ClusterIP

Option B : Docker Compose (Petits projets/recette)

docker-compose.yml avec secrets et configs :

version: '3.8'

services:

  db:

    image: postgres:16-alpine

    environment:

      POSTGRES_DB: dolibarr

      POSTGRES_USER: ${DB_USER}

      POSTGRES_PASSWORD_FILE: /run/secrets/db_password

    secrets:

      - db_password

    volumes:

      - postgres_data:/var/lib/postgresql/data

    healthcheck:

      test: ["CMD-SHELL", "pg_isready -U ${DB_USER}"]

      interval: 10s
app:

    build: .

    depends_on:

      db:

        condition: service_healthy

    ports:

      - "8080:80" # Interface web via Nginx/PHP-FPM

    environment:

      DOLIBARR_DB_HOST: db

      DOLIBARR_DB_NAME: dolibarr

      DOLIBARR_DB_USER: ${DB_USER}

      DOLIBARR_DB_PASS_FILE: /run/secrets/db_password

    secrets:

      - db_password

    volumes:

      - ./documents:/var/www/html/documents # Persistance locale

volumes:

  postgres_data:

secrets:

  db_password:

    file: ./secrets/db_password.txt # À ne pas commiter !

🔄 Étape 3 : Pipeline CI/CD GitOps (Exemple GitHub Actions)

.github/workflows/deploy-prod-k8s.yml :

name: Deploy Dolibarr to Production
on:

  push:

    branches: [ main ]

    paths:

      - 'Dockerfile'

      - 'src/**'

      - '.github/workflows/deploy-prod-k8s.yml'

  # Déclenchement manuel possible

  workflow_dispatch:
jobs:

  build-and-scan:

    runs-on: ubuntu-latest

    outputs:

      image-tag: ${{ steps.meta.outputs.tags }}

    steps:

    - name: Checkout code

      uses: actions/checkout@v4
- name: Set up QEMU

      uses: docker/setup-qemu-action@v3
- name: Set up Docker Buildx

      uses: docker/setup-buildx-action@v3
- name: Login to DockerHub

      uses: docker/login-action@v3

      with:

        username: ${{ secrets.DOCKERHUB_USERNAME }}

        password: ${{ secrets.DOCKERHUB_TOKEN }}
- name: Extract metadata (tags, labels)

      id: meta

      uses: docker/metadata-action@v5

      with:

        images: your-registry/dolibarr

        tags: |

          type=raw,value=prod-${{ github.sha }}

          type=raw,value=latest
- name: Build and push

      uses: docker/build-push-action@v5

      with:

        context: .

        platforms: linux/amd64,linux/arm64

        push: true

        tags: ${{ steps.meta.outputs.tags }}

        cache-from: type=registry,ref=your-registry/dolibarr:buildcache

        cache-to: type=registry,ref=your-registry/dolibarr:buildcache,mode=max
- name: Scan image for vulnerabilities

      uses: aquasecurity/trivy-action@master

      with:

        image-ref: ${{ steps.meta.outputs.tags }}

        format: 'sarif'

        output: 'trivy-results.sarif'
- name: Upload Trivy scan results to GitHub Security tab

      uses: github/codeql-action/upload-sarif@v3

      with:

        sarif_file: 'trivy-results.sarif'
deploy:

    needs: build-and-scan

    runs-on: ubuntu-latest

    steps:

    - name: Checkout k8s manifests repo

      uses: actions/checkout@v4

      with:

        repository: your-org/dolibarr-k8s-manifests

        token: ${{ secrets.PAT_K8S_MANIFESTS }}
- name: Update image tag in manifest

      run: |

        sed -i "s|image: your-registry/dolibarr:.*|image: ${{ needs.build-and-scan.outputs.image-tag }}|g" deployment/prod/dolibarr-deployment.yaml
- name: Commit and push changes

      run: |

        git config --global user.email "ci-bot@your-org.com"

        git config --global user.name "CI Bot"

        git add deployment/prod/dolibarr-deployment.yaml

        git commit -m "Update Dolibarr image to ${{ needs.build-and-scan.outputs.image-tag }} [skip ci]"

        git push

🛡️ Étape 4 : Sécurité & Conformité (Critique en 2026)

  1. Network Policies : Isoler les pods Dolibarr (app, db). Exemple :

    kind: NetworkPolicy
    
apiVersion: networking.k8s.io/v1
    
metadata:
    
  name: dolibarr-allow-only-frontend
    
spec:
    
  podSelector:
    
    matchLabels:
    
      app: dolibarr
    
  policyTypes:
    
  - Ingress
    
  ingress:
    
  - from:
    
    - podSelector:
    
        matchLabels:
    
          app: nginx-ingress # Seul l'ingress controller peut joindre
    
    ports:
    
    - protocol: TCP
    
      port: 80

  2. Pod Security Standards : Appliquer le profil restricted via un policy controller (Kyverno, OPA Gatekeeper).

  3. Secrets Management : Utiliser HashiCorp Vault avec le Kubernetes Auth Method pour injecter dynamiquement les credentials DB. Rotation automatique possible via Vault.

  4. Backup automatisé : Utiliser un side-car ou un CronJob avec pg_dump et transfert vers un stockage objet distant (S3 compatible). Stockage chiffré (SSE-S3).

  5. scanners : Intégrer Trivy (images), Kube-score (manifests), Gitleaks (secrets dans le code) dans la CI.

📊 Étape 5 : Observabilité & Maintenance

Monitoring avec Prometheus :

  • Exporter les métriques Dolibarr via un script custom ou utiliser l’exporteur HTTP générique (blackbox-exporter pour l’uptime).

  • Métriques clés : performance PHP-FPM (php-fpm exporter), latence DB, taille du stockage documents.

Gestion des logs :

  • Structurer les logs applicatifs (JSON) et les envoyer vers Loki via le side-car Fluent Bit ou le DaemonSet.

Mise à jour en rolling update sécurisé :

  • Le Deployment Kubernetes gère automatiquement le rolling update (strategy.type: RollingUpdate).

  • Stratégie recommandée : Mettre à jour d’abord les pods app (avec healthcheck), puis les configurations (ConfigMap) si nécessaire. La base de données est migrée séparément via un Job exécuté manuellement ou déclenché conditionnellement.

Gestion des migrations Dolibarr :

  • Ne jamais automatiser un dolibarr-cli.php sur un environnement de production sans validation humaine préalable. Prévoir une phase de test sur un clone de production (staging) via une Review App (environnement temporaire créé pour chaque PR).

  • Documenter et versionner les scripts de migration spécifiques à vos modules personnalisés.

📈 Étape 6 : Scaling & Haute Disponibilité

  • Horizontal Pod Autoscaler (HPA) : Basé sur l’utilisation CPU/mémoire ou une métrique custom (ex: file d’attente PHP-FPM). 
    apiVersion: autoscaling/v2
    
kind: HorizontalPodAutoscaler
    
metadata:
    
  name: dolibarr-hpa
    
spec:
    
  scaleTargetRef:
    
    apiVersion: apps/v1
    
    kind: Deployment
    
    name: dolibarr-app
    
  minReplicas: 3
    
  maxReplicas: 10
    
  metrics:
    
  - type: Resource
    
    resource:
    
      name: cpu
    
      target:
    
        type: Utilization
    
        averageUtilization: 70

  • Base de données : Utiliser un cluster PostgreSQL managé (CloudSQL, RDS) avec au moins une instance de secours. Activer les read replicas pour les rapports lourds.

  • Stockage documents : Utiliser un stockage objet (S3, MinIO) scalable. Éviter les volumes persistants NFS monolithiques.

🔄 Workflow de déploiement recommandé (GitOps)

  1. Dev : Chaque développeur utilise docker-compose ou un cluster local (Minikube, Kind) avec les mêmes images que la production.

  2. Pull Request : CI exécute tests unitaires, analyse statique (PHPStan, Psalm), scan de vulnérabilités. Review App créée automatiquement pour tests manuels.

  3. Merge vers main : Pipeline CI/CD construit l’image, la push, la scan, et met à jour le manifeste Kubernetes dans un dépôt séparé (manuel ou auto).

  4. Flux CD (GitOps) : Un contrôleur comme ArgoCD ou Flux détecte le changement dans le dépôt de manifestes et applique la nouvelle version dans le cluster prod après validation (si besoin).

  5. Post-deploy : Exécution automatisée des tests de sanity (smoke tests) sur l’url de staging/prod. Notification sur Slack/Teams.

🧹 Maintenance et Rétro-ingénierie

  • Logs rotés : Configurer la rétention dans Loki/Promtail.

  • Nettoyage des images : Configurer un registry avec une politique de rétention (ex: garder les 30 dernières images par tag).

  • Audit des droits : Réaliser un audit trimestriel des rôles Dolibarr via l’interface admin.

  • Mise à jour de l’OS de base : Rebuildr périodiquement les images Docker (weekly) pour inclure les correctifs système de la base alpine.

  • Playbook de crise : Documenter la procédure de rollback (retour à l’image précédente via kubectl rollout undo).

🎯 Conclusion

Déployer Dolibarr en 2026 avec une approche DevOps, c’est :

✅ Gagner en fiabilité : Des déploiements reproductibles, documentés et automatisés.
✅ Renforcer la sécurité : Image minimale, scan continue, secrets managés, isolation réseau.
✅ Assurer la scalabilité : Prêt pour la croissance sans réarchitecture.
✅ Simplifier la maintenance : Observabilité intégrée, rollback immédiat, mises à jour contrôlées.

L’investissement dans cette chaîne DevOps, bien que plus complexe initialement qu’un "simple" LAMP, se rentabilise très rapidement dès que le système devient critique pour l’organisation. La clé du succès réside dans la documentation de chaque étape, la formation des équipes et l’adoption d’une culture de l’automatisation mesurée.

Documentez vos procédures, versionnez vos configs, et surtout : testez, testez, testez !

Ressources utiles :

Article basé sur les standards et outils prédominants mi-2026. Les versions spécifiques doivent être adaptées à votre contexte et à votre fournisseur cloud.

Publications similaires