Comment mettre en place une gouvernance des données d’entreprise adaptée à une PME ?

Un même client apparaît deux fois dans le CRM, le chiffre d’affaires du tableau commercial ne correspond pas à celui de la comptabilité et personne ne sait quelle version retenir. Ces difficultés ne relèvent pas uniquement de la qualité des logiciels. Elles révèlent souvent une absence de responsabilités et de règles communes.

Pour une PME, mettre en place une gouvernance des données consiste à désigner les personnes qui décident, définir les règles applicables et vérifier régulièrement leur respect. L’objectif n’est pas de créer un service supplémentaire, mais de rendre les informations utilisées pour piloter l’entreprise plus fiables, traçables et compréhensibles.

Cette organisation peut démarrer avec quelques données critiques, une matrice de responsabilités dans un tableur et des contrôles périodiques. Elle doit aussi tenir compte des obligations de protection des données personnelles, sans confondre gouvernance métier et conformité au RGPD. La priorité reste de construire des règles suffisamment précises pour sécuriser les décisions, mais assez simples pour être appliquées par les équipes.

Pourquoi les problèmes de données persistent-ils sans responsable clairement identifié ?

Les problèmes de données persistent lorsqu’aucune personne ne possède l’autorité nécessaire pour décider de leur définition, de leur correction et de leur utilisation. Chaque service résout alors les anomalies selon ses propres besoins, sans supprimer leur cause commune. Les doublons, les incohérences et les arbitrages répétés deviennent progressivement des habitudes de fonctionnement.

Dans une PME, une fiche client peut être créée par un commercial, modifiée par l’administration des ventes et enrichie par la comptabilité. Si deux fiches correspondent au même client, chacun peut corriger son propre fichier sans que la base de référence soit réellement assainie.

Le problème est celui de la dilution des responsabilités. Les personnes disposent de droits de modification, mais aucune ne détient explicitement la responsabilité de trancher les conflits entre sources.

Un CRM peut imposer un numéro de client et un ERP peut vérifier certains formats. Ces contrôles techniques ne déterminent pourtant pas quel système fait autorité lorsqu’une adresse, une catégorie de produit ou un montant diffère. Cette décision relève d’une règle métier.

Le diagnostic peut commencer par trois données : le client, le produit et le chiffre d’affaires. Pour chacune, poser trois questions :

• Qui crée ou valide la donnée initiale ?
• Qui corrige une anomalie détectée ?
• Qui décide lorsque deux services présentent des informations contradictoires ?

Si plusieurs collaborateurs donnent des réponses incompatibles, une responsabilité doit être clarifiée. Ce test constitue un signal organisationnel, pas une mesure statistique de la qualité des données.

Dans les petites structures, le dirigeant ou un cadre polyvalent joue souvent spontanément le rôle d’arbitre. Cette centralisation peut fonctionner tant que les sollicitations restent limitées. Avec la croissance, elle risque de ralentir les corrections et de rendre l’entreprise dépendante d’une seule personne.

La première mesure consiste donc à attribuer les décisions au bon niveau métier, sans exiger que chaque anomalie remonte à la direction.

Une fois les domaines sans responsable identifiés, la prochaine étape consiste à formaliser les rôles dans un document utilisable par tous les services concernés.

Comment établir une matrice de responsabilités pour les données sensibles ?

Une matrice de responsabilités efficace associe chaque donnée sensible à un décideur métier, un responsable du suivi opérationnel, des personnes autorisées à la saisir et des utilisateurs identifiés. Pour une PME, il est préférable de commencer par cinq à dix données critiques et de consigner les responsabilités dans un tableau simple, plutôt que cartographier immédiatement tout le système d’information.

Quatre rôles permettent de structurer cette organisation :

• Data owner : décide des définitions, des règles et des arbitrages métier.
• Data steward : organise les contrôles, suit les anomalies et coordonne les corrections.
• Contributeur : saisit ou met à jour les informations dans le cadre des autorisations accordées.
• Utilisateur : consulte ou exploite les données pour réaliser son activité.

La Commission européenne décrit notamment cette distinction entre responsabilité métier et gestion opérationnelle dans son cadre de gouvernance des données de la Commission européenne. Ce document fournit un modèle organisationnel, non une obligation générale imposée aux PME françaises.

Pour démarrer, les domaines prioritaires peuvent comprendre les coordonnées clients, les identifiants fournisseurs, les informations de paie, les données contractuelles et les indicateurs financiers. Le choix dépend de leur sensibilité, de leur fréquence d’utilisation et des conséquences possibles d’une erreur.

Une matrice peut prendre cette forme, à titre d’exemple pédagogique :

Ces attributions sont indicatives : elles doivent être adaptées aux fonctions réellement exercées. Chaque domaine doit avoir un décideur final identifiable, même lorsque plusieurs équipes contribuent à sa gestion.

