Accès application uniquement ou accès délégué : comment synchroniser votre logiciel de réservation de salles de réunion

Pour un collaborateur, réserver une salle est simple : il ouvre son calendrier, choisit un espace disponible et le bloque. Pour les équipes informatiques, en revanche, l'architecture requise pour rendre cette expérience fluide est bien plus complexe. Elle doit concilier fiabilité, sécurité et confort d'utilisation.

Lors du déploiement d'un logiciel de réservation de salles, une question technique majeure se pose très vite : comment la plateforme doit-elle accéder aux calendriers de l'entreprise ? Dans les écosystèmes Microsoft 365 et Google Workspace, deux choix s'offrent à vous :

1. L'accès application uniquement (app-only access)
2. L'accès délégué (delegated access)

Ces deux méthodes permettent de synchroniser les réservations. Cependant, elles impliquent des modèles de sécurité, des efforts de déploiement et une expérience utilisateur très différents.

Pour les responsables informatiques en charge de plusieurs sites, de bâtiments partagés ou des architectures complexes impliquant plusieurs tenants, comprendre cette distinction est indispensable avant de choisir et de déployer une plateforme de réservation de salles.

Qu'est-ce que l'accès application uniquement ?

L'accès application uniquement signifie que le logiciel de réservation accède aux calendriers en utilisant sa propre identité d'application, et non celle d'un utilisateur connecté. Dans Microsoft Graph, on parle de rôles d'application ou autorisations d'application uniquement.

Étant donné que la synchronisation des salles est un processus d'arrière-plan (importation des salles, lecture des disponibilités, création et mise à jour des réservations, détection des conflits, prise en compte des changements), elle doit fonctionner en continu sans qu'aucun utilisateur ne soit connecté. C'est pourquoi ce type d'accès est souvent privilégié pour les déploiements à grande échelle. Il permet au système de fonctionner de manière ininterrompue sur un grand nombre de salles et de bâtiments.

Qu'est-ce que l'accès délégué ?

L'accès délégué signifie que le logiciel de réservation agit au nom d'un utilisateur. Dans Microsoft Graph, l'accès délégué s'applique lorsqu'une application fait appel à l'API pour un utilisateur connecté. En général, les équipes IT mettent cela en place via un compte de service dédié.

Cette méthode peut paraître plus sûr car l'accès est lié à un compte spécifique plutôt qu'à l'application entière. Mais elle engendre des frictions :

• L'accès doit être explicitement configuré pour le calendrier de chaque salle.
• Elle exige une gestion rigoureuse du compte de service et des jetons d'accès.
• L'ajout de nouvelles salles requiert des mises à jour manuelles.
• Toute réservation n'est modifiable qu'à sa source : une réunion créée dans Outlook se modifie dans Outlook ; une réunion créée dans le logiciel de réservation se modifie dans le logiciel de réservation.

Idéal pour les cas de haute sécurité et à portée limitée, ce mode est moins fluide pour les utilisateurs finaux.

Comparaison des modes application uniquement et délégué dans le contexte de la réservation de salles

L'accès application uniquement est généralement préférable pour un déploiement à grande échelle. L'accès délégué est préférable pour le contrôle strict. Le bon choix dépendra de votre politique de sécurité, de vos exigences de conformité et de l'expérience que vous souhaitez offrir à vos collaborateurs.

La synchronisation O365 et Google avec les logiciels de réservation de salles de réunion

• ‍La réservation de salles avec Microsoft 365 : les salles sont des boîtes aux lettres de ressources. La plateforme synchronise les données des salles (nom, capacité, équipement, horaires) et les réservations (heures, organisateur, participants, récurrence, annulations). L'accès application uniquement est souvent privilégié pour garantir une synchronisation fluide en arrière-plan.‍
• La réservation de salles avec Google : les ressources y sont réservées comme s'il s'agissait de participants, via leur adresse e-mail. Un compte de service avec délégation au niveau du domaine permet une synchronisation globale en arrière-plan (à utiliser avec précaution). Le mode délégué via OAuth est plus restrictif, mais exige que le calendrier de chaque salle soit partagé avec l'utilisateur délégué.

