Les projets Salesforce qui échouent le font rarement d’un coup. Ils échouent par une suite de décisions qui semblaient chacune raisonnables, la plupart prises dans les premières semaines, avant toute construction. La plateforme est rarement en cause. Les dégâts viennent de ce qu’on a automatisé sans le remettre en question, de données partagées que personne ne possède, d’intégrations montées dans l’urgence, et d’une adoption faible qu’on croit pouvoir régler en salle de formation.
Le cadrage automatise ce que personne n’a questionné
Le recueil des besoins tourne souvent à la transcription. Les métiers décrivent leur processus actuel, les consultants en font des user stories, et personne qui en ait l’autorité ne demande si ce processus mérite d’être automatisé. La configuration reproduit alors un processus bancal avec une grande fidélité : des Flows qui rejouent des contournements manuels, des relations d’objets qui encodent l’organigramme, des règles de validation qui imposent l’exception comme si c’était la règle.
Le rôle qui manque, c’est une autorité de conception capable de dire non : quelqu’un qui a le droit de refuser une exigence, et pas seulement de la noter. Quand le cadrage est confié à des analystes et que les responsables de la conception arrivent une fois le périmètre figé, l’écart entre ce qui a été spécifié et ce que la plateforme peut tenir est déjà inscrit dans le planning. Personne ne le verra avant la construction.
Personne ne possède les objets partagés
Le modèle de données standard de Salesforce porte des hypothèses sur la façon dont comptes, contacts et opportunités s’articulent. Quand le métier fonctionne autrement, le réflexe est de personnaliser : objets custom, relations custom, objets de jonction empilés sur d’autres objets de jonction. Personnaliser ne pose pas de problème quand quelqu’un en mesure les conséquences. Décidé champ par champ, cela renchérit chaque changement ultérieur, des intégrations aux rapports en passant par chaque Flow qui touche ces enregistrements.
Les trous de gouvernance accélèrent la dérive. Plusieurs équipes déploient sans se coordonner, les sandboxes ne reflètent pas les volumes de production, les mises en production s’écrasent entre elles, et personne ne possède les objets que toutes les équipes utilisent. Les ventes personnalisent Account pour leur processus, le service client le personnalise pour le sien, et l’objet accumule des champs que personne ne sait expliquer.
Ce qui marche tient davantage d’un modèle de propriété que d’un comité : un propriétaire nommé pour chaque objet partagé, une revue dès qu’un changement touche plus d’une équipe, et un modèle de données traité comme un document de conception, revu avant toute configuration, où chaque écart par rapport aux objets standard est écrit avec sa raison.
La phase deux qui n’arrive jamais
C’est dans les intégrations qu’un échec gérable devient coûteux. Les connexions point à point se montent pendant la première livraison parce qu’elles vont plus vite qu’une couche middleware, et cette couche passe en phase deux. La phase deux arrive rarement. L’org accumule des connexions directes (ERP, plateforme marketing, entrepôt de données), chacune avec son authentification, sa gestion d’erreurs et sa logique de relance.
Quand l’une casse, rien n’alerte personne avant qu’un processus métier s’arrête. L’admin reçoit un ticket « les données sont fausses » et doit retrouver quelle connexion en est la cause. Chaque nouveau système oblige ensuite à toucher toutes les connexions qui partagent ses données, et le remplacement de l’ERP devient un chantier de démêlage.
Le sponsor n’a pas à choisir le middleware. Il doit décider, avant la première livraison, si les intégrations passent par une frontière contractuelle supervisée, et qui possède chaque connexion, ses identifiants et ses alertes d’échec. Une phase deux sans date ni budget est une décision de ne pas la faire, et il faut la consigner comme telle.
Quand l’adoption est traitée comme un problème de formation
La faible adoption est régulièrement mal diagnostiquée. La réponse habituelle : plus de formation, une meilleure documentation, un message de la direction. J’enseigne Salesforce (les cours d’administration et de Service Cloud pour PLB ; pour Capgemini, la formation à l’outil des équipes d’agences AXA), et une salle de formation a une limite claire : elle montre comment le système fonctionne. Elle ne rendra jamais digne d’être suivi un processus que personne ne possède.
Les échecs d’adoption remontent le plus souvent à la conception. Soit le système ne correspond pas à la façon dont les gens travaillent, parce que les besoins sont venus des managers plutôt que de ceux qui font le travail. Soit il est plus lent que le contournement qu’il remplace, parce que le modèle de données est lourd et la page noyée sous les champs. Soit il n’apporte rien de nouveau aux utilisateurs, parce qu’il a été cadré autour de la collecte de données pour le reporting.
Traitez l’adoption comme une contrainte de conception. Chaque champ obligatoire et chaque écran de plus est une friction, et pendant la conception quelqu’un doit demander quel résultat métier la justifie. Quand la réponse est « on en a besoin pour le reporting », la question suivante est de savoir si la donnée peut être captée sans que l’utilisateur ait à la saisir.
Diagnostiquer avant de prescrire
Ces causes arrivent rarement seules. Un problème de modèle de données côtoie un trou de gouvernance ; un problème d’intégration nourrit un problème d’adoption, parce que les utilisateurs cessent de faire confiance à des données qui arrivent en retard ou fausses. Le premier livrable d’un programme en difficulté est donc un diagnostic qui classe les problèmes selon ce qu’ils bloquent, plutôt qu’une liste de tout ce qui ne va pas.
Le moment le moins coûteux pour ce diagnostic se situe avant le choix de l’intégrateur. Chez Disneyland Paris en 2022, j’ai audité les processus B2B et rédigé une cible Salesforce avant la sélection de l’intégrateur. Les intégrateurs ont ensuite été comparés sur une cible écrite, au lieu de découvrir le périmètre pendant la construction.
Pour un programme déjà en difficulté, le même tri s’applique : trouver le problème qui bloque les autres, souvent le modèle de données puisque le reporting, les automatisations et les intégrations en dépendent, puis ordonner le reste derrière lui. La revue d’org liste les cinq domaines à lire, et la note sur le redressement de projet couvre les 90 premiers jours.
À vérifier
- Le cadrage inclut une autorité de conception capable de refuser une exigence, pas seulement de la noter.
- Chaque objet partagé, à commencer par Account et Contact, a un propriétaire nommé.
- Chaque écart par rapport aux objets standard est écrit avec sa raison.
- La « phase deux » des intégrations a une date, un budget et un responsable.
- Quand l’adoption est faible, quelqu’un a vérifié le processus avant de commander plus de formation.