FR3043817A1 - Procede de recherche d’informations au sein d’un ensemble d’informations - Google Patents

Abstract

L'invention concerne un procédé d'extraction d'informations au sein d'un ensemble d'informations, selon un critère de pertinence prédéterminé. Le procédé comporte des étapes suivantes : 301 de détermination par un utilisateur curateur (101) de mots clés relatifs à un sujet prédéterminé, ou de sources de recherche à utiliser, définissant ainsi une recherche de l'utilisateur curateur (101), 302 de recherche selon les mots clés choisis par l'utilisateur curateur (101) complétés par des mots clés suggérés par un moteur de suggestion, 303 d'analyse par l'utilisateur curateur (101) de ces données et de détermination, pour chacune d'elles, si elle répond à un critère de pertinence prédéterminé, 304, dans le cas où la donnée répond au critère de pertinence, de caractérisation de la donnée comme publiable au sein d'un dossier relatif au sujet choisi, 305 de qualification de la pertinence de chaque donnée suggérée vis à vis de la recherche de l'utilisateur curateur (101), 306 de modification des paramètres du moteur de suggestion selon cette qualification des données

Description

DOMAINE TECHNIQUE

La présente invention relève du domaine des procédés de traitement d’informations et particulièrement des moteurs de recherche.

Elle concerne plus particulièrement un procédé d’extraction d’informations au sein d’un ensemble très vaste d’informations, selon des critères de pertinence prédéterminés.

ÉTAT DE LA TECHNIQUE L’extraction de données parmi un volume très large de données est généralement désigné par le terme générique anglo-saxon de « big data ». Il s’agit par exemple de recherche d’informations relatives à un sujet prédéterminé.

Lorsque les données sont des articles de presse, et que le but est de regrouper de tels articles atour d’une thématique donnée, par exemple pour les proposer à la lecture d’un public intéressé par ce domaine, on parle de curation de contenu.

Chaque jour, plusieurs millions de nouvelles pages internet sont publiées, relativement à d’innombrables sujets. La lecture de toutes ces pages est naturellement impossible à un lecteur humain qui s’intéresse à un sujet particulier donné, couvert directement ou indirectement par certaines des nouvelles pages publiées, par l’intermédiaire de texte, photos, tableaux etc. Le besoin de curation de contenu, c’est à dire d’interface de compilation intelligente de données entre le web et les lecteurs, résulte de cette constatation.

La curation de données pose plusieurs problèmes, notamment de vitesse d’exécution, de qualité des résultats sélectionnés, de mise en avant de ces résultats pour que les lecteurs puissent les trouver facilement au milieu du bruit de fond de nouvelles pages publiées etc.

EXPOSÉ DE L’INVENTION

La présente invention vise à résoudre certains des problèmes mentionnés plus haut. Elle vise ainsi notamment un procédé de curation de contenu qui soit plus efficace en termes de pertinence des suggestions de contenu.

Avantageusement, le procédé est également plus efficace en termes de visibilité des contenus retenus sur des sites de publication préalablement choisis.

Sous un premier aspect, l’invention vise un procédé d’extraction d’informations au sein d’un ensemble d’informations, selon des critères de pertinence prédéterminés.

Le procédé comporte des étapes suivantes : 301 de détermination par un utilisateur curateur de mots clés relatifs à un sujet prédéterminé, ou de sources de recherche à utiliser, définissant ainsi une recherche de l’utilisateur, 302 de recherche selon les mots clés choisis par l’utilisateur curateur complétés par des mots clés suggérés par un moteur de suggestion, dans un ensemble de sources comprenant les sources choisies par l’utilisateur curateur, complété par d’autres sources suggérées par le moteur de suggestion, et de suggestion de contenu à l’utilisateur curateur selon une distance par rapport à la recherche de l’utilisateur. 303 d’analyse par l’utilisateur curateur de ces données et de détermination, pour chacune d’elles, si elle répond à un critère de pertinence prédéterminé, 304, dans le cas où la donnée répond au critère de pertinence, de caractérisation de la donnée comme publiable au sein d’un dossier relatif au sujet choisi, 305 de qualification de la pertinence de chaque donnée suggérée vis à vis de la recherche de l’utilisateur curateur, 306 de modification des paramètres du moteur de suggestion selon cette qualification des données, en créant ainsi une boucle de rétroaction et d’apprentissage dudit moteur de suggestions.

De la sorte, les utilisateurs curateurs participent directement à l’amélioration permanente du moteur de suggestions, qui vient leur faciliter la tâche de curation

Dans un mode particulier de mise en oeuvre, le procédé comporte également une étape 308, de détermination d’un ou plusieurs sites de publication, et de dates de publication, selon des critères préalablement déterminés de maximisation de la visibilité de la publication ainsi réalisée.

Dans un mode particulier de mise en œuvre, le procédé comporte : - une étape 406 de calcul d’un nombre de vues pour chaque page vue par un, une partie ou tous les utilisateurs curateurs et utilisateurs lecteurs, - une étape 410 de calcul d’un score pour chaque contenu, selon le nombre de pages vues et selon le type d’action réalisé par un utilisateur sur ce contenu : suivre 407, partager 408, recommander 409, - une étape 411 d’analyse des scores pour recommander et catégoriser les contenus en vue de leur qualification par les utilisateurs,

Dans un mode particulier de mise en œuvre, la catégorisation est réalisée en utilisant au moins un algorithme d’apprentissage machine (« machine learning >>) automatique.

Dans un mode particulier de mise en œuvre, le moteur de suggestion met en œuvre : une étape 502, dans laquelle les mots clefs choisis dans l’étape 301 sont utilisés pour parcourir des domaines de données pour en extraire des adresses URL de pages pertinentes au regard de ces mots clefs, une étape 501, dans laquelle le système récupère le contenu des pages web sélectionnées et les stocke en mémoire, une étape 503, dans laquelle le système extrait de ces pages web les textes, images et éventuelles adresses de flux RSS associées, une étape 504, dans laquelle ces flux RSS sont stockés et viennent alimenter une base de données, une étape 506, de parcours en boucle des URL de flux RSS pour rechercher les URL de RSS correspondants aux mots clefs prédéfinis, une étape 507 de chargement de ces flux RSS, une étape 514 dans laquelle, à partir des textes, images et flux RSS extraits lors de l’étape 503, le système indexe et stocke des éléments de suggestions, ces suggestions venant alimenter une base de données de suggestions, une étape 516, dans laquelle le système effectue une recherche des mots clés sélectionnés par l’utilisateur dans la base de suggestions, une étape 517 de filtrage des données extraites selon cette recherche pour en éliminer les pages déjà vues par l’utilisateur curateur lors d’une présente recherche, une étape 518 d’application d’autres filtres définis préalablement par ledit utilisateur, une étape 519, dans laquelle les suggestions sont triées selon des critères prédéfinis.

Dans un mode particulier de mise en œuvre, dans l’étape 308, le système se base sur l’ensemble des données déjà existant tant au niveau de l’utilisateur que de l’ensemble des utilisateurs curateurs et/ou utilisateurs lecteurs pour déterminer pour chaque triplet audience / thème / réseau de publication, un ensemble de moments et intervalles de publication considérés comme les plus efficaces selon un critère prédéterminé.

