Projet CRM qui dérape : les 7 raisons réelles (et comment les éviter)

Près d’un projet CRM sur deux dérape. Vous le savez, vous avez peur, c’est normal. Mais « dérape » ne veut pas dire « échoue », ça veut dire « fait trois mois de plus, coûte 40 % plus cher, et 40 % de l’équipe ne l’utilise pas six mois après ». Cet article décrit les sept vraies causes de dérive, avec des signaux d’alerte que vous pouvez identifier jour un.

Le chiffre qu’on ne dit pas : 1 projet CRM sur 2 dérape

Une étude menée sur 200+ projets CRM en France et Belgique (2024-2026) montre que 47 % des projets sortent de budget, de planning ou de scope. 12 % sont arrêtés avant go-live. 35 % arrivent à bon port mais avec adoption insuffisante (moins de 60 % d’utilisation six mois après). Seul 16 % des projets sont « réussis » : dans les budgets, à l’heure, avec une adoption saine.

Ça fait mal. Mais c’est utile, parce qu’une fois que vous connaissez les sept vraies causes, vous les évitez.

Raison 1 : Le cahier des charges écrit pour le CRM, pas pour le métier

Voici la scène : vous êtes en atelier avec le consultant qui dit « bon, parlons des champs HubSpot ». Boom, vous avez raté le moment critique. Un cahier des charges bon, c’est pas « voilà les 150 champs qu’il faut dans le CRM », c’est « voilà les cinq processus métier qu’on supporte, et voilà comment on les mesure ».

Anecdote réelle : Une PME de 60 personnes (logistique B2B) descend un CRM avec 180 champs. Le cahier des charges décrit chaque champ. Six mois après, 40 champs sont remplis, 140 ne servent à rien, l’équipe est noyée. Coût caché : 15 k€ en configuration inutile. Raison de la dérive : le consultant voulait « bien faire », il a ajouté tout ce qu’il aurait pu être utile. Mauvais.

Signal d’alerte : Votre cahier des charges a plus de 20 pages. Votre consultant parle de « champs » avant de parler de « processus ». Vous vous demandez « pourquoi on met ce truc ? » sur plus de trois champs.

Comment l’éviter : Un bon cahier = deux pages max. Cinq processus métier clés. Pour chacun : input (qui lance ?), étapes critiques, output (qu’est-ce qui se passe après). Le CRM supporte ça. Zéro mention de « champs HubSpot » ou « objets Salesforce » au départ. Ça vient après. Un consultant qui vous demande « bon, comment vous étiez organisés avant le CRM ? », pas « bon, combien de champs ? » = bon consultant.

Raison 2 : La donnée n’a jamais été nettoyée avant la migration

Vous aviez un vieux Pipedrive depuis 2015. Plein de doublons (le même client est « Acme Corp », « ACME », « Acme corporation »). Des emails faux. Des leads morts depuis trois ans. Des champs vides à 80 %.

Vous décidez de migrer. Vous pressez le bouton. Tout passe dans HubSpot. Avec les doublons, avec la merde, avec l’histoire.

Six semaines après go-live : votre équipe passe 30 % de son temps à nettoyer la donnée en live. Trois mois après : plus personne ne fait confiance aux données. Quatre mois après : l’adoption s’effondre. Le projet a coûté 50 k€, mais c’était pour rien.

Anecdote réelle : Un cabinet de conseil RH de 25 personnes migre Salesforce vers HubSpot. Données : 8 000 contacts. Après migration, 3 200 doublons détectés. Coût de nettoyage improvisé : 8 k€ sur 2 mois en post-go-live. Timeline étirée : le projet qui était terminé à go-live a dû être rouverte. Moral de l’équipe : catastrophique. Raison : « on va nettoyer après », on a dit. « Après » c’est jamais.

Signal d’alerte : Le devis dit « donnée : 2 k€ ». Vous avez plus de 1 000 contacts. Quelqu’un dit « on va faire du nettoyage manuel dans le nouveau CRM ». Le consultant dit « on migre et on verra ».

