Sécurité Dolibarr : archivage Étude de cas pour passer à l’échelle

Un guide pratique pour les PME/ETI qui souhaitent exploiter Dolibarr en environnement critique tout en garantissant la conformité et la pérennité des données.

1. Pourquoi parler de sécurité et d’archivage dans Dolibarr ?

Dolibarr est un ERP/CRM open‑source très répandu parmi les petites et moyennes entreprises (PME) et les équipes qui souhaitent une solution modulable, sans licence propriétaire. Sa simplicité d’utilisation masque toutefois un besoin crucial : protéger les données sensibles (factures, contrats, contacts clients, informations comptables) et conserver les archives conformément aux exigences légales (RGPD, normes comptables, exigences fiscales).

Lorsque l’entreprise commence à croître, le volume des transactions augmente, les processus se complexifient et les exigences de traçabilité s’intensifient. La transition « de l’échelle locale à l’échelle organisationnelle » impose de repenser la sécurité et l’archivage dès la phase de conception.

2. Synthèse des exigences de sécurité dans un contexte d’échelle

Exigence Implication pour Dolibarr Bonnes pratiques
Confidentialité Accès restreint aux données personnelles et financières. – Gestion fine des rôles (RBAC)
– Authentification forte (2FA, SSO)
Intégrité Garantir que les enregistrements ne soient pas altérés. – Sauvegarde versionnée
– Journalisation (audit trail)
Disponibilité Accessibilité continue même en période de pic de trafic. – Load balancing, réplication DB, serveur de secours
Traçabilité Historisation des actions pour les audits internes/externes. – Log centralisé (ELK, Graylog)
– Signature numérique des factures
Conformité Respect du RGPD, du code général des impôts, etc. – Anonymisation / pseudonymisation
– Conservation légale des pièces justificatives (10 ans comptabilité)

3. Architecture recommandée pour passer à l’échelle

3.1. Séparation physique / logique des services

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

|   Front-end    |  HTTPS   |   API Gateway  |  HTTP    |   Backend      |

| (React/Bootstrap) | <-----> | (Node/NGINX)   | <-----> | (Dolibarr)    |

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

                                       |

                                       V

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

                                 |  Base de    |

                                 |  données    |

                                 |  (MySQL/PSQL)|

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

                                       |

                                       V

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

                                 |  Stockage   |

                                 |  d’archives |

                                 | (S3, MinIO)  |

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

  • Front‑end : Application web responsive (React, Vue ou le front natif de Dolibarr) avec TLS 1.3 obligatoire.

  • API Gateway : Authentification (OAuth2/OpenID Connect), contrôle du taux d’appel, limitation des requêtes.

  • Backend : Instance Dolibarr déployée en mode « multi‑tenant » si vous avez plusieurs filiales ou clients.

  • Base de données : Réplication en mode maître‑esclave, sauvegarde point‑in‑time (PITR).

  • Archivage : Stockage immuable des pièces justificatives (factures, contrats) dans un bucket S3 avec Object Lock ou via MinIO (mode “Governance”).

3.2. Sécurité au niveau de l’infrastructure

Niveau Action concrète
Réseau – Firewall / Security Group ouvrant uniquement les ports 80/443.
– VPN ou Private Subnet pour les appels internes à la DB.
Conteneurisation – Docker / Kubernetes avec Network Policies limitant la communication entre pods.
Gestion des secrets – Utilisation de Vault ou Kubernetes Secrets pour les mots de passe DB, clés API.
Mise à jour – Patch automatisé du noyau Docker/K8s et des modules PHP.
– Monitoring des CVE via outils comme Trivy.
Sauvegarde – Sauvegarde quotidienne incrémentale + full hebdomadaire.
– Conservation de 30 jours hors‑site (ex. : Glacier, Azure Blob).

4. Gestion de l’archivage dans Dolibarr

4.1. Types d’archives à conserver

