rd solertia

Solertia – L’archi

Solertia - L'archi

29 octobre 2024

Rhapsodies Digital

Antoine Belluard

Responsable technique Rhapsodies Digital

À Rhapsodies Digital, on aime construire des solutions numériques (oui oui), et on s’est dit qu’on avait envie de partager dans le détail ce qu’on fait. C’est donc avec une série d’articles que l’on va soulever le capot, et présenter les détails techniques de nos travaux.

On va commencer par parler de notre projet Solertia (car il est tout frais, le MVP vient de sortir), de son archi, le back, le front, et de comment on a fait tout ça.

Solertia, projet visant à lister, catégoriser et présenter des entreprises au savoir-faire exceptionnel, est aussi notre premier vrai projet interne, imaginé et réalisé par une équipe très réduite, mais passionnée !

On y va ?

Boring or not boring ?

Le choix de l’ennui : côté application

Le projet Solertia en gros résumé

À première vue, le projet présente une architecture très classique, avec un socle API et base de données consommée par un front.

L’avantage, c’est que si, un jour, on a envie d’exposer et de monétiser nos données, c’est presque déjà fait (bon, moyennant un système d’authentification et de rate-limit bien évidemment…). Et ça tombe bien, car c’est également une des ambitions du projet.

Autre avantage, notre front n’étant qu’une couche de présentation, il ne fera pas d’écriture sur nos données, tout comme les clients potentiels de notre API, on peut donc, sans vergogne, couper en deux nos routes et ajouter une protection supplémentaire sur tout ce qui est POST/PUT et DELETE.

Notre API/Back, sera de plus un proxy pour récupérer et agréger de la data sur nos fameuses entreprises, avec notamment des connexions API avec Pappers (et d’autres sources de données qui arriveront par la suite).

C’est pour cela que le full monolithe (bien qu’avec beaucoup d’avantages, on le rappelle, utilisé par exemple chez Stackoverflow), n’a pas retenu mon attention ici.

Le choix de l’ennui : côté base de données

TL;DR : j’aime bien PGSQL.

Une de mes technos préférées, je dois l’admettre, est PostgreSQL. Robuste, ultra-performante, sécurisée et éprouvée, les nombreuses qualités de cette base de donnée relationnelle open source ne sont plus à présenter.

Son excellente gestion du JSON, avec bon nombre de fonctions et d’opérateurs prêts à l’emploi (on en parlera plus en détails sur la partie backend), peuvent permettre, par exemple, de créer des requêtes dont le résultat est directement mappables sur un DTO.

Concernant le volume de données, quelques milliers d’entreprises, il me paraissait overkill d’utiliser ElasticSearch pour l’instant (qui nécessite son serveur et donc sa maintenance — ou alors des solutions SaaS hors de prix (coucou Algolia/Melisearch)), sachant que PG dispose d’un excellent module de recherche fulltext.

Puisqu’on a évoqué un peu de NoSQL, je n’ai pas retenu cette solution non plus, car on a quand même pas mal de relations à gérer, et n’étant pas non plus un fana des micro-services (quand ce n’est pas nécessaire), je n’avais pas envie de m’embêter à ce niveau-là. PostgreSQL est mon choix rationnel, par défaut, quand je cherche une base de donnée.

Car oui, il faut le reconnaître, le NoSQL est sexy et a d’autres avantages, et match très bien quand on a moultes services qui ont leur propre système de stockage. Mais bien souvent, ce n’est qu’une question de préférence sur la modélisation, au final, on peut très bien faire du NoSQL sur PG.

Comment qu’on se cache

TL;DR : un jour oui, mais pas maintenant.

Actuellement, le projet ne dispose pas d’un système de cache applicatif, autre que ce que les technos choisies font nativement. Nous verrons après le lancement du projet, car on aime bien itérer et donc pour l’instant, on préfère avoir notre BDD en frontal de notre API.

Parce que oui, développer un système de cache, ce n’est pas auto-magique, il ne suffit pas d’installer l’excellent Redis et hop, c’est fait. Il y a du code à écrire, et pas mal de cas à gérer, ainsi qu’une dépendance et un serveur supplémentaire.

Parlons technos applicatives !

Le choix du compilé côté Backend

