Brevet FR2959375A1 — publié le 20111028

SMUB4.FRD 1 Système informatique de partage et procédé correspondant L'invention concerne le domaine de l'informatique sur réseau étendu. L'avènement de l'internet a fourni de nouveaux canaux d'expression, tant aux particuliers, qu'aux professionnels de la publication. Cela s'est particulièrement renforcé avec le Web 2.0 au sein duquel les réseaux sociaux permettent de partager des informations toujours plus rapidement. Diverses solutions technologiques ont été développées pour permettre aux utilisateurs d'Internet de partager facilement un lien internet d'intérêt avec leurs connaissances. Cependant, ces outils ne permettent que de partager des éléments relatifs à la consultation du Web. Il n'existe actuellement aucune solution qui permette à un lecteur d'une publication imprimée écrite de partager un article, ou d'accéder à un contenu associé à cet article. L'invention vient améliorer la situation. À cet effet, l'invention propose un système informatique, agencé pour accéder à un réseau étendu qui comprend : - une mémoire stockant des données de page de partage, - une mémoire stockant des données de structure de page de partage, - une mémoire stockant des données de profil d'éditeur, - un extracteur, agencé pour recevoir une requête d'accès et pour en tirer un identifiant de page de partage et un identifiant de profil d'éditeur, - un cribleur agencé pour tirer des données de page de partage à partir d'un identifiant de page de partage, - un moteur agencé pour générer une page de partage à partir de données de structure de page de partage, de données de page de partage, et de données de profil d'éditeur, et - un pilote, agencé pour recevoir une requête d'accès d'un élément du réseau étendu, pour appeler le cribleur avec l'identifiant de page de partage et l'identifiant de profil d'éditeur déterminés par l'extracteur, pour appeler le moteur avec les données résultantes et les données de structure de page de partage, et pour renvoyer la page résultante audit élément du réseau étendu. D'autres caractéristiques et avantages de l'invention apparaîtront mieux à la lecture de la description qui suit, tirée d'exemples donnés à titre illustratif et non limitatif, tirés des dessins sur lesquels : - la figure 1 représente un schéma générique d'un environnement informatique dans lequel l'invention est mise en oeuvre, - la figure 2 représente un diagramme de flux d'un accès à une page de partage selon l'invention, - la figure 3 représente un exemple de maquette de page de partage produite selon l'invention, - la figure 4 représente un diagramme de flux de création et/ou de modification d'un profil d'éditeur dans le cadre de l'invention, - la figure 5 représente un diagramme de flux de création et/ou de modification d'une page de partage dans le cadre de l'invention, - la figure 6 représente un diagramme de flux de génération de données de page de partage dans le cadre de l'invention, et - la figure 7 représente un autre exemple de maquette de page produite selon l'invention. Les dessins et la description ci-après contiennent, pour l'essentiel, des éléments de caractère certain. Ils pourront donc non seulement servir à mieux faire comprendre la présente invention, mais aussi contribuer à sa définition, le cas échéant. La figure 1 représente un schéma générique d'un environnement mettant en oeuvre un système selon l'invention. Dans cet environnement, des postes clients 2 et 4 peuvent communiquer via un réseau 30 étendu 6 (par exemple Internet) avec un système informatique 8 selon l'invention.25 Dans l'exemple décrit, les postes informatiques sont un ordinateur portable 2 et un téléphone mobile 4. Cependant d'autres dispositifs peuvent être envisagés, comme un ordinateur de bureau ou un ordinateur de type "tablette". La principale caractéristique de ces dispositifs est leur capacité à se connecter au système informatique 8 et à afficher les pages que celui-ci leur renvoie. Le système informatique 8 est dans l'exemple décrit, ici, un serveur web monoposte. Ce serveur peut être réalisé sous toute forme appropriée comme une grappe de serveurs, éventuellement répartis en plusieurs emplacements différents. La principale caractéristique du serveur 8 est sa capacité à recevoir les requêtes d'accès aux pages de partage, et à fournir celles-ci. Dans l'exemple décrit ici, l'ordinateur portable 2 et le téléphone 4 comprennent chacun un programme de reconnaissance de caractères. Ce programme permet de détecter une chaîne de caractères dans une image traitée par ces dispositifs. Cette image peut être enregistrée sur la mémoire de ces dispositifs, ou tirée d'un capteur photographique du téléphone 4 ou d'une webcam incorporée à l'ordinateur portable 2. Les postes informatiques 2 et 4 comportent également un programme agencé pour envoyer une requête d'accès à une page de partage sur le serveur 8, qui contient le texte tiré de la reconnaissance de caractères. Le programme de requête d'accès et celui de reconnaissance de caractères peuvent être incorporés à un même programme, ou constituer des éléments séparés invoqués par un autre programme. Ainsi, si l'on considère l'exemple d'une application sur un téléphone mobile moderne, tel l'iPhone (marque enregistrée de la société Apple), une application peut être mise à disposition des utilisateurs. Cette application est programmée pour : - accéder au flux vidéo du capteur photographique de l'iPhone, - appeler un module de reconnaissance de texte sur une partie de ce flux, et - appeler directement le serveur 8 et afficher en retour la page de partage. Ces actions peuvent être exécutées en restant dans l'application et en faisant appel à des modules logiciels incorporés à l'iPhone. En variante, tout ou partie du code peut également être réécrit. Ce dernier cas peut être très avantageux comme on le verra avec la figure 6. Le serveur 8 comprend un pilote 10, un programme de gestion 12, un extracteur 13, un cribleur 14 et un moteur d'assemblage 16, ainsi que des mémoires 18, 20 et 22 pour stocker respectivement des données de profil, des données de page de partage et des données de contenu. Les mémoires 18, 20 et 22 peuvent être physiquement reliées au serveur 8, ou bien être accessibles à distance. Elles peuvent être réalisées au sein d'une mémoire unique, ou dans des unités de mémoire séparées. 20 La figure 2 représente un exemple de mise en oeuvre d'une requête d'accès à une page de partage auprès du serveur 8. Dans une première opération 200, le dispositif informatique 2 ou 4 génère une requête d'accès à la page de partage. Cette opération est réalisée par une fonction Gen(), qui 25 génère la requête à partir de la chaîne de caractère obtenue comme décrit plus haut. La fonction Gen( concatène cette chaîne de caractère avec une chaîne de texte qui forme un squelette de requête. Dans un mode de réalisation décrit ici, le serveur 8 est un serveur Web. La fonction Gen() la concatène avec l'adresse du serveur 8 à laquelle sont 30 envoyées les requêtes d'accès. 10 15 Par exemple la page qui est invoquée pour consulter une page de partage peut être une page "page_de_partage.htm" du serveur 8. La chaîne de caractère avec laquelle la chaîne de caractère sera concaténée sera alors du type http://URL_Serveur/page_de_partage.html, où URL_Serveur est l'adresse URL du serveur 8. Une fois les deux chaînes concaténées, la requête http qui sera émise aura la forme suivante : GET http://URL_Serveur/page_de_partage.html?page=chaîne_de texte_reconnue 10 HTTP/1.0 User-Agent : user agent_du_dispositif Une fois que cette requête est mise en forme par la fonction Gen(), une fonction Send() est utilisée pour envoyer cette requête au serveur 8 dans une opération 202. Cette requête est reçue par le serveur 8, et dans une opération 204, celui-ci la traite et produit des données de page de partage qui définissent une page de partage qui correspond à la chaîne "chaîne_de texte reconnue", au moyen de fonctions propres au serveur 8 désignées ici sous le nom de fonction Mk(ShPgDat). Comme on le verra dans la suite, les données de page de partage ShPDat peuvent varier en fonction de l'origine de la requête d'accès à la page partagée. En effet, comme on le verra avec la figure 6, le serveur 8 ne traitera pas de la même manière une requête issue d'une application spécifique et une requête issue d'un navigateur Web. Ensuite, le serveur 8 renvoie les données de page de partage Sh_Pg_Dat générées à l'opération 204 vers le dispositif 2 ou 4 émetteur dans une opération 206 au moyen de la fonction Send(). 30 Enfin, l'utilisateur peut accéder à la page de partage sur le dispositif émetteur 2 ou 4 dans une opération 208, via une fonction Brws(). 15 20 25 La figure 3 représente un squelette de page de partage qui est rempli avec des informations obtenues à partir de la requête Req par le serveur 8. Le détail de la génération de cette page apparaîtra mieux avec la figure 6. L'exemple représenté ici est particulièrement adapté à l'affichage sur un téléphone mobile. Comme on peut le voir sur la figure 3, les pages de partage sont divisées en plusieurs zones : - une zone EXT Z- , - une zone PUB Z- , -une zone TIT Z, -une zone ART Z, - une zone CONT Z, et - une zone SOC_Z. Les zones EXT Z, PUB_Z et TIT Z sont alignées verticalement dans cet ordre, au dessus des zones ART_Z et CONT Z qui sont sensiblement parallèle l'une avec l'autre dans cet ordre, et au dessus de la zone SOC_Z. Toutes ces zones peuvent être remplies avec divers types de contenu qui peuvent varier selon des paramètres établis par l'éditeur de la page de partage. La zone Ext_Z a pour vocation de recevoir des éléments extérieurs au contexte de la page partagée, et désignés par le créateur de la page. Par exemple, cette zone peut recevoir des données de publicités, qui peuvent permettre à l'éditeur d'être rémunéré en fonction de leur consultation. Par ailleurs, le contenu de ces pages peut être personnalisé en fonction des données fournies par l'éditeur de la page de partage et du fournisseur de pages de publicité. La zone Pub_Z a pour vocation de recevoir des données qui permettent d'identifier l'éditeur de la page de partage. Par exemple, lorsque la page de partage est une page liée à un article d'un magazine, la zone Pub_Z pourra recevoir un logo du magazine ou de l'éditeur du magazine, ainsi que des liens à une page d'abonnement ou autre. Dans l'exemple décrit ici, cette zone est commune aux pages de partage créées par un même éditeur. La zone Tit_Z a pour vocation de recevoir des données qui permettent d'identifier la page de partage. Cela peut par exemple être un titre éventuellement associé à un contenu. Cette zone est entièrement dynamique, c'est-à-dire qu'elle change avec chaque nouvelle page de partage. Il reste bien sûr possible d'utiliser des données identiques pour des zones Tit_Z de deux pages de partage distinctes. La zone Art Z a pour vocation de recevoir des données qui constituent le contenu principal de la page de partage, c'est-à-dire l'objet de la page de partage elle-même. Cela peut par exemple être une photo accompagnée d'un texte qui résume l'article, cette zone formant un lien hypertexte qui amène à l'adresse réelle de l'article faisant l'objet de cette page de partage. Là encore, cette zone est entièrement dynamique, c'est-à-dire qu'elle change avec chaque nouvelle page de partage. Il reste là encore possible d'utiliser des données identiques pour des zones Art Z de deux pages de partage distinctes. La zone Cont _Z a pour vocation de recevoir des données de contenu associé à l'article présenté dans la zone Art_Z. Ces contenus peuvent être des photos, des vidéos, un lien vers un forum de discussion sur cet article, un ou plusieurs liens vers des articles portant sur le même thème, etc. La description de la figure 4 montrera que ce contenu peut être particulièrement varié et là encore dynamique. Enfin la zone Soc_Z a pour vocation de recevoir des données de partage social de cette page de partage. Plus précisément, cette zone peut recevoir deux types d'éléments de partage : - d'une part des liens vers des sites de réseaux sociaux (par exemple Facebook, Twitter, Digg, un compte email ou autres) qui vont permettre à l'utilisateur de partager simplement l'adresse de l'article faisant l'objet de la page de partage avec ses connaissances. Les liens vers les sites de réseaux sociaux ne sont pas des simples redirections vers la page principale du site concerné : ils contiennent également les paramètres de commande nécessaires au partage requis par chaque site concerné. On pourrait les interpréter comme étant des requêtes. - d'autre part un ou plusieurs liens de sauvegarde, qui vont permettre à l'utilisateur d'enregistrer cette page parmi ses favoris dans un service relié au serveur 8 auquel l'utilisateur est abonné, pour permettre une consultation ultérieure avec un accès simplifié. Comme la zone Pub_Z la zone Soc_Z est dans l'exemple décrit ici commune aux pages de partage créées par un même éditeur. Comme cela apparaîtra mieux avec les figures 4 à 6, ces zones peuvent être remplies dynamiquement et très simplement grâce à l'architecture de l'invention. Comme on l'a vu précédemment, les pages de partages suivent un prototype de 15 présentation ou squelette, ici figé, et l'éditeur vient "remplir" les zones en fonction de ses besoins. Cependant, l'éditeur peut être amené à créé plusieurs dizaines, voire des centaines de pages de partage. Dans ce contexte, il est intéressant de créer des profils d'éditeur sur le 20 serveur 8, dans lequel l'éditeur peut centraliser un certain nombre de données qui seront valables pour toutes les pages de partage qu'il crée, ce qui diminuera sa charge de travail. Ainsi, la figure 4 décrit une fonction de création/mise à jour d'un profil d'éditeur 25 permettant de centraliser ces informations. Dans l'exemple décrit ici, cette fonction est mise en oeuvre par une page web sur le serveur 8 (ou sur un autre serveur) à laquelle l'éditeur accède. C'est le programme de gestion 12 qui gère ces pages ainsi que les écritures et accès aux mémoires 18, 20 et 22. 30 Dans d'autres modes de réalisation, un programme pourra être exécuté localement sur une machine de l'éditeur, qui exécute les mêmes opérations que celles décrites avec la10 figure 4, et qui synchronise ces données avec le profil de l'éditeur sur le serveur 8 plus tard. Dans une opération 400, le profil d'éditeur U_Prof est créé. Lorsqu'un éditeur viendra 5 modifier plus tard son profil, cette opération sera une opération d'authentification, par exemple au moyen d'un couple nom d'éditeur/ mot de passe. Ensuite, dans une opération 402, l'éditeur a accès à une page qui lui permet de définir les données Pub_D de la zone Pub_Z. Comme cela a été décrit précédemment, ces données sont communes aux pages qui sont créées par l'éditeur, et elles permettent de l'identifier clairement, par exemple au moyen d'un logo et/ou d'un nom. 15 Dans l'exemple décrit ici, ces données comprennent un logo, que l'éditeur peut téléverser directement sur le serveur 8, ou indiquer par référence en donnant un lien d'un autre serveur sur lequel ce logo est accessible, ainsi que deux liens hypertextes. Le logo doit avoir une taille limitée par le schéma retenu pour la page partagée, comme 20 illustré sur la figure 3. Cela garantit que l'éditeur ne peut pas produire des pages déformées en téléversant un logo de taille trop importante. En variante, le serveur 8 peut comprendre une application qui redimensionne un logo lorsque celui-ci est trop grand. Les données d'image peuvent par exemple être stockées dans la mémoire 22. 25 Les deux liens hypertextes peuvent être personnalisés par l'éditeur pour guider un utilisateur vers des liens d'intérêt. Par exemple, l'un des liens peut être personnalisé pour guider l'utilisateur vers une page d'abonnement au contenu papier de l'éditeur, et l'autre lien peut emmener l'utilisateur vers une page qui permet de s'abonner à des flux d'informations concernant l'éditeur, comme un flux RSS ou une lettre d'information 30 électronique. D'une manière générale, ces deux liens sont deux liens de nature textuels choisis arbitrairement par l'éditeur. 10 Ensuite, dans une opération 404, l'éditeur peut définir des données Soc_D pour la zone Soc_Z. Les données Soc_Z vont porter sur les deux types de liens qui ont été décrits plus haut. De manière avantageuse, cette page pourra se présenter sous la forme d'une page de sélection où chaque réseau social est accompagné d'une icône d'identification de ce réseau et d'une case de type "bouton radio" ou "case à cocher" pour sélectionner le réseau correspondant. Une fois que l'éditeur a fait le choix de tous les éléments de partage via des réseaux sociaux ou la sauvegarde qu'il souhaite présenter, des identifiants de ces réseaux sont enregistrés dans le profil de l'éditeur. Ainsi, à chaque fois que la zone de partage Soc_Z sera activée dans une page de partage, celle-ci affichera la liste des icônes des réseaux sociaux sélectionnés par l'éditeur. Ces icônes seront elles-mêmes des liens hypertexte sur lesquels l'utilisateur pourra cliquer comme décrit plus haut. À partir de là, l'utilisateur pourra partager l'adresse de l'article faisant l'objet de la page de partage avec ses contacts, soit par envoi direct d'un message contenant cette adresse, soit par publication de cette adresse dans sa page de statut par exemple. Enfin, dans une opération 406, l'éditeur peut définir des données de catégorie de contenu. En effet, on a vu avec la figure 3 que la zone Cont _Z est dédiée à la liaison de contenus choisis par l'éditeur. 25 Ces contenus peuvent être de diverses natures : - photo, - vidéo, - forum, - commentaire, 30 - flux RSS, - offre spéciale liée à l'article, - etc.20 L'éditeur peut créer autant de catégories qu'il le souhaite. De manière optionnelle, certaines catégories peuvent être créées par défaut et ne peuvent pas être supprimées, par exemple "photo" et "vidéo". Dans la zone Cont Z, ces catégories apparaîtront lorsqu'elles sont prévues en tant que bouton d'un format prédéterminé, qui contient un texte décrivant le nom de la catégorie, et qui est un lien qui mène vers une adresse contenant le contenu associé à cette catégorie. Optionnellement, l'éditeur peut affecter une valeur par défaut à l'adresse associée à chacune des catégories. Ainsi, si l'une des catégories est un forum par exemple, l'éditeur pourra intégrer directement et automatiquement l'adresse de ce forum, sans avoir besoin de la recréer à chaque fois. Ensuite la création/modification de profil éditeur se termine dans une opération 408. Dans l'exemple qui vient d'être décrit, chaque opération est réalisée par une page web spécifique, ce qui permet de catégoriser les actions de l'éditeur, tout en gardant une taille raisonnable, qui évite une navigation complexe dans l'écran pour être sûr d'avoir rempli tous les champs nécessaires. Cependant, toutes ces opérations pourraient être regroupées sur une seule et unique page de formulaire. En outre, les opérations présentées ci-dessus pourraient être réalisées dans n'importe quel ordre. De même, toutes les opérations ne sont pas nécessaires à la création et/ou la modification d'un profil. Certaines pourront être omises en fonction des besoins de l'éditeur. La figure 5 décrit une fonction de création/mise à jour d'une page de partage par un éditeur. Dans l'exemple décrit ici, cette fonction est mise en oeuvre par une page web sur le serveur 8 (ou sur un autre serveur) à laquelle l'éditeur accède. Ici encore, c'est le programme de gestion 12 qui gère ces pages ainsi que les écritures et accès aux mémoires 18, 20 et 22. Dans d'autres modes de réalisation, un programme pourra être exécuté localement sur une machine de l'éditeur, qui exécute les mêmes opérations que celles décrites avec la figure 5, et qui synchronise ces données avec les données de page de partage sur le serveur 8 plus tard. Dans une opération 500, un profil de page de partage URL_D est créé. Lorsqu'un éditeur viendra modifier plus tard cette page de partage, cette opération sera une opération d'authentification, par exemple au moyen d'un couple nom d'éditeur/ mot de passe et saisie d'un identifiant de la page de partage (par saisie manuelle ou par sélection à la souris par exemple). Ensuite, dans une opération 502, l'éditeur saisit l'adresse à laquelle la page de partage sera accessible. Selon une première variante, l'adresse de la page de partage peut être un composite entre une adresse globale affectée à l'éditeur de type http://URL_Editeur/ et une adresse particulière que l'éditeur choisit pour la page de partage. Ce type de convention d'adresse présente plusieurs avantages. Tout d'abord, il permet d'offrir une certaine homogénéité aux pages de partage créées par l'éditeur. Cela signifie qu'un utilisateur pourra identifier l'éditeur non seulement par les données de la zone Pub Z, mais également par la première partie de l'adresse URL de la page de partage. 25 Ensuite, cela réduit la quantité de données que l'éditeur a besoin de rentrer pour créer une page de partage. Cela représente un gain de temps non négligeable (les URL peuvent prendre un temps conséquent à écrire du fait des caractères spéciaux qu'elles contiennent), mais également une sécurité, car les risques d'erreurs de frappe liées à la 30 première partie de l'URL sont éliminés.20 Enfin, cela permet un traitement facilité par le serveur lorsqu'il reçoit une requête d'accès à une page: cela rend possible d'aller directement chercher dans les pages de partages publiées par un éditeur donné au lieu de chercher dans l'ensemble de toutes les pages de partage créées. Dans d'autres variantes, il sera possible de permettre à l'éditeur de définir l'adresse de la page de partage, partiellement ou dans son intégralité. L'opération 502 est suivie d'une opération 504 dans laquelle l'éditeur peut définir des 10 données ArtD pour leur publication dans les zones Tit_Z et Art_Z. Les données Art]) peuvent comprendre d'une part des données de titre pour l'article, qui est affiché dans la zone Tit_Z, entre les données de la zone Art Z et les données de la zone Pub_Z, et d'autre part des données de l'article que l'éditeur souhaite présenter sur 15 la page de partage. Les données de l'article peuvent comprendre une image dont la taille est limitée par un cadre, de même similaire à ce qui est fait pour le logo de l'éditeur, un texte d'accompagnement et un lien hypertexte vers l'article lui-même. 20 Dans l'exemple décrit ici, cette image est une miniature de l'article qui fait l'objet de la page de partage. Cela permet de rassurer l'utilisateur quant à la page qu'il est sur le point de partager avec ses contacts. Cette miniature peut être générée automatiquement à la création de la page de partage par l'éditeur, ou être générée à chaque consultation par un 25 utilisateur. Bien sûr ces données ne sont pas toutes nécessaires, et le lien hypertexte seul peut suffire. Les données d'image peuvent par exemple être stockées dans la mémoire 22. Ensuite, dans une opération 506, l'éditeur peut définir des données Ext D pour le 30 remplissage de la zone Ext_Z. Généralement, ces données seront formées par une ou plusieurs adresses URL qui contiennent la désignation d'une régie publicitaire, ainsi qu'un identifiant de l'éditeur (optionnel) selon le mode de fonctionnement de la régie.5 Il va de soi que d'autres contenus peuvent être désignés par les adresses des données Ext_D, l'idée étant ici que ces données désignent un contenu que l'éditeur ne maîtrise pas forcément. Enfin, dans une opération 508, l'éditeur peut définir des données Conti) pour remplir la zone Cont_Z. Cette opération peut comprendre deux étapes : - dans une première étape, l'éditeur choisit les catégories de contenu qui doivent être 10 affichées pour la page de partage, - dans une deuxième étape, l'éditeur remplit le contenu des catégories qu'il a sélectionnées à la première étape En effet, ce contenu peut être varié en fonction de la page de partage considérée. La 15 première étape permet donc cette sélection, dont le choix de base correspond aux catégories de contenu définies dans le profil d'éditeur. Cette première étape peut également prévoir un nombre maximum de catégories, afin de préserver la lisibilité de la page de partage. Dans cette première étape, l'éditeur peut 20 également activer ou désactiver le contenu de la zone Soc_Z en cochant une case, selon que l'éditeur souhaite que l'utilisateur puisse partager la page ou pas. La deuxième étape consiste à préciser pour chacune des catégories sélectionnées à la première étape le lien hypertexte qui leur est associé, lorsque celui-ci n'est pas prédéfini 25 (voir opération 406). On notera que, grâce aux possibilités de code modernes, les deux étapes peuvent être réalisées sans recharger la page, ce qui et simplifie la tâche de l'éditeur et améliore l'ergonomie de la page. Enfin cette opération se termine en 510. 30 De manière similaire à la figure 4, chaque opération de l'exemple qui vient d'être décrit est réalisée par une page web spécifique, ce qui permet de catégoriser les actions de l'éditeur, tout en gardant une taille raisonnable, qui évite une navigation complexe dans l'écran pour être sûr d'avoir rempli tous les champs nécessaires. Cependant, toutes ces opérations pourraient être regroupées sur une seule et unique page de formulaire. En outre, les opérations présentées ci-dessus pourraient être réalisées dans n'importe quel ordre. De même, toutes les opérations ne sont pas nécessaires à la création et/ou la modification d'un profil. Certaines pourront être omises en fonction des besoins de l'éditeur. Maintenant que la structure des pages de partage apparaît clairement en correspondance du profil de l'éditeur qui les crée, la figure 6 va permettre de mieux comprendre comment l'accès à une page de partage est géré par le serveur 8. Dans une première opération 600, le serveur 8 reçoit la requête d'accès à une page de partage. Cette opération est le résultat de l'opération 202 de la figure 2. Ensuite, dans des opérations 602 à 606, nous allons décrire un exemple de mise en 20 oeuvre de la fonction Mk(Sh P) de l'opération 204. Dans l'opération 602, le pilote 10 appelle l'extracteur 13 du serveur 8 pour analyser la requête d'accès reçue à l'opération 600, qui en tire l'identifiant de profil d'éditeur (première partie de l'adresse URL de la requête) et l'identifiant de la page de partage 25 qui est visée par cette requête (deuxième partie de l'adresse URL de la requête). Ensuite, dans l'opération 604, le pilote 10 appelle le cribleur 14 du serveur 8 pour requêter la mémoire 20 de données de page de partage et chercher si l'identifiant de page de partage tiré de la requête y est présent. 30 Ensuite, si cet identifiant est trouvé, alors les données de page de partage correspondantes sont récupérées. Sinon, le cribleur 14 renvoie une information d'erreur qui est relayée jusqu'au dispositif émetteur 2 ou 4. Selon une première variante, le cribleur 14 peut déterminer l'identifiant de page de partage le plus proche de celui tiré de l'extracteur 13, ainsi que les données de page de partage correspondante. Selon une seconde variante, le cribleur 14 peut déterminer une pluralité d'identifiants de page de partage proches de celui tiré de l'extracteur 13, et demander à l'utilisateur de choisir parmi ces identifiants. Ces mêmes opérations sont également réalisées sur l'identifiant de profil d'éditeur dans la mémoire 18 pour récupérer les données de page de partage qui sont communes aux 15 pages de partage d'un même éditeur. Une fois que toutes les données concernant la page de partage sont récupérées, le pilote 10 traite les données de page de partage obtenues à l'opération 604 dans une opération 606. Pour cela, le pilote 10 va dans un premier temps déterminer s'il doit appeler le moteur 6 pour générer la page de partage ou non. Cette distinction peut par exemple être réalisée à partir de l'information « User Agent » que contient la requête de l'opération 600. 25 En effet, lorsque l'invention est mise en oeuvre à partir d'un dispositif mobile comme un téléphone portable, celui-ci peut contenir une application spécifique à la consultation des pages de partage de l'invention, de sorte qu'il n'est pas nécessaire de mettre en forme les données de l'opération 606, sinon en les rassemblant dans le fichier ShPDat, et en les envoyant au dispositif requêteur dans une opération 608. 20 30 Dans ce cas, l'application sur le téléphone mobile comprend un moteur adapté à recevoir les données ShPDat sous forme brute, et à afficher la page de partage correspondante conformément au schéma de la figure 3. Pour cela, ce moteur utilise des données de structure de page de partage qui forment un canevas correspondant à la figure 3, et génère la page de partage en y introduisant les données de page de partage ShPDat mentionnées au paragraphe précédent. Dans l'exemple décrit ici, ces données sont stockées dans la mémoire 22. Dans l'exemple décrit ici, le canevas de la page de partage est en langage en XML. Ce canevas décrit des cadres pour chaque zone décrite plus haut. Ces cadres définissent des classes de contenu identifiés. De manière similaire, les données de page de partage tirée des mémoires 18, 20 sont également en langage XML, et comportent des identifiants correspondant à ceux des classes du canevas. Ainsi, ces éléments sont intégrés dans les zones leur correspondant quand le moteur les intègre au canevas. Cela est particulièrement avantageux pour plusieurs raisons. Tout d'abord, cet environnement permet de réduire la quantité de données qui est transmise au dispositif, ce qui est avantageux en termes de coût et de temps de traitement. 25 En outre, comme c'est l'application sur le dispositif elle-même qui se charge de rendre la page de partage. En conséquence, il n'y a qu'une seule application à maintenir à jour et à adapter par système d'exploitation. Cela est avantageux quand on connaît l'étendue des divergences de traitement du code 30 HTML par les divers navigateurs Web du marché. C'est d'autant plus vrai que le moteur de l'application n'a besoin de rendre qu'un seul type de page, et qu'il est donc peu complexe.20 Lorsque le pilote 10 détermine que la requête de l'opération 600 provient d'un navigateur Web, alors il appelle le moteur 16 pour générer la page de partage, de manière similaire à ce qui a été décrit pour le moteur du téléphone mobile. Les données ShPDat sont alors constituées par la page de partage elle-même. Enfin, une fois que le moteur 16 a construit la page de partage correspondant à la requête de l'opération 600, le pilote 10 renvoie cette page vers le dispositif qui a émis la requête pour consultation dans l'opération 608. 10 La figure 7 montre une variante de canevas pour la page de partage qui est plus adaptée pour une consultation sur un ordinateur ou une tablette. Pour cela, le serveur 8 stocke des données de structure de page de partage pour chaque canevas. Le moteur 16 pourra par exemple déterminer le canevas à appliquer en 15 fonction de l'information « User Agent » que contient la requête de l'opération 600. Cela peut être réalisé lors de l'opération 606 par exemple. Ainsi, si l'information « User Agent» indique par exemple que la requête provient du navigateur Web d'une tablette, alors le moteur 16 pourra générer la page de partage adaptée. Dans ce cas, la requête de l'opération 600 peut être émise par le navigateur Web, en entrant la chaîne de texte 20 correspondant à la page de partage dans la barre d'adresse de celui-ci.5 Revendications1. Système informatique, agencé pour accéder à un réseau étendu, caractérisé en ce qu'il comprend : - une mémoire (20) stockant des données de page de partage, - une mémoire (22) stockant des données de structure de page de partage, - une mémoire (18) stockant des données de profil d'éditeur, - un extracteur (13), agencé pour recevoir une requête d'accès et pour en tirer un identifiant de page de partage et un identifiant de profil d'éditeur, - un cribleur (14) agencé pour tirer des données de page de partage à partir d'un identifiant de page de partage, - un moteur (16) agencé pour générer une page de partage à partir de données de structure de page de partage, de données de page de partage, et de données de profil d'éditeur, et - un pilote (10), agencé pour recevoir une requête d'accès d'un élément du réseau étendu, pour appeler le cribleur (14) avec l'identifiant de page de partage et l'identifiant de profil d'éditeur déterminés par l'extracteur (13), pour appeler le moteur (16) avec les données résultantes et les données de structure de page de partage, et pour renvoyer la page résultante audit élément du réseau étendu. 2. Système informatique selon la revendication 1, comprenant en outre un programme de gestion (12) agencé pour permettre à un éditeur de définir des données de profil d'éditeur pour stockage dans la mémoire (18) de données de profil d'éditeur. 3. Système informatique selon la revendication 2, dans lequel les données de profil d'éditeur comprennent des données choisies parmi le groupe comprenant des données d'image d'éditeur, des données de nom d'éditeur, des données de sites de réseaux sociaux, et des données de catégorie. 4. Système informatique selon l'une des revendications 1 à 3, dans lequel le programme de gestion (12) est en outre agencé pour permettre à un éditeur de définir des données de page de partage pour stockage dans la mémoire (20) de données de page de partage. 5. Système informatique selon la revendication 4, dans lequel les données de page de partage comprennent des données choisies parmi le groupe comprenant des données 19de titre, des données d'article, des données de catégorie, des données de partage, des données externes et des données de contenu. 6. Système selon la revendication 5, dans lequel certaines au moins des données de page de partage comprennent un lien hypertexte associé à un texte et/ou à une image d'affichage. 7. Environnement informatique comprenant un système informatique selon l'une des revendications précédentes et un dispositif informatique comprenant un module de reconnaissance de texte, et une interface de communication réseau, ainsi qu'une application agencée pour appeler le système informatique via ladite interface de communication réseau avec une requête d'accès à une page de partage, la requête comprenant des données tirées dudit module de reconnaissance de texte. 8. Environnement informatique selon la revendication 7, dans lequel le dispositif comprend en outre un module d'acquisition de données d'image, et dans lequel ladite application est agencée pour appeler ledit module de reconnaissance de texte avec des données d'image tirées dudit module d'acquisition de données d'images pour générer la requête d'accès à une page de partage. 9. Environnement informatique selon la revendication 8, dans lequel les données d'image sont tirées d'un magazine papier. 10. Environnement informatique selon la revendication 9, dans lequel l'application comprend un moteur agencé pour générer une page de partage à partir de données de page de partage, et dans lequel le pilote (10) est agencé pour recevoir une requête d'accès d'un élément du réseau étendu, pour appeler le cribleur (14) avec l'identifiant de page de partage et l'identifiant de profil d'éditeur déterminés par l'extracteur (13), et pour renvoyer les données résultantes audit dispositif sans appeler le moteur (16).