Garbage in, garbage out: pourquoi l’IA et la Marketing Automation échouent sans vérification des données

Dans les technologies marketing d’entreprise, la pression augmente pour automatiser toujours davantage de processus. Les organisations connectent des Large Language Models aux plateformes CRM, enrichissent les profils clients avec des sources de données externes, génèrent du contenu à partir d’entrées API et intègrent des mécanismes de décision dans des journeys qui fonctionnent en grande partie sans intervention humaine. Les possibilités techniques ne cessent de s’étendre. Le principal risque de l’automatisation se déplace donc vers la qualité, la signification et la gouvernance des données sur lesquelles cette automatisation repose. Les systèmes modernes peuvent sembler convaincants alors même que leur logique sous-jacente est incorrecte. Un tableau de bord peut effectuer des calculs exacts, un texte généré peut être rédigé de manière professionnelle et un visuel peut soutenir un récit apparemment cohérent. Pourtant, une seule définition de produit erronée, une règle d’autorisation manquante ou un contexte incorrect peut se propager dans toute une chaîne et affecter simultanément plusieurs processus. La principale vulnérabilité de l’automatisation basée sur l’IA n’est donc pas que les systèmes puissent commettre des erreurs, mais qu’ils puissent multiplier ces erreurs rapidement, de manière cohérente et convaincante. Le principe classique garbage in, garbage out redevient ainsi particulièrement actuel. Non pas parce que les organisations manquent de technologie, mais parce que l’IA générative et les architectures d’intégration accélèrent la propagation de données de mauvaise qualité. Pour construire une automatisation fiable, il faut donc aller au-delà de la simple connectivité technique. La question n’est pas uniquement de savoir si les systèmes peuvent échanger des données, mais si la signification de ces données reste intacte à chaque étape.

Une erreur qui semble professionnelle reste une erreur

Un exemple concret est celui d’une infographie générée automatiquement qui comparait l’évolution historique d’un prix sur plus de quarante ans. La présentation semblait soignée et quantitativement solide. Elle comportait des montants, des pourcentages et une chronologie claire. À première vue, il y avait peu de raisons de remettre le résultat en question. Un examen plus approfondi a toutefois révélé que différentes sources de données et définitions d’objets avaient été mélangées. Le prix historique concernait un produit vendu séparément, tandis que le prix actuel était associé à une offre groupée incluant des composants supplémentaires et d’autres conditions commerciales. Les informations historiques relatives à la devise n’avaient pas non plus été suffisamment contrôlées. Le modèle avait combiné différents contextes dans une comparaison chiffrée unique qui semblait cohérente en interne, mais qui était méthodologiquement incorrecte. Un système peut fonctionner correctement sur le plan mathématique tout en produisant une conclusion erronée sur le fond. Cela se produit lorsque la validation se limite au format d’un champ, tandis que sa sémantique reste hors du contrôle. Sans contexte, une valeur numérique valide ne dit rien sur le type de produit, le canal de vente, la TVA, les frais de livraison, les conditions contractuelles ou la comparabilité historique. Pour les architectures d’entreprise, cela signifie que la validation technique doit être complétée par des contrôles fonctionnels et contextuels. Quatre questions permettent de rendre ce contrôle concret:

• Comparons-nous réellement le même produit, la même offre ou le même objet?
• Le prix ou le statut appartient-il au même canal de vente et au même public cible?
• Le contexte historique ou commercial est-il réellement comparable sur le fond?
• La source utilisée est-elle la source de référence pour cette application spécifique?