Comment l’éviter : Deux semaines avant la go-live, vous avez un audit data. Combien de doublons ? Taux de donnée manquante ? Validité des emails ? Sur cette base, une liste « prête à migrer » (70 % de ce qui existe) et une corbeille. Ça coûte 3 à 8 k€. Ça vous sauve 20 k€ en post-go-live. Demandez-le au consultant. S’il dit non, c’est un mauvais consultant.

Raison 3 : L’utilisateur final n’a pas été impliqué

Vous avez un projet CRM. Le sponsor c’est le DSI ou le VP Sales. Les ateliers, c’est une fois par semaine avec un représentant par fonction. Personne de « l’équipe opérationnelle » (c’est-à-dire les mecs qui font l’appel à froid, qui valident les devis, qui clôturent les deals) n’est dans les ateliers.

Trois mois plus tard, vous êtes en go-live. L’équipe opérationnelle découvre le CRM. Et découvre aussi que personne n’a demandé son avis. Les workflows ne correspondent pas à comment elle bosse vraiment. Elle repasse à Excel. Ou elle abandonne le CRM pour faire son job.

Anecdote réelle : Une PME de 120 personnes (logistique) met en place un CRM. Les ateliers inclus le directeur ventes et un chef de secteur senior. Les 15 autres commerciaux ? Zéro. Go-live : « pourquoi je peux pas filtrer mes prospects par région directement ? » « pourquoi y a pas un champ pour les dates de reprise ? » « pourquoi on me force à remplir le « montant potentiel » avant de pouvoir avancer ? ». Ces trois questions auraient pris deux heures à régler en atelier. Elles prennent trois semaines en post-go-live. Raison : personne n’a écouté.

Signal d’alerte : L’équipe opérationnelle ne participe pas aux ateliers. Le sponsor dit « on va les impliquer après go-live via la formation ». C’est trop tard. Vous lisez le cahier des charges et vous vous dites « attends, avec comment ils vont faire ça ? ».

Comment l’éviter : Chaque fonction opérationnelle (vente, ops, support, compta si pertinent) a au minimum deux représentants dans les ateliers. Représentant senior (qui décide) et représentant junior (qui fait). Pas de CAC (comité d’arbitrage) qui décide pour l’équipe. Si c’est 30 personnes, c’est 30 personnes. Si c’est 200, ce sont des sous-groupes par processus, mais personne n’est exclu. L’adoption se construit en atelier, pas après go-live.

Raison 4 : Le partenaire facture des heures, pas un résultat

Votre devis dit « 1 000 heures de consulting à 700€/h ». Vous vous dites « ok, c’est 700 k€, oups ». Non. Pire : dans un forfait horaire, le consultant n’a aucun intérêt à faire vite. S’il finit en 800 heures, il facture 800. S’il fait durer six mois, il facture six mois d’intermittent. Sa vie s’améliore si le projet s’éternise.

C’est pas une conspirations, c’est mécanique. Les gens réagissent aux incitations. Dans un modèle « TJM, tant qu’il y a du boulot », l’intérêt du consultant n’est pas votre succès, c’est votre éternité.

Anecdote réelle : Une agence prend un projet CRM à 800€/j pour une PME. Scope : « mettre en place un CRM + intégrer compta et ERP ». Le consultant y va avec prudence. Il fait des trucs deux fois parce qu’il n’est pas sûr. Il itère. Les ateliers durent trois heures au lieu de deux. Six mois plus tard, c’est fini. Coût réel : 170 jours = 136 k€. Vous aviez dit 120 k€. Vous vous êtes ruiné. Raison : le consultant a optimisé pour « faire du jour » pas pour « faire du résultat ».

Signal d’alerte : Le devis est en TJM. Le scope dit « jusqu’à X jours, après on redéfinit ». L’engagement n’est pas clair sur « c’est fini quand ». Le consultant vous promet 800 heures mais dit « selon le détail qu’on découvre, ça peut être plus ».

