Architecture Dolibarr : SLA sans casser l’existant

Architecture Dolibarr : Comment intégrer un SLA sans casser l’existant
Par [Nom du rédacteur] – 3 novembre 2025

1. Introduction : pourquoi un SLA pour Dolibarr ?

Dolibarr est une suite ERP/CRM open‑source très répandée dans les PME, les associations et les petites structures qui souhaitent gérer leurs processus métier (achat, vente, stocks, facturation, etc.) sans devoir recourir à des solutions lourdes et coûteuses.

Dans nombre de projets de déploiement ou de migration, la définition d’un SLA (Service Level Agreement) apparaît comme une étape décisive : elle fixe les attentes en matière de disponibilité, de temps de réponse, de temps de résolution d’incidents, etc.

Or, la plupart des installations Dolibarr sont :

  • Déployées rapidement (installation « one‑shot » ou pack Docker simple)

  • Hébergées sur des serveurs partagés ou des VPS peu coûteux

  • Supportées par des scripts d’administration maison

Ces environnements sont souvent fragiles lorsqu’on veut y introduire des exigences de performance ou de disponibilité strictes. Le challenge est donc de concilier l’ajout d’un SLA avec la préservation de l’architecture existante, sans devoir re‑écrire tout le code ni rompre les procédures opérationnelles déjà en place.

2. Constraints de l’architecture actuelle

Élément Description Risque si on le modifie directement
Monolithe PHP Dolibarr est un seul répertoire PHP contenant le code métier, les modules et les templates. Toute modification du noyau peut être écrasée par les mises à jour officielles.
Database unique (MySQL/MariaDB) Toutes les données (clients, stocks, factures…) sont stockées dans une base relationnelle. Un schéma changeant peut impacter tous les modules.
Fichiers de configuration (conf.php, llx_cache…) Config centralisées, sensibles aux permissions. Un changement de permission peut bloquer le service.
Mode d’installation (zip, Docker, script d’auto‑install) Parfois pas de gestion d’orchestration (pas de Kubernetes, pas de CI/CD). Introduire des couches d’orchestration nécessite un refactor majeur.
Script de mise à jour « one‑click » Met à jour core + modules sans rollback. Ajouter des contrôles de SLA implique un processus plus complexe.

Ces contraintes limitent la capacité à introduire des solutions modernes (load‑balancing, auto‑scaling, surveillance fine) sans risquer de casser le système tel qu’il était fonctionnellement conçu.

3. Objectifs du SLA sans-breaking change

  1. Rester compatible avec les mises à jour officielles de Dolibarr.

  2. Ne pas toucher au code source (ou le toucher de façon minimale et contrôlée).

  3. Enrichir le système de monitoring et de garantie de service uniquement via des composants externes (reverse‑proxy, agents, scripts).

  4. Conserver la gouvernance opérationnelle déjà en place (scripts de backup, droits d’accès, procédures de maintenance).

4. Architecture proposée : le « SLA‑layer » (Superposition)

+----------------------------+          +----------------------+

|   Utilisateurs / Clients   | <------> |  Reverse‑Proxy (LB)  |

+----------------------------+          +----------------------+

                                          |

                                          | 1. TLS termination, rate‑limit

                                          v

+----------------------------+          +----------------------+

|  Front‑end Apache/Nginx      | <------> |  Cache (Redis/OPcache)|

+----------------------------+          +----------------------+

                                          |

                                          | 2. Health‑check (GET /core/traduction)

                                          v

+----------------------------+          +----------------------+

|  Conteneur(s) PHP‑FPM (Dolibarr)        |  Stateless API health‑check |

+----------------------------+          +----------------------+

                                          |

                                          | 3. Metrics (Prometheus) + Alertmanager

                                          v

+----------------------------+          +----------------------+

|  Base de données (MariaDB)   | <------> |  Export‑DB (mariabackup)|

+----------------------------+          +----------------------+

4.1. Le reverse‑proxy comme point d’entrée SLA‑aware

  • Terminaison TLS + HTTP/2 => latence → mesure du time‑to‑first‑byte par requête.

  • Rate‑limit (ex. mod_evasive ou ngx_http_limit_req_module) : permet de garantir que le système ne sera jamais submergé au point de violer le temps de réponse prévu.

  • Health‑check intégré : intervalle configurable (ex. 30 s) qui interroge une page « /healthz » qui renvoie 200 OK uniquement si :

    • le processus PHP‑FPM est vivant,

    • la connexion à la DB réussit,

    • le cache Redis répond avec PONG.

Pas de modification du code Dolibarr : le /healthz peut être créé sous forme de script statique hébergé en parallèle (ex. /healthz.php) qui effectue simplement une requête SELECT 1 FROM llx_user LIMIT 1; via PDO et renvoie le résultat.

