Intégrer Dolibarr avec Azure : Framework en 30 jours

Guide complet pour déployer, sécuriser et optimiser votre solution Dolibarr sur la plateforme Azure

1. Pourquoi Dolibarr + Azure ?

Atout Dolibarr Valeur ajoutée Azure
ERP/CRM léger, open‑source, facile à personnaliser Services PaaS scalables (App Service, Azure SQL, Blob)
Architecture modulaire (modules comptabilité, stocks, CRM…) Gestion de la haute disponibilité & de la continuité d’activité
Grande communauté francophone Outils DevOps (Azure Pipelines, GitHub Actions) & monitoring (Application Insights)
Support multi‑langue et multi‑devise Sécurité intégrée (Azure AD, Managed Identities, Key Vault)

Objectif du framework : fournir un plan d’action détaillé (30 jours) qui vous conduit d’une simple installation locale à un déploiement production sur Azure, tout en conservant la souplesse du code source open‑source.

2. Prérequis techniques

Élément Version minimale recommandée Commentaires
Azure Subscription Free tier → Pay‑as‑you‑go (ou enterprise) Prévoir un quota pour App Service, DB, Stockage
Git 2.30+ Accès à votre repository GitHub/Bitbucket
Node.js / PHP PHP 8.1+ (recommandé) Dolibarr est principalement PHP
Docker (facultatif) 20.10+ Pour les environnements de test locale
VS Code / IDE – Installation de l’extension Azure Tools
Compte Azure AD – Pour le contrôle d’accès et l’authentification unique
Environnement local Linux (Ubuntu 22.04) ou Windows Dépend de votre équipe

3. Architecture cible

┌─────────────────────┐     ┌─────────────────────┐

│   Front‑end (SPA)   │←─► │ Azure Front Door   │

└─────────▲───────────┘     └───────▲───────▲───┘

          │                         │       │

          │                         │       │

┌─────────▼───────────┐   ┌───────────────▼───────┐│

│  Azure App Service  │   │ Azure SQL Database   ││

│  (Dolibarr PHP)    │   │ (Persist. métiers)   ││

└───────▲─────────────┘   └───────▲───────────────┘│

        │                         │           │

        │                         │           │

   ┌────▼─────┐            ┌──────▼─────┐   ┌─────▼─────┐

   │ Blob     │            │ Key Vault  │   │ Application│

   │ Storage  │            │ (Secrets)  │   │ Insights   │

   └──────────┘            └────────────┘   └─────────────┘

  • Front‑End : optionnel, via un SPA (React/Vue) hébergé sur Azure Static Web Apps ou CDN.

  • Back‑End : Azure App Service (PHP 8.1) qui exécute Dolibarr.

  • Base de données : Azure Database for MySQL ou Azure SQL Database (recommandé pour la compatibilité).

  • Stockage d’objets : Azure Blob pour fichiers PDF, factures, pièces jointes.

  • Gestion des secrets : Azure Key Vault.

  • CI/CD : Azure DevOps Pipelines ou GitHub Actions.

  • Monitoring : Application Insights + Log Analytics.

4. Planning 30 jours – Le framework pas‑à‑pas

Semaine Objectif Livrable Temps estimé Ressources clés
S1 – Analyse & pré‑préparation (J1‑J5) • Recenser les besoins métiers
• Définir les scénarios d’utilisation
• Recenser la gouvernance (RGPD, sécurité)		 Document de spécifications fonctionnelles (PDF) 8 h MO, PO
S2 – Environnement de dev local (J6‑J12) • Installer Docker docker-compose.yml avec Dolibarr + MySQL + Blob emulator
• Créer un repo Git dolibarr-azure
• Configurer les variables d’environnement locales		 Repo Git avec docker-compose.yml fonctionnel 12 h Dev team
S3 – Création de l’infrastructure Azure (J13‑J16) • Créer un Resource Group
• Déployer un App Service (Linux)
• Créer Azure Database for MySQL (ou Azure SQL)
• Provisionner Blob Storage et Key Vault		 Infrastructure IaC (Terraform ou ARM) 10 h Cloud Engineer
S4 – CI/CD & Automisation (J17‑J20) • Configurer pipeline Azure DevOps (build → test → deploy)
• Intégrer le branch‑policy (PR)
• Déployer la base de données via migration scripts
• Mise en place du Cache CDN (optionnel)		 Pipeline fonctionnel, documentation CI/CD 12 h DevOps
S5 – Sécurité & conformité (J21‑J23) • Activer Managed Identity pour l’App Service
• Attacher les secrets (DB‑connection, API‑key) depuis Key Vault
• Configurer Azure AD pour SSO (facultatif)		 Identités gérées, secrets injectés 8 h Security Engineer
S6 – Tests fonctionnels & performance (J24‑J26) • Tests d’intégration (API, webhook)
• Tests de charge avec Azure Load Testing
• Validation du rendu (UI/UX)		 Rapport de tests complet, liste des bugs corrigés 10 h QA
S7 – Go‑Live & post‑déploiement (J27‑J30) • Basculer le trafic via Azure Front Door ou Traffic Manager
• Mettre en place le Monitoring (App Insights)
• Élaborer le plan de backup & DR
• Rédaction de la run‑book d’exploitation		 Environnement production, documentation finale 12 h Ops Team

