Brevet FR2998993A1 — publié le 20140606

Traitement de données pour accéder à une application Web La présente invention vise un traitement de données pour permettre à un équipement utilisateur d'accéder à une application Web hébergée dans un serveur. En particulier, l'invention vise un traitement de données pour permettre à un équipement utilisateur d'accéder à une application Web même lorsqu'il est déconnecté du serveur hébergeant l'application Web. Des technologies, par exemple la technologie SaaS (Software as a Service), ont été développées pour permettre la fourniture d'applications Web. Une application Web est généralement hébergée dans un serveur, et est accessible depuis un équipement utilisateur par le biais du réseau Internet. Ainsi, un utilisateur souhaitant accéder à l'application n'a pas besoin de réaliser au préalable une installation de l'application dans son équipement utilisateur. En outre, cette centralisation des données permet aux applications Web d'être plus simples à déployer et à modifier. Cependant, un inconvénient des applications Web est que l'équipement utilisateur ne peut plus y accéder si la connexion au réseau Internet est perdue. Les équipements utilisateurs comportent généralement une mémoire cache dans laquelle sont mémorisés des fichiers relatifs à des pages Web consultées lorsque l'équipement est connecté au réseau Internet. Ces fichiers peuvent être utilisés pour réafficher les pages Web correspondantes lorsque l'équipement est déconnecté du réseau Internet. Cependant, les fichiers mémorisés dans la mémoire cache permettent uniquement un affichage statique d'une page Web. Aussi, les fichiers de la mémoire cache ne permettent pas à un utilisateur d'accéder à des fonctionnalités d'une application Web. La présente invention vient améliorer la situation. A cet effet, l'invention propose un procédé de traitement de données pour permettre à un équipement utilisateur d'accéder à une application Web hébergée dans un serveur, l'équipement utilisateur comprenant un navigateur Web et des moyens de connexion au réseau Internet, le procédé comprenant des étapes, dans l'équipement utilisateur : - déterminer un état de connexion de l'équipement utilisateur par l'envoi d'une requête à destination du serveur, et - lorsque l'équipement utilisateur est déterminé comme étant dans un état connecté : - synchroniser une mémoire cache du navigateur Web avec des fichiers relatifs à l'application Web mémorisés dans le serveur, - mettre à jour une base de données du navigateur Web avec des données relatives à l'application Web mémorisées dans le serveur, et - accéder à l'application Web, - lorsque l'équipement est déterminé comme étant dans un état déconnecté : - accéder à l'application Web en utilisant des fichiers relatifs à l'application Web mémorisés dans la mémoire cache et des données relatives à l'application mémorisées dans la base de données du navigateur Web. La solution proposée dans cette invention peut ainsi permettre un accès à l'application, même en cas de changement d'état de connexion de l'équipement utilisateur, de manière transparente pour l'utilisateur. L'étape de détermination d'un état de connexion de l'équipement utilisateur est par exemple réalisée périodiquement. L'étape de mise à jour de la base de données du navigateur Web peut 20 comprendre une opération de création d'une base de données dans le navigateur Web. L'étape de mise à jour de la base de données du navigateur Web peut comprendre une opération de traitement de données reçues du serveur pour les adapter à un format de la base de données. 25 L'opération de traitement de données peut comprendre le découpage d'un ensemble de données en portions de l'ensemble de données, chaque portion présentant une taille inférieure à une taille limite prédéterminée. L'établissement d'une communication entre l'équipement utilisateur et le serveur est par exemple réalisé en utilisant un protocole de sécurisation des 30 données. Le procédé peut comprendre une étape d'authentification d'un utilisateur souhaitant accéder à l'application Web. L'étape d'authentification peut comprendre l'attribution d'un jeton de sécurité unique à l'utilisateur, le jeton ayant une durée de validité prédéterminée. L'invention propose également un programme informatique comportant des instructions pour la mise en oeuvre du procédé précité lorsque ce programme est exécuté par un processeur. L'invention propose également un équipement utilisateur comprenant un navigateur Web et des moyens de connexion au réseau Internet, l'équipement utilisateur étant configuré pour : - déterminer un état de connexion de l'équipement utilisateur par l'envoi d'une requête à destination d'un serveur hébergeant une application Web, et - lorsque l'équipement utilisateur est déterminé comme étant dans un état connecté : - synchroniser une mémoire cache du navigateur Web avec des fichiers relatifs à l'application Web mémorisés dans le serveur, - mettre à jour une base de données du navigateur Web avec des données relatives à l'application Web mémorisées dans le serveur, et - accéder à l'application Web, - lorsque l'équipement est déterminé comme étant dans un état déconnecté : - accéder à l'application Web en utilisant des fichiers relatifs à l'application Web mémorisés dans la mémoire cache et des données relatives à l'application mémorisées dans la base de données du navigateur Web. D'autres caractéristiques et avantages de l'invention apparaîtront encore à la lecture de la description qui va suivre. Celle-ci est purement illustrative et doit être lue en regard des dessins annexés sur lesquels : - la Figure 1 est un schéma fonctionnel montrant un réseau informatique comportant un serveur et un équipement utilisateur selon un mode de réalisation de l'invention ; - la Figure 2 est un organigramme illustrant les étapes d'un procédé d'accès à une application Web, selon un mode de réalisation de l'invention, cet organigramme pouvant représenter l'algorithme général du programme informatique au sens de l'invention ; - la Figure 3 est un organigramme représentant un exemple de réalisation de l'étape de détermination d'un état de connexion de l'équipement utilisateur du procédé de la figure 2 ; - la Figure 4 est un organigramme représentant un exemple de réalisation de l'étape de création de la base de données du procédé de la figure 2; - la Figure 5 est un organigramme représentant un exemple de réalisation des étapes de mise à jour de la base de données du procédé de la figure 2; - la Figure 6 est un organigramme représentant un exemple de réalisation de l'étape de récupération du manifeste pour la mise à jour de la base de données ; et - la Figure 7 est un organigramme représentant un exemple de réalisation de l'étape de lecture de la base de données du procédé de la figure 2. La figure 1 représente un réseau informatique comprenant un serveur 1 et un équipement utilisateur 2, configurés pour être connectés l'un à l'autre via le réseau Internet 3. Le serveur 1 comporte des moyens de connexion au réseau Internet 11, et héberge une application Web 10. L'application Web 10 est par exemple une application d'une entreprise permettant à des employés en déplacement d'avoir accès en permanence à des données professionnelles. L'application Web 10 peut en variante être une application permettant la consultation de livres numériques, ou de tout autre type de contenu. L'équipement utilisateur 2 est par exemple un ordinateur de bureau, un ordinateur portable, une tablette PC, un téléphone mobile de type Smartphone, ou 30 de manière générale tout type d'équipement utilisateur 2 comportant des moyens de connexion au réseau Internet 20 et un navigateur Web 21. Le navigateur Web 21 est un navigateur Web permettant la création d'une base de données et comportant une mémoire cache 22. L'équipement utilisateur 2 comporte en outre une interface homme-machine 23. L'interface homme-machine 23 est configurée pour recevoir, d'un utilisateur, une demande d'accès à l'application Web 10. L'équipement utilisateur 2 comporte des moyens d'accès à l'application Web 10 en mode déconnecté, c'est-à-dire lorsque l'équipement 2 n'est pas connecté au réseau Internet, donc au serveur 1. Les moyens d'accès peuvent comprendre un plugin installé dans le navigateur Web 21. Les moyens d'accès permettent de mettre en oeuvre, dans l'équipement utilisateur 2, des étapes d'un procédé d'accès à une application Web hébergée dans un serveur. La figure 2 représente des étapes du procédé d'accès à l'application Web 10, selon un mode de réalisation de l'invention. A l'étape Si, l'équipement utilisateur 2 reçoit d'un utilisateur une demande d'accès à l'application Web 10. La demande d'accès est reçue via l'interface 15 homme-machine 23. A l'étape S2, un état de connexion de l'équipement utilisateur 2 est déterminé. L'étape S2 comprend une opération d'envoi d'une requête à destination du serveur 1, une opération de réception d'une réponse à la requête, et une opération de détermination d'un état de connexion en fonction de la 20 réponse. Lorsque l'équipement utilisateur 2 est déterminé comme étant connecté au serveur 1, le procédé passe à l'étape S3, sinon le procédé passe à l'étape S11. L'étape S2 est par exemple réalisée périodiquement, pour détecter un changement d'état de connexion pendant l'accès à l'application 10. Cela permet notamment de gérer un passage de l'état connecté à l'état déconnecté de manière 25 transparente pour un utilisateur en train d'utiliser l'application 10. A l'étape S3, l'équipement utilisateur 2 détermine si des fichiers relatifs à l'application 10 ont déjà été mémorisés dans la mémoire cache 22, c'est-à-dire si l'équipement utilisateur 2 a déjà accédé à l'application 10. Lorsque des fichiers ont déjà été mémorisés dans la mémoire cache 22, le procédé passe à l'étape S4, 30 sinon le procédé passe à l'étape S5. A l'étape S4, les fichiers relatifs à l'application mémorisés dans la mémoire cache 22 sont synchronisés avec des fichiers correspondants mémorisés dans le serveur 1. Pour cela, les fichiers de la mémoire cache 22 sont comparés avec les fichiers correspondants du serveur 1. Lorsque les fichiers de la mémoire cache 22 ne correspondent pas aux fichiers du serveur 1, le procédé passe à l'étape S5, sinon le procédé passe à l'étape S6. A l'étape S5, les fichiers du serveur 1 sont mémorisés dans la mémoire cache 22. Ainsi, la mémoire cache 22 contient la version actuelle des fichiers relatifs à l'application 10. A l'étape S6, l'équipement utilisateur 2 détermine si une base de données à déjà été créée dans le navigateur 21. Si une base de données à déjà été créée, le procédé passe à l'étape S7, sinon le procédé passe à l'étape S8. A l'étape S7, l'équipement utilisateur 2 détermine une mise à jour de la base de données. Pour cela, des données relatives à l'application mémorisées dans la base de données sont comparées avec des données correspondantes mémorisées dans le serveur 1. Si les données de la base de données correspondent aux données du serveur 1, le procédé passe à l'étape S9, sinon le procédé passe à l'étape S10. A l'étape S8, une base de données est créée dans le navigateur 21. A l'étape S9, la base de données est mise à jour. L'étape S9 comprend une opération de traitement des données du serveur 1 pour les adapter au format de la 20 base de données, et une opération de mémorisation des données traitées dans la base de données. A l'étape S10, l'application Web 10 est prête à être utilisée dans un état déconnecté de l'équipement utilisateur 2. Lorsque les étapes S3 à S10 ont été exécutées au moins une fois, c'est-à- 25 dire lorsque l'équipement 2 a accédé au moins une fois à l'application 10 en mode connecté, les étapes S11 à S13 permettent un accès à l'application 10 en mode déconnecté. A l'étape S11, l'équipement utilisateur 2 récupère dans la mémoire cache 22 des fichiers relatifs à l'application 10, qui ont été préalablement mémorisés lors 30 d'un passage à l'étape S5. Aux étapes S12 et S13, les fichiers récupérés dans la mémoire cache 22 sont utilisés pour charger l'application 10. Les fichiers permettent notamment de définir quelles données doivent être récupérées dans la base de données, et dans quel ordre. A l'étape S14, l'équipement utilisateur 2 accède à l'application Web 10, en mode connecté ou en mode déconnecté. En mode déconnecté, l'application 10 est disponible par le biais des fichiers de la mémoire cache 22 et des données de la base de données. En mode connecté, l'application 10 est disponible par le biais d'une connexion au serveur 1, ou par le biais des fichiers de la mémoire cache 22 et des données de la base de données. Ainsi, le passage d'un état connecté à un état déconnecté est transparent pour l'utilisateur. La figure 3 représente un exemple de réalisation de l'étape S2 de détermination d'un état de connexion de l'équipement utilisateur 2. A l'étape S101, l'équipement utilisateur 2 émet une requête à destination du serveur 1 hébergeant l'application Web 10. La requête est par exemple une requête HTTP (HyperText Transfer Protocol). A l'étape S102, l'équipement utilisateur 2 reçoit une réponse à la requête émise à l'étape S101. A l'étape S103, l'équipement utilisateur 2 détermine si la réponse est un 20 message indiquant une connexion au serveur 1 ou un message d'erreur. Si la réponse est un message d'erreur, le procédé passe à l'étape S105. Sinon le procédé passe à l'étape S104. A l'étape S104, l'équipement utilisateur 2 est déterminé comme étant dans un état connecté. 25 A l'étape S105, l'équipement utilisateur 2 détermine si le message d'erreur indique une erreur de connexion ou une erreur d'une autre nature. Lorsque l'erreur est une erreur de connexion, c'est-à-dire que la requête a été correctement émise mais qu'aucune réponse du serveur 1 n'a été reçue, le procédé passe à l'étape S107, sinon le procédé passe à l'étape S106. A l'étape S106, l'équipement utilisateur 2 détermine que la connexion avec le serveur 1 a échouée, pour une raison autre qu'une absence de connexion au réseau Internet 3. A l'étape S107, l'équipement utilisateur 2 est déterminé comme étant dans un état déconnecté. La figure 4 représente un exemple de réalisation de l'étape S8 de création de la base de données. A l'étape S201, l'équipement utilisateur 2 détermine que la base de données n'a pas encore été créée dans le navigateur Web 21. A l'étape S202, l'équipement utilisateur 2 détecte un type de moteur de base de données associé au navigateur 21. A l'étape S203, l'équipement utilisateur 2 interroge le serveur 1 pour déterminer une configuration de l'application 10. A l'étape S204, l'équipement utilisateur 2 réalise une transformation du modèle de données afin d'adapter les données issues du serveur 1 au modèle de stockage utilisé sur l'équipement utilisateur 2. En d'autres termes, l'équipement utilisateur 2 crée un module de translation, dont la fonction est de permettre le traitement des données du serveur 1 pour les adapter au système de stockage du navigateur 21. Par exemple, dans le cas d'une base de données relationnelle, l'équipement utilisateur 2 réalise un mapping objet-relationnel, ou ORM (Objectrelational mapping). L'ORM permet de connecter des objets d'un système orienté-objet à des données stockées dans une base de données relationnelle. A l'étape S205, la base de données est crée par l'exécution de scripts SQL (Structured Query Language) générés à l'étape précédente. A l'étape S206, la base de données est prête à recevoir des données relatives à l'application 10. La figure 5 représente un exemple de réalisation des étapes S6, S7 et S9 de mise à jour de la base de données. A l'étape S301, l'équipement utilisateur 2 détermine qu'une base de données a déjà été créée dans le navigateur 22. A l'étape S302, l'équipement utilisateur 2 interroge le serveur 1 pour récupérer une liste de fichiers relatifs à l'application 10 à mémoriser dans la mémoire cache 22. L'ensemble des fichiers de la liste est appelé manifeste. Les étapes S303 à S309 sont répétées pour chaque fichier, ou ensemble de données, du manifeste. A l'étape S303, le fichier est encodé en base 64. La base de données du navigateur 22 a une structure différente de la base de données du serveur 1. En particulier, la base de données du navigateur 21 n'est pas capable de stocker des données binaires. L'étape S303 permet d'encapsuler des flux binaires pour les transformer en flux adaptés à la base de données du navigateur 21. A l'étape S304, l'équipement utilisateur 2 détermine si une clé a déjà été mémorisée dans la base de données du navigateur 21 pour le fichier. La clé est par exemple constituée par une adresse URL. Si une clé a été mémorisée, le procédé passe à l'étape S305, sinon, le procédé passe à l'étape S307. A l'étape S305, l'équipement utilisateur 2 détermine si le fichier mémorisé dans la base de données du navigateur 21 à la même taille qu'un fichier correspondant mémorisé dans le serveur 1. Si les fichiers ont la même taille, le fichier mémorisé dans la base de données est considéré comme étant à jour, et un nouveau fichier du manifeste est sélectionné, comme symbolisé par la flèche Fi. Sinon, le procédé passe à l'étape S306. A l'étape S306, le fichier mémorisé dans la base de données est supprimé. A l'étape S307, l'équipement utilisateur 2 détermine si la taille du fichier provenant du serveur 1 est supérieure à une taille limite prédéterminée. La taille limite dépend de la structure de la base de données. Si la taille du fichier est supérieure à la taille limite, le procédé passe à l'étape S308, sinon le procédé passe à l'étape S309. A l'étape S308, le fichier provenant du serveur 1 est découpé en portions de fichier, chaque portion présentant une taille inférieure à la taille limite prédéterminée. A l'étape S309, une nouvelle entrée est crée dans la base de données, à partir des portions de fichier. A l'étape S310, la base de données est déterminée comme étant à jour. La figure 6 représente un exemple de réalisation de l'étape S302 de récupération du manifeste. A l'étape S401, une requête de récupération du manifeste est générée et transmise au serveur 1. A l'étape S402, le manifeste est reçu par l'équipement utilisateur 2. L'équipement utilisateur 2 détermine une configuration du manifeste, par exemple en utilisant un fichier de configuration du manifeste. A l'étape S403, l'équipement utilisateur 2 génère un objet JSON (JavaScript Object Notation) à partir de noms de fichiers du manifeste. A l'étape S404, une configuration de l'équipement utilisateur 2 est déterminée. A l'étape S405, l'équipement utilisateur 2 met à jour une adresse URL de l'objet JSON. A l'étape S406, l'objet JSON est retourné. La figure 7 représente un exemple de réalisation de l'étape S13 de lecture de la base de données. A l'étape S501, l'équipement utilisateur 2 est déterminé comme étant déconnecté. A l'étape S502, l'équipement utilisateur 2 détermine si une base de données a été créée dans le navigateur 21. Si une base de données existe, le procédé passe à l'étape S503, sinon, une erreur est renvoyée (5502a). A l'étape S503, l'équipement utilisateur cherche dans la base de données une clé associée aux données à récupérer. A l'étape S504, l'équipement utilisateur 2 détermine si une clé existe. Si la clé existe, le procédé passe à l'étape S505, sinon une erreur est renvoyée (S504a). A l'étape S505, l'équipement utilisateur 2 détermine si un unique enregistrement correspond à la clé dans la base de données. Si un unique enregistrement est mémorisé, le procédé passe à l'étape S507, sinon le procédé passe à l'étape S506. A l'étape S506, l'équipement utilisateur 2 fusionne les enregistrements correspondants à la clé. A l'étape S507, les données de l'enregistrement sont retournées, sous la forme d'un flux de données. A l'étape S508, l'équipement détermine 2 si le flux de données est de type 10 HTML (HyperText Markup Language). Si le flux de données est de type HTML, le procédé passe à l'étape S509, sinon le procédé passe à l'étape S511. A l'étape S509, le flux de données est traité pour déterminer un identifiant URI (Uniform Resource Identifier). A l'étape S510, l'équipement utilisateur 2 détermine si d'autres données 15 doivent être lues dans la base de données. Si d'autres données doivent être lues le procédé retourne à l'étape S503, sinon le procédé passe à l'étape S520. A l'étape S511, l'équipement 2 détermine si le flux de données est de type JS (JavaScript). Si le flux de données est de type JS, le procédé passe à l'étape S512, sinon le procédé passe à l'étape S514. 20 A l'étape S512, l'équipement 2 charge le script correspondant en mémoire. A l'étape S513, l'équipement 2 détermine si le flux de données traité est de type HTML. Si le flux de données est de type HTML, le procédé passe à l'étape S509, sinon le procédé passe à l'étape S520. A l'étape S514, l'équipement 2 détermine si le flux de données est de type 25 CSS (Cascading Style Sheets). Si le flux de données est de type CSS, le procédé passe à l'étape S515, sinon le procédé passe à l'étape S517. A l'étape S515, l'équipement 2 crée un CSS à la volée selon le modèle DOM (Document Object Model). A l'étape S516, l'équipement 2 détermine si le flux de données traité est de type HTML. Si le flux de données est de type HTML, le procédé passe à l'étape S509, sinon le procédé passe à l'étape S520. A l'étape S517, l'équipement 2 détermine si le flux de données est de type média. Si le flux de données est de type média, le procédé passe à l'étape S518. A l'étape S518, l'équipement 2 remplace l'identifiant URI par un flux de données encodé en base 64. A l'étape S519, l'équipement 2 détermine si le flux de données traité est de type HTML. Si le flux de données est de type HTML, le procédé passe à l'étape S509, sinon le procédé passe à l'étape S520. Les étapes S511 à S519 sont des étapes de test de type de flux de données. Il convient de noter que d'autres types de flux de données pourraient être testés. A l'étape S520, les données de contenu à utiliser pour accéder à l'application 10 sont retournées. Le procédé d'accès à l'application permet ainsi de gérer un changement d'état de connexion de l'équipement utilisateur, et de réaliser une synchronisation avec des fichiers et des données du serveur 1 relatifs à l'application 10, de manière transparente pour l'utilisateur. En outre, le procédé peut être mis en oeuvre dans tout type d'équipement utilisateur disposant d'un navigateur Web, ce qui évite de devoir développer des moyens d'accès spécifiques pour chaque type d'équipement. Pour assurer la sécurité des données, l'établissement d'une communication entre l'équipement utilisateur 2 et le serveur 1 peut être réalisé en utilisant le protocole SSL (Secure Socket Layer). De plus, une authentification de l'utilisateur peut être réalisée pour permettre l'accès à l'interface homme-machine 23. L'authentification peut comprendre l'utilisation d'un login et d'un mot de passe permettant l'attribution d'un jeton de sécurité unique à l'utilisateur. Le jeton peut avoir une durée de validité prédéterminée, par exemple de sept jours. Ce jeton peut être un identifiant unique universel de type UUID (Universally Unique Identifier). Le jeton est alors transmis au serveur 1 dans la requête d'accès à l'application 10. Ainsi, pendant la durée de validité du jeton, l'accès à l'application 10 se fait très facilement et très rapidement au moyen du jeton. Le jeton doit être un identifiant unique et non partagé. Il peut par exemple être obtenu en utilisant un numéro d'identification de l'équipement utilisateur, associé à un temps auquel a été faite la demande d'authentification à la milliseconde près, et associé à un numéro d'identification d'un processeur de l'équipement utilisateur 2. Une fois que des données ont été synchronisées sur un équipement utilisateur 2, la version correspondante de l'application peut être utilisée sans connexion ultérieur au serveur 1. Cependant, pour garantir que la version de l'application utilisée est à jour, et/ou pour vérifier que l'utilisateur dispose encore bien des droits d'accès à l'application 10, il peut être souhaitable d'obliger les utilisateurs à se connecter régulièrement au serveur 1, par exemple tous les sept jours maximum. Ainsi, le jeton peut être utilisé pour limiter les conditions d'accès à l'application 10, même après que les données aient été téléchargées dans l'équipement utilisateur 2. Bien entendu, la présente invention ne se limite pas aux formes de réalisation décrites ci-avant à titre d'exemples ; elle s'étend à d'autres variantes.20 REVENDICATIONS1. Procédé de traitement de données pour permettre à un équipement utilisateur (2) d'accéder à une application Web (10) hébergée dans un serveur (1), l'équipement utilisateur comprenant un navigateur Web (21) et des moyens de connexion (20) au réseau Internet, le procédé comprenant des étapes, dans l'équipement utilisateur : - déterminer un état de connexion de l'équipement utilisateur par l'envoi d'une requête à destination du serveur, et - lorsque l'équipement utilisateur est déterminé comme étant dans un état connecté : - synchroniser une mémoire cache (22) du navigateur Web avec des fichiers relatifs à l'application Web mémorisés dans le serveur, - mettre à jour une base de données du navigateur Web avec des données relatives à l'application Web mémorisées dans le serveur, et - accéder à l'application Web, - lorsque l'équipement est déterminé comme étant dans un état déconnecté : - accéder à l'application Web en utilisant des fichiers relatifs à l'application Web mémorisés dans la mémoire cache et des données relatives à l'application mémorisées dans la base de données du navigateur Web. 2. Procédé selon la revendication 1, dans lequel l'étape de détermination d'un état de connexion de l'équipement utilisateur (2) est réalisée périodiquement. 3. Procédé selon la revendication 1, dans lequel l'étape de mise à jour de la base de données du navigateur Web (21) comprend une opération de création d'une base de données dans le navigateur Web. 4. Procédé selon la revendication 1, dans lequel l'étape de mise à jour de la base de données du navigateur Web (21) comprend une opération de traitement de données reçues du serveur (1) pour les adapter à un format de la base de données. 5. Procédé selon la revendication 4, dans lequel l'opération de traitement de données comprend le découpage d'un ensemble de données en portions de l'ensemble de données, chaque portion présentant une taille inférieure à une taille limite prédéterminée. 6. Procédé selon la revendication 1, dans lequel l'établissement d'une communication entre l'équipement utilisateur (2) et le serveur (1) est réalisé en utilisant un protocole de sécurisation des données. 7. Procédé selon la revendication 1, comprenant une étape d'authentification d'un utilisateur souhaitant accéder à l'application Web (10). 8. Procédé selon la revendication 7, dans lequel l'étape d'authentification comprend l'attribution d'un jeton de sécurité unique à l'utilisateur, le jeton ayant une durée de validité prédéterminée. 9. Programme informatique comportant des instructions pour la mise en oeuvre du procédé selon la revendication 1 lorsque ce programme est exécuté par un processeur. 10. Equipement utilisateur (2) comprenant un navigateur Web (21) et des moyens de connexion (20) au réseau Internet, l'équipement utilisateur étant configuré pour : - déterminer un état de connexion de l'équipement utilisateur par l'envoi d'une requête à destination d'un serveur (1) hébergeant une application Web (10), et - lorsque l'équipement utilisateur est déterminé comme étant dans un état connecté : - synchroniser une mémoire cache (22) du navigateur Web avec des fichiers relatifs à l'application Web mémorisés dans le serveur, - mettre à jour une base de données du navigateur Web avec des données relatives à l'application Web mémorisées dans le serveur, et - accéder à l'application Web, - lorsque l'équipement est déterminé comme étant dans un état déconnecté : - accéder à l'application Web en utilisant des fichiers relatifs à l'application Web mémorisés dans la mémoire cache et des données relatives à l'application mémorisées dans la base de données du navigateur Web.