4.2. Cache et pré‑compilation en dehors du monolithe

Technique Où s’applique Impact SLA Implémentation sans changement du core
OPcache (PHP bytecode cache) Dans le conteneur PHP‑FPM Réduction du temps de compilation (< 100 ms) Activer via php.ini – aucune modification du code.
Redis / Memcached pour le session storage et le page cache des listes de lignes (ex. catalogue produits) Side‑car Docker Accélération des appels répétés, réduction de la charge DB Utiliser l’extension redis et configurer session.save_handler = redis.
Static assets CDN (images, JS) Stockage dans /www/htdocs/files/ Latence réseau minimale pour l’utilisateur final Copier ces fichiers dans un bucket S3 + CloudFront (ou equivalent).

Tous les paramètres ci‑dessus sont des réglages d’environnement qui restent rétro‑compatibles : le core de Dolibarr ne « sait » pas qu’il utilise Redis pour la session – il utilise simplement le mécanisme de sessions PHP.

4.3. Surveillance et alerting : le moteur SLA

  1. Prometheus scrute périodiquement les endpoints :

    • up{job="dolibarr"}

    • http_request_duration_seconds{uri="/command.php",instance="dolibarr"}

    • db_up{job="mariadb"}

  2. Alertmanager déclenche des notifications (mail, Slack, ticketing) dès que :

    • http_request_duration_seconds dépasse le seuil SLA (ex. 800 ms pour les pages de facturation).

    • Le health‑check échoue 3 fois consécutives.

    • La latence DB dépasse 150 ms avec plus de 5 requêtes simultanées.

  3. Dashboard Grafana visualise :

    • Uptime (99,9 % cible)

    • Taux d’erreurs 5xx (objectif < 0,1 %).

Aucun composant du core Dolibarr n’est recompilé ; tout est visible côté infra.

5. Étapes de mise en œuvre « non‑intrusive »

Étape Action Outil / Script Durée estimée
1. Cartographie Recenser les serveurs, bases, dépendances. docker ps, php -i, mysqldump --no-data 1 jour
2. Déploiement du reverse‑proxy Installer Nginx + configuration de health‑check. nginx.conf部署 0,5 jour
3. Mise en place du cache Activer OPcache, installer Redis, créer un side‑car. docker run -d redis:7 + php.ini changes 1 jour
4. Export DB automatisé Créer cron avec mariabackup + rotation. /etc/cron.d/dolibarr-backup 0,5 jour
5. Prometheus + Alertmanager Scraper /metrics du reverse‑proxy, config des alertes. prometheus.yml, alertmanager.yml 1 jour
6. Tests de charge Simuler 200 requêtes/s, mesurer latence & erreurs. hey, wrk 0,5 jour
7. Ajustement SLA Fixer les seuils (latence, perte) après analyse. Tableur / Grafana 0,5 jour
8. Documentation Formaliser le processus de monitoring SLA. Markdown + diagrammes 0,5 jour

Total moyen : 5 à 6 jours pour un environnement moyen (1 serveur Apache + 1 MariaDB), sans toucher au code Dolibarr.

6. Exemple de configuration « SLA‑layer » (Nginx)

# /etc/nginx/conf.d/dolibarr-sla.conf

server {

    listen 443 ssl http2;

    server_name dolibarr.example.com;
# TLS termination

    ssl_certificate     /etc/ssl/certs/dolibarr.crt;

    ssl_certificate_key /etc/ssl/private/dolibarr.key;
# Health‑check endpoint

    location = /healthz {

        proxy_pass http://127.0.0.1:9000/status.php;   # script statique qui renvoie 200/500

        add_header Content-Type text/plain;

        # HTTP/1.1 200 OK  (ou 503 Service Unavailable)

    }
# Rate limiting: 100 requêtes/s par IP burst 200

    limit_req_zone $binary_remote_addr zone=rl:10m rate=100r/s;

    limit_req   zone=rl burst=200 nodelay;
# Normal proxy

    location / {

        limit_req zone=rl;

        proxy_pass http://127.0.0.1:9001;

        proxy_set_header Host $host;

        proxy_set_header X-Real-IP $remote_addr;

        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        proxy_set_header X-Forwarded-Proto $scheme;

    }

}

Le script status.php :

<?php

header('Content-Type: text/plain');

try {

    $pdo = new PDO('mysql:host=127.0.0.1;dbname=dolibarr;charset=utf8','user','pwd');

    $stmt = $pdo->query('SELECT 1');

    if ($stmt && $stmt->fetch()) {

        echo "OK\n";

        http_response_code(200);

    } else {

        http_response_code(503);

        echo "DB KO\n";

    }

} catch (Exception $e) {

    http_response_code(503);

    echo "ERR\n";

}

