Empêcher les mauvaises données d'entrer

🌐 Aussi en 28 langues

English · Español · 日本語 · Português (Brasil) · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Image générée par IA

Traduit par IA. Pas encore relu par la communauté. Lire en anglais

Module 2 sur 6 du chapitre Qualité et gouvernance des données, chapitre 5 du cours Data Architect. Chaque module est autonome. Précédent : La gouvernance se conçoit dans l’organisation · Suivant : Connaître ses données

La question à laquelle répond ce module : comment rendre les données bonnes, et les garder ainsi ?

Il y a deux façons de traiter les mauvaises données : les arrêter avant qu’elles n’entrent, ou les nettoyer après. Vous ferez un peu des deux. Mais si j’ai le choix, je préfère prévenir le problème plutôt que de bâtir une organisation autour de son nettoyage perpétuel. Doublons, mauvais identifiants, informations manquantes, valeurs non standard, utilisateurs qui modifient des champs qu’un autre système possède, intégrations qui écrasent de bonnes données avec de mauvaises : tout cela devient le projet de nettoyage de quelqu’un. La question de conception est donc : quelles mauvaises données puis-je raisonnablement tenir à l’écart dès le départ ? Et « raisonnablement » compte, car la réponse n’est pas de verrouiller chaque champ jusqu’à rendre le système inutilisable.

« Assez bon » est une définition métier

Avant d’empêcher les mauvaises données, définissez les bonnes. Il n’y a pas de définition unique. Bon peut vouloir dire assez complet pour faire tourner le processus, assez exact pour décider, assez à jour pour la charge de travail, assez cohérent pour être combiné avec d’autres systèmes, assez unique pour savoir de quel client on parle, assez standard pour l’automatisation, assez traçable pour savoir d’où il vient. Cela dépend des données. Si Steve Trucking facture un partenaire distributeur, l’identité juridique du partenaire doit être juste. Si un commercial prend des notes après une réunion, personne n’a besoin d’un comité pour approuver chaque phrase. « Assez bon » est une définition métier ; l’architecte la rend mesurable et applicable.

Prévenez les erreurs coûteuses

Tous les mauvais champs ne méritent pas la même attention. Je m’intéresse surtout aux erreurs qui ont des conséquences en aval. Un client en double, c’est deux historiques de ventes, deux historiques de service, deux ensembles de contacts, deux ID externes, deux intégrations qui synchronisent la même entreprise, deux versions dans l’entrepôt de données et dans Data 360, et à la fin un agent qui décide quel client est le vrai. C’est bien plus coûteux qu’une faute de frappe dans une description. Alors ne commencez pas par « comment valider chaque champ ? » Commencez par quelles mauvaises données créent le plus gros problème métier ou d’architecture ? et placez-y les contrôles les plus forts.

Ouvert ou verrouillé ?

La création de comptes est l’exemple classique. Chaque commercial doit-il pouvoir créer un compte ? Ma réponse : cela dépend de la gouvernance autour des données. Pour la plupart des petites et moyennes organisations, une création ouverte convient. Un commercial rencontre un prospect, crée le compte, se met au travail ; c’est à cela que sert un CRM. Les règles de doublons, les informations obligatoires et l’intendance gèrent la qualité. Je n’ajoute pas un processus d’approbation lourd simplement parce que la gouvernance a l’air responsable.

Changez maintenant le paysage. Le client juridique est maîtrisé dans l’ERP, arrive dans Salesforce avec un identifiant ERP, et l’ERP fait autorité. Maintenant, une création ouverte veut dire deux façons de créer la même entité gouvernée. Quand l’ERP et un commercial créent tous les deux la même entreprise, lequel l’emporte, quel identifiant les intégrations utilisent-elles, quel enregistrement porte l’historique ? La création ouverte cesse d’être une question d’ergonomie et devient une question de données maîtres. Quand les comptes sont maîtrisés dans un ERP ou synchronisés avec lui, verrouillez la création.

Mais tout verrouiller échoue aussi. Le commercial a rencontré un prospect qui n’est pas dans l’ERP et veut ouvrir une opportunité, et le modèle de gouvernance dit « pas de compte pour vous ». Alors il attend trois jours la Finance, ou rattache l’opportunité au mauvais compte, ou garde le prospect dans un champ de notes ou un tableur. Nous avons protégé le modèle de données et abîmé le métier.

La voie médiane : un type d’enregistrement provisoire