S’il y a bien une chose que j’ai comprise au cours de mes derniers projets, c’est que l’interprété, c’est pratique, mais c’est coûteux en performance et donc en serveur.

Côté API, il est absolument vital que les performances soient au RDV, car c’est notre backend, c’est ce qui va exposer nos données, et c’est ce qui sera le plus gros bottleneck de notre architecture.

Ce que j’aime bien avec les exécutables, c’est qu’après avoir target une plateforme, on a pratiquement besoin de rien sur le serveur pour le faire tourner, couplé avec supervisord par exemple, on peut également avoir rapidement un système simple, auto-gérable. Le choix de docker en prod est par ailleurs plus envisageable, il suffit d’une alpine vanilla et c’est parti.

Les choix évidents : Rust vs Go

Secrètement, cela fait des années que je me forme au langage Rust, que j’adore et dont j’admire le design. Gestion de la mémoire fine sans garbage collector, syntaxe élégante, typage strict, friendly compilateur, zero-cost abstractions et performances proches du C/C++.

Néanmoins, son gros (et peut-être seul ?) défaut reste son niveau d’adoption professionnelle. Bien qu’on dénombre de plus en plus de success story après un passage à du Rust (Discord, AWS, Kernel Linux, 1Password…), le nombre de développeurs est actuellement limité, et la gymnastique mentale nécessaire pour coder en Rust est importante.

Je suis convaincu que le jour où on sera plus nombreux, je pousserai fort pour que l’on puisse construire nos backend en Rust pour participer également à la popularisation de ce langage.

Surtout que tokio (les créateurs de l’async sur le langage), avance à grands pas avec son framework web ultra-performant axum, qui je pense va tout éclater sur son passage. À l’heure où j’écris ces lignes, le projet est en v0.9.3.

Le vainqueur rationnel : Go

Et donc oui, spoiler alerte, le backend de Solertia est écrit en Go.

Rebuté par sa syntaxe dans un premier temps, loin d’être élégante, force est de constater que le langage est populaire. Certainement causé par la réécriture de pas mal de backend PHP/Nodejs/Java et avec un Google en back.

Il s’est rapidement imposé, comme un bon compromis simplicité d’utilisation/performances.

Bien qu’on s’écarte sensiblement des performances de Rust, il est sympa de voir que des calls API sont de l’ordre de la milliseconde, avec des appels BDD derrière de la transformation de data. Surtout une belle économie de CPU/RAM, juste parce qu’on utilise mieux les ressources et qu’on a besoin de peu de dépendances (genre curl en fait) sur le serveur.

Côté langage, Go est également typé strictement et se veut surtout une boîte à outils complète côté network. Et là oui, pour faire du web, c’est simple, nativement tout existe déjà dans le STD. De plus, sa gestion de la concurrence le rend très cool à utiliser.Côté librairies/framework, on est aussi très bien, avec bon nombre de choses qui existent (forcément, car le gros du truc est déjà présent dans le langage). Ici, on va juste teaser, en disant qu’on a un framework web (Gin), un semi-ORM un peu naze, mais pratique pour les migrations (Bun) et un truc génial pour auto-générer la documentation OpenAPI à partir de nos DTO d’entrée et de sortie (Huma).

NodeJS et Astro pour le front

Je vais vous l’avouer, je n’ai jamais été très grand partisan de NodeJS (étant plus côté PHP historiquement).

On peut néanmoins reconnaître que son extrême popularité a généré tout un tas de truc quand même bien cool comme Typescript et Astro, excellent framework web que l’on m’a fait découvrir très récemment (big-up à Renaud qui se reconnaitra s’il est dans les parages !). Et également, côté performance, il ne se défend pas si mal que ça. Le souci, c’est qu’on paie ça avec un nombre absolument dingue de dépendance nécessaire.

Mais l’histoire de ce choix est, en réalité, un peu plus complexe que ça. 

Un truc que fait très bien Astro, c’est la génération d’un build statique (du pur HTML/CSS avec un très peu de javascript côté client). Et ça, pour le coup, j’aime bien, car ça me rappelle le côté exécutable, presque ennuyeux, prêt à l’hébergement sur un bucket (par exemple), avec 0 dépendances côté serveur et des performances forcément extraordinaires.

