Automatiser qualité des données dans Dolibarr : FAQ sans casser l’existant

Objectif : Vous fournir un guide complet pour implémenter des règles d’automatisation de la qualité des données (DQ) dans Dolibarr, tout en préservant les données déjà en production.
Public cible : Administrateurs Dolibarr, consultants en ERP/CRM, équipes IT et métiers souhaitant garantir la fiabilité de leurs informations sans interrompre le fonctionnement quotidien.

1. Pourquoi automatiser la qualité des données dans Dolibarr ?

Problématique	Impact	Solution offerte par l’automatisation
Saisie manuelle (erreurs de transcription, champs vides)	Doublons, factures erronées, défauts de suivi client/fournisseur	Rules Engine (règles métier) + Workflows automatiques
Données hétérogènes (format dates, codes pays, unités)	Rapports incohérents, difficultés d’intégration externalisée	Validators centralisés (regex, listes de référence)
Mises à jour fréquentes (nouveaux pays, nouvelles taxes)	Risque de non‑conformité légale	Versioning des règles, tests en sandbox
Auditabilité	Difficulté à prouver la conformité des données	Logs détaillés, historisation des actions

En résumé, l’automatisation vous permet de :

Détecter les anomalies dès la saisie ou l’import,

Corriger (ou bloquer) les enregistrements non conformes,

Documenter chaque intervention pour audit,

Éviter de toucher aux données déjà validées.

2. Architecture technique recommandée

[ UI Dolibarr ]  <--->  (REST API / Hooks)  -->  [ Engine DQ ]  -->  [ Table de logs / Observabilité ]

Hooks & Triggers : Utilisez les hooks natifs de Dolibarr (ex. formCapture, entityGet, postInsert) pour déclencher la validation dès que l’utilisateur enregistre un formulaire ou qu’un script d’import s’exécute.

Engine DQ : Un petit service (PHP, Python ou même du SQL pur) qui regroupe :
- Validators (format, champ obligatoire, domaine de référence)
- Business Rules (ex. “TVA doit être calculée uniquement si le client est professionnel”)
- Actions (correction automatique, ajout d’un flag d’alerte, mise en quarantaine)

Persistences :
- Table dq_log (ID, date, utilisateur, entité, champ, type de règle, statut) – Table dq_quarantine (copies de lignes suspectes pour re‑examen manuel) > Bon à savoir : Dolibarr autorise la création de modules complémentaires via le répertoire /custom. Vous pouvez placer votre engine dans /custom/dq_engine/ sans toucher au cœur du logiciel.

3. Mise en œuvre pas à pas (sans casser l’existant)

Étape 1 – Cartographier les flux de données critiques| Entité | Points d’entrée (formulaires, scripts, import) | Risques clés |

Astuce : Commencez par les entités les plus volumineuses ou les plus à risque de non‑conformité.

Étape 2 – Créer des règles de validation simples (exemple avec PHP)

<?php

// custom/dq_engine/Rule_Clients.phpclass DQ_Rule_Clients implements DQ_RuleInterface {

    public function validate(array $data) : array {

        $errors = [];
// champ obligatoire : raison_sociale        if (empty(trim($data['razon_sociale']))) {

            $errors[] = self::ERROR_REQUIRED('razon_sociale');

        }
// format email

        if (!empty($data['email'])) {

            if (!filter_var($data['email'], FILTER_VALIDATE_EMAIL)) {

                $errors[] = self::ERROR_FORMAT('email', '/^[\\w\\.-]+@[\\w\\.-]+\\.[A-Za-z]{2,}$/');

            }

        }
// code pays doit être dans la liste FR, BE, CH, ...

        $allowed = ['FR','BE','CH','DE'];

        if (!in_array($data['country_id'], $allowed, true)) {

            $errors[] = self::ERROR_INVALID('country_id', $allowed);

        }
return $errors; // tableau de messages ou [] si OK

    }

}

?>

DQ_RuleInterface : Interface simple à définir dans custom/dq_engine/interface.php (déclaration de ERROR_REQUIRED, ERROR_FORMAT, …).

Retour : Retourner un tableau de messages → affichage dans l’UI ou journalisation.

Étape 3 – Hooker l’engine sur les points d’entrée

Dans un module Dolibarr :

// custom/dq_engine/modules/dq_hook_client.php

function dq_hook_client_before_save($hookn, $param) {

    // $param contient les champs du client avant l’enregistrement

    $rules = require __DIR__.'/Rule_Clients.php';

    $engine = new DQ_Engine($rules);

    $errors = $engine->validate($param);

    if (!empty($errors)) {

        // Ajouter le log sans bloquer le save (ou bloquer selon votre politique)

        $logId = DQ_Log::add('CLIENTS', 'INSERT', $_SESSION['user']->id, $errors);

        dol_syslog('DQ :: Client '. $param['id'] .' rejeté : '.implode(', ', $errors), LOG_WARNING);

        // Option : Lever une exception pour annuler l'enregistrement

        // throw new Exception('Données client non conformes');

    }

    return true;

}

?>