Voici la voie médiane que j’aime. Laissez les ventes créer le compte avec un type d’enregistrement spécifique, un type prospect ou provisoire, et contrôlez sa conversion vers le type gouverné. Les ventes saisissent l’entreprise et commencent à vendre. L’enregistrement dit clairement : pas encore établi dans le système qui fait autorité. Puis un processus contrôlé le convertit : la Finance l’approuve, ou une intégration le soumet à l’ERP, qui soit le rapproche d’un client existant, soit en crée un nouveau et renvoie l’identifiant qui fait autorité. L’enregistrement franchit alors une frontière, provisoire → gouverné, ce qui est très différent de deux systèmes qui créent chacun ce qu’ils croient être l’enregistrement maître.

Le type d’enregistrement est le mécanisme que j’enseigne. Quoi que vous utilisiez, rendez l’état visible dans les données : d’où vient l’enregistrement, s’il a franchi la frontière, qui peut le modifier désormais, et l’identifiant qui le relie au système qui fait autorité. L’ID client de l’ERP, qui n’existe qu’après la conversion, est le signal le plus clair de tous.

Un type d’enregistrement par flux

Mettez tout le flux sur une seule image et vous verrez pourquoi cela fonctionne. Les clients et les produits arrivent de l’ERP. Les opportunités et leurs lignes repartent et deviennent les commandes de l’ERP. Et les comptes ? Certains arrivent, d’autres repartent. Un schéma courant que j’ai vu d’une implémentation à l’autre consiste donc à avoir deux types d’enregistrement sur le compte, un pour chaque sens. Un compte Ventes naît dans Salesforce : les commerciaux le créent, le modifient, lui vendent, et quand il devient client, il est envoyé à l’ERP. Un compte ERP (je l’ai appelé Client, ou simplement SAP) naît dans l’ERP et arrive par l’intégration. Personne ne crée ce type d’enregistrement à part l’intégration, et ses champs de données maîtres (raison sociale, adresses, conditions de paiement) sont en lecture seule pour les utilisateurs. Le type d’enregistrement vous dit dans quel sens circule l’enregistrement, donc le sens de la maîtrise est visible directement sur l’enregistrement.

Click to enlarge

Un type d’enregistrement par flux : les comptes Ventes sortent, les comptes ERP entrent.

Cela ne supprime pas le cas difficile. Un commercial convertit une piste pour Steve’s Plumbing, mais Steve’s Plumbing existe déjà comme compte ERP, et, on ne sait comment, la vérification des doublons ne l’a pas détecté. Vous voilà en train de fusionner, de rattacher les enfants à un nouveau parent et de décider quel enregistrement survit (chapitre 6, module 3).

Et ne restez pas bloqué sur le type d’enregistrement lui-même. Normalement, j’évite les types d’enregistrement sauf s’il y a une bonne raison de les utiliser. Je les ai utilisés ici parce qu’avant Dynamic Forms (formulaires dynamiques), le type d’enregistrement choisissait la présentation de page, et une présentation affichait les champs ERP en lecture seule. Avec Dynamic Forms, des règles de visibilité peuvent afficher et masquer des champs selon la valeur d’un champ, un champ peut être en lecture seule sur une page donnée, et Salesforce lui-même dit que Dynamic Forms réduit le nombre de présentations de page et de types d’enregistrement dont vous avez besoin (Break Up Your Record Details with Dynamic Forms (opens in a new tab) ; Required and Read-Only Fields in Dynamic Forms (opens in a new tab), en anglais). Mais en lecture seule sur une page veut dire en lecture seule sur cette page : l’API, un chargement de données ou une intégration peuvent toujours écrire dans le champ. La vraie application, c’est la sécurité au niveau du champ ou une règle de validation ; une validation dans l’interface n’est pas une validation des données (chapitre 3, module 9). Les types d’enregistrement méritent encore leur place quand les deux sortes de comptes ont besoin de valeurs de liste de sélection ou de processus métier différents. Ce qui compte vraiment, c’est qu’un champ dise clairement d’où vient l’enregistrement : la clé ERP elle-même, un indicateur de données maîtres ou une liste de sélection de source. Ensuite, pilotez la possibilité de modifier à partir de ce champ.

Click to enlarge

Du provisoire au gouverné : les ventes commencent à vendre tout de suite ; seul le processus qui fait autorité rend l’enregistrement gouverné.

Protégez l’enregistrement gouverné

