Architecture Dolibarr : multi-devise avec une approche sécurité

Architecture Dolibarr : Multi‑devises avec une approche sécurité

Une présentation détaillée pour les équipes IT et les décideurs qui souhaitent exploiter la solution ERP‑CRM open‑source Dolibarr dans un contexte international tout en garantissant la meilleure protection des données.

1. Introduction

Dolibarr est un ERP (Enterprise Resource Planning) et CRM (Customer Relationship Management) à source ouverte, particulièrement apprécié des PME et des petites entreprises pour sa simplicité d’installation et son extensibilité. L’un de ses atouts majeurs est la prise en charge native de plusieurs devises (multi‑currency), ce qui le rend idéal pour les entreprises opérant dans plusieurs pays ou commercialisant leurs produits à l’international.

Cependant, chaque avantage technique s’accompagne d’un enjeu de sécurité : les transactions financières, les données bancaires et les informations clients sont sensibles et doivent être protégées contre les accès non autorisés, les altérations et les fuites.

Cet article décrit :

  1. L’architecture interne de Dolibarr lorsqu’on utilise plusieurs devises.

  2. Les bonnes pratiques de sécurité spécifiques à cette configuration.

  3. Des recommandations pour les administrateurs et les développeurs afin de renforcer l’ensemble du système.

2. Architecture de Dolibarr en mode multi‑devise

2.1. Modélisation des devises

Élément Description Stockage
Liste des devises Table lg_cc répertorie toutes les devises activées (code ISO‑4217, symbole, taux de change moyen). Base de données (MySQL/PostgreSQL/SQLite).
Unité monétaire Chaque catégorie (produits, comptes bancaires, factures, devis…) possède un champ currency indiquant la devise utilisée. Champ currency de chaque table dédiée (ex. llx_product, llx_invoice).
Taux de change Les conversions se font en temps réel via les taux configurés dans llx_cprice ou llx_currency_rate. Table llx_currency_rate (historique des taux).
Conversion dynamique Les calculs sont effectués par les fonctions convert_price(), convert_amount() qui utilisent les tables de taux pour garantir la cohérence des montants dans la devise de référence de l’entreprise. Fonctions PHP incluses dans include/erp_invoice.class.php, etc.

Schéma simplifié 

 Utilisateur → UI (FR/EN/etc.) → Choix devise → Sélection du taux → Calcul → Enregistrement (stocker montant dans devise source + devise cible)

2.2. Gestion des mouvements financiers

  1. Création d’un document (ex. facture)

    • L’utilisateur indique le montant en devise sélectionnée (ex. € 150).

    • Dolibarr récupère le taux de change du jour (ou du jour de la facturation) depuis llx_currency_rate.

    • Le montant est converti en devise de référence de la société (souvent EUR) et stocké dans la base.

    • Le champ multi‑devise (currency) conserve la valeur originale pour affichage et audit.

  2. Opérations de paiement

    • Lorsqu’un paiement est reçu en devise différente (ex. $ 200), Dolibarr ajuste le solde en utilisant le taux du jour du paiement.

    • Les différences de conversion (gain ou perte) sont automatiquement journalisées dans le compte de variation de change.

  3. Rapports financiers

    • Les rapports de comptabilité affichent les totaux à la fois en devise locale et en devises étrangères, en s’appuyant sur la table de conversion historisée.

    • Les exports (CSV, Excel, PDF) permettent de choisir la devise de sortie, ce qui évite les incohérences lors de la transmission à des partenaires.

2.3. Sécurité intégrée à l’architecture

Couche Points de vigilance Mesures par défaut
Accès aux données Lecture/écriture directe via SQL Authentification via la table llx_user. Chaque requête PHP vérifie la session et les droits ($user->id).
Gestion des conversions Risque d’injection si les taux ne sont pas validés Taux stockés dans llx_currency_rate via des écritures protégées ; aucune saisie brute utilisateur directe.
Affichage Risque d’exposition de valeurs sensibles dans les logs Les champs monétaires sont formatés et les logs utilisent des masques (ex. *****).
Export Export CSV peut contenir des données brutes Les fonctions d’export filtrent les colonnes sensibles et appliquent des contrôles d’accès (ex. droit export_csv).

3. Approche sécurité spécifique aux données monétaires