Comment l’éviter : Devis en forfait. « C’est 60 k€, c’est fini fin novembre, que ce soit 400 ou 600 heures. » Le consultant a intérêt à faire vite. Si c’est TJM, mettez une enveloppe budgétaire fixed : « 60 k€ max, c’est soit 100 jours à 600€, soit 85 jours à 700€, peu importe, c’est 60 k€. » Ça change tout. Demandez des références : « montrez-moi trois projets que vous avez terminé en forfait. » Si le consultant balance des excuses, c’est pas bon.

Raison 5 : Pas de gouvernance après le go-live

Go-live : c’est fini. Le consultant s’en va. Vous pensez que c’est le début, mais structurellement, c’est la fin de l’appui.

Deux mois après, vous avez 50 demandes d’évolution : « rajoute un champ », « change ce workflow », « ajoute une intégration avec ce nouvel outil ». Qui arbitre ? Personne. Tout le monde crie fort. Le CRM devient un dépotoir d’évolutions non validées. Quatre mois après : plus personne ne comprend comment ça marche. L’adoption s’effondre parce que le CRM a muté en mille trucs au lieu de rester simple.

Anecdote réelle : Une PME de 90 personnes (SaaS) met en place un CRM. Go-live : 2 000 leads dans le système. Tout neuf. Le VP Sales dit « c’est parfait ». Deux mois après, 40 demandes d’évolution. Pas de processus de validation. Chaque demande, dès qu’un responsable crie « c’est urgent », elle passe en prod. Après six mois : 150 champs, 80 workflows, zéro documentation, zéro personne qui comprend le system. Budget TMA explose à 30 k€/an parce qu’on répare les bugs qu’on crée. L’adoption ? 40 %. Raison : pas de gouvernance. Il fallait dire « nouvelles features, c’est mardi matin en comité, vous demandez quinze jours avant, on arbitre ensemble ».

Signal d’alerte : Go-live : « bravo, c’est fini ». Pas de backlog d’évolution documenté. Pas de personne qui dit « c’est moi qui reçoit les demandes de changement ». Personne ne sait qui facture les evolutions post-go-live.

Comment l’éviter : Avant go-live, définissez un processus de gouvernance : « demandes d’évolution, on les reçoit ici, on les valide mardi, on en parle avec Cloud Koala/le fournisseur, on arbitre, on fait une release par mois ». Une personne interne (responsable métier du CRM, 10 % de son temps) qui tient ce processus. C’est boring. C’est aussi ce qui fait la différence entre un CRM qu’on aime et une usine à gaz qui fait chier tout le monde.

Raison 6 : Les intégrations ont été sous-estimées

Vous avez un CRM. Mais vous avez aussi un ERP, une compta, un outil marketing, un data warehouse, un système de support client. Tout doit parler.

Le consultant dit « ah, on va utiliser Zapier, c’est cool, ça prend une journée par intégration ». Six mois après : Zapier est down, vos données se synchronisent mal, un contact HubSpot ne se crée jamais en compta, un deal de 50 k€ passe inaperçu parce que l’API d’ERP a changé.

Les intégrations, c’est la grume d’un projet CRM.

Anecdote réelle : Une PME de 110 personnes (industrie) met en place Salesforce. Six systèmes à intégrer. Le consultant dit « c’est quatre-vingt-dix heures pour les six, je fais ça en deux semaines ». Résultat : sept mois après go-live, une intégration sur six n’est pas vraiment stable. Une autre a des pertes de données sporadiques. Deux autres font doublement. Budget post-go-live pour « fixer les intégrations » : 25 k€. Raison : les intégrations, c’était du « on va voir » pas du « on l’a testé, c’est testé ».

Signal d’alerte : Vous avez 4+ systèmes à intégrer. Le consultant dit « c’est facile avec Zapier ». Personne n’a fait un POC (proof of concept) avant de dire « oui, ça marche ». Le devis d’intégration est très léger pour la complexité (un budget de 10 k€ pour 6 intégrations c’est du rêve).

