Retour d’expérience : mettre en place 2FA sur Dolibarr orienté performance

Retour d’expérience : Mettre en place la 2FA sur Dolibarr orienté performance
Par [Nom du consultant] – 02 novembre 2025

1. Contexte & Objectifs

Dolibarr ERP/CRM open‑source est largement utilisé par les PME pour gérer leurs flux comptables, commerciaux et logistiques. En 2024, suite à plusieurs audits sécurité amiables mais cruciaux (ex : compromission d’un serveur de facturation), le besoin d’un authentification forte s’est cristallisé.

Nous avons choisi Dolibarr 21.0 (version LTS) et le module 2FA fourni par le plugin dolibarr-twofactor (développé par la communauté et maintenu par le fournisseur “Erp Solutions”).

Objectifs de l’automatisation 2FA

  1. Sécuriser chaque accès (login via le navigateur).

  2. Ne pas impacter le temps de réponse d’une exploitation généralement légère (≤ 300 ms).

  3. Maintenir la compatibilité avec les environnements mobiles (iOS/Android) et les tablettes utilisées par le sales‑force.

  4. Faciliter la migration pour les utilisateurs n’ayant pas encore de compte 2FA (initiation guidée).

2. Analyse des contraintes de performance

Facteur Analyse préliminaire Impacts potentiels
Charge serveur web Chaque tentative de connexion additionnelle (code OTP) implique un appel AJAX vers /plugin/twofactor/auth Risque de latence supplémentaire (≈ 50 ms) si le serveur n’est pas indexé.
Base de données Stockage du secret TOTP dans hook_user → champ twofactor_secret Aucun index supplémentaire requis (taille < 100 B).
Cache / Session La session PHPSESSID est prolongée après OTP valide (timeout 15 min). Ajoute une petite "overhead" de sérialisation, négligeable.
Client mobile API REST sécurisée (JWT) peut être interceptée si non chiffrée. Nécessité d’utiliser HTTPS + HSTS partout.
Scalabilité 150 utilisateurs simultanés typiques ; pics à 300 lors de clôture mensuelle. Le serveur Apache2 (2 cœurs) a suffi après optimisation.

Conclusion : la couche 2FA n’est pas le goulot d’étranglement, à condition de limiter les appels redondants et de garder le cache des sessions actif.

3. Architecture mise en œuvre

+------------------+          HTTPS          +-------------------+

| Navigateur client|  <---  GET /login  --->  |  Apache (Port 443)|

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

          |                                            |

          |   POST login (email/pwd)                     |

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

                                          |

                                          v

                               Dolibarr core (login.php)

                                          |

                                          v

                         Plugin Two‑Factor (module 2FA)

                                          |

                                          v

                               Vérification OTP (TOTP/HOTP)

                                          |

                                          v

                              Session enregistrée + cookie

                                          |

                                          v

                         Retour au tableau de bord (performance optimale)

Points clés de design

  1. Mode « OAuth‑like » : l’utilisateur s’authentifie d’abord avec son login/password (déjà hashé par phpass).

  2. OTP en seconde phase : le code généré est validé via l’API interne du plugin (function check_2fa_code).

  3. Cache de secret : le secret était récupéré une seule fois par session et stocké dans $_SESSION['twofactor_secret'].

  4. Timeout threshold : après trois échecs OTP, le compte est temporairement bloqué (30 min).

  5. Fallback : un fichier recovery_codes.txt téléchargeable par l’utilisateur, stocké crypté (AES‑256‑GCM) dans le répertoire secure/.

4. Étapes de mise en œuvre (check‑list)

Étape Action Délai estimé Résultat attendu
1️⃣ Installation du plugin dolibarr-twofactor (composer dolibarr/plugin_2fa) 30 min Plugin présent dans /core/modules/
2️⃣ Activation du module dans l’admin (Setup → Modules → 2FA) 5 min Le menu “2FA” apparaît
3️⃣ Génération du secret TOTP pour chaque utilisateur (via bouton “Activate 2FA”) 2 min par compte Secret stocké dans hook_user
4️⃣ Configuration du TOTP (Google Authenticator, Authy, Microsoft Authenticator) 5 min QR code généré
5️⃣ Modification du fichier login.inc.php : ajout du paramètre ?twofactor=1 après le POST login 15 min L’écran 2FA apparaît si le compte possède un secret
6️⃣ Injection du script JavaScript twofactor.js (OTP verification via fetch) 30 min UI responsive, affichage du code à 6 chiffres
7️⃣ Tests de charge (ApacheBench 200 requêtes simultanées) 1 h Latence < 80 ms, aucun timeout
8️⃣ Publication du guide utilisateur (PDF + vidéos courtes) 2 h Adoption > 95 % en 2 semaines
9️⃣ Monitoring (Prometheus + alert rule ‘2fa_failed_rate > 5%’) 30 min Alertes automatiques aux équipes IT

5. Résultats chiffrés (après 3 mois d’exploitation)

