La problématique : L'ordre de commande, et non l'exécution
Lorsqu'une organisation se tourne vers un fournisseur Salesforce, la première demande est presque toujours une "proposition de prix pour une implémentation". Dans de nombreux cas, il ne s'agit pas de la bonne demande. Certaines organisations ont déjà un système et ce qui leur manque est un diagnostic ; d'autres ne connaissent pas encore le processus qu'elles souhaitent ; et d'autres encore ont un système qui fonctionne de manière raisonnable, mais il leur manque une gestion continue.
Commander un type de service inapproprié génère un projet dont le livrable est non pertinent, et cela n'est souvent découvert qu'après des mois. Ce guide cartographie les quatre types de services en fonction du symptôme qui pousse une organisation à chercher de l'aide.
Cartographie rapide par symptôme
| Ce que vous dites | Ce qui est probablement nécessaire | Livrable principal |
|---|---|---|
| "Nous travaillons sur Excel et voulons de l'ordre" | Analyse et implémentation par vagues | Carte des processus, modèle de données, première vague en production |
| "Nous avons Salesforce mais personne ne l'utilise" | Bilan de santé et plan d'adoption | Rapport de conclusions priorisées et ordre de correction |
| "Le système est lent et défectueux après des années" | Diagnostic technique et plan de dette technique | Cartographie de la dette, recommandation de refactor ou de reconstruction |
| "Le projet est bloqué depuis six mois" | Sauvetage de projet | Évaluation de la situation, décision de poursuite, plan de stabilisation |
| "Il nous faut quelqu'un pour la maintenance courante" | Accompagnement ou services gérés (Managed Services) | SLA, rythme des livraisons, point d'entrée pour les requêtes |
| "Le PDG veut savoir si Salesforce convient" | Conseil court, pas de projet | Avis et recommandation d'adéquation |
Ce tableau suffit pour la plupart des cas. Le reste de l'article détaille ce qu'il faut exiger pour chaque service.
Service 1 : Conseil et analyse fonctionnelle
Quand le commander : Lorsque le processus, la source de vérité et les limites du projet ne sont pas encore clairs ; ou lorsqu'il existe un désaccord interne entre les départements.
Ce que le livrable doit inclure : Une carte des processus au niveau de la décision, un modèle de données central, un modèle d'autorisation, une carte des systèmes, des critères d'acceptation et des indicateurs de base. Un livrable qui n'inclut pas les cinq premiers n'est pas une analyse mais un compte-rendu de réunions.
Portée typique : Entre deux et huit semaines, selon le nombre de processus interdépartementaux. Ce qu'il faut exactement obtenir et comment identifier un bon consultant est détaillé dans le Guide de Conseil Salesforce.
Service 2 : Implémentation et déploiement
Quand le commander : Lorsque l'analyse fonctionnelle existe, les propriétaires de processus sont connus et la décision a été prise concernant ce qui est inclus dans le premier flux.
Ce qui doit être inclus dans le contrat : La définition des vagues, les critères d'acceptation pour chaque vague, la responsabilité de la migration des données, le mécanisme de demande de changement, la période de garantie et le plan de transfert de connaissances. L'absence des deux derniers est la cause fréquente d'une dépendance à long terme vis-à-vis du fournisseur.
Signal d'alerte : Une proposition qui détaille le nombre d'heures de développement mais ne précise pas ce qui est considéré comme "achevé".
Service 3 : Bilan de santé (Health Check) et diagnostic
Quand le commander : Lorsque le système est en production mais que quelque chose ne fonctionne pas — faible adoption, données non fiables, performances, ou incapacité à modifier sans causer de ruptures.
Ce que le livrable doit inclure : Une liste de conclusions avec leur gravité, leur impact commercial, l'effort de correction et l'ordre recommandé. Un rapport qui énumère cinquante conclusions sans priorisation est inutile ; un rapport qui dit "commencez par corriger ces trois-là et ne touchez pas au reste pour l'instant" est un produit utile.
Différence importante : Un Bilan de Santé n'est pas un projet de correction. Il vise à permettre de décider quoi corriger et dans quel ordre.
Service 4 : Accompagnement, support et Managed Services
Quand le commander : Lorsque le système est en production et qu'il n'y a pas d'équipe interne capable d'assurer la propriété continue.
Ce qui doit être défini : Ce qui est inclus et ce qui ne l'est pas. La distinction essentielle se fait entre la correction d'un bug, une petite modification de configuration et le développement d'une nouvelle fonctionnalité. Un contrat qui regroupe les trois dans une "banque d'heures" a tendance à exploser en un trimestre, car le développement de nouvelles fonctionnalités dévore les heures allouées au support.
En outre : Temps de réponse selon la gravité, rythme de livraison régulier et propriété de la documentation.
Combinaison optimale des services
La plupart des organisations ne consomment pas un service unique mais une séquence. La séquence saine se présente comme suit :
- Un conseil rapide pour décider de l'adéquation — des jours, pas des semaines.
- Une analyse fonctionnelle ciblée pour la première vague.
- Une implémentation par vagues.
- Une période de stabilisation définie après la mise en production.
- Un accompagnement continu.
- Un Bilan de Santé périodique, de préférence réalisé par une partie tierce et non par le constructeur initial.
Le sixième point est le plus souvent ignoré, alors qu'il est le moins coûteux.
Exemple illustratif : Chaîne d'hôtels-boutiques
Le scénario est hypothétique et à des fins d'illustration. Une chaîne de quatre hôtels a contacté trois fournisseurs pour une proposition d'implémentation Salesforce afin de gérer les événements et les demandes des clients. Les deux premières propositions concernaient une implémentation complète s'étendant sur plusieurs mois.
Le troisième fournisseur a posé une question unique : Qui définit ce qu'est un "événement" — le responsable des événements de chaque hôtel ou le siège social. La réponse était qu'il n'y avait pas de définition commune. Dans une telle situation, une implémentation complète aurait créé quatre systèmes différents sous un même nom. La chaîne a plutôt commandé une courte analyse fonctionnelle, a obtenu une définition unique convenue et un modèle de données, et ce n'est qu'alors qu'elle a procédé à l'implémentation — avec une portée plus limitée que ce qui avait été proposé initialement.
Signaux d'alerte lors de la commande d'un service
- L'offre estime des heures mais ne définit pas de livrable.
- La même offre inclut l'analyse et l'implémentation pour un montant unique sans jalon permettant un arrêt.
- Il n'y a pas de période de garantie définie après la livraison.
- Il n'y a pas de clause de transfert de connaissances et de documentation dont la propriété revient à l'organisation.
- Le fournisseur refuse de fournir un avis architectural avant la signature.
Les outils pour vérifier le fournisseur lui-même — et pas seulement le service — sont regroupés dans le Guide pour choisir votre partenaire d'implémentation Salesforce.
De la demande au document
Une fois que le service requis a été décidé, l'étape suivante consiste à le formuler de manière à ce que les propositions reçues soient comparables. La structure du document de demande de proposition et la liste des questions à inclure sont détaillées dans le Guide RFP pour l'implémentation Salesforce, et les clauses qui doivent figurer dans le contrat lui-même sont détaillées dans le Guide Contrat et SOW pour Salesforce.
Prochaine étape
Avant de demander une proposition, décrivez en une phrase le symptôme — et non la solution. "Nous n'avons pas une vue client unifiée entre les ventes et le service" conduit à une commande différente de "Nous voulons Salesforce". Cette phrase vaut plus que tout document de spécifications rédigé par la suite.