Pour les données personnelles, cette matrice doit s’articuler avec le registre des traitements, les habilitations et les responsabilités juridiques prévues par le RGPD. Le data owner est une fonction de gouvernance interne : il ne devient pas automatiquement responsable de traitement au sens juridique.

La CNIL explique comment identifier le responsable de traitement et le sous-traitant à partir des décisions réellement prises sur les finalités et les moyens du traitement. Dans une PME, l’entreprise elle-même est fréquemment responsable de traitement, tandis qu’un salarié exerce une responsabilité métier déléguée.

La matrice devient réellement opérationnelle lorsque les personnes désignées connaissent aussi la frontière entre leurs responsabilités de décision et leurs missions de contrôle.

Data owner ou data steward : qui doit valider les règles de qualité ?

Le data owner valide les règles de qualité qui engagent le métier : définitions, seuils acceptables, priorités et traitement des exceptions. Le data steward prépare leur application, coordonne les contrôles et suit les corrections. Dans une PME, ces fonctions peuvent être cumulées, à condition que l’autorité de décision reste explicite et que les règles soient documentées.

La distinction repose sur deux questions complémentaires : que doit signifier la donnée ? et comment garantir qu’elle respecte cette définition ?

Le propriétaire métier répond à la première. Le steward transforme la décision en consignes opérationnelles, critères de contrôle et procédures de correction.

Prenons la notion de client actif. La règle « un client actif est un client qui commande » laisse ouvertes plusieurs interprétations. Une définition telle que « un client est actif s’il a commandé dans les 24 derniers mois » est vérifiable, sous réserve que cette période corresponde réellement aux besoins de l’entreprise.

Le data owner valide la période et les exceptions éventuelles. Le data steward vérifie que les dates de commande sont disponibles, que le calcul est correctement appliqué et que les anomalies peuvent être corrigées.

Le modèle de responsabilité des données du gouvernement britannique distingue également les décisions métier, la gestion quotidienne et les opérations techniques. Cette référence concerne initialement l’administration britannique ; elle constitue une aide méthodologique, pas une norme obligatoire en France.

Dans une petite entreprise, le responsable commercial peut être à la fois owner et steward des données clients. Ce cumul n’est pas nécessairement problématique si la charge reste maîtrisable. Il devient plus fragile lorsque la personne doit arbitrer ses propres erreurs sans regard extérieur.

Pour choisir le propriétaire, le critère déterminant n’est donc pas la maîtrise du CRM ou de l’ERP. Il faut rechercher la fonction qui assume les conséquences métier d’une donnée incorrecte : devis erroné, relance inappropriée, mauvaise prévision ou décision financière biaisée.

Les règles techniques, comme un format de date ou une contrainte d’unicité, peuvent être élaborées avec les équipes informatiques. Toutefois, leur impact sur le travail quotidien doit être validé par le responsable métier concerné.

Une règle correctement attribuée ne suffit cependant pas : elle doit aussi pouvoir être respectée dans les conditions concrètes de travail des équipes.

Les règles de gouvernance impossibles à appliquer dans les équipes opérationnelles

Une gouvernance des données peut échouer malgré des responsabilités clairement définies lorsque ses règles ralentissent excessivement les opérations. Les exigences de saisie disproportionnées, les validations systématiques et les contrôles incompatibles avec les délais métier incitent parfois les collaborateurs à contourner le dispositif.

Imaginons un commercial qui doit créer une fiche prospect pendant un appel. Si le CRM exige immédiatement un identifiant d’entreprise vérifié, une adresse complète et plusieurs informations administratives encore inconnues, la création peut devenir impossible.

Le collaborateur risque alors de renseigner une valeur provisoire fictive, d’utiliser une fiche existante ou de conserver ses informations dans un fichier parallèle. La règle destinée à améliorer la qualité produit l’effet inverse.

La solution consiste à adapter les exigences au cycle de vie de la donnée.

Ce modèle est illustratif : les champs réellement obligatoires dépendent des activités, des exigences légales et des logiciels utilisés. Certaines informations doivent être vérifiées dès la création lorsqu’un risque particulier le justifie.

Avant de généraliser une règle, un pilote sur une équipe et un cycle de travail complet permet de mesurer le temps de saisie, la proportion de champs correctement renseignés et les difficultés rencontrées.

Les retours doivent déboucher sur des modifications concrètes : retirer un blocage inutile, préciser une consigne ambiguë ou prévoir une validation différée. Une exception documentée est préférable à une donnée fictive impossible à distinguer d’une information fiable.

Le pilote permet d’améliorer les règles avant leur déploiement ; des contrôles réguliers permettront ensuite de vérifier qu’elles restent adaptées lorsque l’organisation évolue.

