Architecture Dolibarr : CSV orienté performance

Introduction

Dolibarr, l’ERP/CRM open source populaire, est souvent déployé pour la gestion complète d’entreprises de toutes tailles. Une de ses utilisations courantes, mais parfois sous-estimée, concerne le traitement massif de fichiers CSV : import de catalogues produits, export de rapports financiers, migration de données depuis des systèmes legacy, ou synchronisation avec des plateformes e-commerce.

Cet article explore l’architecture de Dolibarr sous l’angle spécifique de la performance CSV, en analysant ses forces, ses limites inhérentes, et les stratégies d’optimisation pour manipuler efficacement des volumes de données importants.

1. Architecture générale de Dolibarr : Un contexte PHP/MySQL

Pour comprendre les enjeux CSV, rappelons l’architecture de base :

  • Stack technique : PHP (principalement en mode synchronisé via Apache/Nginx) + MySQL/MariaDB.

  • Pattern : Architecture MVC modulaire, avec un cœur (htdocs) et des modules (htdocs/custom).

  • Accès aux données : Couche d’abstraction DoliDB (gérant MySQL, PostgreSQL, etc.) et classes de modèles (Object comme Product, Societe).

Les opérations CSV sont généralement traitées par :

  • Des scripts d’import/export natifs (via l’interface admin ou modules spécifiques comme import).

  • Des scripts maison (développés sur mesure dans /custom/).

  • Des appels API externes pouvant générer/consommer du CSV.

2. Le défi des performances CSV dans un environnement web synchrone

Le traitement de fichiers CSV pose des défis classiques en PHP web :

  • Limite mémoire : Charger un fichier CSV de 500 Mo en une fois épuise la mémoire PHP par défaut (128M).

  • Timeout : Un import de 10 000 lignes peut dépasser le max_execution_time (souvent 30s).

  • Charge serveur : Boucler sur 100 000 enregistrements et faire des appels BDD individuels est catastrophique.

  • Verrouillage : En mode web, une longue requête bloque le processus PHP-FPM/Apache.

Dolibarr par défaut n’échappe pas à ces contraintes. Son module d’import standard, bien que pratique, peut être lent sur gros volumes car il traite souvent les lignes une par une avec validation et insertion immédiate.

3. Stratégies d’optimisation "CSV Performant" dans Dolibarr

3.1. Passer en mode CLI/Worker pour les traitements lourds

Principe : Exécuter les imports/exports lourds via php-cli (en ligne de commande) plutôt que par le navigateur.

  • Avantages : Pas de timeout web, mémoire illimitée (ou quasi), pas de blocage du serveur web.

  • Mise en œuvre :

    • Créer un script PHP dans /custom/scripts/ qui utilise les classes Dolibarr (require_once '../../main.inc.php').

    • Lancer via cron ou manuellement : php /chemin/vers/custom/scripts/import_massif.php fichier.csv.

    • Exemple de squelette : 
      <?php
      
define('USEDOLIBARR', 1);
      
require_once __DIR__.'/../../main.inc.php';
      
$file = $argv[1];
      
$handle = fopen($file, 'r');
      
while(($data = fgetcsv($handle, 10000, ';')) !== FALSE) {
      
// Traitement par lot avec INSERT ... ON DUPLICATE KEY
      
}
      
fclose($handle);

3.2. Traitement par lots (batch) et optimisation BDD

  • Éviter les insertions ligne à ligne : Utiliser des requêtes INSERT multi-lignes (jusqu’à 1000 lignes/requête) ou LOAD DATA INFILE (MySQL) si le fichier est sur le serveur.

  • Désactiver les triggers et calculs temporairement : Si votre module personnalisé le permet, couper les mises à jour automatiques de compteurs, calculs de stocks pendant l’import, puis les recalculer en bloc après.

  • Utiliser les transactions : BEGIN; ... INSERT ...; COMMIT; pour accélérer et sécuriser.

  • Indexer intelligemment : Pour les imports, supprimer les index secondaires non critiques avant, puis les recréer après (surtout sur tables volumineuses comme llx_product, llx_societe).

3.3. Streaming et générateurs (PHP ≥ 5.5)

Ne jamais charger tout le fichier en mémoire. Utiliser fgetcsv() dans une boucle while, ou mieux, un générateur :

function readCsv($filename) {

    $handle = fopen($filename, 'r');

    while(($row = fgetcsv($handle, 10000, ',')) !== false) {

        yield $row;

    }

    fclose($handle);

}

foreach(readCsv('bigfile.csv') as $line) {

    // Traitement faible mémoire

}

