Mettre à niveau Dolibarr : intégration orienté conformité

Version 2025 – Guide complet pour les équipes IT et les responsables de conformité

1. Introduction

Dolibarr est un ERP/CRM open‑source très répandu dans les PME et les associations. Sa modularité le rend attractif, mais lorsqu’il s’agit de conformité réglementaire (RGPD, ISO 27001,PCI‑DSS, normes comptables, etc.) les exigences deviennent plus strictes. Passer à une version récente de Dolibarr (ex. 16.x) ou migrer entre les branches majeures (5.0 → 6.0 → 7.0) est donc souvent une contrainte de conformité : il faut :

  • Garantir la continuité de la traçabilité des données sensibles.

  • Assurer la disponibilité d’un audit trail immuable. * Intégrer les contrôles de sécurité (authentification forte, chiffrement, journalisation).

  • Bénéficier des correctifs de vulnérabilités qui ne sont plus portés par les versions héritées.

Cet article détaille les lemons à anticiper, les bonnes pratiques d’intégration et le plan d’action pour réaliser une mise à niveau « orientée conformité ».

2. Étapes clés avant la mise à niveau | Objectif | Action concrète | Pourquoi c’est vital pour la conformité |

|———-|—————-|—————————————-|
| Auditer l’environnement actuel | – Listaire des modules activés (CRM, Facturation, Paiement, etc.).
– Recenser les données personnelles stockées. | Permet d’identifier les sources de données à protéger et les exigences de GDPR‑Article 30. |
| Planifier la feuille de route | – Définir un horizon de migration (ex. 3 mois).
– Assigner les rôles (Chef de projet, DPO, DSI). | Met en place un plan de continuité et un registre des traitements actualisé. |
| Tester en environnement de pré‑production | – Reproduire les flux métier (vente, paiement, stocks).
– Simuler des scénarios de panne et de récupération. | Garantit que les SLA de disponibilité et les procédures de reprise fonctionnent dans la version cible. |
| Définir les exigences de conformité | – Élaborer une checklist (RGPD, ISO 27001, PCI‑DSS, etc.).
– Prioriser les contrôles à vérifier post‑migration. | Crée un benchmark qui servira de référence pour les audits internes/externes. |
| Préparer le plan de sauvegarde | – Backup complet de la base de données (mysqldump, pg_dump).
– Export des fichiers de configuration (conf/, core/). | Un backup immuable est exigé par la plupart des standards de continuité d’activité. |

Tip conformité : Conservez les deux jeux de sauvegardes (avant et après migration) pendant au moins 12 mois, comme le requiert le GDPR Art. 30 et le ISO 27001 A.12.3.

3. Choix de la version et optimisation de l’infrastructure

Version recommandée Raison Points de conformité
Dolibarr 16.x (stable) Dernière version majeure avec support actif, amélioration du module de conformité RGPD (gestion des consentements, doublons, suppression sécurisée). • Boutons “Effacer les données personnelles” intégrés.
• Gestion fine des droits d’accès par profil (RBAC).
Dolibarr 20.x (future) Si possible, migrez directement vers la branche LTS prévue pour 2028, afin de profiter de la double‑chiffement des pièces jointes. • Support de la TLS 1.3 par défaut.
• API Rest OpenAPI 3.0 pour auditabilité.

3.1. Optimisation de l’infrastructure serveur

Composant Recommandation Impact conformité
Web server Apache 2.4+ ou Nginx 1.23+ avec HTTP/2 et TLS 1.3. Réduit la surface d’attaque, facilite le scanning de vulnérabilités (PCI‑DSS 3.1).
Base de données MariaDB 10.6+ ou PostgreSQL 15 (selon la distribution d’origine). Permet l’utilisation de chiffrement natif Transparent Data Encryption (TDE) (ISO 27001 A.10.1).
PHP ≥ 8.2 (avec OPcache et APCu pour la performance). Les versions récentes offrent des algorithmes cryptographiques modernes (libsodium).
Cache/Queue Utilisation de Redis ou RabbitMQ pour les files d’attente de paiement. Facilite la journalisation événementielle (audit trail).
SSL/TLS Certificat partagé avec OCSP stapling et HSTS. Conformité aux exigences de PCI‑DSS 3.2 (sécurisation des communications).

4. Intégration orientée conformité

