Ordinateur portable affichant une carte et un itinéraire, visuel généré par IAVisuel IA · Provenance

Logiciels et responsabilités · Fiche de contrôle

Vérifier les permissions d’un logiciel tourisme

Un intitulé de rôle ne suffit pas à prouver ce qu’un compte peut faire. Vérifiez les permissions accordées et les refus attendus sur des comptes de test.

Publié le . Méthode éditoriale à adapter à votre produit et à votre organisation. Source de référence : RoomRaccoon : différentes connexions utilisateur, consultée le .

Définir ce que la fiche doit permettre de vérifier

La documentation RoomRaccoon distingue notamment des connexions manager et réception. Cette fiche propose une méthode pour examiner les droits réellement configurés dans votre logiciel ; elle n’attribue pas les mêmes permissions à tous les produits.

Définissez les tâches nécessaires avec les responsables métier, puis utilisez des comptes de test autorisés. Les résultats doivent documenter les accès utiles, les actions refusées et le retrait des droits. Évitez d’exécuter des actions financières réelles pour une simple démonstration.

Huit champs à rapprocher de leurs preuves

Gardez la source et la date de vérification à côté des informations collectées. Sur téléphone, les contrôles se lisent en cartes.

Vérifier les permissions d’un logiciel tourisme : données et contrôles
ChampÀ collecterTest ou rapprochement
Compte et périmètreCompte de test, établissement et environnement.Vérifier que le compte ne peut consulter un site hors de son périmètre.
Rôle accordéRôle actuel et personne qui l’a validé.Comparer le rôle affiché aux permissions effectives.
ConsultationDossiers et données nécessaires à la tâche.Ouvrir un dossier autorisé et un dossier exclu.
ModificationActions tarifaires, capacité et documents.Tester une action permise puis une action qui doit être refusée.
ExportTypes de fichiers et données accessibles.Contrôler le contenu exporté avec chaque rôle.
Action sensibleAnnulation, remboursement ou gestion des comptes.Utiliser un cas simulé et relever validation, refus et trace.
Retrait de droitDésactivation, changement de rôle et sessions ouvertes.Vérifier quand le retrait devient effectif selon le fonctionnement du logiciel.
TraçabilitéAuteur, date, objet et résultat d’une action.Relier une action de recette à la trace disponible.

Trois erreurs qui fragilisent le dossier

  • Valider les droits seulement depuis un compte administrateur.
  • Confondre absence d’un bouton et interdiction réelle de l’action.
  • Oublier les sessions déjà ouvertes au retrait d’un droit.

Transmettre un résultat exploitable

Remettez la matrice des rôles, les actions réussies et refusées, les limites de trace et la procédure de retrait. Indiquez responsable de validation et prochaine revue lors d’un changement d’équipe ou de logiciel.

Choisir un registre de contenus, médias ou recette · Préciser les responsabilités du parcours

Questions fréquentes

Faut-il tester les refus ?

Oui. Une recette doit prouver les actions nécessaires et les actions qui doivent rester interdites.

Un compte partagé convient-il pour la preuve ?

Il ne permet pas d’attribuer simplement les actions aux personnes. Utilisez les comptes et règles d’identification prévus dans votre organisation.

Quand refaire le contrôle ?

Après changement de rôle, arrivée ou départ d’un utilisateur, nouvelle fonction sensible ou évolution de la configuration.

Approfondir ce contrôle

Toutes les fiches de contrôle · Méthode des sources

Passer à la vérification

Des fiches de contrôle pour ce sujet

Champs à collecter, tests, erreurs fréquentes et consignes de transmission pour travailler sur un dossier concret.

Toutes les fiches de contrôle →