Archive Durée légale (France) Format recommandé Méthode d’archivage
Factures (ventes) 10 ans PDF signé (XML ou PDF/A‑3) Stockage immuable S3, indexé dans Dolibarr
Factures d’achat 10 ans PDF Même procédé que ci‑dessus
Contrats clients/fournisseurs 5‑10 ans (selon type) PDF signé Dossier « Contracts » dans le bucket
Comptes annuels, bilans 10 ans PDF/Excel Archivage dans un répertoire versionné
Courriels / pièces jointes 5 ans PDF/HTML Export via le module « E‑mail » (archivage complet)

4.2. Processus automatisé d’archivage

  1. Déclencheur : Ajout ou modification d’un enregistrement « Facture » avec le statut payée ou validée.

  2. Export PDF : Utilisation du module Print Invoicing pour générer un PDF conforme (PDF/A‑3 inclut la signature numérique).

  3. Signature : Application d’une signature digitale via DocuSign, Adobe Sign ou SignRequest intégrée via API.

  4. Uploader : Le PDF signé est poussé dans le bucket S3 (ou MinIO) avec la clé suivante : archive/{client_id}/{annee}/{num_facture}.pdf.

  5. Métadonnées : Un enregistrement de type « Archive » est créé dans Dolibarr (table llx_files) pointant vers l’URL du fichier stocké. Ce champ est visible uniquement par les profils « Archiviste » ou « Comptable ».

  6. Vérification d’intégrité : Checksum (SHA‑256) enregistré dans la base pour chaque fichier (colonne sha256 dans llx_files).

  7. Planification : Un job cron quotidien s’assure que tous les dossiers générés sont ventilés correctement et que les quotas S3 ne sont pas dépassés.

Tip : Si vous avez besoin d’un archivage immuable (Object Lock), choisissez un bucket S3 avec la règle WORM (Write Once, Read Many) et activez la période de rétention (ex. : 7 ans). Ainsi, même un administrateur ne peut pas supprimer ou modifier les objets.

5. Étude de cas : Passage à l’échelle d’une PME de 50 collaborateurs

5.1. Contexte

  • Secteur : Distribution de pièces mécaniques.

  • Volume actuel : 2 500 factures/mois, 150 contrats actifs.

  • Outils : Dolibarr installé sur un serveur dédié (Ubuntu 22.04, PHP 8.2, MySQL 8.0).

  • Problèmes :

    • Goulots d’étranglement lors des pointes de facturation (début de mois).

    • Absence d’archivage structuré → perte de pièces justificatives lors d’un contrôle fiscal.

    • Gestion des droits d’accès « tout le monde peut tout voir » – besoin de différenciation.

5.2. Migration vers l’architecture évolutive

Étape Action Résultat
1. Analyse fonctionnelle Cartographie des processus (achat, vente, paiement). Identification de 3 flux critiques à sécuriser.
2. Refonte du front Migration vers un SPA (React) avec authentification via Keycloak (OAuth2). Séparation des rôles (Comptable, Manager, Lecteur).
3. Déploiement de l’infrastructure Passage à Kubernetes (3 nœuds) avec Ingress NGINX TLS‑termination. Haute disponibilité (99,9 %).
4. Sécurisation de la DB Réplication master‑slave + lecture‑only replica pour les rapports. Temps de requête réduit de 45 % pendant les pics.
5. Implémentation de l’archivage Création d’un bucket S3 « dolibarr‑archive‑2025 » avec Object Lock 10 ans. Toutes les factures sont désormais immuables et indexées.
6. Automatisation Script Python + Airflow qui :
• Génère le PDF/A‑3
• Ajoute la signature numérique
• Uploads vers S3
• Met à jour la table llx_files.		 Processus d’archivage complet < 30 s par facture.
7. Plan de continuité Backup quotidien chiffré et réplication vers un site distant (Azure). RTO < 4 h, RPO < 15 min.
8. Formation Sessions pour les équipes comptabilité & vente sur les nouveaux droits et le flux d’archivage. 100 % des utilisateurs certifiés « Archivage sécurisé ».

5.3. KPI post‑migration (6 mois)

KPI Avant Après Évolution
Temps moyen de génération d’une facture 7 min 2 min –71 %
Nombre d’erreurs de saisie facturation 3,2 % 0,4 % –87 %
Temps de récupération d’une facture archivée 12 min (recherche manuelle) 45 s (recherche par numéro) –96 %
Conformité au contrôle fiscal (audit) 85 % (documents manquants) 100 % (tous les PDF archivés) +15 %
Disponibilité du service ERP 97 % 99,9 % +2,9 %

