Une plateforme d'expérience occupant ne remplace aucun de vos systèmes : elle s’appuie dessus. C'est ce qui rend le sujet simple sur le principe, et exigeant sur les interfaces.
Le malentendu le plus fréquent en début de projet consiste à voir une plateforme d'expérience occupant comme un nouveau système à déployer, en concurrence avec le contrôle d'accès ou la GMAO en place. C'est l'inverse.
Elle agrège : elle lit et écrit dans des systèmes qui restent maîtres de leurs données, et présente à l'occupant une interface unique. Le contrôle d'accès reste le référentiel des droits. La GMAO reste le référentiel des interventions. Le SIRH reste le référentiel des collaborateurs. La plateforme ne remplace pas ces systèmes, elle les orchestre.
La conséquence pratique : le projet ne se juge pas sur les fonctionnalités de la plateforme, mais sur la qualité de ses interfaces avec ce que vous avez déjà.
C'est le point de départ. Sans authentification fédérée, vous créez un référentiel d'identités parallèle, qui dérivera. La plateforme doit s'authentifier avec votre fournisseur d'identité, hériter des groupes, et surtout répercuter les départs automatiquement. Un collaborateur désactivé dans l'annuaire doit perdre ses accès sans intervention.
L'interface porte sur l'émission et la révocation d'identifiants, la lecture des droits par zone, et la synchronisation des populations temporaires. Le point d'attention est la latence : une révocation doit être effective en temps réel, pas au prochain cycle de synchronisation. Vérifiez aussi que l'interface est bidirectionnelle — beaucoup de connecteurs lisent sans savoir écrire.
Il alimente les arrivées, les départs et les changements d'affectation des utilisateurs. C'est ce qui permet à un accès d'exister avant le premier jour, et de disparaître le jour du départ. Sans cette liaison, le processus reste manuel et les écarts s'accumulent.
Ces deux mots recouvrent des besoins différents qu'on confond souvent. Multi-sites : une même organisation, plusieurs immeubles, avec des règles et des services qui diffèrent d'un site à l'autre. Multi-locataires : plusieurs organisations dans le même immeuble, qui doivent partager certains services — accueil, restauration, parkings — sans jamais voir les données les unes des autres.
Le second cas est le plus exigeant, et c'est celui des foncières. Le cloisonnement doit être structurel, pas un filtre applicatif : chaque locataire administre ses propres droits, et l'exploitant garde une vue sur les espaces communs sans accéder aux données des occupants.
Avant toute démonstration : « quels connecteurs existent déjà pour mes systèmes, en production, chez d'autres clients ? » Un connecteur annoncé dans une roadmap n’est pas un connecteur disponible. La différence entre ce qui existe aujourd’hui et ce qui est prévu demain peut transformer un déploiement de trois mois en un projet de dix-huit mois.
Trente minutes, à partir de votre contexte réel. Pas de présentation générique.