Comment l’éviter : Chaque intégration (après la première) = un POC de trois jours AVANT le devis. Vous testez le flux de bout en bout. Si ça marche, vous facturez deux jours de mise en prod. Si ça marche pas, vous savez que c’est plus cher ou plus compliqué que prévu. Budget crédible pour 6 intégrations : 40 à 80 k€. Si le consultant dit moins, il n’a pas écouté l’ampleur. Demandez une architecture d’intégration (un dessin : quels systèmes, quels flux, quels risques) AVANT de signer. Si y a pas de dessin, c’est pas viable.

Raison 7 : Personne n’a tracé le ROI

Vous lancez un projet CRM. Coût : 100 k€. Bénéfice attendu : votre équipe gagne 15 % de productivité, c’est 150 k€/an de valeur, ROI positif en 8 mois.

Douze mois après go-live. Personne n’a mesuré. Vous avez pas de baseline (avant). Vous avez pas de mesure (après). Vous pouvez pas montrer si c’est rentable. Pire : si ça a pas marchée (adoption 40 %), tout le monde le sent mais personne ne peut le prouver chiffré.

Anecdote réelle : Un cabinet de conseil de 75 personnes déploie un CRM. Engagement : « ça va faire gagner 20 % de temps en prospection ». Douze mois après : le managing partner dit « c’est un échec, on l’utilise pas vraiment ». Mais personne n’a mesuré le temps avant et après. Peut-être qu’il y a eu un gain qu’on a pas vu, peut-être que c’est un vrai dérape, on ne sait pas. Coûts gaspillés : au moins 50 k€, peut-être plus. Raison : pas de mesure.

Signal d’alerte : Personne ne sait répondre à « avant le projet, on vendait combien par personne par mois ? ». Le projet CRM dit « on gagne 15 % », mais y a pas d’hypothèse précise (15 % de quoi ? comment on mesure ?).

Comment l’éviter : AVANT go-live, vous mesurez trois KPIs : (1) cycle de vente moyen, (2) taux de conversion lead-to-deal, (3) productivité vente (CA/personne/mois). Vous les re-mesurez 3 mois, 6 mois, 12 mois après. Vous avez une baseline, vous avez un progrès mesurable. Si c’est -5 % (dérape), vous le savez. Si c’est +18 % (succès), vous le savez aussi. Ça oriente aussi la formation (si adoption est faible, c’est qu’on a raté le changement, pas qu’on a mal choisi le CRM).

Le check-list des 10 points avant de signer

1. Cahier des charges : Deux pages max. Cinq processus métier. Zéro mention de champs techniques. A-t-on posé la question « comment on mesure le succès » ? Si pas, c’est pas bon.
2. Audit data : Avez-vous un devis pour « audit + nettoyage donnée avant migration » ? Si pas, ça veut dire vous payerez après go-live.
3. Implication opérationnelle : L’équipe qui utilise vraiment le CRM participe-t-elle aux ateliers ? Pas juste le sponsor. Les gens qui font le job. Si pas, c’est red flag.
4. Devis forfait : C’est en forfait fixe ou en TJM ? Si TJM, y a une enveloppe budgétaire fixée ? Pas d’ambiguïté « selon ce qu’on découvre » après go-live ?
5. Architecture intégration : Avez-vous un dessin des systèmes à intégrer, des flux, des risques ? Pas juste une liste « oui, on intègre compta ». Un vrai schéma. Si pas, demandez-le.
6. POC intégration : Pour chaque intégration « complexe » (pas triviale), y a une POC de 3-5 jours AVANT le prix final ? Si le consultant dit « c’est trop long », c’est qu’il veut pas se découvrir.
7. Gouvernance post-go-live : Qui reçoit les demandes d’évolution après go-live ? Qui arbitre ? C’est formalisé ? Si c’est flou, c’est que personne ne va le faire.
8. Formation + changement : Le devis inclut-il plus que « une journée de formation par fonction » ? Workshops métier ? Champions identifiés ? Support post-go-live ? Si c’est juste « webinaire », c’est insuffisant.
9. TMA claire : Budget pour la maintenance annuelle, c’est quoi ? Est-ce que c’est clair avant de signer ? Un consultant qui dit « on verra après » n’aime pas clarifier parce qu’il sait que c’est cher.
10. KPIs de succès : Vous mesurez quoi avant et après ? C’est quantifié ? Si personne ne peut répondre en 30 secondes, c’est pas bon.

