Gouvernance des logiciels
Droits d’accès aux logiciels tourisme : donner à chacun le périmètre utile
Une agence, un hôtel ou un voyagiste partage des dossiers entre vente, production, finance et assistance. Les rôles doivent permettre le service sans donner à tous la capacité de modifier un paiement, exporter des profils ou supprimer un dossier.
Réponse directe
Lister les actions avant de créer les rôles
Ne partez pas seulement de titres de poste. Listez les objets — client, dossier, tarif, fournisseur, paiement, remboursement, rapport — et les actions possibles : voir, créer, modifier, approuver, exporter, supprimer. Ajoutez la portée : propres dossiers, équipe, établissement, marché ou groupe. Une personne peut avoir le droit de consulter un règlement sans pouvoir le déclencher.
Le guide OWASP sur l’autorisation recommande le principe du moindre privilège et la revue régulière des droits. Traduisez-le en cas métier plutôt qu’en paramétrage abstrait.
Écrire une matrice par équipe et par objet
| Équipe | Besoin habituel | Action sensible à séparer |
|---|---|---|
| Vente | Créer et suivre les dossiers confiés | Rembourser ou exporter tout le portefeuille |
| Production | Modifier les prestations et documents | Changer un tarif contractuel global |
| Finance | Rapprocher et valider les paiements | Changer seule le bénéficiaire et approuver le virement |
| Support | Voir l’état utile pour aider le client | Consulter toutes les données personnelles sans besoin |
| Prestataire | Intervenir sur un périmètre et une durée | Garder un accès permanent après la mission |
Cette matrice est un exemple à adapter. Elle doit être testée sur les outils réels, y compris leurs API et exports, car masquer un bouton dans l’interface ne protège pas nécessairement l’action sous-jacente.
Gérer l’arrivée, le changement et le départ
À l’arrivée, attribuez un rôle justifié et un responsable d’approbation. Lors d’un changement de fonction, retirez les anciens droits avant d’accumuler les nouveaux. Au départ, révoquez les sessions et accès applicatifs, puis réattribuez les dossiers ouverts et les tâches planifiées. Les comptes de service et connexions entre systèmes doivent avoir un propriétaire et une finalité documentée.
Évitez les droits temporaires qui deviennent permanents. Conservez une date de fin et une trace de l’approbation pour les interventions exceptionnelles.
Tester les limites avec des scénarios concrets
- Un conseiller ouvre un dossier d’une autre agence : vérifier la séparation attendue.
- Un agent de support consulte une réservation sans voir les informations de paiement non nécessaires.
- Un comptable prépare un remboursement sans pouvoir approuver seul une modification de bénéficiaire.
- Un prestataire tente un export hors de son périmètre après la date de fin.
- Un collaborateur change d’équipe : vérifier le retrait effectif des droits antérieurs.
Auditer sans créer un journal inexploitable
Conservez les événements utiles : qui a modifié une condition, lancé un remboursement, exporté un ensemble de dossiers ou accordé un droit. Protégez l’accès à ces journaux et définissez leur durée de conservation selon les besoins et obligations applicables. Une revue périodique doit aboutir à des retraits et corrections documentés, pas seulement à un tableau signé.
Une matrice de rôles versionnée, reliée à des tests d’accès et à une liste des propriétaires des comptes techniques.
Construire une recette des permissions négatives
Choisissez trois tâches sensibles : exporter des clients, changer un tarif et rembourser une réservation. Faites-les tenter avec un compte réception puis avec un compte manager configurés pour votre établissement. Documentez les refus attendus et les traces disponibles. Vérifiez également un ancien utilisateur désactivé et un changement de rôle : le retrait d’un droit doit être effectif sur les sessions et accès concernés, selon le fonctionnement documenté du logiciel.
Hospitalité : distribution, droits du PMS, tarification et tables : fonctions documentées, limites et questions à poser à quatre acteurs du secteur.
Contrôler les fichiers et leurs liens de partage
Les droits de consultation doivent être vérifiés sur les pièces et les exports, pas seulement sur les menus du logiciel. Un lien transmis peut donner accès à un document en dehors de l’interface habituelle. Testez sa validité, le compte destinataire et le refus d’accès ; documentez le circuit de renouvellement nécessaire.
Lire le dossier Documents voyageurs : collecte, versions et partage des fichiers, avec sa fiche de contrôle et ses repères de travail associés.
Examiner le cycle de la délégation technique
Lorsqu’une application agit au nom d’un compte partenaire, contrôlez identité du compte, environnement et opérations autorisées. Rejouez une connexion de deux établissements et une expiration pendant traitement dans l’environnement de test. La reprise doit retrouver les objets déjà traités et les références restantes. Les traces de recette ne doivent contenir ni jeton ni secret ; elles documentent la portée constatée et le résultat. Une autorisation technique ne remplace pas le contrat de distribution.
OAuth dans la travel tech : déléguer un accès et organiser sa fin
Vérifier la récupération et la fin de l’accès fournisseur
Complétez la matrice des rôles par le parcours des comptes fournisseurs : MFA, récupération et départ. Un rôle correctement attribué ne résout pas le téléphone perdu, la session encore ouverte ou les dossiers confiés à une personne qui quitte l’équipe.
Le registre de revue des accès garde les procédures, résultats et retraits attendus. Les mots de passe et codes restent hors du document. La fiche de contrôle distingue les éléments documentés des essais effectivement observés.
Un accès conservé après un changement de mission
Cas fictif proposé pour préparer vos contrôles ; aucun résultat fournisseur n’est présumé.
Dans une agence fictive, une personne change d’équipe. Son profil conserve une fonction sensible qu’elle n’utilise plus, tandis que son nouveau responsable ignore qui peut la retirer.
- Action à préparer
- Comparer la mission actuelle, les droits nécessaires et les accès observés. Identifier le propriétaire de l’outil et préparer une modification contrôlée avec un compte de test lorsque c’est possible.
- Pièces à rapprocher
- Conserver la demande approuvée, la liste des droits avant et après et le résultat du contrôle. Éviter de copier des secrets ou des données clients dans le registre.
- Décision à documenter
- Clore la revue après vérification des droits attendus et des fonctions retirées ; garder un suivi explicite pour les outils dont l’accès n’a pas encore été vérifié.
Accès aux outils : validation, retrait et revue des droits
Un compte peut rester actif alors que sa mission a changé. La fiche CNIL donne des repères précis pour organiser la revue des accès aux données personnelles.
| Point documenté | Ce que la source précise | Conséquence pour votre contrôle |
|---|---|---|
| Séparer les responsabilités | La CNIL recommande des profils limitant les données accessibles à celles nécessaires à la mission, avec séparation des tâches. | Décrivez les opérations attendues pour le conseil, le support et l’administration ; un intitulé de poste ne suffit pas à définir les droits. |
| Faire valider l’accès | Chaque demande d’habilitation doit être validée par un responsable. | Conservez la demande et son approbation avant d’attribuer un droit sensible, en identifiant l’outil et le périmètre concernés. |
| Retirer sans attendre la revue | La fiche prévoit le retrait des permissions dès la fin de l’habilitation, notamment au changement de mission ou à la fin du contrat. | Une autorisation donnée pour un remplacement doit aussi avoir une fin vérifiable. |
| Revoir au moins chaque année | La CNIL recommande une revue régulière, a minima annuelle, avec implication des métiers pour vérifier la légitimité des droits. | Comparez comptes inutilisés, missions actuelles et droits observés ; la date du dernier examen doit être retrouvable. |
Deux accès à recontrôler
Exemples fictifs pour préparer une revue, sans modification de compte.
Un remplacement prend fin avant la revue annuelle
Une conseillère a reçu un droit de remboursement pendant deux semaines.
Motif : remplacement
Fin de mission : atteinte
Prochaine revue générale : dans huit moisLecture du cas. Traitez la fin du droit temporaire maintenant. Conservez la preuve du retrait et du contrôle, sans attendre la prochaine revue générale.
Le départ est traité dans le PMS mais pas dans le portail fournisseur
Une personne utilisait plusieurs outils avec des comptes distincts.
Compte PMS : désactivé
Portail fournisseur : encore actif
Mission : terminéeLecture du cas. La désactivation du PMS ne prouve pas le retrait dans l’autre outil. Rapprochez chaque compte de son responsable et de la procédure de clôture attendue.
Recommandations de sécurité de la CNIL consultées le 23 octobre 2026, appliquées ici aux outils traitant des données personnelles. La procédure concrète dépend des comptes et des responsabilités de l’organisation.
CNIL — Sécurité : gérer les habilitations · publiée le 13/03/2024 · consultée le . Les contrôles proposés sont une lecture éditoriale de cette référence.
Cloudbeds PMS : vérifier les privilèges derrière le nom du rôle
Deux comptes appelés « réception » peuvent avoir des droits différents. La documentation Cloudbeds permet de préparer des essais sur les privilèges réellement configurés.
| Point documenté | Ce que la source précise | Conséquence pour votre contrôle |
|---|---|---|
| Rôle avant utilisateur | Cloudbeds indique de définir un rôle avant d’ajouter un utilisateur, avec des privilèges personnalisables par fonction et par action. | Inventoriez les actions nécessaires au poste ; évitez de prendre le rôle Administrator comme solution par défaut. |
| Gestion des rôles | L’accès au paramétrage dépend du privilège Manage User Roles and privileges, que le Property Owner peut accorder. | Une page de réglages absente peut venir du droit du compte, sans démontrer que la fonction est indisponible dans le PMS. |
| Exemple du ménage | La fiche associe notamment au rôle Housekeeper le changement d’état propre/sale et la création de blocages ou de chambres hors service. | Vérifiez le rôle réellement configuré dans l’établissement ; les exemples de la documentation ne constituent pas une liste de droits imposée. |
| Paiement au-delà du solde | Add Payments Larger Than Reservation Total autorise un paiement supérieur au solde restant ; sans ce privilège, l’ajout est limité au montant restant de la réservation. | Testez un dépassement avec un compte de recette autorisé, sans réaliser un encaissement réel pour vérifier un simple droit. |
Deux essais de droits à préparer
Scénarios fictifs pour un environnement de recette, sans encaissement ni changement de droits réels.
Le compte ne voit pas l’écran de gestion des rôles
La réception cherche à comparer ses privilèges avec ceux d’un autre compte.
Écran Roles : absent
Droit de gestion des rôles : non confirméLecture du cas. Faites vérifier les permissions par le responsable habilité. L’absence de l’écran ne permet pas de conclure que le PMS ne sait pas gérer des rôles.
Un ajout de paiement dépasse le solde du dossier
Le jeu de recette prévoit un solde fictif de 80 € et un ajout de 100 €.
Solde fictif : 80 EUR
Ajout demandé : 100 EUR
Privilège de dépassement : désactivéLecture du cas. Selon la règle décrite, ce compte ne doit pas pouvoir dépasser le solde restant. Conservez le résultat de l’essai et faites examiner tout écart ; aucun paiement réel n’est nécessaire ici.
Fonctions de Cloudbeds PMS décrites dans une aide mise à jour le 13 août 2026, consultée le 23 octobre. Ces rôles ne prouvent pas les permissions d’une API ni celles d’un autre produit Cloudbeds.
Cloudbeds — Add, edit or delete roles · mise à jour par la source le 13/08/2026 · consultée le . Les contrôles proposés sont une lecture éditoriale de cette référence.
Apaleo : le type de client détermine la lecture des accès
Le mot « scope » ne décrit pas tous les clients Apaleo de la même façon. Identifiez le modèle de l’application avant de comparer demande, consentement et jeton.
| Point documenté | Ce que la source précise | Conséquence pour votre contrôle |
|---|---|---|
| Choix à l’enregistrement | Le type d’accès du client, à scopes ou à permissions fines, ne peut plus être changé après la création de l’application. | Consignez ce choix dans le dossier technique ; ne préparez pas une migration comme un simple changement de paramètre. |
| Requête d’autorisation | Un client à permissions fines transmet les scopes OpenID Connect ; les scopes d’API ajoutés dans scope sont ignorés. | Vérifiez les permissions configurées pour l’application plutôt que d’ajouter des mots dans l’URL d’autorisation. |
| Réponse de jeton | Pour ce client, identity:permissions est un marqueur dans la réponse, distinct d’une liste de scopes d’API accordés. | Ne déduisez pas les opérations autorisées de ce seul marqueur ; relisez les exigences de l’opération. |
| Application intégrée à l’interface | Les appels d’une UI integration utilisent le jeton de l’installateur, pas celui de la personne qui travaille actuellement dans l’interface. | Conservez le compte installateur et son périmètre dans la recette ; ne supposez pas que changer d’utilisateur à l’écran change l’identité d’appel. |
Identifier le bon contexte d’autorisation
Quatre éléments à relever dans une recette Apaleo, sans créer de compte ni modifier de droits.
- Application
Retrouver son type d’accès enregistré : scopes ou permissions fines.
- Opération
Lire dans la documentation de cette opération le droit qu’elle exige.
- Établissement
Identifier la propriété effectivement visée et l’accès accordé à l’application.
- Identité d’appel
Pour une application intégrée, retrouver l’installateur plutôt que déduire le compte du seul écran affiché.
Deux interprétations d’accès à corriger
Scénarios fictifs de préparation d’intégration.
Une permission est ajoutée uniquement dans scope
L’application fictive a été créée comme client à permissions fines.
Type : permissions fines
Modification effectuée : ajout d’un scope API dans l’URL
Permissions configurées : inchangéesLecture du cas. L’ajout dans l’URL ne constitue pas l’octroi attendu. Relisez le paramétrage de l’application et les exigences de l’opération, sans conclure qu’un consentement affiché a ouvert ce droit.
Le collaborateur change à l’écran dans une UI integration
Une autre personne utilise l’application intégrée après son installation.
Installateur : compte A
Utilisateur présent : compte B
Identité d’appel à vérifier : installateurLecture du cas. La documentation rattache les appels de ce type d’intégration au jeton de l’installateur. Conservez ce contexte pour expliquer les résultats de la recette et les changements d’accès.
Modèles Apaleo décrits dans la documentation consultée le 23 octobre 2026. Les clients existants à scopes continuent de fonctionner ; les propriétés, permissions et rôles du projet doivent être vérifiés.
Apaleo — Scopes and permissions · consultée le . Les contrôles proposés sont une lecture éditoriale de cette référence.
Sources et périmètre des faits documentés
La date de consultation figure avec chaque référence. Les méthodes d’essai et recommandations de ce guide sont éditoriales ; les conditions d’accès et d’usage se vérifient dans la documentation actuelle.
- D-EDGE : Distribution et connectivité hôtelières : D-EDGE distingue une famille CRS avec channel manager et booking engine, un Connectivity Hub et des outils de Data Intelligence. (consultée le )
- RoomRaccoon : Gestion hôtelière avec droits utilisateurs : La documentation RoomRaccoon distingue notamment les droits du gestionnaire et ceux de la réception, avec des zones protégées selon le rôle. (consultée le )
- Zenchef : Réservation et opérations de restaurant : Zenchef présente des fonctions de réservation, gestion des tables, liste d’attente, prépaiement et paiement à table. (consultée le )
- Duetto : Pilotage des prix hôteliers : Duetto présente GameChanger pour le pricing et la distribution, et distingue cette fonction des outils de prévision et reporting de sa suite. (consultée le )
- CNIL — Sécurité : gérer les habilitations : Recommandations de sécurité de la CNIL consultées le 23 octobre 2026, appliquées ici aux outils traitant des données personnelles. La procédure concrète dépend des comptes et des responsabilités de l’organisation. (consultée le )
- Cloudbeds — Add, edit or delete roles : Fonctions de Cloudbeds PMS décrites dans une aide mise à jour le 13 août 2026, consultée le 23 octobre. Ces rôles ne prouvent pas les permissions d’une API ni celles d’un autre produit Cloudbeds. (consultée le )
- Apaleo — Scopes and permissions : Modèles Apaleo décrits dans la documentation consultée le 23 octobre 2026. Les clients existants à scopes continuent de fonctionner ; les propriétés, permissions et rôles du projet doivent être vérifiés. (consultée le )
Questions fréquentes
Questions utiles avant de décider
Un compte administrateur partagé est-il pratique ?
Il rend difficile l’attribution d’une action à une personne et multiplie les pouvoirs inutiles. Préférez des comptes individuels, des rôles explicites et une procédure pour les interventions exceptionnelles.
Comment traiter un prestataire externe ?
Définissez les dossiers et fonctions nécessaires, une durée, un responsable interne et une revue à la fin de la mission. Testez que l’accès n’expose pas les autres clients ou marchés.
À quelle fréquence revoir les droits ?
Revoyez-les lors d’un changement de poste, d’un départ, d’une nouvelle intégration et périodiquement selon le risque. Les droits d’export et d’administration méritent une attention particulière.
Peut-on attendre la revue annuelle pour retirer un accès temporaire ?
Non. La fiche CNIL prévoit de retirer les permissions dès que la personne n’est plus habilitée. La revue annuelle est un contrôle complémentaire ; elle ne prolonge pas un remplacement ou une mission terminée.