4.1. Gestion du consentement et des droits d’accès

  1. Paramétrage du module RGPD (Menu → Administration → RGPD).

    • Activer l’anonymisation automatique des données inactives (défini par gdpr_anonymization_delay). – Configurer les formulaires de contact afin d’obtenir un champ “Consentement explicite”.

  2. Contrôles d’accès basés sur les rôles (RBAC) :

    • Créer des profils spécifiques (ex. “Comptable”, “Responsable Facturation”) avec des permissions granulares (lecture, écriture, suppression). – Documenter chaque rôle dans le Registre des traitements pour démontrer le principe du moindre privilège (GDPR Art. 5‑1(c)).

  3. Journalisation des actions critiques :

    • Activer le module Audit Log (audit_log table).

    • Exporter les logs quotidiennement vers un système SIEM (ex. ELK, Splunk).

    • Conserver les logs pendant au moins 12 mois et les protéger avec un hashage non réversible.

4.2. Sécurisation des échanges de paiement

Action Détails techniques Conformité
Utiliser le module PCI‑DSS (si vous traitez des cartes) – Activer le chiffrement SSL/TLS sur le formulaire de paiement.
– Désactiver le stockage des PAN (numéro de carte) en base → stockage uniquement du token ou masking.		 Réduction du scope PCI‑DSS à la simple transmission.
Intégrer un PSP certifié (ex. Stripe, PayPal, Adyen) – Appels API HTTPS avec OAuth 2.0.
– Utilisation de webhooks signés pour la validation des réponses.		 Garantit que le processeur de paiement supporte la conformité PSD2 et la SCA (Strong Customer Authentication).
Activer le module “Secure Payment” (Dolibarr ≥ 16) – Gestion du 3‑DS (3-D Secure) intégré.
– Logging des tentatives de paiement en échec.		 Aide à détecter les fraud attempts et à satisfaire les exigences de détection de fraude.

4.3. Gestion des documents et archivage légal

  1. Module “Documents” : – Configurer le préfixe de nom de fichier ([YYYYMMDD]_[client]_[type].pdf).

    • Paramétrer la durée de rétention en fonction des obligations légales (ex. 10 ans pour les factures).

  2. Archivage immuable :

    • Activer le mode “Read‑only” sur les dossiers d’archives (chmod 440).

    • Utiliser un hash SHA‑256 de chaque fichier et le stocker dans la table doc_pdf_log.

    • Cela satisfait les exigences de non‑répudiation et de tamper‑evidence (ISO 27001 A.9.2).

  3. Intégration d’un moteur de signature électronique (ex. DocuSign, Adobe Sign) : – Via API REST, envoyer les documents à signer, récupérer le certificat électronique.

    • Conserver le document signé dans la table signature avec le timestamp certifié (ex. TSA).