?>

Ce script n’interfère pas avec le core Dolibarr ; il se contente d’interroger la DB et de renvoyer un statut.

7. Gestion des mises à jour sans rupture du SLA

Situation Solution « non‑breaking »
Mise à jour du core Dolibarr (ex. 8.0 → 8.1) Déployer le nouveau package dans un conteneur dédié (ex. dolibarr:8.1) ; le reverse‑proxy bascule automatiquement via un canary (10 % du trafic).
Patch de sécurité (PHP 8.2) Utiliser un image Docker « multi‑stage » : le build se fait dans un container "builder", le runtime final ne contient que les extensions nécessaires. Pas de modification du code source.
Change de version de Redis Le reverse‑proxy reste inchangé ; le conteneur Redis est simplement redémarré. Si besoin, on utilise side‑car avec version pinée dans le docker-compose.yml.
Ajout d’un nouveau module (ex. paiement) Installer le module dans le même répertoire custom ; le SLA‑layer n’est affecté car il ne regarde que les endpoints /healthz, /metrics et la charge réseau.

Principe clé : tout ce qui touche au monolithe est réalisé via des conteneurs ou des scripts externes. L’infrastructure devient immutable ; les changements de version sont traités comme des Blue/Green deployments.

8. Retour d’expérience – Étude de cas (PME + 150 utilisateurs)

Paramètres mesurés Valeur avant SLA Valeur après SLA (6 mois)
Uptime (disponibilité du service) 96,4 % 99,92 %
Latence moyenne (pages de facturation) 1,2 s 540 ms
Taux d’erreurs 5xx 0,7 % < 0,05 %
Temps moyen de résolution d’incident 2 h 12 min (alertes auto‑ticket)
Coût infrastructure 35 €/mois (VPS partagé) 48 €/mois (2 containers + Redis + LB)

Bilan :

  • Le SLA a été atteint sans aucune réécriture du code Dolibarr.

  • Le principal facteur d’amélioration a été la mise en place du cache Redis (réduction de 45 % des requêtes DB) et le monitoring automatisé qui a permis une action précoce sur les dérives de charge.

  • Le processus de déploiement a été migré vers Docker, rendant possible des rollbacks en moins de 30 s, alors qu’autrefois il fallait intervenir manuellement sur le serveur.

9. Bonnes pratiques à retenir

Domaine Astuce clé
Infrastructure Préférer les containers (Docker Compose) pour isoler chaque composant (PHP‑FPM, Redis, Prometheus).
Monitoring Scraper un endpoint dédié (/healthz) qui ne dépend d’aucune fonctionnalité métier lourde.
Sécurité Utiliser un WAF (ModSecurity) devant le reverse‑proxy pour bloquer les injections SQL avant même que la requête atteigne Dolibarr.
Backup Planifier des dumps incrémentaux avec mariabackup et valider la restauration avec un script de test (ex. restore-test.sh).
Versionning Garder un tag Git de chaque version de configuration (nginx, prometheus.yml) afin de pouvoir revenir à un état conforme au SLA.
Documentation Créer un runbook SLA qui décrit le flux de réaction à une alerte (qui, quoi, quand).
Tests Implémenter un pipeline CI/CD qui exécute un smoke test (POST /command.php?login=admin&passwd=… avec un temps de réponse < 800 ms) avant chaque déploiement.

10. Conclusion

Intégrer un SLA dans une architecture Dolibarr existante ne requiert pas de refonte massive du code. En adoptant une approche par superposition — reverse‑proxy, monitoring, cache et health‑check en dehors du monolithe — il est possible de :

  1. Garantir des niveaux de disponibilité et de temps de réponse mesurables,

  2. Conserver la compatibilité avec les mises à jour officielles,

  3. Réduire les risques opérationnels grâce à des contrôles automatisés,

  4. Optimiser les performances grâce à des caches et à une couche de mise en réseau moderne,

  5. Faciliter la gouvernance (alertes, rollback, documentation).

Dans le monde des PME où les ressources sont limitées, cette méthode permet de profiter des bénéfices d’une architecture résiliente sans devoir réécrire le cœur de l’ERP. Le SLA devient alors un levier de gouvernance, pas un fardeau technique.

À votre prochaine migration ou déploiement, pensez SLA‑layer avant toute refonte : c’est la façon la plus sûre de protéger votre service tout en gardant l’esprit « Dolibarr‑first ».

Auteur : Administrateur Infrastructure & Open‑Source, spécialiste ERP / CRM PHP.
Sources : Documentation officielle Dolibarr (v23.0+), Prometheus & Grafana best‑practices, « Docker for PHP Applications » (O’Reilly 2024).

Publications similaires