Contrôle d’accès en tant que service (ACaaS) : ce que c’est et pourquoi c’est important
Acheter du contrôle d’accès signifiait autrefois lancer un projet d’investissement : un serveur, des armoires de...

Le contrôle d’accès mobile est un système dans lequel l’identifiant permettant d’ouvrir une porte est conservé sur un smartphone plutôt que sur une carte, un badge ou une clé mécanique. Cet identifiant est attribué et retiré de façon centralisée depuis un logiciel. Une personne peut ainsi recevoir l’accès à certaines portes pendant une période précise, sans remise d’objet physique. Cet identifiant est également appelé identifiant mobile ou clé numérique.
Un système de contrôle d’accès mobile comporte trois éléments, qu’il convient de distinguer avant d’aller plus loin.
L’identifiant est une donnée. Il prouve l’identité de son détenteur et définit ce qu’il est autorisé à ouvrir. Sur une carte, il réside dans une puce ; dans un système de contrôle d’accès mobile, il se trouve dans une application, un pass de portefeuille numérique ou un code sur le téléphone, voire sur une tablette ou une montre connectée lorsque la plateforme le permet.
Le lecteur ou la serrure est le dispositif installé sur la porte qui reçoit l’identifiant. Il peut s’agir d’un lecteur câblé placé à côté de la porte ou d’une serrure électronique sans fil alimentée par batterie intégrant le lecteur, sous la forme d’une poignée, d’un cylindre ou d’un autre équipement adapté à la porte.
La plateforme est le logiciel dans lequel un administrateur définit qui peut ouvrir quoi et où les événements d’accès sont enregistrés. Elle est généralement accessible depuis un navigateur.
Chacun de ces trois éléments peut être conçu de plusieurs façons, et leur combinaison détermine le comportement du système en situation dégradée.
Un système de contrôle d’accès mobile effectue quatre opérations successives : il place un identifiant sur un téléphone, le téléphone le présente à une porte, un composant décide d’ouvrir ou non, puis l’événement est enregistré. Chacune de ces étapes peut être mise en œuvre de plusieurs façons ; ce sont ces choix qui différencient les systèmes.
L’identifiant est transmis par invitation, selon plusieurs méthodes. Pour les personnes qui utilisent régulièrement un bâtiment, il s’agit généralement d’une application : l’utilisateur l’installe, se connecte avec son compte professionnel existant et l’identifiant est provisionné sur cet appareil. Pour les utilisateurs occasionnels, il peut s’agir d’un code QR, ajouté au portefeuille numérique du téléphone ou envoyé sous forme de lien par email ou SMS, ce qui évite de télécharger une application. Un code PIN constitue une autre option lorsqu’une porte dispose d’un clavier ou d’un interphone ; il est communiqué à la personne sous forme de numéro plutôt que stocké sur le téléphone.
Certains systèmes limitent l’utilisateur à un seul appareil actif. Il s’agit d’une restriction volontaire plutôt que technique, car un identifiant présent simultanément sur plusieurs téléphones peut être prêté. Le passage à un nouveau téléphone s’effectue généralement en libre-service : l’utilisateur se connecte sur le nouvel appareil et l’identifiant y est réémis, ce qui le retire de l’ancien.
Sur la plateforme ATLAS, un collaborateur ajoute l’accès à son propre téléphone à l’aide de son compte Microsoft, de l’application et d’un code QR, en moins d’une minute.
Du point de vue de l’utilisateur, l’interaction est généralement très simple. Dans un premier mode, l’application fonctionne en arrière-plan : la porte s’ouvre lorsque la personne présente son téléphone, sans rien ouvrir ni sélectionner. Dans un second mode, l’utilisateur active d’abord l’écran du téléphone, puis l’application répond sans être ouverte. Les deux modes sont couramment utilisés, mais ils n’offrent pas le même niveau de sécurité. Lorsque l’application répond en arrière-plan, le code PIN ou la biométrie du téléphone ne sont pas vérifiés à la porte ; un téléphone tenu par une autre personne peut donc encore l’ouvrir. Ce point doit être pris en compte lors du choix du mode.
En arrière-plan, deux technologies à courte portée transmettent l’identifiant du téléphone à la porte, et les systèmes diffèrent selon celle qu’ils utilisent.
Le Bluetooth Low Energy (BLE) fonctionne à distance plutôt que par contact, ce qui permet l’ouverture mains libres. Les fournisseurs annoncent des portées très variables, de quelques centimètres à quelques mètres, car celle-ci est configurable ; il convient donc de demander le réglage précis de chaque lecteur. Le système doit également être correctement calibré : une porte qui s’ouvre lorsqu’une personne passe de l’autre côté d’un mur constitue un problème plutôt qu’un avantage, et un mauvais paramétrage est une cause reconnue d’ouvertures accidentelles.
Le NFC fonctionne uniquement au contact ou à quelques centimètres : l’utilisateur approche donc son téléphone du lecteur. Il est rapide, difficile à déclencher par accident et se comporte comme une carte sans contact. Il consomme aussi très peu d’énergie, tant du côté du téléphone que de la serrure, ce qui compte dans un bâtiment équipé de nombreuses serrures alimentées par batterie.
Certains systèmes prennent en charge plusieurs de ces technologies, afin que l’identifiant puisse toujours être présenté si l’une des méthodes est indisponible.
ATLAS utilise à la fois le BLE et le NFC pour les identifiants. Le NFC intervient aussi lors de l’installation : une carte NFC sert à réveiller une nouvelle serrure avant son ajout au système.
Un identifiant mobile est protégé par deux mécanismes que le bâtiment n’a pas à fournir.
Le premier est le téléphone lui-même. Lorsque l’utilisateur active l’écran avant de présenter le téléphone, l’identifiant ne peut pas être utilisé tant qu’il n’a pas validé le code PIN, l’empreinte digitale ou la reconnaissance faciale de l’appareil. Deux éléments sont donc vérifiés au lieu d’un : le téléphone et la personne qui le tient. Le bâtiment n’a pas à financer cette seconde vérification, puisque le téléphone l’effectue déjà. C’est pourquoi un téléphone trouvé est bien moins utile à un inconnu qu’une carte trouvée. Lorsque l’application répond en arrière-plan, cette vérification n’a pas lieu à la porte. Pour les zones à haute sécurité, comme les salles serveurs ou les laboratoires, il est généralement recommandé d’exiger une seconde vérification, par exemple un code PIN, afin qu’un téléphone volé ou déverrouillé ne suffise pas à entrer.
Le second mécanisme est le chiffrement. L’identifiant est chiffré lorsqu’il est stocké et pendant sa transmission au lecteur, ce qui rend sa copie impraticable. À l’inverse, une ancienne carte non chiffrée peut souvent être copiée avec du matériel peu coûteux.
Il s’agit du choix de conception le plus déterminant de tout le système, et il reste invisible jusqu’à ce qu’une panne survienne.
Un contrôleur installé dans le bâtiment décide. Les autorisations résident sur un contrôleur local qui répond au lecteur. Les portes continuent de fonctionner si internet est indisponible. Le logiciel de gestion est souvent hébergé dans le cloud, mais il administre le système au lieu de décider de chaque entrée.
Le cloud décide de chaque entrée. Le lecteur envoie la demande à la plateforme et attend sa réponse avant de déverrouiller la porte. Certains systèmes peuvent acheminer cette demande via les données mobiles du téléphone plutôt que par la connexion internet du bâtiment ; une panne sur site n’empêche donc pas nécessairement l’ouverture.
L’identifiant contient les droits. Les droits d’accès sont transportés par l’identifiant lui-même ; la serrure les lit et prend sa décision sans connexion, puis les événements sont collectés ultérieurement. Ce modèle est à la base du standard OSS Offline, un standard multifournisseur permettant d’inscrire les droits d’accès sur une carte (« data on card »). ATLAS le suit par l’intermédiaire de l’application mobile, ainsi qu’avec des cartes lorsqu’un second type d’identifiant est nécessaire.