Les visuels générés peuvent également renforcer une interprétation erronée. Dans l’exemple cité, le produit moderne était représenté visuellement comme nettement plus grand que le produit historique, ce qui pouvait rendre le prix plus élevé plus logique. Avec l’IA multimodale, la contamination des données ne se limite donc pas aux champs textuels ou aux tableaux numériques: la génération d’images peut également renforcer une hypothèse de départ incorrecte. Le problème apparaît dans une chaîne où différents composants reprennent le même postulat erroné sans contradiction. Un modèle interprète les données sources, un composant suivant transforme le résultat en texte, un générateur d’images traduit le même contexte en visuel et un flux de publication met le résultat en ligne. Chaque étape peut fonctionner correctement sur le plan technique alors que le résultat global reste incorrect sur le fond.

Les hallucinations des LLM ne naissent pas uniquement dans le modèle

Dans les discussions sur l’IA générative, l’hallucination est souvent présentée comme une caractéristique propre au modèle de langage. Dans les environnements d’entreprise, cette vision est trop limitée. Un LLM peut inventer des informations ou compléter des hypothèses sans fondement fiable, mais de nombreuses erreurs apparaissent plus tôt dans l’architecture qui l’entoure: dans le choix des sources, le mapping des données, les métadonnées, la couche d’autorisation ou la logique utilisée pour construire le contexte. Un modèle qui fonctionne via une intégration peut par exemple recevoir des données provenant d’un flux produit, d’un objet CRM, d’un data lake ou d’une API externe. Si la sémantique de ces données n’est pas explicitement définie, le modèle doit lui-même déduire les relations. Un champ de prix sans métadonnées complémentaires n’indique pas si le montant inclut la TVA, si les frais de livraison sont compris, s’il s’agit d’un prix B2B ou B2C, si le prix est temporaire ou si le produit est réellement disponible pour le compte qui interroge les données. Pour un humain, ces différences peuvent sembler évidentes. Pour un système, il s’agit d’attributs distincts qui doivent être explicitement modélisés. Si ce contexte manque, un modèle génératif peut paraître extrêmement convaincant alors que l’interprétation choisie est incorrecte.

Un appel API techniquement réussi prouve que les systèmes peuvent communiquer. Il ne prouve pas que les données reçues sont fonctionnellement adaptées à la décision qui suit.

Une architecture d’entreprise doit donc distinguer la connectivité de la fiabilité. Un endpoint peut être parfaitement accessible tout en fournissant des données inadaptées. Une intégration n’est réellement utile que lorsque les données sont non seulement techniquement valides, mais également cohérentes avec le contexte métier dans lequel elles sont utilisées. Cela est particulièrement important pour les organisations marketing. Dès que l’IA générative est connectée à Salesforce, Marketing Cloud, Account Engagement, des plateformes de commerce ou des sources de données externes, une classification incorrecte peut déclencher des journeys inappropriés, sélectionner les mauvais publics, promouvoir des produits indisponibles ou produire des rapports qui sont ensuite considérés en interne comme fiables. L’erreur passe alors du niveau du contenu au niveau du processus.

Le même SKU ne correspond pas toujours à la même offre

Un deuxième cas pratique montre pourquoi le rapprochement traditionnel des données peut être insuffisant. Imaginons qu’un fabricant ou un fournisseur propose le même produit sur un site destiné aux consommateurs et sur un portail professionnel. Le code EAN et le SKU sont identiques. Une intégration simple conclut donc qu’il s’agit du même produit disponible. Techniquement, cette identification est correcte, mais commercialement l’offre peut être différente. Un fournisseur peut proposer activement un produit sur son site B2C tout en le bloquant pour ses partenaires professionnels, en le réservant à certains comptes ou en le marquant comme indisponible dans le portail B2B. Des décisions commerciales délibérées peuvent expliquer cette situation: stratégie de canal, gestion des marges, conditions contractuelles, priorisation des stocks ou droits de distribution. Pour un flux générique, le produit existe. Pour le compte professionnel concerné, l’offre n’existe en pratique pas. Lorsqu’un pipeline de catalogue automatisé ne prend en compte que l’EAN, le SKU, le prix et un statut de stock générique, une contamination du catalogue apparaît. Le système synchronise un produit que le segment de clientèle concerné ne peut réellement pas commander. Cette erreur peut ensuite se propager au commerce, aux campagnes, à la communication sur les stocks, au service client et au reporting. Ce type de problème n’apparaît souvent qu’après qu’une organisation a déjà construit une automatisation importante. Les équipes techniques voient un identifiant correctement rapproché, tandis que les opérations constatent que le produit ne peut pas être livré. L’architecture échoue parce que la disponibilité a été modélisée à tort comme un attribut universel unique.