Le seul “soucis”, c’est que c’est complexe à mettre en place quand on a du contenu dynamique. On n’a ici pas des masses de choix :

La deuxième solution ne me plait guère, car cela veut dire que si on veut implémenter un rate-limit pour protéger et monétiser notre API, les conséquences seront subies côté client (ou alors, on ajoute un BFF, mais ça nécessite une autre app et donc de la complexité), et qu’on va nécessairement perdre de la performance et donc l’intérêt d’un build statique.

Donc, je suis plutôt partisan ici de la première solution, sauf que c’est quand même assez compliqué à mettre en place, surtout qu’on a, en plus, un moteur de recherche à implémenter (oui, des solutions pour le build statique existent, mais on verra plus tard !).

Limités par le temps et les ressources de développement, on va donc la jouer interprété côté serveur, avec les technos qui permettent de générer un static, et on migrera vers cette solution par la suite, ça, c’est certain.

Et PHP alors ?

Croyez-moi bien qu’avec mes 8 ans d’xp en développement PHP/Symfony (et j’adore le langage depuis sa version 7), cette piste a été étudiée, finalement rejetée, car j’avais envie d’expérimenter d’autres choses, principalement pour ouvrir mes chakras (bien qu’elle fonctionne très bien !).

De plus, pour la génération de build statique (qui est, rappelons-le, notre cible idéale), on a des solutions qui sont, selon moi, bien moins éprouvées que côté NodeJS. Et de toute façon, on a de l’interactivité forte côté UI, donc on aura forcément besoin de JavaScript.

Le Backoffice

Ce qu’on a dit jusqu’à présent, c’est super, mais il faut quand même à un moment pouvoir administrer nos données, car ça ne se fait pas tout seul (dommage…).

Et bon, ouvrir un éditeur de base de données et faire les modifs comme ça, directement en prod, c’est bien nature, un peu trop à mon goût.

Le p’tit soucis, c’est que faire un back-office, c’est pénible car :

Si seulement il existait des solutions qui permettent de faire du drag & drop de composants, de gérer l’authentification et les droits des utilisateurs, de créer des formulaires en 4 clics, plug & play sur n’importe quelle API, ça serait vraiment cool pour notre use case !

Ah, mais si ça existe et ça s’appelle Retool !

Grâce à cet outil et à sa version gratuite, on a pu monter un BO en quelques jours, autour des endpoints d’écriture de notre API. Sa base est solide pour faire des formulaires et des listings simples, sur les résultats de notre API. On définit les endpoints, on map les champs sur les inputs et pouf, ça marche.

Après, il y a quand même des désavantages par rapport à un BO développé maison, certaines choses m’ont bien frustré, comme l’absence de gestion avancée des images par exemple, car le système ne propose qu’un bête input d’upload de fichier, exit donc les jolis croppers et les résolutions fixes en fonction du champ.

Une infra (plutôt) simple

Avant de terminer cet (long) article, j’aimerais tout même partager quelques mots sur l’infra choisie pour l’hébergement du projet.

Étant très sensible à la philosophie Dev Ops, mais avec des connaissances limitées en Infra as Code (IAC) et en administration réseau, j’avais tout même envie d’un environnement propre avec, surtout, de la facilité au niveau du déploiement. L’IAC puisqu’on en parle, est, selon moi, l’un des aspects les plus importants à mettre en place, parce qu’elle constitue une description exhaustive de ce qui est online.

Côté hébergement, cela fait maintenant quelques années également que j’évolue dans des environnements “cloud”, où l’approche budgétaire et la grande flexibilité sous-jacente permettent d’appliquer l’agilité et l’itération plus facilement au domaine du système, notamment encore fois, lorsque les forces vives sont réduites. Il était donc naturel pour moi d’implémenter ces outils pour Solertia.

Le Cloud de Scaleway

Etant plutôt à l’aise avec les services d’AWS, j’ai également voulu innover, et de tester les services de Scaleway, qui est européen par nature.

On retrouve tout ce qu’il faut pour construire ce que l’on désire ici :

Comme décrit plus haut, j’aime itérer et faire vivre l’architecture, ici, on ne présente que ce qui propulsera le MVP. Il est possible que cela change dans le futur (pourquoi s’en priver ? c’est un des aspects sympa qu’offre le cloud).

