Un CRM qui n’est plus supporté coûte cher à conserver et il est risqué de l’éteindre, car dix ans d’historique client y sont stockés. La solution que nous avons retenue conserve l’historique et retire l’application.
La plupart des organisations qui utilisent encore une ancienne version de Dynamics CRM savent déjà qu’elles doivent en sortir. Les serveurs ne sont plus supportés, les personnes qui maîtrisaient les personnalisations sont parties, et chaque revue de sécurité ajoute une ligne au registre des risques. Ce qui les retient est rarement la nouvelle plateforme. Ce sont les dix ou quinze années d’historique client stockées dans l’ancienne.
Cet historique sert encore. Une réclamation vieille de plusieurs années refait surface, ou un auditeur demande ce qui a été dit à un client avant la modification d’un produit. Éteignez le CRM, et ces questions n’ont plus nulle part où aller.
L’application et les données qu’elle contient ne vieillissent pas de la même façon. L’application a besoin de serveurs, de correctifs, de licences, d’intégrations et de quelqu’un capable de la réparer à deux heures du matin. Les données ont seulement besoin de rester en sécurité et consultables.
Nous aidons une entreprise de services financiers à séparer les deux. Son environnement CRM ne pouvait plus être maintenu et les serveurs devaient être mis hors service. Migrer de nombreuses années d’enregistrements vers la nouvelle plateforme était possible, mais cela aurait obligé à retravailler des données que personne n’avait l’intention de modifier à nouveau, pour un coût sans rapport avec la fréquence à laquelle elles sont consultées.
Nous avons donc conservé la base de données et retiré tout ce qui l’entourait.
La conception est volontairement modeste. Le portail lit la base SQL du CRM là où elle se trouve déjà, au moyen d’un compte en lecture seule à privilèges minimaux, qui accède aux données à travers les vues filtrées du CRM lui-même. Un portail web léger vient se placer au-dessus : une API .NET qui n’expose que les entités que les utilisateurs recherchent réellement, à savoir les contacts, les comptes, les dossiers, les activités et les notes, et une interface Angular pour la recherche, le filtrage et la consultation détaillée.
Personne ne reçoit de nouveau mot de passe. La connexion passe par l’Entra ID existant de l’organisation, et l’accès est réservé aux membres d’un seul groupe de sécurité : retirer l’accès à quelqu’un se fait donc exactement comme partout ailleurs dans l’entreprise. Le portail n’écrit jamais dans la base de données. Une fois le portail en service, aucun des composants applicatifs du CRM n’est plus nécessaire. Le déploiement s’effectue depuis les pipelines DevOps du client vers ses propres serveurs web, et comme le portail ne détient aucune donnée propre, il n’y a rien de nouveau à sauvegarder.
Les bases de données créées par un CRM ne sont pas toujours organisées autour des clés qu’attend une bibliothèque moderne d’accès aux données. Nous avons donc profilé le schéma réel avant d’écrire la moindre ligne de code de l’API, et chaque requête est un script SQL nommé et paramétré, conservé sous gestion de versions, et non une procédure stockée cachée dans la base. Le découvrir pendant la conception coûte une conversation. Le découvrir au deuxième sprint coûte le sprint.
Le document le plus important de cette mission a été la liste de ce que nous ne ferions pas. Aucun nettoyage de données. Aucune déduplication. Aucune migration vers la nouvelle plateforme. Aucun reporting au-delà des vues de recherche et de détail. Aucun export en masse. Aucun accès public.
Chaque élément de cette liste était une demande raisonnable que quelqu’un aurait formulée en troisième semaine. Les consigner avant le début du développement garde le portail peu coûteux à faire tourner et a permis de le livrer rapidement. Cela a aussi placé la discussion sur chacun d’eux là où elle doit se tenir : une décision distincte, avec son propre coût, prise plus tard si elle s’avère nécessaire.
Le portail tourne désormais dans l’environnement de test du client sur les données réelles du CRM et s’achemine vers la production. Une fois le portail mis en production et validé, les anciens serveurs applicatifs pourront disparaître, et avec eux les correctifs et les licences. Seul le serveur de base de données restera, en lecture seule. L’historique restera consultable par ceux qui en ont besoin, avec la même authentification et les mêmes règles d’accès que tout le reste. Le nouveau CRM part d’une page blanche, car il n’a rien à absorber de force pour préserver le passé.
Nos travaux de modernisation des systèmes hérités commencent généralement par cette question, et les choix de plateforme qui la sous-tendent sont présentés à la page Plateformes de données gouvernées.
Les enregistrements structurés sont la moitié la plus facile d’un retrait. Les documents qui les accompagnaient sont plus difficiles, et ce sera le sujet d’un prochain article.
Fait partie de la série Retours de nos projets. Recevez les nouvelles analyses par e-mail ou suivez le flux RSS.
Les produits de bien-être regorgent de chiffres impressionnants. La plupart mesurent la façon dont les gens se perçoivent. Cela mérite d’être mesuré, à condition que chacun sache clairement que c’est cela qui est mesuré.
Dans une application de bien-être, les gens notent des choses qu’ils cacheraient à presque tout le monde. Pour UMOYA Zone, nous sommes partis du principe que les données personnelles les plus sûres sont celles que nous ne détenons jamais.
On dit des entreprises implantées à la fois à Maurice et en Afrique du Sud qu’elles ont deux bureaux. La description utile est ailleurs : ce que chaque base apporte à une initiative dans un autre pays africain, et ce que le partenaire sur place en retire.