| Identifiant mobile | Carte d’accès | Badge | Code QR | Code PIN | Biométrie | |
|---|---|---|---|---|---|---|
| Mode d’attribution | Envoyé par invitation et activé par l’utilisateur sur son propre téléphone | Encodé et remis en main propre | Encodé et remis en main propre | Envoyé sous forme de lien ou d’image, puis enregistré dans le portefeuille numérique du téléphone | Communiqué à la personne ou envoyé dans un message | Enregistré une seule fois en personne, lors de l’inscription |
| Mode de révocation | Retiré de façon centralisée ; cesse de fonctionner sur l’appareil dès qu’il se connecte | Supprimé de façon centralisée si le système est en ligne ; sinon récupéré ou placé sur liste noire | Comme une carte | Retiré de façon centralisée ou expire automatiquement à une heure définie | Doit être modifié, ce qui affecte toutes les personnes qui le connaissent | Supprimée de façon centralisée |
| En cas de perte | La personne qui trouve le téléphone doit d’abord le déverrouiller, sauf si l’application répond en arrière-plan | Utilisable par la personne qui la trouve jusqu’à son signalement | Utilisable par la personne qui le trouve jusqu’à son signalement | Toute personne détenant l’image peut l’utiliser jusqu’à son expiration ou son retrait | Aucun objet à perdre ; le risque est le partage | Ne peut pas être perdue |
| Peut-il être copié ? | Chiffré au repos et en transit ; le clonage est donc impraticable | Une ancienne carte non chiffrée peut être clonée avec du matériel peu coûteux | Comme une carte | L’image peut être photographiée ou transférée | Rien à copier ; le risque est le partage | Pas de copie dans le cadre d’un usage normal |
| Peut-il être prêté ? | Pas en pratique : le téléphone reste avec la personne | Facilement et sans laisser de trace | Facilement et sans laisser de trace | Facilement, en transférant l’image | Facilement, en le communiquant oralement | Non |
| Coût récurrent | Aucun support physique à réémettre | Une nouvelle carte chaque fois qu’une carte est perdue ou qu’une personne rejoint l’organisation | Un nouveau badge à chaque fois | Aucun | Aucun | Le matériel de lecture coûte plus cher par porte |
| Fonctionne sans réseau | Oui, lorsque l’identifiant contient les droits | Oui, lorsque l’identifiant contient les droits | Oui, lorsque l’identifiant contient les droits | Nécessite un écran sur le téléphone et une caméra à la porte | Oui, avec un clavier hors ligne | Dépend du lecteur |
Trois constats sans détour ressortent de ce tableau.
Une carte se prête très facilement à un collègue, contrairement à un téléphone. Il s’agit d’une différence comportementale plutôt que technique, et c’est le principal gain de sécurité concret apporté par les identifiants mobiles. Les gens partagent leur carte pour rendre service. Ils ne confient pas l’appareil qui contient leurs messages et leurs informations bancaires.
Chaque réémission de carte a un coût, principalement lié au travail nécessaire plutôt qu’au matériel. L’enjeu est aussi environnemental : un bâtiment qui cesse de distribuer des cartes cesse de produire le matériel (plastique) correspondant. Le code PIN est le moyen le plus faible du groupe, car il se communique oralement sans laisser de trace et ne peut être retiré qu’en le modifiant pour tout le monde.
Le smartphone n’est pas supérieur dans tous les domaines. Une carte n’impose pas au collaborateur de posséder un smartphone ni d’accepter d’installer une application. Tout bâtiment passant aux identifiants mobiles doit conserver un second type d’identifiant pour les personnes qui ne peuvent pas ou ne souhaitent pas utiliser de téléphone.
La plupart des systèmes de contrôle d’accès sont exacts le jour de leur configuration, puis dérivent. Une personne arrive et attend deux jours sa carte. Une autre change de service et conserve ses anciens accès parce que personne ne les a retirés. Une autre quitte l’organisation et sa carte reste valide jusqu’à ce qu’un responsable pense à la récupérer. Il ne s’agit pas de négligence. Cela arrive parce que le système d’accès possède sa propre liste de personnes, laquelle ne correspond à la réalité que lorsqu’un humain la met à jour.
Le provisionnement piloté par l’annuaire supprime cette étape humaine. La plateforme d’accès lit les données de l’annuaire d’identités déjà utilisé par l’organisation pour les emails et les connexions aux applications, généralement Microsoft Entra ID. Un nouveau collaborateur apparaît dans le système d’accès parce qu’il apparaît dans l’annuaire. Une personne quittant l’organisation perd l’accès au bâtiment dès que son compte est désactivé, sans demande distincte auprès d’une seconde équipe.
Deux détails comptent en pratique. Les accès d’un utilisateur correspondent à la combinaison de tous les groupes auxquels il appartient ; le déplacer d’un groupe à un autre modifie donc ses accès sans intervention porte par porte. Par ailleurs, la rapidité de propagation d’une modification jusqu’aux portes dépend de la configuration de la connexion à l’annuaire. Il faut donc convenir avec le fournisseur du délai attendu plutôt que de supposer qu’il est instantané. Avec Entra ID, l’application mobile est mise à jour lorsque l’utilisateur dispose d’une connexion internet.
Cette convergence a une autre conséquence. Lorsqu’un même annuaire gère à la fois le bâtiment et les logiciels, le téléphone peut servir à davantage qu’ouvrir une porte : le même appareil qui ouvre l’entrée peut authentifier une connexion au réseau ou à une application. C’est pourquoi les identifiants mobiles sont souvent abordés comme une composante de l’identité plutôt que comme un simple accessoire de sécurité.
L’effet sur l’administration est plus important qu’il n’y paraît. Sur une plateforme de contrôle d’accès dans le cloud, accorder à un prestataire l’accès à certaines portes prend moins d’une minute, et la modification des droits d’un collaborateur prend effet immédiatement. Toutes les personnes absentes de l’annuaire, prestataires, agents d’entretien, fournisseurs et visiteurs, sont créées directement dans la plateforme, généralement avec une date d’expiration définie dès la création afin que l’accès se supprime automatiquement.
La synchronisation avec l’annuaire convient bien aux collaborateurs. Elle ne couvre pas les personnes qui doivent entrer dans un bâtiment sans jamais apparaître dans un système RH, et c’est souvent là que le contrôle d’accès se heurte aux réalités quotidiennes.
Le problème tient au fait que l’administrateur constitue le goulot d’étranglement et n’est pas la bonne personne. Le responsable du magasin sait qu’un fournisseur arrive à 7h00. Le responsable des installations sait que l’entreprise de nettoyage a remplacé deux personnes cette semaine. Faire passer chacune de ces modifications par un administrateur central retarde une demande qui doit généralement être satisfaite dans l’heure.
La délégation des identifiants résout ce problème en confiant le partage à la personne qui dispose du contexte. Un administrateur désigne certains utilisateurs comme responsables d’un groupe d’utilisateurs et leur attribue un nombre d’identifiants. Ces responsables peuvent ensuite partager le profil d’accès du groupe depuis leur propre téléphone, par le canal déjà utilisé par les deux parties, sans intervention de l’administrateur à chaque fois.
L’administrateur conserve ce qui compte pour le contrôle : la limite du nombre d’identifiants qu’un responsable peut partager, la piste d’audit indiquant qui a ouvert quelle porte et la possibilité de tout retirer en une seule fois. La délégation répartit le travail sans répartir la supervision.
Dans ATLAS, cette fonction s’appelle le partage d’identifiants. Elle est disponible dans l’application pour le responsable d’un groupe ou tout utilisateur auquel l’administrateur a accordé ce droit. La personne autorisée partage le profil d’accès du groupe via l’application ATLAS, un email, AirDrop, WhatsApp ou toute autre application de messagerie. Le nombre de destinataires est illimité par défaut, mais l’administrateur peut le plafonner. Dans le commerce de détail, la chaîne va du gestionnaire immobilier, qui attribue un nombre défini d’identifiants à chaque responsable de magasin via le portail web, au responsable de magasin, qui les partage avec les collaborateurs, fournisseurs et équipes de nettoyage, puis les retire de la même manière lorsqu’une personne part.
| Situation | Ce qui se passe | Action de l’administrateur | À prévoir en amont |
|---|---|---|---|
| Téléphone perdu ou volé | L’identifiant est protégé par l’écran de verrouillage du téléphone ; trouver l’appareil ne permet donc pas d’ouvrir une porte, sauf si l’application répond en arrière-plan | Retire l’identifiant de façon centralisée ; il cesse de fonctionner sur cet appareil dès que le téléphone se connecte à internet, puis un nouvel identifiant est attribué au nouveau téléphone | Accepter qu’un téléphone maintenu hors ligne conserve son identifiant jusqu’à sa prochaine connexion. C’est pourquoi le code PIN ou la biométrie de l’appareil font partie du modèle de sécurité, sauf si l’application répond en arrière-plan |
| Batterie du téléphone déchargée | La personne ne peut pas présenter d’identifiant mobile | Aucune action | Un second type d’identifiant, choisi avant le déploiement |
| Absence de connexion internet | Cela dépend de l’endroit où la décision est prise. Un contrôleur dans le bâtiment et un identifiant contenant les droits fonctionnent normalement. Seule une décision prise dans le cloud nécessite une connexion | Aucune action ; les événements sont transmis au retour de la connexion | Confirmer avec le fournisseur quelles portes prennent leur décision sans la plateforme et lesquelles ont besoin de sa réponse |
| Batterie de la serrure faible | La serrure transmet son état à la plateforme par l’intermédiaire de l’application chaque fois qu’une personne utilise cette porte | Planifie le remplacement de la batterie avant l’arrêt de la serrure | Un système qui signale l’état des batteries afin de planifier leur remplacement plutôt que de réagir à une panne |
| Pas de smartphone, ou le collaborateur ne peut pas ou ne souhaite pas utiliser l’application | Aucun identifiant mobile n’est possible pour cette personne | Attribue une carte à la place | Un second type d’identifiant dès le premier jour, pour les personnes dépourvues de téléphone adapté et celles qui préfèrent ne pas installer l’application de leur employeur |
Deux de ces lignes méritent quelques précisions.
Un identifiant de secours doit résulter d’une décision de conception, et non d’une improvisation. Il faut déterminer non seulement ce qui ouvre la porte lorsque le téléphone ne le peut pas, mais aussi si cette solution de secours fonctionne sur toutes les portes ou seulement certaines. Avec ATLAS, une carte fonctionne sur n’importe quelle serrure, et les entrées équipées d’un interphone peuvent aussi accepter un code PIN ou un code QR, ce qui permet à un visiteur d’entrer sans rien installer.
La révocation atteint le smartphone, et non la serrure. Lorsque les serrures sont hors ligne et que les identifiants contiennent les droits, le retrait d’un identifiant ne nécessite pas d’intervenir sur chaque porte. L’annulation est transmise au téléphone et l’application cesse de fonctionner dès que l’appareil dispose d’une connexion. Un système de ce type peut ainsi fonctionner hors ligne au niveau de la porte tout en permettant une révocation rapide.