Docker couplé avec une CI/CD chez Gitlab

Bon c’est super tout ça, mais je n’aime pas spécialement l’idée de construire mes images docker sur mon poste et de les mettre en prod via la console UI de Scaleway.

Fort heureusement, nous utilisons Gitlab, qui avec sa puissante et beginner-friendly CI/CD m’a permis de mettre en place, pour les deux projets :

Le cycle quant à lui est honteusement simple : À chaque nouvelle branche, la CI nous dit si c’est bien (ou pas, très objective qu’elle est), et à chaque nouveau tag sur main, ça déploie.

La full picture

Pour conclure, ce qu’il va falloir améliorer

Voici une mini-liste non exhaustive de ce que j’ai mal/pas fait, et que j’aimerais donc pousser par la suite :

Merci de m’avoir lu !

Écrit par Antoine Belluard – Responsable technique chez Rhapsodies Digital, j’ai une dizaine d’années d’expérience dans le développement informatique. Passionné par la programmation et la technologie, et poussé par un fort impostor-syndrome, je suis en apprentissage continu.

architecture-innovante-catalogue-de-donnees-essentiel-data

Accompagnement Transformations Data, Digitale et Agile !

Accompagnement Transformations Data, Digitale et Agile !

15 avril 2024

– 3 minutes de lecture

3 Expertises en transformations

Alba Royo

Consultante senior Transformation Agile des Organisations

Maureen Delaloi

Manager Transformation Data

Hajer Lagha

Senior Manager Transformation Digitale

Nous vous accompagnons dans vos Transformations Data, Digitale et Agile !

Les autres sucess story qui peuvent vous intéresser 


rhapsodies digital

RHAPSODIES CONSEIL ANNONCE LA CRÉATION DE RHAPSODIES DIGITAL

RHAPSODIES CONSEIL ANNONCE LA CRÉATION DE RHAPSODIES DIGITAL

RHAPSODIES CONSEIL ANNONCE LA CRÉATION DE RHAPSODIES DIGITAL ET L’ARRIVÉE DE DEUX NOUVEAUX COLLABORATEURS À SA DIRECTION

Fort de 130 collaborateurs et d’un positionnement en pivot Métier, Delivery, Tech, permettant d’accélérer les projets de transformations de ses clients. Rhapsodies Conseil, le cabinet indépendant de conseil en management au 18 millions d’€ en 2023, annonce la création de Rhapsodies Digital. Implantée à Lyon et à Paris, Rhapsodies Digital se veut une Digital Factory as a Service “à la française” et marque l’arrivée de deux nouveaux collaborateurs à sa direction. 

Lumière sur Rhapsodies Digital

Les évolutions sociétales et technologiques constantes créent de nouveaux besoins chez les consommateurs et offrent autant d’opportunités de croissance et de développement pour les entreprises que de contraintes permanentes de mise à niveau. Elles portent aussi des enjeux de vélocité pour pouvoir les adresser rapidement.

C’est dans ce contexte qu’est née Rhapsodies Digital, une Digital Factory as a Service “à la française”, implantée à Lyon et à Paris.  

Sa mission : accompagner les entreprises dans l’accélération de leur transformation digitale en développant des produits et des services numériques sur-mesure tout en s’appuyant sur  les fondements du manifeste Agile avec une approche frugale, éthique et responsable.

“Le credo de Rhapsodies Digital : excellence technique et qualité du delivery sans compromis et sans dogmatisme. Construire avec nos clients une relation de partenariat pour créer les meilleurs produits, les meilleurs services qui s’inscrivent dans leur feuille de route et leur réalité opérationnelle”

Jean-Baptiste Desnoulet

Associé Fondateur Rhapsodies Digital

Deux nominations au sein de Rhapsodies Digital

Rhapsodies Digital sera co-dirigée par deux nouveaux collaborateurs, Pascale Bonnard et Jean-Baptiste Desnoulet, tous deux placés sous la responsabilité de Damien Blandin, Directeur Général de Rhapsodies Digital. 

Pascale Bonnard rejoint le groupe Rhapsodies Conseil en tant qu’associée fondatrice de Rhapsodies Digital. Elle possède une vaste expertise de l’innovation numérique et digitale, et de la transformation des organisations, cumulant une expérience de près de 30 ans dans ces secteurs.

