Mettre à niveau Dolibarr : Make en 30 jours

Guide complet pour réaliser la transition vers la dernière version de Dolibarr sans surprise

1. Introduction

Dolibarr est un ERP/PGSI (Gestion Commerciale et Industrielle) open‑source très souple, mais comme tout logiciel, il évolue. Passer d’une version x à la version y implique souvent :

  • Des changements de structure de base de données

  • L’ajout ou la suppression de champs, de tables ou de fonctions

  • Des évolutions de compatibilité PHP / MySQL / MariaDB – Des modifications de fichiers de configuration ou de thèmes

Un upgrade mal préparé peut entraîner :

  • Des pertes de données

  • Une interruption prolongée du service – Des incompatibilités avec des modules tiers (ex. : paiement en ligne, messagerie)

C’est pourquoi nous vous proposons un plan d’action structuré sur 30 jours pour passer la main en toute sérénité, en limitant les risques et en maximisant la réussite.

2. Vision globale du projet en 30 jours

Phase Durée Objectif principal Livrable
1️⃣ Audit & diagnostic 5 jours Recenser l’environnement actuel (version Dolibarr, PHP, MySQL, modules installés) Rapport d’audit (PDF)
2️⃣ Plan de migration 3 jours Définir la feuille de route détaillée (backup, tests, déploiement) Plan projet (Gantt simplifié)
3️⃣ Sauvegarde & pré‑mise en place du rollback 3 jours Créer des sauvegardes fiables (DB + fichiers) et préparer un environnement de secours Backups + documentation de restauration
4️⃣ Environnement de test 5 jours Installer une version cible dans un environnement dédié et reproduire le catalogue de flux métier Instance de test fonctionnelle
5️⃣ Phase de tests fonctionnels 7 jours Vérifier chaque module clé (articles, devis/PO, factures, stocks, paiement…) Rapport de tests complet
6️⃣ Validation & certification 2 jours Obtenir le « go‑livrable » des parties prenantes (direction, compta, logistique) Sign‑off projet
7️⃣ Mise en production 3 jours Déployer la nouvelle version en production avec plan de bascule et monitoring Version en prod + plan de suivi
8️⃣ Suivi post‑déploiement 2 jours Vérifier la stabilité, analyser les incidents éventuels Rapport de clôture + recommandations

Total : 30 jours calendaires (ou 6 semaines de travail à plein temps).
Le planning ci‑dessus est bien sûr ajustable selon la taille de votre société et le nombre de modules activés.

3. Détail de chaque phase ### 3️⃣.1 Audit & diagnostic

Étape Action Outil / Ressource
1.1 Identifier la version installée ($DOL_DB_VERSION ou phpinfo) Interface d’administration Dolibarr
1.2 Recenser les extensions installées (ex. : dolibarr_pdf, dolibarr_llxPayPal) php -m / dossier htdocs/interfaces
1.3 Vérifier les dépendances serveur (PHP ≥ 7.4, MariaDB ≥ 10.3) php -v, mysql --version
1.4 Exporter la configuration actuelle ( dolibarr.conf ou php.ini personnalisé ) Sauvegarde du fichier conf/
1.5 Faire un inventaire des données (tables personnalisées, triggers, vues) Script SQL SELECT * FROM names; SHOW CREATE TABLE …

Livrable : Rapport d’audit (3 pages max) contenant les versions, les modules critiques, les points de friction potentiels.

2️⃣.2 Plan de migration

  • Créer un diagramme de Gantt (outil : Trello ou Asana) avec les dates cibles.

  • Prioriser les modules à tester en priorité selon l’usage métier.

  • Définir les fenêtres de coupure (ex. : dimanche soir pour la mise à jour).

  • Assigner les rôles :

    • Chef de projet (vous)

    • DBA (admin base)

    • Développeur (customisation)

    • Responsable QA (tests)

    • Support (post‑déploiement)

3️⃣.3 Sauvegarde & rollback

