Google Workspace
Compte de service Google ou OAuth
que choisir pour les écrans de salle
Comparez les deux méthodes d
Réponse courte : utilisez un compte de service si vous déployez de nombreuses salles, souhaitez un fonctionnement autonome sur le long terme, et disposez d'un accès administrateur Google Workspace — il s'authentifie une fois via la délégation à l'échelle du domaine et n'a jamais besoin qu'un humain se reconnecte. Utilisez OAuth si vous avez quelques salles, aucune envie de manipuler la console d'administration, ou simplement le chemin le plus rapide vers un écran fonctionnel — vous vous connectez par iPad avec un compte Google. Les deux sont sûrs ; le choix dépend de l'échelle et de qui possède la configuration.
The Room Display prend en charge deux façons de se connecter à Google Agenda, et les écrans de configuration permettent de choisir facilement l'une ou l'autre. Mais elles conviennent à des situations très différentes, et un mauvais choix signifie soit se battre avec la console d'administration pour une seule salle, soit surveiller des connexions sur cinquante. Voici comment décider.
Les deux méthodes en un paragraphe chacune
Compte de service. Un compte de service est une identité Google non humaine dotée d'une clé privée. Avec la délégation à l'échelle du domaine activée dans la console d'administration Google Workspace, il peut lire et écrire dans n'importe quel calendrier de salle de votre organisation sans qu'une personne ait à se connecter. Vous le configurez une fois, et chaque iPad l'utilise. C'est le modèle conçu pour les parcs d'appareils.
OAuth. OAuth est le flux familier « Se connecter avec Google ». Sur chaque iPad, vous vous connectez avec un compte Google ayant accès au calendrier de la salle, vous approuvez les autorisations, et c'est en ligne. Pas de console d'administration, pas de clés privées — mais l'identifiant est lié à un compte réel et à son accès.
Comparaison côte à côte
| Facteur | Compte de service | OAuth |
|---|---|---|
| Idéal pour | Nombreuses salles, déploiements pilotés par l'IT | 1 à 10 salles, configuration rapide |
| Nécessite un administrateur Workspace | Oui (délégation à l'échelle du domaine) | Non |
| Effort de configuration | Plus élevé, une seule fois | Faible, par iPad |
| Autonomie sur le long terme | Oui — aucune reconnexion | La connexion peut nécessiter un rafraîchissement occasionnel |
| Récupère toutes les salles automatiquement | Oui (Admin SDK) | Limité à ce que le compte peut voir |
| Type d'identifiant | Clé privée (JSON) | Jeton de connexion de compte |
| Révocation | Retirer la délégation / désactiver la clé | Révoquer l'accès du compte |
Quand choisir un compte de service
Optez pour la voie du compte de service si l'un de ces éléments s'applique :
- Vous déployez plus qu'une poignée de salles, en particulier sur plusieurs bâtiments.
- Vous voulez des écrans qui fonctionnent pendant des années sans que personne ne se reconnecte.
- Vous voulez que l'application découvre automatiquement chaque ressource de salle — le compte de service utilise l'API Admin SDK Directory pour énumérer toutes les ressources de calendrier du domaine, il vous suffit donc de choisir chaque salle dans une liste.
- Votre équipe IT possède le déploiement et est à l'aise avec la console d'administration Google Workspace.
Le coût ponctuel est réel : vous créez le compte de service dans Google Cloud, activez les API Calendar et Admin SDK, et autorisez son ID client avec deux autorisations dans la console d'administration. Mais vous le faites une seule fois pour tout le parc. Notre guide de réservation Google Workspace détaille les étapes de la console, et le guide des ressources de salle couvre le côté ressources.
Quand choisir OAuth
Optez pour OAuth si :
- Vous avez une salle ou un petit bureau et voulez être en ligne en cinq minutes.
- Vous n'avez pas ou ne voulez pas impliquer l'administration Workspace.
- Vous testez The Room Display avant de vous engager dans un déploiement plus large.
- Vous préférez ne stocker ni gérer aucune clé privée.
Le compromis : OAuth lie chaque écran à un compte connecté, et sa visibilité se limite aux calendriers auxquels ce compte a accès. Pour une petite installation, ce n'est pas un problème. Pour cinquante salles, cela devient cinquante connexions à maintenir — exactement la contrainte que le compte de service supprime.
Considérations de sécurité
Les deux méthodes sont solides. Quelques nuances :
- Moindre privilège. Un compte de service ne détient que les deux autorisations que vous lui accordez — l'accès au calendrier et l'accès en lecture seule à l'annuaire des ressources de salle. Ce n'est pas un super-administrateur. La délégation à l'échelle du domaine est limitée précisément à ces autorisations.
- Gestion des clés. La clé privée du compte de service est sensible. The Room Display la stocke dans le trousseau iOS (Keychain), pas dans des réglages en clair. Traitez le fichier JSON comme n'importe quel secret — remettez-le de façon sécurisée (l'application prend en charge l'import via AirDrop) et ne l'envoyez pas par e-mail.
- Architecture purement locale. Quelle que soit la méthode choisie, l'application parle directement à Google — aucun cloud tiers n'est intermédiaire pour stocker vos données de calendrier ou vos identifiants. C'est un véritable avantage en matière de confidentialité et de RGPD par rapport aux plateformes SaaS de réservation de salle. Pour en savoir plus sur le modèle de sécurité, consultez la sécurité de l'écran de salle.
- La révocation est nette. Désactivez la clé du compte de service ou retirez sa délégation pour couper tous les écrans d'un coup ; révoquez l'accès d'un compte pour couper ses écrans OAuth.
Une règle de décision simple
Si vous êtes un administrateur IT déployant des salles à l'échelle d'une organisation, utilisez un compte de service — le travail initial dans la console se rentabilise immédiatement et le parc fonctionne ensuite tout seul. Si vous êtes une petite équipe ou un office manager qui installe vous-même quelques salles, utilisez OAuth et passez à autre chose. Vous pouvez toujours commencer avec OAuth pour un pilote puis passer à un compte de service en montant en échelle — voir déployer 10 à 50 salles sans projet IT.
Questions fréquentes
Un compte de service est-il plus sûr qu'OAuth ?
Aucun des deux n'est intrinsèquement plus sûr. Un compte de service est limité exactement aux deux autorisations calendrier/annuaire que vous lui accordez ; OAuth est lié à l'accès d'un compte réel. Le point clé avec un compte de service est de protéger sa clé privée, que l'application conserve dans le trousseau.
Microsoft 365 propose-t-il aussi une option de compte de service ?
Non. Microsoft 365 utilise uniquement OAuth via l'API Microsoft Graph — il n'existe pas d'équivalent au compte de service Microsoft. Les comptes de service sont une fonctionnalité propre à Google Workspace.
Le compte de service peut-il voir des salles auxquelles personne n'est abonné ?
Oui — c'est un avantage clé. Il utilise l'API Admin SDK Directory pour lister toutes les ressources de calendrier du domaine, pas seulement les calendriers qu'un utilisateur a ajoutés, si bien que chaque salle apparaît automatiquement.
Ai-je besoin de droits d'administrateur Google Workspace pour OAuth ?
Non. OAuth se connecte par compte et ne nécessite aucune modification dans la console d'administration, ce qui le rend adapté aux petites installations. Les comptes de service nécessitent un accès administrateur pour activer la délégation à l'échelle du domaine.
Puis-je changer de méthode plus tard ?
Oui. Vous pouvez commencer avec OAuth pour un pilote puis reconfigurer les écrans pour utiliser un compte de service en montant en échelle, ou l'inverse. La salle et ses réservations ne sont pas affectées.
Guides connexes
- Guide de réservation de salle de réunion Google Workspace
- Guide des ressources de salle Google Agenda
- Gérer les ressources de salle Google Agenda à grande échelle