Pour aller plus loin

Si cet article vous a été utile, ces lectures complémentaires de notre blog le prolongent bien :

FAQ

Si un projet commence à déraper, à quel moment on le sauve encore ?

Jusqu’à go-live, c’est sauvable : vous ramenez le scope (moins de champs, moins d’intégrations), vous retardez go-live de 4 semaines, vous augmentez le budget de 15 à 20 k€. Après go-live, c’est plus difficile : vous devez faire « un deuxième projet » de correction / gouvernance / adoption. Ça coûte 20 à 40 % du coût original. Mieux vaut sauver AVANT.

On est sur un projet qui dérive, comment on le dit au consultant ?

Directement. « On a X semaines restantes, le scope actuel tient pas dans le timing. Qu’est-ce qu’on enlève ? » Un bon consultant vous dira quoi scoper down. Un mauvais consultant vous promettra « on va y arriver » (et vous ne serez pas dedans le problème, lui si). La vérité, c’est toujours la meilleure stratégie.

Nous on a choisi un CRM qu’on regrette. Migrer vers un autre, c’est pas déraper aussi ?

Oui, mais moins que de continuer dans la mauvaise direction. Si vous êtes six mois post-go-live et que l’adoption est catastrophique parce que le CRM n’est simplement pas bon pour votre métier, migrer vers un meilleur CRM c’est investir dans le succès long terme. Exemple : vous aviez choisi Pipedrive (trop simple), vous migrez Salesforce (plus flexible). Coût migration : 30 à 50 k€. Coût de rester dans Pipedrive cinq ans avec 40 % d’adoption : 150 k€ en valeur détruite. Raison de migrer : rentabilité. Si le premier CRM est pas mauvais juste « mal implanté », la solution c’est une meilleure gouvernance et une meilleure formation, pas de migrer.

Si on signe avec Cloud Koala, comment vous évitez ces sept pièges ?

Cahier des charges métier avant tout (on appelle ça « L’Atelierographie »). Audit data financé en début. Tous les ateliers incluent opérationnels, pas juste sponsors. Devis forfait, pas TJM. Architecture intégration dessinée et validée d’abord. POC pour chaque intégration non-triviale. Gouvernance formalisée avant go-live (nous, on la facilite). Vrai budget formation (pas juste slides). TMA = 10 à 15 % du coût intégration, c’est clair avant de signer. KPIs fixés au démarrage, mesurés après. Après go-live, on reste deux mois en « support renforcé » (deux jours par semaine de disponibilité) pour corriger ce qui émerge. C’est pas « devis 50 k€ bye », c’est « 50 k€ c’est la première phase, success en mois trois » + on redéfinit la TMA selon ce qu’on a vraiment appris.

Conclusion

Un projet CRM qui dérape, c’est jamais la faute du CRM (HubSpot, Salesforce, Pipedrive, Zoho, tous les quatre sont bons). C’est la faute de l’approche : mauvais cahier des charges, données pas propres, opérationnels pas impliqués, partenaire mal incité, pas de gouvernance, intégrations sous-estimées, ROI pas tracé. Chacun de ces sept points est évitable. Si vous êtes au stade « on va signer », relisez cette checklist des dix points. Si vous en cochez pas au moins neuf, signé pas, demandez au consultant de revoir son approche. Si vous êtes en cours de projet, regardez où vous êtes sur les sept raisons et agissez avant go-live : c’est le moment où c’est encore facile de corriger.

Vous voulez parler de votre projet ? Contactez Cloud Koala, on revient vers vous sous 24 h.