Sécurité Dolibarr : SLA FAQ pour mieux piloter

Version 1.0 – Novembre 2025

1. Introduction

Dolibarr est une suite ERP/CRM open‑source très appréciée des PME et des associations pour sa simplicité d’utilisation et sa modularité. Cependant, comme tout système d’information, il expose des surfaces d’attaque (API, fichiers de configuration, plugins…) qui doivent être correctement protégés.

Dans une démarche de gouvernance des services, il est fréquent d’instaurer des SLA (Service Level Agreements) afin de définir clairement les attentes de sécurité, de disponibilité et de support. Un FAQ SLA aide les équipes techniques et les décideurs à mesurer, piloter et améliorer la sécurité de leurs instances Dolibarr.

Cet article propose :

  1. Un rappel des bonnes pratiques de sécurité pour Dolibarr.

  2. Un cadre de rédaction de SLA orienté sécurité.

  3. Une FAQ SLA prête à l’emploi, structurée par questions/ réponses.

  4. Des pistes d’action pour transformer ces engagements en objectifs mesurables.

2. Sécurité de Dolibarr – Les principes de base

Domaine Bonnes pratiques Outils / Méthodes recommandés
Installation – Utiliser uniquement des sources officielles (GitHub, paquets officiels).
– Désactiver le compte administrateur par défaut.		 apt-get install dolibarr (ou Docker) + htpasswd
Configuration du serveur web – Bloquer l’accès direct aux dossiers sensibles (conf/, dolibarr/bib/, pics/).
– Activer HTTPS (TLS 1.3).		 Nginx/Apache / mod_ssl, fail2ban
Authentification – Forcer les mots de passe forts (≥12 caractères, mélange de majuscules/minuscules, chiffres, spéciaux).
– Activer l’authentification à 2 facteurs (2FA) via plugins (ex. : Google Authenticator).		 libpam-pwquality, plugin 2FA
Gestion des droits – Appliquer le principe du moindre privilège (le groupe “User” ne doit jamais avoir accès admin).
– Utiliser les groupes de droits Dolibarr (Admin, User, Public).		 Revue régulière des profils → scripts de conformité
Mises à jour – Mettre à jour le core et les plugins dès qu’une release de sécurité est disponible.
– Maintenir un environnement de test pour valider les upgrades.		 Ansible playbooks, GitLab CI/CD
Journalisation & suivi – Centraliser les logs (auditd, ELK, Graylog).
– Configurer des alertes sur tentatives d’accès multiples ou sur modification de fichiers critiques.		 rsyslog, OSSEC, Splunk
Sécurité des données – Chiffrer la base de données (MariaDB/MySQL Transparent Data Encryption ou gpg‑based backups).
– Sauvegarder en dehors du serveur et conserver les sauvegardes chiffrées.		 mariabackup, restic
Modules additionnels – Limiter les plugins installés à ceux réellement utilisés.
– Auditer les plugins pour vulnérabilités connues (ex. : Dolibarr Antivirus, Advanced Payment).		 OWASP Dependency‑Check, npm audit (si Node.js)
Backup & récupération – Réaliser des backups complets au moins quotidiennement.
– Tester la restauration régulièrement (ex. : exercice de “fire drill”).		 Duplicity, BorgBackup
Hardening du serveur – Désactiver les services inutiles (ex. : FTP, Telnet).
– Utiliser un firewall (iptables/ufw) restrictif.		 ufw enable, iptables -A INPUT -p tcp --dport 80 -j ACCEPT

Tip : Documentez chaque point dans un CMDB dédié aux configurations de sécurité afin d’assurer la traçabilité des changements.

3. Cadre de rédaction d’un SLA orienté sécurité

3.1. Objectifs du SLA

