Un ERP peut être techniquement stable et pourtant produire de mauvaises décisions. La cause est souvent la même: des données incomplètes, incohérentes ou trop tardives dans les processus critiques.
Pour une DSI, la qualité des données n’est pas un chantier ponctuel de nettoyage. C’est un système de contrôle permanent, au même titre que la sécurité, la disponibilité ou la continuité de service.
Ce playbook propose une approche opérationnelle: où placer les contrôles, comment automatiser les alertes, quels rituels instaurer avec les métiers, et comment éviter que la qualité des données retombe après quelques semaines.
Pourquoi les projets ERP dérapent sur la qualité des données
Dans la plupart des projets, la qualité des données est traitée trop tard. Les ateliers fonctionnels avancent, les interfaces se construisent, les tests techniques passent. Puis viennent les tests métier, et les anomalies explosent: fournisseurs incomplets, articles non classés, adresses non conformes, règles TVA mal paramétrées, nomenclatures incohérentes.
Le vrai problème n’est pas seulement “la donnée sale”. C’est l’absence de système de responsabilité clair.
Quand personne ne sait qui est propriétaire d’un attribut critique, cet attribut devient instable. Quand aucun contrôle automatique ne bloque les cas non conformes, les exceptions deviennent la norme. Et quand les anomalies ne sont pas visibles dans un tableau de bord partagé, elles se déplacent d’équipe en équipe sans jamais être résolues durablement.
Le cadre DSI: penser qualité des données comme un produit
Une DSI qui réussit ce sujet traite la qualité des données comme un produit interne:
- un périmètre clair (données maîtres + flux transactionnels prioritaires)
- des règles explicites et versionnées
- une mesure continue
- un backlog d’amélioration
- un sponsor métier par domaine
Cette logique évite le piège du “grand nettoyage” annuel qui mobilise beaucoup d’énergie pour un effet temporaire. L’objectif n’est pas d’atteindre une perfection théorique. L’objectif est de rendre fiables les données qui pilotent la facturation, les achats, la planification, la marge et la conformité.
Les 4 couches de contrôle à implémenter
1. Contrôles à la saisie
Premier niveau: empêcher la création d’erreurs évitables.
Exemples de règles utiles:
- champ obligatoire sur les fiches tiers et articles
- formats imposés (IBAN, TVA intracom, code postal, e-mail)
- listes de valeurs autorisées pour les attributs structurants
- contrôles de cohérence de base (date de fin après date de début, devise active, unité compatible)
Ces contrôles doivent être stricts sur les attributs critiques, souples sur les attributs secondaires. Sinon, les utilisateurs contournent l’ERP avec des champs libres ou des exports Excel.
2. Contrôles de flux (batch ou temps réel)
Deuxième niveau: vérifier que les processus exécutés restent cohérents.
Exemples:
- commande client sans condition de paiement définie
- commande fournisseur sur un article sans famille d’achat
- réception stock sans lot alors que le produit est loti
- écriture comptable sans axe analytique obligatoire
Ces contrôles ne vivent pas dans l’interface utilisateur uniquement. Ils doivent aussi tourner automatiquement sur les flux nocturnes, les imports et les interfaces externes.
3. Contrôles transverses inter-modules
Troisième niveau: détecter les divergences entre modules. C’est souvent ici que les incidents métier apparaissent.
Exemples:
- divergence entre référentiel article ventes et article achats
- client actif en CRM mais bloqué en finance
- compte de charge utilisé sans mapping budgétaire
- nomenclature production incohérente avec les règles de stock
Sans ces contrôles inter-modules, chaque équipe “voit juste” dans son périmètre local, mais l’entreprise exécute mal de bout en bout.
4. Contrôles de pilotage (KPIs + alertes)
Quatrième niveau: rendre la qualité visible et actionnable.
Une bonne pratique est d’avoir un scorecard simple par domaine (clients, fournisseurs, articles, finance, production) avec quelques indicateurs lisibles par un comité DSI-métiers.
Exemples d’indicateurs:
- taux de complétude des attributs critiques
- taux d’anomalies bloquantes ouvertes
- délai moyen de résolution des anomalies
- part des flux rejetés au contrôle
- volume de corrections manuelles post-traitement
Le scorecard doit être vivant: alertes automatiques, responsables nommés, revues régulières.
Mise en place pratique: plan en 6 sprints
Sprint 1: cadrer les objets critiques
Commencez petit mais utile. Sélectionnez les objets qui impactent directement le business:
- tiers clients/fournisseurs
- référentiel article
- conditions de paiement et taxes
- axes analytiques
Documentez pour chaque objet:
- attributs critiques
- propriétaire métier
- impact en cas d’erreur
- niveau de contrôle attendu (bloquant, avertissement, monitoring)
Sprint 2: formaliser les règles de qualité
Transformez les attentes métier en règles testables. Une règle non testable n’est pas une règle opérationnelle.
Format recommandé:
- identifiant de règle
- objet concerné
- condition de non-conformité
- sévérité
- action attendue (blocage, rejet, alerte)
- équipe responsable
Sprint 3: instrumenter les contrôles automatiques
Implémentez les contrôles dans les bons points du SI:
- formulaire de saisie ERP
- jobs d’intégration
- pipelines ETL
- API d’échange
- vues de contrôle SQL
Cible prioritaire: automatiser ce qui déclenche le plus de corrections manuelles aujourd’hui.
Sprint 4: créer la boucle d’alerte
Un contrôle sans boucle d’action ne sert à rien. Reliez chaque anomalie à un responsable et à un délai de traitement.
Mécanismes efficaces:
- ticket automatique selon la sévérité
- notification ciblée au data owner
- tableau de suivi partagé
- règle d’escalade si dépassement du délai
Sprint 5: lancer les rituels DSI-métiers
Installez deux rituels simples:
- revue opérationnelle courte (hebdomadaire) sur anomalies ouvertes
- comité gouvernance (mensuel) sur tendances et arbitrages
La revue hebdo résout les incidents. Le comité mensuel ajuste les règles et les priorités.
Sprint 6: industrialiser et stabiliser
Une fois la première boucle en place:
- élargissez le périmètre à d’autres domaines
- retirez les contrôles redondants
- consolidez la documentation des règles
- mesurez la baisse des corrections manuelles
Le but est de passer d’une logique de “correction après coup” à une logique de “prévention intégrée”.
Rôles et gouvernance: qui doit décider
La gouvernance échoue quand le sujet est uniquement “IT” ou uniquement “métier”. Le modèle efficace est partagé:
- DSI: architecture des contrôles, automatisation, fiabilité d’exécution
- métiers: définition de la règle, priorisation par impact, validation des exceptions
- finance/contrôle de gestion: cohérence des impacts budgétaires et comptables
- direction: arbitrage quand deux objectifs entrent en conflit (vitesse vs qualité)
Un principe clé: chaque attribut critique doit avoir un propriétaire explicite. Sans propriétaire, pas de décision. Sans décision, pas de qualité durable.
Erreurs fréquentes à éviter
Vouloir traiter tout le référentiel d’un coup
Le “big bang data quality” produit souvent une surcharge puis un abandon. Mieux vaut avancer par domaines prioritaires.
Confondre contrôle et bureaucratie
Si le contrôle ralentit trop les équipes, elles créeront des contournements. Les règles doivent protéger les processus critiques, pas tout bloquer.
Laisser des exceptions sans date de fin
Une exception non bornée devient un standard implicite. Toute dérogation doit avoir un propriétaire, une justification et une échéance.
Mesurer sans corriger
Un dashboard rempli d’indicateurs ne crée pas de qualité. Ce qui compte est la vitesse de résolution et la réduction des récidives.
Check-list DSI pour les 90 prochains jours
Utilisez cette check-list pour passer rapidement à l’action:
- lister les objets de données critiques par processus métier
- nommer un propriétaire par attribut critique
- définir un premier lot de règles testables
- automatiser les contrôles sur saisie et flux
- connecter les anomalies à un mécanisme de ticketing
- instaurer une revue hebdo DSI-métiers
- suivre un scorecard simple par domaine
- publier un plan d’amélioration trimestriel
Cette discipline crée un effet cumulatif: moins de corrections urgentes, moins d’écarts inter-modules, meilleure confiance métier dans l’ERP.
Ce qu’il faut retenir
La qualité des données ERP n’est pas un projet annexe. C’est une capacité opérationnelle qui conditionne la performance des processus, la fiabilité des reportings et la qualité des décisions.
Pour une DSI, le levier le plus puissant n’est pas un outil supplémentaire. C’est la combinaison de règles claires, contrôles automatiques, responsabilités explicites et rituels de pilotage réguliers.
Pour approfondir, lisez notre guide sur la migration de données ERP, notre playbook MDM et gouvernance des données et notre méthodologie de conduite du changement ERP.