Dans un mode particulier de mise en oeuvre, le procédé comporte en outre une étape dans laquelle le système extrait, pour chaque article partagé, le nombre de réactions qu’il génère, calcule un score pour chaque partage, et en déduit les heures les plus propices au partage sur chacun des réseaux sociaux.

Dans un mode particulier de mise en oeuvre, le procédé comporte une étape 605 dans laquelle les détails de chaque partage (date, heure, contenu, destination etc.) sont stockés, et une étape 606, dans laquelle le système analyse l’impact obtenu par le partage réalisé, de manière à alimenter une base de données pour un apprentissage machine.

Dans un mode particulier de mise en œuvre, l’étape 306 met en œuvre un algorithme basé sur les comportements et les actions de l’ensemble des utilisateurs curateurs et/ou utilisateurs lecteurs, permettant de mettre en avant des contenus, de les catégoriser dans des groupes thématiques, de mettre en relation des utilisateurs qui ont les mêmes centres d’intérêts.

Dans un mode particulier de mise en œuvre, le procédé comporte : une étape 409 d’enregistrement des actions de chaque utilisateur lecteur : lecture d’un contenu, partage d’un contenu, qualification d’un contenu, ou recommandation d’un contenu, de façon attachée audit contenu pour le qualifier. une étape 410 de calcul d’un score pour le contenu, sur la base de ces éléments de qualification recueillis au cours de temps, une étape 411 de comparaison du score à des valeurs seuils prédéfinies, i) si ce score du contenu est inférieur à une première valeur seuil prédéterminée mais supérieur à une seconde valeur seuil prédéterminée, une étape 703 de calcul de catégories pertinentes pour le contenu, une étape 704 de proposition à l’utilisateur de choisir lui-même une catégorie, ce choix de l’utilisateur lecteur étant utilisé pour améliorer dans une étape 705 le moteur de choix de catégories automatique, une étape 706, d’utilisation du contenu pour des recommandations, ii) si ce score du contenu est supérieur à la première valeur seuil, le contenu est utilisé pour des recommandations, et, si il n’a pas de catégories attachées, le système calcule, comme précédemment, des catégories qui viendront le qualifier.

PRÉSENTATION DES FIGURES

Les caractéristiques et avantages de l’invention seront mieux appréciés grâce à la description qui suit, description qui expose les caractéristiques de l’invention au travers d’un exemple non limitatif d’application.

La description s’appuie sur les figures annexées qui représentent :

Figure 1 : un schéma de principe des éléments impliqués dans le dispositif, - Figure 2 : une illustration schématique de l’environnement opérationnel du système proposé, - Figure 3 : un organigramme simplifié des étapes principales du procédé de curation, - Figure 4 : un organigramme des étapes du fonctionnement en lecture, - Figure 5 : un organigramme des étapes du procédé de suggestion optimisée de contenus, - Figure 6 : un organigramme des étapes du procédé de partage des informations et de planification des publications,

Figure 7 : un organigramme des étapes du procédé de recommandation et de classification.

DESCRIPTION DÉTAILLÉE D’UN MODE DE RÉALISATION DE L’INVENTION L’invention est destinée à être mise en oeuvre de façon logicielle.

Comme illustré schématiquement figure 1. le procédé est mis en oeuvre par un ou plusieurs utilisateurs curateurs 101 et utilisateurs lecteurs 106. Chacun de ces utilisateurs curateurs 101 et utilisateurs lecteurs 106 travaille sur un ordinateur 102, par exemple mais non limitativement de type PC. Chaque ordinateur comporte des moyens de mettre en oeuvre une partie du procédé.

Chaque ordinateur 102 est relié, via un réseau 103 connu en soi, à diverses bases de données 104, ainsi qu’à au moins un serveur central 105 sur lequel est exécuté un logiciel mettant en oeuvre une autre partie du procédé.

La fonction de l’utilisateur curateur 101 est de trier des données et de choisir lesquelles sont adaptées à décrire correctement un sujet prédéterminé, ce qui correspond à la définition courante de la curation de sujet. Ces utilisateurs curateurs 101 peuvent être humains ou algorithmiques. Dans le cas où ces utilisateurs curateurs 101 sont algorithmiques, on définit une distance entre le sujet choisi et les données associées à ce sujet

Le procédé de « curation du web » comprend des logiciels (Web par exemple mais pas limitativement) permettant de suggérer des contenus aux utilisateurs en fonction de leurs intérêts, préalablement définis notamment par divers mots-clés et mémorisés. Le but est d’extraire l’essence de ces contenus et de recommander les plus pertinents en fonction des contenus déjà acceptés, c’est à dire intégrés dans des topics de divers utilisateurs curateurs 101. L’essence d’un document désigne ici des données particulièrement pertinentes pour caractériser ce document : par exemple titre et sous-titres ou têtes de paragraphes, mots-clés, auteur, date, photo, mots les plus fréquemment utilisés, etc.

Dans la suite de la description, on définit par contenu une page de données de type page web, comportant typiquement des textes, des images, des balises de date de mise à jour, de mots clefs associés etc.

On définit par topic un ensemble de données, par exemple sous forme de pages web, d’images, de textes etc. relevant d’un même domaine sémantique choisi par un utilisateur.

On définit par visibilité le nombre de fois que des internautes viennent voir un topic donné.

Le but du système est pour l’utilisateur curateur 101 d’augmenter la visibilité de ses topics sur le web par des utilisateurs lecteurs 106, en se positionnant grâce au système en tant que spécialiste d’un domaine bien particulier. On définit par utilisateur lecteur 106 un utilisateur qui vient lire le contenu de divers topics qui l’intéressent.

Dans cet objectif, le système permet de diffuser un contenu sélectionné sur le web au travers de plusieurs axes : visibilité sur les moteurs de recherche, les réseaux sociaux, les sites d’entreprise des utilisateurs...

Le système permet de conserver la sélection faite au travers d’un magazine regroupant l’ensemble des contenus pertinents sur une page publique unique.

Le système propose des outils en ligne pour le « content marketing » : une stratégie marketing qui implique la création et la diffusion, par une entreprise, de contenus médias afin d'acquérir de nouveaux clients.

Environnement opérationnel du système (figure 2)

Le moteur du système est une plateforme (définie comme un ensemble de services) qui représente, c’est à dire contient les références d’un très grand nombre d’adresses de pages internet. A titre d’ordre de grandeur nullement limitatif, la plateforme représente ici plus de 50 millions d’URLs. Il s’agit d’un système de curation de contenus éditoriaux et d’une plateforme communautaire à forte audience. L’architecture de la plateforme est basée sur l’architecture web illustrée figure 2. Comme on le voit sur cette figure, le procédé est utilisé dans le cadre d’un réseau de données de type Internet 201. Le système met en œuvre : un module 202 de protection contre les attaques en déni de service, un module 203 de répartition de charge (« IP load balancing » et « http load balancing ») entre utilisateurs.

Il comprend par ailleurs d’une part au moins un serveur 204 de navigation web (« crawling »), au moins un serveur de suggestions de pages 205, associé à un système « big data » 206 de stockage de pages internet, c'est-à-dire une base de données stockant un très grand volume de pages internet.