6. Bonnes pratiques à retenir pour la mise à l’échelle

  1. Adopter le principe du moindre privilège

    • Chaque rôle (ex. : « Factureur », « Auditeur ») ne voit que les modules nécessaires.

    • Utilisez les permissions de Dolibarr ($user->rights) et les groups SSO pour filtrer les vues.

  2. Séparer les environnements

    • Dev → Test → Prod avec des bases de données distinctes.

    • Les sauvegardes de production ne doivent jamais être restaurées sur un environnement de test.

  3. Utiliser des formats d’archivage standardisés

    • PDF/A‑3 ou PDF/X‑4 pour la conformité légale.

    • Conservez les fichiers en objet immuable (WORM) dès le moment de la génération.

  4. Mettre en place un audit trail automatisé

    • Chaque modification d’un enregistrement doit créer une entrée dans la table llx_events ou un log centralisé (Syslog/ELK).

    • Exportez les logs d’audit chaque mois vers un référentiel sécurisé.

  5. Planifier la capacité de stockage

    • Estimez le volume mensuel de pièces (ex. : 2 500 factures × 0,2 Mo ≈ 500 Mo/mois).

    • Activez des alertes sur le bucket S3 (ex. : 80 % de la quota) pour éviter les dépassements imprévus.

  6. Tester régulièrement les scénarios de restauration

    • Simulez une perte de la base de données et restaurer à partir du dernier backup.

    • Vérifiez que les archives restaurées sont consultables (checksum cohérent).

  7. Suivre les évolutions légales

    • RGPD : anonimisation des données personnelles dans les exports.

    • Comptabilité : durée de conservation des pièces justificatives (10 ans).

    • Normes ISO 27001 / ISO 9001 si votre clientèle le requiert.

7. Checklist rapide pour un projet de mise à l’échelle

✅ Action
1 Auditer les droits d’accès actuels et les comparer aux besoins de séparation des rôles.
2 Déployer un serveur d’authentification central (Keycloak/OIDC).
3 Mettre en place un load balancer TLS + Ingress NGINX.
4 Configurer la réplication de la base de données et planifier les sauvegardes.
5 Créer un bucket S3 avec Object Lock et définir une politique de rétention (ex. : 10 ans).
6 Intégrer un moteur de génération de PDF/A‑3 + signature digitale.
7 Script d’automatisation du upload + métadonnées (Airflow / Cron).
8 Mettre en place le monitoring (Prometheus + Grafana) + alertes sur latence DB, utilisation du bucket.
9 Réaliser un test de restauration complet (DB + archives).
10 Former les équipes utilisateurs à la nouvelle interface et aux processus d’archivage.

8. Conclusion

La montée en échelle de Dolibarr ne doit pas être envisagée uniquement du point de vue fonctionnel ; la sécurité et l’archivage durable sont les piliers d’une solution pérenne. En suivant les bonnes pratiques présentées — authentification forte, séparation des services, archivage immuable, journalisation détaillée et automatisation du processus de sauvegarde—les organisations peuvent :

  • Réduire les risques de fuite ou de perte de données

  • Garantir la conformité légale (RGPD, fiscalité)

  • Assurer une disponibilité élevée même lors des pics d’activité

  • Faciliter la production d’audits sans effort manuel excessif

En adoptant cette architecture « cloud‑native » tout en conservant la simplicité d’utilisation de Dolibarr, les PME/ETI disposent d’une plateforme ERP/CRM prête à croître sans compromettre la sécurité ni la traçabilité des informations essentielles.

À retenir : chaque étape de l’évolution (addition de nouveaux modules, augmentation du volume de données, expansion géographique) doit être accompagnée d’une revue de la politique de sécurité et d’un test d’archivage. La discipline du « security‑by‑design » dès le départ évitera des refontes coûteuses plus tard.

Cet article est proposé à titre informatif. Pour toute implémentation spécifique, il est recommandé de consulter un architecte cloud certifié et/ou un consultant en conformité.

Publications similaires