La multi‑devise implique la manipulation de montants stockés dans plusieurs devises. Chaque montant possède deux attributs : la valeur et la devise. La perte ou la modification non autorisée de ces champs peut entraîner :

  • Des erreurs de facturation (sur‑ou sous‑facturation).

  • Des pertes financières (ex. mauvaise gestion des variations de change).

  • Des fuites de données (ex. export de comptes bancaires avec leurs soldes).

Voici les principaux risques et les contre‑mesures recommandées :

3.1. Contrôles d’accès granulaire

Type d’accès Exemple Implémentation Dolibarr
Vue Visualiser les soldes bancaires Permissions view_accounts.
Modification Changer un montant ou un taux de change Droits edit_currency, edit_price.
Exportation Télécharger les états financiers Permission export_csv, export_pdf.
Administration Configurer les devises autorisées Droits réservés au groupe admin.

Bonne pratique : Créer des profils d’utilisateur personnalisés (ex. Comptable_ToutDevise, Gestionnaire_Clients) afin de limiter les droits selon les besoins métiers.

3.2. Chiffrement des communications

  • HTTPS obligatoire sur toutes les interfaces (frontend et backend).

  • Activation du mode ssl dans la configuration serveur Apache/Nginx.

  • Utilisation de cryptages forts (TLS 1.3) pour les échanges API ou les web‑hooks (ex. notifications de paiement).

  • Si Dolibarr est déployé derrière un reverse proxy, le protocole X-Forwarded-Proto doit être validé pour éviter les redirections non sécurisées.

3.3. Protection contre les attaques classiques

Menace Mise en œuvre
Injection SQL Utilisation du propriété‑paramètre ($db->query(...)) qui échappe automatiquement les paramètres. Toujours éviter la concaténation directe d’interpolations dans les requêtes.
Cross‑Site Scripting (XSS) Les champs monétaires sont affichés via les fonctions htmlentities() ou htmlspecialchars() dans les templates. Aucun code natif n’est autorisé dans les entrées.
Cross‑Site Request Forgery (CSRF) Dolibarr intègre le token $(session_token) dans chaque formulaire. Les actions POST doivent inclure ce token ; il est vérifié côté serveur.
Forced Browse Les fichiers de configuration (conf.php, inc.php) sont protégés hors du répertoire web (/public_html/dolibarr/).

3.4. Gestion des états de conversion (caches)

  • Les taux de change sont stockés avec horodatage et versionnés.

  • Un journal d’audit (table llx_currency_audit) consigne chaque modification (qui, quand, ancien taux, nouveau taux).

  • En cas de désaccord ou de suspicion de manipulation, il est possible de reconstituer le historique complet et d’alerter l’administrateur.

3.5. Sauvegarde et restauration sécurisées

  • Sauvegarde chiffrée (ex. via mysqldump --encrypt) des bases contenant les devises et les transactions.

  • Les sauvegardes sont conservées selon une politique 3‑2‑1 (3 copies, 2 supports différents, 1 hors‑site chiffré).

  • Tests périodiques de restauration afin de s’assurer que les tables multi‑devise restent cohérentes.

4. Scénario d’implémentation « Multi‑devise sécurisée »

4.1. Étapes de mise en place

  1. Définir le périmètre

    • Identifier les pays et les devises requises.

    • Choisir la devise de référence de l’entreprise (ex. EUR).

  2. Activer les devises 

    php -r '$_CONFIG["main_url"] = "https://exemple.com/dolibarr"; require_once "core/library/dolibarr_func.lib.php"; require_once "mes_func_lib.inc.php";'
    