Quels contrôles trimestriels instaurer pour vérifier la gouvernance des données ?

Un contrôle trimestriel de gouvernance doit examiner trois dimensions : les responsabilités sont-elles toujours attribuées, les données respectent-elles les règles de qualité et les équipes utilisent-elles les sources validées ? Une PME peut commencer avec un échantillon de dossiers par service, quelques indicateurs simples et une réunion courte consacrée aux décisions correctives.

Le premier volet est un contrôle de conformité organisationnelle. Il consiste à vérifier que les propriétaires de données sont toujours en poste, que les délégations sont à jour et que les règles de modification correspondent aux pratiques réelles.

Le deuxième volet mesure la qualité. Selon les données concernées, les indicateurs peuvent comprendre :

• Le taux de doublons détectés dans un échantillon de fiches clients.
• La proportion de champs obligatoires manquants.
• Le nombre d’anomalies non résolues depuis le précédent contrôle.
• La fréquence des corrections manuelles répétées.

Le troisième volet examine l’utilisation des données. Un reporting commercial peut être techniquement exact tout en s’appuyant sur un export obsolète ou une définition du chiffre d’affaires différente de celle retenue par la direction financière.

Pour éviter un audit disproportionné, sélectionner quelques fiches représentatives par service et tracer les anomalies observées. Cet échantillonnage permet de détecter des dérives, mais ne garantit pas l’absence d’erreurs dans l’ensemble de la base.

La réunion de gouvernance doit ensuite transformer les constats en décisions. Chaque anomalie importante reçoit un responsable, une action corrective et une échéance. Les désaccords entre services sont arbitrés par le propriétaire métier compétent.

Un signal mérite une attention particulière : le retour des mêmes corrections manuelles à chaque trimestre. Il peut indiquer une règle mal définie, un contrôle placé trop tard dans le processus ou une mauvaise synchronisation entre applications.

Dans ce cas, rappeler les consignes aux collaborateurs ne suffit pas. Il faut rechercher pourquoi l’erreur est créée et modifier le processus à son origine.

Cette logique conduit naturellement à renforcer les contrôles au moment où les données sont enregistrées, sans bloquer inutilement les opérations.

Comment contrôler les champs obligatoires avant l’enregistrement d’une donnée métier ?

Pour contrôler les champs obligatoires, il faut distinguer les informations indispensables à l’enregistrement, celles dont l’absence justifie une alerte et celles qui peuvent être vérifiées ultérieurement. Le niveau de contrôle dépend du risque métier, de la maturité du dossier et des obligations applicables. Un blocage doit toujours correspondre à une nécessité identifiable.

Trois mécanismes peuvent être paramétrés dans les applications :

• Blocage : l’enregistrement est refusé tant qu’une information critique n’est pas correctement renseignée.
• Alerte : l’utilisateur est informé d’une anomalie, mais peut poursuivre avec une justification ou une correction ultérieure.
• Contrôle différé : les données incomplètes sont recensées et vérifiées lors d’une opération de qualité programmée.

Le choix doit être documenté champ par champ. Un numéro de dossier indispensable à une opération peut nécessiter un blocage, tandis qu’une information commerciale secondaire peut être complétée plus tard.

Multiplier les champs bloquants peut inciter les utilisateurs à saisir « N/A », une date fictive ou un identifiant provisoire non reconnu comme tel. Ces valeurs sont particulièrement problématiques lorsqu’elles passent ensuite les contrôles de présence.

Un contrôle efficace doit donc aller au-delà de la simple vérification d’un champ non vide.

La matrice de responsabilités doit préciser qui valide les critères, qui paramètre les contrôles et qui tranche lorsqu’un cas particulier est bloqué. Sans responsable accessible, une règle technique peut interrompre un processus sans solution opérationnelle.

Enfin, les anomalies refusées ou signalées doivent pouvoir être suivies. Un contrôle qui empêche une erreur sans permettre d’identifier sa fréquence prive l’entreprise d’une information utile pour améliorer le processus.

Une donnée correctement créée doit ensuite rester maîtrisée pendant toute sa durée d’utilisation, jusqu’à son archivage ou sa suppression.

Archivage intermédiaire ou suppression définitive pour des dossiers clôturés ?

Un dossier clôturé doit être archivé lorsqu’une obligation de conservation ou un besoin légitime justifie de le conserver après son utilisation courante. Il doit être supprimé lorsque sa conservation n’est plus nécessaire et qu’aucune autre justification applicable ne subsiste. Pour les données personnelles, cette décision doit respecter le principe de limitation de la durée de conservation.

Trois critères permettent d’organiser l’arbitrage : les obligations légales applicables, l’utilité historique ou analytique des informations et les risques liés à leur conservation ou à leur réutilisation.