Les droits B2B et B2C doivent faire partie du modèle de données

Une architecture d’entreprise devient plus robuste lorsque la disponibilité n’est pas traitée comme un simple champ binaire, mais comme une combinaison de conditions. La question pertinente n’est pas uniquement ce produit est-il en stock? La meilleure question est: ce produit est-il disponible pour ce compte, via ce canal, selon ces conditions commerciales et à ce moment précis? Le modèle de données doit donc contenir davantage de contexte que la seule identification du produit et le stock. Le type de compte, le segment de clientèle, le canal de vente, le statut contractuel, les droits d’accès au catalogue, le stock par contexte de distribution, les règles tarifaires et les périodes de validité peuvent tous déterminer si un enregistrement peut réellement être activé. Ce n’est que lorsque ces attributs sont disponibles sous forme de règles métier distinctes qu’une couche d’intégration peut déterminer de manière fiable si un enregistrement peut être transmis à une boutique en ligne, une campagne, un processus commercial ou une application d’IA. C’est également ici que la distinction entre intégration, harmonisation et activation devient importante. Une couche middleware ou d’intégration, par exemple via MuleSoft ou une autre forme d’orchestration API, peut récupérer les données et appliquer des règles opérationnelles. Salesforce Data Cloud peut ensuite harmoniser les données provenant de différentes sources et les rendre disponibles pour la segmentation et l’activation. Marketing Cloud et Account Engagement peuvent ensuite utiliser ce contexte validé dans les communications et les journeys. Aucune de ces couches ne remplace toutefois la nécessité de définir correctement les règles métier en amont. Une implémentation Data Cloud ne corrige pas automatiquement une mauvaise définition de source. Si un champ de disponibilité est mal modélisé sur le plan sémantique, le principal résultat est une erreur diffusée de manière plus cohérente.

Une Single Source of Truth est plus qu’une base de données unique

De nombreuses organisations cherchent à établir une Single Source of Truth. Ce concept est parfois réduit à une base de données centrale unique ou à un enregistrement CRM de référence, mais un emplacement central peut toujours contenir des informations incorrectes, obsolètes ou dépourvues de contexte. La centralisation ne crée de valeur que lorsqu’il est clairement défini quelle source est de référence pour chaque attribut et dans quelles conditions cette source peut être utilisée. Un ERP peut par exemple être la source de référence pour les prix, un système de consent management pour les autorisations marketing et une plateforme contractuelle ou de commerce pour les droits associés aux comptes. La vérité ne réside alors pas dans une seule application, mais dans des accords clairs sur l’autorité des sources, l’actualité, l’utilisation des données et leur validité. Cela devient encore plus important lorsque des LLM sont utilisés comme interface au-dessus de plusieurs sources de données. Dans une seule réponse, un modèle peut combiner des informations issues du CRM, des données de support, des catalogues produits et des sources externes. Sans hiérarchisation claire des sources, il peut fusionner des informations contradictoires dans une réponse qui semble crédible mais qui n’existe nulle part comme vérité validée. Dans les environnements d’entreprise, il faut donc documenter non seulement l’origine des données, mais également pourquoi cette source est considérée comme fiable pour ce contexte précis. La data lineage, la priorité des sources, les timestamps, le statut de validation et les droits d’accès ne sont donc pas de simples détails administratifs, mais des composants fonctionnels de la gouvernance de l’IA.

