Imaginez que vous automatisiez votre processus de commande demain. Tout va plus vite, tout est numérique. Et trois fois plus vite qu'avant, des commandes incorrectes arrivent chez le fournisseur — parce que l'adresse dans votre système est obsolète depuis deux ans. L'automatisation ne corrige pas les erreurs de données. Elle les accélère.
Ce que la mauvaise qualité des données coûte vraiment
Gartner estime le coût annuel moyen d'une mauvaise qualité des données à environ 12,9 millions de dollars (par organisation). Pour une PME, ce chiffre paraît abstrait. Il devient concret dès qu'on le décompose : chaque adresse incorrecte dans les données de base génère un retour. Chaque niveau de stock erroné entraîne une surcommande ou un retard de livraison. Chaque fiche client dupliquée multiplie les erreurs dans les systèmes en aval.
Ce qui rend cela insidieux : la plupart de ces coûts n'apparaissent pas sur une ligne du compte de résultat. Ils se cachent dans le temps que passent des collaborateurs expérimentés à corriger manuellement des exceptions. Dans des décisions prises sur la base de chiffres erronés. Dans des systèmes auxquels plus personne ne fait confiance, et autour desquels des listes Excel émergent qui finissent par porter la vraie connaissance de l'entreprise.
Garbage in, garbage out : pourquoi la maturité prime sur la vitesse
« Garbage in, garbage out » est le principe le plus ancien du traitement des données — et le plus souvent ignoré. Il signifie : la qualité de l'output ne sera jamais meilleure que la qualité de l'input. Automatiser un processus avec de mauvaises données produit de mauvais résultats plus vite. Entraîner un modèle d'IA sur des données historiques incohérentes lui fait prendre de moins bonnes décisions qu'un chef de projet expérimenté — mais cent fois plus vite.
C'est pourquoi le niveau de maturité des données n'est pas une note de bas de page technique — c'est un prérequis de projet. On peut distinguer grossièrement cinq niveaux de maturité : des données brutes et non systématisées jusqu'aux fondements fiables et analysables. La plupart des PME ne démarrent pas au niveau cinq. Beaucoup sous-estiment à quel niveau elles se trouvent réellement.
Ce n'est pas une critique — c'est le point de départ. Connaître son niveau de maturité des données avant de lancer un projet permet une planification réaliste : ce qui doit d'abord être nettoyé, quelle automatisation est immédiatement possible et où un travail préparatoire est encore nécessaire.
Améliorer la qualité des données : un cycle, pas un effort unique
La bonne nouvelle : la qualité des données n'est pas un grand projet que l'on mène une fois et que l'on coche. C'est un cycle que l'on parcourt étape par étape — d'abord pour le domaine de données le plus important, puis le suivant. Cette approche itérative a fait ses preuves en pratique, car elle maintient le risque faible et livre rapidement de premiers résultats, plutôt que de passer des mois à « nettoyer » avant que quoi que ce soit ne devienne utilisable. La base méthodologique est la logique de contrôle issue de Six Sigma / DMAIC : ne pas nettoyer une fois, mais rester propre.
Les quatre étapes sont délibérément simples :
- Profiler : Mesurer d'abord où se trouvent réellement les erreurs — doublons, lacunes, formats contradictoires. Pas de sentiment, mais un état des lieux honnête du domaine de données concerné.
- Nettoyer : Corriger les erreurs trouvées, fusionner les doublons, combler les lacunes. Travail de nettoyage ponctuel — la partie que la plupart associent à la « qualité des données ».
- Ancrer les règles : L'étape décisive que beaucoup sautent. Champs obligatoires, validations et une source unique de vérité claire garantissent que les mêmes erreurs ne réapparaissent pas demain. Sans cette étape, vous nettoyez à nouveau dans six mois.
- Surveiller : Quelques indicateurs simples — taux de doublons, part des enregistrements incomplets — montrent en continu si la qualité se maintient. Si une valeur bascule, vous intervenez tôt plutôt que d'être désagréablement surpris lors du prochain projet.
Puis le cycle recommence — avec le prochain domaine de données. La qualité des données grandit ainsi avec l'activité, plutôt que de devoir être « terminée » à l'avance dans un grand effort risqué. Pour les PME, c'est la voie pragmatique : de petites étapes vérifiables plutôt qu'un big bang.
Vos données parlent déjà — les écoutez-vous ?
Le versant positif de l'avertissement : les données que vous possédez déjà contiennent généralement plus de réponses que vous ne le pensez. Pas comme une promesse abstraite de big data, mais très concrètement.
À quelle fréquence les commandes sont-elles corrigées manuellement ? Quel est le taux de reprise sur les factures entrantes ? À quelle étape surgissent le plus de questions ? Ce ne sont pas des impressions — ce sont des mesures qui existent déjà dans vos systèmes. Elles montrent où le processus coince, quelle est la qualité réelle des données et où se trouvent les plus grands leviers d'amélioration.
Si 30 % des tickets dans un système de ticketing portent le statut « question à l'initiateur », ce n'est pas un hasard. C'est un point de données qui dit : des champs obligatoires cohérents manquent lors de la saisie. Ou les bonnes personnes voient la mauvaise information. Les deux sont solubles — mais seulement si on regarde.
La vérification honnête du niveau de maturité avant le projet
Avant tout projet d'optimisation, cinq questions honnêtes valent la peine d'être posées :
- D'où viennent nos données de base — et qui les maintient, selon quelles règles ?
- Quel est le taux de correction manuel dans les processus concernés ?
- Combien de systèmes contiennent les mêmes données dans des versions différentes ?
- Qui est la source fiable de vérité pour les bases de décision les plus importantes ?
- Quelles décisions prenons-nous aujourd'hui à l'instinct parce que la situation des données est floue ?
Plus ces questions mènent à un « pas vraiment sûr », plus il est précieux de les clarifier avant d'investir. Non pas pour freiner le projet — mais pour le construire sur des fondations solides.
Nous examinons cet état avec nos clients avant de développer des concepts techniques. Ce qui arrive régulièrement : les données utilisables sont souvent meilleures que craintes. Et les points problématiques sont plus petits et plus ciblément solubles qu'on ne le pensait. C'est la différence entre un projet qui livre et un projet qui est flanqué de solutions Excel de contournement un an après le lancement.
La partie suivante de cette série aborde un prérequis encore moins souvent clarifié explicitement que la situation des données : qui porte réellement la responsabilité du bon fonctionnement durable de ce processus ?