Critère Définition Exemple de KPI Niveau attendu
Disponibilité du service Pourcentage de temps où l’instance Dolibarr est opérationnelle et accessible. Disponibilité mensuelle (Uptime) ≥ 99,5 %
Temps de réponse des requêtes Latence moyenne des appels HTTP (page d’un formulaire, recherche de factures). Temps de réponse < 2 s (p95) ≤ 1,5 s
Détection et résolution des incidents de sécurité Délai moyen entre la découverte d’un incident et sa résolution. MTTR (Mean Time To Repair) ≤ 4 h pour les incidents critiques
Gestion des sauvegardes Fréquence des sauvegardes fiables + temps de restauration. RPO ≤ 12 h, RTO ≤ 2 h 100 % des backups réussis, RTO ≤ 2 h
Patch Management Rapidité d’application des correctifs de sécurité. Délai d’application des patches critiques ≤ 48 h après publication du correctif
Audit & conformité Nombre d’audits internes réalisés par période et actions correctives. Audits internes semestriels 2 audits/an + reporting
Sensibilisation Pourcentage du personnel formé aux bonnes pratiques de sécurité. Sessions de formation / an 100 % du staff (au moins 1h/an)

3.2. Parties prenantes

Rôle Responsabilité SLA Contact
Direction Valider les objectifs, allouer les moyens. CIO / DSI
Équipe DevOps Mettre en place les outils de monitoring et de patching. Lead DevOps
Équipe Sécurité Auditer la conformité, gérer les incidents critiques. Responsable Sécurité
Support technique Gestion du premier niveau d’incidents, escalade. Service Helpdesk
Prestataire externe (si externalisé) Fournir les services de sauvegarde / d’hébergement. CSM (Customer Success Manager)

3.3. Mécanisme de suivi

  • Tableau de bord (BI) affichant les KPIs en temps réel.

  • Revues mensuelles du SLA avec les parties prenantes.

  • Rétroaction : chaque revues génère un plan d’action (CAPA).

4. FAQ SLA – Questions fréquentes et réponses

4.1. Quelle est la différence entre Uptime et Disponibilité ?

  • Uptime = temps réel pendant lequel le serveur reste en ligne (détecté par un moniteur).

  • Disponibilité = temps réel où le service répond correctement (inclut la latence, les erreurs de code, les maintenances planifiées).

    SLA cible généralement la disponibilité (ex. : 99,5 %).

4.2. Que se passe‑t‑il si un patch de sécurité critique n’est pas appliqué dans les 48 h ?

  • Escalade immédiate vers le Responsable Sécurité.

  • Plan d’action : mise en place d’un window de maintenance (souvent le week‑end) ou un hot‑fix temporaire (patch manuel).

  • Notification au comité de pilotage avec justification du retard.

4.3. Comment mesurer le MTTR (Mean Time To Repair) des incidents de sécurité ?

  1. Loguez l’heure de découverte (début du ticket).

  2. Enregistrez l’heure de clôture (résolution ou mise en quarantaine).

  3. Calculez la moyenne mensuelle des durées.

  4. Cible : ≤ 4 h pour les incidents classés Critique ou Élevé.

4.4. Quels outils peuvent automatiser le monitoring des KPI de sécurité ?

  • Prometheus + Grafana – collecte de métriques (CPU, temps de réponse, 5xx).

  • Zabbix – alertes sur la disponibilité et la latence.

  • ELK – analyse des logs et corrélation d’événements de sécurité.

  • Docker Healthchecks – pour les conteneurs Dolibarr, déclenchement d’alertes si le conteneur ne répond plus.

4.5. Le SLA doit‑il couvrir les plugins tiers ?

  • Oui, tout ce qui touche à la sécurité du service.

  • Chaque plugin doit être censé disposer de son propre plan de mise à jour et être testé dans l’environnement de pré‑production avant déploiement en production.

4.6. Quelle est la fréquence des tests de restauration des sauvegardes ?

  • Mensuelle (au minimum).

  • Après chaque mise à jour majeure du core ou d’un plugin.

  • En cas d’incident majeur : le test doit être effectué immédiatement pour valider la capacité de reprise.

4.7. Le SLA prévoit‑il des pénalités en cas de non‑respect ?

  • Oui, généralement sous forme de credits ou de régénération de ressources (ex. : extension du temps de maintenance sans frais supplémentaires).

  • Les pénalités doivent être définies dans le contrat et communiquées aux parties prenantes dès le départ.

