Idée principale

Accorder à un grand compte que la base de son logiciel de paie vive dans son environnement Azure ouvre une question qui n'a pas été posée : ce client contrôle-t-il aussi les évolutions du schéma, donc le rythme des mises en production ?

Les deux ne sont pas liées, et les confondre coûte cher. Un client qui demande à conserver ses données chez lui ne demande pas à gouverner les migrations de l'éditeur. Il veut la maîtrise de l'emplacement, pas celle de l'évolution.

D'où une frontière qui se formule en une phrase : le client contrôle où vivent ses données, l'éditeur contrôle comment le produit évolue.

Pourquoi c'est important

Cette frontière est ce qui rend l'arrangement viable. Sans elle, accorder l'hébergement revient à céder le calendrier de livraison, et l'éditeur perd ce qui fait la nature même d'un service en ligne.

Elle donne aussi un critère d'acceptation net : héberger chez le client n'est compatible avec ce modèle que si les migrations restent automatisées et pilotées par l'éditeur, dans un cadre de sécurité accepté.

Nuances et limites

La frontière est claire à énoncer et discutée en pratique : un client dont la politique interdit toute modification non validée ne peut pas l'accepter telle quelle.

Et elle ne règle pas tout : l'emplacement des données emporte des conséquences sur la supervision et les responsabilités, qui restent à trancher séparément.

Questions ouvertes

• Que faire d'un client dont la gouvernance interdit précisément les migrations automatisées ?