Version 1.0 – Novembre 2025
1. Introduction
Dolibarr est une solution ERP/CRM open‑source très appréciée des PME et des auto‑entrepreneurs pour sa simplicité d’utilisation et son extensibilité via modules et hooks.
Cependant, une mauvaise configuration ou une personnalisation approximative peut engendrer :
- Des fautes de saisie ou des doublons de données.
- Des processus métiers incomplets ou mal alignés avec la réalité quotidienne.
- Des failles de sécurité ou des pertes de performance.
Ce document propose une check‑list détaillée à suivre lors du déploiement de Dolibarr, afin de personnaliser l’outil tout en limitant les sources d’erreurs. Elle s’adresse aux équipes IT, aux consultants fonctionnels et aux responsables de projets de mise en production.
2. Principes de base avant toute personnalisation
| ✅ | Action | Pourquoi |
|---|---|---|
| 1 | Faire une analyse fonctionnelle exhaustive (processus achat, facturation, stocks, relances clients, etc.) | Clarifie les besoins réels et évite la sur‑personnalisation. |
| 2 | Installer la dernière version stable (ex. Dolibarr 24.x) sur un serveur isolé (sandbox) | Garantit la compatibilité avec les modules et les correctifs de sécurité. |
| 3 | Activer le mode « Debug » uniquement pendant les phases de configuration | Facilite la traçabilité des erreurs sans exposer de logs en production. |
| 4 | Sauvegarder la configuration initiale (base de données, répertoires, fichiers de configuration) | Permet de revenir à un état connu en cas d’incident. |
| 5 | Documenter les changements (version, date, auteur, impact) | Traçabilité et partage des connaissances au sein de l’équipe. |
3. Checklist de personnalisation – Étape par étape
3.1. Configuration de l’environnement | ✅ | Action | Référence Dolibarr / Code |
|—-|——–|—————————|
| 3.1.1 | Définir les paramètres PHP (memory_limit, max_execution_time, upload_max_filesize) pour éviter les dépassements lors d’imports massifs. | php.ini |
| 3.1.2 | Choisir le bon type de base de données (MySQL 8+, PostgreSQL 13+, ou SQLite pour les petites structures) et vérifier la collation (utf8mb4_unicode_ci). | install.php |
| 3.1.3 | Activer HTTPS (certificat valide) au niveau du serveur web (Apache/Nginx) avant d’activer les modules de paiement ou de signature électronique. | HTTPS |
| 3.1.4 | Limiter les droits d’accès : créer un user dédié avec uniquement les privilèges nécessaires (SELECT/INSERT/UPDATE). | MySQL user |
| 3.1.5 | Désactiver le mode display_errors en production et configurer les logs (error_log) vers un fichier sécurisé. | php.ini |
3.2. Paramétrage de Dolibarr core
| ✅ | Action | Champ / Module concerné | Astuce anti‑erreur |
|---|---|---|---|
| 3.2.1 | Activer les modules nécessaires (ex. Product, Stock, Invoice, Payment, Mail) via l’interface Modules → Setup → Modules → List. |
product, stock |
Ne pas cocher « All modules » ; sélectionner uniquement ceux réellement utilisés. |
| 3.2.2 | Configurer les bases de données de référence (prix catalogues, conditions de paiement, zones de livraison). | Setup → Parameters → Company |
Vérifier la cohérence des nomenclatures et des unités de mesure. |
| 3.2.3 | Définir une unité de compte unique (ex. Euro, Dollar) et désactiver les devises superflues. | Currencies |
Un seul code ISO actif évite les doublons de prix. |
| 3.2.4 | Configurer le système de paie (journal comptable par défaut, plan comptable). | Accounting → Chart of Accounts |
S’assurer que les comptes de charges/débit/credit sont correctement mappés. |
| 3.2.5 | Activer les hooks de synchronisation (ex. avec un CRM externe ou un ERP) seulement après validation du modèle de données. | Hook |
Tester les hooks en mode sandbox avant mise en production. |
3.3. Personnalisation des champs et des статуes
| ✅ | Action | Où le faire | Risque d’erreur si négligé |
|---|---|---|---|
| 3.3.1 | Ajouter ou modifier des champs (ex. numéro de lot, code couleur) via Setup → Custom fields. |
Custom fields |
Un champ ajouté sans validation de format peut créer des données incohérentes (ex. texte dans un champ numérique). |
| 3.3.2 | Définir des listes déroulantes propres (ex. statut de commande : En cours de préparation, Expédié, Annulé). | Lists → Liste de statuts |
Si la même valeur dupliquée existe déjà, le système peut confondre les états et générer des relances erronées. |
| 3.3.3 | Adapter les statuts de paiement (ex. Paiement en attente, Paiement accepté, Paiement refusé) et leurs notifications. | Payment → Statuses |
Une mauvaise séquence de statut peut passer à tort le paiement en « accepté » sans réellement vérifier le statut côté banque. |
| 3.3.4 | Faire des tests de validation (ex. un champ email doit respecter RFC 822). |
Fields validation |
Les messages d’erreur génériques masquent les causes racines. |
3.4. Gestion des flux de travail (workflow)
| ✅ | Action | Où le faire | Astuce pour éviter l’erreur |
|---|---|---|---|
| 3.4.1 | Définir les étapes de validation (ex. Devis → Validation → Facturation → Paiement). | Setup → Document types → Workflows |
Ignorer une étape de validation peut entraîner des factures émises avant que le client n’ait accepté le devis. |
| 3.4.2 | Configurer les actions automatisées (envoi de mail de rappel, mise à jour du stock). | Triggers → After order validated |
Négliger de tester les déclencheurs peut provoquer un envoi de mails multiples ou une augmentation du stock non désirée. |
| 3.4.3 | Mettre en place des seuils de stock et des alertes. | Stocks → Alerts |
Un seuil trop bas ou trop haut entraîne soit des ruptures de stock non anticipées, soit un sur‑stock inutile. |
| 3.4.4 | Test de scénario : simuler un cycle complet (commande → facture → paiement → livraison). | Environnement de test | Une erreur empoisonne le processus complet lorsqu’elle se reproduit en production. |
3.5. Intégrations externes (CRM, ERP, API, paiement)
| ✅ | Action | Points de vigilance |
|---|---|---|
| 3.5.1 | Exporter / importer des données CSV en utilisant le bouton Tools → Data et valider le mapping avant chaque import. | Vérifier les colonnes obligatoires, les unités de mesure, les séparateurs. |
| 3.5.2 | Activer la synchronisation avec un service de paiement (ex. PayPal, Stripe). | Tester en mode sandbox et s’assurer que les webhooks renvoient le statut correct. |
| 3.5.3 | Planifier les appels API (ex. mise à jour de contacts depuis un CRM) avec des tentatives limitées et un delai exponentiel. | Prévenir les boucles infinies ou les pannes de service. |
| 3.5.4 | Sauvegarder les clés API hors du répertoire public (ex. .env ou config.php hors web). |
Risque de fuite de credentials si mal protégé. |
| 3.5.5 | Mettre en place un système de monitoring des appels externes (status 200/500). | Les erreurs réseau non détectées causent des données manquantes. |
3.6. Tests et validation avant mise en production
| ✅ | Action | Pourquoi |
|---|---|---|
| 3.6.1 | Test fonctionnel : chaque scénario métier (ex. creation d’une facture récurrente). | Garantit que les règles métier fonctionnent comme prévu. |
| 3.6.2 | Test de charge : simuler plusieurs dizaines d’enregistrements simultanés (ex. import de 1000 fiches clients). | Vérifie les performances et évite les erreurs de timeout. |
| 3.6.3 | Test de sécurité : scanner les vulnérabilités OWASP (ex. XSS, SQL injection). | Évite les failles qui peuvent altérer les données. |
| 3.6.4 | Revue de code avec au moins un collègue qui n’a pas participé à la configuration. | Découvrir des biais de logique ou des oublis. |
| 3.6.5 | Sign-Off : obtenir l’accord écrit du business owner sur le périmètre fonctionnel validé. | Formalise la livraison et limite les changements post‑déploiement. |
4. Exemple complet de checklist (format PDF ou tableau partagé)
NOTE : Vous pouvez copier‑coller le tableau ci‑dessous dans votre outil de suivi (Jira, Trello, Asana). Marquez chaque case “Done” lorsque la tâche est terminée.
| # | Action | Responsable | Priorité | État | Commentaires |
|---|---|---|---|---|---|
| 1 | Analyse fonctionnelle complète | PO / BA | Haute | ☐ | Document #123 |
| 2 | Installation de Dolibarr 24.x en sandbox | Admin IT | Haute | ☐ | Version php 8.2 |
| 3 | Vérification des paramètres PHP | DevOps | Moyenne | ☐ | memory_limit = 512M |
| 4 | Création du compte DB dédié | DBA | Haute | ☐ | dolibarr_user |
| 5 | Activation du module Stock | Config. | Haute | ☐ | Sélection de l’unité en kg |
| 6 | Ajout du champ « Numéro de lot » | Admin | Moyenne | ☐ | Validation regex alphanumérique |
| 7 | Définition des statuts facturation | BA | Haute | ☐ | En attente → Payée |
| 8 | Configuration du workflow “Devis → Facture” | BA | Haute | ☐ | Alertes email paramétrées |
| 9 | Integration Stripe (sandbox) | Dev | Haute | ☐ | Webhook test OK |
| 10 | Test de bout en bout (commande réelle) | QA | Haute | ☐ | Stateless OK |
| … | … | … | … | … | … |
5. Bonnes pratiques pour pérenniser la réduction d’erreurs
- Documenter chaque changement dans un Change Log versionné (ex. Git).
- Mettre en place un processus de revue (pull‑request) pour tous les scripts de mise à jour ou les ajustements de configuration.
- Planifier une revue trimestrielle des procédures opérationnelles (procédures d’import, de backup, de restauration).
- Utiliser les environnements de pré‑production avant chaque mise à jour majeure – jamais directement en live.
- Former les utilisateurs finaux aux champs nouveaux et aux messages d’erreur afin d’éviter les saisies non conformes.
- Planifier les backups (daily + full weekly) et tester la restauration aléatoirement.
- Surveiller les logs via un outil (ELK, Graylog) et configurer des alertes sur des patterns d’erreur récurrents. —
6. Conclusion
La personnalisation de Dolibarr est un levier puissant pour aligner l’outil sur vos processus internes, à condition de la faire de manière structurée. En suivant la checklist ci‑dessus :
- Vous limitez les sources d’erreurs liées à la configuration.
- Vous sécurisez les intégrations externes et les échanges de données.
- Vous facilitez la maintenance et l’évolution future du système.
En résumé, la déploiement maîtrisé de Dolibarr repose sur trois piliers : analyse, validation et documentation. Appliquez la checklist à chaque étape, impliquez toutes les parties prenantes et vous disposerez d’une solution ERP/CRM fiable, robuste et prête à évoluer sans générer les bugs classiques qui freinent les projets de digitalisation.
Annexes (liens utiles)
| Ressource | Description |
|---|---|
| 📄 Guide d’installation officielle | https://github.com/Dolibarr/dolibarr |
| 🛡️ OWASP Top 10 – Application Security | https://owasp.org/www-project-top-ten/ |
| 📦 Docker‑compose template for Dolibarr | https://github.com/docker-md/dolibarr |
| 🔧 Hooks & API reference | https://docs.dolibarr.org/en/latest/modules/ |
| 🗂️ Modèles de workflow | https://github.com/Dolibarr/dolibarr/tree/master/sql/sql` |
Bonne implémentation ! 🚀