La Réponse Courte
La plupart des projets Salesforce bloqués ne le sont pas à cause d'un code de mauvaise qualité. Ils sont bloqués parce que personne n'a pris le temps de se demander ce qui allait réellement changer dans le travail des utilisateurs, qui était responsable de chaque décision, et ce qui se passerait si quelque chose ne se déroulait pas comme prévu. Le résultat : sprint après sprint ajoutant des fonctionnalités, sans amélioration de la vue d'ensemble.
Sauver un projet Salesforce bloqué signifie d'abord arrêter le saignement, et seulement ensuite décider quoi faire de ce qui a déjà été construit. Cet ordre est essentiel : de nombreuses organisations passent directement à la phase de correction sans diagnostiquer pourquoi le processus précédent a échoué, répétant ainsi la même erreur une deuxième fois. Ceux qui souhaitent comprendre comment prioriser la dette accumulée peuvent consulter l'article Priorisation de la dette technique Salesforce.
Signes de blocage : comment identifier qu'un projet n'est plus sur la bonne voie
Il y a une différence entre un projet qui avance lentement et un projet qui ne bouge plus du tout. Les signes suivants sont récurrents dans presque toutes les missions de sauvetage que nous avons effectuées :
- Les discussions de statut se transforment en discussions d'explication : Une réunion de statut hebdomadaire qui devient une série de justifications expliquant pourquoi quelque chose n'est toujours pas prêt, sans nouvelle date limite fiable.
- Le backlog s'étoffe plus rapidement que le taux de résolution : De nouveaux éléments sont ajoutés chaque semaine, mais le nombre d'éléments clos reste constant ou diminue.
- Aucune version n'a été testée par un utilisateur réel au cours du dernier mois : Seulement une démonstration interne de l'équipe technique, sans contact avec ceux qui utiliseront réellement le système.
- Changements fréquents de besoins sans documentation : Chaque conversation génère "un petit changement supplémentaire" qui n'est pas intégré dans un document de cadrage (Scope Document) structuré.
- Manque de confiance manifeste : Les utilisateurs créent déjà des feuilles Excel parallèles "pour plus de sécurité", ce qui indique qu'ils ont cessé de croire que le système fonctionnera à temps.
Lorsque quatre de ces cinq signaux sont simultanément présents, il s'agit d'un projet bloqué et non d'un projet lent, et cette distinction modifie toute la stratégie de traitement.
Diagnostic en 10 jours : quoi vérifier et dans quel ordre
Un bon diagnostic ne nécessite pas deux mois. Dix jours ouvrables, avec une allocation adéquate, suffisent pour obtenir une image suffisamment fiable pour prendre une décision. Voici une répartition suggérée :
Jours 1-2 : Entretiens et cartographie initiale. Brèves conversations avec le Sponsor, le propriétaire du processus, deux ou trois utilisateurs finaux et le responsable de l'équipe de développement. L'objectif est de recueillir différentes versions de "ce qui a mal tourné", et non de tirer des conclusions à ce stade.
Jours 3-5 : Vérification technique directe. Accès à l'Org elle-même : structure des données, automatisation existante, permissions, journaux d'erreurs et requêtes lentes. Ici, on vérifie si le problème est architectural ou opérationnel.
Jours 6-7 : Comparaison entre ce qui a été promis et ce qui a été construit. Lecture des documents originaux (SOW, User Stories, Design Docs si existants) par rapport à l'état réel dans le Sandbox ou la Production.
Jours 8-10 : Formulation des constatations et décision initiale. Un document concis qui classe chaque problème identifié comme relevant du Scope, de l'Architecture ou de la Confiance, et présente une première recommandation : Réinitialisation (Reset), Refactorisation (Refactor) ou Poursuite à un rythme corrigé.
Trois niveaux de problème : Scope, architecture et confiance
L'erreur la plus courante est de traiter chaque blocage comme s'il s'agissait d'un problème unique. En réalité, il s'agit presque toujours d'une combinaison de trois couches différentes, chacune nécessitant une approche distincte.
Le problème de Scope se manifeste par le fait que personne ne sait vraiment ce qui doit être inclus dans la version initiale. Cela se produit lorsque la définition originale était trop générale ("gérer l'ensemble du processus de vente dans Salesforce") et n'a pas été décomposée en scénarios concrets. La solution n'est pas une nouvelle réunion de planification, mais la rédaction d'une liste Must/Should/Later précise, avec un Responsable pour chaque point.
Le problème d'architecture se manifeste par des choix techniques qui ne tiennent pas la route à l'échelle : un modèle de données qui ne supporte pas le volume d'enregistrements, une automatisation qui s'exécute dans un ordre incorrect, une intégration qui échoue silencieusement. Ici, une vérification technique approfondie est nécessaire, et parfois l'implication d'un Mise à niveau du système Salesforce comme infrastructure parallèle pour la correction.
Le problème de confiance est souvent la conséquence des deux premiers, mais il acquiert sa propre dynamique : les utilisateurs cessent de signaler les problèmes car "de toute façon, personne ne les corrige", et la direction cesse de financer les changements car "nous avons déjà essayé". Un problème de confiance ne se résout pas par des déclarations, mais par des preuves concrètes et répétées.
Tableau de diagnostic : Symptôme, cause première et première action
| Symptôme observé | Cause première probable | Première action recommandée |
|---|---|---|
| Chaque conversation génère une nouvelle exigence | Scope jamais défini, aucune définition de ce qui est hors Scope | Rédiger un document de portée avec une section explicite "Non inclus dans cette version" et le faire signer |
| Les rapports présentent des chiffres contradictoires | Plusieurs sources d'information fiables, sans source unique de vérité | Identifier le champ/objet source officiel et éliminer les duplications de rapports |
| Le système "ralentit" sous une charge moyenne | Automatisation inefficace ou boucles de mise à jour | Profilage de Flow et Apex sous charge simulée, avant toute correction ponctuelle |
| Les utilisateurs reviennent à Excel | Manque de confiance dans la capacité du système à refléter la situation réelle | Correction rapide d'un problème quotidien majeur, et communication publique de la correction |
| L'équipe technique n'explique pas ses choix | Lacunes de communication entre le Business et l'IT, pas nécessairement un problème technique | Réunion d'éclaircissement concise où chaque décision technique est présentée en termes commerciaux |
| Chaque Release repousse la date limite | Scope croissant en cours de travail sans contrôle | Gel des changements (Change Freeze) jusqu'à la fin de la vague actuelle |
Reset vs Refactor : Comment décider
C'est la décision la plus importante et aussi la plus coûteuse, elle doit donc reposer sur des critères et non sur une intuition. Trois tests peuvent aider :
- L'ampleur de la dette technique par rapport à l'ampleur de ce qui fonctionne déjà. Si 70 % des fonctionnalités fonctionnent raisonnablement bien et que seules des parties spécifiques échouent, il s'agit d'un Refactor. Si le problème réside dans le modèle de données de base, un Reset partiel est presque toujours préférable.
- Le coût de l'explication par rapport au coût de la reconstruction. Si une nouvelle équipe met plus d'une semaine à comprendre pourquoi quelque chose a été construit d'une certaine manière, il est probable que le coût de maintenance futur dépassera le coût d'une construction propre.
- L'état de la confiance des utilisateurs. Lorsque la confiance est très faible, un Reset ciblé et visible (avec l'annonce "nous lançons une nouvelle version corrigée") permet parfois d'obtenir plus de coopération qu'une correction silencieuse que les utilisateurs ne perçoivent pas.
En pratique, la plupart des sauvetages réussis sont hybrides : un Reset pour le composant central problématique (par exemple, le modèle d'Opportunité ou le processus d'approbation), associé à un Refactor pour le reste du système. Une comparaison structurée des approches figure dans Reconstruire Salesforce, qui détaille les critères pour chaque scénario.
Plan de sauvetage sur 90 jours
| Étape | Jours | Objectif principal | Livrable mesurable |
|---|---|---|---|
| Stabilisation | 1-10 | Arrêt des dommages, Gel des changements dans les zones sensibles | Diagnostic complet et liste des risques |
| Décision | 11-20 | Reset vs Refactor, portée finale pour la première vague | Document de décision signé avec Responsable |
| Première vague | 21-50 | Correction du problème le plus douloureux pour les utilisateurs | Scénario End-to-End fonctionnel et testé |
| Extension | 51-75 | Ajout de capacités selon un ordre de priorité convenu | Deux à trois processus supplémentaires en utilisation |
| Stabilisation et clôture | 76-90 | Mesure par rapport à la ligne de base, transfert de la gouvernance | Tableau de bord, documentation et plan de maintenance |
Il est crucial de planifier la phase de "première vague" autour d'un processus unique dont les utilisateurs ressentiront les bénéfices en quelques semaines, et non autour du composant le plus intéressant techniquement. Les projets qui échouent une seconde fois le font souvent parce qu'ils répètent la même erreur : ils ont commencé par la fonctionnalité la plus impressionnante au lieu de la douleur réelle. Cette phase est également directement liée aux performances réelles, et ceux qui rencontrent des problèmes de réactivité sont invités à consulter Optimisation des performances Salesforce.
Rétablir la confiance des utilisateurs
La confiance ne se rétablit pas grâce à une présentation ; elle se regagne grâce à la réalisation cohérente de petites promesses. Voici quelques principes qui ont fait leurs preuves :
- Annoncez explicitement une petite victoire. Lorsque vous avez corrigé un problème récurrent, envoyez une brève notification expliquant précisément ce qui a été réparé et qui l'a demandé. Une telle transparence génère plus de confiance qu'une liste globale de réalisations.
- Invitez les utilisateurs à un test anticipé, et pas seulement à l'UAT final. Celui qui voit une version intermédiaire et sent que ses commentaires ont été pris en compte devient un ambassadeur du projet auprès du reste de l'équipe.
- Ne promettez pas de date si vous n'en êtes pas sûr. Une date repoussée pour la troisième fois nuit davantage à la confiance qu'un calendrier réaliste, même s'il est moins optimiste.
- Documentez publiquement les échecs également. Lorsqu'un problème survient, une brève explication de ce qui s'est passé et des changements apportés inspire plus de crédibilité qu'un silence discret.
Le processus de rétablissement de la confiance prend généralement plus de temps que la correction technique elle-même, il est donc conseillé de le planifier comme une voie parallèle au plan de 90 jours, et non comme un résultat automatique de celui-ci. Les organisations qui souhaitent un accompagnement structuré pour ce processus, y compris un suivi étroit de l'équipe et de la direction, peuvent utiliser le Service Salesforce Health Check comme cadre de travail complet.
Cas d'étude organisationnel
Une entreprise de services financiers a mené un projet Salesforce pendant neuf mois sans Go Live. L'audit a révélé que le Scope avait triplé par rapport à la planification initiale, que l'équipe technique avait construit trois versions différentes du même processus d'approbation sans en documenter les raisons, et que les utilisateurs clés étaient déjà passés à la gestion de leur rapport mensuel sur une feuille de calcul séparée.
Le plan de diagnostic de dix jours a montré que le problème principal n'était pas technique : l'équipe technique recevait des exigences contradictoires de deux managers différents sans aucune coordination. La décision a été un Refactor partiel, et non un Reset complet, car la majeure partie du code était fonctionnelle. La première phase s'est concentrée uniquement sur le processus d'approbation, principale source de frustration, et en cinq semaines, une version stable, approuvée conjointement par les managers, a été mise en ligne. Ce n'est qu'alors que l'extension aux autres processus a été poursuivie.
La leçon clé : le blocage ne provenait pas d'une défaillance technique ponctuelle, mais de l'absence d'une entité unique détenant la vision d'ensemble des décisions. Un tel rôle, même temporaire, fait souvent la différence entre un projet qui réussit la deuxième fois et un projet qui se bloque à nouveau.
Liste de contrôle avant de prendre une décision de sauvetage
- ☐ Un diagnostic de 10 jours a été réalisé avec des entretiens, une vérification de l'Org et une comparaison avec les documents originaux
- ☐ Les problèmes ont été clairement classés par Scope, Architecture ou Confiance
- ☐ Une décision Reset/Refactor documentée et motivée a été prise
- ☐ Un processus unique a été sélectionné pour la première vague, basé sur une douleur réelle des utilisateurs
- ☐ Un Gel des changements (Change Freeze) a été défini pour la période de diagnostic et de décision
- ☐ Des indicateurs de référence (Baseline) ont été établis avant le début de la correction
- ☐ Un plan de communication continu est en place pour les utilisateurs et la direction
- ☐ Un Responsable unique a été désigné pour détenir la vue d'ensemble des décisions
- ☐ Le plan de 90 jours inclut des jalons mesurables et pas seulement une date de fin
- ☐ Un processus de transfert de la Gouvernance et de la Maintenance a été défini à la fin du sauvetage
Ressources professionnelles
- Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html
- HPI Pro – Salesforce Health Check — https://hpi.pro/salesforce-health-check
- HPI Pro – Support et Accompagnement — https://hpi.pro/support