WHAT – Les solutions pour un processus de bout en bout
WHAT - Les solutions pour un processus de bout en bout
L’idée est de présenter un panorama de solutions disponibles pour implémenter l’architecture MCP en entreprise organisé par différentes couches : Clients / Interface UX, Orchestration entreprise & agents, Agents IA, LLM Provider…
Schéma de référence des différentes couches et de leurs solutions
Introduction
L’idée est de présenter un panorama de solutions disponibles pour implémenter l’architecture MCP en entreprise organisé par différentes couches :
Clients / Interface UX
Orchestration entreprise & agents
Agents IA
API & API Gateway
LLM Provider
Tool / Endpoints API
Observabilité
L’objectif n’est pas de réinventer la roue pour des couches déjà existantes dans un SI d’entreprise mais de se concentrer sur les couches qui participent activement au fonctionnement et à la communication avec l’écosystème MCP.
Les différentes couches sont passées en revue, en rappelant leur fonction, avant de s’attarder sur les solutions disponibles sur le marché. Certaines solutions ne sont pas strictement segmentées et peuvent couvrir plusieurs couches.
Même si les couches techniques continuent d’exister, leurs frontières deviennent moins visibles au fur et à mesure que les éditeurs enrichissent leur “package” avec de nouvelles briques (solution tout-en-un), de sorte que l’entreprise n’a plus à gérer séparément chaque couche.
Orchestration entreprise & agents
Cette couche d’orchestration va gérer les processus métier globaux. L’orchestration d’agent, quant à lui, va router les requêtes vers les agents appropriés.
Au sein d’outils comme Mulesoft ou Boomi, l’orchestrateur d’agents est implémenté comme un service appelé et non comme une brique interne.
Des frameworks open source comme LangGraph, LangChain ou LlamaIndex permettent de construire un orchestrateur d’agents chargé de coordonner l’exécution des tâches entre différents agents spécialisés. Pour simplifier le choix des frameworks, on peut les positionner ainsi :
Un agent IA reçoit l’entrée envoyée par l’orchestrateur, va analyser et comprendre l’intention sous-jacente pour déterminer la meilleure action à prendre pour répondre au besoin. Il va déterminer quoi faire en fonction du contexte et des objectifs.
Le MCP client, quant à lui, est le point de connexion entre l’agent IA et le serveur. Il consomme les tools et ressources exposés par les serveurs.
Solution : les agents sont développés en Python / Javascript à l’aide des frameworks cités précédemment, notamment LangChain utilisé pour la logique agent. Une fois les agents construits, il sont déclarés dans l’Agent Registryqui est une couche de gouvernance et d’exposition au sein de l’orchestrateur entreprise. (Ex : Mulesoft Agent Registry). En effet, certaines plateformes commencent à proposer des capacités de gouvernance et de catalogage d’agents.
API & AI gateway
L’API gateway vérifie les autorisations et gère la sécurité AVANT toute consommation de ressources IA.
Authentification : Validation de l’identité de l’utilisateur ou du système appelant
Autorisation : Vérification des permissions pour exécuter l’action demandée
Rate Limiting : Application des quotas par utilisateur/tenant (ex: max 10 opérations/minute)
Caching : Stockage des réponses techniques identiques pour éviter de solliciter inutilement les serveurs d’application => économie de bande passante
Routing : Redirection de la requête vers le bon service
…
L’AI Gateway orchestre des modèles, gère des coûts tokens et assure l’observabilité IA. Cet élément détermine quel LLM l’agent utilise en fonction des besoins. Il gère également des fonctions permettant de communiquer avec les MCP serveurs.
Voici les briques pour la partie LLM :
Multi LLM : Un accès unique vers tous les modèles (GPT-4, Claude, etc.)
Guardrails : Le garde-fou qui filtre les propos déplacés ou dangereux
Semantic Routing : Redirection de la requête vers le LLM le plus adapté selon le sens de la question (Attention : cette brique n’est pas une fonctionnalité native universelle, il peut être présent en custom)
Caching : Pas de coûts supplémentaires pour une question à laquelle on a déjà répondu.
AI Observability : Monitoring spécifique à l’IA
…
Voici les briques pour la partie MCP Server :
MCP Authn & Authz : Gestion de l’identité de l’agent IA. Elle vérifie que l’agent a le droit d’appeler un outil spécifique et gère les secrets/clés API pour se connecter aux serveurs MCP
MCP Routing : Dirige l’agent vers le bon serveur MCP pour exécuter l’action.
MCP Analytics : Mesure l’efficacité et l’utilisation des outils. Qui utilise quel outil ? Quel outil échoue souvent ?
Solutions :
Kong API Gateway + Kong AI Gateway
Gravitee API Gateway + AI Agent Management
Apigee (fonctionnalités IA incluses dans le produit)
Mulesoft Flex Gateway + Mulesoft AI Chain
Boomi API Management + Boomi AI, Boomi MCP…
Tools /Endpoints API
Dans une approche “standard entreprise », mieux vaut passer par l’IPaaS déjà en place. L’éditeur possède déjà une centaine de connecteurs (SAP, ServiceNow etc.). Même sans connecteur spécifique pour une application legacy, l’utilisation du connecteur HTTP permet de bénéficier de la sécurité et du monitoring de la plateforme. L’IPaaS peut servir de base pour exposer les APIs sous forme de tools compatibles MCP via une couche d’adaptation.
Attention : MCP est un protocole émergent, pas encore un standard formel type OpenAPI.
Le catalogue des APIs est alors transformé en catalogue d’outils IA. Ce qui veut dire que les agents ont la capacité d’agir sur le SI de manière autonome, mais sous le contrôle total de votre plateforme d’intégration.
Solution : Éditeur IPaaS déjà en place.
Observabilité
En évoquant le contrôle total, cela nous fait une excellente transition vers l’observabilité.
L’IPaaS existant agit comme un agrégateur central qui produit des données avec OpenTelemetry adopté par un large panel de plateformes (Mulesoft, Kong etc.). Il est ainsi possible d’exporter ces données et les stocker dans d’autres outils d’observabilité déjà existant. Avec ces données, il est possible de surveiller la performance, les coûts, les agents utilisés… via des dashboards.
Solutions : Se baser sur les outils d’observabilité existant. Cependant voici un exemple d’outils déjà utilisé dans le SI :
Le MCP visant à faciliter l’accès d’un client via ses LLM à des ressources distantes, il se base sur une architecture client – serveur classique.
Du côté client, deux briques : l’hôte (application ou utilisateur via son application IA de chat, IDE, etc.) et le client (instance spécifique créée par l’hôte en vue de la communication avec le serveur MCP visé). Si l’hôte doit requêter plusieurs serveurs MCP différents, il instancier autant de clients MCP, afin de garder cette relation un-pour-un.
Concepts
Afin d’établir une communication entre client et serveur, il est nécessaire de connaître les capacités offertes par chacun. Dans MCP cela se fait via une notion appelée primitive. Client et serveur s’exposent des primitives l’un à l’autre.
Primitives exposées par le serveur :
Prompt : template à réutiliser par les LLM comme guide de requête pour bien utiliser les capacités du serveur (par exemple donnant des paramètres à inclure dans une future requête) ;
Ressource : données statiques (ou quasi) du serveur exposées, typiquement pour du cache : fichiers, réponses API ;
Tool : fonctions (écrire dans BDD, appel API, écriture fichier) appelées par le LLM.
Ressource et tool semblent assez proches, l’un comme l’autre pouvant retourner de la donnée. La principale différence réside dans la manière de les contrôler : par l’application pour les ressources et par le modèle pour les tools. Autrement dit, les tools peuvent être appelés de manière autonome par le LLM, tandis que les ressources ne sont appelées que via un choix de l’utilisateur/application.
Primitives exposées par le client :
Sampling (échantillonnage) : permet au serveur de demander au client d’utiliser son LLM pour une tâche, avec potentielle intégration d’une validation utilisateur. Le serveur MCP n’a ainsi pas besoin d’avoir un SDK de langage, ni de payer un abonnement à un LLM ;
Elicitation : permet au serveur de demander de façon structurée des informations supplémentaires à l’utilisateur ;
Roots (racines) : permet de préciser au serveur une organisation des dossiers & fichiers du client, une segmentation/structuration par domaine, ou par privilège. Le client précise ce périmètre d’accès afin que le serveur “comprenne” mieux où rechercher des informations du client. Attention, cela n’applique aucun contrôle d’accès, aucune sécurité. Tout cela doit être fait par ailleurs, hors du cadre du MCP ;
Logging : envoi de messages log au client pour déboguer et monitorer.
Protocole
Le MCP utilisé du JSON-RPC 2.0. Sans rentrer trop dans le détail de chaque étape du protocole, la connexion commence par un handshake puis une découverte. Y sont échangés la version de protocole, les capacités supportées par le client et le serveur, notamment au travers de l’échange des primitives. Une fois ces primitives supportées connues, on peut les lister.
Par exemple, le serveur dit au client qu’il supporte les primitives type tools. Le client demande alors une liste de ces tools puis il peut faire les appels souhaités. Enfin, le serveur peut aussi envoyer des notifications pour prévenir le client de changements.
Intégration au SI
Le MCP ayant pour but de faciliter un accès à des ressources, il est essentiel de les protéger. Imaginons que notre serveur MCP ait comme outil des appels API sur une base de données. Il convient de gérer ces API de la même manière qu’on le ferait habituellement : plateforme d’API management, application de policies de rate limiting, gestion de l’authentification et de l’autorisation, etc.
Le MCP ne remplace en rien ces sécurités. Le besoin est au contraire accru car les appels issus d’IA sont potentiellement moins contrôlés qu’avec des applications/utilisateurs classiques où l’on choisit normalement mieux les appels générés. C’est pour cela que certains APIs Gateway gèrent aussi le filtrage et le routing de LLM, afin entre autres d’éviter d’envoyer des données critiques à des LLMs publiques.
A2A
Le protocole A2A se base lui aussi sur une notion de client-serveur. Un utilisateur final, qu’il soit humain ou non, fait une requête nécessitant des agents. L’agent client (application, service ou agent IA) vient initier une communication comme client vers un agent distant agissant comme serveur. Ce dernier a une bonne couche d’abstraction, du point de vue de l’agent client, l’agent distant est une boîte noire ayant des capacités d’intérêt.
Concepts
Afin de connaître ces capacités, l’agent expose son Agent Card (fichier JSON), qui va permettre la découverte. Elle contient une description, l’URL de l’endpoint du service, les options supportées, l’authentification nécessaire, …
Les deux agents communiqueront au moyen de Messages, représentant un tour de communication. Ce Message a un rôle : utilisateur ou agent. Surtout il contient une ou plusieurs parts.Une Part est la donnée utile transmise, que ce soit du texte, un fichier, une image, etc.
L’agent client fera une requête qui débouchera sur une Task (tâche) du côté agent distant. Cette tâche débouchera sur un Artefact, le résultat généré par l’agent distant, constitué de une ou plusieurs Parts.
Protocole
A2A utilise HTTPS pour le transport et JSON-RPC2.0 pour le format de payload.
Plusieurs mécanismes de découverte sont envisageables, selon les cas d’usages : exposer l’agent card serveur sur une URI standardisée, la référencer dans un catalogue d’entreprise, ou encore l’inscrire en dur dans le client. Selon le niveau de sensibilité pour l’entreprise des informations présentes sur la carte, il conviendra d’ajuster le niveau de protection nécessaire.
A2A peut donc utiliser des protocoles type OAuth2, OIDC. L’autorisation est gérée par le serveur, l’agent A2A distant, alors que l’authentification est typiquement déléguée à l’IAM de l’entreprise. Pour gérer au mieux la couche de sécurité, la performance et la cohérence entre les agents de l’entreprise, bref pour une meilleure gouvernance, il est conseillé d’intégrer ces serveurs A2A avec les solutions d’intégration type API management.
Si certaines requêtes sont simples, on peut s’attendre à une réponse immédiate, via un objet message. Inversement, si la requête est complexe, le traitement peut être long et donc nécessiter un objet tâche (ou plusieurs en parallèle). Il faut alors éviter de bloquer l’agent client. Donc trouver divers modes permettant d’avoir l’information d’avancement de la tâche et de son résultat. Notamment utiliser de l’asynchrone.
En mode pooling (requête/réponse), le fonctionnement basique, une fois la tâche créée côté agent distant, le client demande régulièrement l’état de la tâche ;
En mode streaming Server Sent Events (SSE), le serveur envoie l’état en temps réel, voire des résultats de manière incrémentale (à la manière d’un texte qui se complète peu à peu) ;
En mode notification push, grâce à une webhook, le serveur communique sur des avancées significatives sur la tâche.
Grâce à ces divers modes, on peut ainsi être au courant qu’une tâche a été créée, de son avancement, qu’un artefact a été généré et enfin que la tâche est terminée.
A noter que même terminée ou rejetée, si besoin de raffiner une réponse, on pourra se référer au contexte d’une tâche précédente, mais toujours via une nouvelle. Pas de redémarrage d’une tâche passée.
MCP & A2A
A première vue, MCP & A2A pourraient se recouper.
En réalité, le MCP s’intéresse à faciliter et standardiser l’accès à des ressources par un agent. Le A2A s’intéresse à faciliter la communication entre agents en vue d’une tâche, la décomposer en sous-tâches mieux réparties.
Dès lors MCP et A2A se complètent. Pour résoudre une tâche complexe faisant appel à des données dispersées, on utilisera du A2A pour orchestrer la communication avec des agents spécialisés. Ces agents spécialisés utiliseront du MCP pour requêter les données nécessaires à la résolution du problème.
Un serveur A2A pourrait exposer des capacités en tant que ressources MCP si elles sont bien définies, accessibles avec du stateless, etc.
Résolution d’identité : pourquoi votre RCU échouera sans elle
Résolution d'identité : pourquoi votre RCU échouera sans elle
La vraie question aujourd’hui, ce n’est plus de savoir si vous devez travailler votre résolution d’identité. C’est de comprendre comment vous allez l’implémenter pour qu’elle serve concrètement votre business, pas juste pour cocher une case « RCU » dans votre roadmap IT.
Vous investissez dans un Référentiel Client Unique. Vous connectez vos systèmes, vous nettoyez vos bases, vous alignez vos équipes. Pourtant, 6 mois après le lancement, vos doublons sont de retour. Vos campagnes ciblent toujours les mêmes clients en triple exemplaire. Votre vision 360° reste fragmentée.
Le problème n’est pas votre technologie. C’est votre stratégie de résolution d’identité.
La résolution d’identité est le cœur battant de votre RCU. Sans elle, vous n’avez qu’une base de données centralisée de plus. Avec elle, vous obtenez enfin ce que vous cherchiez : une source de vérité unique sur vos clients.
Mais toutes les approches ne se valent pas. Et surtout, il n’existe pas de solution miracle.
La vérité inconfortable : vous devrez choisir entre fiabilité et couverture
L’approche déterministe : la rigueur au prix de l’aveuglement
Le principe est simple : vous utilisez un identifiant unique et vérifiable (email, téléphone, numéro de carte) pour reconnaître vos clients à coup sûr.
Un client s’inscrit à la newsletter avec son email, crée un compte e-commerce, télécharge l’app mobile et achète en magasin en donnant ce même email ? Parfait. Toutes ces interactions sont automatiquement rattachées à un profil unique. Fiabilité : 99,9%.
C’est l’approche incontournable pour tout ce qui compte vraiment :
Transactions et paiements
Service après-vente
Gestion de compte et programme de fidélité
Conformité RGPD (consentement traçable)
Mais elle a trois angles morts critiques :
1. Vous êtes aveugle aux visiteurs anonymes
Que se passe-t-il pour les 60 à 80% de visiteurs qui naviguent sans créer de compte ? Pour les clients qui ne souhaitent pas s’identifier avant d’acheter ? Pour le trafic en magasin non rattaché à la fidélité ?
→ Vous perdez toute la phase d’exploration et de considération. Vous ne voyez que la conversion finale, sans comprendre le parcours qui y mène.
2. Un identifiant ≠ toujours une personne
Marie a trois adresses email : perso, pro, et son ancienne adresse Hotmail qu’elle utilise encore pour certains achats. Dans votre système, Marie = 3 profils différents. Paul et Sophie partagent l’email familial pour les achats en ligne. Dans votre système, Paul et Sophie = 1 profil.
→ Vous créez des doublons tout en fusionnant des personnes distinctes. Vos statistiques sont faussées dans les deux sens.
3. C’est une porte ouverte à l’usurpation d’identité
Si votre résolution d’identité repose uniquement sur email + nom/prénom, n’importe qui peut créer un compte à votre place. En magasin, avec quelques informations basiques, un tiers peut accéder au compte de quelqu’un d’autre.
La solution ? Authentification forte (email/SMS de confirmation, 2FA). Le coût ? Friction supplémentaire, taux d’abandon en hausse.
Le verdict : l’approche déterministe est indispensable, mais insuffisante.
L’approche probabiliste : la couverture totale au prix de l’incertitude
Le principe est radicalement différent : vous analysez des dizaines de signaux comportementaux et techniques pour déduire statistiquement qu’il s’agit de la même personne, même sans identifiant commun.
Les signaux utilisés :
Caractéristiques de l’appareil (modèle, OS, navigateur, résolution)
Comportement (produits consultés, temps passé, parcours)
Temporalité (heures et jours de visite, fréquence)
Exemple concret :
Deux sessions partagent la même IP, le même appareil (iPhone 14 Pro, iOS 17), des habitudes de navigation similaires (catégorie « chaussures femme » entre 20h et 22h), et la même géolocalisation (Paris 15ème).
→ Probabilité > 90% qu’il s’agisse de la même personne, même si elle n’est pas connectée.
L’avantage est massif : vous capturez enfin les comportements anonymes, vous reconstituez le parcours complet (de la première visite à l’achat), vous enrichissez vos profils avec des données comportementales précieuses.
Mais le revers de la médaille est réel :
1. Vous restez dans l’inférence statistique
Des erreurs existent toujours :
Faux positifs : vous fusionnez deux personnes différentes (un couple partageant la même IP et les mêmes appareils)
Faux négatifs : vous ne reconnaissez pas la même personne entre deux sessions (changement de réseau, nouvel appareil)
→ Vous ne pouvez pas baser des décisions critiques (paiement, SAV) sur une probabilité de 85%.
2. La complexité technique et les coûts explosent
Il vous faut :
Une infrastructure capable de collecter massivement des données sur tous les canaux
Des capacités de traitement en temps réel sur de gros volumes
Des modèles de machine learning à entraîner, optimiser et maintenir en continu
Une CDP performante ou une plateforme de données custom
→ Budget : plusieurs centaines de milliers d’euros en technologie et compétences.
3. Les défis réglementaires s’accumulent
Consentement RGPD pour le tracking comportemental (plus complexe qu’un simple opt-in email)
Fin des cookies tiers (ITP sur Safari, ETP sur Firefox, Privacy Sandbox sur Chrome)
Obligation de transparence sur les mécanismes d’inférence
→ Vous devez être irréprochable juridiquement, sous peine d’amendes CNIL.
Le verdict : l’approche probabiliste est puissante, mais ne peut pas remplacer le déterministe.
Arrêtons de chercher la solution miracle. La vraie question n’est pas « déterministe OU probabiliste », mais « comment articuler intelligemment les deux ? »
La seule stratégie qui fonctionne : l’approche hybride
Phase 1 : Bâtir le socle déterministe (mois 1-3)
Avant tout, vous devez avoir un système de résolution déterministe solide :
Identifiants maîtres clairement définis (email en priorité, téléphone en backup)
Règles de matching configurées et testées
Processus d’authentification adapté à votre secteur
Gestion des cas limites (changement d’email, comptes multiples)
C’est votre fondation. Tout ce qui suit ne tiendra que si cette base est fiable.
Phase 2 : Ajouter la couche probabiliste (mois 4-9)
Une fois le déterministe maîtrisé, vous pouvez enrichir avec le probabiliste :
Mise en place du tracking cross-device et cross-canal
Implémentation des algorithmes de matching probabiliste
Calibrage des seuils de confiance (à partir de quel score fusionnez-vous ?)
Monitoring continu de la qualité (taux de faux positifs/négatifs)
C’est votre multiplicateur de valeur. Vous capturez maintenant les comportements invisibles.
Phase 3 : Orchestrer la fusion intelligente (en continu)
Le vrai art réside dans la fusion des deux approches :
Exemple de parcours client hybride :
Jour 1 → Un visiteur anonyme navigue sur votre site Tracking probabiliste actif : collecte des signaux
Jour 3 → Le même appareil revient, consulte d’autres produits Le profil probabiliste s’enrichit (produits vus, préférences)
Jour 5 → Le visiteur crée un compte avec son email Résolution déterministe : Golden ID attribué
Fusion automatique → L’historique probabiliste des jours 1-5 est rattaché au profil déterministe créé au jour 5
→ Vous obtenez la vision complète : de la découverte anonyme jusqu’à la conversion identifiée
Les règles d’or pour réussir votre résolution d’identité
1. Séparez clairement les niveaux de confiance
Ne mélangez pas les profils déterministes (certitude > 99%) et probabilistes (confiance 70-90%). Marquez-les explicitement dans votre RCU.
Utilisez le déterministe pour :
Toutes les transactions et opérations sensibles
Les communications officielles (factures, SAV)
Les statistiques officielles (reporting direction)
Utilisez le probabiliste pour :
La personnalisation web et app
L’enrichissement de profils existants
Les analyses exploratoires et segmentations marketing
2. Définissez des seuils de fusion adaptés à vos enjeux
Scoring de confiance :
95-100% : fusion automatique (déterministe)
80-95% : fusion automatique avec traçabilité (probabiliste haute confiance)
60-80% : proposition de fusion pour validation manuelle
< 60% : pas de fusion, simple rapprochement pour enrichissement
Ne cherchez pas la perfection. Préférez 80% de couverture fiable à 100% de couverture douteuse.
3. Investissez dans la gouvernance, pas seulement la technologie
La meilleure technologie du monde échouera sans :
Règles métiers claires : qui arbitre en cas de conflit ? Quelle source est maître ?
Processus de contrôle : revues qualité régulières, correction des erreurs de fusion
Formation des équipes : marketing et service client doivent comprendre les limites de chaque approche
KPIs de pilotage : taux de dédoublonnage, couverture identitaire, taux d’erreur
4. Préparez-vous à l’évolution réglementaire
Le paysage privacy change vite :
Fin des cookies tiers d’ici 2025 (vraiment cette fois ?)
Montée en puissance des solutions first-party (authentification, login universel)
Émergence de standards comme FLoC, Topics API, ou autres alternatives
Votre stratégie de résolution d’identité doit être flexible. Privilégiez les approches first-party et l’authentification volontaire plutôt que le tracking passif.
Ce qu’il faut retenir
La résolution d’identité n’est pas un chantier qu’on termine en trois mois pour passer à autre chose. C’est un sujet qu’il faut piloter dans la durée, ajuster au fil de l’eau, faire évoluer avec vos besoins métiers.
Notre recommandation si vous démarrez :
Commencez par le déterministe. C’est moins spectaculaire que le probabiliste avec du machine learning, mais c’est ce qui va tenir dans le temps. Une fois cette base propre et fiable, vous pourrez envisager d’ajouter une couche probabiliste — mais seulement si vous avez les équipes et le budget pour la maintenir correctement.
Ensuite, définissez des seuils de confiance clairs pour vos fusions automatiques. Mettez en place des règles métiers, des points de contrôle réguliers, et des KPIs qui vous permettent de détecter rapidement les dérives. Et gardez en tête que les règles du jeu vont continuer à évoluer — cookies, RGPD, nouvelles régulations — donc construisez quelque chose de flexible dès le départ.
La vraie question aujourd’hui, ce n’est plus de savoir si vous devez travailler votre résolution d’identité. C’est de comprendre comment vous allez l’implémenter pour qu’elle serve concrètement votre business, pas juste pour cocher une case « RCU » dans votre roadmap IT.
Sans cela, votre Référentiel Client Unique restera une promesse non tenue de plus. Avec cela, vous aurez enfin les moyens de personnaliser véritablement la relation client, sur tous les canaux.
Le Référentiel Client Unique (RCU) : la réponse à la fragmentation de vos données clients
Le Référentiel Client Unique (RCU) : la réponse à la fragmentation de vos données clients
Reconnaître le client instantanément, comprendre ses comportements, personnaliser les interactions et piloter la performance sur l’ensemble du cycle de vie.
51 % des utilisateurs de CRM considèrent que la synchronisation des données est le problème majeur de leur solution actuelle (Stratenet).
Dans un monde où l’expérience client omnicanale est devenue l’avantage concurrentiel majeur, la fragmentation des données clients représente le principal angle mort des directions marketing. Selon une étude Gartner de 2024, 82% des organisations ne peuvent pas calculer avec précision la Customer Lifetime Value (CLV) de leurs clients en raison de données dispersées entre multiples systèmes. Cette fragmentation n’est pas simplement un problème technique : elle compromet fondamentalement la résolution d’identité client, c’est-à-dire la capacité à reconnaître qu’une même personne physique interagit avec la marque sur plusieurs canaux.
Sans la résolution d’identité, impossible de construire une véritable connaissance client. Le profil créé lors d’un achat en ligne reste déconnecté de l’achat en boutique du lendemain. Les préférences déclarées sur l’application mobile ne sont pas exploitées lors d’un échange avec le service client. Le parcours qui débute sur Instagram et se termine en point de vente reste invisible, rendant toute attribution marketing illusoire. Et pourtant, dans un monde où des données sont dispersées dans des systèmes hétérogènes incapables de dialoguer entre eux, les directions marketing, commerciales, relation client, retail et data sont tout de même attendues sur un même terrain : reconnaître le client instantanément, comprendre ses comportements, personnaliser les interactions et piloter la performance sur l’ensemble du cycle de vie.
Les défis et les impacts par direction métier
Marketing
Défis clés
• Attribution multi-touch impossible : les conversions boutique après exposition digitale ne sont jamais créditées aux campagnes online
• Segmentation RFM faussée : une cliente dépensant 1 200€/an apparaît comme deux profils « moyens » à 600€ et ne reçoit jamais les invitations VIP
• Gaspillage direct : emails envoyés en double, catalogues dupliqués, offres inadaptées
Impact chiffré
• 56% des CMO ne peuvent pas mesurer le ROI cross-canal (Gartner 2024)
• 15-20% des clients VIP non identifiés = 2-5M€ de manque à gagner/an pour une enseigne de 500M€ (Forrester)
• 21% du budget marketing gaspillé sur doublons (SiriusDecisions)
Ventes & Retail
Défis clés
• ROPO invisible : 73% des acheteurs en magasin ont recherché en ligne, mais le vendeur démarre à zéro
• Clients omnicanaux non identifiés : impossible de savoir qui achète sur plusieurs canaux
• Click & Collect mal exécuté : recherche manuelle de 8 min, pas d’accès à l’historique, vente additionnelle ratée
Impact chiffré
• Conversion boutique -15 à -25% sans contexte web (McKinsey 2023)
• Panier moyen -20 à -30% quand le vendeur ignore la recherche online
• Taux de vente additionnelle C&C : 35% avec vue 360° vs 12% sans = 23 points perdus (Accenture 2023)
Relation Client
Défis clés
• Répétition frustrante : le client doit répéter son problème à chaque interlocuteur (email, chat, téléphone)
• Incident critique sur 1er achat : traité en routine alors qu’il nécessite priorisation et compensation
• Retour cross-canal impossible : pas de retour web en boutique, retour postal obligatoire
Impact chiffré
• 72% des clients doivent se répéter (Zendesk 2024) • Temps de résolution x2,3 sans vue 360° (Gartner 2024)
• 60-80% des nouveaux clients avec incident mal géré ne rachètent jamais (Bain & Company 2023)
• Taux de récupération : 40% sans RCU vs 75% avec contextualisation (Accenture 2024)
Data
Défis clés
• 70-80% du temps passé à nettoyer au lieu d’analyser : réconciliation manuelle, déduplication, normalisation
• Absence de Golden Record : 3 réponses différentes à « Combien de clients actifs ? »
• Conformité RGPD compromise : plusieurs jours pour traiter un droit à l’oubli au lieu de 30 jours légaux
Impact chiffré
• Décisions sur données inexactes = 1,5% du CA perdu (Gartner 2024)
• Coût traitement demande RGPD : 1 400€ sans RCU vs 150€ avec
Direction Générale
Défis clés
• CLV inaccessible : 82% des organisations ne peuvent pas calculer la vraie valeur client
• Décisions stratégiques sur intuitions : impossible de définir rationnellement les seuils VIP, d’estimer le ROI fidélité
• Angle mort sur clients à haute valeur
Impact chiffré
• 82% ne calculent pas la CLV précisément (Gartner 2024) • Entreprises pilotées par CLV : croissance x2,4 supérieure (Bain & Company 2023)
• Coût total fragmentation : 12-25M€/an pour 500M€
LE RCU : BIEN PLUS QU’UN PROJET TECHNIQUE
Le Référentiel Client Unique (RCU) constitue la « single source of truth » pour l’ensemble des données clients d’une organisation. Contrairement à une approche traditionnelle où les données sont dispersées entre multiples systèmes (CRM, POS, e-commerce, loyalty, marketing automation), le RCU centralise et unifie ces informations autour d’une identité unique par client physique. Cette unification transforme radicalement la connaissance client : là où une entreprise voyait cinq profils déconnectés pour une même personne, elle dispose désormais d’une vue 360° complète et actionnable.
Le RCU repose sur trois piliers fonctionnels interdépendants qui, ensemble, créent un effet de levier sur la performance business.
Premier pilier : unifier les identités clients via un Global ID.
Le RCU attribue un identifiant unique et universel à chaque client physique, quel que soit le canal d’interaction. Ce Global ID devient la clé de voûte permettant de reconstituer l’intégralité du parcours client : la cliente qui s’inscrit à la newsletter sur le site web, visite une boutique le lendemain, télécharge l’application mobile, puis achète en ligne est immédiatement reconnue comme une seule et même personne sur les quatre points de contact. Cette résolution d’identité s’appuie sur des modèles de matching sophistiqués combinant données déterministes (email, téléphone, identifiants externes) et probabilistes (nom, prénom, adresse, comportement d’achat).
Deuxième pilier : garantir la qualité des données par des contrôles systématiques et une déduplication continue.
Le RCU implémente des règles de validation à la création (formats email et téléphone, champs obligatoires, normalisation des adresses) et détecte automatiquement les doublons potentiels via des algorithmes de similarité. Selon l’étude « The State of Customer Data Quality » de Forrester Research publiée en 2023, les entreprises ayant déployé un RCU avec moteur de déduplication actif réduisent leur taux de doublons de 25% (moyenne secteur retail) à moins de 3%, soit une amélioration de 88% de la qualité des données.
Troisième pilier : orchestrer les flux omnicanaux d’acquisition et de propagation des données
Le RCU capture les données clients depuis tous les canaux (flux d’acquisition) et les redistribue automatiquement vers tous les systèmes qui en ont besoin (flux de propagation), en temps réel ou near real-time selon la criticité. Cette orchestration élimine les intégrations point-à-point coûteuses et sources d’erreurs : au lieu de maintenir 15 à 20 connexions bilatérales entre systèmes, l’architecture se simplifie en 5 à 8 intégrations centralisées via le RCU.
Conclusion
Plus fondamentalement, le RCU démocratise la connaissance client à l’échelle de l’organisation. Chaque fonction dispose enfin d’une vue complète, fiable et actualisée : le Marketing peut segmenter avec précision, les Ventes reconnaissent les clients VIP sur tous les canaux, le Service Client accède à l’historique complet, la Data analyse sans passer 80% du temps à nettoyer, la Direction Générale pilote sur des KPIs fiables. Cette connaissance client unifiée devient l’actif stratégique différenciant dans un monde où l’expérience client constitue le principal avantage concurrentiel.
Les 5 questions à se poser avant de lancer votre projet RCU (pour éviter de partir dans le mauvais sens)
Les 5 questions à se poser avant de lancer votre projet RCU
Un bon projet RCU ne démarre pas par le choix d’un outil. Il démarre par une vision claire de ce que vous voulez résoudre et comment vous allez y arriver.
Vous êtes convaincu qu’un Référentiel Client Unique va résoudre vos problèmes de doublons, améliorer votre personnalisation et unifier enfin votre vision client. Vous avez raison. Mais j’ai vu trop de projets RCU patiner pendant des mois, voire échouer, parce qu’ils sont partis trop vite, sans prendre le temps de poser les bonnes questions au démarrage.
Un RCU, ce n’est pas juste un projet IT. C’est un projet qui touche l’ensemble de vos métiers, qui réorganise vos flux de données, et qui modifie profondément la façon dont vos équipes travaillent. Si vous ne clarifiez pas certains points dès le début, vous allez soit créer une usine à gaz que personne n’utilisera, soit passer à côté de l’essentiel.
Voici les 5 questions stratégiques que vous devez absolument vous poser avant de lancer quoi que ce soit.
1. Quel problème business concret cherchez-vous à résoudre en priorité ?
C’est la question la plus importante. Et pourtant, c’est souvent celle qu’on esquive en se disant « on verra bien une fois que le RCU sera en place ».
Mauvaise réponse : « On veut avoir une vision 360° du client.
» Bonne réponse : « Nos vendeurs en boutique ne voient pas l’historique web des clients, ce qui nous fait perdre des ventes sur les clients qui ont déjà consulté nos produits en ligne. »
Mauvaise réponse : « On veut améliorer la qualité de nos données. »
Bonne réponse : « On a un taux de rebond email de 18% à cause de doublons et d’emails invalides, ce qui plombe le ROI de nos campagnes. »
Pourquoi c’est crucial ? Parce que le problème que vous identifiez va déterminer :
Les cas d’usage prioritaires à adresser
Les sources de données à connecter en premier
Le niveau de temps réel nécessaire (ou pas)
Les KPIs de succès du projet
Si vous ne savez pas précisément ce que vous voulez résoudre, vous allez construire un RCU générique qui ne servira personne vraiment bien.
Ce que vous devez faire :
Listez 3 à 5 irritants business concrets que vous vivez aujourd’hui. Classez-les par impact (chiffre d’affaires, satisfaction client, efficacité opérationnelle). Identifiez les quick-wins, les problèmes que vous pouvez résoudre dans les 3 à 6 premiers mois, et les objectifs à moyen terme.
Une fois que vous avez cette liste, vous avez une roadmap. Vous savez par où commencer, et surtout, vous savez comment mesurer le succès.
2. Où sont vos données clients aujourd’hui, et dans quel état ?
Impossible de construire un RCU sans savoir ce que vous allez y mettre. Et là, ça devient vite compliqué.
La plupart des organisations sous-estiment largement la fragmentation de leurs données. Vous avez probablement :
Des données dans votre CRM (mais lequel ? vous en avez peut-être plusieurs selon les BU)
Des données dans votre système e-commerce
Des données dans votre système de caisse
Des données dans votre plateforme d’emailing
Des données dans votre app mobile
Des données dans votre service client (ticketing, chat)
Des données dans des fichiers Excel « cachés » chez les opérationnels
Et vous n’avez probablement aucune idée de :
La qualité réelle de ces données (taux de complétude, taux de doublons, obsolescence)
Qui produit et qui consomme chaque type de donnée
Quels flux existent déjà entre ces systèmes (spoiler : souvent des intégrations point-à-point fragiles)
Ce que vous devez faire :
Avant même de parler technologie, faites un audit de vos sources de données. Pas un audit IT exhaustif qui va prendre 6 mois, mais un diagnostic rapide qui répond à ces questions :
Cartographie des sources : Où sont stockées les données clients ? Quelles données d’identité, transactionnelles, comportementales avez-vous ?
Qualité des données : Quel est le taux de doublons estimé par source ? Le taux de complétude des attributs clés (email, téléphone, adresse) ?
Flux existants : Comment les données circulent-elles aujourd’hui entre les systèmes ? Y a-t-il déjà des synchronisations en place (même imparfaites) ?
Sans cette cartographie, vous risquez de découvrir en cours de projet qu’une source critique existe mais que personne ne vous en avait parlé, ou que la qualité des données d’une source est tellement mauvaise qu’elle va polluer tout votre RCU.
3. Comment allez-vous identifier vos clients de manière unique ?
C’est le cœur du sujet. Votre RCU doit créer un identifiant unique (Golden ID) pour chaque client. Mais comment décidez-vous que deux profils = une seule personne ?
Les choix à faire :
Quel identifiant maître privilégier ?
Email (le plus courant, mais attention aux emails partagés ou multiples)
Numéro de téléphone (plus stable, mais moins systématiquement collecté)
Combinaison nom + prénom + date de naissance (utile pour détecter les doublons)
Numéro de carte de fidélité (si vous en avez un)
Quelle approche de résolution d’identité ?
Déterministe (matching sur identifiants exacts) : fiable mais limité aux clients identifiés
Probabiliste (inférence statistique sur signaux comportementaux) : plus large mais moins fiable
Hybride (les deux) : idéal mais complexe
Quelles règles de déduplication ?
À partir de quel score de similarité considérez-vous que 2 profils doivent être fusionnés ?
Fusion automatique ou validation manuelle ?
Comment gérer les conflits d’attributs lors de la fusion (quelle source fait foi pour l’adresse ? le téléphone ?) ?
Ces questions peuvent sembler techniques, mais elles ont un impact business direct. Si votre résolution d’identité est trop stricte, vous allez créer des doublons. Si elle est trop laxiste, vous allez fusionner des personnes différentes (et là, bonjour les problèmes RGPD).
Ce que vous devez faire :
Définissez vos règles de matching dès le début. Testez-les sur un échantillon de données réelles pour calibrer les seuils. Et surtout, documentez ces règles clairement, car vous devrez les ajuster au fil du temps.
4. Quelle plateforme technologique est adaptée à votre contexte ?
Là, on entre dans le concret. Vous avez plusieurs options pour héberger votre RCU, et chacune a ses avantages et inconvénients.
Déjà en place, compétences internes, coût marginal
Pas conçu pour être un hub de données, performances limitées, verrouillage vendor
Option 2 : Une Customer Data Platform (CDP)
Conçue pour ce cas d’usage, connecteurs natifs, temps réel
Coût élevé, complexité fonctionnelle, risque de sur-engineering
Option 3 : Une solution de Master Data Management (MDM)
Robustesse pour la gouvernance et la qualité de données
Complexité, coûts, orienté entreprise legacy
Option 4 : Une solution « maison » sur data lake / data warehouse
Flexibilité totale, pas de licence vendor
Développement et maintenance lourds, compétences techniques pointues nécessaires
Il n’y a pas de bonne ou mauvaise réponse universelle. Ça dépend de :
Vos volumétries (millions de profils ? milliards d’événements ?)
Vos besoins de temps réel (personnalisation web en temps réel vs reporting hebdomadaire)
Votre stack technologique existant (mieux vaut s’appuyer sur ce que vous avez déjà)
Vos compétences internes (avez-vous les data engineers pour maintenir une solution custom ?)
Votre budget (licences, infra, intégration, run)
Ce que vous devez faire :
Évaluez 2 à 3 options technologiques en fonction de vos contraintes réelles. Faites des POC (Proof of Concept) sur vos cas d’usage prioritaires avant de vous engager. Et surtout, ne choisissez pas la solution la plus en vogue si elle ne correspond pas à votre maturité organisationnelle.
5. Qui va piloter et gouverner le RCU côté métier ?
C’est probablement la question la plus sous-estimée. Et pourtant, c’est souvent là que ça bloque.
Un RCU, c’est de la donnée. Et la donnée appartient aux métiers, pas à l’IT. Mais dans beaucoup d’organisations, personne ne veut vraiment prendre la responsabilité de la qualité des données clients.
Les questions de gouvernance à trancher :
Qui est responsable de la qualité des données dans le RCU ?
Un Data Owner désigné par domaine (identité, transactions, comportement) ?
Une équipe transverse dédiée ?
Les métiers de manière décentralisée (avec le risque que personne ne soit vraiment responsable) ?
Comment arbitrer les conflits entre départements ?
Marketing dit que l’adresse dans le CRM est la bonne, Ventes dit que c’est celle de leur outil. Qui décide ?
Quel processus d’escalade ? Quelle instance de décision ?
Comment mesurer et piloter la qualité dans la durée ?
Quels KPIs de qualité suivre (taux de dédoublonnage, complétude, fraîcheur) ?
Quelle fréquence de revue (hebdomadaire, mensuelle) ?
Qui est alerté en cas de dégradation ?
Sans gouvernance claire, votre RCU va devenir un nouveau silo. Chaque métier va continuer à privilégier « sa » source de données, et vous n’aurez rien résolu.
Ce que vous devez faire :
Désignez un sponsor exécutif (CMO, CDO, DSI) qui arbitrera en dernier ressort. Créez un comité de gouvernance avec des représentants métiers (marketing, ventes, service client, e-commerce). Et surtout, mettez en place des revues qualité régulières dès le démarrage – pas après 6 mois quand tout le monde aura pris de mauvaises habitudes.
En résumé : ne sautez pas les étapes
Je sais que vous avez envie d’avancer vite. Votre direction attend des résultats. Vos équipes marketing sont frustrées par les doublons. Vos projets sont bloqués faute de données fiables.
Mais un projet RCU mal cadré au départ, c’est 6 à 12 mois de perdus, des budgets qui explosent, et des équipes démotivées.
Prenez le temps de répondre à ces 5 questions. Impliquez les métiers dès le début. Faites des choix clairs sur vos priorités, votre approche de résolution d’identité, votre technologie, et votre gouvernance.
Un bon projet RCU ne démarre pas par le choix d’un outil. Il démarre par une vision claire de ce que vous voulez résoudre et comment vous allez y arriver.
Comment garantir une souveraineté numérique pragmatique et adaptée à vos enjeux ?
Chez Rhapsodies Conseil, nous accompagnons nos clients à chaque étape :
– Définir une architecture cible alignée sur leur stratégie d’entreprise
– Identifier les providers éligibles selon leurs besoins de souveraineté
– Élaborer un plan stratégique clair avec une feuille de route concrète
Avec ce plan, nos clients reprennent le contrôle de leurs données et assurent à la fois souveraineté, continuité de service et conformité réglementaire.
Découvrez dans notre carrousel comment nous vous aidons à construire une trajectoire de souveraineté numérique claire et opérationnelle.