3.4. Adapter les paramètres PHP/MySQL

  • memory_limit : Passer à 512M ou 1G pour les scripts CLI.

  • max_execution_time : 0 (illimité) en CLI, mais contrôler via votre propre timer si besoin.

  • MySQL innodb_buffer_pool_size : Assurez-vous qu’il peut accueillir les tables intensément modifiées.

  • bulk_insert_buffer_size : Augmenter pour les INSERT massifs.

3.5. Exploiter les API natives performantes de Dolibarr

  • DoliDB::insert : Méthode d’abstraction BDD, mais pour la performance extrême, écrire du SQL natif via $db->query().

  • Classes de chargement rapide : Certains modules (ex: product) ont des méthodes fetchAll avec options de limitation. Les utiliser pour les vérifications (ex: "ce SKU existe-t-il déjà ?") avec des requêtes SELECT en batch (WHERE IN (…) sur les 500 prochains SKUs) plutôt qu’une requête par ligne.

4. Étude de cas concret : Import de 50 000 produits

Contexte : Import mensuel d’un catalogue fournisseur (CSV 150 Mo, 50 000 lignes, 20 colonnes).

Approche naïve (interface web standard) :

  • Échec probable : timeout à 30s, mémoire épuisée.

  • Solution "par défaut" : Découper le CSV en 50 fichiers de 1000 lignes → fastidieux.

Approche optimisée (CLI + batch) :

  1. Pré-traitement : Nettoyer le CSV (supprimer les BOM, uniformiser les séparateurs) via iconv/sed si nécessaire.

  2. Script CLI :

    • Lecture streaming du CSV.

    • Par lot de 1000 lignes :

      • Vérification d’existence en batch (SELECT ref FROM llx_product WHERE ref IN (…)).

      • Préparation d’un tableau d’INSERT/UPDATE.

      • Exécution d’une seule requête INSERT ... ON DUPLICATE KEY UPDATE.

    • Validation : comptage lignes traitées vs. total.

  3. Post-traitement :

    • Reconstruction des index sur llx_product.

    • Lancement du cron de recalcul des stocks/prix si nécessaire (module stock).

Résultat : Import en ~3-5 minutes (dépend de l’indexation), mémoire stable sous 100M.

5. Pièges à éviter et bonnes pratiques

  • Ne pas contourner la logique métier Dolibarr : Si vous insérez directement des produits sans appeler Product::create, vous risquez de casser les liens (ex: prix par défaut, catégories, images). Solution : soit wrapper la création via les classes natives en batch, soit reproduire exactement la logique métier après coup (risqué).

  • Gérer les erreurs : Logguer les lignes en échec dans un fichier CSV d’erreur avec la raison, plutôt que d’arrêter le script.

  • Transactions et rollback : Traiter par lot avec transaction. Si un lot échoue, rollback du lot et log de l’erreur, sans tout annuler.

  • Test en environnement pré-production : Toujours valider avec un échantillon représentatif (taille, format) avant production.

6. Outils et modules communautaires

  • Module import avancé : Certains modules payants ou communautaires proposent des imports plus robustes (gestion de fils d’attente, reprise sur erreur). Rechercher sur Dolistore.

  • Symfony Console : Pour Dolibarr ≥ 14, on peut créer des commandes Symfony (dans custom/command/) bénéficiant du système de logging et de progression native, plus propre que les scripts PHP bruts.

  • External ETL : Pour les très gros volumes (100 000+), envisager un outil externe (Pentaho, Talend, ou même Python+SQLAlchemy) qui se connecte directement à la BDD Dolibarr, en respectant le schéma et les contraintes. Moins intégré mais souvent plus performant.

Conclusion

L’architecture de Dolibarr, bien que conçue pour la polyvalence et l’extensibilité, n’optimise pas nativement les traitements CSV massifs en mode web synchrone. La clé d’une performance CSV réside dans :

  1. Sortir du navigateur → passer en CLI/cron.

  2. Stratégie batch + SQL optimisé → éviter la boucle PHP/BDD 1:1.

  3. Respecter la logique métier → utiliser les classes Dolibarr ou reproduire leur comportement.

  4. Adapter l’environnement → mémoire, timeout MySQL, index.

En adoptant ces pratiques, Dolibarr devient un outil redoutable pour l’intégration de données à grande échelle, sans sacrifier sa stabilité ni samaintenabilité. L’open source ici offre une liberté précieuse : nous pouvons adapter l’outil à la charge, et non subir la charge.

Article rédigé par un expert technique Dolibarr. Les codes et configurations sont des exemples génériques – adapter à votre version Dolibarr et à votre infrastructure.

Publications similaires