Un appel d’offres Salesforce peut produire un excellent plan de mise en œuvre et laisser l’acheteur avec un modèle de delivery qui cède à la première décision contestée. Les décisions qui comptent précèdent toute estimation fournisseur : qui décide, qui doit être consulté, qui possède la plateforme après le go-live, et quelle preuve fait changer une décision. Réparties entre une slide de gouvernance, une annexe de staffing et une clause du contrat, elles sont faciles à approuver et difficiles à faire respecter. Elles font partie de la conception de la solution.
Les droits de décision dans l’appel d’offres, pas dans le support de lancement
Demandez à chaque candidat de décrire les droits de décision aux endroits où un programme se bloque ou diverge. Un RACI générique ne suffit pas : il peut nommer un responsable sans dire s’il peut arbitrer entre un standard de données global, une exigence commerciale locale et une dépendance fournisseur.
Exigez un registre des décisions dès le départ. Chaque entrée nomme la décision, le propriétaire, les contributeurs, la preuve attendue, l’échéance, la voie d’escalade et le coût du retard. Le registre fait de la gouvernance un contrôle réel et permet au sponsor de distinguer une vraie dépendance d’une préférence du fournisseur.
Testez-le avec des scénarios. Une business unit demande de modifier le modèle Account partagé après le début du build. Un responsable d’intégration rejette un contrat d’API proposé par l’équipe Salesforce. Un contrôle de sécurité entre en conflit avec une date de release. Une réponse crédible dit qui décide et sur quelle preuve. « Le comité de pilotage va s’aligner » ne répond pas à la question.
Les droits de décision ont aussi une limite. L’intégrateur recommande une conception et s’engage sur la livraison. Il ne devient pas l’autorité finale sur la politique de données de l’acheteur, son modèle opérationnel cible ou son acceptation du risque. Si la propriété interne manque, le contrat ne comble pas le vide : il le constate.
Plus l’acheteur sait tôt ce qu’il veut décider lui-même, plus l’appel d’offres est précis. Chez Disneyland Paris en 2022, j’ai audité les processus B2B et fixé une cible Salesforce avant le choix de l’intégrateur : la sélection du partenaire est partie d’un périmètre écrit plutôt que d’une phase de découverte menée par le fournisseur. Un candidat qui reçoit un périmètre écrit doit le chiffrer ; celui qui reçoit un cahier des charges ouvert l’écrira à votre place.
Séparer l’autorité de conception du pilotage de la delivery
Beaucoup d’appels d’offres demandent un directeur de programme, un responsable de conception et une équipe de delivery sans demander comment ces rôles tranchent un désaccord.
L’autorité de conception (design authority) répond de l’intégrité de la solution : frontières du modèle de données, contrats d’intégration, contraintes de sécurité, exigences non fonctionnelles et dérogations aux standards. Le pilotage de la delivery répond du planning, des dépendances, des prévisions et du rattrapage des engagements manqués. Les propriétaires métier décident si le résultat vaut encore son coût.
Ces rôles se recouvrent sans être interchangeables. Le responsable de delivery expose l’impact d’une décision de conception tardive, sans la prendre discrètement pour protéger un jalon. L’autorité de conception explique pourquoi une configuration locale met en risque une capacité partagée, sans fixer la priorité métier à la place du propriétaire métier.
Exigez une autorité de conception nommée des deux côtés. Côté acheteur, cette personne a accès aux sponsors métier et le mandat de refuser une conception commode localement qui abîme une capacité partagée. Côté fournisseur, le responsable nommé a du temps réservé dans le staffing pour gouverner le travail, au-delà d’un atelier au début et d’une escalade à la fin. Demandez à chaque candidat de montrer comment ce responsable transforme un choix de conception en décision bornée : un propriétaire, des hypothèses, des critères d’acceptation et une trace écrite.
Faire de la passation un critère d’acceptation
Un programme Salesforce ne s’arrête pas au déploiement. Le modèle commercial suppose souvent une passation, mais l’appel d’offres dit rarement ce que l’acheteur doit savoir faire tourner sans l’équipe de delivery.
Fixez des critères d’acceptation du modèle opérationnel à côté des critères fonctionnels : un journal des décisions, des propriétaires nommés pour les intégrations et les métadonnées critiques, un processus de release, un circuit de tri du support, un modèle de propriété du backlog et un accès aux choix de conception importants. L’objectif est de rendre la propriété observable avant que le rôle du fournisseur change.
Demandez aux candidats quelles responsabilités restent chez eux après le go-live, lesquelles passent aux équipes internes et lesquelles demandent un service maintenu, puis ce qui rend chaque transfert crédible. Un plan de transition qui liste des réunions est faible ; celui qui nomme le futur propriétaire, la décision qu’il devra prendre, la preuve dont il a besoin et la date à laquelle il prend la main peut être testé.
L’enjeu grandit quand la plateforme couvre plusieurs business units ou partenaires : sans propriétaire commun pour les sujets transverses, chaque équipe optimise son backlog et les définitions de données divergent. La note sur le centre d’excellence Salesforce décrit où ces sujets peuvent être portés.
Noter le modèle commercial à l’aune de son modèle de contrôle
Les TJM et les estimations de vélocité ne montrent pas comment un fournisseur se comporte quand une décision modifie le plan commercial.
Demandez aux candidats quels événements changent le périmètre, lesquels déclenchent une révision des prévisions, et qui approuve un arbitrage entre coût, date et intégrité de la conception. La réponse doit relier la gestion des changements du contrat au registre des décisions du programme. Sinon, le projet vit avec deux versions de la réalité : le planning de delivery et le processus commercial.
Lisez les incitations aussi attentivement que l’estimation. Un fournisseur payé au seul taux d’occupation peut repousser la conception difficile jusqu’à en faire une exception coûteuse. Un fournisseur payé à la seule vitesse peut livrer une release qui reporte le risque sur le support. Aucun des deux cas ne suppose de mauvaise foi, seulement un contrat qui laisse la qualité et le rattrapage hors de la discussion commerciale.
Organisez une courte revue de scénario avec chaque candidat retenu, sur le même cas pour tous : une dépendance d’intégration est en retard, un sponsor demande une nouvelle priorité, et la date de go-live initiale reste visible de la direction. Demandez les deux prochaines semaines de décisions, pas une méthode de redressement. Comparez les hypothèses qu’ils contestent, les personnes qu’ils impliquent, les preuves qu’ils demandent et les engagements qu’ils refusent de prendre sans approbation.
Le premier mois teste les promesses
Une réponse à appel d’offres est un ensemble d’hypothèses. La mobilisation doit les tester avant que la conception et le build rendent tout retour en arrière coûteux.
Vérifiez que les rôles nommés animent bien les instances prévues, et que les escalades du registre aboutissent à une décision avant de devenir du bruit. Faites passer une décision de conception transverse par toutes ses étapes : demande, preuve, approbation, trace écrite, communication. Si le résultat dépend d’un accès informel à un dirigeant du fournisseur, le modèle est plus fragile que la réponse ne le laissait croire.
Une petite décision réelle suffit à montrer si l’autorité de l’acheteur, la méthode du fournisseur et les contrôles commerciaux se tiennent. Sinon, corrigez le modèle opérationnel tant que le périmètre est encore réduit.