Un projet Salesforce ne s'effondre presque jamais du jour au lendemain. Il se dégrade par accumulation : un cadrage flou, une donnée mal reprise, des utilisateurs qui contournent l'outil. Le problème, c'est que ces symptômes deviennent visibles trop tard, souvent au moment de la mise en production. Pourtant, la plupart sont déjà détectables au sprint 3, quand les premières fonctionnalités sortent et que la réalité rencontre la maquette. Cet article détaille les 10 causes réelles d'échec observées sur les projets d'ETI, et les signaux faibles qui permettent d'agir avant qu'il ne soit trop tard.

Pourquoi les projets Salesforce échouent-ils vraiment ?

Les causes d'échec sont rarement techniques. Salesforce est un outil mature ; ce qui casse un projet relève le plus souvent du cadrage, de la gouvernance de la donnée et de l'adoption. L'échec se mesure de plusieurs façons : dépassement de budget, allongement des délais, périmètre livré mais inutilisé, ou abandon pur et simple.

~70%
des projets CRM sont considérés comme sous-performants selon plusieurs études sectorielles
3
le sprint où apparaissent les premiers signaux faibles exploitables
1
cause dominante : l'écart entre le besoin cadré et le besoin réel

Les 10 causes réelles d'échec

1. Un cadrage confondu avec un cahier des charges

Beaucoup d'ETI démarrent avec une liste de fonctionnalités, pas avec des processus métier priorisés. Résultat : on paramètre des objets sans savoir quelle décision commerciale ou opérationnelle ils doivent servir. Le projet devient une transposition de l'existant, pas une amélioration.

2. Une reprise de données sous-estimée

La qualité des données historiques (doublons, champs vides, formats hétérogènes) est presque toujours pire que prévu. La reprise consomme un temps considérable et retarde tout le reste. Une donnée sale importée détruit la confiance des utilisateurs dès la première connexion.

3. Un sponsor absent

Sans un décideur métier engagé qui arbitre les priorités, le projet dérive au fil des demandes contradictoires. L'intégrateur ne peut pas trancher à la place de l'organisation.

4. La sur-personnalisation précoce

Développer du code (Apex, Lightning Web Components) avant d'avoir épuisé les possibilités standard crée une dette technique qui alourdit chaque évolution et complique les mises à jour de la plateforme.

5. L'absence de gouvernance de la donnée

Qui possède le champ « segment client » ? Qui a le droit de créer un compte ? Sans règles claires, la base se dégrade rapidement, et les rapports deviennent inexploitables.

6. Un périmètre trop large au premier lot

Vouloir livrer Sales Cloud, Service Cloud et Marketing en une seule fois multiplie les dépendances et les risques. Un premier lot resserré, mis en production vite, apporte des retours concrets bien plus utiles.

7. Une conduite du changement traitée en fin de projet

La formation ne se résume pas à une session de deux heures avant le lancement. Si les utilisateurs n'ont pas été associés à la conception, ils rejetteront l'outil, quelle que soit sa qualité technique.

8. Un choix d'intégrateur mal aligné

Un partenaire compétent sur les grands comptes n'est pas forcément adapté au rythme et au budget d'une ETI. L'inverse est vrai aussi. Le désalignement de méthode se paie en incompréhensions répétées.

9. L'absence de mesure de succès

Sans indicateurs définis dès le départ (taux de connexion, complétude des fiches, cycle de vente), impossible de savoir si le projet crée de la valeur. On avance à l'aveugle.

10. Une intégration au SI négligée

Salesforce vit rarement seul : ERP, facturation, outil marketing. Sous-estimer les flux d'intégration transforme un CRM prometteur en silo déconnecté.

Les signaux faibles à détecter au sprint 3

Le sprint 3 est un moment charnière : assez de fonctionnalités ont été livrées pour que la réalité se manifeste, mais il reste assez de budget et de temps pour corriger le tir. Voici ce qu'il faut surveiller.

Sur le cadrage et le périmètre

  • Les démonstrations de fin de sprint déclenchent systématiquement des demandes de « petites » modifications structurantes : le besoin n'était pas cadré.
  • Le backlog grossit plus vite qu'il ne se vide.
  • Personne ne sait dire précisément quelles user stories restent avant la mise en production.

Sur la donnée

  • La reprise de données est repoussée « au prochain sprint » depuis le début.
  • Les premiers jeux de test contiennent des doublons ou des champs incohérents que personne n'a le mandat de nettoyer.

Sur l'adoption

  • Les utilisateurs clés ne participent pas aux revues de sprint, ou n'ouvrent pas l'environnement de recette.
  • Les retours se limitent à l'esthétique, jamais aux processus : signe que l'outil n'a pas encore été projeté dans le quotidien.

Sur la gouvernance

  • Les arbitrages traînent plusieurs jours faute de sponsor disponible.
  • Les comptes rendus de sprint ne sont ni lus ni contestés côté métier.

Si, au sprint 3, vous cochez plus de trois de ces signaux, le risque n'est pas encore l'échec — mais la trajectoire est mauvaise. Un point de recadrage formel (périmètre, données, disponibilité du sponsor) est plus efficace à ce stade qu'un plan de sauvetage en fin de projet, quand le budget est déjà consommé.

Comment reprendre le contrôle

La bonne nouvelle : aucune de ces causes n'est fatale si elle est identifiée tôt. Trois actions concrètes au sprint 3 :

  • Re-prioriser le périmètre du premier lot autour de quelques processus qui apportent une valeur mesurable, et reporter le reste.
  • Traiter la reprise de données comme un chantier à part entière, avec un responsable désigné et un objectif de qualité chiffré.
  • Redonner un rôle actif au sponsor et aux utilisateurs clés dans les revues, pour que les retours portent sur l'usage réel.

Ces ajustements supposent parfois de questionner l'alignement avec l'intégrateur : méthode, rythme, capacité à dire non aux demandes hors périmètre. Ce n'est pas un aveu d'échec, mais une hygiène de projet.

Le rôle du choix initial

Beaucoup de signaux faibles trouvent leur origine avant même le lancement, dans le choix du prestataire. Un intégrateur dont la méthode ne correspond pas à la taille et à la maturité de l'ETI reproduira les mêmes tensions à chaque projet. Qualifier le besoin en amont — sur des critères objectifs plutôt que sur un discours commercial — réduit fortement la probabilité de rencontrer ces causes d'échec.

C'est précisément le rôle d'un tiers de confiance : aider à cadrer le besoin à partir de données publiques et de critères vérifiables, puis orienter vers des intégrateurs dont la méthode et la taille correspondent au projet, sans lien commercial avec un éditeur.

Un projet Salesforce à cadrer ?

Trouver le bon intégrateur Salesforce

Mise en relation gratuite · sans engagement · qualification par la donnée publique