Type Méthode Fréquence
Base de données mysqldump -u root -p dolibarr > dolibarr_$(date +%F).sql Full + incrémentale (nightly)
Fichiers tar -czf /backup/dolibarr_$(date +%F).tgz htdocs/dolibar Avant toute modification
Configuration serveur Script ansible ou cron pour copier /etc/php/7.4/apache2/conf.d/* Vérifier les changements de version
Plan de rollback Documenter les étapes de restauration (ex. : restaurer DB + fichiers, redémarrer Apache) Tester sur l’environnement de test avant la phase 5

Astuce : Conservez 2 jours de sauvegarde incrémentale pour pouvoir revenir en arrière rapidement.

4️⃣.4 Environnement de test

  1. Provisionner un serveur dédié (VM ou conteneur LXC).

  2. Installer une stack compatible :

    • PHP 8.2 (ou la version requise par la nouvelle version de Dolibarr)

    • MySQL 10.6 ou MariaDB 10.5

    • Apache 2.4 ou Nginx + PHP‑FPM

  3. Cloner la base (mysqldump) et restorer dans le serveur de test.

  4. Déployer le code de la version cible dans /var/www/dolibarr-test.

  5. Vérifier les logs d’erreurs (error_log) dès le premier accès.

5️⃣.5 Phase de tests fonctionnels

Module clé Actions de test Critères d’acceptation
Articles / Catalogos Création, modification, import CSV, gestion des variantes Pas d’erreur 500, persistance des champs personnalisés
Devis & Commandes du fournisseur Génération d’un devis → commande → facture Liaison correcte avec la comptabilité (compte fournisseur)
Facturation Generation PDF, archivage, relances de paiement Export correct des données dans la base de facturation
Gestion des stocks Réception, mise à jour du niveau de stock, inventaire Recalcul exact des quantités et valuations (FIFO/LIFO)
Paiement en ligne (ex. : PayPal, Stripe) Simuler transaction et webhook Confirmation de paiement sans perte de commande
Authentification & SSO Test des comptes LDAP/Active Directory Aucun déclencheur d’erreur après migration

Méthode : Utilisez un check‑list markdown pour cocher chaque scenario validé.
Outils : Selenium, Postman (API), ou simplement les formulaires web.

6️⃣.6 Validation & certification

  • Réunion de revue avec les parties prenantes (direction comptable, logistique).

  • Signature du sign‑off sur le livrable « Dolibarr vX.Y en production ».

  • Documentation : guide d’utilisation de la nouvelle version, manuel de restauration rapide.

7️⃣.7 Mise en production

  1. Planifier la coupure (ex. : dimanche 22 h à 2 h du matin).

  2. Mettre le site en mode maintenance ($db->query('INSERT INTO systematicket ...'); ou page maintenance.html).

  3. Restaurer la dernière sauvegarde de la base de production dans le serveur cible.

  4. Déployer le nouveau code (git pull ou transfert SCP).

  5. Exécuter les scripts de migration de base de données (ex. : php upgrade.php si fourni).

  6. Vérifier les logs immédiatement après la remise en ligne.

  7. Monitorer le système pendant les 48 h suivantes (CPU, I/O, erreurs 5xx).

Points de vigilance : vérifier la présence du fichier dolibarr.conf personnalisé, les variables d’environnement (DB_HOST, DB_NAME), etc.

8️⃣.8 Suivi post‑déploiement – Rapport quotidien des incidents (tickets JIRA/OTRS).

  • Analyse des performances (temps de réponse avant/après).

  • Plan d’évolution (features nuevas, maintenance future).

4. Checklist rapide (à copier‑coller) « `

[ ] Audit complet (version, modules, dependencies) ☐
[ ] Sauvegarde DB + fichiers (full + incrémentale) ☐
[ ] Documentation du rollback ☐
[ ] Création d’un environnement de test isolé ☐
[ ] Deploiement de la version cible sur le test ☐
[ ] Tous les scénarios fonctionnels validés ☐
[ ] Sign‑off des parties prenantes ☐
[ ] Coupure prévue + maintenance page ☐
[ ] Migration DB + redémarrage services ☐[ ] Monitoring initial (30min, 1h, 24h) ☐
[ ] Rapport final + leçons apprises ☐


---
## 5. Bonnes pratiques & astuces  
| Situation | Astuce recommandée |

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

| **Modules personnalisés** | Créez un fork Git dédié, testez-le dans l’environnement de test avant de le réintégrer. |

| **Mise à jour de PHP** | Utilisez `php -l` pour vérifier les erreurs de syntaxe avant la migration. |

| **Changements de schéma** | Exécutez `php DolibarrUpgrade.php` **dans un terminal** pour suivre la progression ligne par ligne. |

| **Sauvegarde incrémentale** | Utilisez `mariabackup` ou `pg_dump` (si vous avez migré vers PostgreSQL) pour des sauvegardes rapides et restaurables. |

| **Tests automatisés** | Intégrez des scénarios Postman dans votre pipeline CI (GitHub Actions, GitLab CI). |

| **Communication** | Envoyez un **mail de mise à jour** chaque fin de phase aux parties prenantes pour garder tout le monde informé. |

| **Temps de latence** | Avant le go‑live, effectuez un test de charge (JMeter ou k6) pour s’assurer que la nouvelle version supporte le trafic prévu. |
---
## 6. Conclusion  
Passer à la **dernière version de Dolibarr** en suivant le **plan « Make en 30 jours »** vous garantit :
- **Sécurité des données** grâce à des sauvegardes structurées et à un rollback testé.  

- **Qualité fonctionnelle** grâce à des tests exhaustifs sur l’ensemble des processus métiers.  

- **Transparence** avec un planning partagé et une validation formelle par les parties prenantes.  

- **Continuité du service** avec une fenêtre de mise à jour planifiée et un monitoring immédiat.
En appliquant strictement chaque étape du calendrier, votre équipe pourra aborder la migration comme un projet **maîtrisé, prévisible et sans surprise**.  
Bonne migration ! 🚀  
---  
*À votre disposition pour adapter ce modèle à votre contexte spécifique, affiner le planning ou préparer les scripts de migration automatisés.*

Publications similaires