in

Le référentiel client unique relève souvent de projets spécifiques – Par Nicolas Simonnet, Almavia

Le référentiel client unique (RCU) rassemble toutes les données clients qu’il est utile de partager à l’échelle de l’entreprise. De multiples contraintes orientent bien souvent sa concrétisation au travers d’un projet spécifique plutôt qu’un produit sur étagère.

Pierre angulaire de la vision à 360° du client, le RCU (référentiel client unique) rassemble toutes les informations liées au client ou prospect qu’il est utile de partager à l’échelle du SI, afin d’optimiser son parcours et de mieux le connaitre. Au-delà d’une simple base de données, il nécessite des mécanismes et processus de consolidation des données et d’intégration avec de multiples sources : CRM (marketing, service client, outils des commerciaux…), centre de contacts, ERP (logistique, facturation…), plateformes e-Business, réseaux sociaux, services tiers (publicité en ligne, CRM onboarding…) ou encore SI de partenaires.

Les outils sur étagères souvent écartés

En 2019, à l’heure des progiciels triomphants, on pourrait s’attendre à voir émerger des plateformes de RCU sur étagère. De grands acteurs comme Salesforce, Oracle ou Adobe proposent bien des produits pouvant accueillir un RCU. Mais malgré leurs panoplies de connecteurs, ces produits ciblent essentiellement les entreprises dont le SI est en grande partie déjà basé sur l’offre de ces éditeurs.

Puisque le RCU rassemble les données clients, la base de données du CRM pourrait logiquement les accueillir. C’est parfois le cas mais seulement sur des projets de taille relativement modeste.

Autre alternative sur étagère : on a vu émerger des plates-formes dites de CDP (Customer Data Platform) qui correspondent bien à la mise en œuvre du concept de RCU. Mais ces offres en mode SaaS émanent d’éditeurs de taille modeste qui posent de légitimes questions de pérennité et de capacité à supporter des projets importants.

De multiples contraintes orientent vers un projet maison

Au final, la plupart des projets de RCU d’entreprises d’une certaine taille relèvent d’une approche spécifique reposant généralement sur une base de données et des middlewares, ou sur un outil de Master Data Management (certains d’entre eux intègrent d’ailleurs une application pré-packagée permettant de construire un RCU). Les raisons sont multiples. Tout d’abord, les sources de données d’un RCU sont nombreuses et très hétérogènes, de même que les types d’interfaces permettant d’y accéder (services web, connecteurs SGBD, fichiers plats…). D’autre part, les processus et règles de consolidation et de propagation des données sont également très différents d’une entreprise à l’autre, ce qui rend difficile leur personnalisation par un simple paramétrage. Les volumétries sont en outre importantes, ce qui élimine généralement la base du CRM. Enfin, depuis peu, certaines entreprises souhaitent mettre à jour les données de leur RCU en temps réel, notamment lorsqu’elles cherchent à réagir rapidement à une anomalie (par exemple un système de paiement en panne). Ces contraintes de volumétries et de délais de latence imposent généralement le choix d’une base de données noSQL.

Nicolas Simonnet, consultant au sein du pôle Conseil d’Almavia

Morgane
Morgane Palomo

Diplômée d'un master un brand management marketing, sa curiosité et sa soif de savoir ne sont étanchées. De nature créative, elle a su diversifier ses expériences. De la création graphique, à l'événementiel en passant par la communication interne et le marketing digital, elle s’est construit un savoir pluriel et avant tout polyvalent.

Written by Morgane Palomo

Diplômée d'un master un brand management marketing, sa curiosité et sa soif de savoir ne sont étanchées. De nature créative, elle a su diversifier ses expériences. De la création graphique, à l'événementiel en passant par la communication interne et le marketing digital, elle s’est construit un savoir pluriel et avant tout polyvalent.