Son parcours reflète une capacité remarquable à piloter des équipes et à superviser des projets d’envergure. En tant que Directrice Générale chez Indigo Neo, filiale du Groupe Indigo, elle a mené à bien la transformation des activités de stationnement traditionnel en un modèle commercial et une expérience client totalement digitalisés.

Pascale a également été entrepreneure dans la tech, en fondant Amano (CMS dédié aux Progressive Web Apps). Auparavant, associée du cabinet Eurogroup Consulting, elle a dirigé la practice Telecom et piloté de nombreux projets de transformation pour ses clients.

Jean-Baptiste Desnoulet, associé fondateur de Rhapsodies Digital, 38 ans, évolue dans le secteur depuis 18 ans. Il excelle dans la direction stratégique et opérationnelle du secteur numérique au sens large, avec une expertise particulière dans la déclinaison d’une stratégie d’entreprise en un écosystème digital ordonnancé, adaptatif et résilient. 

Avant de rejoindre Rhapsodies Digital, Jean-Baptiste pilotait l’équipe lyonnaise de Neo9, assurant le management transversal de l’agence. 

Auparavant, en tant que Digital Partner chez Boiron France, il a dirigé la Digital Factory du groupe pharmaceutique. Avec une carrière diversifiée, allant de la transformation digitale chez PEAKS à la gestion de projets mondiaux chez GL events, Jean-Baptiste apporte ses expériences passées au sein de secteurs d’activité très divers, et incarne un leadership dynamique et innovant.

“Cette création va ainsi nous permettre d’accompagner au mieux nos clients de bout-en-bout en faisant valoir nos facteurs différenciateurs : la responsabilité (Numérique Responsable de A à Z), l’expertise (excellence technique et qualité du delivery) et l’agilité (Lean et Agile par nature).”

Olivier Barthelemy

Fondateur Rhapsodies Conseil

Quelles fondations digitales / data pour soutenir votre SI de demain ?

Quelles fondations digitales / data pour soutenir votre SI de demain ?

28 juin 2022

– 2 minutes de lecture

Damien Blandin

Directeur Architecture, Data & Transformation

Le 23 juin 2022, l’équipe Architecture a animé un événement dédié aux fondations digitales et data. C’était l’occasion de partager avec les participants les témoignages exceptionnels de Catherine Gapaillard (Groupama) et de Yannick Brahy (STIME – DSI du Groupement Les Mousquetaires).

Image mise en avant

Retour sur notre petit déjeuner événement

Nos intervenants ont pris le temps de partager leur contexte, leur expérience, les spécificités de leurs directions , ainsi que les leviers : organisation, gouvernance et outils mis en place pour soutenir leurs systèmes d’information

3 Temps forts ont rythmé cette matinée:



Téléchargez notre livre blanc Architecture SI – Nos modèles de référence

Revivez l’évènement en photo :

A propos de Rhapsodies Conseil

Créé en 2006, Rhapsodies Conseil est un cabinet indépendant de conseil en management. Sa vocation : accompagner les programmes de transformation
de ses clients, depuis le cadrage jusqu’à leur mise en œuvre opérationnelle, sur 4 grands domaines d’expertise : Architecture & Transformation Data/ Digitale, Sourcing & Performance de la DSI, Paiements & Cash Management et enfin Agilité, Projets & Produits. Fort d’une centaine de consultants et d’une
longue expérience de la transformation des processus et du SI, Rhapsodies Conseil intervient auprès des Grands Comptes et ETI de secteurs d’activité variés (Banque, Assurance, Services, Industrie, Luxe, e-commerce,…). Expertise, Indépendance, Engagement, Agilité, Partage, Innovation et Responsabilité sont
les valeurs fondatrices du cainet et guident l’action de ses consultants au quotidien.

livre-blanc-rhapsodies-architecture-si

Téléchargez notre livre blanc Architecture SI Nos Modèles de Référence

Téléchargez notre livre blanc Architecture SI Nos Modèles de Référence

12 janvier 2022

– 1 min

Damien Blandin

Directeur Architecture, Data & Transformation

L’entreprise data driven, la digitalisation de la relation client, l’amélioration de l’expérience client omnicanale, l’ouverture et la cloudification du SI sont autant de préoccupations actuelles pour les entreprises qui sont portées par les innovations technologiques du SI.