Une fois que le client revient de l’ERP, son ID ERP, sa raison sociale, son identifiant fiscal et ses coordonnées de facturation sont des attributs gouvernés. Le commercial doit-il les modifier ? Pas si l’ERP les possède. C’est la politique du module 1 qui a besoin de son point d’application : l’ID ERP en lecture seule, l’identité juridique contrôlée, tandis que le commercial modifie toujours le territoire, les notes de relation et les classifications propres à Salesforce. Le but n’est pas un compte intouchable. C’est une ligne claire entre les données que Salesforce possède et les données que Salesforce référence. (Le préfixe erp_ du chapitre 4 rend cette ligne visible dans le schéma.)

Ce que vous obtenez au final, c’est un golden record qui est en réalité hybride. Les champs de données maîtres de l’ERP arrivent : raison sociale, adresses de facturation et de livraison, conditions de paiement. Puis Salesforce ajoute ses propres champs, qui ne repartent jamais : une note commerciale, la date de la dernière commande, à peu près tout ce qu’utilise le marketing. Même compte, deux sortes de champs, et chaque sorte a une seule source.

Le plus difficile, ce sont les bidirectionnels. Disons qu’un commercial a besoin que la raison sociale dans l’ERP passe de Steve’s Plumbing à Steve’s Plumbing LLC. Dans ces mêmes cinq minutes, quelqu’un dans l’ERP la change en Steve’s Plumbing L.L.C. Quel changement l’emporte ? Voici l’état d’esprit : si un champ est maîtrisé dans l’ERP, vous ne modifiez pas le champ, vous demandez à le modifier. Décidez de ce qui se passe quand la demande entre en collision : l’ERP l’emporte, la demande est rejetée si la valeur a changé entre-temps, ou elle attend qu’une personne tranche. Et décidez si les champs liés voyagent ensemble en un seul changement ou un par un. Le chapitre 6 va plus loin sur les collisions (Boucles et collisions).

Arrêtez les doublons à la porte

Les doublons s’accumulent. Attrapez-en un avant sa création et c’est un petit problème. Trouvez-le deux ans plus tard, avec des opportunités, des requêtes, des contacts, des factures, des intégrations et de l’analytique accrochés aux deux, et c’est un gros problème. Le module 7 du chapitre 3 a couvert les mécanismes (règles de correspondance, règles de doublons, ID externes uniques), je ne vais donc pas les réenseigner. La question de gouvernance est : où devons-nous empêcher la duplication, et où allons-nous la tolérer et la résoudre plus tard ? Une piste marketing occasionnelle peut vivre avec de l’ambiguïté. Un client gouverné par l’ERP avec des transactions financières, non.

Standardisez ce que lisent les machines

Le texte libre est merveilleux pour les personnes et terrible quand un système doit l’interpréter. Mettez Arizona, AZ, Ariz., Phoenix area et Southwest dans un champ qui pilote l’acheminement, et vous avez un problème de qualité. Si une valeur pilote l’automatisation, l’intégration, les rapports, la sécurité, l’attribution ou l’action d’un agent, réfléchissez sérieusement au niveau de standardisation dont elle a besoin. Tous les champs texte ne deviennent pas des listes de sélection, mais distinguez l’information que lisent les personnes de l’information sur laquelle décident les machines. La seconde mérite un contrôle plus fort.

Ne laissez pas les champs obligatoires créer de fausses données

Nous décidons qu’un champ compte et le rendons obligatoire. L’utilisateur ne connaît pas la réponse, le système ne le laisse pas continuer, alors il tape N/A, Unknown, 999999 ou test@test.com. Le champ est rempli ; les données sont des déchets. Avant de rendre quelque chose obligatoire, demandez-vous si l’utilisateur le connaît réellement à ce moment-là. Sinon, exigez-le plus tard dans le processus, laissez un autre système le fournir, utilisez l’état provisoire, ou proposez un Inconnu explicite quand « inconnu » est une réponse légitime. Une règle de validation peut appliquer une politique. Elle ne peut pas faire savoir à quelqu’un ce qu’il ne sait pas.

Chaque frontière de données a besoin d’une décision de qualité

