FR 2923629 A1 20090515 FR 0759049 A 20071114 -1- � Procédé de gestion d'un accès automatique à un site web à partir d'un code graphique imprimé ou affiché � L'invention concerne un procédé de gestion de l'accès à une ressource informatique à travers un réseau, permettant d'améliorer les méthodes d'accès automatiques par lecture automatique d'un code graphique par exemple bidimensionnel. Etat de la technique Des appareils électroniques, en particulier mobiles, comprennent de plus en plus la capacité de capturer une image, photo ou vidéo, et de se connecter à un réseau d'ordinateurs tel que l'Internet. Dans ce cadre, certains modèles de téléphones mobiles peuvent exécuter un programme qui leur permet de lire un code graphique contenant une chaîne de caractères. De tels codes graphiques sont issus du principe des codes barres et existent selon différents formats, en particulier codés sur deux dimensions voire plus. Des formats de codes 2D actuellement connus sont par exemple les formats � Datamatrix � et � QRCode � et peuvent être imprimés sur différents supports permanents ou affichés sur des supports électroniques. Ces formats présentent souvent la forme d'un carré renfermant un grand nombre de petits carrés unitaires imprimés en noir ou en blanc, et dont la combinaison encode une chaîne de caractères plus ou moins longue. Certains formats peuvent présenter plus de deux dimensions, par exemple en utilisant des carrés unitaires de couleurs différentes, ou en utilisant des hexagones unitaires au lieu de carrés. Certaines applications utilisent ce type de codes graphiques, aussi appelés � tags �, pour accéder automatiquement à une adresse électronique qui est encodée dans un code graphique. Il peut s'agir par exemple une URL (Universel Ressource Locator) et plus particulièrement une adresse Internet de type mnémonique au format HTTP (Hyper Text Transport Protocol) sous une forme du type : � http://www.exemple.com �. Par exemple, un tel code graphique est imprimé dans une publicité pour un film à sortir. Ce code contient une chaîne de caractères formant -2- l'adresse d'une page web montrant une bande annonce de ce film. En photographiant ce code avec son téléphone mobile multimédia connectable, un utilisateur peut afficher facilement cette page web sur son téléphone, et visualiser cette bande annonce. Cependant, avec un grand nombre de types de codes graphique couramment utilisés, il s'avère que le nombre de caractères d'un emplacement de fichier ou d'une adresse web est parfois trop grand pour qu'ils puissent être encodés dans un seul code graphique. La trop grande longueur de cette adresse peut aussi obliger le code graphique à être de dimensions trop importantes, ou diminuer la taille des carrés unitaires et dégrader la fiabilité et la lisibilité du code imprimé ou affiché. Par ailleurs, une fois le code graphique imprimé et son support diffusé, il n'est plus possible de modifier son contenu, même si l'adresse électronique qu'il contient n'est plus valide ou doit être modifiée. Plus récemment, il a été proposé d'utiliser un code graphique imprimé ou affiché qui contient un code crypté spécifique, par exemple sous une forme numérique, généré précédemment par les soins d'un fournisseur de codes selon un plan de numérotation qui lui est propre. Ce code graphique est imprimé ou affiché sur un support, par exemple un journal ou un écran d'ordinateur. Il peut alors être photographié par un téléphone mobile configuré spécialement pour cela et doté d'un appareil photo numérique. Un tel téléphone comprend un logiciel de lecture spécifique dans lequel a été préalablement mémorisée l'adresse URL d'un serveur de décryptage spécifique qui est géré ou mis à jour par le fournisseur de codes. Chaque fois que ce téléphone lit un code graphique généré par ce même fournisseur de codes, ce logiciel de lecture ou � player � spécifique envoie à ce serveur de décryptage le code numérique contenu dans le code graphique qu'il a lu. Le serveur de décryptage utilise alors ce code numérique pour retrouver l'adresse complète du site web pour lequel le fournisseur de codes a généré ce code graphique, et l'utilise pour établir une connexion entre téléphone appelant et ce site web. Dans une telle application, seuls les téléphones disposant de ce logiciel de lecture spécifique et de l'adresse du serveur de décryptage -3- peuvent utiliser les codes graphiques générés pour accéder au site web correspondant. En effet, n'importe quel logiciel de lecture standard compatible avec la norme du code graphique, par exemple QRCode ou Datamatrix, pourra parfaitement lire le code numérique qu'il contient mais ne sera pas capable de l'utiliser. Ainsi, il serait utile de pouvoir utiliser de tels codes graphiques avec n'importe quel logiciel de lecture standard, par exemple pour des touristes étrangers qui ne disposent pas du logiciel spécifique. De plus, il existe un grand nombre de fournisseurs différents de tels téléphones ou ordinateurs, ainsi que de logiciels capables de lire de tels codes graphiques. En conséquence, il est très difficile d'apporter à ces standards des modifications ou des améliorations qui soient utilisables par tous les utilisateurs, quels que soient leur appareil ou leur logiciel ou leur opérateur de télécommunications. Objectifs de l'invention Un but de l'invention est de pallier aux inconvénients de l'art antérieur, et d'améliorer la compatibilité, la flexibilité, la fiabilité et la diversité des applications de communication utilisant un code graphique pour accéder à une information ou un service électronique sur réseau, en particulier selon les standards HTTP et World Wide Web sur un réseau de type Internet ou intranet ou extranet. Plus particulièrement, l'invention cherche à apporter de telles améliorations tout en permettant l'utilisation de tels codes graphiques par des appareils ou logiciels ou opérateurs variés voire quelconques, dès lors qu'ils sont compatibles avec le standard graphique du code graphique et avec les standards de connexion au réseau. De plus, un objectif important est à permettre à ce type d'application de connexion plus de liberté dans la longueur de la chaîne de caractères encodée dans un code graphique à lecture automatique et/ou dans la diversité des caractères qu'elle contient, y compris pour des caractères d'alphabets différents. -4- Elle cherche aussi à permettre une évolution du comportement obtenu en réponse à la lecture du code graphique, même après la diffusion de ce code graphique. Il est intéressant aussi de pouvoir effectuer un suivi plus ou moins centralisé de l'utilisation d'une pluralité de codes graphiques différents. Cela peut par exemple servir à une régie publicitaire d'effectuer des statistiques quant au succès de ses différentes campagnes en cours, pour le compte d'un client ou de plusieurs clients différents. Par ailleurs, l'invention cherche aussi à permettre la génération de tels codes graphiques de façon souple et en minimisant les contraintes telles que la mise à jour des serveurs, tout en restant simple et rapide pour les utilisateurs souhaitant faciliter l'accès à une adresse web déterminée. Exposé de l'invention Pour cela, l'invention propose un procédé de gestion de l'accès par un objet informatisé communicant doté de capacités de capture d'image, dit terminal de lecture, à au moins une page informatique, par exemple un document électronique ou une ressource informatique, hébergée par un premier serveur informatique, dit cible, au sein d'un réseau informatique. Ce procédé s'applique d'une part à la gestion d'un tel accès par un terminal de lecture, lorsque celui-ci est utilisé pour capturer sur un support imprimé ou affiché l'image d'un code graphique et décoder une chaîne de caractère contenue dans ce code graphique, dans le cas où cette chaîne de caractères forme une URL répondant directement aux standards de connexion au réseau. Selon l'invention, ce procédé de gestion d'accès comprend les étapes suivantes : - réception par un deuxième serveur dit intermédiaire, à travers ce réseau informatique et en provenance de ce terminal de lecture, d'une requête réseau dite intermédiaire, par exemple au format HTTP, comprenant une telle chaîne de caractères qui a été précédemment extraite d'un code graphique lu par ledit terminal de lecture, cette première URL incluant un identifiant correspondant à ce même code graphique ; -5- - traitement de cet identifiant de code graphique par le serveur intermédiaire pour fournir une chaîne de caractères formant une deuxième URL pointant sur ce serveur cible ; -utilisation de la deuxième URL pour connecter le terminal de lecture à ladite page de ce serveur cible. Dans un mode de réalisation actuellement préféré de l'invention, le terminal de lecture est un téléphone mobile ou un ordinateur mobile autonome comprenant une interface de communication informatique sans fil. Des ordinateurs fixes peuvent toutefois parfaitement être concernés, alternativement ou en combinaison. Le mode de réalisation actuellement privilégié comprend une requête réseau intermédiaire émise par le terminal de lecture au format HTTP sur le réseau Internet. Des applications sont toutefois possibles dans d'autres types de réseaux, avec les standards adéquats, en particulier des réseaux à architecture décentralisée et/ou de type client-serveur tels que des réseaux intranet ou extranet, publics ou privés. Dans le même esprit, le procédé selon l'invention s'applique d'autre part à la mise en place automatisée d'un code graphique personnalisé destiné à être utilisé par un tel procédé de gestion d'accès. Selon l'invention, le procédé comprend alors les étapes suivantes : - réception par un serveur dit générateur, de la part d'un ordinateur client, de données représentant une requête d'encodage et contenant une chaîne de caractères formant une URL dite cible pointant sur au moins une page d'un serveur dit cible ; - calcul d'une chaîne de caractères formant une URL dite intermédiaire et contenant : o d'une part au moins un chemin d'accès pointant sur un serveur mettant en oeuvre un tel procédé de gestion d'accès en tant que serveur intermédiaire, et o d'autre part une donnée d'identification de ladite requête d'encodage en tant qu'identifiant de code graphique tel que défini dans ce procédé de gestion d'accès ; -6- - émission, vers l'ordinateur client d'un fichier contenant des données aptes à imprimer ou afficher un code graphique contenant ladite URL intermédiaire. De plus, l'invention propose aussi un système informatique comprenant des moyens pour mettre en oeuvre un tel procédé de gestion d'accès, que ce soit en tant que serveur intermédiaire ou en tant que serveur générateur, ou les deux. Avantages apportés L'invention permet ainsi une grande ouverture vis à vis des différents intervenants de la chaîne technologique impliquée : en particulier les fabricants de terminaux, de logiciels de lecture, de logiciel de navigation, et/ou les opérateurs de communication pour l'accès au réseau (par exemple les opérateurs de téléphonie mobile). Cette ouverture est un atout important pour permettre la diffusion des avantages apportés par l'invention sans compromettre la compatibilité avec des intervenants inhabituels ou minoritaires, par exemple pour des touristes en provenance d'un pays étranger ou pour les clients d'un opérateur n'ayant pas d'accord de coopération technique avec le gestionnaire du serveur intermédiaire. Les serveurs intermédiaires ont moins besoin d'être centralisés ou concertés entre eux pour des mises à jour, diminuant ainsi les contraintes au niveau du ou des gestionnaires de serveurs intermédiaires, et facilitant leur fonctionnement et leur développement de façon plus indépendante les uns des autres. L'invention peut ainsi contribuer à une plus grande fluidité des échanges commerciaux et technologiques dans le secteur concerné, à une diffusion plus rapide des possibilités nouvelles, et permettre le maintien de possibilités de concurrence au sein du marché sans compromettre la liberté contractuelle des intervenants. Cette compatibilité universelle et cette souplesse de gestion apportées par l'invention sont d'autant plus intéressantes qu'elles sont combinées avec une meilleure souplesse de gestion de la page ou ressource accédée, et des capacités d'encodage type donné de code graphique. -7- L'invention permet ainsi aussi au gestionnaire du système intermédiaire, par exemple une régie publicitaire ou un fournisseur de services, de modifier l'URL finale (la deuxième URL) à n'importe quel moment, en temps réel, et donc de contrôler la ressource réellement accédée par un code graphique donné, sans changer la chaîne de caractères (la première URL) encodée dans ce code graphique lorsqu'il a été généré et diffusé. Ce code graphique restera donc utilisable en permanence par tous les utilisateurs, même si sa cible change au cours du temps. La chaîne de caractères encodée dans le code graphique n'a pas besoin d'être traitée manuellement par l'utilisateur du terminal client. Cette chaîne n'a donc pas besoin d'être mnémonique. Les contraintes diverses pesant sur l'URL finale de la page cible, par exemple dépendant de la structure du site web ciblé, ne s'appliquent pas à cette URL intermédiaire (la première URL). Cette première URL, et la chaîne de caractères qui sera encodée dans le code graphique, peut donc être générée sous une forme condensée telle qu'une numérotation continue. En diminuant le nombre de caractères à encoder, on améliore la compacité et/ou la lisibilité et la fiabilité du code graphique utilisé ce qui est intéressant pour les codes graphiques bidimensionnels les plus courants actuellement, par exemple QRCode et Datamatrix. En effet, bien que souvent d'une plus grande capacité que les codes barres unidimensionnels comme le EAN ou UPC (pour les numériques) ou le CIP39 (alphanumérique), certains de ces codes 2D actuels présentent moins de capacité d'encodage que d'autres codes bidimensionnels utilisés dans des domaines différents, comme par exemple le code PDF417. Par cette amélioration de capacité, l'invention peut aussi permettre d'utiliser des codes graphiques de moindre capacité ou densité, par exemple des codes barres unidimensionnels alphanumériques classiques, tels que le code CIP39. Liste des figures D'autres particularités et avantages de l'invention ressortiront de la description détaillée d'un mode de mise en oeuvre nullement limitatif, et des dessins annexés sur lesquels : -8- les FIGURE 1 et FIGURE 2 sont respectivement un schéma d'architecture et un schéma de procédure illustrant le fonctionnement de l'accès à une page web par un téléphone mobile à partir d'un article dans un magazine ; les FIGURE 3 et FIGURE 4 sont respectivement un schéma d'architecture et un schéma de procédure illustrant le fonctionnement de la génération d'un code graphique géré par un procédé selon l'invention. Description d'un mode de réalisation Une fois le code graphique lu par un lecteur approprié et pouvant naviguer sur Internet, la page cible ou la ressource finale visée est localisée dans une base de données spécifique. Avantageusement mais non exclusivement, cette base de données est hébergée ou mémorisée dans le serveur intermédiaire, correspondant au site web dont le nom de domaine a été utilisé pour générer l'URL encodée dans le code graphique. L'algorithme du site web est développé de façon à reconnaître l'identifiant de code graphique dans l'URL qui lui est transmise, puis à récupérer l'URL finale visée via une requête à la base de données, puis à rediriger le navigateur vers cette URL finale. Le code barre est donc interopérable avec tout système pouvant décoder le symbole et accéder à une ressource via une URL. Est appelée � URL � (pour � Uniform Resource Locator �), une chaîne de caractères qui peut être interprétée par un logiciel navigateur pour accéder à une ressource sur un réseau informatique. Au format HTTP, cette chaîne combine les informations nécessaires pour indiquer à un tel logiciel comment accéder à une ressource Internet, par son nom mnémonique alphanumérique au standard � web � ou par son adresse numérique au standard IP (Internet Protocol). Il est à noter que, depuis le 8 octobre 2007, les URL peuvent contenir d'autres caractères que les caractères ASCII, et donc par exemple des caractères chinois, japonais ou autres (Kanji, etc.). -9- Le terme d'URL est ici à prendre au sens large, c'est à dire qu'il inclut non seulement le nom de protocole et le chemin d'accès, mais aussi d'autres éléments de type paramètres de commande ou de configuration. Quelques exemples de possibilités et de définitions relatives au concept d'adresse de type � URL � sont présentés comme suit. Pour l'URL � www.example.com �: � http � indique le protocole de communication, en l'occurrence pour accéder à un service world wide web. � : � est un caractère de séparation. � // � est une chaîne de caractères utilisée pour les protocoles dont la requête comprend un chemin d'accès, permettant de préciser et localiser le service avant ce chemin. Différents exemples de types de sous-ensemble de la chaîne formant l'URL : � www.example.com � est le nom de domaine du service. Il est aussi possible d'utiliser son adresse IP (� 000.000.000.000 �). Si le nom de service ou l'adresse contiennent des caractères réservés, comme � : �, le nom de service ou l'adresse sera encadré de crochets doubles � [[ � et � ]] �. Dans l'URL � http://www.zone.example.com �, la chaîne � zone � indique un sous-domaine du domaine � www.example.com � Dans l'URL � http://www.zone.example.com/acc%C3%A8s.php �, la chaîne � acc%C3%A8s.php � est un nom de page Web appartenant au site web � www.example.com �. La chaîne � %C3%A8 � représente un caractère non ASCII, ici � è �. Des données supplémentaires optionnelles, inclues dans l'URL, peuvent être reçues par une requête réseau comprenant une demande d'accès à une ressource. Dans l'URL "http://www. server.com/page.php?argl=donnes#4266" : � ? � est un caractère de séparation pour indiquer que des données complémentaires suivent. � # � est un caractère de séparation pour indiquer un signet ou une balise à l'intérieur d'un document, par exemple dans une page HTML. - 10 - D'autres syntaxes permettent la réception de données supplémentaires optionnelles, par exemple : � q=req&q2=reg2 � est une chaîne de requête qui peut être traitée par la page web atteinte. Processus d'accès Les FIGURE 1 et FIGURE 2 illustrent le fonctionnement d'un accès par un terminal de lecture, tel que géré par le procédé selon l'invention. Le terminal de lecture 101 représenté ici est un téléphone mobile, ou cellulaire, d'un type disposant d'un appareil photo numérique et d'une interface connexion à l'Internet 100 selon les standards HTTP du World Wide Web. Il est doté d'un logiciel de reconnaissance et de décodage, tel que ceux qui sont actuellement couramment diffusés dans le monde, compatible avec une ou plusieurs normes de codes graphiques. Lors de sa lecture d'un magazine 110, l'utilisateur rencontre un ou plusieurs codes graphiques 111 et 115 imprimés dans un article, par exemple dans une brochure d'un Office du tourisme du département du Finistère en Bretagne. Souhaitant en savoir plus ou visionner informations multimédia sur ce sujet, l'utilisateur active, si besoin, la capture d'image 201 de l'un 115 de ces codes graphiques en le présentant devant l'objectif de son téléphone 101. Dans ce téléphone 101, le logiciel adapté (� player �) reconnaît que l'image comprend un code graphique. Il en effectue le décodage 202 et affiche sur son écran la chaîne de caractères 116 qu'il contient, à savoir une première URL (URL 1), dite intermédiaire ou condensée. Dans l'exemple cette URL condensée a la forme de la chaîne 116 suivante : � http://4265.server.com � Automatiquement, le logiciel de lecture transmet 203 cette chaîne de 30 caractères 116 au logiciel de navigation Internet du téléphone 101 pour lancement d'une consultation vers cette même URL (URL1). Le navigateur émet 204 vers le réseau 100 une requête réseau comprenant cette URL condensée 116. - 11 - Il est à noter que cette URL condensée présente un caractère totalement standard du point de vue du format de requête utilisée sur le réseau, et peut donc être employée par n'importe quel logiciel navigateur. Pour la même raison, cette URL condensée peut aussi être utilisée de façon � manuelle �, c'est à dire en saisissant manuellement ses caractères par exemple sur un clavier, par exemple si le code n'est pas lisible ou le dispositif de scanning du terminal de lecture n'est pas opérationnel. Son utilisation est possible dès lors que la chaîne de caractères 117 correspondante est connue, par exemple imprimée ou affichée à côté du code graphique, ou transmise de façon conventionnelle par exemple par téléphone ou par courrier papier. L'aspect � ouvert � fournit ainsi une compatibilité universelle qui permet des utilisations en mode dégradé dans de nombreuses situations. Acheminée par l'Internet 100 grâce à cette URL 116, cette requête intermédiaire est reçue 205 par un serveur dit intermédiaire 102, qui est enregistré dans l'Internet comme destinataire de cette URL (URL1), avec le nom de domaine : � server.com � Dans ce mode de réalisation, cette requête est reçue automatiquement et sans nécessiter aucune connexion ou identification ou abonnement supplémentaire. Toute reçue par cette URL intermédiaire est donc traitée comme venant de la lecture d'un code graphique 115, quelle que soit son parcours antérieur réel. Le serveur intermédiaire traite 206 la chaîne de caractères 116 de l'URL condensée (URL1), et en extrait une donnée d'identification 117 correspondant au code graphique 115 qui a été lu par le téléphone 101. dans l'exemple, cet identifiant est : � 4265 � Cette étape de traitement 206 de l'identifiant 117 du code graphique 115 fournit une deuxième URL (URL2) pointant sur la page web 1045 dite cible, hébergée par un serveur cible 104 au sein d'un site web 1040. Dans le présent exemple, cette deuxième URL présente la forme de la chaîne de caractères 1046 suivante : � http://fr.wikipedia.org/wiki/Climat du Finist%C3%A8re#Une � - 12 - On voit que cette deuxième URL (URL2) comprend 58 caractères ASCII, et peut ainsi être accédée automatiquement à partir d'un code graphique 115 qui ne contenait que les 22 caractères de la chaîne 116 de l'URL condensée (URL1), donc avec une meilleure fiabilité que s'il avait fallu encoder la totalité des 58 caractères. Cette page cible 1045 est sélectionnée parmi une pluralité de pages 1041, 1051 et 1061 hébergées par une pluralité de serveurs 1040, 1050 et 1060, possiblement au sein d'une pluralité de sites web 104, 105 et 106. Cette deuxième URL (URL2), appelée aussi URL profonde ou finale, est obtenue par une consultation 207 par le serveur intermédiaire 102 d'une base de données 103 mémorisant une pluralité d'enregistrements comprenant chacun de façon associée : - d'une part au moins une donnée correspondant à un identifiant 117 encodé dans au moins un code graphique 115, parmi une pluralité d'identifiants 113, 117, 123, respectivement 133 encodés dans une pluralité de codes graphiques différents générés ou diffusés 111, 115, 121, respectivement 131, et -d'autre part au moins chaîne 1046 représentant une adresse URL d'une page 1045, ou d'un serveur 1040, parmi cette pluralité de pages ou de serveurs. Le serveur effectue alors une redirection 208 du terminal de lecture 101 vers l'URL profonde, pour obtenir une connexion 209 de celui-ci au serveur cible 1040 hébergeant la page cible 1045 correspondant au code graphique 115 qui a été lu 201.. Dans l'exemple présenté, l'étape de connexion 208, 209 du terminal de lecture 101 au serveur cible 1040 comprend une émission 2081 de données comprenant un chaîne de caractères 1046 représentant la deuxième URL (URL2), par le serveur intermédiaire 102 vers le terminal de lecture 101. Cette émission 2081 est suivie d'une émission 2082 sur l'Internet 100 d'une requête réseau comprenant cette deuxième URL (URL2), par ce même terminal de lecture 101 vers ce serveur cible 1040. L'émission 2081 de l'URL profonde (URL2) vers le terminal de lecture 101 peut constituer par exemple une réponse par une fonction chargée de - 13 - renvoyer une entête HTTP, indiquant l'URL de redirection 1046 à utiliser et le statut de cette redirection. Une telle réponse peut être codée par exemple en langage ASP (Active Server Page), ou en langage PHP selon une syntaxe du type : header( "Status: 302 Moved temporarily", false, 302); header( "Location: http://fr.wikipedia.org/wiki/Climat du FinistôC3ôA8re#Une "); 10 exit () ; Si le terminal de lecture est compatible, par exemple si l'on souhaite éviter un référencement de cette redirection, cette réponse peut aussi être codée en Javascript, par exemple sans modifier l'entête HTTP selon une syntaxe du type : 15 window. location. replace( "http://fr.wikipedia.org/wiki/Climat du FinistôC3ôA8re#Une "); 20 --> Alternativement, l'étape de connexion 208, 209 du terminal de lecture 101 à la page cible 1045 du serveur cible 1040 peut comprendre une émission par le serveur intermédiaire 102, à destination de la deuxième 25 URL (URL2), d'une requête sur le réseau 100 pour le compte du terminal de lecture 101. Il peut s'agir par exemple d'émettre une telle requête avec comme identifiant d'expéditeur un identifiant du terminal de lecture 101, par exemple son adresse IP. Il est aussi possible au serveur intermédiaire de relayer un ou plusieurs échange de requêtes dans les deux sens entre le 30 terminal de lecture 101 et le serveur cible 1040. Optionnellement, le procédé selon l'invention peut comprendre en outre une mémorisation de données de statistiques par le serveur intermédiaire 102. Ces données statistiques peuvent être élaborées et mémorisées à 35 n'importe quel moment après réception de la requête réseau intermédiaire - 14 - sur l'URL condensée (URL1). Il peut s'agir par exemple d'une donnée de statistique représentant une demande de connexion 204 du terminal de lecture 101 au serveur cible 1040, calculée à partir de l'identifiant 117 du code graphique 115 qui a été lu 201 et/ou de l'URL profonde (URL2) vers laquelle s'est faite la redirection 208. Il peut s'agir aussi d'une donnée de statistique identifiant le terminal de lecture 101, calculée à partir de l'identification de l'expéditeur telle qu'elle figure dans la requête réseau intermédiaire reçue 205 sur l'URL condensée (URL1). Au cours de ses différentes activités, l'utilisateur de ce téléphone 101 peut-être confronté à différents codes graphiques, diffusés ou affichés sur différents supports, dont certains sont ici illustrés à titre d'exemple. Il peut ainsi lire simplement un code graphique affiché sur 121 l'écran de l'ordinateur de poche 120 d'un de ses amis, pour consulter simplement la page d'accueil du site web ou du � blog � de cet ami. Il peut aussi enregistrer cette image pour effectuer cette consultation ultérieurement ou l'ajouter aux favoris de son logiciel navigateur. Cet utilisateur 101 peut aussi lire automatiquement un code graphique imprimé sur l'étiquette d'un article de commerce, par exemple un plant de séquoia proposé par une boutique de jardinage. Il peut ainsi accéder immédiatement à une documentation vidéo fournie par le fournisseur de ce plant sur son site web commercial, et consulter des informations complémentaires sur le produit proposé, par exemple à quelle hauteur peut effectivement pousser cet arbre. L'invention peut aussi permettre une plus grande souplesse dans la gestion des différents de jeux de caractères qui peuvent maintenant être utilisés pour réaliser des adresses URL sur l'Internet. Optionnellement, lors de la création d'un code graphique, le serveur générateur 302 détecte de quel type sont les caractères de la chaîne formant l'URL profonde (URL2) qu'il reçoit 403. Si ces caractères risquent de ne pas être compatibles avec tous les logiciels de navigation existant, il propose à l'utilisateur de l'ordinateur client de mémoriser une troisième adresse URL, ou URL profonde alternative, qui sera fournie ou utilisée à titre - 15 - de remplacement lors d'une demande d'accès 204 par un navigateur non compatible. Dans un mode de réalisation incluant une telle option, le serveur intermédiaire 102 exécute en outre alors les étapes suivantes lorsqu'il reçoit une demande d'accès 204 quelconque : - détection, par le serveur intermédiaire 102, d'une différence entre le jeu de caractères exigé ou préféré par le logiciel navigateur du terminal de lecture 101 et le jeu de caractères utilisé dans la page cible 1045 ou dans l'adresse URL (URL2) de cette page cible ; - traitement de cette erreur, par exemple par émission vers ce terminal de lecture d'un message d'erreur indiquant une incompatibilité. Le traitement de cette erreur peut aussi comprendre la sélection par le serveur intermédiaire 102 d'une troisième chaîne de caractère formant une troisième URL pointant sur une partie de la page cible (1045) ou sur une version alternative de ladite page cible qui soit compatible avec le jeu de caractères utilisé par le logiciel navigateur de ce terminal de lecture. Cette troisième URL peut par exemple être mémorisée dans la base de données 103 au sein du même enregistrement que l'identifiant (117, ID) et l'URL cible (1046, URL2). Processus de mise en place Les FIGURE 3 et FIGURE 4 illustrent la mise en place d'un nouveau code graphique en self-service depuis un ordinateur client, dans un système gérant les accès selon l'invention. L'utilisateur d'un ordinateur client 301 dispose de l'adresse URL2 d'un site web, ou d'une ressource informatique, qu'il veut pouvoir faire partager facilement. Cette adresse URL2 dite cible a la forme d'une chaîne de caractères 1052 et pointe sur une page web 1051 hébergée par un serveur dit cible 1050 dans le cadre d'un site web 105. Pour obtenir un code graphique qui permette un accès automatique, tel que décrit plus haut, à cette page 1051 de son site web 105, l'utilisateur se connecte 401 à un serveur générateur 302, possiblement avec une identification et/ou un paiement. Dans le présent exemple, la chaîne 1052 de l'URL cible est : - 16- "http://fr.monblog. org/toto/accueil copains.htm#photo noel" L'utilisateur envoie 402 à ce serveur générateur 302 une demande ou requête d'encodage comprenant la chaîne de caractère 1052 de l'URL cible (URL2). Après réception 403 et acceptation de cette demande, le serveur générateur 302 génère un nouvel identifiant (ID) correspondant à cette demande, et qui sera utilisé comme identifiant de code graphique lors d'une demande d'accès 204 (cf. FIGURE 2) traitée par le serveur intermédiaire 102 (cf. FIGURE 1). Il peut s'agir par exemple d'une chaîne de caractères 123 représentant un numéro incrémenté de un par rapport au précédent numéro 117 généré, ici la chaîne : "4266" A partir de cet identifiant (ID), le serveur générateur 302 génère une chaîne de caractères 122 formant une URL dite condensée (URL1), comprenant cet identifiant (ID) et qui servira ultérieurement d'URL intermédiaire pour une demande d'accès 204 depuis n'importe quel terminal de lecture 101. La mise en place comprend alors plusieurs processus pouvant s'exécuter sans nécessité d'ordonnancement entre eux : - Envoi 406 à l'ordinateur client de données lui permettant d'utiliser ou de diffuser un code graphique 121 contenant l'URL condensée (122, URL1). - Mémorisation 408 d'un nouvel enregistrement dans la base de données 103 ; - Activation 407 de l'URL condensée dans ou vis à vis du serveur intermédiaire 102 ; et L'étape 406 d'envoi des données de code graphique à l'ordinateur client 301 comprend le calcul des paramètres définissant un code graphique 121 contenant la chaîne 122 formant l'URL condensée (URL1) précédemment générée 405. A partir de ces paramètres, le serveur générateur 302 génère 4061 un fichier image 1210, de type bitmap ou vecteur, qu'il envoie 4062 à l'ordinateur client 301. Ce fichier peut porter un nom contenant la chaîne 123 de l'identifiant ID de code graphique 121, par exemple : "tag4266.jpg" pour un fichier image au format JPEG. - 17 - L'utilisateur peut alors mémoriser cette URL condensée, sous forme de caractères 122 ou sous forme de code graphique 121, et l'imprimer 4063 ou l'afficher 120 (cf. FIGURE 1) pour la faire lire 201 à touts ceux qui souhaitent pouvoir se connecter facilement à son site web 1052, 105. L'étape 408 de mémorisation comprend une mémorisation de la chaîne 1052 formant l'URL cible (URL2), en association avec l'identifiant (ID) de code graphique 121 dans une base de données 103 accessible au serveur intermédiaire 102 pour une consultation 207 déclenchée par une demande d'accès 204. En outre, sans nécessité d'ordonnancement, un agent logiciel est généré ou activé 407 dans ou vis à vis du serveur intermédiaire 302, de façon à ce que toute requête réseau 204 envoyée sur le réseau 100 vers cette URL condensée (122, URL1) soit reçue par ce serveur intermédiaire 102. Une telle requête sera alors traitée comme requête intermédiaire et déclenchera une redirection 208, 209 vers la page cible 1051 quel que soient le terminal de lecture ou son logiciel de lecture et de navigation ou l'opérateur de communication qui la transmet vers ou à travers le réseau 100. L'activation peut être déclenchée de différentes façons, par exemple par envoi de données contenant la chaîne de caractères 122 formant l'URL condensée générée au serveur intermédiaire 102, avec une commande lui indiquant d'en déclencher une activation. Différentes syntaxes sont possibles pour générer cette URL condensée (URL1), à partir de l'identifiant et d'un chemin d'accès aboutissant au serveur intermédiaire 102 devant être utilisé pour recevoir les demandes d'accès 204. Le mode d'activation 408 de chaque URL condensée auprès du serveur intermédiaire 102 se fera conformément à la syntaxe utilisée pour la génération 405 de l'URL condensée. De plus, lors d'une demande d'accès 204, le traitement 206 de l'URL intermédiaire reçue par le serveur intermédiaire 102 pour en extraire l'identifiant (ID) du code graphique lu 201, est réalisé selon un algorithme adapté à la syntaxe utilisée pour la génération 405 de l'URL condensée (URL1). - 18 - Par exemple, l'identifiant ID peut être intégré dans l'URL condensée en tant que sous-domaine du domaine web pour lequel le serveur intermédiaire 102 est enregistré. L'activation 407 comprendra alors le paramétrage d'un sous-domaine pour le serveur intermédiaire 102. Ainsi, pour un nom de domaine du serveur intermédiaire 102 : "http://www.server.com" La chaîne 122 formant l'URL condensée peut être : "http://4266.server.com" L'identifiant peut aussi être passé sous la forme d'une référence relative à la hiérarchie au sein du domaine, auquel cas l'activation 408 comprendra la création d'une page correspondant à cette hiérarchie et comprenant un script programmé pour consulter la base de donnée 103. Par exemple : "http://www.server.com/4266/" Il est aussi possible de passer cet identifiant sous la forme d'un nom de fichier script, auquel cas l'activation 408 comprendra la création d'un fichier script programmé pour consulter la base de donnée 103. Par exemple pour un script de type PHP : "http://www.server.com/4266.php" Une autre possibilité est de passer cet identifiant sous la forme d'un paramètre additionnel ou supplémentaire utilisé par une ressource active présente dans le domaine du serveur intermédiaire 102, auquel cas l'étape d'activation 408 peut être réduite voire inexistante. Par exemple pour un fichier script de type PHP nommé � page.php � et recevant 206 l'identifiant (ID) en paramètre et consultant 207 la base de données 103 : "http://www.server.com/page.php?4266" "http://www. server.com/page.php?argl=4266" "http://www. server.com/page.php?argl=donnes#4266" Optionnellement, le serveur intermédiaire 102 peut être programmé pour pouvoir traiter des URL intermédiaires répondant à différentes syntaxes. Par exemple en activant différents types de ressources au sein de son domaine, ou en interprétant un paramètre inclus dans l'URL condensée et indiquant le type de syntaxe utilisée pour sa génération 405. - 19 - Il est à noter que le procédé selon l'invention peut aussi s'appliquer à d'autres types d'adresses informatique. Ainsi, il peut s'agir par exemple d'adresses de courrier électronique, ou d'adresses de type URI (pour � Universal Ressource Identifier �), qui sont un type plus large d'adresse informatique dans un réseau. Bien sûr, l'invention n'est pas limitée aux exemples qui viennent d'être décrits et de nombreux aménagements peuvent être apportés à ces exemples sans sortir du cadre de l'invention. REVENDICATIONS 1. Procédé de gestion de l'accès par un objet informatisé communicant doté de capacités de capture d'image, dit terminal de lecture (101), à au moins une page informatique (1045) hébergée par un premier serveur informatique (1040), dit cible, au sein d'un réseau informatique (100), ledit procédé comprenant les étapes suivantes : - réception (205) par un deuxième serveur (102) dit intermédiaire, à travers ledit réseau informatique (100) et en provenance dudit terminal de lecture (101), d'une requête réseau dite intermédiaire comprenant une chaîne de caractères (116) formant une première URL (URL1) qui a été précédemment extraite (202) d'un code graphique (115) lu (201) par ledit terminal de lecture sur un support imprimé (110, 130) ou affiché (120), ladite première URL incluant un identifiant (117) correspondant audit code graphique (115) ; traitement (206) dudit identifiant (117) de code graphique par le serveur intermédiaire (102) pour fournir une chaîne de caractères (1046) formant une deuxième URL (URL2) pointant sur ledit serveur cible (1040) ; -utilisation (208) de la deuxième URL pour connecter (209) le terminal de lecture (101) à ladite page (1045) dudit serveur cible (1040). 2. Procédé selon la revendication précédente, caractérisé en ce qu'il comprend (206) en outre une étape d'extraction de l'identifiant (117, ID) du code graphique (115), par le serveur intermédiaire (102), à partir d'un chemin d'accès compris dans la première URL (116, URL1) extraite dudit code graphique par le terminal de lecture (101). 3. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend (206) en outre une étape d'extraction de l'identifiant (117, ID) du code graphique (115), par le serveur intermédiaire (102), à partir d'au moins une donnée de paramètre comprise dans la première URL (116, URL1) extraite dudit code graphique par le terminal de lecture (101).- 21 - 4. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que l'étape (206) de traitement de l'identifiant (117) du code graphique (115) pour fournir la deuxième URL (1046, URL2) pointant sur une page (1045) d'un serveur cible (1040) parmi la pluralité de serveurs (1040, 1050, 1060) comprend une consultation (207) par le serveur intermédiaire (102) d'au moins une base de données (103) mémorisant une pluralité d'enregistrements comprenant chacun de façon associée : - d'une part au moins une donnée correspondant à un identifiant (113, 117, 123, 133) encodé dans au moins un code graphique (111), parmi une pluralité de codes graphiques (111, 115, 121, 131) différents générés ou diffusés, et -d'autre part au moins une adresse URL (1046, URL2) d'un serveur (1040) parmi une pluralité d'URL (1042, 1046, 1052, respectivement 1062) pointant vers ladite pluralité de serveurs (1040, 1040, 1050, respectivement 1060). 5. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que l'étape de connexion (208, 209) du terminal de lecture (101) au serveur cible (1040) comprend au moins une émission (2081) de données comprenant la deuxième URL (1046, URL2), par le serveur intermédiaire (102) vers le terminal de lecture (101), suivie d'une émission (2082) à travers le réseau (100) d'une requête comprenant ladite deuxième URL (1046, URL2), par ledit terminal de lecture (101) vers ledit serveur cible (1040). 6. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que l'étape de connexion (208, 209) du terminal de lecture (101) au serveur cible (1040) comprend au moins une émission par le serveur intermédiaire (102), à destination de la deuxième URL (1046, URL2), d'une requête pour le compte du terminal de lecture (101). 7. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend en outre une mémorisation par le serveur-22 - intermédiaire (102), à partir de l'identifiant (117) du code graphique (115), d'au moins une donnée de statistique représentant une demande (204) de connexion du terminal de lecture (101) au serveur cible (1040). 8. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend en outre une mémorisation par le serveur intermédiaire (102), à partir de l'identification de l'expéditeur de la requête réseau intermédiaire (204, URL1), d'au moins une donnée de statistique identifiant le terminal de lecture (101). 9. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend en outre les étapes suivantes : -détection, par le serveur intermédiaire (102), d'une différence entre le jeu de caractères exigé ou préféré par le logiciel navigateur du terminal de lecture (101) et le jeu de caractères utilisé dans la page cible (1045) ; - traitement de cette erreur, soit par émission vers ledit terminal de lecture d'un message d'erreur indiquant une incompatibilité, soit en choisissant une troisième une chaîne de caractère formant une troisième URL pointant sur une partie de la page cible (1045) ou sur une version alternative de ladite page cible qui soit compatible avec le jeu de caractères utilisé par le logiciel navigateur dudit terminal de lecture. 10. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le terminal de lecture (101) est un téléphone mobile ou un ordinateur mobile autonome comprenant une interface (1019) de communication informatique sans fil permettant l'accès au réseau (100). 11. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que la requête réseau intermédiaire (204, URL1) est émise par le terminal de lecture (101) au format HTTP sur le réseau Internet (100) ou un réseau de type intranet ou extranet. 12. Procédé de fourniture d'un code graphique personnalisé comprenant les étapes suivantes :- 23 - - réception (402) par un serveur dit générateur (302), de la part d'un ordinateur client (301), de données représentant une requête d'encodage et contenant une chaîne de caractères (1052) formant une URL dite cible (URL2) pointant sur au moins une page (1051) dite cible d'un serveur dit cible (1050) ; - calcul (404, 405) d'une chaîne de caractères (122) formant une URL dite intermédiaire (URL1) et contenant o d'une part au moins un chemin d'accès pointant sur un serveur mettant en oeuvre un procédé de gestion d'accès selon l'une quelconque des revendications 1 à 9 en tant que serveur intermédiaire (102), et o d'autre part une donnée (123) d'identification de ladite requête d'encodage en tant qu'identifiant (ID) de code graphique ; - émission (406), vers l'ordinateur client (301) d'un fichier (1210) contenant des données aptes à imprimer (4063) ou afficher un code graphique (121) contenant ladite URL intermédiaire (122, URL1). 13. Procédé selon la revendication 12, caractérisé en ce qu'il comprend en outre, dans ledit serveur intermédiaire (102), une génération ou activation (407) d'un agent logiciel apte à recevoir (205) une requête réseau selon ladite URL intermédiaire (122, URL1) de la part d'au moins un terminal de lecture (101) et à mettre en oeuvre ledit procédé d'accès pour connecter (208, 209) ledit terminal de lecture avec ladite page cible (1051) dudit serveur cible (1050) ; 14. Procédé selon l'une quelconque des revendications 12 à 13, caractérisé en ce qu'il comprend en outre une étape de mémorisation (408) de la chaîne de caractères (1052) formant l'URL cible (URL2), en association avec l'identifiant (123, ID) de code graphique, dans une base de données (103) accessible au serveur intermédiaire (102). 15. Système informatique (102, 302) comprenant des moyens pour mettre en oeuvre un procédé selon l'une quelconque des revendications 1 à 14.