CRM existant, intégration ou logiciel sur mesure : décider à partir du travail réel

CRM existant, intégration ou développement sur mesure : comparer les options à partir du parcours client, des données, de la maintenance et de la capacité de l'équipe à utiliser la solution.

Une demande arrive sur le site web d’une PME, rejoint une boîte courriel, puis est recopiée dans un CRM. Le devis part d’un autre outil et l’équipe qui réalise la prestation reçoit ses instructions par message. Face aux oublis, faut-il remplacer le CRM, relier les applications ou développer un logiciel sur mesure ?

Ce parcours est un exemple fictif. Il illustre une difficulté concrète : un problème visible dans un outil peut prendre naissance entre deux équipes. Avant de comparer les solutions, il faut préciser le travail à améliorer et les responsabilités qui l’accompagnent.

Décrire un parcours complet

Prenons une demande commerciale, de son arrivée à la fin de la prestation. Pour chaque étape, une équipe devrait pouvoir répondre à quatre questions : qui agit, avec quelles informations, pour produire quel résultat, et à quelle condition le dossier passe-t-il à la suite ?

Cette description révèle des différences importantes. Un dossier peut être bloqué parce qu’une information manque, parce que personne n’en est responsable ou parce que deux applications affichent des versions contradictoires. Ces trois problèmes appellent des réponses différentes. Ajouter un champ ne clarifie pas une responsabilité ; ajouter une automatisation ne rend pas une donnée fiable.

Le diagnostic gagne à s’appuyer sur un petit ensemble de dossiers réels, examiné avec les utilisateurs. On peut relever les ressaisies, les étapes d’attente et les corrections nécessaires. Ces observations constituent un point de départ pour évaluer un pilote, sans promettre un gain avant de l’avoir mesuré.

Quand un CRM existant suffit

Un CRM configurable mérite d’être testé lorsque le parcours repose principalement sur des fonctions courantes : contacts, opportunités, tâches, devis ou historique des échanges. La question n’est pas seulement de savoir si une fonction existe. Il faut vérifier si l’équipe peut accomplir son travail avec les droits, les règles et les données disponibles dans la formule envisagée.

Une démonstration utile reprend un dossier représentatif, y compris une exception : changement d’interlocuteur, devis refusé ou reprise d’un dossier ancien. Elle permet d’observer le nombre de manipulations, les informations visibles et la façon de corriger une erreur.

Il est aussi utile de distinguer une contrainte métier d’une habitude. Reproduire chaque ancien tableur peut alourdir une solution qui fonctionnerait mieux avec un processus simplifié. À l’inverse, demander aux utilisateurs de contourner quotidiennement une règle essentielle révèle une mauvaise adéquation.

Quand relier les outils est préférable

Si chaque application remplit correctement sa fonction, mais que les informations circulent mal, une intégration peut être plus adaptée qu’un remplacement général. Le site web transmet la demande au CRM ; le CRM communique ensuite les éléments nécessaires à l’outil de réalisation.

Il reste à décider quel outil fait référence pour chaque information. Où modifie-t-on l’adresse du client ? Qui peut changer le statut d’un devis ? Que se passe-t-il si une transmission échoue ? Une connexion utile doit rendre ces situations compréhensibles aux personnes chargées de les traiter.

Le devis d’intégration devrait donc préciser les échanges couverts, leurs limites et la responsabilité du suivi. Une synchronisation qui semble fonctionner lors d’une démonstration ne suffit pas à établir ce qui se passera après une modification de l’une des applications. La maintenance et le traitement des erreurs font partie du périmètre à comparer.

Quand envisager un logiciel sur mesure

Le développement spécifique devient une option à examiner lorsque des règles essentielles restent difficiles à couvrir par la configuration ou les connexions disponibles. Il peut s’agir, dans un exemple hypothétique, d’un processus de validation qui dépend simultanément du type de prestation, des compétences disponibles et des autorisations du client.

Cela ne justifie pas nécessairement de reconstruire tout le système. Un module limité peut compléter un CRM existant. Le choix se fait alors fonction par fonction : que conserver, que connecter, que développer ? Cette approche permet de réserver le développement aux besoins qui le justifient.

Le périmètre initial doit inclure les conditions de fonctionnement après la livraison : documentation, accès aux données, gestion des droits, sauvegardes, maintenance et reprise par une autre équipe. Le sur-mesure apporte de la liberté de conception, mais demande aussi des décisions explicites sur la durée de vie du produit.

Comparer le même scénario avant de choisir

Les trois options peuvent être évaluées avec une grille commune : adéquation au processus, qualité et accès aux données, facilité d’utilisation, échanges avec les autres outils, coût de fonctionnement et capacité à évoluer. Chaque critère doit correspondre à une observation ou à une condition vérifiable, plutôt qu’à une note intuitive.

Le prix initial ne décrit qu’une partie du choix. Il faut aussi examiner les abonnements nécessaires, la configuration, la migration, la formation, le suivi des connexions et les évolutions prévisibles. Ces postes varient selon le projet ; ils doivent être explicités plutôt que remplacés par une estimation universelle.

Un pilote limité à un parcours et à un groupe d’utilisateurs peut enfin départager les options. Avant son lancement, l’équipe fixe ce qu’elle vérifiera : demandes bien attribuées, informations accessibles, erreurs détectables et tâches réalisables sans ressaisie inutile. Elle prévoit également comment revenir au fonctionnement précédent si le test échoue.

La décision peut alors s’appuyer sur le travail observé. Le bon périmètre est celui que l’équipe comprend, utilise et peut faire évoluer, qu’il repose sur un CRM existant, sur des intégrations ou sur un développement spécifique.