Brevet FR2915606A1 — publié le 20081031

PROCEDE ET SYSTEME DE CONTROLE D'ACCES A UN EVENEMENT OU A UN SERVICE La présente invention concerne un procédé et un système pour le contrôle d'accès à tous types d'évènements, s'agissant par exemple de spectacles, concerts, expositions, évènements sportifs etc., ou encore en vue d'autoriser l'utilisation d'un service (par exemple un moyen de transport). Classiquement, le contrôle d'accès à un évènement nécessite de valider des autorisations d'accès, généralement nommées billets, permettant d'attester à leurs titulaires le droit d'entrer. Ces billets peuvent être préalablement émis par l'organisateur de l'évènement par l'intermédiaire de différents canaux de distribution appropriés ou être délivrés directement sur le site de l'évènement, y compris en dernières minutes ou pendant le déroulement de celui-ci. Un billet, classiquement au format papier, porte généralement les informations suivantes, données à titre indicatif et non limitatif : le titre de l'évènement, la date de l'évènement, la catégorie de place, le tarif, ainsi qu'un code barres constituant une représentation graphique d'un numéro d'ordre unique du billet permettant de faciliter la gestion automatique de l'ensemble des billets diffusés pour l'évènement. Il est également connu des billets dématérialisés au format électronique remplaçant le billet papier. Un billet électronique peut par exemple être stocké dans un terminal utilisateur disposant d'un moyen d'affichage par l'intermédiaire duquel au moins une partie de l'information susmentionnée relative au billet peut être présentée pour le contrôle. Un système de contrôle d'accès largement répandu repose sur l'utilisation de terminaux de contrôle, fixes ou mobiles, encore appelés douchettes dans ce dernier cas, capables de lire les codes barres des billets, et permettant ainsi d'assurer un contrôle et une comptabilisation rapide et efficace des billets. Ces terminaux de contrôle disposant de lecteurs de codes barres comprennent des moyens de stockage devant être préalablement chargés avec l'ensemble des codes barres correspondant aux billets valablement émis pour l'évènement en question, avant de pouvoir démarrer toute opération de contrôle. Ces terminaux de contrôle nécessitent donc d'arrêter les ventes de billets au moment de leur utilisation, ce qui les rend incompatibles avec des évènements autorisant des ventes de billets de dernières minutes. En effet, des billets vendus en dernières minutes, qui seraient émis après la synchronisation de la base de données mémorisée en local dans la douchette, ne pourraient pas être validés, bien qu'émis valablement. Une mise à jour la base de la base de données locale de la douchette pour prendre en compte les ventes de billets de dernières minutes nécessiterait pour le contrôleur de se rendre physiquement auprès du terminal mémorisant l'ensemble des billets vendus, alors que ce dernier peut être éloigné ou même être sur un site différent. Il est de plus difficile pour l'organisateur de l'évènement de disposer de statistiques précises suivies et en temps réel au sujet du nombre d'entrées, avant d'avoir déchargé l'ensemble des mémoires des différents terminaux de contrôle en fonctionnement sur le site. Cette opération, longue et complexe, nécessite en outre de disposer d'un technicien capable de la réaliser. Egalement, la mise en oeuvre de ce système de contrôle d'accès n'est pas satisfaisante dans le cadre de certains évènements où, dans un souci d'assurer une plus grande fluidité, les utilisateurs disposent de plusieurs accès, éventuellement éloignés de plusieurs dizaines voire centaines de mètres. En effet, ces terminaux lecteurs de codes barres n'étant pas prévus pour communiquer entre eux, on peut tout à fait imaginer qu'un même billet puisse donner droit à l'accès au niveau d'une entrée et redonner frauduleusement un nouveau droit d'accès au niveau d'une autre entrée distante. Ce système de contrôle d'accès basé sur l'utilisation de douchettes n'apporte donc à l'heure actuelle aucune solution pour gérer les liaisons entre les différents points d'accès correspondants aux différentes entrées du site. La présente invention a pour but de remédier à un ou plusieurs des inconvénients précités en proposant un système de contrôle d'accès amélioré. Avec cet objectif en vue, l'invention a pour objet un procédé de contrôle d'accès à un évènement ou à un service comprenant les étapes suivantes : d'enregistrement dans une base de données distante, pour toute autorisation d'accès à valider, de l'information relative à ladite autorisation comprenant au moins un identifiant unique d'autorisation ; -de connexion à la base de données distante depuis au moins un terminal de contrôle ; - de synchronisation en temps réel d'une base de données stockée localement sur le terminal de contrôle avec la base de données distante ; d'acquisition par le terminal de contrôle d'au moins un identifiant d'autorisation d'accès à vérifier ; - d'interrogation par le terminal de contrôle de la base de données distante ou de la base de données locale, pour identifier une autorisation d'accès à valider dont l'identifiant unique correspond à l'identifiant d'autorisation à vérifier; - de validation d'accès en cas de succès de ladite interrogation ; et - de mise à jour en temps réel de la base de données interrogée, consistant à indiquer ladite autorisation d'accès identifiée comme étant validée. Selon un mode de mise en oeuvre, le procédé comprend une étape d'enregistrement de l'identifiant d'autorisation d'accès identifiée dans la base de données locale dans une liste d'autorisations d'accès validées, contrôle. stockée localement dans le terminal de Avantageusement, le procédé comprend alors : la transmission de la liste d'autorisations d'accès validées, stockée localement dans le terminal de contrôle, vers la base de données distante, - la mise à jour de la base de données distante avec la liste d'autorisations d'accès validées reçue, et - le vidage de ladite liste. Avantageusement, l'étape de synchronisation de la base de données locale avec la base de données distante est effectuée à intervalles réguliers, de préférence après chaque vidage de la liste d'autorisations d'accès validées, stockée localement dans le terminal de contrôle. Selon un mode de réalisation, l'étape de synchronisation de la base de données locale comprend : - la récupération et la mémorisation sur le terminal de contrôle d'une signature de la base de données distante ; - la comparaison de la signature de la base de données distante avec une signature de la base de données locale ; - la substitution de l'information enregistrée dans la base de données locale par celle enregistrée dans la base de données distante en cas de différence des signatures ; et - la mémorisation de la signature courante de base de données locale. De préférence, l'information relative à une autorisation d'accès à valider comprend l'identité de la personne titulaire de ladite autorisation d'accès, l'étape de validation d'accès comprenant en outre la comparaison de l'identité de la personne titulaire de l'autorisation d'accès à vérifier avec celle enregistrée. Avantageusement, on interroge la base de données locale depuis le terminal de contrôle en cas de défaut temporaire de la connexion avec la base de données distante. De préférence, l'étape d'acquisition par le terminal de contrôle d'au moins un identifiant d'autorisation d'accès à vérifier comprend la lecture d'un code barres stocké et affiché sur un téléphone mobile. L'invention concerne également un système de 15 contrôle d'accès à un évènement ou à un service, comprenant . - un serveur central hébergeant une base de données distante mémorisant, pour toute autorisation d'accès à valider, l'information relative à ladite 20 autorisation comprenant un identifiant unique d'autorisation, et des moyens de connexion à un réseau de communication, - au moins un terminal de contrôle, comprenant : - des moyens de connexion sans fil adaptés à 25 réaliser une connexion automatique à un réseau local connecté par l'intermédiaire d'une passerelle audit réseau de communication, - des moyens de communication avec ledit serveur central via ledit réseau de communication, 30 - des moyens de synchronisation en temps réel d'une base de données stockée localement sur le terminal avec la base de données distante hébergée sur le serveur, - des moyens d'acquisition d'au moins un identifiant d'autorisation d'accès à vérifier, - des moyens d'interrogation de la base de données distante ou de la base de données locale pour identifier une autorisation d'accès à valider dont l'identifiant unique correspond à l'identifiant d'autorisation à vérifier, - des moyens de validation d'accès en cas de succès de l'interrogation, ledit système comprenant des moyens de mise à jour en temps réel de ladite base de données interrogée permettant d'indiquer ladite autorisation d'accès 15 identifiée comme étant validée. De préférence, le réseau local est un réseau local sans fil de type WiFi. Avantageusement, l'identifiant d'autorisation d'accès à vérifier comprend un code barres stocké et 20 affiché sur un téléphone mobile. L'invention concerne encore un terminal de contrôle, comprenant : - des moyens de connexion sans fil à un réseau de communication, 25 - des moyens pour établir une communication avec un serveur par l'intermédiaire du réseau de communication, - des moyens de synchronisation en temps réel d'une base de données stockée localement sur le 30 terminal avec une base de données distante hébergée sur le serveur, mémorisant des informations relatives à des 10 autorisations d'accès à valider, comprenant au moins un identifiant unique d'autorisation pour chaque autorisations d'accès à valider, - des moyens d'acquisition d'au moins un identifiant d'autorisation d'accès à vérifier, - des moyens d'interrogation de la base de données distante ou de la base de données locale pour identifier une autorisation d'accès à valider dont l'identifiant unique d'autorisation correspond à l'identifiant d'autorisation à vérifier, et - des moyens de validation d'accès en cas de succès de la vérification. Avantageusement, le terminal comprend des moyens de stockage d'une liste d'autorisations d'accès validées mémorisant l'identifiant d'autorisation d'accès identifiée dans la base de données locale et des moyens pour transmettre ladite liste audit serveur pour mise à jour de la base de données distante. Selon un mode de réalisation, les moyens d'acquisition comprennent un lecteur de codes barre. De préférence, les moyens d'acquisition comprennent des moyens de saisie manuelle d'un code numérique ou alphanumérique. Avantageusement, le terminal comprend un moyen 25 d'affichage. D'autres caractéristiques et avantages de la présente invention apparaîtront plus clairement à la lecture de la description suivante donnée à titre d'exemple illustratif et non limitatif et faite en 30 référence aux figures annexées dans lesquelles : la figure 1 décrit une architecture fonctionnelle sur laquelle repose le système de contrôle d'accès selon l'invention ; - la figure 2 illustre un organigramme décrivant 5 l'enchaînement d'étapes mises en oeuvre dans le procédé selon l'invention, de l'acquisition à la validation d'un billet par le terminal de contrôle, dans un premier mode de réalisation ; - la figure 3 illustre un organigramme décrivant 10 l'enchaînement d'étapes mises en oeuvre dans le procédé selon l'invention, de l'acquisition à la validation d'un billet par le terminal de contrôle, dans un second mode de réalisation ; - la figure 4 illustre un organigramme décrivant 15 l'enchaînement des étapes mises en oeuvre en parallèle des étapes décrites aux figures précédentes, pour la synchronisation de la base locale et la mise à jour de la base distante. Le système selon la présente invention, plus 20 particulièrement décrit en référence à la figure 1, repose sur une architecture permettant à une pluralité de terminaux de contrôle, tels que le terminal 20 représentés, répartis au niveaux de différents points d'accès sur le site de l'évènement, d'accéder en temps 25 réel à une base de données distante 14, prévue pour mémoriser toute l'information relative à des billets, ou autorisations d'accès, émis pour cet évènement et devant être validés lors du contrôle d'accès. L'information mémorisée pour chaque billet émis à 30 valider comprend nécessairement un identifiant unique de billet, typiquement le numéro associé au code barre ainsi que par exemple, l'identité (nom et prénom) du titulaire du billet, son numéro de téléphone mobile, le nombre de personnes compris sur le billet, la catégorie de tarif, etc. Pour ce faire, chaque terminal de contrôle comprend des moyens de connexion sans fil 24, adaptés à réaliser une connexion automatique à un réseau local 30, connecté par l'intermédiaire d'une passerelle 32 à un réseau de communication 34, typiquement le réseau Internet. Le réseau local 30 est de préférence un réseau sans fil de type WiFi. Les moyens de connexion 24 comprennent donc dans ce cas une carte réseau WiFi. Toutefois, pour éviter d'installer une infrastructure WiFi sur le site de l'évènement dort l'accès doit être contrôlé, on pourrait tout aussi bien envisager d'utiliser en tant que réseau d'accès local au réseau Internet, un réseau téléphonique cellulaire de type GPRS/GSM, EDGE ou UMTS par exemple. L'homme du métier saura alors choisir des moyens de connexion au réseau local adaptés en conséquence. Le terminal de contrôle comprend en outre une unité de traitement 25, mettant en oeuvre un programme informatique adapté à réaliser l'ensemble des fonctionnalités requises et qui seront explicitées plus en détail ci-après. Ainsi, le terminal de contrôle est adapté à communiquer via le réseau local et le réseau Internet avec un serveur central 10, doté de moyens de connexion 16 au réseau et hébergeant la base de données distante 14 de billets à valider. Pour la mise en oeuvre de l'invention, le terminal de contrôle comprend également des moyens de stockage d'une base de données locale 21, prévue pour être synchronisée avec la base de données distante 14 des billets à valider. Des moyens de synchronisation de la base de données 21 stockée localement sur le terminal avec la base de données distante 14 hébergée sur le serveur 10, sont alors mis en oeuvre par l'unité de traitement 25 du terminal de contrôle, comme détaillés plus loin. En outre, l'unité de traitement 25 est également adaptée pour mettre en oeuvre des moyens d'interrogation de la base de données distante ou de la base de données locale, pour identifier un billet à valider stockée dans la base, dont un identifiant unique correspond à un identifiant de billet à vérifier, présenté par son titulaire à un contrôleur muni du terminal de contrôle disposé au niveau d'un point d'accès de l'évènement. En cas de reconnaissance du billet à vérifier dont les modalités seront vues plus loin en détail, l'unité de traitement 25 du terminal de contrôle est adaptée à mettre en ouvre des moyens de validation d'accès, permettant d'indiquer au contrôleur que le billet est valide et que l'accès à l'évènement est donc autorisé. Pour ce faire, le terminal de contrôle est muni de moyens d'acquisition 23 d'au moins un identifiant de billet à vérifier. Comme on l'a vu, un billet comprend classiquement un code barres, constituant une représentation graphique d'un numéro d'ordre unique du billet. Ainsi, les moyens d'acquisition 23 du terminal de contrôle sont de préférence mis en ouvre sous la forme d'un lecteur de codes barres. Il peut s'agir par exemple d'un lecteur de codes barres équipé d'un dispositif à couplage de charges, encore appelé lecteur CCD. Un tel lecteur est particulièrement avantageux en ce qu'il permet de lire un code barres affiché sur un écran à cristaux liquides rétro-éclairé, dans l'hypothèse où le billet présenté au contrôleur serait un billet électronique, comprenant un code barres stocké dans un terminal utilisateur, par exemple un téléphone mobile 27, disposant d'un tel moyen d'affichage. Le code barres peut ainsi être stocké dans le téléphone mobile 27 sous la forme d'un fichier image au format GIF ou JPEG ou encore sous la forme d'un message multimédia (MMS). En variante, on pourrait aussi envisager d'utiliser à la place d'un lecteur de codes barres, un lecteur d'étiquettes radiofréquence, si l'information concernant le billet est stockée dans une puce RFID, ou encore un lecteur de carte à puce. Les moyens d'acquisition 23 comprennent ou outre des moyens de saisie manuelle d'un code numérique ou alphanumérique, en cas de d'impossibilité de lecture du code barres, par exemple parce que ce dernier serait illisible. Il est alors possible de saisir manuellement le code numérique, et éventuellement alphanumérique, présent sur le billet. Ces moyens de saisie manuelle se présentent typiquement sous la forme d'un clavier muni de touches alphanumériques, ainsi que de touches de fonction, servant à saisir des données et à lancer des commandes. Enfin, le terminal de contrôle est doté d'un moyen d'affichage 26, tel qu'un écran LCD par exemple, par l'intermédiaire duquel le contrôleur peut dialoguer avec le terminal via les moyens de saisie. Différents modes d'utilisation du terminal de contrôle dans le cadre du système de contrôle d'accès selon l'invention vont maintenant être présentés. Tout d'abord, préalablement à une opération de contrôle d'accès pour un évènement donné, le terminal de contrôle se connecte à une base de données évènements 12 hébergée au niveau du serveur central 10. La liste des évènements disponible est alors téléchargée sur le terminal de contrôle via le réseau de communication. Cette liste se présente par exemple sous la forme d'un menu déroulant affiché à l'écran du terminal, dans lequel l'évènement concerné est sélectionné, de même que sa date de représentation si plusieurs dates sont disponibles. Après validation de l'étape précédente, l'ensemble des billets émis pour l'évènement devant être validés lors du contrôle d'accès est téléchargé de la base de données distante 14 hébergé au niveau du serveur 10 dans la base de données 21 stockée localement au niveau du terminal de contrôle 20. Dès lors les opérations de contrôle des billets pour l'évènement en question peuvent démarrer. Dans un premier mode, illustré à la figure 2, les tâches d'acquisition et de validation des billets par le terminal de contrôle se déroulent en donnant priorité à la base de données locale 21. Ainsi, identifiant le terminal la lecture manuelle du Egalement, une première étape 40 d'acquisition d'un de billet à vérifier est mise en oeuvre par de contrôle. Cette étape peut consister en du code barre du billet ou en la saisie code numérique correspondant au code barre. on peut envisager ccmme alternative la sélection du code parmi une liste de codes présentée à l'écran du terminal. Une étape 41 d'interrogation de la base de données locale 21 est ensuite mise en oeuvre. Cette étape consiste à rechercher dans la base de données locale une occurrence dont le code mémorisé correspond au code à vérifier acquis par le terminal de contrôle. Cette étape est suivie d'une étape de validation 42, consistant à valider ou non l'accès suivant le résultat de l'interrogation menée à l'étape précédente. A l'étape 43, en cas de succès de l'interrogation, c'est-à-dire au cas où un billet à valider a été identifié dans la base de données locale dont le code correspond au code à vérifier, l'indication valide peut alors s'afficher à l'écran du terminal de contrôle, indiquant au contrôleur que le billet est reconnu et est alors composté ou validé. L'accès est alors autorisé à la personne titulaire du billet validé. Cette même étape 43 comprend la sauvegarde de ce résultat dans la base de données locale 21. Ainsi, la base de données locale est mise à jour en temps réel en indiquant, par exemple par un marqueur spécifique, que 30 le billet ainsi identifié a été validé. Pour renforcer la sécurité, l'étape de validation d'accès pourrait en outre comprendre la comparaison de l'identité de la personne titulaire du billet avec celle enregistrée dans la base de données locale pour le billet identifié. Enfin, une étape 44 est mise en oeuvre consistant à enregistrer l'identifiant du billet ainsi identifié dans la base de données locale 21, dans une liste 22 de billets validés, stockée localement dans le terminal de contrôle. Cette liste est destinée à mettre à jour la base de données distante 14, afin que cette dernière puisse prendre en compte de manière centralisée l'ensemble des billets validés par les différents terminaux de contrôle qui lui sont connectés et donc indiquer ces billets comme validés. Cette tâche de mise à jour fait l'objet d'une routine exécutée par le terminal de contrôle en parallèle des étapes d'acquisition et de validation d'un billet telles qu'elles viennent d'être décrite. Cette routine de mise à jour de la base de données distante est plus particulièrement décrite à la figure 4. Ainsi, dans une étape 60, on vérifie si la liste 22 de billets à valider dans la base de données distante est vide. Dans la négative, la liste est transmise vers la base de données distante 14, laquelle est mise à jour dans une étape 61 avec ladite liste. L'ensemble des billets de la liste validés par le terminal de contrôle est alors égaiement indiqué, par exemple par un marqueur spécifique, comme validé dans la base de données distante. Puis dans une étape 62, la liste 22, stockée localement dans le terminal de contrôle, est vidée. L'accès et la mise à jour en temps réel de la base de données distante permet ainsi avantageusement de mutualiser l'information de validation des billets récupérée par l'ensemble des terminaux de contrôle présents sur le site de l'évènement. Toutefois, afin de garantir la fiabilité du système, il est nécessaire que la base de données locale 21 soit synchronisée avec la base de données distante 14 à intervalles réguliers, afin justement de pouvoir être mise à jour avec l'information de validation récupérée et transmise par les autres terminaux de contrôle, mais aussi pour pouvoir prendre en compte des ventes de billets dernières minutes dont l'information relative correspondante aura été enregistrée dans la base de données distante après le précédent téléchargement du contenu de cette dernière dans la base de données locale. Cette tâche de synchronisation de la base de données locale avec la base de données distante fait partie de la même routine décrite en référence à la figure 4, prévue pour s'exécuter dans le terminal de contrôle en parallèle des tâches d'acquisition et de validation des billets. On parvient ainsi à une synchronisation en temps réel des bases de données locales et distantes, dans la mesure où le mode de traitement permet que les données relatives aux billets soient traitées immédiatement après leur acquisition et, en tous les cas que le temps de réponse qui sépare leur acquisition de leur prise en compte au niveau de la base de données locale est réduit au minimum. De préférence, la tâche de synchronisation est effectuée après chaque vidage de la liste 22 consécutif à la mise à jour de la base de données distante 14 avec la liste 22 de billets validés par le terminal de contrôle. Dans ce cas, le résultat de l'étape 60 fait passer directement à l'étape 70, consistant en la récupération et la mémorisation sur le terminal de contrôle d'une signature de la base de données distante 14. Pour calculer la signature de la base de données distante, on utilise par exemple la fonction de hachage MD5, permettant d'obtenir une empreinte numérique (en l'occurrence une séquence de 128 bits) du contenu de la base de données. Lorsque la moindre information change dans la base de données, sa signature utilisant l'algorithme MD5 change. Il s'agit ainsi d'un moyen simple et immédiat permettant de vérifier si le contenu de la base de données distante 14 a été modifié depuis la dernière synchronisation de la base de données locale 21 avec elle. Pour ce faire, on vérifie donc dans une étape 71 si la signature de la base de données distante récupérée par le terminal de contrôle est différente ou non de la signature courante de la base de données locale calculée en utilisant le même algorithme MD5. Dans la négative, la routine de mise à jour et de synchronisation des bases retourne à l'étape 60. Par contre, en cas de différence entre les signatures calculées, cela signifie que la base de données locale doit être synchronisée avec la base de données distante pour prendre en compte les modifications enregistrées dans cette dernière. Pour ce faire, une étape 72 est mise en oeuvre consistant à télécharger le contenu de la base de données distante 14 et à substituer l'information enregistrée dans la base de données locale 21 par celle ainsi téléchargée. Puis, la nouvelle signature de la base de données locale 21 est mémorisée par le terminal de contrôle. La figure 3 illustre un second mode où les tâches d'acquisition et de validation des billets par le terminal de contrôle se déroulent en donnant priorité à la base de données distante 14, la base de données locale n'étant dans ce mode utilisée que lorsque la connexion au réseau de communication est en défaut. Une étape 50 d'acquisition d'un identifiant de billet à vérifier est alors mise en oeuvre par le terminal de contrôle, de la même manière que celle décrite pour l'étape 40 en référence à la figure 2. Puis, une étape 51 d'interrogation de la base de données distante 14 est ensuite mise en oeuvre. Cette étape consiste à émettre une requête d'interrogation à destination du serveur 10 pour rechercher dans la base de données distante 14 une occurrence dont le code mémorisé correspond au code à vérifier acquis par le terminal de contrôle. Cette étape est suivie d'une étape de validation 52, consistant à valider ou non l'accès suivant le contenu de la réponse reçue du serveur 10 à la requête d'interrogation émise à l'étape précédente. A l'étape 53, en cas de succès de l'interrogation, c'est-à-dire au cas où un billet à valider a été identifié dans la base de données distante 14 dont le code correspond au code à vérifier, l'indication valide peut alors s'afficher à l'écran du terminal de contrôle, indiquant au contrôleur que le billet est reconnu et est alors composté ou validé. L'accès est alors autorisé à la personne titulaire du billet validé. La base de données distante est alors mise à jour en temps réel en indiquant, par exemple par un marqueur spécifique, que le billet ainsi identifié a été validé. La base de données locale 21 est également mise à jour de la même façon. Si la réponse à la requête d'interrogation est perdue, par exemple parce que la connexion est interrompue, l'étape 52 de validation bascule sur les étapes 41 à 44 de validation d'un billet en mode local qui s'exécutent de la même manière que décrite en référence à la figure 2. Enfin, les tâches de mise à jour et de synchronisation s'exécutent également selon la même routine que celle déjà décrite en référence à la figure 4, en parallèle des étapes d'acquisition et de validation de billets décrites selon le mode de réalisation de la figure 3.30 REVENDICATIONS 1. Procédé de contrôle d'accès à un évènement ou à un service comprenant les étapes suivantes : - d'enregistrement dans une base de données distante (14), pour toute autorisation d'accès à valider, de l'information relative à ladite autorisation comprenant au moins un identifiant unique d'autorisation ; de connexion à la base de données distante (14) depuis au moins un terminal de contrôle (20) ; - de synchronisation en temps réel d'une base de données (21) stockée localement sur le terminal de contrôle avec la base de données distante ; d'acquisition (40, 50) par le terminal de contrôle d'au moins un identifiant d'autorisation d'accès à vérifier ; - d'interrogation (41, 51) par le terminal de contrôle de la base de données distante ou de la base de données locale, pour identifier une autorisation d'accès à valider dont l'identifiant unique correspond à l'identifiant d'autorisation à vérifier; - de validation d'accès (43, .53) en cas de succès de ladite interrogation ; et - de mise à jour (43, 53) en temps réel de la base de données interrogée, consistant à indiquer ladite 25 autorisation d'accès identifiée comme étant validée. 2. Procédé selon la revendication 1, caractérisé en ce qu'il comprend une étape d'enregistrement (44) de l'identifiant d'autorisation d'accès identifiée dans labase de données locale dans une liste (22) d'autorisations d'accès validées, stockée localement dans le terminal de contrôle. 3. Procédé selon la revendication 2, caractérisé en ce qu'il comprend : -la transmission de la liste (22) d'autorisations d'accès validées, stockée localement dans le terminal de contrôle, vers la base de données distante (14), - la mise à jour (61) de la base de données distante (14) avec la liste d'autorisations d'accès validées reçue, et - le vidage (62) de ladite liste. 4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que l'étape de synchronisation de la base de données locale avec la base de données distante est effectuée à intervalles réguliers. 5. Procédé selon les revendications 3 et 4, caractérisé en ce que l'étape de synchronisation de la base de données locale avec la base de données distante est effectué après chaque vidage de la liste d'autorisations d'accès validées, stockée localement dans le terminal de contrôle. 6. Procédé selon les revendications 4 ou 5, caractérisé en ce que l'étape de synchronisation de la base de données locale comprend :- la récupération (70) et la mémorisation sur le terminal de contrôle d'une signature de la base de données distante ; - la comparaison (71) de la signature de la base de données distante avec une signature de la base de données locale ; la substitution (72) de l'information enregistrée dans la base de données locale par celle enregistrée dans la base de données distante en cas de différence des signatures ; et - la mémorisation (73) de la signature courante de base de données locale. 7. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que l'information relative à une autorisation d'accès à valider comprend l'identité de la personne titulaire de ladite autorisation d'accès et en ce que l'étape de validation d'accès comprend en outre la comparaison de l'identité de la personne titulaire de l'autorisation d'accès à vérifier avec celle enregistrée. 8. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'on interroge la base de données locale depuis le terminal de contrôle en cas de défaut temporaire de la connexion avec la base de données distante. 9. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que l'étape d'acquisition (40, 50) par le terminal decontrôle d'au moins un identifiant d'autorisation d'accès à vérifier comprend la lecture d'un code barres stocké et affiché sur un téléphone mobile (27). 10. Système de contrôle d'accès à un évènement ou à un service, comprenant : - un serveur central (10) hébergeant une base de données distante (14) mémorisant, pour toute autorisation d'accès à valider, l'information relative à ladite autorisation comprenant un identifiant unique d'autorisation, et des moyens de connexion (16) à un réseau de communication (34), au moins un terminal de contrôle (20), comprenant . -des moyens (24) de connexion sans fil adaptés à réaliser une connexion automatique à un réseau local (30) connecté par l'intermédiaire d'une passerelle (32) audit réseau de communication, - des moyens (25) de communication avec ledit serveur central via ledit réseau de communication, - des moyens (25) de synchronisation en temps réel d'une base de données (21) stockée localement sur le terminal avec la base de données distante hébergée sur le serveur, des moyens (23) d'acquisition d'au moins un identifiant d'autorisation d'accès à vérifier, des moyens d'interrogation (25) de la base de données distante ou de la base de données locale pour identifier une autorisation d'accès à valider dont l'identifiant unique correspond à l'identifiant d'autorisation à vérifier,- des moyens de validation. (25) d'accès en cas de succès de l'interrogation, ledit système comprenant des moyens de mise à jour en temps réel de ladite base de données interrogée 5 permettant d'indiquer ladite autorisation d'accès identifiée comme étant validée. 11. Système selon la revendication 10, caractérisé en ce que le réseau local est un réseau local sans fil 10 de type WiFi. 12. Système selon la revendication 10 ou 11, caractérisé en ce que l'identifiant d'autorisation d'accès à vérifier comprend un code barres stocké et 15 affiché sur un téléphone mobile (27). 13. Terminal de contrôle, comprenant : - des moyens (24) de connexion sans fil à un réseau de communication, 20 des moyens (25) pour établir une communication avec un serveur (10) par l'intermédiaire du réseau de communication, - des moyens (25) de synchronisation en temps réel d'une base de données (21) stockée localement sur le 25 terminal avec une base de données distante (14) hébergée sur le serveur, mémorisant des informations relatives à des autorisations d'accès à valider, comprenant au moins un identifiant unique d'autorisation pour chaque autorisations d'accès à 30 valider,- des moyens (23) d'acquisition d'au moins un identifiant d'autorisation d'accès à vérifier, - des moyens d'interrogation (25) de la base de données distante ou de la base de données locale pour identifier une autorisation d'accès à valider dont l'identifiant unique d'autorisation correspond à l'identifiant d'autorisation à vérifier, et - des moyens (25) de validation d'accès en cas de succès de la vérification. 14. terminal selon la revendication 13, caractérisé en ce qu'il comprend des moyens de stockage d'une liste (2.2) d'autorisations d'accès validées mémorisant l'identifiant d'autorisation d'accès identifiée dans la base de données locale (21) et des moyens pour transmettre ladite liste audit serveur pour mise à jour de la base de données distante. 15. Terminal selon les revendications 13 ou 14, caractérisé en ce que les moyens d'acquisition (23) comprennent un lecteur de codes barre. 16. terminal selon la revendication 15, caractérisé en ce que les moyens d'acquisition (23) comprennent des moyens de saisie manuelle d'un code numérique ou alphanumérique. 17. Terminal selon l'une quelconque des revendications 13 à 16, caractérisé en ce qu'il comprend un moyen d'affichage (26).