Commencer par rôles et tâches
Pour choisir un PMS, un écran de permissions ne suffit pas. Demandez trois comptes fictifs : réception, ménage et direction. Examinez travail nécessaire et limites ensemble. Le but n’est pas de cacher le plus de boutons, mais de terminer les tâches sans accès superflu. C’est une grille d’achat, pas une certification de sécurité ou un audit technique complet. Utilisez uniquement des comptes et dossiers inventés, sans vrais clients, conditions privées ou identifiants.
Ce que montrent les sources
OWASP décrit le moindre privilège, limité au travail nécessaire. La documentation publique Oracle illustre l’attribution de tâches aux rôles. Les pages ont été lues le 8 octobre 2026. Elles ne prouvent ni contrôles identiques pour tous les PMS ni sécurité d’un produit. Notre matrice est éditoriale. Principes et exemples ne remplacent pas une observation autorisée. Nous n’attribuons aucune fonction précise de permission ou de session à Stayax. Une description publique n’est pas un test terminé.
Définir tâche, dossier et résultat
Pour chaque ligne, écrivez rôle, action, périmètre et résultat attendu. Une réception fictive pourrait consulter les arrivées quotidiennes ; le ménage, actualiser la préparation attribuée. Définissez séparément la revue de direction. Ces exemples n’imposent pas une organisation commune à tous les hôtels. Établissez vos besoins, y compris établissement et dossiers concernés. Ouvrir un écran ne décrit ni informations ni actions disponibles. Formulez concrètement le résultat pour que vendeur et équipe examinent la même exigence.
Montrer possibilités et limites
Demandez la démonstration de chaque compte dans les écrans normaux. Vérifiez travail nécessaire accompli et actions restreintes. Un bouton caché ne prouve pas une limite d’accès ; demandez la démonstration prise en charge pour les données concernées. Cela ne nécessite ni attaque, ni contournement d’adresse, ni test non autorisé. Un point invisible reste non vérifié et appelle clarification. Une démonstration avec un autre compte ne prouve pas le comportement du rôle étudié, même si l’interface paraît semblable.
Interroger remplacement et départ
Demandez comment des droits temporaires sont accordés, approuvés et retirés. Fin de mission et responsable de revue sont des exigences, pas des fonctions supposées. Pour un départ, demandez à montrer désactivation et état d’une session déjà ouverte. Ne supposez pas des fournisseurs identiques. Séparez comportement observé, explication orale et démonstration absente. Utilisez des comptes fictifs dans la démo autorisée, jamais un vrai compte salarié. Conservez explicitement les questions que le vendeur ne peut pas montrer.
Évaluer sans bloquer le travail
Un rôle trop étroit peut transférer toute routine à la direction. Observez accomplissement et escalade des exceptions. Ne corrigez pas le blocage en donnant l’administration à tous. Expliquez les données nécessaires à l’étape puis demandez un périmètre adapté. Ce rapprochement ne garantit ni sécurité ni productivité. Gardez visibles accès excessifs et tâches inachevées. Un refus isolé ne démontre pas un bon fonctionnement, tout comme un accès illimité ne suffit pas à valider le besoin.
Fonder la note d’achat sur l’observation
Notez rôle, comportement attendu, résultat et question ouverte. Date et contexte rendent la preuve interprétable ensuite. Ne recueillez ni données réelles ni clés d’accès. Distinguez montré, non montré et explication attendue. Ce sont des notes transparentes d’achat, pas des conclusions d’audit officiel. Ne transformez pas une promesse non vérifiée en test achevé. Appliquez la même matrice aux candidats pour comparer limites, tâches terminées et incertitudes avec des exigences équivalentes. Si version ou rôle change, revérifiez la ligne. Gardez l’ancienne note et datez la nouvelle observation : une preuve ancienne ne démontre pas un nouveau comportement.