Le SI est désormais au cœur des décisions stratégiques de transformation des entreprises et conditionne leur capacité à accroître leur performance au travers d’une évolution permanente et continue.

L’Architecture SI se base sur des fondations digitales / data, des modèles de référence associés à des principes directeurs qui permettent de structurer et définir une vision cible du SI et les trajectoires de transformation associées.

Nos modèles de référence d’Architecture sont donc là pour vous aider à soutenir vos projets de transformation SI, à organiser et structurer la construction de vos fondations digitales / data pour établir une feuille de route cohérente de votre SI cible.

Au cœur de notre expertise, ces modèles de référence d’Architecture structurent notre approche méthodologique construite par R&D mais aussi éprouvée de manière très opérationnelle auprès de nos clients.

Dans ce Livre Blanc, vous trouverez une cartographie de toutes les fonctions attendues par modèle de référence afin d’éclairer vos choix de solution selon vos enjeux métier et vos contextes SI spécifiques.

D’autres modèles de référence d’Architecture viendront très prochainement enrichir et compléter cette première version.

Bonne lecture et à bientôt

Et si mon nouveau CRM devenait mon référentiel Client

Et si mon nouveau CRM devenait mon référentiel Client ?

Et si mon nouveau CRM devenait mon référentiel client ?

La question est légitime, car le CRM doit contenir l’ensemble des Clients / Prospects et l’information peut être tenue à jour par les commerciaux qui les rencontrent régulièrement. Mais avant de faire ce choix, quelques interrogations méritent d’être levées.

La gouvernance à mettre en place est-elle compatible avec mon CRM ?

Le CRM n’est pas le seul système à pouvoir créer, compléter ou mettre à jour des données Clients. Les systèmes de gestion, de facturation ou autres frontaux Clients influent également sur la vie de ces données. Appliquer au CRM l’étiquette de référentiel n’est donc pas suffisant. Il faut mettre en place l’ensemble de la gouvernance des données de référence Client (ou plus généralement concernant les Tiers) associées au principe de référentiel :

Quel modèle de donnée client dans le référentiel ?

Il faut également garder en mémoire que les CRM se concentrent par nature sur les éléments ayant trait à la relation commerciale avec les Clients. Or l’ensemble des données du CRM ne sont pas forcément à porter dans un référentiel. Inversement, dans bien des cas un CRM ne contient pas l’ensemble des données référentielles d’un Client (rôles du Client [payeur / commanditaire / bénéficiaire…], données techniques liées à la mise en place d’un service pour le Client…).

Construire le référentiel Client au sein du CRM implique donc de s’assurer que ce dernier contienne bien l’ensemble des données référentielles et de pouvoir aisément distinguer celles-ci des données à caractère opérationnel.

De plus, dans de nombreux cas cela implique également que des acteurs non commerciaux aient accès au CRM afin de maintenir ces données Client. La Direction Commerciale et Marketing souhaitera-t-elle ouvrir son outil à ces acteurs ? Ceux-ci accepteront-ils d’utiliser le CRM, outil qui n’est pas fait pour répondre à leurs propres besoins ?

Quel périmètre de données est concerné ?

Lorsque les clients sont des personnes morales, il peut être intéressant de croiser les données afin de savoir quels sont les clients qui sont également fournisseurs, quel est le chiffre d’affaire généré par un Client/Fournisseur vs la charge que représente ses prestations. Toute consolidation risque d’être complexe si les référentiels Client et Fournisseur sont distincts. Il s’agit pourtant dans les deux cas de personnes morales mais gérer ses Fournisseurs dans un CRM ne fait pas forcement sens. Dans ce cas, un référentiel ad hoc permettrait de pallier le problème. La problématique sera identique pour tout autre tiers d’intérêt comme les apporteurs d’affaire, les sous-traitants, les cautions / garants…).

Et la technique dans tout ça ?

