Idée principale

Quand le client paie lui-même son Azure SQL, le raisonnement spontané est qu'il devrait payer l'abonnement moins cher : une ligne de coût vient de sortir du périmètre de l'éditeur.

Elle en est sortie, et une autre s'est ouverte. Supporter des bases installées chez les clients oblige à gérer des versions différentes, des contraintes réseau différentes, des mécanismes de réplication, des sauvegardes, des instantanés, des restaurations, des droits, de la supervision, des configurations particulières — et surtout beaucoup plus de scénarios à comprendre quand quelque chose ne fonctionne plus.

Le coût d'infrastructure baisse, le coût de service monte. Ce ne sont pas les mêmes lignes, et rien ne garantit que la seconde soit plus petite que la première.

Pourquoi c'est important

Le raisonnement spontané conduit à consentir une remise au moment même où le coût réel augmente. L'erreur est structurelle : on compare ce qui est facile à chiffrer — le prix d'une ressource — à ce qui ne l'est pas — la variété à supporter.

Cela donne aussi une règle pour les engagements associés. Garantir la restauration d'une base hébergée chez le client demande de la technologie, des tests, de la supervision, des procédures de reprise : c'est une responsabilité supplémentaire, donc une ligne à facturer. Si le client préfère la garder, la rétention, la qualité des sauvegardes et les conséquences d'une sauvegarde inutilisable doivent lui être explicitement attribuées.

Nuances et limites

L'augmentation dépend de la variété réellement acceptée. Une seule version supportée, une seule configuration, et le surcoût reste modeste.

Et une part du coût est d'apprentissage : les premiers déploiements coûtent plus que les suivants, ce qui fausse toute extrapolation faite trop tôt.

Questions ouvertes

• Comment chiffrer un coût de service à l'avance, quand il dépend de la variété qu'on aura acceptée ?