Total estimé : ≈ 72 h réparties sur 30 jours calendaires (≈ 2,4 h/jour).

5. Détail des étapes clés

5.1. Création du conteneur Docker local (S2)

version: "3.8"

services:

  db:

    image: mysql:8

    environment:

      MYSQL_DATABASE: dolibarr

      MYSQL_USER: dolibarr

      MYSQL_PASSWORD: secret

    volumes:

      - db_data:/var/lib/mysql

  php:

    image: php:8.1-apache

    depends_on:

      - db

    volumes:

      - ./dolibarr:/var/www/html

      - ./docker/php.ini:/usr/local/etc/php/php.ini

    environment:

      - DB_SERVER=db

      - DB_NAME=dolibarr

      - DB_USER=dolibarr

      - DB_PASSWORD=secret

    ports:

      - "8080:80"

volumes:

  db_data:

  • Avantage : reproduit exactement le stack Azure (MySQL, PHP) pour éviter les surprise de configuration.

5.2. Infrastructure as Code (IaC) – Exemple Terraform

resource "azurerm_resource_group" "rg" {

  name     = "rg-dolibarr"

  location = "France Central"

}
resource "azurerm_app_service_plan" "plan" {

  name                = "ap-dolibarr-plan"

  location            = azurerm_resource_group.rg.location

  resource_group_name = azurerm_resource_group.rg.name

  sku {

    name   = "B1"

    tier   = "Basic"

    size    = "B1"

  }

}
resource "azurerm_linux_web_app" "app" {

  name                = "dolibarr-app"

  location            = azurerm_resource_group.rg.location

  resource_group_name = azurerm_resource_group.rg.name

  app_service_plan_id = azurerm_app_service_plan.plan.id
publisher = "php|8.1"

  version   = "8.1"
app_settings = {

    "DOLIBARR_DB_HOST"    = azurerm_mysql_server.mysql.server_name

    "DOLIBARR_DB_NAME"    = "dolibarr"

    "DOLIBARR_DB_USER"    = "dolibarr_user"

    "DOLIBARR_DB_PASSWORD" = azurerm_key_vault_secret.db_password.value

  }
identity {

    type = "SystemAssigned"

  }

}
resource "azurerm_mysql_server" "mysql" {

  name                         = "mysql-dolibarr"

  location                     = azurerm_resource_group.rg.location

  resource_group_name          = azurerm_resource_group.rg.name

  version                      = "5.7"

  administrator_login          = "admin"

  administrator_login_password = "StrongPassword!"

}
resource "azurerm_key_vault" "kv" {

  name                        = "kv-dolibarr"

  location                      = azurerm_resource_group.rg.location

  resource_group_name           = azurerm_resource_group.rg.name

  tenant_id                     = data.azurerm_client_config.current.tenant_id

}
resource "azurerm_mysql_database" "db" {

  name     = "dolibarr"

  server_id = azurerm_mysql_server.mysql.id

}

À retenir : vous pouvez versionner ce fichier .tf dans le même repo Git que votre application.

5.3. Pipeline Azure DevOps (exemple de YAML)

trigger:

  branches:

    include:

      - main
pool:

  vmImage: 'ubuntu-latest'
variables:

  - name: azureSubscription

    value: 'mysubscription'   # service connection Azure

  - name: imageName

    value: 'myregistry.azurecr.io/dolibarr:$(Build.BuildId)'
stages:

- stage: Build

  jobs:

  - job: BuildDolibarr

    steps:

    - checkout: self

    - task: Docker@2

      displayName: 'Build Docker image'

      inputs:

        containerRegistry: $(ACR)

        repository: $(imageName)

        command: build
