Idée principale
« Je veux savoir qui se connecte à l'application. » Lue comme une demande fonctionnelle, la phrase est mince : un journal d'accès, rien de spectaculaire.
Elle porte souvent tout autre chose. Derrière peuvent se trouver un audit ISO, une politique de sécurité, une équipe cybersécurité, un SIEM central, une procédure d'investigation — ou simplement une culture d'entreprise dans laquelle chaque accès doit être traçable.
La même lecture vaut pour les demandes voisines : utiliser l'IAM du client, ses clés de chiffrement, son contrat de fournisseur de modèle, sa passerelle d'email. Elles paraissent hétéroclites et racontent la même chose.
Pourquoi c'est important
Traitées comme des exigences techniques, ces demandes se jugent au coût de développement, et on conclut souvent qu'elles ne créent aucune valeur métier. Ce jugement est juste et hors sujet.
Lues comme l'expression d'une gouvernance, elles se jugent autrement : non pas « qu'est-ce que ça apporte au produit ? » mais « qu'est-ce que ça permet à cette organisation d'accepter ? ».
Nuances et limites
Toutes ne relèvent pas de la culture : certaines sont de vraies obligations réglementaires, d'autres de simples préférences d'équipe. Le travail consiste précisément à ne pas les confondre.
Et la culture d'un grand compte n'est pas homogène : ce que demande la sécurité et ce que demande la direction métier peuvent s'opposer.
Questions ouvertes
- Comment distinguer, à la lecture d'une demande, l'obligation réglementaire de l'habitude organisationnelle ?