Les serveurs de suggestion 205 et les protections 202 et modules 203 d’équilibrage de charge alimentent au moins un serveur applicatif 207 associé à un serveur d’images 208. Le serveur applicatif 207 met en œuvre un moteur de recherche 209.

Par ailleurs, le serveur d’images 208 est relié à une base de données big data 210 de stockage d’images et une base de données 211 de stockage relationnel. Des références vers les images sont stockées dans une base relationnelle afin de permettre des jointures entre les systèmes noSQL et les stockages relationnels.

Le serveur applicatif 207 et le serveur d’images 208 sont relié à une base de données cache 212. Le serveur applicatif 207 est relié à une base de données 214 de stockage d’évènements. Ce système de stockage d’évènements peut être vu comme un système de log qui peut être utilisé pour des opérations de maintenance, ou des statistiques interne ou externe - externe = pour les utilisateurs. En complément des serveurs applicatifs 207, un cluster de serveurs NoSQL 213 est utilisé pour stocker les données non structurées et exécuter sur ces données divers algorithmes de recommandation, de classification, d’analyses statistiques etc.

Enfin, la base de données de stockage d’évènements 214 alimente au moins un serveur de calcul de taches asynchrones 215, taches de calcul pour fournir des statistiques à l’utilisateur mais aussi pour des besoins internes lequel vient également alimenter la base de données de stockage non SQL 213 avec les résultats des calculs. L’exploration du web et la récolte de données porteuses de sens sur les pages web est basée sur des programmes écrits par exemple en Python -marque déposée- et en Java -marque déposée- qui permettent de parcourir et d’extraire l’information essentielle des pages visitées.

Tout ou partie des fonctions 201 d’accès internet, 202 de protection, 203 d’équilibrage de charge, de serveurs 204 de navigation, de serveurs 205 de suggestion, 206 de stockage de pages internet, de serveurs applicatifs 207, des serveurs d’images 208, de moteur de recherche 209, de gestion des bases de données 210, 211, 212, 213, 214, et de serveurs de calcul asynchrone 215 sont exécutées par un serveur central 105 de la figure 1.

Fonctionnement général du procédé de curation (figure 3)

Les suggestions que propose le système mettant en oeuvre le procédé sont issues de mots clefs et de sources sélectionnés par un utilisateur curateur 101.

On définit par suggestion une adresse de page internet comportant des informations pertinentes relativement à un thème préalablement choisi, celui-ci étant défini par exemple par un ensemble de mots clés.

On définit par source l’adresse d’une page ou serveur de données internet, par exemple mais non limitativement indépendant du présent système.