De la validation des données à une architecture tolérante aux erreurs

La validation des données est traditionnellement considérée comme un contrôle technique des champs obligatoires, des types de données, des formats et des doublons. Pour les processus marketing basés sur l’IA, une approche plus large est nécessaire. L’architecture doit également pouvoir identifier des anomalies sémantiques, commerciales et contextuelles et y répondre de manière sûre.

Une organisation peut par exemple contrôler un prix en fonction de son type de données et de sa devise, tout en évaluant si l’écart par rapport à la période précédente est plausible. Un flux produit peut être techniquement complet mais tout de même bloqué si le droit B2B requis est absent. Une sortie LLM peut être syntaxiquement correcte mais être renvoyée pour vérification si la justification par les sources manque ou si différentes sources de données se contredisent. Le passage de la validation à la tolérance aux erreurs signifie également que les systèmes ne doivent pas uniquement détecter les erreurs, mais disposer d’un processus de suivi sûr. Un enregistrement incertain est placé en quarantaine au lieu d’être publié. Un statut d’autorisation manquant bloque l’activation. Lorsque les éléments de preuve sont insuffisants, un modèle ne doit pas inventer de valeur, mais revenir à inconnu, à une vérification supplémentaire des sources ou à une évaluation humaine.

Couche d’architecture	Risque fréquent	Contrôle requis
Données sources	Enregistrements obsolètes, sans contexte ou contradictoires	Autorité des sources, timestamps et règles de qualité des données
API et intégration	Données techniquement valides mais fonctionnellement incorrectes	Règles métier, droits et logique de canal
Harmonisation	Des enregistrements incorrects sont correctement fusionnés	Modèle de données sémantique et priorité des sources
Couche LLM et IA	Hallucination ou ajout non justifié	Grounding, vérification des sources et seuils de confiance
Activation	Une sortie incorrecte atteint un client ou un collaborateur	Approval flows, règles de quarantaine et monitoring

C’est précisément cette combinaison qui fait la différence entre une démonstration techniquement impressionnante et une solution pouvant être déployée de manière responsable à l’échelle de l’entreprise. La qualité d’une architecture ne se révèle pas uniquement lorsque tout fonctionne correctement, mais surtout dans la manière dont le système gère l’incertitude, les sources contradictoires et le contexte manquant.

Le data steward humain reste indispensable

La solution ne consiste pas à revenir sur l’automatisation, mais à définir les points auxquels l’expertise humaine apporte le plus de valeur. Un data steward ou un responsable fonctionnel identifie souvent des éléments qu’un système ne comprend pas spontanément: une hausse de prix peut être techniquement correcte mais commercialement improbable; un produit peut être visible publiquement mais ne pas être livrable contractuellement; un montant historique peut avoir été correctement converti tout en correspondant à une autre offre. Ce contrôle ne signifie pas que chaque sortie individuelle doit être examinée manuellement. La gouvernance d’entreprise consiste plutôt à identifier les exceptions pour lesquelles une intervention humaine est nécessaire. Il peut s’agir de données sources contradictoires, de faibles scores de confiance, de variations de prix inhabituelles, de nouvelles catégories de produits, de modifications des droits associés aux comptes ou de situations dans lesquelles plusieurs systèmes se contredisent. Une architecture mature rend ces exceptions visibles avant qu’un processus ne soit entièrement automatisé. Human-in-the-loop n’est alors pas un frein d’urgence ajouté après coup, mais une exigence explicite de conception. L’humain ne contrôle pas chaque enregistrement, mais définit les limites dans lesquelles le système peut agir de manière autonome. Plusieurs principes de conception sont particulièrement importants pour cette gouvernance:

• Distinguer les données sources validées, les données dérivées et les données générées par l’IA.
• Enregistrer la source, le timestamp et le statut de validation des données utilisées downstream.
• Définir explicitement quelles exceptions nécessitent une vérification humaine.
• Empêcher qu’une sortie IA incertaine remplace automatiquement les données de référence.