Un défi commun : les réunions récurrentes. Lorsque deux systèmes essaient tous deux de gérer la logique des récurrences, la synchronisation devient instable. C'est pourquoi beaucoup de plateformes choisissent de laisser Outlook ou Google Calendar rester la source de vérité absolue pour ces séries.

L'avis du CTO : les modèles d'autorisation façonnent l'expérience collaborateur

Le choix entre accès application et accès délégué est souvent présenté comme une simple décision de sécurité.

En réalité, c'est aussi un choix d'expérience produit.

Le modèle d'autorisation est déterminant sous plusieurs aspects :

• la possibilité de créer des réservations à partir de plusieurs interfaces,
• la modification d'une réservation dans Outlook et dans le logiciel de réservation de salles,
• la garantie que les réunions privées sont traitées comme telles,
• la prise en charge des réunions récurrentes,
• la rapidité avec laquelle les mises à jour apparaissent sur tous les systèmes,
• la synchronisation continue des écrans de réservation de salles, de l'application workplace et des calendriers,
• la facilité avec laquelle de nouveaux bâtiments et salles peuvent être ajoutés,

Pour les responsables informatiques, la question n'est donc pas seulement : quel modèle de permissions est le plus sécurisé ?

La vraie question est : quel modèle offre le meilleur équilibre entre sécurité, scalabilité et expérience utilisateur ?

Pour la grande majorité des déploiements en entreprise, des rôles d'application correctement définis offrent la base la plus solide pour une synchronisation fiable. L'accès délégué reste pertinent lorsqu'une organisation a besoin d'un modèle d'accès plus restreint ou plus contrôlé.

Le cas particulier de la réservation de salles dans un contexte multi-tenant : les autorisations ne suffisent plus

Jusqu'ici, nous sommes partis du principe que les utilisateurs et les salles appartenaient au même environnement Microsoft 365 ou Google Workspace. Mais, sur le terrain, la réalité est souvent bien plus complexe.

Une grande entreprise peut posséder plusieurs tenants Microsoft Entra ID pour diverses raisons :

• Acquisitions
• Structures informatiques régionales
• Filiales
• Infrastructures historiques
• Unités commerciales séparées

Il arrive que des collaborateurs s'authentifient sur le Tenant A, alors que les salles de réunion qu'ils cherchent à réserver sont hébergées sur le Tenant B.

De même, un gestionnaire d'immeubles de bureaux avec plusieurs entreprises locataires peut vouloir centraliser la gestion des ressources partagées. Chaque entreprise locataire possède son propre tenant Microsoft 365, mais toutes utilisent les mêmes salles de réunion physiques.

Ici, le problème n'est pas la portée des autorisations : c'est que les utilisateurs et les salles ne se trouvent pas dans le même tenant. L'accès application uniquement peut autoriser un logiciel au sein du tenant qui héberge la salle ; l'accès délégué peut donner à un compte de service l'accès à des salles précises. Mais aucun des deux ne permet nativement à un utilisateur externe de réserver ces salles depuis son propre compte Outlook. C'est là qu'une intégration standard Microsoft 365 atteint ses limites.

Comment Witco gère la réservation de salles en environnement multi-tenant

Witco agit comme une couche de réservation inter-tenants (cross-tenant) :

1. Les salles restent gérées dans le tenant propriétaire.
2. Witco synchronise la disponibilité et les règles de réservation.
3. Les utilisateurs d'autres tenants réservent la salle depuis l'application Witco.
4. Witco crée la réservation dans le calendrier du tenant hébergeant la salle.
5. L'utilisateur reçoit une invitation par e-mail : la réservation devient visible dans son propre agenda, même si la salle appartient à un autre tenant.

Dans ce modèle, les utilisateurs peuvent réserver depuis l'application Witco et recevoir tout de même une invitation de calendrier.

Pour une entreprise multisites, cela garantit une expérience de réservation unifiée malgré une architecture fragmentée.

Pour les gestionnaires d'immobilier commercial, cela permet de mutualiser les réservations entre différentes entreprises locataires sans les forcer à utiliser le même tenant Microsoft.

Witco devient la couche de réservation neutre entre les tenants.