La tarification n'est pas une question de prix, mais de risque.
Lorsqu'une organisation hésite entre un modèle à prix fixe et un modèle à temps et matériel (Time & Materials), elle cherche généralement à savoir quelle option est la plus économique. C'est une question erronée. Les deux modèles englobent le même travail ; la différence réside dans qui absorbe l'écart lorsque la réalité diverge de l'hypothèse initiale.
Dans le modèle à prix fixe, le fournisseur absorbe le risque — il intègre donc une marge de risque dans son prix et se protège en définissant précisément ce qui est inclus. Dans le modèle T&M, l'organisation absorbe le risque — elle a donc besoin de mécanismes de contrôle. Avec un contrat de maintenance (Retainer), les deux parties gagnent en stabilité au détriment d'une flexibilité réduite.
La règle est simple : plus la définition du périmètre est mature, plus le prix fixe est avantageux. En revanche, s'il y a de réelles inconnues, un modèle T&M plafonné est préférable.
Comparaison rapide entre les trois modèles
| Aspect | Prix fixe | Time & Materials | Retainer |
|---|---|---|---|
| Qui supporte le risque de périmètre | Le fournisseur | L'organisation | Partagé dans le cadre du périmètre convenu |
| Conditions de réussite | Périmètre bien défini | Transparence et gestion rapprochée | Demande stable et prévisible |
| Flexibilité au changement | Faible, via des demandes de changement | Élevée | Moyenne |
| Fardeau administratif pour l'organisation | Moyen, centré sur la définition | Élevé, continu | Faible |
| Échec typique | Conflits de périmètre | Dérive des heures de travail | Heures non utilisées ou consommées |
| Convient le mieux pour | Phase de déploiement définie | Intégration, migration, recherche | Maintenance et amélioration continue |
Prix fixe — Quand l'adopter et à quoi faire attention
Ce modèle est adapté lorsque les spécifications incluent des critères d'acceptation, lorsque les intégrations sont connues et documentées, et lorsque la qualité des données a été vérifiée. Dans de telles conditions, le fournisseur peut fixer un prix avec une confiance raisonnable, et l'organisation bénéficie d'une véritable certitude budgétaire.
Mécanismes de protection à exiger :
- Définition de "terminé" pour chaque livrable, pas seulement son nom.
- Liste explicite des hypothèses sur lesquelles le prix est basé.
- Tarif préétabli pour les demandes de changement, afin d'éviter qu'il ne soit fixé sous contrainte.
- Calendrier de paiement lié à l'acceptation des livrables et non aux dates.
Signal d'avertissement : Un prix fixe proposé sans aucune question sur le volume de données, le nombre d'utilisateurs ou les systèmes sources. Un tel prix est voué à changer, la question est seulement quand.
Time & Materials — Quand l'adopter et comment le contrôler
C'est le modèle approprié lorsqu'il existe des inconnues qui ne peuvent être éliminées à moindre coût : un ancien système central sans documentation, des données historiques de qualité incertaine, ou un processus métier en constante évolution.
Mécanismes de contrôle qui le rendent sûr :
- Plafond pour chaque jalon avec une alerte dès l'atteinte d'un pourcentage convenu de celui-ci.
- Rapportage par tâche : nom de la tâche, heures consacrées, statut.
- Points de sortie à la fin de chaque jalon, sans pénalité.
- Composition de l'équipe convenue : nombre d'heures senior et junior, pour éviter tout changement discret.
La dernière clause est souvent oubliée, et elle influence le coût bien plus que le tarif lui-même.
Retainer — Quand il devient un gaspillage
Le modèle de Retainer fonctionne très bien après la mise en production, lorsqu'il y a un flux constant de demandes. Il échoue dans deux situations opposées : lorsque la demande est faible et que l'organisation paie pour des heures non utilisées, et lorsqu'un développement significatif est introduit, épuisant ainsi la capacité de support.
Deux corrections simples : une séparation claire entre le support et le développement, et une clause de report partiel des heures non utilisées au mois suivant, avec un plafond. La combinaison des deux stabilise le modèle.
Modèles hybrides qui fonctionnent en pratique
| Phase du projet | Modèle recommandé | Justification |
|---|---|---|
| Conseil et spécifications | Prix fixe court | Le périmètre est connu, le livrable est défini |
| Migration de données | T&M avec plafond | La qualité des données se révèle en cours de projet |
| Intégrations vers des systèmes existants | T&M avec plafond | Dépend de la partie tierce |
| Phase de déploiement définie | Prix fixe | Les critères d'acceptation existent |
| Période de stabilisation | Inclus dans le prix de la phase | Évite les discussions sur ce qui est un bug et ce qui est un changement |
| Maintenance courante | Retainer | Demande constante |
Une telle répartition peut sembler plus complexe qu'un seul accord, mais elle réduit précisément les litiges qui ralentissent les projets.
Exemple illustratif : Importateur d'équipements médicaux
Le scénario est hypothétique et conçu à des fins d'illustration. Un importateur a demandé une proposition à prix fixe pour un projet qui comprenait également l'intégration d'un système de gestion des stocks vieux de quinze ans, sans documentation API. Les trois offres reçues variaient considérablement, et la moins chère contenait une petite phrase : "Sous l'hypothèse qu'une interface REST est disponible".
L'organisation a effectué une courte étude de faisabilité d'une semaine avant de signer. Il s'est avéré qu'une telle interface n'existait pas et qu'une couche d'intermédiation était nécessaire. Cette étude a changé la donne : l'intégration est passée sous un modèle T&M plafonné, et le reste du projet est resté à prix fixe.
Ce que la courte étude a prévenu, ce n'est pas un coût supplémentaire – celui-ci serait arrivé de toute façon – mais une dispute contractuelle en plein milieu du projet sur la responsabilité de l'hypothèse non vérifiée.
Ce qui influence le prix plus que le modèle de tarification
- Maturité de la définition : Une spécification partielle renchérit tout modèle.
- Nombre de systèmes sources et leur niveau de documentation.
- Qualité des données existantes.
- Disponibilité des propriétaires de processus au sein de l'organisation : Les retards de décision sont un coût direct.
- Nombre d'unités commerciales qui doivent s'accorder.
Quatre des cinq points sont sous le contrôle de l'organisation et non du fournisseur. C'est pourquoi investir dans la préparation réduit le coût d'un projet plus que toute négociation tarifaire.
Du modèle au contrat
Après le choix du modèle, c'est la formulation qui compte : qu'est-ce qui sera considéré comme un livrable achevé, qui valide, et que se passe-t-il si l'autre partie retarde. Les clauses à inclure dans l'accord sont détaillées dans le Guide de contrat et SOW pour projet Salesforce, et la manière de rédiger une demande de sorte que les offres soient comparables est détaillée dans le Guide RFP.
Le choix du type de service à tarif initial est détaillé dans le Guide des services Salesforce, et l'évaluation du fournisseur lui-même dans le Guide pour choisir une société d'implémentation Salesforce.
Prochaine étape
Avant de demander une tarification, classez les trois principales sources d'incertitude de votre projet. Si vous pouvez les nommer précisément, vous êtes prêt pour un prix fixe pour une partie du travail. Si vous ne le pouvez pas, la première chose à obtenir est une courte étude pour les éliminer, et non une offre de prix pour l'ensemble du projet.