La gouvernance des données, c’est l’ensemble des règles qui disent qui est responsable de quelle donnée, à quoi elle doit ressembler pour être juste, quelle source fait foi, qui peut la consulter ou la modifier, et comment on retrouve l’origine d’un chiffre. Dans une PME ou une ETI, elle n’a pas besoin d’un comité ni d’un logiciel dédié pour exister : quelques décisions écrites et tenues suffisent souvent. Elle devient indispensable dès qu’on veut automatiser un processus, parce qu’un système exécute ce qu’on lui donne sans compenser les incohérences comme le fait une personne. Avant d’automatiser, il faut donc avoir réglé au minimum les responsables, les référentiels, les champs critiques et les accès du processus concerné.
Une définition utile, sans vocabulaire de grand groupe
Les définitions de manuel parlent de politiques, de cycle de vie et de rôles aux noms anglais. Pour une entreprise de 50 ou 500 personnes, on peut ramener la gouvernance des données à cinq questions, posées donnée par donnée.
Qui en répond ? Chaque donnée importante (un fichier client, un tarif, un code analytique, un statut de commande) a un responsable métier. Ce n’est pas forcément la personne qui la saisit, ni le service informatique qui administre l’outil : c’est celle qui tranche quand deux versions se contredisent et qui valide une modification de règle.
À quoi ressemble une donnée correcte ? Ce sont les règles de qualité : champs obligatoires, formats attendus, valeurs autorisées, cohérence entre deux champs. « Un client a un SIREN valide », « un code TVA appartient à une liste fermée », « une date de livraison n’est pas antérieure à la date de commande ».
Quelle source fait foi ? Ce sont les référentiels : la liste officielle des clients, des fournisseurs, des articles, des comptes, des centres de coût. Quand l’ERP, le CRM et un fichier Excel décrivent le même client différemment, une règle dit lequel l’emporte et où l’on corrige.
Qui peut voir et modifier quoi ? Ce sont les accès : qui consulte, qui crée, qui modifie, qui supprime, et pour quelle raison. Les droits hérités d’anciens postes ou partagés « par commodité » en font partie.
Comment remonte-t-on à l’origine ? C’est la traçabilité : savoir d’où vient un chiffre, quelles transformations il a subies, qui l’a modifié et quand. Sans elle, chaque écart se règle par une enquête.
Tant que ces réponses existent quelque part par écrit et sont appliquées, l’entreprise a une gouvernance des données, même si elle ne l’appelle pas ainsi.
Ce qu’elle n’est pas
Elle n’est pas d’abord un outil. Un catalogue de données ou une solution de gestion des données de référence peut aider une organisation qui a déjà des règles ; il ne les crée pas à sa place.
Elle n’est pas non plus un poste à pourvoir. Dans une PME, recruter un responsable de la qualité des données est rarement la première étape. Ce qui compte, c’est que les responsables métier existants acceptent explicitement la responsabilité de leurs données, avec un peu de temps prévu pour cela. Un rôle dédié peut se justifier plus tard, quand le nombre de sources et de flux le rend nécessaire.
Enfin, elle n’est pas un projet global à mener avant toute chose. Vouloir gouverner toutes les données de l’entreprise d’un coup produit surtout de la documentation que personne ne tient à jour. Il est plus efficace de partir d’un processus précis et des données dont il a besoin.
Pourquoi un processus automatisé amplifie les défauts de données
Dans un processus manuel, les personnes compensent en permanence. Elles savent que « Dupont SAS » et « DUPONT S.A.S. » sont le même client, qu’un champ vide dans le CRM veut dire « à voir avec le commercial », que le tarif du fichier partagé est plus récent que celui de l’ERP. Ce savoir n’est écrit nulle part, mais il corrige les données au passage.
Un système qui exécute le processus n’a pas ce savoir. Il applique ses règles à chaque enregistrement, au même rythme, sans s’arrêter pour douter. Trois défauts reviennent presque toujours.
Les doublons. Deux fiches pour un même tiers, et les relances, les encours ou les remises se calculent sur une moitié de l’historique. Un traitement automatique peut aussi créer lui-même de nouveaux doublons s’il n’a pas de règle pour reconnaître un tiers existant.
Les référentiels divergents entre ERP, CRM et Excel. Le même article porte un libellé, une unité ou un prix différent selon l’outil. Le système prend celui de la source qu’on lui a branchée, qui n’est pas forcément celle que l’équipe considère comme juste.
Les champs libres. Un motif d’avoir, un statut ou une catégorie saisis en texte libre ne peuvent pas être traités de façon fiable par une règle. Un modèle d’IA peut les interpréter, mais avec une marge d’erreur qu’il faut alors contrôler, ce qui rejoint la question de ce qui doit rester du code, de l’IA ou une validation humaine.
Prenons un exemple illustratif : une entreprise automatise l’envoi des relances clients à partir de l’ERP. Le fichier client contient des doublons et certains contacts de facturation ne sont à jour que dans le CRM. Le jour du lancement, une partie des relances part à d’anciens interlocuteurs, et un client ayant réglé sur l’autre fiche reçoit une relance injustifiée. L’automatisation a fonctionné exactement comme prévu ; ce sont les données qui n’étaient pas prêtes.
C’est aussi pour cette raison qu’un tableau de bord financier ne vaut que par la fiabilité des données qui l’alimentent : l’automatisation rend le résultat plus rapide, pas plus juste.
Checklist : les données sont-elles prêtes pour automatiser ?
Cette grille s’applique à un processus précis, pas à toute l’entreprise. On la remplit avec la personne qui exécute le processus aujourd’hui et avec le responsable métier des données concernées.
| Point à vérifier | Pourquoi | Comment le vérifier |
|---|---|---|
| Chaque donnée d’entrée a un responsable métier nommé | Sans arbitre, les écarts détectés par le système restent sans suite | Lister les données utilisées par le processus et écrire un nom en face de chacune |
| Une source de référence est désignée pour chaque référentiel | Le système doit savoir quelle version prendre quand deux outils divergent | Pour les clients, fournisseurs, articles ou comptes utilisés, noter l’outil qui fait foi et où l’on corrige |
| Le taux de doublons est connu | Les doublons faussent les calculs et se multiplient avec l’automatisation | Extraire les tiers ou articles concernés et rechercher les correspondances sur le nom, l’identifiant légal, l’adresse ou le courriel |
| Les champs critiques sont renseignés | Un champ vide bloque une règle ou déclenche un mauvais traitement | Mesurer le taux de remplissage des champs dont dépend une décision du processus |
| Les valeurs sont normées plutôt que libres | Une règle ne peut pas traiter de façon fiable un texte saisi librement | Repérer les champs en texte libre utilisés pour décider et regarder la variété réelle des valeurs saisies |
| Les correspondances entre outils sont écrites | Les codes d’un outil doivent se traduire sans ambiguïté dans l’autre | Vérifier qu’une table de correspondance existe, qui la tient à jour et ce qui se passe pour un code absent |
| Les exceptions connues sont listées | Ce que les personnes corrigent de tête doit devenir une règle ou un cas renvoyé à un humain | Observer le processus sur plusieurs occurrences et noter chaque correction manuelle |
| Les accès nécessaires sont identifiés et limités | Le système ne doit lire et écrire que ce dont le processus a besoin | Dresser la liste des données lues et écrites, et vérifier qu’un compte dédié peut s’en tenir à ce périmètre |
| Chaque modification est traçable | En cas d’erreur, il faut savoir ce que le système a fait, sur quelle base | Vérifier que les outils conservent un historique et prévoir un journal des actions du système |
Il n’est pas nécessaire que tout soit parfait pour commencer. Un point non résolu peut être traité autrement : un contrôle en entrée qui écarte les enregistrements incomplets, un dédoublonnage préalable, une validation humaine sur les cas ambigus. Ce qui pose problème, ce sont les points qu’on n’a pas regardés.
Le RGPD : minimisation et accès dès la conception
Dès qu’un processus manipule des données personnelles (clients particuliers, contacts, salariés, candidats), la gouvernance des données rejoint le RGPD. L’article 5 du règlement pose notamment que les données doivent être adéquates, pertinentes et limitées à ce qui est nécessaire au regard des finalités (minimisation), exactes et tenues à jour si nécessaire, conservées pour une durée limitée et protégées par des mesures de sécurité appropriées. L’article 25 demande d’intégrer cette protection dès la conception des traitements.
Pour un processus automatisé, cela se traduit par des choix concrets :
- le système ne reçoit que les champs dont il a besoin, pas l’export complet d’une table ;
- les droits d’accès sont nominatifs ou propres au système, et réduits au strict nécessaire ;
- les copies intermédiaires (exports, fichiers de travail, données envoyées à un service d’IA) sont identifiées et supprimées selon une durée définie ;
- une donnée inexacte peut être corrigée à la source, et la correction se propage.
Une donnée bien gouvernée est ainsi plus facile à protéger : on sait où elle se trouve, qui y accède et pourquoi. Notre façon de traiter ces sujets pendant une mission est décrite dans la page sécurité et données.
Par où commencer
Le point de départ le plus efficace est un processus que l’on envisage d’automatiser, choisi selon sa fréquence, son coût et ses risques ; le guide pour choisir le premier processus à automatiser détaille ces critères. On en déduit ensuite les données concernées, et on applique la checklist ci-dessus à ce périmètre seulement.
Dans la plupart des cas, trois décisions débloquent l’essentiel : nommer un responsable métier par référentiel utilisé, désigner la source qui fait foi, et transformer les deux ou trois champs libres qui servent à décider en listes fermées. Le reste peut s’améliorer au fil de l’exploitation, avec des contrôles qui signalent les anomalies plutôt que de les laisser passer.
Il y a aussi des situations où l’automatisation n’est pas la bonne réponse tout de suite. Si les référentiels sont en cours de migration vers un nouvel ERP, si personne ne veut porter la responsabilité d’une donnée, ou si les règles du processus changent chaque mois, mieux vaut stabiliser d’abord. Automatiser à ce moment-là reviendrait à figer un désordre, et il faudrait tout reprendre ensuite. Dans ces cas, un chantier interne de nettoyage et d’organisation vaut mieux qu’un prestataire d’automatisation.
La suite logique
Si vous hésitez sur l’état réel des données d’un processus, la cartographie de processus sert précisément à observer le flux actuel, les sources, les exceptions et les accès, avant de décider ce qui peut être automatisé et à quelles conditions.