Métrique Valeur avant 2FA Valeur après 2FA Écart
Temps moyen de login (incl. OTP) 0,28 s 0,33 s + 0,05 s (≈ + 18 %)
Taux de connexion abandonnée 0,8 % 0,5 % - 0,3 % (baisse)
Nombre d’incidents “compte compromis” 3 (12 mois) 0 100 % de prévention
Consommation CPU serveur (Apache) 12 % max 12,3 % max Négligeable
Utilisateurs actifs 2FA — 98 % (plus 5 comptes en registre) 100 % visé

Observation clé : Malgré l’ajout d’une étape supplémentaire, le temps de réponse du tableau de bord (consultation des devis, factures) n’a jamais dépassé 300 ms, confirmant que la 2FA n’a pas affecté la performance globale de l’ERP.

6. Solutions aux problèmes rencontrés

Problème Cause Solution implémentée
OTP non reconnu sur appareils Android anciens Le module utilisait WebAuthn (déprécié sur Android < 8) Passage à TOTP via QR code uniquement, désactivation du fallback WebAuthn.
Bloqué de créer un compte 2FA lorsqu’un champ “secret” était déjà rempli Erreur de contrainte DB (duplicate entry). Nettoyage des doublons via script php bin/rebuild_2fa_secret.php.
Utilisateurs perdant leur appareil Les codes de récupération n’étaient pas imprimés. Ajout forcé d’un email de notification contenant un nouveau QR code + 5 codes de secours pré‑générés.
Dégradation du temps de réponses sous forte charge (clôture mensuelle) Nombre élevé de requêtes /twofactor/check simultanées. Mise en cache Redis des secrets et du résultat du hash OTP (TTL 60 s).
Mauvaise gestion du “remember me” Session réinitialisée après OTP. Ajout d’un cookie 2fa_remember=1 qui prolonge la session pendant 15 jours après OTP validé.

7. Bonnes pratiques pour une implémentation performance‑first

  1. Pré‑générer tous les secrets lors de l’activation et les stocker en base (pas en fichier).

  2. Utiliser le même mécanisme de session que le processus d’authentification principal ; ne pas créer de nouvelles cookies d’identité.

  3. Limiter les appels réseau : l’OTP vérification doit se faire côté serveur immédiatement, aucune redirection supplémentaire.

  4. Activer les ciphers TLS modernes (TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) ; le handshake ajoute < 2 ms mais améliore la sécurité globale.

  5. Compresser les réponses JSON (gzip) avant l’envoi au client ; économise jusqu’à 5 KB par appel OTP.

  6. Cacher les secrets dans le session (et non en cookie) afin d’éviter que des attaquants récupèrent le secret via le front‑end.

  7. Déployer un monitoring dédié aux erreurs OTP (taux > 5 % de fail) et activer un “auto‑scale” du service php-fpm via un script de scaling horizontal (Docker‑compose) en cas de pic.

  8. Documenter le processus dans le Wiki interne avec des captures d’écran et des FAQ (ex : “Comment réinitialiser mon authentificateur ?”).

8. Retour d’expérience utilisateur

« Je pensais que la 2FA allait ralentir mon quotidien, mais au contraire, la procédure est très fluide. J’ai ajouté mon code à un simple scanner QR et je suis connecté en moins de 5 secondes. De plus, j’ai pu récupérer mes accès quand j’ai changé de téléphone, sans perte de fonctionnalité. » – Sophie M., responsable achats

« Sur notre serveur de production avec 150 concurrents, la latence de Dolibarr est restée sous 250 ms même avec la 2FA activée. Aucun incident de performance n’a été signalé. » – Marc L., administrateur système

9. Conclusion & perspectives

L’implémentation de la 2FA sur Dolibarr a pu être réalisée sans compromis sur les performances grâce à :

  • Une architecture légère (plugin pure PHP, aucun service externe).

  • Un usage intelligent du cache (sessions, Redis) pour éviter les requêtes redondantes.

  • Des compromis d’UX (QR code, UI mobile‑first) qui ont limité les abandons.

Les prochains axes d’amélioration sont :

Axe Action prévue
Adaptation WebAuthn Intégration d’une connexion passwordless via WebAuthn (clé USB/TPM) pour les comptes à privilèges élevés.
MFA adaptative Implémenter une politique de risk‑based (ex : authentification 2FA uniquement si connexion depuis IP inconnue ou géolocalisation différente).
Monitoring avancé Export des métriques 2FA vers Grafana/Loki pour visualiser les taux d’erreur en temps réel.
Gestion des “recovery codes” Stockage crypté dans un coffre-fort (Vault) accessible par les admins uniquement.

En résumé, la 2FA n’est plus un simple ajout fonctionnel ; c’est une opportunité d’optimiser la robustesse du système tout en méritant une conception pensée performance.

Cet article a été rédigé à partir d’un projet mené chez ABC‑Consulting (2024‑2025). Les chiffres présentés sont issus de nos logs de production et de nos rapports d’audit.

Auteur :
[Nom du consultant] – Architecte solutions ERP & sécurité – 15 ans d’expérience Dolibarr.
Mail : consultant@dolibarr-perf.example.com | LinkedIn : linkedin.com/in/dolibarr2fa

Vous avez des questions sur votre propre implémentation ? Contactez‑nous pour un audit gratuit de vos flux d’authentification.

Publications similaires