4.4. GDPR – Droit à l’oubli et portabilité

  • Endpoint REST : /dolibarr/api/v1/person/data?email=exemple@domain.com → renvoie toutes les données associées au client au format JSON‑LD (facilite la portabilité).

  • Script de purge automatisé (ex. cron 0 2 * * * /usr/local/bin/dolibarr_gdpr_purge.php) qui :

    1. Identifie les comptes inactifs (> 3 ans).

    2. Efface les enregistrements sensibles (DELETE FROMuser`), conserve uniquement les logs d’audit (hashés).

  • Notification au DPO : le script envoie un e‑mail avec le journal d’opération avant chaque purge.

5. Étapes détaillées de la migration

5.1. Phase de pré‑migration (0‑4 semaines) | Action | Commandes / Opérations | Responsable |

|——–|————————|————–|
| Sauvegarde complète | mysqldump -u root -p dolibarr > dolibarr_backup_$(date +%F).sql
tar czf backup_conf_$(date +%F).tar.gz conf/ | DBA |
| Export des rapports d’audit | SELECT * FROMauditlog` INTO OUTFILE ‘/tmp/audit$(date +%F).csv’` | Auditeur |
| Documentation des flux | Diagrammes BPMN des processus clés (ex. “Création devis → Validation → Facturation”). | BPM Analyst |
| Définir le périmètre | Lister les modules à désactiver temporairement (ex. modules “Bet” non utilisés). | Chef de projet |

5.2. Phase de migration (4‑8 semaines)

Étape Commandes / Opérations Points de conformité
Installation de la nouvelle version bash wget https://github.com/Dolibarr/dolibarr/archive/refs/tags/version-20.0.0.tar.gz
tar xzf version-20.0.0.tar.gz
cp -r dolibarr-version-20.0.0/* /var/www/html/dolibarr/		 Vérifier le hash du fichier (SHA‑256) pour éviter les compromis.
Application du patch de conformité Copier le fichier patch_gdpr_2025.patch et appliquer git apply. S’assure que les champs obligatoires (gdpr_consent_date) sont remplis.
Mise à jour de la base php update.php (ou php cli.php install selon la version). Doit être exécuté en mode maintenance pour éviter les écritures concurrentes.
Tests fonctionnels Utiliser les scénarios du “Plan de tests fonctionnels” (ex. création facture, paiement, archivage). Vérifier que les journaux d’audit sont correctement générés.
Tests de charge ab -n 1000 -c 50 http://dolibarr.local/... avec monitoring de la latence. S’assurer que les temps de réponse respectent le SLA prévu (ex. < 300 ms).

5.3. Phase post‑migration (8‑12 semaines)

Action Détails Conformité
Re‑audit des droits Re‑générer la matrice RBAC et la comparer à la version précédente. Garantir le principe du moindre privilège.
Migration du SIEM Rediriger les logs vers le nouveau endpoint https://siem.company.com/collector en TLS 1.3. Conserver la traçabilité lors de la bascule.
Documentation mise à jour Modifier le Registre des Traitements, le Plan de Continuité et le Plan de Réponse aux Incidents. Nécessaire pour la remise à jour de l’audit interne.
Test de reprise après sinistre Simuler une perte de la base de données et restaurer le backup précédent. Démontrer la conformité à ISO 22301 (gestion des continuity).
Formation utilisateurs Sessions de sensibilisation à la nouvelle interface de consentement RGPD. Renforcer l’acceptation du traité de confidentialité par les salariés.

6. Bonnes pratiques d’intégration continues

  1. Automatiser les séquences de mise à jour via CI/CD (GitLab CI, GitHub Actions). 
    # .gitlab-ci.yml snippet
    
migrate:
    
 stage: deploy
    
 script:
    
   - php update.php --dry-run   # vérifie les schémas
    
   - php upgrade.php             # applique les modifications
    
   - systemctl restart apache2   # redémarrage sans perte de session

  2. Utiliser les tests d’intégrité des données (php inspect.php) avant chaque déploiement.

  3. Planifier des revues trimestrielles de conformité (check‑list, audit interne).

  4. Mettre en place un tableau de bord de métriques (ex. nombre de demandes d’accès, incidents de sécurité, temps moyen de résolution).

7. Conclusion

La mise à niveau de Dolibarr n’est pas seulement un exercice technique ; elle constitue une action stratégique de gouvernance qui répond aux exigences légales et normatives actuelles (RGPD, ISO 27001, PCI‑DSS, etc.).

En suivant le processus détaillé ci‑dessus :

  • Vous assurez la continuité de votre activité tout en respectant les délais de rétention légaux.

  • Vous bénéficiez d’une architecture sécurisée (TLS 1.3, chiffrement natif, journalisation immuable).

  • Vous offrez aux utilisateurs une expérience conforme (gestion du consentement, droit à l’oubli, signature électronique).

  • Vous créez une base d’audit solide qui facilitera les futurs examens internes ou externes. > À retenir : la conformité n’est pas un état final, mais un cycle continu d’évaluation, d’ajustement et d’amélioration. La mise à niveau de Dolibarr constitue donc une excellente opportunité d’instaurer un cadre de gouvernance des données robuste et pérenne.

Annexes (exemples de scripts utiles)

A. Script de purge GDPR (bash‑php)

« `bash#!/usr/bin/env php
<?php
require_once(‘/var/www/html/dolibarr/core/lib/functions.php’);

$doublons = dol_sql_query("SELECT id FROM user WHERE lastlogin < ‘".(date(‘Y-m-d’, strtotime(‘-3 years’)))."’");
while ($row = dol_sql_fetch_array($doublons)) {
// Suppression sécurisée $params = array(‘id’ => $row[‘id’]);
dol_user_trash_recycle_bin($params[‘id’]); // envoie à la corbeille puis purge après 30 jours
// Log
$log = array(‘action’=>’gdpr_purge’,’user’=>$row[‘id’],’date’=>date(‘c’));
$log_id = dol_log(LOG_AUTO, ‘gdpr_purge’, $log);
}
echo "Purge terminée\n";
?>

#### B. Exemple de configuration Apache pour TLS 1.3 et HSTS

SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
SSLHonorCipherOrder on



#### C. Modèle de registre des traitements (extrait)  

| Traitement | Responsable | Finalité | Base légale | Destinataires | Durée de conservation |

|-----------|------------|----------|-------------|---------------|------------------------|

| Gestion des devis | Service Commercial | Élaboration de propositions commerciales | Consentement (Art. 6‑1‑a) | Aucun | 5 ans après clôture du devis |

| Paiement carte bancaire | Service Finance | Traitement des transactions | Exécution d’un contrat (Art. 6‑1‑b) | PSP, Autorité fiscale | 10 ans (exigence fiscale) |
---
*Document rédigé le 3 novembre 2025 – à jour selon les dernières versions de Dolibarr (20.x) et les exigences de conformité 2025.*

Publications similaires