Après treize ans et plus de 700 projets, ce qui nous frappe n'est pas le nombre de projets CRM décevants, c'est la constance de leurs causes. Un projet CRM déçoit rarement à cause de l'outil lui-même. Un défaut de l'éditeur, une synchronisation défaillante ou un champ mal mappé se corrigent en quelques jours. Trois choses ne se corrigent pas après le déploiement : une décision d'organisation qui n'a pas été prise au bon moment, par la bonne personne, un intégrateur choisi sur les mauvais critères, et un management qui n'a pas changé ses propres habitudes.
Le diagnostic est plus favorable qu'il n'y paraît. La déception a rarement son origine là où le comité de pilotage la cherche, mais chacune de ses causes se neutralise, à condition d'agir avant le déploiement plutôt que pendant.
Voici les sept causes que nous rencontrons le plus souvent en mission, chez des organisations B2B du mid-market aux grands comptes. Pour chacune : le symptôme, la cause racine, et la manière dont nous l'écartons dans nos propres projets.
Le symptôme. Il apparaît tard, trois ou quatre mois après le go-live. La direction commerciale constate que l'outil ne reflète pas la manière dont l'entreprise vend. Les commerciaux tiennent leurs fichiers en parallèle, le pipeline de l'outil ne correspond pas au pipeline réel, et le déploiement est désigné responsable.
La cause racine. Le déploiement a souvent été correctement exécuté ; la défaillance se situe en amont. Le projet a parfois été lancé pour de mauvaises raisons. La première est l'alibi. Le chiffre baisse, l'équipe ne prospecte pas assez et vit sur le portefeuille existant, et le CRM absent ou jugé peu performant est désigné coupable : c'est plus simple à acheter qu'un changement de comportement commercial. On déploie un nouvel outil, et six mois plus tard l'équipe ne prospecte toujours pas, avec un meilleur CRM. Un CRM ne change pas une équipe qui ne prospecte pas ; il rend visible qu'elle ne prospecte pas, et il ne sert à rien sans l'usage que l'on attend d'elle. La seconde est la surveillance : on l'installe pour contrôler les équipes, ce que les équipes comprennent dès la première semaine. Le plus souvent, la question de ce que l'outil doit changer, et pour qui, n'a simplement pas été posée. Le cycle de vente réel n'a pas été cartographié avant le paramétrage. Les étapes du pipeline ont été reprises du modèle de l'éditeur. Les objets métier (abonnements, projets, dossiers) ont été forcés dans le format « transaction ». Les cas particuliers, qui occupent une part significative du quotidien des équipes, n'ont jamais été posés en atelier. Les intégrations avec l'ERP, le devis ou la facturation ont été renvoyées à une « phase 2 » sans budget ni date, qui n'arrive jamais : la ressaisie s'installe et l'adoption ne s'en remet pas. Dans les organisations importantes, la complexité réelle (entités, canaux, cycles de vente multiples) est sous-estimée, et l'outil est déployé dans une configuration générique qui ne répond pas au besoin : trop de clics pour peu d'utilité perçue. Le projet a commencé par la configuration parce qu'elle produit du concret à montrer en comité.
Notre position est nette : un projet CRM dont le planning commence par le paramétrage a déjà pris du retard. Le cadrage n'est pas une phase préparatoire, c'est la phase où la réussite se décide.
Comment nous l'évitons. Aucune ligne de configuration de l'instance client n'est écrite avant qu'un cahier des charges décrive les processus, la donnée, les flux et les indicateurs que la direction suivra ; notre modèle de cahier des charges CRM en fixe la trame.
Le cadrage commence par une question posée à la direction : quel comportement commercial doit changer avec l'outil, et qui en répond ? Si la réponse est « prospecter davantage », le sujet est un plan de prospection, avec des objectifs et un management, que le CRM outillera ; ce n'est pas le CRM qui le créera. Nos ateliers de cadrage arrivent préparés : modèle de données esquissé, cas d'usage documentés, démonstrations construites dans HubSpot sur des scénarios proches du contexte du client. L'atelier sert à confronter et à trancher, non à découvrir.
Les cas particuliers sont recensés à ce stade et chacun reçoit une décision explicite : modélisé, contourné ou exclu du périmètre. Un cas particulier laissé sans décision au cadrage revient toujours, sous forme de fichier Excel, après le go-live. Même règle pour les intégrations : celles dont dépend le quotidien des équipes font partie du périmètre initial ou reçoivent une date et un budget fermes ; une intégration « en phase 2 » sans l'un ni l'autre est une ressaisie acceptée, et nous la nommons ainsi. Si la sélection de l'outil est encore ouverte, la grille de décision CRM traite la question préalable ; le présent article commence là où elle s'arrête.
Un CRM ne règle pas un désaccord d'organisation. Il le rend visible.
Le symptôme. Des débats sans fin sur le paramétrage. Qui possède le lead après la qualification marketing ? À quel moment une opportunité change-t-elle de propriétaire ? Le service client accède-t-il aux données commerciales ? Chaque question de configuration rouvre un arbitrage que l'organisation n'a jamais rendu. Les ateliers se multiplient, le projet ralentit, et l'outil, une fois livré, fige un compromis que personne ne défend. Six mois plus tard, le verdict tombe sur le CRM, qui n'y est pour rien.
La cause racine. Des processus de revenu non arbitrés : frontière marketing-ventes floue, règles d'attribution des comptes jamais formalisées, deux définitions concurrentes du lead qualifié, passage de relais entre la vente et l'administration des ventes jamais décrit, circuit de contractualisation qui varie selon le commercial. L'investissement interne s'est concentré sur le paramétrage de l'outil, pas sur la formalisation des routines et des processus qu'il est censé encadrer. Tant que ces sujets vivaient dans des tableurs séparés, le flou était supportable. Un CRM partagé le rend intenable, et c'est précisément sa valeur. Cette cause est la plus inconfortable des sept à nommer, parce qu'elle met en question l'organisation et non le prestataire.
Comment nous l'évitons. Dès le cadrage, nous dressons la liste des décisions de processus à prendre (propriété du lead, règles de passage entre étapes, définitions partagées, relais vente-ADV et contractualisation, périmètre CRM/ERP) et nous la soumettons à la direction avant les premiers paramétrages. Chaque décision a un propriétaire, une échéance et un statut, et les décisions en attente sont passées en revue à chaque comité de pilotage : un arbitrage qui traîne bloque une partie du projet, et cela se voit. Un désaccord tranché en trente minutes par un dirigeant coûte moins qu'une série d'ateliers qui tournent autour. La même logique s'applique au périmètre des outils : décider quels objets vivent dans le CRM et lesquels restent dans l'ERP est un arbitrage de processus avant d'être un sujet de connecteur.
Le symptôme. Il se repère dès les premières semaines. Les questions de l'intégrateur restent sans réponse plus de dix jours. Les participants aux ateliers doivent « vérifier en interne » avant de valider. Le sponsor, un dirigeant, a signé le lancement puis s'est retiré de la boucle. Chaque décision remonte, attend, et redescend déformée.
La cause racine. L'organisation a budgété la prestation, pas sa propre implication. Les équipes métier censées contribuer à la conception n'ont aucun temps dégagé : les ateliers se tiennent avec ceux qui sont disponibles plutôt qu'avec ceux qui savent, et les décisions attendent. Un projet CRM exige du client des décisions hebdomadaires, non une validation trimestrielle. Un comité de pilotage sans personne habilitée à trancher n'est pas un comité de pilotage, c'est une réunion de suivi. Deux issues sont alors possibles : le projet s'enlise faute de décisions, ou le prestataire tranche à la place du client sur des sujets d'organisation qui ne lui appartiennent pas. Dans les deux cas, le résultat déçoit. De toutes les causes de cette liste, celle-ci est la plus banale et la plus coûteuse, davantage que la technique ou le budget.
Comment nous l'évitons. Un RACI est défini dès le cadrage, et l'implication attendue côté client y figure en clair : un référent projet interne doté d'un mandat réel, disponible environ 0,5 à 1 jour par semaine pendant le projet, et un décideur nommé, capable d'arbitrer une question de processus en quelques jours. Ces engagements font parfois hésiter en avant-vente, et c'est souhaitable : une organisation qui ne peut pas dégager une demi-journée par semaine pour son propre CRM n'est pas prête à le déployer, et mieux vaut le constater avant de s'engager qu'après. Cette exigence peut coûter une signature. Elle évite une déception.
Il serait commode de conclure que la déception vient toujours du fonctionnement interne de l'organisation. Une partie des projets que nous reprenons a été cadrée et arbitrée correctement, puis confiée à un prestataire qui n'était pas fait pour elle. Le sujet n'est pas la compétence en général, mais l'adéquation : le bon intégrateur pour un projet n'est pas le bon pour un autre.
Le symptôme. Il varie selon le décalage. Avec un prestataire sous-dimensionné, l'outil reproduit la demande au sens strict : chaque exigence devient une propriété, chaque exception un workflow, et personne n'a jamais dit non. Un an plus tard, l'instance est illisible, sans documentation, et le moindre changement d'étape de pipeline exige de rappeler l'intégrateur. Avec un prestataire surdimensionné ou généraliste, c'est l'inverse : méthodologie lourde, interlocuteurs qui changent, spécifications de cent pages pour un cycle de vente qui tient en une, et une facture qui finance la structure du cabinet plus que le projet. Avec un prestataire qui ne connaît pas l'outil retenu en profondeur, des développements spécifiques apparaissent là où une fonction native existait, et chaque évolution de l'éditeur devient une migration.
La cause racine. L'intégrateur a été choisi sur des critères qui ne prédisent pas la réussite : le prix, la notoriété ou la proximité. Les critères prédictifs sont ailleurs : l'habitude de projets de taille comparable, la connaissance approfondie de l'outil retenu, la capacité à contredire une demande en atelier, l'existence de standards écrits (nommage, documentation, recette, contrôle qualité), et un modèle d'engagement qui aligne l'intérêt du prestataire sur le vôtre : un cadrage qui se conclut vite, un périmètre tenu, une instance que vous pouvez reprendre. Choisir un intégrateur est une décision de direction, au même titre que le choix de l'outil, et elle se prend souvent avec moins de rigueur.
Comment nous l'évitons. D'abord en disant à quels projets nous sommes adaptés, et à quels projets nous ne le sommes pas. Markentive est spécialisé sur HubSpot, pour des organisations B2B du mid-market aux grands comptes, ETI incluses ; nos projets de déploiement sont menés au forfait, sur un périmètre fixé au cadrage. Un projet hors de ce cadre sera mieux servi ailleurs, et nous le disons en avant-vente.
Ensuite en rendant l'adéquation vérifiable avant la signature : démonstration construite sur le contexte du prospect et non sur un scénario générique, et construction d'atelier sur-mesure afin d'adapter la méthodologie projet à la réalité de l'organisation du prospect.
Enfin en livrant une instance que le client peut reprendre : la documentation et le transfert aux administrateurs font partie du périmètre. Un client obligé de nous rappeler pour modifier une étape de pipeline est un projet à moitié réussi.
Un reporting faux est pire qu'une absence de reporting. Sans reporting, la direction sait qu'elle navigue à vue. Avec un reporting faux, elle croit voir.
Le symptôme. Au premier comité de direction après le déploiement, le pipeline affiché ne correspond pas aux chiffres que le directeur commercial a en tête. La vérification révèle des transactions manquantes, des montants comptés deux fois, des opportunités immobiles depuis trois semaines. La suite est mécanique : la direction cesse de citer les chiffres du CRM, les managers reconstruisent leurs tableaux dans Excel, et les commerciaux, constatant que plus personne ne regarde l'outil, cessent de l'alimenter. Un trimestre suffit. La confiance dans la donnée se perd en un comité et se reconstruit sur une année.
La cause racine. Presque jamais le module de reporting. Quand le paramétrage est en cause, on retombe sur les causes 1 et 4 : un cadrage escamoté ou un intégrateur inadapté. Le reste du temps, c'est la donnée elle-même : champs facultatifs là où le calcul en dépend, doublons non traités lors de la reprise, étapes de pipeline ambiguës que chaque commercial interprète à sa manière, indicateurs définis après la configuration au lieu de la précéder. Le tableau de bord agrège fidèlement une donnée infidèle.
Comment nous l'évitons. Le reporting se conçoit au cadrage, avant la configuration, qui en découle. Dès les premiers ateliers, nous fixons avec la direction les trois à cinq indicateurs qu'elle suivra en comité, puis nous remontons la chaîne : quels champs, quelles règles de saisie, quelle qualité de reprise ces indicateurs exigent. Les champs dont dépend un indicateur deviennent obligatoires à l'étape où l'information est connue ; chaque étape de pipeline reçoit un critère d'entrée écrit, identique pour tous les commerciaux. La reprise de données est menée par lots, chaque lot contrôlé et validé avec le client avant la mise en production ; les doublons sont traités avant la bascule, jamais après. La boucle recherchée est simple : un paramétrage précis produit des reportings justes, des reportings justes créent la confiance, et la confiance nourrit l'adoption. Elle tourne aussi en sens inverse, beaucoup plus vite. Notre offre d'intégration CRM est structurée autour de ce protocole.
Le symptôme. L'adoption a été traitée comme une phase finale : on déploie, on forme une fois, on observe. Quelques mois plus tard, devant des taux d'utilisation faibles, un plan de relance de l'adoption est lancé. Ces plans échouent bien plus souvent qu'ils ne réussissent. Non parce qu'ils sont mal conçus, mais parce qu'ils arrivent après que chaque utilisateur a rendu son verdict et construit son contournement : le tableur personnel, les notes sur le téléphone, la messagerie utilisée comme CRM. Déloger une habitude installée est un projet en soi, plus coûteux que celui que l'on croyait achever.
La cause racine. L'adoption a été traitée comme un sujet de formation alors qu'elle relève de la conception. Un outil adopté rend service à celui qui saisit, pas seulement à celui qui consulte les tableaux de bord. Si enregistrer un appel demande six manipulations et que le commercial ne retire rien de sa saisie, aucune formation ne compensera. Les premières semaines sont décisives : les habitudes d'usage s'y installent, dans un sens ou dans l'autre.
Comment nous l'évitons. En trois temps, et le premier commence au cadrage.
Concevoir pour l'utilisateur qui saisit : ses écrans, ses gestes, et la contrepartie que l'outil lui restitue (historique consolidé du compte, relances automatiques, priorisation du portefeuille).
Former par profil plutôt qu'en session générique : un commercial terrain, un manager et un marketeur n'ont ni les mêmes écrans ni les mêmes raisons d'adhérer ; c'est le principe de nos formations HubSpot CRM et sales enablement, avec exercices sur les cas réels de l'équipe, guide utilisateur propre à l'instance, temps dédié dans l'agenda et présentiel chaque fois que possible. Une session d'une heure en visioconférence sur des données de démonstration n'a jamais installé une habitude.
Tenir un hypercare actif les premières semaines, c'est-à-dire une présence renforcée de l'équipe projet auprès des utilisateurs, pour répondre à leurs questions et procéder aux ajustements de paramétrage nécessaires. Un hypercare négligé est l'un des moyens les plus sûrs de perdre le premier trimestre.
Le symptôme. Il se lit dans l'agenda des managers. La revue de pipeline se fait sur un fichier Excel extrait le lundi matin, le point hebdomadaire se prépare par email, le comité de direction reçoit des slides reconstruites à la main. Les commerciaux, à qui l'on demande de tout saisir dans le CRM, constatent que leur manager ne l'ouvre pas, ou seulement pour vérifier un chiffre. Quand l'outil est consulté, c'est pour relever un retard ou un écart, jamais pour préparer un entretien ou aider à débloquer une affaire. Dans l'esprit des équipes, le CRM devient un instrument de contrôle, et la saisie se réduit au minimum défendable.
La cause racine. Les managers intermédiaires n'ont pas été consultés au cadrage, ou trop tard, et certains sont devenus des détracteurs silencieux. Personne ne leur a demandé de changer leurs propres routines : le projet visait les commerciaux, pas leur encadrement. Or une équipe adopte ce que son manager regarde. Tant que le pilotage se fait hors du CRM, par confort ou par habitude, chaque demande d'un rapport Excel ou d'un point par email signale que l'outil ne compte pas. Et un CRM qui sert d'abord à surveiller produit exactement la donnée que l'on mérite : partielle, tardive, arrangée. L'outil a été pensé comme un instrument de reporting pour la direction ; il n'a jamais été présenté aux managers comme un outil de coaching de leurs équipes.
Comment nous l'évitons. Les managers sont dans les ateliers de conception dès le cadrage, avec leurs propres cas d'usage : la revue de pipeline, la préparation des entretiens individuels, l'arbitrage des priorités du portefeuille. Leurs rituels de management sont construits dans le CRM (vues, rapports, tâches) et les reportings parallèles sont arrêtés au go-live, pas après. Nous formons les managers à part, avant leurs équipes, sur un usage de coaching : lire un pipeline pour aider à conclure, pas seulement pour constater un écart. Enfin, le sponsor de direction s'engage sur une règle simple : aucun chiffre commercial n'est cité en comité s'il ne vient pas du CRM. C'est la règle la plus efficace que nous connaissions pour l'adoption, et elle ne coûte rien.
Cadrage escamoté, processus non tranchés, décideur absent, intégrateur inadapté, donnée qui fausse le reporting, adoption reportée, management qui pilote hors de l'outil : aucune de ces causes ne tient à l'outil. Toutes relèvent de décisions prises, ou non prises, par l'organisation cliente, y compris le choix de celui qui construit, et toutes se jouent avant le déploiement ou dans les semaines qui le suivent. La déception CRM est répandue et évitable pour la même raison : les organisations investissent dans l'outil et dans l'intégration, beaucoup moins dans leur propre préparation et dans le choix du prestataire.
Les sept causes ci-dessus ont un mérite : elles se diagnostiquent avant de coûter. Processus arbitrés ou non, décideur nommé ou non, paramétrage documenté ou non, donnée fiable ou non : autant de questions auxquelles votre organisation peut répondre dès maintenant, sans prestataire. Pour situer votre projet dans l'ensemble du cycle, du choix de l'outil à son exploitation, notre guide CRM : choisir, intégrer et exploiter un CRM qui sert le revenu réunit la démarche complète. Et pour cadrer le vôtre sur les bonnes bases, commencez par notre modèle de cahier des charges CRM.