Ces principes ne ralentissent pas l’innovation. Ils permettent au contraire une innovation évolutive, car les organisations peuvent expérimenter plus rapidement lorsqu’il est clair quelles sorties sont de simples recommandations, quelles données constituent un enrichissement et quelles informations peuvent être considérées comme une vérité validée.

Ce que cela signifie pour les architectures Salesforce

Dans l’écosystème Salesforce, des volumes croissants de données deviennent disponibles pour la segmentation, la personnalisation, l’IA et l’activation automatisée. Cela crée des opportunités importantes, mais ne réduit pas l’importance de la gouvernance. Au contraire: plus le nombre de composants interconnectés augmente, plus l’impact d’une erreur introduite tôt dans la chaîne devient important. Pour une architecture comprenant Sales Cloud, Data Cloud, Marketing Cloud et Account Engagement, il faut donc définir à l’avance quels systèmes créent des enregistrements, quels systèmes sont autorisés à les enrichir et quels systèmes ne peuvent consommer que des sorties validées. Il faut également empêcher que des données générées par l’IA acquièrent silencieusement le même statut que des données sources contrôlées. Une conception pratique peut donc utiliser des champs distincts, des statuts d’objets ou des étapes de validation séparées pour les données sources, les données dérivées et les données générées. Les sorties IA peuvent être utilisées efficacement pour des suggestions, des résumés, de la classification ou de l’enrichissement sans remplacer automatiquement les données de référence. Ce n’est qu’après validation qu’un enregistrement doit passer à un statut autorisant son utilisation par les processus downstream.

La valeur de l’IA ne vient pas du fait que le système puisse tout renseigner de manière autonome, mais du fait que les décisions qu’il peut prendre seul et celles qu’il ne peut pas prendre soient clairement définies.

Cette distinction est essentielle pour les organisations qui souhaitent réellement opérationnaliser l’IA générative. Un proof of concept peut rapidement sembler impressionnant, mais la valeur d’entreprise n’apparaît que lorsque l’architecture, la gouvernance et la réalité fonctionnelle sont alignées. La modélisation des données, les structures de droits, la priorité des sources, la logique d’exception et le monitoring sont moins visibles qu’une interface IA, mais déterminent en définitive si la solution reste fiable.

Passer de davantage d’automatisation à une meilleure automatisation

L’étape suivante d’une Marketing Automation mature ne consiste pas à supprimer autant que possible le contrôle humain. Elle consiste à savoir précisément où ce contrôle reste nécessaire et où la technologie peut évoluer en toute sécurité. Cela exige des architectures dans lesquelles les données ne sont pas seulement collectées, mais également qualifiées; dans lesquelles les API ne font pas que connecter des systèmes, mais transmettent également le contexte commercial; et dans lesquelles l’IA n’est pas évaluée uniquement selon sa capacité de persuasion, mais également selon sa traçabilité. Pour CloudEngagePro, c’est précisément à cet endroit que se rencontrent technologie marketing, data engineering et expertise métier fonctionnelle. Les plateformes Salesforce peuvent automatiser largement les processus, mais uniquement lorsque l’architecture prend en compte la réalité derrière les données: rôles clients, droits de catalogue, logique de prix, contexte historique, fiabilité des sources et exceptions humaines. Garbage in, garbage out n’est donc pas une expression informatique dépassée. À l’ère de l’IA générative, il s’agit d’un risque d’entreprise qui peut apparaître plus rapidement, de manière plus convaincante et à plus grande échelle que jamais. Les organisations qui souhaitent utiliser durablement l’IA et la Marketing Automation ne créent pas le plus de valeur en collectant le maximum de données ou en rendant le maximum de processus autonomes. Elles créent de la valeur en rendant les données fiables avant que l’automatisation ne commence à les exploiter.