Vous venez de reprendre une PME, ou votre équipe IT part à la retraite : vous découvrez un Dolibarr installé depuis 5 ans, des modules maison oubliés, des données hétérogènes, des sauvegardes qui datent. C'est une situation courante, souvent stressante. Avant de décider une refonte coûteuse, il existe une stratégie pragmatique pour reprendre un projet Dolibarr legacy sans partir de zéro.

Auditer avant de décider

La première erreur est de crier au catastrophe. Un Dolibarr « legacy » n'est pas forcément pourri : c'est souvent simplement une instance qui a grandi sans documentation. Commencez par trois jours d'audit méthodique :

  • État de la base de données : volume, intégrité, tables orphelines, données mal formatées. Un script SQL d'audit suffit.
  • Modules installés et actifs : listez ce qui tourne vraiment, ce qui dort, ce qui est cassé. Beaucoup de modules « legacy » ne sont jamais désinstallés.
  • Intégrations externes : quels outils parlent avec Dolibarr ? (compta, CRM, paie, logistique). Ces connexions définissent vos vrais contraintes de migration.
  • Performance réelle : quelle est la charge ? Les requêtes SQL sont-elles optimisées ou chaotiques ?
  • Infrastructure sous-jacente : version PHP, version Dolibarr, serveur, SSL, sauvegardes. Cela fixe votre plafond technique.

Cet audit doit documenter ce qui fonctionne vraiment et être hiérarchisé : problèmes bloquants vs. améliorations cosmétiques.

Stabiliser sans refondre

Une fois le diagnostic posé, ne lancez pas immédiatement une refonte à 100 k€. Stabilisez d'abord :

Mettre à jour avec prudence

Si Dolibarr est sur v10 et vous êtes en v19, ne jumpez pas en 3 fois. Faites une montée de version progressive : v10 → v13 → v16 → v19, en testant chaque étape sur une copie. Les modules legacy cassent souvent aux updates majeures, mais vous le verrez avant de toucher la prod.

Nettoyer la base sans perte

Identifiez les tables parasites et les enregistrements orphelins. Créez une archive complète avant toute suppression. Un nettoyage simple peut réduire le temps d'exécution des requêtes de 30 %.

Documenter l'existant

Écrivez un runbook : liste des tâches cron, noms des modules custom, point de contact pour les intégrations, procédures de sauvegarde. Cela prend 2 jours et sauve votre équipe en cas d'urgence.

Améliorer progressivement

Avec une base stable, vous pouvez maintenant ajouter de la valeur sans détruire :

Quand envisager une refonte partielle

Trois situations justifient vraiment une refonte, pas avant :

  1. Modules custom trop nombreux ou non maintenables : si 40 % de votre Dolibarr est du code maison et que personne ne sait le lire, une refonte vers un SaaS spécialisé ou une architecture modulaire peut avoir du sens.
  2. Passage à multi-tenant obligatoire : si vous vendez Dolibarr à vos clients, passer du monolithe mono-client à une architecture SaaS demande une réécriture (mais c'est un business case, pas un problème technique).
  3. Pas de continuité opérationnelle : s'il n'existe aucune sauvegarde, aucune documentation, aucun responsable technique, et que l'instance a 8 ans, une refonte peut être justifiée pour réduire le risque futur.

Sinon, investissez progressivement. Un Dolibarr legacy bien repris dure encore 3–5 ans sans problème.

Le rôle du développement sur mesure

Un bon prestataire ne doit pas vous vendre une refonte. Il doit vous proposer un audit honnête, puis des micro-améliorations (briques de scripts d'automatisation, ajout de modules, correction de bugs, documentation). C'est moins valorisé commercialement qu'une grosse refonte, mais c'est souvent ce que vous vraiment besoin.

Conclusion : l'approche par étapes

Reprendre un Dolibarr legacy n'est pas une urgence absolue. Commencez par auditer, stabiliser, puis améliorer progressivement. Vous économiserez des dizaines de milliers d'euros et conserverez vos données historiques. Si vous avez besoin d'aide pour diagnostiquer ou reprendre votre instance, nous pouvons faire un audit ensemble.

FAQ

Questions fréquentes

Entre 2 000 et 5 000 € pour 3 à 5 jours de travail, selon la complexité. C'est 10 fois moins qu'une refonte et cela vous épargne des erreurs coûteuses. L'audit doit vous dire clairement s'il faut refondre ou non.

Non, mais vous pouvez monter de version progressivement (v10 → v13 → v16 → v19) en testant chaque étape. Les modules legacy cassent souvent, mais vous le découvrez sur une copie avant la prod.

Non, si c'est bien fait. Les agents IA doivent tourner en tâches asynchrones (cron jobs) en dehors de Dolibarr, ou via une API. Cela ne surcharge pas l'instance et vous garde la flexibilité de changer de technologie IA demain.