4.8. Comment garantir la confidentialité des données sauvegardées ?

  • Chiffrer les sauvegardes (AES‑256) avant de les transférer vers un stockage externe.

  • Restreindre l’accès aux dépôts de sauvegarde (IAM, ACL).

  • Vérifier la conformité du provider (RGPD, ISO 27001).

4.9. Les utilisateurs internes doivent‑ils suivre des règles de sécurité spécifiques ?

  • Oui. Chaque collaborateur doit :

    • Utiliser un mot de passe unique et fort.

    • Activer la 2FA.

    • Ne jamais partager ses identifiants.

    • Signaler immédiatement toute anomalie (ex. : login depuis une IP inconnue).

4.10. Quel est le RTO acceptable pour restaurer Dolibarr après une perte totale du serveur ?

  • En fonction du criticalité métier :

    • RTO ≤ 2 h pour les services opérationnels (ex. : point de vente, facturation).

    • RTO ≤ 4 h pour les environnements de test ou de reporting moins critiques.

5. Mettre les SLA en pratique – Étapes de pilotage

  1. Bibliographie SLA

    • Rédiger un Document de Service Level (PDF ou wiki) incluant les objectifs, KPIs, responsabilités et pénalités.

    • Le versionner (Git) pour garder l’historique des évolutions.

  2. Définir les outils de mesure

    • Installer Prometheus + Grafana pour la disponibilité et le temps de réponse.

    • Configurer Zabbix pour les alertes d’incident de sécurité.

    • Mettre en place Backup‑Monitor (script qui envoie un rapport de succès de sauvegarde chaque jour).

  3. Automatiser la collecte des tickets

    • Utiliser un système de ticketing (GitLab Issues, Jira Service Management) avec des SLA‑aware workflows.

    • Ajouter des champ “SLA critique” qui déclenche des notifications si dépassé.

  4. Former les équipes

    • Session d’onboarding sur la signification des KPI et les conséquences d’un dépassement.

    • Simulations d’incidents (drill) pour tester le MTTR.

  5. Effectuer un audit initial

    • Vérifier chaque KPI actuel (ex. : Uptime 99,2 % → nécessite amélioration).

    • Identifier les écarts et les plans d’action prioritaires.

  6. Piloter les revues mensuelles

    • Présenter le tableau de bord aux parties prenantes.

    • Mettre à jour les objectifs en fonction des nouvelles exigences (ex. : passage à 99,8 % de disponibilité).

  7. Améliorer continuellement

    • Intégrer les retours d’audits, les nouvelles vulnérabilités (ex. : CVE‑2024‑XXXXX).

    • Réviser les plugins chaque trimestre et mettre à jour le plan de patching.

6. Conclusion

La sécurité de Dolibarr ne peut être négligée lorsqu’on s’appuie sur cet ERP pour le cœur même de la gestion commerciale, financière ou logistique. Un SLA orienté sécurité fournit un cadre contractuel et opérationnel qui :

  • Quantifie les attentes (disponibilité, latence, temps de réponse aux incidents).

  • Gouverne les responsibilities entre les équipes techniques, la direction et les prestataires externes.

  • Facilite le pilotage grâce à des indicateurs mesurables et à une gouvernance basée sur les revues mensuelles.

  • Anti‑pâne les risques en imposant des délais stricts de mise à jour, de sauvegarde et de restauration.

En combinant des bonnes pratiques de durcissement avec un FAQ SLA structuré, vous transformerez votre instance Dolibarr en un service résilient, audité et aligné sur les exigences de conformité modernes.

À retenir : le SLA n’est pas un document figé ; il doit évoluer avec votre maturité de sécurité et les exigences métier. Le pilotage continu via des tableaux de bord et des revues structurées est la clef d’une amélioration durable.

Pour toute question supplémentaire ou pour obtenir un modèle de SLA personnalisable, n’hésitez pas à nous contacter via le formulaire « Support & SLA » de votre plateforme Dolibarr ou à rejoindre la communauté sur le forum officiel.

Auteur :
Équipe Sécurité & Gouvernance – Solutions Open‑Source
Novembre 2025

Publications similaires