Angle
Une exigence technique de grand compte — la base de données dans son propre abonnement cloud, sa passerelle d'email, son fournisseur de modèle de langage — se négocie sur son motif, jamais sur sa faisabilité. Le motif dit ce qu'il suffit d'accorder ; répondre à la demande telle qu'elle est formulée revient à accorder le maximum sans savoir pourquoi, et ce maximum se paie ensuite en divergence du produit, sur des lignes qu'aucun tableau de coûts ne montre.
Synthèse
Un grand groupe évalue votre logiciel de paie. L'affaire avance. Puis une phrase tombe : « la base de données doit être dans notre abonnement Azure ».
La discussion qui suit se tient presque toujours au même endroit : est-ce faisable ? Oui, techniquement. Combien de temps ? Deux mois. On chiffre, on s'engage, on passe à la suite.
Cette discussion a sauté la seule question qui donne la main : pourquoi cette demande. Un audit ISO à passer, une politique de sécurité qui interdit les données hors de son locataire, une équipe cybersécurité qui veut ses journaux dans son propre outil de supervision. Ce ne sont pas des jugements sur votre compétence — personne ne pense que le client hébergera mieux que vous. C'est du contrôle : pouvoir répondre de ses données devant son auditeur.
Le motif compte parce qu'il fixe le dosage. Si le besoin est de prouver que les données ne sortent pas de l'Union européenne, une région d'hébergement et un engagement écrit y répondent. S'il est de tenir la clé de chiffrement, une clé gérée par le client y répond. Aucun de ces deux besoins n'exige la base dans son abonnement. Répondre à la demande telle qu'elle est formulée, c'est accorder le maximum pour un motif qu'on n'a pas identifié.
Car ce qu'on accorde a un prix, et il se paie sur des lignes que personne ne tient. La base vit chez le client : chaque mise en production qui touche la structure de données devient une procédure à envoyer, une validation à attendre, une fenêtre de maintenance à réserver. Le premier client la passe mardi, le troisième reporte au mois suivant, et trois mois plus tard vos correctifs se testent contre quatre états de base différents. Ce qui se perd là est exactement ce qui faisait l'intérêt du modèle : un produit unique qu'on fait avancer pour tout le monde en même temps. La ligne d'infrastructure, elle, a baissé — et c'est celle-là que le commercial voit quand il propose une remise.
Il y a un cas où le calcul change de sens : une brique qui ne différencie rien peut à elle seule empêcher la vente. Le SSO ne distingue aucun logiciel de paie de ses concurrents, et son absence suffit à vous éliminer. On la construit donc, non pour ce qu'elle apporte, mais pour ce que son absence coûte. La question n'est jamais « est-ce que ça crée de la valeur » — elle est « qu'est-ce que ça ouvre, et sur quelle ligne ça se paie ».
D'où la conclusion, qui n'est pas technique. Ces exigences ne sont pas des cas particuliers à traiter au coup par coup : c'est la culture de gouvernance d'un segment de marché. Décider d'y vendre, c'est accepter cette contrainte comme une donnée du marché, la chiffrer une fois pour toutes, et négocier chaque demande sur son motif plutôt que sur sa faisabilité.
Tensions / contradictions
Deux notes ne disent pas la même chose sur ce qu'on peut céder. L'une pose que remplacer un fournisseur sans changer la valeur rend le service substituable — donc qu'il faut résister ; l'autre que la substitution reste coûteuse dès que la brique porte l'état durable — donc que le risque est plus faible qu'il n'y paraît. La frontière entre les deux n'est pas tracée.
Tension non résolue également : la thèse demande de négocier sur le motif, mais rien ne garantit que l'interlocuteur le connaisse. Une exigence relayée par un acheteur peut avoir perdu sa raison en chemin.
Questions
- Comment faire remonter le motif quand l'interlocuteur ne fait que transmettre une règle interne ?
- Jusqu'à quel nombre d'états de base différents une équipe tient-elle avant que la qualification devienne impraticable ?