Brevet FR2950214A1 — publié le 20110318

PROCEDE DE DEMANDE DE VERIFICATION DE DONNEES PROFIL UTILISATEUR D'UN SITE DE RESEAU SOCIAL DOMAINE TECHNIQUE DE L'INVENTION La présente invention concerne un procédé de demande de vérification de données profil utilisateur d'un site de réseau social et un procédé de vérification de données profil utilisateur d'un site de réseau social. L'invention concerne également un agent client permettant de mettre en oeuvre ledit procédé de demande de vérification, et un agent serveur permettant de mettre en oeuvre ledit procédé de vérification. Elle trouve une application particulière, mais non exclusive, dans le domaine des systèmes de réseau de communication pour site de réseau social. ARRIÈRE-PLAN TECHNOLOGIQUE DE L'INVENTION Dans le domaine des systèmes de réseau de communication pour site de réseau social, il existe des interfaces de programmation applicative, dite API, qui sont de plus en plus utilisées pour les sites de réseau social, jusqu'à être devenues des standards de facto. Tel est le cas de l'API OpenSocialTM Cette interface permet à des développeurs de créer des applications dites sociales et qui peuvent être utilisées sur n'importe quel site de réseau social, appelés SNS (« Social Networking Site » en anglais), compatible avec cette API. Cette API permet d'accéder à des données profil utilisateurs telles que des données relatives aux amis, activités, animaux de compagnie, etc....en relation avec le réseau social établi par le site de réseau social. Un inconvénient de ces API est que de telles données ne sont pas vérifiables par les développeurs qui veulent les utiliser dans des applications qui sont utilisables avec le site de réseau social. Seule l'autorité de gestion du site de réseau social peut les vérifier à partir d'une vérification de la carte d'identité d'un utilisateur par exemple. Dans ce cas, elle valide certaines données du profil utilisateur sur la base de données du site de réseau social. Ces données sont alors certifiées. DESCRIPTION GENERALE DE L'INVENTION La présente invention a pour but un procédé de demande de vérification de données profil utilisateur d'un site de réseau social qui permet de résoudre le problème posé ci-dessus. Ce but est atteint par un procédé de demande de vérification de données profil utilisateur d'un site de réseau social selon lequel il comporte les étapes de : - à partir d'un agent client, lancer une demande de vérification de données profil utilisateur, la demande de vérification comprenant un indicateur de vérification de données profil utilisateur ; - à partir dudit agent client, envoyer une requête correspondant à ladite demande de vérification à un agent serveur gestionnaire du site de réseau social, la requête comprenant ledit indicateur de vérification de données profil utilisateur et étant générée à partir d'une bibliothèque client/serveur ; - à partir dudit agent client, recevoir dudit agent serveur un message de retour comprenant les données profil utilisateur dont au moins une donnée profil utilisateur est accompagnée d'un marqueur de vérification représentatif d'une certification de ladite donnée profil utilisateur par le site de réseau social si ladite donnée profil utilisateur est certifiée. Comme on va le voir en détail par la suite, ce procédé va permettre d'interroger le site de réseau social sur les données profil utilisateur de manière à savoir si elles ont été certifiées ou non par ledit site. Selon des modes de réalisation non limitatifs, le procédé peut comporter en outre une ou plusieurs caractéristiques supplémentaires parmi les suivantes : - L'agent client reçoit une pluralité de données profil utilisateur accompagnées chacune d'un marqueur de vérification si elles sont certifiées. - La demande de vérification est compatible avec l'interface de programmation applicative OpenSocialTM. Le procédé peut ainsi être utilisé sur des réseaux sociaux utilisant cette interface. - Une propriété d'intégrité est associée au message de retour. Cela permet de vérifier qu'il n'a pas été modifié par une tierce partie. En outre, il est également proposé un procédé de vérification de données profil utilisateur d'un site de réseau social, selon lequel il comporte les étapes de : à partir d'un agent serveur gestionnaire du réseau social en ligne, recevoir une requête correspondant à une demande de vérification de données profil utilisateur lancée par un agent client, la requête comprenant un indicateur de vérification de données profil utilisateur et étant générée à partir d'une bibliothèque client/serveur ; - à partir dudit agent serveur, interpréter ledit indicateur de vérification dans ladite requête et vérifier dans une base de données du site de réseau social si les données profil utilisateur ont été certifiées ; et - transmettre audit agent client un message de retour comprenant les données profil utilisateur dont au moins une donnée profil utilisateur est accompagnée d'un marqueur de vérification représentatif d'une certification de ladite donnée profil utilisateur par le site de réseau social si ladite donnée profil utilisateur est certifiée. Selon un mode de réalisation non limitatif, le procédé peut comporter en outre la caractéristique supplémentaire suivante : - L'étape d'interprétation de l'indicateur de vérification est effectuée par une injection de dépendance d'une instance d'un élément de gestion de requêtes clients d'un moteur d'exécution de l'agent serveur. Cela permet de choisir quel élément de gestion utiliser en fonction de la présence ou non de l'indicateur de vérification de données profil utilisateur. En outre, il est également proposé un agent client pour site de réseau social apte à coopérer avec un agent serveur et apte à demander une vérification des données profil utilisateur d'un site de réseau social, selon lequel il est apte à : - lancer une demande de vérification de données profil utilisateur, la demande de vérification comprenant un indicateur de vérification de données profil utilisateur ; - envoyer une requête correspondant à ladite demande de vérification à un agent serveur gestionnaire du site de réseau social, la requête comprenant ledit indicateur de vérification de données profil utilisateur et étant générée à partir d'une bibliothèque client/serveur ; - recevoir dudit agent serveur un message de retour comprenant les données profil utilisateur dont au moins une donnée profil utilisateur est accompagnée d'un marqueur de vérification représentatif d'une certification de ladite donnée profil utilisateur par le site de réseau social si ladite donnée profil utilisateur est certifiée. Selon un premier mode de réalisation non limitatif, l'agent client est un navigateur web. Selon un deuxième mode de réalisation non limitatif, l'agent client est un gadget compatible avec une interface de programmation applicative OpenSocialTM En outre, il est également proposé un agent serveur pour site de réseau social apte à coopérer avec un agent client et apte à vérifier des données profil utilisateur d'un site de réseau social, selon lequel il est apte à : - recevoir une requête correspondant à une demande de vérification de données profil utilisateur lancée par un agent client, la requête comprenant un indicateur de vérification de données profil utilisateur et étant générée à partir d'une bibliothèque client/serveur ; - interpréter ledit indicateur de vérification dans ladite requête et vérifier dans une base de données du site de réseau social si les données profil utilisateur ont été certifiées ; et - transmettre audit agent client un message de retour comprenant les données profil utilisateur dont au moins une donnée profil utilisateur est accompagnée d'un marqueur de vérification représentatif d'une certification de ladite donnée profil utilisateur par le site de réseau social si ladite donnée profil utilisateur est certifiée. En outre, il est également proposé un système de réseau de communication pour site de réseau social comprenant au moins un agent client selon l'une des caractéristiques précédentes et un agent serveur gestionnaire du site de réseau social selon la caractéristique précédente, l'agent client et l'agent serveur étant aptes à coopérer entre eux pour vérifier des données profil utilisateur dudit site de réseau social. L'invention et ses différentes applications seront mieux comprises à la lecture de la description qui suit et à l'examen des Figs. qui l'accompagnent. BREVE DESCRIPTION DES FIGURES Celles-ci ne sont présentées qu'à titre indicatif et nullement limitatif de l'invention. - La Fig.1 est un schéma simplifié d'un exemple non limitatif d'un système de réseau de communication pour site de réseau social comprenant au moins un agent client et un agent serveur gestionnaire du site de réseau social dans lesquels le procédé de demande de vérification de données utilisateur et le procédé de vérification de données utilisateur selon l'invention sont mis en oeuvre respectivement - La Fig.2 est un organigramme simplifié d'un mode de réalisation non limitatif du procédé de demande de vérification de données profil utilisateur selon l'invention ; - La Fig.3 est un organigramme simplifié d'un mode de réalisation non limitatif du procédé de vérification de données profil utilisateur selon l'invention ; - La Fig.4 est un organigramme simplifié d'un mode de réalisation non limitatif de l'ensemble des procédés de la Fig. 2 et de la Fig. 3 ; - La Fig.5 illustre schématiquement des échanges de requête et message entre un agent serveur et un agent client selon les étapes illustrées à la Fig. 4 ; et - La Fig.6 illustre schématiquement un système de réseau de communication pour site de réseau social comprenant un agent client et un agent serveur aptes à effectuer respectivement les étapes du procédé demande de vérification de données profil utilisateur de la Fig. 2 et les étapes du procédé de vérification de données profil utilisateur de la Fig. 3. DESCRIPTION DE MODES DE REALISATION DE L'INVENTION Un système de réseau de communication SYS pour site de réseau social OPS est illustré dans un exemple de réalisation non limitatif à la Fig. 1 Dans cet exemple, le système de réseau de communication SYS comprend : - au moins un agent client AC comprenant une bibliothèque client/serveur RPCLIB (décrite plus loin) ; - un site de réseau social OPS, le site de réseau social comprenant une base de données (« data repository » en anglais) BDD ; et - un agent serveur AS gestionnaire du site de réseau social OPS, l'agent serveur AS comprenant un moteur d'exécution SHIND ; Dans un premier mode de réalisation non limitatif, un agent client AC est un navigateur web NAV. Dans un deuxième mode de réalisation non limitatif, un agent client AC est un gadget GADG (décrit plus loin) compatible avec une interface de programmation applicative, dite API, du site de réseau social OPS. Dans un exemple non limitatif, l'API est OpenSocialTM. On notera qu'un gadget GADG est lancé à partir d'un navigateur web NAV. Ainsi, en général, le système de réseau de communication SYS comprend une pluralité d'agents clients AC. Par souci de simplification, la Fig. 1 n'illustre qu'un seul agent client AC (que ce soit le navigateur web NAV ou un gadget GADG). Le procédé PROC1 de demande de vérification de données profil utilisateur DUP d'un site de réseau social OPS, est décrit dans un mode de réalisation non limitatif à la Fig. 2, et le procédé PROC2 de vérification de données profil utilisateur DUP d'un site de réseau social OPS, est décrit dans un mode de réalisation non limitatif à la Fig. 3. Ils sont mis en oeuvre respectivement dans un agent client AC et dans un agent serveur AS, l'agent client AC et l'agent serveur AS étant aptes à coopérer entre eux pour vérifier des données profil utilisateur DUP dudit site de réseau social. On notera qu'on entend par vérification le fait de vérifier si des données profil utilisateur DUP ont été certifiées par le site de réseau social OPS. Le procédé PROC1 de demande de vérification de données profil utilisateur DUP d'un site de réseau social OPS comporte, tel qu'illustré sur la Fig. 2, les étapes de : - à partir d'un agent client AC, lancer une demande D_VERIF de vérification de données profil utilisateur DUP, la demande de vérification comprenant un indicateur de vérification FLG de données profil utilisateur (étape F1(D_VERIF(FLG)) ; - à partir dudit agent client AC, envoyer une requête RQ correspondant à ladite demande de vérification D_VERIF à un agent serveur AS gestionnaire du site de réseau social OPS, la requête comprenant ledit indicateur de vérification FLG de données profil utilisateur DUP et étant générée à partir d'une bibliothèque client/serveur RPCLIB (étape TX_RQ(FLG)) ; - à partir dudit agent client AC, recevoir dudit agent serveur AS un message de retour MSG comprenant les données profil utilisateur DUP dont au moins une donnée profil utilisateur DUP est accompagnée d'un marqueur de vérification M représentatif d'une certification de ladite donnée profil utilisateur DUP par le site de réseau social OPS si ladite donnée profil utilisateur est certifiée (étape RX_MSG(DUP, M)). 7 On notera qu'on entend par certification par le site de réseau social, le fait que le site de réseau social OPS (en pratique l'autorité de gestion du site) certifie qu'une donnée est véridique. Selon un mode de réalisation non limitatif, l'agent client AC reçoit une pluralité de données profil utilisateur DUP accompagnées chacune d'un marqueur de vérification M si elles ont été certifiées. Par ailleurs, le procédé PROC2 de vérification de données profil utilisateur DUP d'un site de réseau social OPS, comporte, tel qu'illustré sur la Fig. 3, les étapes de : - à partir d'un agent serveur AS gestionnaire du site de réseau social, recevoir une requête RQ correspondant à une demande de vérification D_VERIF de données profil utilisateur DUP lancée par un agent client AC, la requête comprenant un indicateur de vérification FLG de données profil utilisateur et étant générée à partir d'une bibliothèque client/serveur RPCLIB (étape RX_RQ(FLG)) ; - à partir dudit agent serveur AS, interpréter ledit indicateur de vérification FLG dans ladite requête RQ et vérifier dans une base de données BDD du site de réseau social OPS si les données profil utilisateur DUP ont été certifiées (étape F2(N_PERSONHANDLR) et étape VEFIF_BDD(DUP)); et - transmettre audit agent client AC un message de retour MSG comprenant les données profil utilisateur DUP dont au moins une donnée profil utilisateur DUP est accompagnée d'un marqueur de vérification M représentatif d'une certification de ladite donnée profil utilisateur DUP par le site de réseau social OPS si ladite donnée profil utilisateur est certifiée (étape TX_MSG(DUP, M, SIC N)). Dans un mode de réalisation non limitatif, l'étape d'interprétation de l'indicateur de vérification FLG est effectuée par une injection de dépendance d'une instance d'un élément de gestion de requêtes clients (dédié aux profils utilisateurs) N_PERSONHANDLR d'un moteur d'exécution SH I N D de l'agent serveur AS. Ainsi, quand un utilisateur du site de réseau social OPS veut accéder, via un ordinateur par exemple, à des données profil utilisateur du site de réseau social, telles que par exemple, la liste des profils utilisateur de ses amis, il se connecte dans un exemple non limitatif via un navigateur web (par exemple www.ops.com) pour accéder au site de réseau social OPS, et demande la liste de ses amis. Dans un mode de réalisation non limitatif, la demande s'effectue via un gadget GADG qui comporte une interface utilisateur (non représentée) prévue à cet effet. On notera qu'un gadget GADG est un fichier XML qui comporte un code JavaScript du gadget et des métadonnées telles que notamment le nom de l'auteur du gadget, le nom du gadget, le(s) bibliothèque(s) client/serveur RPCLIB à utiliser. On notera qu'un gadget sous forme de fichier XML avec un code JavaScript étant bien connu de l'homme du métier, il n'est pas décrit plus en détail ici. A ce moment, en se référant à la Fig. 4 et à la Fig. 5, les étapes suivantes sont effectuées. Dans une première étape 1), l'agent client AC lance une demande D_VERIF de vérification de données profil utilisateur DUP, la demande de vérification comprenant un indicateur de vérification FLG de données profil utilisateur. Ainsi, dans le mode de réalisation non limitatif du gadget GADG décrit précédemment, le gadget GADG comprend ladite demande de vérification D VERIF. Selon un mode de réalisation non limitatif, la demande de vérification D_VERIF est compatible avec l'interface de programmation applicative OpenSocialTM Dans un mode de réalisation non limitatif, la demande de vérification D VERIF se base sur un composant connu de l'API OpenSocialTM nommé opensocial.DataRequest.newFetchPersonRequest dans lequel on ajoute un paramètre supplémentaire qui est l'indicateur de vérification FLG de données profil utilisateur DUP. En pratique, ce paramètre supplémentaire fera partie des paramètres opt_params du composant opensocial.DataRequest.newFetchPersonRequest(idSpec, opt_params). Ainsi, on pourrait nommer la demande D_VERIF, NewCheckPersonRequest par exemple. Dans un exemple non limitatif, l'indicateur de vérification FLG est un booléen qui est donc positionné ici à vrai afin que les données profil utilisateur demandées soit vérifiées. Ainsi, le lancement de la demande D_VERIF de vérification de données profil utilisateur DUP déclenche la seconde étape ci-dessous. On notera que dans le cas où l'agent client AC est un gadget GADG compatible avec l'API OpenSocialTM, et qui peut être lancé à partir d'un navigateur web, alors le site de réseau social OPS comporte un composant conteneur qui est apte à transformer le gadget en un code exécutable et compréhensible par le navigateur web. Ce principe de composant conteneur étant bien connu de l'homme du métier, il n'est pas décrit en détail ici. Dans une deuxième étape 2), l'agent client AC envoie une requête RQ correspondant à ladite demande de vérification D_VERIF à l'agent serveur AS gestionnaire du site de réseau social OPS, la requête comprenant ledit indicateur de vérification d'informations FLG et étant générée à partir de la bibliothèque client/serveur RPCLIB. On notera que la bibliothèque client/serveur RPCLIB est une bibliothèque de dialogue client/serveur qui permet de mettre en forme la demande de vérification D_VERIF en une requête RQ en utilisant un protocole de communication préétabli (ici un protocole d'appel de procédures à distance) entre l'agent client AC et l'agent serveur AS. Dans un mode de réalisation non limitatif, la requête RQ est une requête HTTP POST. Le dialogue « à l'aller » agent client AC/agent serveur AS s'effectue ainsi via le protocole de communication http («HyperTexTransfer Protocol» en anglais) bien connu de l'homme du métier. Cela permet d'utiliser un protocole connu et couramment utilisé. Dans un exemple non limitatif illustratif, le contenu de la requête RQ utilise le format json (« JavaSript Object Notation » en anglais) bien connu de l'homme du métier, et est de la forme suivante : POST /rpc HTTP/1.1 Host : api.ops.com Authorization: Content-type: application/json { "method":" people.get", "id":"moi" "params": { "userlD:@me", "groupld":"@self", "FLG":vrai } } On notera que la méthode « people.get » est une commande envoyée à l'agent serveur AS qui permet de récupérer les données profils utilisateurs. Ainsi, la requête POST contient le message à destination de l'agent serveur AS d'exécuter la méthode « people.get » sur ledit agent serveur AS. Dans une troisième étape 3), l'agent serveur AS reçoit la requête RQ correspondant à une demande de vérification D_VERIF de données profil utilisateur DUP lancée par un agent client AC, la requête comprenant ledit indicateur de vérification d'informations FLG et étant générée à partir de la bibliothèque client/serveur RPCLIB. Dans une quatrième étape 4), l'agent serveur AS interprète ledit indicateur de vérification FLG dans ladite requête RQ et dans une cinquième étape 5) il vérifie dans une base de données BDD du site de réseau social OPS si les données profil utilisateur DUP ont été certifiées. L'interprétation dudit indicateur de vérification FLG est effectuée par le moteur d'exécution SHIND de l'agent serveur AS. Dans un exemple non limitatif, le moteur d'exécution est un moteur ShindigTM compatible avec l'API OpenSocialTM Dans un mode de réalisation non limitatif, l'étape d'interprétation de l'indicateur de vérification FLG est effectuée par une injection de dépendance d'une instance d'un élément de gestion de requêtes clients N_PERSONHANDLR du moteur d'exécution SHIND de l'agent serveur AS. L'injection de dépendance est un modèle de conception (« design pattern » en anglais) qui permet de choisir quelle instanciation de requêtes clients N_PERSONHANDLR on utilise lorsque l'indicateur de vérification FLG est présent ou non dans la requête RQ. A cet effet, il suffit de mettre à jour un fichier de configuration FCONF dans lequel on indique quel est l'instance de l'élément de gestion de requêtes clients N_PERSONHANDLR à utiliser en présence ou en l'absence de l'indicateur de vérification FLG dans la requête RQ. Ainsi, cela évite de recompiler tout le code du moteur d'exécution SHIND. Dans un exemple non limitatif, lorsque le moteur d'exécution SHIND utilisé est ShindigTM, le fichier de configuration FCONF associé est web.xml et l'injection de dépendance est effectuée en pratique par l'atelier de développement (« framework » en anglais) GuiceTM Par ailleurs, l'élément de gestion de requêtes clients N_PERSONHANDLR permet d'analyser des requêtes RQ concernant des demandes de données profil utilisateur DUP et les redistribue vers des sous-éléments (non représentés) qui vont récupérer lesdites données profil utilisateur DUP dans la base de données BDD du site de réseau social OPS. Dans un mode de réalisation non limitatif, l'élément de gestion de requêtes clients N_PERSONHANDLR est compatible avec l'interface de programmation applicative OpenSocialTM. Dans ce mode, dans un exemple de réalisation non limitatif, l'élément de gestion de requêtes clients N_PERSONHANDLR est un composant nommé PersonHandlerTM On notera qu'il existe une mise en correspondance (« mapping » en anglais) entre les données profil utilisateur de la requête RQ et celles inscrites dans la base de données BDD. Ce « mapping » sera effectué au moyen par exemple d'un fichier de « mapping » (non représenté). Cela permet au serveur de réseau social d'utiliser une dénomination physique pour les données profil utilisateur DUP différente de la dénomination logique desdites données au niveau des agents clients AC. Ainsi, cela évite les interdépendances. Dans une sixième étape 6), l'agent serveur AS transmet audit agent client AC un message de retour MSG comprenant les données profil utilisateur DUP dont au moins une donnée profil utilisateur DUP est accompagnée d'un marqueur de vérification M représentatif d'une certification de ladite donnée profil utilisateur DUP par le site de réseau social OPS si ladite donnée profil utilisateur est certifiée. Dans un premier mode de réalisation non limitatif, lorsqu'une donnée profil utilisateur a été certifiée par le site de réseau social OPS, alors elle est accompagnée d'un marqueur de vérification M. Dans le cas contraire, il n'y a aucun marqueur M. Dans un exemple non limitatif, le marqueur de vérification M est un marqueur de vérification logique. Par exemple pour une donnée profil utilisateur tel que l'âge, si l'âge a été certifié, le marqueur logique de vérification M est AgeVérifié = vrai. Dans un deuxième mode de réalisation non limitatif, lorsqu'une donnée profil utilisateur a été certifiée par le site de réseau social OPS, alors elle est accompagnée d'un marqueur de vérification M. Dans le cas contraire, elle est également accompagnée d'un marqueur de vérification M. Dans un exemple non limitatif, le marqueur de vérification M est un marqueur logique. Par exemple pour une donnée profil utilisateur tel que le nom, si le nom a été certifié, le marqueur de vérification logique M est NomVérifié = vrai. Par contre, dans le cas contraire, le marqueur de vérification logique M est NomVérifié = faux. On notera que dans un mode de réalisation non limitatif, le message de retour MSG est un message HTTP. Le dialogue « de retour » agent client AC/agent serveur AS s'effectue ainsi via le protocole de communication http bien connu de l'homme du métier. Cela permet d'utiliser un protocole connu et couramment utilisé. Ainsi, dans un exemple non limitatif illustratif, le contenu du message de retour HTTP_M utilise le format json (« JavaScript Object Notation » en anglais) bien connu de l'homme du métier, et est de la forme suivante : HTTP/1.X Multi-Status Content-type: application/json { "id":"moi" "result": { "id" : "ops.com:34KJD394", "nom": {"non structurée": "Doe"}, "NomVérifié":vrai, "Genre": "féminin" "GenreVérifé":vrai " Age " : "30" } } Avec « id » correspondant à une clef unique pour un profil utilisateur. Ainsi, dans cet exemple non limitatif, on peut voir que les données Nom et le Genre ont été certifiées par le site de réseau social OPS, tandis que la donnée Age n'a pas été certifiée. 30 Par ailleurs, dans un mode de réalisation non limitatif, une propriété d'intégrité SIGN est associée au message de retour MSG. Cela permet à l'agent client AC de vérifier que ledit message de retour MSG envoyé par l'agent serveur AS n'a pas été modifié par une tierce partie. Dans un exemple de réalisation non limitatif, la propriété d'intégrité SIGN est une 35 signature avec une clef publique/clef privée. Le processus de signature étant25 bien connu de l'homme du métier, il n'est pas décrit ici. Dans une septième étape 7), l'agent client AC reçoit dudit agent serveur AS le message de retour MSG comprenant les données profil utilisateur DUP (ci-dessus) dont au moins une donnée profil utilisateur DUP est accompagnée d'un marqueur de vérification M représentatif d'une certification de ladite donnée profil utilisateur DUP par le site de réseau social OPS si ladite donnée profil utilisateur est certifiée. Ainsi, les étapes décrites permettent de vérifier que des données profil utilisateur DUP ont bien été certifiées par le site de réseau social OPS, et plus précisément par l'autorité de certification gestionnaire du site de réseau social OPS. Il suffit par la suite d'établir un test sur la présence ou non d'un marqueur de vérification M pour chaque donnée profil utilisateur, ou de la valeur dudit marqueur M. Ainsi, dans un exemple non limitatif, selon le résultat de ce test, on peut envoyer un message à l'utilisateur du navigateur web pour lui dire que la donnée a bien été certifiée ou non. On notera que dans le cas où le lancement de la demande de vérification D VERIF se fait au moyen d'un gadget GADG, ce test peut être intégré dans ledit gadget GADG. Le procédé PROC1 de demande de vérification de données profil utilisateur DUP et le procédé PROC2 de vérification de données profil utilisateur DUP sont mis en oeuvre respectivement dans un agent client AC et dans un agent serveur AS. Ainsi, un agent client AC pour site de réseau social OPS apte à coopérer avec un agent serveur AS et à demander une vérification des données profil utilisateur DUP d'un site de réseau social OPS, est apte à : - lancer une demande D_VERIF de vérification de données profil utilisateur DUP, la demande de vérification comprenant un indicateur de vérification FLG de données profil utilisateur ; - envoyer une requête RQ correspondant à ladite demande de vérification D_VERIF à un agent serveur AS gestionnaire du site de réseau social OPS, la requête comprenant ledit indicateur de vérification FLG de données profil utilisateur DUP et étant générée à partir d'une bibliothèque client/serveur RPCLIB ; - recevoir dudit agent serveur AS un message de retour MSG comprenant les données profil utilisateur DUP dont au moins une donnée profil utilisateur DUP est accompagnée d'un marqueur de vérification M représentatif d'une certification de ladite donnée profil utilisateur DUP par le site de réseau social OPS si ladite donnée profil utilisateur est certifiée. Par ailleurs, l'agent serveur AS pour site de réseau social OPS apte à coopérer avec un agent client AC et à vérifier des données profil utilisateur DUP d'un site de réseau social OPS, est apte à : - recevoir une requête RQ correspondant à une demande de vérification D_VERIF de données profil utilisateur DUP lancée par un agent client AC, la requête comprenant un indicateur de vérification FLG de données profil utilisateur DUP et étant générée à partir d'une bibliothèque client/serveur RPCLIB ; - interpréter ledit indicateur de vérification FLG dans ladite requête RQ et vérifier dans une base de données BDD du site de réseau social OPS si les données profil utilisateur DUP ont été certifiées ; et - transmettre audit agent client AC un message de retour MSG comprenant les données profil utilisateur DUP dont au moins une donnée profil utilisateur DUP est accompagnée d'un marqueur de vérification M représentatif d'une certification de ladite donnée profil utilisateur par le site de réseau social OPS si ladite donnée profil utilisateur est certifiée. Bien entendu la description n'est pas limitée à l'application, aux modes de réalisation et aux exemples décrits ci-dessus. - Ainsi, dans un mode de réalisation non limitatif, la transmission du message de retour MSG est effectuée par le protocole sécurisé https (« HyperTextTransfer Protocol Secured » en anglais). Cela évite qu'une tierce partie qui aurait accès frauduleusement au réseau local de l'agent client AC ne vienne altérer le contenu du message de retour MSG avant qu'il n'arrive à l'agent client AC. Elle ne pourra pas non plus lire le contenu dudit message, le message étant crypté. - En outre, dans un autre mode de réalisation non limitatif, au lieu d'utiliser une demande D_VERIF de données profil utilisateur DUP basée sur une interface JavaScript, telle qu'une demande NewFetchCheckPerson décrite précédemment, on peut utiliser une demande de données profil utilisateur DUP basée sur une interface différente, telle que l'interface REST (« Representational State Transfer » en anglais). Cette interface se base également sur le protocole de communication HTTP et utilise des URI (« Uniform Resource Identifier » en anglais). Dans ce cas, la demande est une URI de la forme http//www.ops.org/people/identifiantutilisateur/amis?FLG, dans un exemple non limitatif, ladite URI comportant également un indicateur de vérification FLG de données profil utilisateur DUP. Cette URI permet d'accéder à une ressource « amis » de l'utilisateur dont l'identifiant est donné dans l'URI. Cette demande de vérification de données profil utilisateur DUP est alors transformée en une requête correspondante RQ, qui est ici une requête HTTP GET et qui est envoyée à l'agent serveur AS. Une telle requête étant bien connue de l'homme du métier, elle n'est pas décrite ici. L'agent serveur AS renvoie un message de retour MSG qui est une représentation de la ressource demandée « amis » indiquant sous quelle forme sont les données qui suivent (ici les profils des amis), par exemple sous la forme d'une page XML ou de données JSON. Tel que décrit précédemment, le message retour MSG comprend au moins une donnée profil utilisateur DUP accompagnée d'un marqueur de vérification M représentatif d'une certification de ladite donnée profil utilisateur par le site de réseau social si ladite donnée profil utilisateur est certifiée. On notera que l'interface REST étant bien connue de l'homme du métier, elle n'est pas décrite plus en détail ici. - Par ailleurs, dans un autre mode de réalisation non limitatif, l'agent client AC peut être un programme autonome, dit « stand-alone » en anglais, qui peut être directement exécuté par le système d'exploitation de l'ordinateur sur lequel un utilisateur demande les profils utilisateur de ses amis par exemple. Ce programme autonome utilise par exemple l'interface REST compatible avec l'API OpenSocialTM décrit ci-dessus pour dialoguer directement avec l'agent serveur AS. Ainsi, l'invention décrite présente notamment les avantages suivants : - elle est simple à mettre en oeuvre, notamment dans le mode de réalisation non limitatif qui se base sur l'API OpenSocialTM ; - elle permet à des développeurs d'applications sociales de pouvoir exploiter les données profil utilisateur (par exemple l'âge et le sexe d'une personne) en fonction de leur état certifié ou non par exemple, ce qui est important pour nombre de sites de réseau social, tels que les sites de réseau social professionnels ou encore les sites de rencontres par exemple ; - le fait d'utiliser une demande de vérification de données compatible avec l'API OpenSocialTM, permet d'avoir un procédé de demande de vérification et un procédé associé de vérification compatible avec une API standard, donc facile d'utilisation par un développeur. De plus, cela évite de définir une nouvelle API, apporte une bonne portabilité des procédés sur différents sites de réseau social, et une réutilisation facile des implémentations (tels que gadgets). REVENDICATIONS1- Procédé (PROC1) de demande de vérification de données profil utilisateur (DUP) d'un site de réseau social (OPS), ledit procédé comportant les étapes de : - à partir d'un agent client (AC), lancer une demande (D_VERIF) de vérification de données profil utilisateur (DUP), la demande de vérification comprenant un indicateur de vérification (FLG) de données profil utilisateur ; - à partir dudit agent client (AC), envoyer une requête (RQ) correspondant à ladite demande de vérification (D_VERIF) à un agent serveur (AS) gestionnaire du site de réseau social (OPS), la requête comprenant ledit indicateur de vérification (FLG) de données profil utilisateur (DUP) et étant générée à partir d'une bibliothèque client/serveur (RPCLIB) ; - à partir dudit agent client (AC), recevoir dudit agent serveur (AS) un message de retour (MSG) comprenant les données profil utilisateur (DUP) dont au moins une donnée profil utilisateur (DUP) est accompagnée d'un marqueur de vérification (M) représentatif d'une certification de ladite donnée profil utilisateur (DUP) par le site de réseau social (OPS) si ladite donnée profil utilisateur est certifiée. 2- Procédé de demande de vérification selon la revendication 1, selon lequel l'agent client (AC) reçoit une pluralité de données profil utilisateur (DUP) accompagnées chacune d'un marqueur de vérification (M) si elles sont certifiées. 3- Procédé de demande de vérification selon la revendication 1 ou selon la revendication 2, selon lequel la demande de vérification (D_VERIF) est compatible avec l'interface de programmation applicative OpenSocialTM 4- Procédé (PROC2) de vérification, selon lequel une propriété d'intégrité (SIGN) est associée au message de retour (MSG). 5- Procédé (PROC2) de vérification de données profil utilisateur (DUP) d'un site de réseau social (OPS), ledit procédé comportant les étapes de - à partir d'un agent serveur (AS) gestionnaire du site de réseau social (OPS), recevoir une requête (RQ) correspondant à une demande de vérification (D_VERIF) de données profil utilisateur (DUP) lancée par un agent client (AC), la requête comprenant un indicateur de vérification (FLG) de données profil utilisateur (DUP) et étant générée à partir d'une bibliothèque client/serveur (RPCLIB) ; - à partir dudit agent serveur (AS), interpréter ledit indicateur de vérification (FLG) dans ladite requête (RQ) et vérifier dans une base de données (BDD) du site de réseau social (OPS) si les données profil utilisateur (DUP) ont été certifiées ; et - transmettre audit agent client (AC) un message de retour (MSG) comprenant les données profil utilisateur (DUP) dont au moins une donnée profil utilisateur (DUP) est accompagnée d'un marqueur de vérification (M) représentatif d'une certification de ladite donnée profil utilisateur (DUP) par le site de réseau social (OPS) si ladite donnée profil utilisateur est certifiée. 6- Procédé (PROC2) de vérification selon la revendication précédente, selon lequel l'étape d'interprétation de l'indicateur de vérification (FLG) est effectuée par une injection de dépendance d'une instance d'un élément de gestion de requêtes clients (N_PERSONHANDLR) d'un moteur d'exécution (SHIND) de l'agent serveur (AS). 7- Agent client (AC) pour site de réseau social (OPS) apte à coopérer avec un agent serveur (AS) et apte à demander une vérification des données profil utilisateur (DUP) d'un site de réseau social (OPS), selon lequel il est apte à : - lancer une demande (D_VERIF) de vérification de données profil utilisateur (DUP), la demande de vérification comprenant un indicateur de vérification (FLG) de données profil utilisateur ; - envoyer une requête (RQ) correspondant à ladite demande de vérification (D_VERIF) à un agent serveur (AS) gestionnaire dusite de réseau social (OPS), la requête comprenant ledit indicateur de vérification (FLG) de données profil utilisateur (DUP) et étant générée à partir d'une bibliothèque client/serveur (RPCLIB) ; - recevoir dudit agent serveur (AS) un message de retour (MSG) comprenant les données profil utilisateur (DUP) dont au moins une donnée profil utilisateur (DUP) est accompagnée d'un marqueur de vérification (M) représentatif d'une certification de ladite donnée profil utilisateur (DUP) par le site de réseau social (OPS) si ladite donnée profil utilisateur est certifiée. 8- Agent client (AC) selon la revendication précédente, selon lequel c'est un navigateur web. 9- Agent client (AC) selon la revendication 7, selon lequel c'est un gadget compatible avec une interface de programmation applicative 15 OpenSocialTM 10-Agent serveur (AS) pour site de réseau social (OPS) apte à coopérer avec un agent client (AC) et apte à vérifier des données profil utilisateur (DUP) d'un site de réseau social (OPS), selon lequel il est apte à: '20 - recevoir une requête (RQ) correspondant à une demande de vérification (D VERIF) de données profil utilisateur (DUP) lancée par un agent client (AC), la requête comprenant un indicateur de vérification (FLG) de données profil utilisateur (DUP) et étant générée à partir d'une bibliothèque client/serveur (RPCLIB) ; 25 - interpréter ledit indicateur de vérification (FLG) dans ladite requête (RQ) et vérifier dans une base de données (BDD) du site de réseau social (OPS) si les données profil utilisateur (DUP) ont été certifiées ; et - transmettre audit agent client (AC) un message de retour (MSG) 30 comprenant les données profil utilisateur (DUP) dont au moins une donnée profil utilisateur (DUP) est accompagnée d'un marqueur de vérification (M) représentatif d'une certification deladite donnée profil utilisateur par le site de réseau social (OPS) si ladite donnée profil utilisateur est certifiée. 11-Système de réseau de communication (SYS) pour site de réseau social (OPS) comprenant au moins un agent client (AC) selon l'une des revendications 7 à 9 et un agent serveur (AS) gestionnaire du site de réseau social selon la revendication 10, l'agent client (AC) et l'agent serveur (AS) étant aptes à coopérer entre eux pour vérifier des données profil utilisateur (DUP) dudit site de réseau social (OPS).10