Les personnes ne sont pas la seule source de mauvaises données ; les intégrations en produisent plus vite. Le manifeste d’un partenaire distributeur arrive avec quelques centaines de lignes. Une poignée ont des codes postaux invalides, deux ou trois citent un centre de distribution inconnu, deux répètent la même référence de commande. Que se passe-t-il ? Rejeter tout le fichier ? Accepter les bonnes lignes et renvoyer les mauvaises ? Tout charger et nettoyer plus tard ? Mettre les exceptions en quarantaine ? Qui est prévenu, et comment le partenaire apprend-il ce qui a échoué ? Il n’y a pas de réponse universelle, mais il doit y en avoir une. Le chapitre 4 disait que chaque flèche a besoin d’un mécanisme. Ajoutez : chaque frontière de données a besoin d’une décision de qualité : ce que nous acceptons, rejetons ou mettons en quarantaine, et qui possède l’exception.

Click to enlarge

Chaque frontière de données a besoin d’une décision de qualité.

Les données historiques sont différentes

RouteDesk contient huit ans d’historique de Steve Trucking, et sa qualité varie selon le centre de distribution. Devons-nous nettoyer les huit années selon les normes d’aujourd’hui avant de les déplacer ? Probablement pas automatiquement. À quoi servent-elles : les opérations quotidiennes, la consultation, les réclamations, les rapports, l’analyse de tendances ? Doivent-elles toutes être dans Salesforce, ou une partie peut-elle rester ailleurs ? Le chapitre sur la migration va en profondeur. Le point de gouvernance : l’historique n’a pas automatiquement besoin des mêmes normes que les données actives. Si vous allez prendre des décisions à partir de lui, la qualité compte. Si vous le gardez pour consultation, une autre norme peut suffire. Connaissez l’objectif avant de dépenser une fortune pour nettoyer le passé.

Mesurez ce sur quoi quelqu’un agira

La gouvernance n’est jamais terminée, alors vous devez voir quand la qualité glisse : taux de doublons en hausse, davantage d’enregistrements en quarantaine, davantage de rejets d’intégration, valeurs bouche-trou qui se répandent, davantage de demandes de contournement, rapports qui ne concordent plus. Mais ne construisez pas 150 indicateurs pour en ignorer 143. Pour Steve Trucking, ce sont peut-être les livraisons sans référence partenaire valide, les livraisons sans adresse exploitable, les références de commande répétées, les messages partenaires rejetés, les comptes bloqués à l’état provisoire. Un tableau de bord plein de pastilles vertes ne veut pas dire que les données sont bonnes. Mesurez ce sur quoi quelqu’un est prêt à agir.

Au-delà de l’examen : ce que l’IA change. Les mauvaises données deviennent de plus en plus de mauvaises actions. Une personne peut remarquer qu’un numéro de téléphone a l’air faux avant de l’appeler ; un agent utilise simplement la valeur qu’on lui donne. Les clients en double, les statuts périmés, les fausses valeurs obligatoires et les mauvais identifiants se transforment directement en mauvais message ou en mauvaise mise à jour. Cela augmente la valeur de la prévention. Cela ne supprime pas le besoin d’intendance.

Ce qu’un architecte décide ici

• Quels défauts de qualité font assez de dégâts pour justifier des contrôles préventifs.
• Si les enregistrements gouvernés sont créés librement, seulement par le système qui fait autorité, ou par un chemin provisoire → gouverné.
• Quels attributs Salesforce possède et lesquels il ne fait que référencer.
• Ce qui arrive aux données entrantes qui échouent aux contrôles (accepter, rejeter ou mettre en quarantaine) et qui possède l’exception.
• Quels signaux de qualité sont mesurés, pour que les data stewards voient le glissement.

Vous n’empêcherez jamais chaque mauvais enregistrement. Le travail n’est pas d’avoir des données parfaites ; c’est d’empêcher que des mauvaises données évitables deviennent des données coûteuses. Arrêtez le doublon avant qu’il n’ait deux ans d’historique. Protégez l’identifiant avant que dix intégrations ne dépendent du mauvais. Laissez les ventes créer le prospect, mais ne prétendez pas que c’est le client gouverné tant qu’il ne l’est pas. Et quand quelque chose de mauvais passe, assurez-vous que quelqu’un puisse le voir, en être responsable et le corriger.

Pour aller plus loin

• Aide Salesforce, Things to Know About Duplicate Rules (opens in a new tab) (en anglais), consulté le 2026-10-14.
• Aide Salesforce, Break Up Your Record Details with Dynamic Forms (opens in a new tab) et Required and Read-Only Fields in Dynamic Forms (opens in a new tab) (en anglais), consulté le 2026-10-14.