- stage: Deploy

  dependsOn: Build

  condition: succeeded()

  jobs:

  - deployment: DeployToAzure

    environment: 'Azure-Prod'

    strategy:

      runOnce:

        deploy:

          steps:

          - download: current

            artifact: drop

          - task: AzureWebApp@1

            inputs:

              azureSubscription: $(azureSubscription)

              appName: 'dolibarr-app'

              package: '$(Pipeline.Workspace)/drop/dolibarr.zip'

5.4. Sécurisation des secrets avec Azure Key Vault

# Exemple PowerShell pour stocker la chaîne de connexion

$connectionString = "Server=tcp:${{azurerm_mysql_server.mysql.server_name}},${{azurerm_mysql_server.mysql.fqdn)};Database=dolibarr;User ID=dolibarr_user;Password=P@ssw0rd;Encrypt=yes;TrustServerCertificate=no;"

Set-AzKeyVaultSecret -VaultName kv-dolibarr -Name "DB-ConnectionString" -SecretValue $connectionString

Dans le configuration.php de Dolibarr :

$dbhost = getenv('DOLIBARR_DB_HOST') ?: 'localhost';

$dbname = getenv('DOLIBARR_DB_NAME') ?: 'dolibarr';

$dbuser = getenv('DOLIBARR_DB_USER') ?: 'dolibarr';

$dbpass = getenv('DOLIBARR_DB_PASSWORD') ?: '';

$language = 'fr';

En production, Injectez les variables d’environnement depuis Key Vault via App Settings (Azure Portal → Configuration → Application Settings) – c’est plus simple que de modifier le code.

6. Bonnes pratiques & points d’attention

Thème Règles d’or
Versioning Taguer chaque release (v1.0, v1.1) dans Git et dans Azure Container Registry (ACR).
Scalabilité Configurer App Service Plan en mode PremiumV2 dès le lancement d’un trafic prévisible > 100 RPS.
Sauvegarde DB Activer le zone‑redundant backup et planifier full + log backups (7 jours).
Monitoring Créer un Alert Rule sur Requests>5xx, CPU>80%, Memory>75%.
Sécurité Ne jamais stocker de secrets en clair dans le repo – passer systématiquement par Key Vault.
Performance Activer le caching de pages (Azure CDN) pour les assets statiques et les API GET.
Déploiement zéro‑downtime Utiliser des slot swap dans App Service (staging → production).
Conformité RGPD Implémenter un Data Processing Agreement avec le provider Azure et chiffrer les données sensibles (Blob SSE‑CMK).

7. Checklist finale avant le Go‑Live

✅ Élément
1 Resource Group, App Service, MySQL, Blob, Key Vault créés via IaC.
2 Application déployée sur slot staging et testée (fonctions, journaux).
3 Secrets injectés depuis Key Vault → App Settings.
4 URL du front‑end pointée vers le slot production.
5 Monitoring (Application Insights) configuré & alertes actives.
6 Backup DB (daily) et test de restauration réalisés.
7 Document de run‑book (démarrage, mise à jour, rollback) rédigé.
8 Validation du gateway SSL (Azure Front Door) et du WAF (si besoin).
9 Tests de charge terminés, seuils < 5 s de latence.
10 Communication de lancement (mail aux utilisateurs, guides d’assistance).

8. Conclusion

Intégrer Dolibarr sur Azure n’est pas seulement une opération d’hébergement ; c’est une démarche architecturale qui profite du cloud pour :

  • Garantir la scalabilité (Ajout d’instances sans downtime).

  • Sécuriser les données (identités managées, vault, chiffrement).

  • Automatiser le cycle de vie (CI/CD, IaC, monitoring).

Le framework présenté ci‑dessus, découpé en 30 jours, vous permet de :

  1. Maîtriser chaque composant (Docker, Terraform, Azure services).

  2. Valider continuellement grâce aux tests automatisés.

  3. Passer de la preuve de concept à la production avec rigueur et visibilité.

En suivant ce plan, votre organisation pourra exploiter Dolibarr comme plateforme ERP/CRM fiable, tout en tirant parti des atouts d’Azure pour la résilience et l’innovation.

Bonne migration ! 🚀

Sources & ressources complémentaires

  • Dolibarr Documentation officielle – Section Installation on Azure (v17.2).

  • Microsoft Learn – Deploy a PHP web app to Azure App Service.

  • Azure Architecture Center – Pattern Web App + Azure Database for MySQL.

  • Blog interne “Getting started with Key Vault and PHP”.

Cet article a été rédigé par l’équipe Cloud Solutions, 2025.

Publications similaires