Dans le présent exemple de mise en œuvre, le procédé utilise une très large partie, voire l’ensemble des données (c'est-à-dire des pages, textes, images) stockées ou référencées par les autres utilisateurs curateurs 101 et utilisateurs lecteurs 106 pour qualifier, ordonner et filtrer le contenu suggéré.

Les suggestions envoyées à un utilisateur curateur 101 sont issues à la fois des mots clefs et des sources donnés par cet utilisateur curateur 101, mais aussi de l’ensemble des connaissances acquises par le système en analysant le comportement des autres utilisateurs curateurs 101 et utilisateurs lecteurs 106 aux contenus (voir figures 4 et 7 et les descriptions associées).

La figure 3 illustre ce fonctionnement. Dans une étape 301, un utilisateur curateur 101 détermine des mots clés relatifs à un sujet prédéterminé, ou des sources à utiliser pour la réponse à une recherche, et entre ces données dans le système mettant en œuvre le procédé objet de la présente invention.

Dans une étape 302, un moteur de suggestion (nommé dans la suite de la description « moteur de suggestion 302 » par simplification), ici mais non limitativement mis en œuvre par un serveur central, effectue un tri sur les données (informations, articles) auxquelles il peut accéder, et détermine pour ces données une distance par rapport à une réponse idéale à la recherche de l’utilisateur. Il transmet alors à l’utilisateur curateur 101 les données (articles) les plus pertinentes, classées par exemple par distance croissante à la réponse idéale.

Le détail de l’étape 302 est donné figure 5.

Dans une étape 303, l’utilisateur curateur 101 analyse ces données (comprenant par exemple diverses pages internet) et détermine, pour chacune d’elles, dans une étape 310, si elle doit être parcourue et analysée de façon plus détaillée (« Read »). Si ce n’est pas le cas, l’utilisateur curateur 101 passe à la suggestion suivante. Si c’est le cas, la suggestion est parcourue en détails (« read »), puis, évaluée, dans une étape 309, pour déterminer si elle répond à un critère prédéterminé et doit donc être publiée (« curate ») relativement à la recherche initiale, ce critère prédéterminé pouvant par exemple prendre en compte la date de la donnée ou sa source.

Si la donnée répond au critère de pertinence prédéterminé, dans une étape 304, la donnée est caractérisé comme publiable au sein d’un dossier relatif au sujet initialement choisi.

Quel que soit le classement de la donnée relativement au critère de pertinence donnée par l’utilisateur curateur 101 dans l’étape 310 (à publier, à ne pas publier, non pertinente), dans une étape 305, la donnée est associée à une qualification caractérisant sa pertinence vis à vis de la recherche initiale, ou complétant sa description par divers mots-clés ou notes de qualité.

Dans une étape 306, ces éléments complémentaires de qualification des données en relation avec la recherche initiale sont utilisés pour modifier les paramètres de réglage du moteur de suggestions, en créant ainsi une boucle de rétroaction et d’apprentissage dudit moteur de suggestions.

Dans une étape 307, le système détermine si la donnée doit être partagée ou non.

Si la donnée doit être publiée, dans une étape 308, le système détermine un ou plusieurs sites de publication, et des dates de publication, selon des critères préalablement déterminés de portée maximum de la publication ainsi réalisée.

Le détail de l’étape 307 est donné figure 6.

Pour pouvoir fournir à l’utilisateur curateur 101 un grand nombre de suggestions de contenus pertinents par rapport à son thème de travail, le système mettant en œuvre le procédé de curation décrit ici, doit être capable de découvrir en temps réel une proportion la plus large possible des articles correspondant aux intérêts d’un utilisateur. En effet, fournir du contenu de qualité n’est pas suffisant, il faut par ailleurs le fournir en temps réel ou le plus proche possible de cet état. Se pose donc un problème de rapidité de la collecte de nouvelle information et de l’extraction de la partie utile. En effet le système doit affiner la qualification d’un article et donc extraire de ce dernier l’information qui est utile pour sa qualification. L’incertitude dans ce domaine réside dans la sélection des informations nécessaires pour la qualification de l’article.

Pour des raisons de lisibilité des suggestions par l’utilisateur curateur 101, le système doit être capable d’extraire l’essence de l’article, ici définie comme une image associée à l’article ainsi qu’un extrait de texte significatif pour la compréhension de l’article.

Le système de collecte d’information ne collecte pas l’ensemble du web mais simplement une sous partie du web correspondant au sujet traités par les utilisateurs de la plateforme. Cependant la limitation principale réside dans le fait de réussir à extraire les parties nécessaires à une bonne analyse ultérieure du contenu. L’idée est de fournir aux utilisateurs du système un maximum d’articles pertinents (et leurs données associées) capturés sur le Web en temps réel. Il s’agit donc également d’extraire les informations sémantiques afférentes, sur des pages dont la structure varie de site en site. Le système doit trouver une solution générique (la diversité des données est importante) et rapide (il s’agit de proposer en temps réel des articles aux utilisateurs).

Pour trouver un maximum de contenu, il existe deux techniques connues. La première est la technique récursive d’exploration / extraction de données qui consiste à suivre de lien en lien l’ensemble des documents présent sur le web. La seconde est d’utiliser et de multiplier les services externes (afin de bénéficier du travail déjà effectué) afin d’extraire uniquement le contenu à priori intéressant tout en garantissant une rapidité d’exécution suffisante.

Pour l’extraction de données des documents, il existe des solutions ou outils qui n’implémentent qu’une partie des besoins pour l’exploration des documents web (exploration exhaustive du web) et des frameworks (ensemble de composants logiciels) incomplets d’exploration et de sémantisation pour le web. En effet le système doit pouvoir présélectionner un sous ensemble du web avant de l’explorer car explorer l’ensemble du web serait bien trop coûteux en termes de ressources et d’infrastructure.

Les inventeurs ont donc décidé de développer leur propre solution, d’une manière itérative afin d’être le plus simple et rapide possible, tout en restant pertinent.

Plusieurs méthodes dans la collecte de données peuvent être envisagées. Les algorithmes mis en oeuvre dans le procédé se concentrent sur un périmètre restreint du Web. Le système limite l’exploration du web aux domaines d’intérêts déclarés par l’utilisateur curateur 101 par des mots clefs. Ces mots clefs permettent via différentes API de sélectionner des URLs constituant des points de départ à une recherche de contenus sur le web.

De plus, le système cumule beaucoup de flux RSS qui peuvent aussi servir de révérenciel de base à l’exploration du web.

En effet ces flux RSS ont été saisis par l’ensemble des utilisateurs curateurs 101 et utilisateurs lecteurs 106 et donc le sous ensemble du web qu’ils représentent est le reflet des contenus pertinents pour les utilisateurs curateurs 101 et utilisateurs lecteurs 106. L’extraction du contenu des pages et des données essentielles pour la qualification des contenus a connu plusieurs implémentations : - Lecture simple des méta-données HTML, - Affichage des pages visuellement dans un pseudo navigateur (Python et QtWebkit -marques déposées-) pour trouver l’information principale. Le rendu des pages web via QtWebkit -marque déposée- permet de réaliser un rendu de la page et ainsi d’extraire le contenu en se basant sur des règles évolutives visuelles.

Ces techniques présentent des inconvénients de pauvreté de contenu extrait ou de ressources nécessaires à leur mise en œuvre. L’extraction des données est ici basée sur une analyse des données microformats (http://fr.wikiDedia.org/wiki/Microformat) et en particulier le protocole OpenGraph (http://oap.me/).

Cependant certaines informations ne sont pas disponibles ou bien certaines pages web ne fournissent pas ces informations. De plus les informations extraites ne sont pas assez nombreuses.

Il est donc souhaitable de mettre en place des nouveaux algorithmes pour extraire le contenu entier d’un article. L'algorithme se base principalement sur des heuristiques sur les métadonnées et sur la structure de la page web. Le système utilise une liste d'éléments HTML et de classes CSS qui sont souvent utilisés pour délimiter l'article dans la page web. L'algorithme repère donc tous les contenus encadrés par ces éléments et ces classes. Parmi cette liste de contenus trouvés, le procédé met en œuvre d'autres heuristiques pour reconnaître l'article principal. Par exemple, le procédé attache de l'importance à la taille du contenu trouvé, et la place de ce contenu dans la structure du document HTML.

Sur la base d'une liste de sites web populaires, le procédé s’assure de manière automatique que l'algorithme arrive à extraire du contenu en quantité suffisante, c’est à dire supérieure à une valeur prédéterminée.

Pour la récupération des impacts sur les réseaux sociaux des pages analysées, pour chacune des pages, on requête différents réseaux sociaux afin de déterminer le nombre de « like », « tweet », etc... d’un article.

Fonctionnement en lecture (figure 4)

Une fois que les contenus ont été extraits lors de la phase de curation, ils sont publiés dans les topics des utilisateurs curateurs 101, et sont ainsi mis à disposition des utilisateurs lecteurs 106, selon leurs centres d’intérêt.

Dans le présent exemple non limitatif de mise en œuvre du procédé, un utilisateur lecteur 106 découvre dans une étape 401 du contenu internet à partir de plusieurs sources (en haut du schéma figure 4). Ces sources de contenus : réseaux sociaux 402, moteur de recherche 403, « suivi » (« followed content ») 404, recommandation ou catégorisation 405, etc. permettent de découvrir du contenu publiable pour l’utilisateur relativement à son thème de travail. Ces contenus vus permettent dans une étape 406 de calculer un nombre de vues pour chaque page vue par un, une partie ou tous les utilisateurs curateurs 101 et utilisateurs lecteurs 106. L’utilisateur lecteur 106 peut effectuer plusieurs actions sur ces contenus : suivre 407, partager 408 (dans ce cas au moins une destination de partage est sélectionnée par l’utilisateur), recommander 409 (dans ce cas, le contenu est marqué comme étant qualifié). Ces actions associées aux pages vues calculées dans l’étape 406 permettent de calculer un score par contenu (étape 410). Chacune de ces actions donne de la valeur au contenu pour lequel l’action est réalisée. Ces notations associées à des algorithmes permettent de calculer un score pour chaque contenu.

Ce score est ensuite analysé par le système dans une étape 411 pour recommander et catégoriser les contenus en vue de leur parcours par les utilisateurs lecteurs 106 dans l’étape 405. La catégorisation est partiellement basée sur des algorithmes d’apprentissage machine (en anglais machine learning) automatique. L’utilisateur lecteur 106 valide par ailleurs le choix de la catégorie. Cette validation sert par la suite d’entrée pour des algorithmes d’apprentissage machine.

Le détail des étapes 409, 410 et 411, qui complètent l’étape 305 de la figure 3, est donné figure 7 relative aux intérêts et recommandations.

Fonctionnement du moteur de suggestion (figure 5)

Les informations collectées sur Internet ainsi que les informations sélectionnées par les utilisateurs curateurs 101 doivent être filtrées et classées pour ensuite être mises en avant sur les pages du système.

Ainsi les articles récoltés sur l’Internet doivent être analysés, classés, filtrés pour, par la suite être proposés aux utilisateurs curateurs 101. En effet le premier niveau de curation est fait par le moteur de suggestion 302 qui doit être capable à partir de l’ensemble des articles extraits quotidiennement de l’internet, de sélectionner ceux qui doivent être proposés à un utilisateur curateur 101 donné.

Pour cela, plusieurs systèmes doivent être mis en place : analyse des données, classification et filtrage avant de proposer ces contenus à l’utilisateur curateur 101. Le temps d’exécution des calculs devra être rapide pour permettre de proposer du nouveau contenu plusieurs fois par jour.

Dans une première version, le moteur de suggestion 302 appelle des API web afin de trouver des contenus à proposer à l’utilisateur curateur 101. Aucune mise en commun des informations globales (c’est à dire émanant de tous les utilisateurs) de la plateforme n’est utilisée.

Dans une seconde version utilisant des algorithmes de recommandation et de classification du contenu, l’expérience acquise permet de qualifier, filtrer et ordonner les informations récoltées sur le web.

Etant donné la particularité du contenu de la plateforme, qui est essentiellement constitué de citations d'articles préexistants sur le web, le système s’intéresse à la recommandation de contenu court.

La plateforme du système offrant des fonctionnalités d'interaction sociale, les algorithmes profitant de l'aspect social des données correspondent aux besoins du système. Une attention particulière au volume de données est nécessaire en concordance avec l'évolution du système. La scalabilité des algorithmes est importante, c’est à dire leur capacité à accommoder un volume de données pouvant fortement augmenter au cours du temps.

Le système met en œuvre une implémentation d'algorithme de filtre collaboratif via un moteur de recherche. L’ensemble des contenus collectés via le moteur de suggestion 302 sont stockés dans un système « big data >> (expression anglophone désignant des ensembles de données tellement volumineux qu'ils en deviennent difficiles à travailler avec des outils classiques de gestion de base de données ou de gestion de l'information - source Wikipedia). Ces données sont ensuite indexées et enrichie par des métas données internes ou externes. Cet index permet par la suite de proposer aux utilisateurs des données ainsi collectées sans passer par les API web. Ainsi le procédé de curation, ici décrit à titre d’exemple non limitatif, enrichit au fur et à mesure du temps ses propres bases de contenus non curés pouvant être utile aux futurs utilisateurs curateurs 101.

Ainsi, en plus des algorithmes d’analyse des données, il est nécessaire de filtrer et de trier les contenus afin de ne pas présenter les contenus peu intéressants et d’afficher les contenus dans le meilleur ordre possible pour l’utilisateur curateur 101. L’utilisateur curateur 101 saisit des mots clefs pour que le système lui propose du contenu, ainsi le premier moyen de filtrer est basé sur ces mots clefs. Comme le système propose du contenu aux utilisateurs curateurs 101.qui ont ensuite le choix du sélectionner pour le publier ou de le rejeter, il est possible, dans une étape ultérieure, d’apprendre des comportements des utilisateurs curateurs 101.pour classifier et filtrer le contenu.

Le moteur de suggestion 302 est directement dépendant de la partie relative à la collecte de données sur le web. Ainsi la problématique tourne autour du volume de données extrait. Si ce dernier n’est pas assez important, le moteur de suggestion 302 manque de données à analyser, trier, organiser. D’un autre côté, la collecte de données doit extraire les données importantes pour que les algorithmes d’analyse, tri, organisation puissent fonctionner. La quantité de données aujourd’hui envisagée est de 25 millions de pages analysées par jour, et elle semble idéale pour les algorithmes.

Le but du moteur de suggestion 302 est de profiter de l’ensemble des articles extraits du web, selon divers mots clefs ou critères prédéterminés, afin de les proposer aux utilisateurs curateurs 101. A cet effet, dans une étape 501 (voir figure 5). des contenus sous forme d’adresses URL sont récupérés vers le serveur 102 par des sources de contenus associées au mot clefs saisis par l’utilisateur curateur 101 (dans l’étape 301). L’objectif est ensuite de les trier, filtrer et organiser.

Le moteur de suggestion 302 met en œuvre un algorithme qui utilise comme tri primaire le nombre de mots clés détectés dans les suggestions. Si deux suggestions ont le même nombre de mots clés, le tri secondaire utilisé est la date de publication du contenu. Cet algorithme combine donc pertinence et fraîcheur du contenu. Il permet également de rendre le tri compréhensible aux utilisateurs car tous les critères utilisés sont affichés.

Certaines données des articles du web sont primordiales lors de l’extraction de contenu pour permettre par la suite une bonne qualification dudit contenu. Ces données sont ensuite la base de travail d’algorithmes permettant de classer, trier, filtrer les contenus. Au niveau de ces données, plusieurs informations sont recherchées : les dates des articles, l'auteur, l’image d’illustration, etc. En ce qui concerne la date des articles, cette information n’est parfois pas présente ou cachée au sein même du contenu.

La popularité sociale des articles est, par ailleurs, l’un des meilleurs indices sur la qualité d’un article mais elle est difficile à obtenir. Ce type de métrique est la propriété des différents réseaux sociaux, et interroger ces réseaux sociaux de façon intensive (30 millions / jour) demande une architecture conséquente.

Tel qu’il est illustré de façon non limitative figure 5, le moteur de suggestion 302 met en œuvre un ensemble d’algorithmes capables de choisir, de classer, et de qualifier des contenus à proposer à l’utilisateur curateur 101. Ces algorithmes sont basés sur l’ensemble des connaissances des comportements des utilisateurs curateurs 101 et sur l’ensemble du contenu que le système possède ou est capable d’aller chercher sur le web. Ils utilisent aussi les mots clefs saisis par les utilisateurs curateurs 101.

Comme on l’a vu, dans une étape 301, l’utilisateur curateur 101 détermine des mots clefs et/ou des sources sous forme URL. Dans une étape 502, les mots clefs choisis ont utilisés pour parcourir des domaines de données de type Twitter -marque déposée-, Facebook -marque déposée- etc. pour en extraire des adresses URL de pages pertinentes au regard de ces mots clefs. Dans l’étape 501, le système récupère le contenu des pages web sélectionnées et les stocke en mémoire.

Dans une étape suivante 503, le système extrait de ces pages web les textes, images et éventuelles adresses de flux RSS associées.

Dans une étape 504, les flux RSS sont stockés et viennent alimenter une base de données 505. Dans une étape 506, le système parcourt en boucle les URL de flux RSS pour rechercher les URL de RSS correspondants aux mots clefs prédéfinis. Puis ces flux RSS sont chargés dans une étape 507. A partir des textes, images et flux RSS extraits lors de l’étape 503, dans une étape 514, le système indexe et stocke des éléments (snippets) de suggestion. Ces suggestions viennent alimenter une base de données 515 de suggestions sous forme d’URLs associées aux mots clef de la recherche. Le stockage consiste à stocker une url associée à un ensemble de données extraite de la page : date, titre, contenu utile (épuré de sa décoration), images essentielles de la page, etc. ainsi que des métadonnées aidant à la qualification (mot clefs, etc.).

Dans une étape 516, le système effectue une recherche des mots clés sélectionnés par l’utilisateur dans la base de données 515 de suggestions comprenant toutes les suggestions précédentes pour tous les utilisateurs de la base.

Les données extraites selon cette recherche sont filtrés pour en éliminer les pages déjà vues par l’utilisateur lors de la présente recherche (étape 517), et appliquer d’autres filtres définis préalablement par ledit utilisateur (étape 518).

Dans une étape 519, les suggestions sont triées selon des critères prédéfinis, par exemple par date associée, ou par un critère plus complexe de score de qualité ou autre. Ces critères de score peuvent émaner de données d’apprentissage machine stockées dans une base 520.

Enfin, dans une étape 521, le système présente les suggestions retenues, filtrées et triées à l’utilisateur en réponse à sa requête.

Fonctionnement du module de partage et du module d’optimisation de calendrier d’affichage (voir figure 6)

Les utilisateurs curateurs 101 du système souhaitent que leur écosystème, défini comme l’ensemble des utilisateurs lecteurs 106 de pages web qui suivent régulièrement leurs publications, référencement, réactions sur les réseaux sociaux, profite au mieux des articles qu’ils ont sélectionnés. Ainsi la simple publication sur une page du système n’est pas suffisante. L’objectif est de partager ces articles sur les différents réseaux sociaux. Cependant des partages sur des intervalles de temps aléatoire ne sont pas efficaces, par exemple en termes de nombre de pages vues. L’objectif du système est alors de partager les documents sélectionnés sur des créneaux temporels automatiquement adaptés à l’audience de l’utilisateur curateur 101. Pour cela le système pourra (dans l’étape 308 vue plus haut) se baser sur l’ensemble des données déjà existant tant au niveau de l’utilisateur curateur 101 que de l’ensemble des utilisateurs pour déterminer, pour chaque triplet audience / thème / réseau social de publication, un ensemble de moments et intervalles de publication considérés comme les plus efficaces selon un critère prédéterminé, par exemple utilisant le nombre pages vues.

Le but est donc de construire des algorithmes pour réaliser un système capable automatiquement de sélectionner les meilleurs moments ou partager un contenu en fonction de l’audience de l’utilisateur, de la thématique de l’utilisateur et du réseau social concerné. Certains créneaux de temps sont communément admis comme meilleurs que d’autres en fonction des réseaux sociaux. Pour affiner le meilleur moment de partage on propose d’inclure les réactions générées sur un réseau social donné, et de faire des suggestions de créneaux horaires aux utilisateurs curateurs 101.

Dans une variante, le système répète plusieurs fois une même information sur chacun des réseaux sociaux. Cette répétition n’est pas aléatoire mais elle aussi basée sur des analyses des résultats des partages. Cette méthode permet de toucher plus de monde alors même que la forte masse d’information sur les réseaux sociaux ne permet pas au lecteur de consulter l’ensemble des flux d’informations en permanence.

Un premier défi consiste dans la capacité du système à connaître les « réactions >> engendrées par les partages des utilisateurs pour pouvoir in-fine déterminer les meilleurs créneaux horaires pour chaque utilisateur.

Un second défi est d’établir des règles en fonction des thèmes (catégories) de contenu. L’objectif est dans un premier temps de gérer des heures préférées d’ordonnancement pour les partages sur les réseaux sociaux. Ces heures préférés seront générées de façon statique, et pourront être par la suite modifiées pour chacun des couples utilisateur curateur 101 / topic.

Dans le mode de mise en œuvre décrit ici, des heures préférentielles pour chaque réseau social sont préalablement déterminées, et le partage se fait prioritairement à ces heures préférentielles en fonction du fuseau horaire défini par l’administrateur du topic.

Ainsi l’étape suivante est d’extraire pour chaque article partagé le nombre de réactions qu’il génère. Pour cela on utilise les API des différents réseaux sociaux.

Il est également possible d’utiliser le nombre de vues sur l’article en se basant sur le référent (en anglais « referer ») du navigateur de l’utilisateur 101. Ainsi il est possible de calculer un score pour chaque partage (par exemple calculé comme le nombre de réactions sur des réseaux sociaux plus le nombre de vues). Ce score représente donc le succès d’un partage. En faisant des calculs de moyenne de succès par heure, il est possible de définir les heures les plus propices au partage sur chacun des réseaux sociaux.

Fort de la connaissance de l’amplification des partages sur les réseaux sociaux par l’analyse des partages fait depuis le système et par les objectifs fixés par les utilisateurs, le module d’optimisation de calendrier d’affichage permet à l’utilisateur curateur 101 de partager ces contenus au moment optimal pour qu’ils reçoivent le meilleur écho possible sur les réseaux sociaux.

La figure 6 détaille le fonctionnement du module de partage et du module d’optimisation de calendrier d’affichage.

Comme on le voit sur cette figure, lorsque, dans une étape 601, l’utilisateur curateur 101 décide de partager un contenu, il lui est demandé dans une étape 602 s’il souhaite un partage immédiat ou non.

Dans le cas où il souhaite un partage immédiat, le contenu est partagé dans une étape 603 et publié sur le web (étape 604). Simultanément, les détails de ce partage (date, heure, contenu, destination etc.) sont stockés dans une étape 605, et dans une étape 606, le système analyse l’impact obtenu par le partage réalisé, de manière à alimenter une base de données pour un apprentissage machine. L’impact obtenu peut être mesuré par le nombre de vues de la page ou par d’autres paramètres (durée de séjour sur la page, citations etc.).

Dans le cas ou l’utilisateur curateur 101 ne requiert pas un partage immédiat du contenu, dans une étape 610, il choisit une date basée sur un objectif de résultat ou non. Si il ne souhaite pas un calendrier basé sur un objectif de résultat, dans une étape 611, il choisit une date de partage, et, dans une étape 612, le contenue à partager est ajouté à une file d’attente, en vue de sa publication à la date choisie.

Dans le cas où l’utilisateur curateur 101 choisit durant l’étape 610 une date basée sur un objectif de résultat, une date préférée de partage ayant été définie préalablement dans une étape 613, le système détermine, dans une étape 614, la date (ou un ensemble de dates) les mieux adaptés à l’objectif de maximisation du résultat, et ajoute ensuite le contenu à publier dans la file d’attente de publication, associé à cette ou ces dates de partage calculés.

Fonctionnement du système de recommandation et classification (figure 7)

Ce système, basé sur les comportements et les actions de l’ensemble des utilisateurs curateurs 101 et utilisateurs lecteurs 106, permet de mettre en avant des contenus, de les catégoriser dans des groupes thématiques, de mettre en relation les utilisateurs lecteurs 106 qui ont les mêmes centres d’intérêts.

La figure 7 illustre son fonctionnement de façon détaillée.

Lorsque un utilisateur quelconque du système lit un contenu, partage un contenu, ou qualifie un contenu avec un marqueur « like », le système enregistre, dans une étape 409, ces actions des utilisateurs, de façon attachée audit contenu pour le qualifier. Le système calcule ensuite dans une étape 410 un score pour le contenu, sur la base de ces divers éléments d’appréciation recueillis au cours de temps.

Selon le résultat d’une étape 411 de comparaison de score à des valeurs seuils prédéfinies, si le score du contenu est inférieur à une première valeur seuil prédéterminée mais supérieur à une seconde valeur seuil prédéterminée, le système calcule (étape 703) trois catégories pertinentes pour le contenu, propose (étape 704) à l’utilisateur de choisir lui-même une catégorie, ce choix de l’utilisateur étant utilisé pour améliorer dans une étape 705 le moteur de choix de catégories automatique. Il est clair que le nombre de catégories calculées peut être supérieur ou inférieur à trois dans des variantes de mis en œuvre du présent procédé.

Enfin, dans une étape 706, le contenu est utilisé pour des recommandations. En d’autres termes, une fois le contenu catégorisé, il est affiché dans une partie dédiée du site dans sa catégorie avec son classement par rapport aux autres contenus dans cette section.

Si le score du contenu est supérieur à la première valeur seuil, il est utilisé pour des recommandations, et, si il n’a pas de catégories attachées, le système calcule, comme précédemment, trois catégories qui viendront le qualifier.

Si le score du contenu est inférieur à la seconde valeur seuil, il n’est pas utilisé pour des recommandations de contenu.

Stockage de données

Le système doit être capable de stocker des gros volumes de données correspondant aux pages indexées lors de l’étape de lecture. L’objectif en terme de nombre d’articles stockés est de 30 millions / jour soit environ 30% des articles parcourus et analysés. Par ailleurs, pour chaque article l’utilisateur peut choisir une image à lui associer. Dans cet objectif, le système devra aussi être capable de stocker un très grand nombre d’images et de pouvoir les servir très rapidement.

Dans un contexte de grande volumétrie, un soin particulier est apporté au fait de pouvoir lire de façon efficace et rapide les articles à proposer à un utilisateur. Pour le stockage des articles extraits du web, les bases de données relationnelles sont difficilement compatibles avec une écriture intensive de données. Ces dernières années ont vu émerger des bases de données non relationnelles (NoSQL). Certaines de ces bases de données sont particulièrement adaptées à l’écriture intensive de données. Le système doit être capable de stocker plus de 30 millions d’articles par jour tout en permettant de servir ces contenus en temps réel aux utilisateurs. Il faut par ailleurs les stocker de façon suffisamment efficace pour pouvoir les fournir rapidement aux utilisateurs.

Ainsi se pose un problème de concurrence en lecture et en écriture. Le système doit être capable d’écrire rapidement une grande quantité d’informations de relativement petite taille (un article) mais aussi de délivrer un ensemble d’articles complets sélectionnés en « batch ».

Afin de pouvoir stocker des données efficacement, le système utilise en parallèle des stockages SQL et NoSQL.

De nombreux système de stockage ont été imaginés pour le stockage des données extraites de l’Internet : - Base de données SQL abandonnée car le volume de données est trop grand, - NoSQL trop lent en lecture.

Aussi, les inventeurs ont développé un système de stockage redondé (GPDB -Grabbed Post Data Base) où les écritures se font en concaténation sur un fichier de données. Chaque requête de lecture lisant entièrement un des fichiers de données. Cette approche permet de bénéficier de très bonnes performances en écriture sans pour autant bloquer les lectures de l’ensemble des données en une seule requête.

La redondance de ce système de stockage est assurée par synchronisation (rsync) du système de fichier d’une machine maître vers un serveur secondaire. Cette synchronisation est effectuée par exemple une fois par jour. Cependant, une telle réplication possède de nombreux inconvénients en cas de perte de la machine maître: - les données ne sont synchronisées qu'une fois par jour, donc elles ne prennent pas en compte les derniers ajout/suppressions, - une action manuelle est requise pour déclarer le second serveur comme serveur maître.

Il est souhaitable de permettre une synchronisation en temps réel des données. Ainsi les inventeurs ont choisi, dans le présent exemple non limitatif de mise en œuvre, d'opter pour une réplication "Maître-Esclave". A l'instar de MySQL, le serveur maître écrit un fichier de log de toutes les actions d'écriture à effectuer sur les données. Le serveur esclave vient lire le fichier de log du maître et exécute les opérations séquentiellement.

Haute disponibilité des serveurs et couches logicielles L’architecture logicielle et matérielle doit être analysée et améliorée pour répondre aux défis de scalabilité. La haute disponibilité d’une plateforme de service Web dépend essentiellement de l’architecture mise en place ainsi que de la capacité des couches logicielles à répondre de façon efficace. D’un point de vue architecture, un cluster LVS permet d’assurer une répartition de charge. Par la suite, il est essentiel d’assurer un second niveau de répartition de charge vers les serveurs applicatifs. Cette seconde couche peut être assurée par des serveurs Apache. D’un point de vue applicatif, deux facteurs sont primordiaux pour permettre une haute disponibilité applicative. Tout d’abord, rendre les serveurs applicatifs sans état permet de s’affranchir des problèmes de synchronisation entre couches applicatives, mais aussi de pouvoir supporter l’arrêt d’une des machines applicatives (maintenance ou panne). D’un autre côté, la base de données constitue souvent le point individuel de défaillance. Il faut donc pouvoir utiliser soit des techniques de réplication Master-Slave ou Master Master, de clustering ou encore de réplication bloc à bloc du système de fichiers hébergeant la base de données. Enfin, la réduction de temps de chargement des pages peut être effectuée par deux axes : l’optimisation des requêtes effectuées mais aussi via une couche de caches distribués, par exemple Memcached.

Le système vise à atteindre un niveau de visibilité élevé sur le web et un nombre important de pages délivrées (typiquement 15 millions de pages vues par mois). La problématique est donc de mettre en œuvre des couches logicielles et matérielles permettant d’absorber des pics de charge tout en garantissant un temps de réponse constant. Les inventeurs ont développé une technique d'écriture dans le cache afin de garantir l'intégrité des données.

On distingue à cet effet trois types d'opérations qui peuvent amener à une écriture d'une ressource dans le cache: - une lecture de la ressource depuis la base de données - une écriture de la ressource dans la base de données - une suppression de la ressource de la base de données

Chaque opération se voit affecter une priorité. Si deux écritures de cache se font "en même temps", l'écriture qui provient d'une opération avec la plus grande priorité l'emporte. Par exemple, si deux serveurs accèdent à la même ressource en même temps, l'un modifie la ressource, l'autre la lit ; seule la version de la ressource provenant de la modification de celle ci devra se retrouver en cache. Il en va de même pour une suppression d'une ressource : la suppression étant définitive, aucune autre mise en cache de la ressource ne doit être possible après la suppression. Le système utilise une "pierre tombale" qui est mise en cache à la place de la ressource avec la plus haute priorité.

La gestion de la concurrence des écritures dans le cache utilise un mécanisme classique de "Compare-and-Swap". Ainsi, les écritures sont garanties séquentielles pour chaque ressource. Le système de priorité affectée à la raison de l'écriture garanti l'intégrité des données en cache vis à vis de notre modèle transactionnel.

Optimisation de référencement

Les moteurs de recherche mettent à jour constamment leurs algorithmes pour s’adapter aux nouveaux usages d’Internet et améliorer la pertinence de leurs résultats, et ces algorithmes restent secrets.

Au niveau de la structure du contenu, le système utilise l’ajout de tags sémantiques HTML5 dans le code source des pages. Ces tags <article>, <header>, <nav>, <footer>,... permettent aux moteurs de recherche d'identifier plus facilement la structure des pages et les contenus qui y sont mis en avant.

Le dé-doublonnage des URLs de pages qui partagent la même URL car elles sont chargées en Ajax (par exemple lors de navigations par onglets) sera mis en place. L'utilisation de la fonction PushState permet aux moteurs de recherche de faire la distinction entre ces pages, et donc d'accroître le nombre de pages indexées.

Avantages

Le système décrit plus haut permet de découvrir, de suggérer et d’organiser les articles du web en fonction des intérêts des utilisateurs et d’offrir aux utilisateurs une visibilité accrue sur le web.

Le système est une plateforme qui doit être en permanente évolution et enrichie constamment de nouveau contenu et doit être en permanence capable de proposer des contenus de plus en plus proches des intérêts de chaque utilisateur tout en restant rapide et capable de répondre à la charge de l’audience en constante augmentation. De plus le système permet de positionner l’utilisateur comme leader de pensée dans sa thématique. Pour cela le système doit permettre de partager au bon moment sur les réseaux sociaux.

Claims (10)

1. REVENDICATIONS

   1. Procédé d’extraction d’informations au sein d’un ensemble d’informations, selon un critère de pertinence prédéterminé, caractérisé en qu'il comporte des étapes suivantes : 301 de détermination par un utilisateur curateur (101) de mots clés relatifs à un sujet prédéterminé, ou de sources de recherche à utiliser, définissant ainsi une recherche de l’utilisateur, 302 de recherche selon les mots clés choisis par l’utilisateur curateur (101) complétés par des mots clés suggérés par un moteur de suggestion, dans un ensemble de sources comprenant les sources choisies par l’utilisateur curateur (101) complété par d’autres sources suggérées par le moteur de suggestion, et de suggestion de contenu à l’utilisateur curateur (101) selon une distance par rapport à la recherche de l’utilisateur, 303 d’analyse par l’utilisateur curateur (101) de ces données et de détermination, pour chacune d’elles, si elle répond à un critère de pertinence prédéterminé, 304, dans le cas où la donnée répond au critère de pertinence, de caractérisation de la donnée comme publiable au sein d’un dossier relatif au sujet choisi, 305 de qualification de la pertinence de chaque donnée suggérée vis à vis de la recherche de l’utilisateur, 306 de modification des paramètres du moteur de suggestion selon cette qualification des données, en créant ainsi une boucle de rétroaction et d’apprentissage dudit moteur de suggestions.
2. 2. Procédé selon la revendication 1, comportant également une étape suivante : 308, de détermination d’un ou plusieurs sites de publication, et de dates de publication, selon des critères préalablement déterminés de maximisation de la visibilité de la publication ainsi réalisée.
3. 3. Procédé selon l’une quelconque des revendications 1 à 2, comportant : - une étape 406 de calcul d’un nombre de vues pour chaque page vue par un, une partie ou tous les utilisateurs curateurs (101) et/ou utilisateurs lecteurs (106), - une étape 410 de calcul d’un score pour chaque contenu, selon le nombre de pages vues et selon le type d’action réalisé par un utilisateur lecteur (106) sur ce contenu : suivre 407, partager 408, recommander 409, - une étape 411 d’analyse des scores pour recommander et catégoriser les contenus en vue de leur qualification par les utilisateurs curateurs (101) et/ou utilisateurs lecteurs (106).
4. 4. Procédé selon la revendication 3, dans lequel la catégorisation est réalisée en utilisant au moins un algorithme d’apprentissage machine (« machine learning ») automatique.
5. 5. Procédé selon l’une quelconque des revendications 1 à 4, dans lequel le moteur de suggestion met en oeuvre : une étape 502, dans laquelle les mots clefs choisis dans l’étape 301 sont utilisés pour parcourir des domaines de données pour en extraire des adresses URL de pages pertinentes au regard de ces mots clefs, une étape 501, dans laquelle le système récupère le contenu des pages web sélectionnées et les stocke en mémoire, une étape 503, dans laquelle le système extrait de ces pages web les textes, images et éventuelles adresses de flux RSS associées, une étape 504, dans laquelle ces flux RSS sont stockés et viennent alimenter une base de données (505), une étape 506, de parcours en boucle des URL de flux RSS pour rechercher les URL de RSS correspondants aux mots clefs prédéfinis, une étape 507 de chargement de ces flux RSS, une étape 514 dans laquelle, à partir des textes, images et flux RSS extraits lors de l’étape 503, le système indexe et stocke des éléments de suggestions, ces suggestions venant alimenter une base de données (515) de suggestions, une étape 516, dans laquelle le système effectue une recherche des mots clés sélectionnés par l’utilisateur dans la base de suggestions, une étape 517 de filtrage des données extraites selon cette recherche pour en éliminer les pages déjà vues par l’utilisateur lors d’une présente recherche, une étape 518 d’application d’autres filtres définis préalablement par ledit utilisateur, une étape 519, dans laquelle les suggestions sont triées selon des critères prédéfinis.
6. 6. Procédé selon l’une quelconque des revendications 1 à 5, dans lequel, dans l’étape 308, le système se base sur l’ensemble des données déjà existant tant au niveau de l’utilisateur curateur (101) que de l’ensemble des utilisateurs curateurs (101) et/ou utilisateurs lecteurs (106) pour déterminer pour chaque triplet audience / thème / réseau de publication, un ensemble de moments et intervalles de publication considérés comme les plus efficaces selon un critère prédéterminé.
7. 7. Procédé selon la revendication 6, comportant en outre une étape dans laquelle le système extrait, pour chaque article partagé, le nombre de réactions qu’il génère, calcule un score pour chaque partage, et en déduit les heures les plus propices au partage sur chacun des réseaux sociaux.
8. 8. Procédé selon la revendication 7, comportant une étape 605 dans laquelle les détails de chaque partage (date, heure, contenu, destination etc.) sont stockés, et une étape 606, dans laquelle le système analyse l’impact obtenu par le partage réalisé, de manière à alimenter une base de données pour un apprentissage machine.
9. 9. Procédé selon l’une quelconque des revendications 1 à 8, dans lequel, l’étape 306 met en œuvre un algorithme basé sur les comportements et les actions de l’ensemble des utilisateurs curateurs (101) et/ou utilisateurs lecteurs (106), permettant de mettre en avant des contenus, de les catégoriser dans des groupes thématiques, de mettre en relation des utilisateurs qui ont les mêmes centres d’intérêts.
10. 10. Procédé selon la revendication 9, comportant : une étape 409 d’enregistrement des actions de chaque utilisateur lecteur (106) : lecture d’un contenu, partage d’un contenu, qualification d’un contenu, ou recommandation d’un contenu, de façon attachée audit contenu pour le qualifier. une étape 410 de calcul d’un score pour le contenu, sur la base de ces éléments de qualification recueillis au cours de temps, une étape 411 de comparaison du score à des valeurs seuils prédéfinies, i) si ce score du contenu est inférieur à une première valeur seuil prédéterminée mais supérieur à une seconde valeur seuil prédéterminée, une étape 703 de calcul de catégories pertinentes pour le contenu, une étape 704 de proposition à l’utilisateur de choisir lui-même une catégorie, ce choix de l’utilisateur étant utilisé pour améliorer dans une étape 705 le moteur de choix de catégories automatique, une étape 706, d’utilisation du contenu pour des recommandations, ii) si ce score du contenu est supérieur à la première valeur seuil, le contenu est utilisé pour des recommandations, et, si il n’a pas de catégories attachées, le système calcule, comme précédemment, des catégories qui viendront le qualifier.