php -r ' dolibarr_add_currency("USD"); dolibarr_add_currency("GBP");'   # via le script d’admin

  3. Configurer les taux de change

    • Dans le menu Administration → Devise → Taux de change, saisir les taux ou activer la récupération automatique via un service externe (ex. European Central Bank).

  4. Attribuer les rôles

    • Créer un groupe Comptable_Devise avec droits limité à view_invoice, edit_currency_rate.

    • Assigner les utilisateurs concernés au groupe via Administration → Utilisateurs → Groupes.

  5. Restreindre les accès aux tables

    • Vérifier que les fichiers htdocs/core/tables/ sont protégés (chmod 640).

    • Désactiver l’accès direct aux scripts PHP de configuration (conf/*.php) via la configuration Apache (<Directory "…/core"> deny from all </Directory>).

  6. Activer TLS et headers de sécurité 

    SSLProtocol all -SSLv3
    
SSLCipherSuite HIGH:!aNULL:!MD5
    
Header always set X-Content-Type-Options "nosniff"
    
Header always set X-Frame-Options "SAMEORIGIN"
    
Header always set Content-Security-Policy "default-src 'self' https: data: 'unsafe-inline';"

  7. Plan de sauvegarde

    • Planifier une sauvegarde nocturne chiffrée avec gpg et la conserver sur un stockage hors‑site.

  8. Tests de pénétration

    • Utiliser OWASP ZAP ou Burp Suite pour vérifier l’absence de XSS, CSRF et d’injection.

    • Tester la robustesse des conversions en injectant des taux de change fictifs et en observant le comportement du système.

4.2. Diagramme simplifié du flux d’une facture multi‑devise

[Utilisateur] --> [Formulaire Facture] --> Choix devise (ex. USD)

                              |

                              v

[Dolibarr] --> Récupération taux du jour (Table llx_currency_rate)

                              |

                              v

Conversion → Montant (USD) ↔ Montant (EUR de référence)

                              |

                              v

Enregistrement de la facture → llx_invoice (currency = USD)

                              |

                              v

Journalisation de l'opération → llx_currency_audit (who, when, old_rate, new_rate)

                              |

                              v

Affichage sécurisé → UI (HTML escappe, token CSRF)

5. Recommandations et bonnes pratiques résumées

Domaine Action clé Pourquoi
Gestion des devises Limiter le nombre de devises actives à celles réellement utilisées. Réduit la surface d’attaque et évite les incohérences de taux.
Taux de change Utiliser un service de mise à jour automatisée (ex. ECB, Open Exchange Rates). Garantit l’exactitude des conversions et centralise le point de mise à jour.
Contrôle d’accès Implémenter des profils utilisateurs basés sur les besoins (ex. « Comptable », « Manager »). Empêche les modifications non autorisées des montants et des taux.
Chiffrement Forcer HTTPS, activer HSTS, désactiver les protocoles obsolètes. Protéger les données en transit contre l’interception.
Audit Conserver un journal des changements de taux (llx_currency_audit). Facilite la traçabilité en cas d’anomalie ou de fraude.
Sauvegarde Sauvegarder les bases de données avec chiffrement et conserver au moins 3 copies (local + hors‑site). Garantir la disponibilité et l’intégrité des données financières.
Tests de sécurité Réaliser un audit annuel (scanner de vulnérabilités, tests de pénétration). Anticiper et corriger les failles avant qu’elles ne soient exploitées.
Mise à jour Appliquer régulièrement les correctifs de sécurité de Dolibarr (version ≥ 9.0). Réduire les vulnérabilités connues.
Documentation Tenir à jour le manuel interne sur les processus de conversion et de validation des montants. Facilite la formation et la conformité aux exigences comptables/audit.

6. Conclusion

Dolibarr offre une solution souple et économique pour gérer des opérations multi‑devises, mais cette flexibilité impose une vigilance accrue en matière de sécurité. En tirant parti de :

  • La modélisation centralisée des taux et des conversions,

  • Les contrôles d’accès granularisés,

  • Le chiffrement TLS et les politiques de sauvegarde,

les organisations peuvent exploiter pleinement les capacités de Dolibarr tout en protégeant leurs flux financiers contre les erreurs humaines, les attaques informatiques et les fraudes.

Adopter une approche « security‑by‑design » dès la configuration initiale permet de garantir que chaque facture, devis ou relevé bancaire généré dans plusieurs devises reste intègre, traçable et conforme aux exigences légales et comptables modernes.

En résumé : la sécurité d’une architecture Dolibarr multi‑devise repose sur une combinaison judicieuse de gestion rigoureuse des données monétaires, contrôles d’accès stricts, communication chiffrée et surveillance continue. En suivant les recommandations présentées, les équipes IT peuvent transformer un simple ERP open‑source en une plateforme financière fiable et résiliente, prête à soutenir la croissance internationale de l’entreprise.

Auteur :
Développeur ERP‑CRM open‑source | Spécialiste en sécurité des systèmes d’information

Date : 3 novembre 2025

Publications similaires