Les délais varient selon les catégories de documents : factures, pièces comptables, dossiers RH et données commerciales ne relèvent pas nécessairement des mêmes règles. Une durée unique appliquée à tous les dossiers serait donc inadaptée.

La CNIL détaille ces distinctions dans ses recommandations sur les durées de conservation des données. Elle distingue notamment la base active, l’archivage intermédiaire et, dans certains cas particuliers, l’archivage définitif.

L’archivage intermédiaire permet de retirer un dossier de l’utilisation quotidienne tout en conservant les informations nécessaires à une obligation ou à une finalité justifiée. Pour les données personnelles concernées, l’accès doit être limité aux personnes habilitées et la séparation avec la base active doit être organisée.

À l’inverse, une simple mention « inactif » dans un CRM ne constitue pas nécessairement un archivage satisfaisant. Si les fiches continuent d’alimenter les campagnes, les exports et les statistiques, elles restent exploitées dans les processus courants.

La suppression dite douce, qui masque une fiche sans la purger, doit donc être encadrée. Il faut définir une durée, les conditions d’accès, la procédure de suppression effective et les éventuelles exceptions justifiées.

La conservation d’informations historiques pour des analyses peut être pertinente, mais elle ne dispense pas de respecter les règles applicables aux données personnelles. Lorsque le besoin porte uniquement sur des tendances, l’utilisation de données réellement anonymisées peut être étudiée.

Chaque catégorie de dossiers devrait disposer d’une règle écrite précisant son événement de clôture, sa durée de conservation, sa destination et le responsable de son élimination.

Cette maîtrise du cycle de vie complète la gouvernance : les informations utilisées pour piloter l’activité doivent être fiables, mais aussi pertinentes et correctement délimitées dans le temps.

Comment fiabiliser les données d’entreprise utilisées pour piloter les activités ?

Pour fiabiliser les données de pilotage, une PME doit commencer par les indicateurs réellement utilisés pour décider, identifier leurs sources et attribuer la responsabilité de leurs définitions. La méthode consiste ensuite à documenter les règles de calcul, résoudre les divergences entre systèmes et contrôler périodiquement les résultats, sans chercher à nettoyer toutes les données simultanément.

Une première sélection de dix à quinze indicateurs peut constituer un périmètre de travail raisonnable : chiffre d’affaires par client, marge, trésorerie disponible, encours fournisseurs ou évolution du portefeuille commercial, selon les priorités de l’entreprise.

Pour chaque indicateur, il faut remonter jusqu’aux données qui alimentent son calcul. Cette démarche permet de découvrir les divergences de définition et les transformations manuelles qui échappent aux contrôles.

Par exemple, un tableau commercial peut présenter les commandes signées tandis qu’un rapport comptable présente les factures enregistrées. Les deux montants peuvent être exacts dans leurs périmètres respectifs, mais ils ne mesurent pas nécessairement le même phénomène.

La gouvernance doit donc préciser la période, le périmètre, les exclusions et la source retenue. La notion de source de référence partagée ne signifie pas qu’un logiciel doit nécessairement contenir toutes les informations. Elle signifie que chaque donnée clé possède une autorité clairement définie.

Lorsque le CRM, la gestion commerciale et la comptabilité divergent, les règles d’arbitrage doivent être connues avant la production du reporting. Une correction manuelle ponctuelle doit être tracée, expliquée et, si possible, remplacée par un traitement reproductible.

Le dispositif complet repose alors sur une chaîne cohérente :

1. Identifier les responsables des données qui alimentent les décisions.
2. Valider les définitions métier et les règles de calcul.
3. Organiser une saisie et des corrections compatibles avec les opérations.
4. Contrôler la qualité, les divergences et les usages des sources.
5. Gérer l’actualisation, l’archivage et la suppression selon le cycle de vie applicable.

Cette approche évite de confondre qualité et uniformité. Deux chiffres différents peuvent être légitimes s’ils répondent à des définitions distinctes ; ils deviennent problématiques lorsque leur signification n’est pas explicitée.

Le dirigeant doit également pouvoir retrouver la provenance d’un indicateur contesté. Sans cette traçabilité, les équipes risquent de perdre confiance dans les tableaux de bord et de revenir à leurs propres fichiers de suivi.

La gouvernance ne garantit pas l’absence totale d’erreurs. Elle rend néanmoins les responsabilités, les contrôles et les arbitrages suffisamment explicites pour détecter et traiter les écarts qui compromettent les décisions.

Une action concrète consiste à réunir les responsables commercial, financier et opérationnel autour de trois indicateurs contestés, puis à documenter pour chacun sa définition, sa source et son décideur. Ce premier référentiel peut ensuite être élargi progressivement aux autres données critiques.