Activation : Dans le fichier llxModule::globalSetup(), appelez dol_register_hook($hookn, array($this,'dq_hook_client_before_save'), 0, '');.

Without breaking existing data : La fonction est exécutée avant l’enregistrement (before_save). Si vous choisissez de bloquer l’enregistrement, capturez l’erreur et notifiez l’utilisateur ; sinon, simplement loguer et laisser le système continuer.

Étape 4 – Implémenter un mécanisme de mise en quarantaine (Quiet Zone)

Objectif : éviter la perte accidentelle de données lorsqu’un enregistrement est rejeté.

Mise en place : Copier la ligne suspecte dans dq_quarantine (avec le timestamp). Le responsable peut alors analyser et corriger manuellement.

function dq_move_to_quarantine($entity, $rowid, $data) {

    $quarantine = new DQ_Quarantine();

    $quarantine->saveQuarantine($entity, $rowid, $data);

}

Étape 5 – Monitoring et tableau de bord

Créez un rapport Dolibarr ($functions->load['reports']['dq_status']) affichant :
- Nombre d’erreurs détectées par jour,
- Nombre d’enregistrements en quarantaine,
- Évolution du taux de conformité.

Intégrez cet onglet dans le menu principal via $_MENU['setup->tabAdmin'][] = array('title'=>'Data Quality','url'=>'index.php?leftMenu=4&mainmenu_signons=1&thirdmenu_signons=1&page=dq_dashboard');.

4. FAQ – Questions fréquentes

#	Question	Réponse détaillée
1	Puis‑je appliquer ces règles à des fichiers d’import CSV déjà existants sans les modifier ?	Oui. Créez un job d’import qui, après la lecture du CSV, parcourt chaque enregistrement avec `DQ_Engine::validate()`. Si des erreurs apparaissent, placez la ligne dans `dq_quarantine` et demandez à l’opérateur de la corriger ou de la rejeter avant que le script ne ré‑écrive le tableau `llx_...` correspondant. Aucun changement du format CSV n’est requis.
2	Et si je dois corriger automatiquement des champs (ex. normaliser le pays) ?	Implémentez une action corrective dans chaque règle. Ex. `if ($data['country_id'] == 'F') { $data['country_id'] = 'FR'; }`. La correction s’applique en amont de la validation et la ligne est ensuite ré‑enregistrée avec les valeurs corrigées. Vous avez la possibilité de ne pas accepter la correction automatique si vous préférez un examen manuel.
3	Comment m’assurer que les règles ne casseront pas les anciennes données déjà validées ?	1. Versionner chaque règle (ex. `Rule_Clients_v1.php`, `Rule_Clients_v2.php`). 2. Exécuter les règles en mode lecture‑seule sur une copie de la base (dump). 3. Utiliser la table `dq_log` pour re‑appliquer les validations sur les enregistrements déjà existants, sans les modifier. 4. Ne bloquez rien tant que vous avez validé le processus en sandbox.
4	Les règles de validation sont‑elles compatibles avec les versions futures de Dolibarr ?	Tant que vous vous basez exclusivement sur les hooks documentés (`formCapture`, `entityGet`, `postExecute`) et que vous ne touchez pas aux classes internes (`class Db`, `class Hook`), votre module restera fonctionnel à travers les versions mineures (≥ 9.0). Pour les grosses évolutions (ex. refactorisation du core), prévoyez un test d’intégration chaque 6 mois.
5	Quel impact sur la performance ?	Les validateurs sont légers (regex, listes d’autocomplétion). Le coût principal vient de la sauvegarde en log et de l’éventuel re‑enregistrement en quarantaine. En pratique, pour < 10 000 enregistrements/jour, l’impact < 50 ms par transaction.
6	Dois‑je toucher à la base de données directement ?	Non nécessairement. Utilisez les API Dolibarr (`$db->insert`, `$db->update`) qui encapsulent les verrous et les triggers internes. La table `dq_quarantine` peut être créée via les scripts d’installation du module, mais aucune modification directe de tables métier (`llx_client`, `llx_product`, …) n’est requise.
7	Comment documenter ces règles pour mon équipe ?	– Créez un Wiki interne avec le fichier `README.md` du répertoire `custom/dq_engine/`. – Ajoutez des commentaires dans chaque règle décrivant le raison métier, le contexte et le impact. – Exportez les logs (`SELECT * FROM dq_log WHERE created > NOW() - INTERVAL 30 DAY`) dans un CSV mensuel pour le reporting d’audit.
8	Puis‑je combiner ces validations avec les champs “obligatoires” déjà définis dans Dolibarr ?	Oui. Le champ `obligatory` de Dolibarr déclenche déjà un check côté UI. Vous pouvez renforcer ce contrôle en validant également côté serveur, ce qui garantit la conformité même via l’API ou les scripts batch.
9	Quelle est la meilleure façon de gérer les exceptions (ex. clients historiques) ?	Utilisez le concept de score d’exception : chaque règle renvoie un poids. Si le poids dépasse un seuil configurable, la ligne est mise en quarantaine. Les clients anciens peuvent être "exemptés" via une table de `dq_exception` (ex. ID client, motif). Cela évite de bloquer des données historiques qui ne respectent pas encore les nouvelles exigences.
10	Dois‑je faire appel à un tiers ou rester sur du PHP pur ?	Vous pouvez implémenter l’engine en PHP (plus simple à installer) ou en Python si vous avez déjà un micro‑service. L’important est de rester hors du core Dolibarr. Exposez un endpoint HTTP (`/custom/dq_engine/api/validate`) que vos scripts peuvent appeler via `curl`.