La réticence du personnel envers les identifiants sur téléphone ne concerne généralement pas la technologie. Elle vient de la crainte que l’installation d’une application de l’employeur sur un appareil personnel permette un suivi.
Le système enregistre quel identifiant a ouvert quelle porte et à quelle heure. Il s’agit du même événement que celui qu’un système à cartes a toujours enregistré. Cela produit une piste d’audit indiquant qu’une personne donnée est entrée dans une pièce donnée à un moment donné.
Le système n’enregistre ni les déplacements entre les portes, ni la localisation en dehors du bâtiment, ni aucune autre donnée du téléphone. Un événement de porte correspond à un point précis dans le temps et l’espace. Il ne dit rien sur l’endroit où la personne s’est rendue ensuite.
Ces enregistrements constituent des données à caractère personnel au sens du RGPD, ce qui entraîne trois obligations. La finalité du traitement doit être définie et communiquée. La durée de conservation doit être fixée et documentée, plutôt que laissée indéfinie. L’accès aux enregistrements doit être limité aux personnes qui en ont besoin pour cette finalité.
Au-delà du minimum légal, il convient de trancher la question du suivi des présences avant la mise en service du système. Les événements de porte ressemblent à des données de pointage ; une organisation qui commence à les utiliser ainsi a posteriori, sans l’avoir annoncé, transforme un déploiement discret en conflit.
Huit questions déterminent si un déploiement de contrôle d’accès mobile se déroule correctement. Chacune mérite d’être posée par écrit au fournisseur.
La réponse honnête est qu’une vérification au cas par cas est nécessaire. Cela dépend de nombreux facteurs propres à la technologie de chaque fournisseur.
Il importe de savoir si la plateforme prend en charge votre annuaire nativement, ce qui est la solution la plus simple, ou au moyen d’une connexion API à un système tiers. Les deux conviennent. Il faut éviter de découvrir que ni l’une ni l’autre n’est disponible et que la liste des utilisateurs doit être maintenue séparément.
Déterminez quel identifiant de secours est pris en charge et s’il fonctionne sur toutes les portes ou seulement certaines.
Demandez où la décision d’accès est prise, plutôt que de demander simplement si le système fonctionne hors ligne.
Deux éléments sont déterminants. Si la plateforme lit les données de votre annuaire, les fiches des collaborateurs apparaissent automatiquement sans saisie manuelle. Et si les collaborateurs peuvent ajouter eux-mêmes l’identifiant sur leur téléphone, au lieu qu’un administrateur le fasse pour chacun, la charge de travail évolue avec le nombre de collaborateurs plutôt qu’avec la taille de votre équipe. Si aucune de ces conditions n’est remplie, le temps compte : quelques minutes supplémentaires par personne représentent environ une semaine de travail pour mille collaborateurs.
La plateforme doit afficher cet état de manière centralisée afin que les serrures dont la batterie faiblit apparaissent dans une liste avant que quelqu’un ne reste bloqué. Dans ATLAS, la serrure transmet son état via l’application chaque fois qu’une personne utilise la porte. Sans signalement centralisé, le premier signe d’une batterie déchargée est une porte qui ne s’ouvre plus, ce qui rend la maintenance réactive dans un bâtiment pouvant compter des centaines de serrures.
L’export permet de conserver un historique plus long que celui de la plateforme et de déterminer quelles données peuvent être récupérées en cas de changement de fournisseur.
La gestion multisite répond à des besoins différents de la gestion d’un seul site : groupes d’utilisateurs communs à plusieurs emplacements, autorisations différentes selon le bâtiment et vue centralisée des événements. Il est plus simple de la prévoir dès le départ que de l’ajouter ultérieurement. Il convient donc d’aborder ce point même si vous ne gérez actuellement qu’un bâtiment mais prévoyez d’en avoir d’autres.
Acheter du contrôle d’accès signifiait autrefois lancer un projet d’investissement : un serveur, des armoires de...