La réponse courte
La question centrale lors de l'implémentation de Salesforce dans une organisation n'est pas "quel module activer en premier", mais plutôt comment construire un parcours où chaque étape produit un livrable qui peut être approuvé, et pas seulement une réunion supplémentaire. Ce guide suit huit étapes : Discovery, Solution Design, Construction progressive, Migration, UAT, Formation, Go Live et Hypercare. À chaque étape, il y a un livrable obligatoire, une partie prenante qui l'approuve et un risque principal à neutraliser avant de passer à l'étape suivante.
L'idée maîtresse est une séquence ininterrompue : on ne peut pas construire sans un Solution Design approuvé, et on ne peut pas se lancer sans un UAT signé par une personne ayant une autorité commerciale. Lorsque l'on saute une étape, le problème ne disparaît pas – il est simplement déplacé vers une étape où sa correction est plus coûteuse. Des informations supplémentaires sur la décision de remplacer ou non un système existant sont disponibles dans Remplacer un système CRM par Salesforce.
Carte complète des étapes
| Étape | Livrable obligatoire | Qui l'approuve | Risque principal |
|---|---|---|---|
| Discovery | Document As-Is/To-Be, Baseline et indicateurs de succès | Sponsor commercial et propriétaire du processus | Définition vague du succès révélée seulement lors de l'UAT |
| Solution Design | Modèle de données, permissions, ADR et diagramme d'intégrations | Architecte Salesforce et DSI | Solution construite autour d'une demande ponctuelle et non d'un processus |
| Construction progressive | Vertical Slice fonctionnel à chaque sprint, avec Démo | Product Owner | Accumulation d'un arriéré de "presque terminé" sans définition de fin |
| Migration | Résultat de répétition de migration complète (Migration Rehearsal) face à des critères de qualité | Propriétaire des données par objet | Données dupliquées ou manquantes découvertes uniquement après le chargement en production |
| UAT | Signature des propriétaires de processus sur les scénarios de bout en bout | Chefs d'équipe commerciaux | Test superficiel couvrant uniquement le "chemin heureux" (Happy Path) |
| Formation | Plan d'habilitation, supports de formation et liste des Champions | Responsable CRM | Utilisateurs apprenant "sur le tas" et générant des données de mauvaise qualité |
| Go Live | Liste de contrôle Go/No-Go signée et plan de Rollback | Gestion de projet | Mise en service sans plan de repli en cas d'échec |
| Hypercare | Journal d'erreurs quotidien et mesure d'adoption par rapport à la Baseline | Responsable CRM et équipe d'implémentation | Clôture prématurée du projet avant que l'adoption ne soit stabilisée |
Discovery : Avant de toucher aux outils
La phase de Discovery détermine tout ce qui suivra, et pourtant c'est celle que trop d'organisations raccourcissent pour "commencer à construire rapidement". Le livrable requis n'est pas une présentation, mais un document comprenant un processus As-Is documenté, un objectif To-Be, et une liste explicite de ce qui n'est pas inclus dans la première version. Sans cette définition, toute nouvelle demande survenant dans deux mois sera perçue comme une partie "évidente" du projet.
L'outil le plus pratique durant cette phase est une Baseline mesurable : temps de traitement d'un lead, pourcentage d'affaires conclues sans double saisie, taux de champs vides dans la fiche client. Sans un chiffre avant le changement, il est impossible de prouver une amélioration après le lancement – seulement de sentir qu'elle existe. Les organisations qui sautent cette étape y reviennent de toute façon, généralement en pleine construction, et cela coûte plus cher. D'autres implications d'un saut précoce sont détaillées dans Erreurs fréquentes dans l'implémentation Salesforce.
Solution Design : Là où la plupart des décisions coûteuses sont prises
Le Solution Design est l'étape où l'on choisit entre plusieurs options d'implémentation possibles et où l'on documente pourquoi l'une a été choisie par rapport aux autres. Le modèle de données, la structure des permissions (y compris le partage entre rôles et régions) et le diagramme d'intégrations avec des systèmes tels que l'ERP, les plateformes de paiement ou de marketing – tout cela doit être documenté avant même l'ouverture du premier environnement de développement.
Une erreur courante est de laisser l'équipe de développement "décider au fur et à mesure" de l'apparence du modèle de partage, car cela semble être un détail technique. En fait, modifier un modèle de partage après qu'il y ait déjà des centaines d'enregistrements en production est un projet en soi. Par conséquent, lorsque la décision concerne plusieurs départements ou affecte des permissions sensibles, il est important de s'assurer que les responsabilités et les rôles autour du projet sont clairs – voir plus d'informations dans L'équipe projet Salesforce.
Ce qui doit être documenté dans le Solution Design
- Modèle d'objets et de champs clés, y compris ce qui n'est pas construit dans la première version
- Carte des permissions par rôle, y compris les exceptions et les cas d'accès temporaire
- Liste des intégrations avec le sens du flux d'informations et la fréquence de synchronisation
- Au moins trois décisions architecturales avec une alternative rejetée et la raison de ce rejet
Construction progressive : Une tranche verticale et non une collection d'écrans
Dans la phase de construction, le piège courant est la progression "horizontale" – la mise en place de tous les écrans simultanément sans qu'aucun processus ne fonctionne de bout en bout. L'approche correcte consiste à construire une seule tranche verticale (Vertical Slice) à chaque cycle : un processus complet, avec des données réelles et des permissions représentatives, qui peut être démontré au propriétaire du processus pour obtenir un retour immédiat.
Chaque sprint doit se terminer par une démonstration, et pas seulement par la "mise en ligne de code". Sans Démo régulière, un stock de "presque fini" s'accumule et se révèle incomplet seulement lors de la phase d'UAT, ce qui est précisément ce qui rend le projet plus coûteux dans son dernier tiers.
Migration : La partie la plus sous-estimée
La migration de données est souvent le plus grand risque d'un projet, et elle reçoit généralement le moins de temps dans le calendrier. Il est impératif de réaliser une répétition complète (Rehearsal) – chargement de données dans un environnement de test à pleine échelle, y compris des volumes réels, et vérification des résultats par rapport à des critères de qualité prédéfinis : doublons, champs obligatoires manquants, format de date et de devise, et compatibilité entre les systèmes.
Un tableau utile pour gérer ce risque :
| Test de qualité | Ce qui est testé | Seuil d'acceptation recommandé |
|---|---|---|
| Complétude des champs obligatoires | Pourcentage d'enregistrements avec un champ critique vide | Moins de 2% |
| Doublons | Clients/leads avec le même identifiant commercial | Moins de 1% après déduplication |
| Compatibilité de format | Dates, devises, codes de pays | 100% conforme à la norme cible |
| Connectivité des enregistrements | Relations parent-enfant non rompues lors du transfert | 100% des relations critiques |
UAT : Validation avec une vraie propriété, pas une signature technique
Un UAT correctement mené implique que les propriétaires du processus exécutent eux-mêmes les scénarios de bout en bout, et non que l'équipe projet leur fasse une démonstration. Il est recommandé de choisir 8 à 12 scénarios qui couvrent non seulement le parcours normal mais aussi les cas extrêmes : un client sans adresse e-mail, une transaction annulée après approbation, un utilisateur avec une autorisation partielle. La signature de l'UAT doit être explicite – nom, date et liste des écarts restants pour la prochaine version, et non pas simplement une "approbation verbale en réunion".
Formation : Là où le projet réussit ou échoue discrètement
Même une excellente solution technique échoue si les utilisateurs ne l'adoptent pas. Un bon plan de formation comprend du matériel adapté à chaque rôle (pas une présentation uniforme pour tous), des démonstrations dans un environnement Sandbox avec des données familières, et une liste de Champions – des utilisateurs clés de chaque équipe qui peuvent répondre aux questions courantes sans avoir à ouvrir un ticket de support. Les organisations qui investissent dans la formation deux semaines avant le Go Live constatent généralement moins de fausses signalisations d'erreurs ("Le système ne fonctionne pas" alors qu'il s'agit d'une erreur de saisie).
Go Live et Hypercare : La mise en service est le début, pas la fin
Le Go Live exige une liste de contrôle signée qui inclut la vérification des permissions dans l'environnement de production, la validation des intégrations actives, et un plan de Rollback clair en cas de défaillance bloquante. Après le lancement, une période d'Hypercare s'ouvre – généralement de deux à quatre semaines pendant lesquelles l'équipe surveille quotidiennement les journaux d'erreurs, le taux d'utilisation réel et les plaintes des utilisateurs, et procède à des corrections prioritaires dans un délai d'un jour ouvrable. Clôturer le projet avant que l'adoption ne soit stabilisée est une erreur courante : les données des deux premières semaines présentent presque toujours une image moins bonne que la réalité, une fois que les habitudes se stabilisent.
Ce qui se passe réellement mal dans les organisations de taille moyenne en Israël
Dans la pratique de HPI Pro avec des entreprises de taille moyenne en Israël (entre 20 et 300 employés), la plupart des problèmes ne proviennent pas d'un mauvais choix de produit mais de raccourcis processuels :
- Direction non disponible pour approuver le Scope – Le projet avance sur la base de l'interprétation du responsable informatique, et lorsque la direction voit enfin un résultat, elle demande des changements qui font reculer le projet de plusieurs semaines.
- Dépendance vis-à-vis d'un seul développeur ou d'un petit bureau sans documentation de secours – Lorsque la personne quitte l'entreprise, personne ne comprend les décisions prises lors du Solution Design.
- Migration à partir de sources non officielles – Feuilles Excel gérées individuellement par chaque commercial, sans source de vérité unique, ce qui transforme la phase de nettoyage en un sous-projet.
- Compression de l'UAT en une semaine avant le Go Live – Lorsque le calendrier est serré, l'UAT est la première étape à être raccourcie, et c'est pourtant l'étape qu'il est le plus rentable de protéger.
- Manque de formation adaptée à la langue et au rôle – Des supports de formation génériques en anglais pour une équipe commerciale travaillant en hébreu conduisent à une utilisation partielle et à un contournement effectif du système.
La manière de réduire ces risques n'est pas de "travailler plus vite" mais de planifier la couche DevOps du projet – environnements de test séparés, processus de Release défini et suivi des changements – dès le début. Pour plus d'informations, consultez Salesforce DevOps Sandboxes.
Liste de contrôle avant de passer à l'étape suivante
- ☐ Un livrable écrit existe pour chaque étape, pas seulement un résumé de réunion
- ☐ Une Baseline est mesurée avant le début du projet
- ☐ Le modèle de données et les permissions sont approuvés avant l'ouverture du développement
- ☐ Chaque sprint se termine par une démonstration de Vertical Slice
- ☐ Une répétition de migration complète (Migration Rehearsal) a été effectuée avec un seuil de qualité défini
- ☐ L'UAT est signé par les propriétaires du processus avec une liste des écarts ouverts
- ☐ Un plan de formation adapté au rôle et à la langue existe
- ☐ Une checklist Go/No-Go et un plan de Rollback sont en place
- ☐ La période d'Hypercare est définie en termes de durée et de responsabilités
Comment mesurer le succès réel d'un projet
| Domaine de mesure | Ce qui est vérifié | Fréquence de suivi recommandée |
|---|---|---|
| Adoption | Pourcentage d'utilisateurs actifs par rapport au nombre total de licences | Hebdomadaire pendant le premier mois |
| Qualité des données | Champs obligatoires manquants, doublons | Avant le Go Live et une fois par mois |
| Performances des processus | Temps de traitement d'un lead/d'une affaire par rapport à la Baseline | Mensuel pendant les trois premiers mois |
| Incidents | Nombre de tickets de support et taux de réouverture | Quotidien pendant la période d'Hypercare |
Les organisations qui choisissent un accompagnement professionnel tout au long de ce parcours, de la Discovery à la clôture de l'Hypercare, peuvent bénéficier des services d'implémentation Salesforce pour s'assurer que chaque étape reçoit le livrable, l'approbation et le contrôle des risques appropriés avant de passer à la suivante.
Sources professionnelles
- Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html
- HPI Pro – Implémentation Salesforce — https://hpi.pro/salesforce-implementation
- HPI Pro – Méthodologie de travail — https://hpi.pro/methodology