5. Checklist « Go‑Live » – Déploiement sans heurt

✅	Action	Vénère
1	Test unitaire des règles sur un dump de production (au moins 2 mois de données).	✔
2	Validation en sandbox : lancer le hook dans un environnement isolé, valider les logs.	✔
3	Mise en place du tableau de logs et vérification de la rotation (ex. `logrotate`).	✔
4	Formation d’au moins un administrateur par service (commercial, compta) sur le volet “Quarantaine”.	✔
5	Plan de rollback : désactiver le hook ou remplacer le module par la version désactivée.	✔
6	Plan de monitoring : alertes (Slack/Email) lorsqu’un jour > 50 erreurs, ou quand le taux de quarantaine dépasse 2 %.	✔
7	Communication interne : annoncer le futur “Data Quality Dashboard” et les bénéfices (ex. réduction de 15 % des erreurs de facturation).	✔

6. Ressources complémentaires

Type	Lien / Référence
Documentation officielle Dolibarr	https://www.dolibarr.org/doc/en/modules/
Guide de développement de modules	`htdocs/core/modules/` (section Hooks API)
Exemple de module “Data Quality” sur GitHub	https://github.com/yourorg/dolibarr-dq-module
Blog technique (case‑study)	“Automating Data Validation in Dolibarr – From Rules to Dashboard” – OpenERPmag 2024
Formation en ligne	Webinar « Dolibarr Data Governance », organisé par la communauté French ERP (Octobre 2024)

7. Conclusion

Automatiser la qualité des données dans Dolibarr est à la fois simple (via hooks, règles de validation et log) et puissant (quarantaine, tableau de bord, versioning). En suivant le processus ci‑dessus :

Cartographier les points d’entrée critiques,

Développer des règles de validation ciblées,

Hooker ces règles sans toucher au cœur du système, 4. Gérer les rejets via la quarantaine,

Monitorer les indicateurs en continu,

vous obtenez un système de contrôle de qualité totalement intégré, transparent pour les utilisateurs et non‑intrusif pour les données historiques. Vous pouvez ainsi garantir la fiabilité de vos rapports, réduire les erreurs de traitement et respecter les exigences de conformité sans jamais mettre en danger l’existant.

Petit bonus : commencez par un pilote sur l’entité Clients. Une fois les règles validées, étendez‑les progressivement à Articles, Factures et Utilisateurs. Vous verrez rapidement le gain en qualité de données et en confiance utilisateur.

Bonne automatisation ! 🚀

Automatiser qualité des données dans Dolibarr : FAQ sans casser l’existant

1. Pourquoi automatiser la qualité des données dans Dolibarr ?

2. Architecture technique recommandée

3. Mise en œuvre pas à pas (sans casser l’existant)

Étape 1 – Cartographier les flux de données critiques| Entité | Points d’entrée (formulaires, scripts, import) | Risques clés |

Étape 2 – Créer des règles de validation simples (exemple avec PHP)

Étape 3 – Hooker l’engine sur les points d’entrée

Étape 4 – Implémenter un mécanisme de mise en quarantaine (Quiet Zone)

Étape 5 – Monitoring et tableau de bord

4. FAQ – Questions fréquentes

5. Checklist « Go‑Live » – Déploiement sans heurt

6. Ressources complémentaires

7. Conclusion

Dolibarr et la gestion des commandes en ligne : Les meilleures pratiques à connaître

Pourquoi Dolibarr Maroc est-il incontournable pour les PME ?

Optimisez votre entreprise avec Dolibarr et la gestion des relations clients

Les fonctionnalités essentielles de Dolibarr CRM

Dolibarr avancé : reverse proxy en 2026

DevOps Dolibarr : workflows Checklist avec une approche sécurité

1. Pourquoi automatiser la qualité des données dans Dolibarr ?

2. Architecture technique recommandée

3. Mise en œuvre pas à pas (sans casser l’existant)

Étape 1 – Cartographier les flux de données critiques| Entité | Points d’entrée (formulaires, scripts, import) | Risques clés |

Étape 2 – Créer des règles de validation simples (exemple avec PHP)

Étape 3 – Hooker l’engine sur les points d’entrée

Étape 4 – Implémenter un mécanisme de mise en quarantaine (Quiet Zone)

Étape 5 – Monitoring et tableau de bord

4. FAQ – Questions fréquentes

5. Checklist « Go‑Live » – Déploiement sans heurt

6. Ressources complémentaires

7. Conclusion

Publications similaires

1. Pourquoi automatiser la qualité des données dans Dolibarr ?

5. Checklist « Go‑Live » – Déploiement sans heurt