Idée principale

La base de paie vit désormais dans l'environnement Azure du client. Un matin, l'application ne répond plus. Est-ce le moteur de l'éditeur, la base SQL Server du client, une règle réseau modifiée la veille, un certificat, une configuration d'IAM, une saturation de connexions, un quota, une latence ?

Répondre « la base est chez le client, ce n'est pas notre problème » ne fonctionne pas. Pour l'utilisateur qui ne peut pas faire sa paie, c'est le service de l'éditeur qui est en panne.

Le contrat a déplacé une responsabilité ; la perception, elle, n'a pas bougé.

Pourquoi c'est important

Cela impose une obligation qui ne découle pas du contrat mais de la situation : superviser suffisamment la ressource externalisée et sa connectivité pour comprendre d'où vient un incident. Non pas administrer l'infrastructure du client, mais disposer des signaux — disponibilité, latence, erreurs de connexion, saturation, état de santé.

C'est un coût que l'arrangement ne fait pas apparaître au moment où on le négocie, et qui ne disparaît jamais ensuite.

Nuances et limites

La supervision ne rend pas l'éditeur capable d'agir : voir la panne et pouvoir la réparer sont deux choses.

Et l'obligation a une limite : au-delà d'un certain point, superviser tout l'environnement du client revient à l'exploiter, ce que le partage était censé éviter.

Questions ouvertes

• Quel niveau de supervision suffit à diagnostiquer sans empiéter sur l'exploitation du client ?