Point inhérent aux précédents, le CRM a-t-il les capacités techniques pour assurer le rôle de référentiel ? Est-il capable de faire de la gestion de la qualité des données ? Ou alors s’intégrer avec un outil de DQM (Data Quality Management) spécifique ? Est-ce que le modèle de données du CRM est compatible ou suffisamment personnalisable afin d’intégrer le modèle de données de l’entreprise ? L’outil aura-t-il les capacités techniques pour diffuser l’information au sein du SI ? Supportera-t-il des dizaines de milliers de requête par jour ? Est-ce que le contrat de service associé à ce CRM est suffisant pour permettre à l’ensemble des applications qui en dépendent de fonctionner correctement ?

Est ce que je fais un bon investissement ?

Les aspects financiers sont également un élément-clé de la décision. Certes, de prime abord, utiliser le CRM comme référentiel Client permet d’éviter un investissement dans un nouveau système, mais à quel prix ? Combien coûte la mise en place (et l’exploitation) des fonctionnalités de référentiel au sein d’un CRM ? Combien coûtent la haute disponibilité, la qualité de service, les SLA qui n’étaient peut-être pas nécessaires pour le simple usage des commerciaux ? Combien coûtent les licences supplémentaires attribuées aux utilisateurs qui n’étaient pas dans le périmètre initial ? Le modèle de facturation du fournisseur est-il en cohérence avec l’usage que l’on souhaite en faire (un coût à l’usage peut s’avérer rapidement très onéreux) ? Est-ce que l’économie est réelle lorsque l’on compare cette option à la mise en place d’un référentiel dédié ?

Quelles sont les autres solutions possibles ?

Si le CRM n’est pas l’outil le plus adapté à votre cas, quelles sont les autres possibilités ?

Les MDM (Master Data Management) sont a priori plus aptes à traiter les problématiques de référentiel de données puisqu’ils ont été développés dans cette optique. Ils possèdent des fonctionnalités pour traiter la saisie, la consolidation et la diffusion des données et intègrent généralement une couche de DQM permettant d’en assurer la qualité.

Toutefois, la prudence s’impose car tous les outils n’ont pas forcement la même maturité et tous proposent des fonctionnalités qui répondent à des besoins qui ne sont peut-être pas les vôtres. Pourquoi payer les fonctionnalités d’un progiciel si c’est pour ne pas les utiliser ?

Pour répondre à des besoins relativement simples, le développement d’une solution spécifique pourrait être considéré.

Quelle est la meilleure solution pour mon référentiel client ?

CRM, MDM ou développement spécifique, il n’y a pas de réponse générique, mais il peut y avoir des conséquences sur l’ensemble du système d’information.

Bien que tous les éditeurs (de CRM) soutiennent que leur solution peut être utilisée en tant que référentiel Client, ils sont beaucoup plus tempérés une fois les besoins et contraintes à traiter exprimés.

Par ailleurs, et non des moindres, il faut noter que ce n’est pas uniquement le réceptacle qui fait le référentiel. C’est bien la gouvernance qui encadre la donnée qui permet de maintenir le point de vérité. Il est nécessaire de mettre en place une organisation avec des rôles et responsabilités définis ainsi que des outils adaptés respectant l’urbanisation et l’architecture du système d’information.

Mais n’en sommes-nous pas à la vision 360° client désormais ?

Encore une fois, malgré des éditeurs de CRM et de MDM qui promettent la Vision 360° Client, il faut replacer ces solutions à leurs « justes » fonctionnalités et regarder vers de nouveaux outils autour du Big Data qui permettent effectivement la mise en place d’une « vraie » Vision 360° Client sans pour autant remplacer le CRM ni le Référentiel Client. Ces visions consolidées et cross-business sont généralement utiles aux clients eux-mêmes mais aussi et surtout aux commerciaux ou gestionnaires pour leur permettre d’être encore plus efficient dans leur travail au quotidien.

Notons surtout que ces nouveaux outils ne font que renforcer l’intérêt d’un Référentiel Client qui soit partagé au sein du SI car construire une vision 360° Client nécessite d’agréger en un point unique des données venant de l’ensemble du SI.

De nouveaux types d’architecture, incluant la mise en place de Data Lake, d’API, de frontaux digitaux permettent la construction et l’utilisation de cette vision 360° mais elle ne restera possible que si les données peuvent être corrélées les unes avec les autres. Cette corrélation est grandement facilitée lorsqu’un référentiel Client a été mis en place au cœur du système d’information. La vision 360° n’a alors plus qu’à relier tous les éléments métier autour du « golden record » Client unique.