plateforme d'un site internet

DOMAINE TECHNIQUE GENERAL

La présente invention concerne le domaine de l'analyse de données utilisateur pour le e-commerce.

Plus précisément elle concerne un système de traitement de données de connexion à une plateforme d'un site Internet, le procédé étant dédié notamment aux traitements statistiques, au forage de données ("datamining" dans la terminologie anglo-saxonne), à la conception d'outils d'aide à la décision, aux diagnostics, à la prévision ou à l'approximation, à la conception de simulateurs, de systèmes d'apprentissage automatique ou d'aide à l'apprentissage et d'une manière générale à la conception de systèmes d'analyse de situations ou analyse situationnelle.

ETAT DE L'ART

Le développement d'internet a entraîné l'essor du commerce en ligne, ou « e-commerce ». De nombreux services allant de la vente de produits à la mise en relation d'utilisateurs en passant par la banque ou la presse sont ainsi proposés sur les réseaux.

Le e-commerce a entraîné dans son sillage l'apparition du « e- business », c'est-à-dire tout ce qui peut être mis en œuvre en amont pour concrétiser une transaction et par la suite assurer la fidélisation client, en particulier le marketing électronique.

En effet, bien que la vente en ligne permette théoriquement la personnalisation à l'extrême de la relation-client, l'anonymat qui règne sur Internet empêche l'application des règles marketing traditionnelles, qui sont basées sur le ciblage et la différentiation des clients.

Comprendre l'internaute est donc essentiel. Certains acteurs du e- commerce proposent ainsi à leurs client de remplir des profils permettant de mieux les identifier, ce afin de leur offrir une approche personnalisée, comme le ferait un vendeur dans un magasin. Cette solution est toutefois contraignante pour l'internaute, lequel est en outre souvent réticent à donner des informations personnelles.

Des techniques connues proposent la collecte de « données comportementales » de l'internaute, par exemple via le contenu de son historique, afin de mieux l'identifier et de personnaliser les contenus en particulier publicitaire qu'il reçoit. Ces techniques n'apportent toutefois qu'une compréhension partielle de l'internaute, et ne permettent d'en déduire que peu d'informations.

La présente invention propose un système de traitement de données de connexion alternatif qui, par une architecture inédite, permet de déterminer de situations d'utilisateurs connectés à la plateforme d'un site Internet, puis de les analyser pour obtenir des données et prédire d'autres situations, sans être dépendant d'un modèle ou d'une structure d'implémentation physique ou logique.

PRESENTATION DE L'INVENTION La présente invention propose un système de traitement de données de connexion à une plateforme d'un site Internet, caractérisé en ce qu'il comprend :

- au moins deux modules indépendants de traitement de données de connexion, les modules de traitement étant répartis en moins deux groupes complémentaires, les modules d'un groupe étant configurés pour mettre en œuvre un sous-ensemble des opérations nécessaires pour l'exécution d'un procédé de traitement des données de connexion d'un utilisateur via un équipement à ladite plateforme comprenant l'identification d'une situation de l'utilisateur, les modules de traitement de chaque groupe recevant des données issues des modules de traitement d'un autre groupe de sorte à compléter la totalité du procédé de traitement de données de connexion ; - un module répartiteur qui reçoit lesdites données de connexion et les transmet aux modules de traitement ;

- un module réconciliateur qui collecte les données issues des modules de traitement et délivre des données traitées de connexion à ladite plateforme et/ou à l'équipement de l'utilisateur.

Selon d'autres caractéristiques avantageuses et non limitatives de l'invention :

• les différents modules s'échangent des données sous la forme de flux XML ;

• les modules de traitement d'un groupe mettent en œuvre les opérations en temps réel, et les modules d'un autre groupe mettent en œuvre les opérations différées ;

• les modules de traitement d'un groupe sont des modules de pré- traitement configurés pour identifier les situations d'utilisateurs connectés à ladite plateforme, et les modules de traitement d'un autre groupe sont des modules de post-traitement configurés pour traiter des situations identifiées d'utilisateurs connectés ;

• le ou les modules de pré-traitement collectent des données issus du ou des modules de post-traitement de sorte à influer sur l'identification des situations ;

• les modules de traitement de chaque groupe mettent en œuvre le procédé de traitement spécifiquement pour les utilisateurs naviguant sur les pages du site internet relatives à une ou plusieurs lignes de services données ;

• les modules de traitement sont connectés à une bibliothèque de moteurs situationnels exécutables et/ou à une base de données contenant une ontologie caractéristique dudit site internet. BREVE DESCRIPTION DES FIGURES D'autres caractéristiques et avantages de la présente invention apparaîtront à la lecture de la description qui va suivre d'un mode de réalisation préférentiel. Cette description sera donnée en référence aux dessins annexés dans lesquels :

- la figure 1 est un schéma d'une architecture réseau dans laquelle s'inscrit l'invention ;

- la figure 2 est un diagramme représentant schématiquement les étapes du procédé de traitement de données de connexion selon l'invention ;

- la figure 3 est un schéma d'un mode de réalisation d'un système de traitement de données de connexion selon l'invention ;

- la figure 4 représente un module de traitement d'un système de traitement de données de connexion selon l'invention ;

- la figure 5 est un schéma d'un module de traitement immédiat d'un mode de réalisation d'un système de traitement de données de connexion selon l'invention ;

- la figure 6 est un schéma d'un module de traitement différé d'un mode de réalisation d'un système de traitement de données de connexion selon l'invention.

DESCRIPTION DETAILLEE D'UN MODE DE REALISATION PREFERE

Situations Contrairement à tous les procédés de traitement connus, le procédé de traitement de données selon l'invention est basé comme mentionné précédemment sur l'analyse de « situations » complètes, et non sur une simple liste de paramètres.

Dans la suite de la présente description, on décrira plus particulièrement l'application du procédé au domaine mentionné précédemment du e-commerce (dans ce cas lesdites données sont des données de connexion à une plateforme d'un site Internet), mais on comprendra qu'il peut être transposé au traitement de données utilisateur de façon générale sur un poste de travail. Les données peuvent en effet être les e-mails de l'utilisateur, ses paramètres système, etc. Le traitement de données de connexion donne d'excellents résultats en terme d'identification de situation grâce au volume et à la diversité de telles données.

On entend ici par "situation" d'un utilisateur une information plus ou moins complexe et plus ou moins floue décrivant les notions d'ordre psychologique, sociologique de l'utilisateur et sa scène situationnelle (l'ensemble des situations des autres utilisateurs connectés). Une situation peut être nommée par un terme porteur de sens pour le e-commerçant, comme par exemple « butineuse de l'après-midi » pour désigner des femmes qui surfent sur internet après déjeuner sans idées préconçues.

L'analyse situationnelle ouvre ainsi de grandes perspectives dans de nombreux domaines économiques utilisant des outils d'analyse, de prédiction et de simulation. Des processeurs d'analyse situationnelle (voir par exemple la demande de brevet français FR2962823) sont capables de façon autonome de recevoir en entrée un ou plusieurs flux situationnels, d'en extraire des situations, de distinguer les éléments importants et de leur appliquer en continu des traitements, de détecter des phénomènes et de prévoir des évolutions de solutions, notamment par induction.

Les avantages sont multiples : comme on va le voir les systèmes situationnels ne sont pas contraints par des modèles ou des architectures d'implémentation, et s'adaptent donc en permanence. Ils sont capable, à l'instar du cerveau humain, de se concentrer sur l'essentiel en gérant leurs ressources. Enfin, leurs possibilités apparaissent bien plus universelles que celles de n'importe quel système expert actuel, cloisonné dans un domaine particulier.

Le principe du procédé de traitement de données (le traitement étant réalisé par un serveur comprenant au moins une unité de traitement de données et des moyens de stockage de données, le serveur étant dans le cas du traitement de données de connexion à une plateforme d'un site Internet en connexion réseau avec ladite plateforme) selon l'invention est ainsi d'identifier par un premier mécanisme la situation d'un ou plusieurs utilisateurs, puis de traiter par un deuxième mécanisme les situations collectés dans une deuxième temps. Les utilisateurs concernés sont dans le cas du-e-commerce des utilisateurs connectés à ladite plateforme via un équipement, voire tous les internautes visiteurs si les ressources du serveur le permettent (voir plus loin).

Ce traitement peut avoir plusieurs destinataires et de nombreuses finalités, comme il sera également expliqué plus loin.

La figure 1 représente l'architecture réseau dans laquelle l'invention s'inscrit. Un équipement 3 (on comprendra qu'il peut s'agit de toute sorte d'équipement informatique sur lequel un utilisateur peut accéder à Internet, du poste de travail au terminal mobile tel qu'un smartphone ou une tablette tactile) est connecté à la plateforme 2 d'un site internet via le réseau internet 4. Le serveur 1 comprenant au moins une unité de traitement de données et des moyens de stockage de données pour la mise en œuvre du procédé est en connexion réseau avec ladite plateforme 2.

Il est important de comprendre que le terme « plateforme » désigne un ou plusieurs serveurs interconnectés du site internet sur lequel sont hébergées la ou les pages de site internet que l'utilisateur est en train de consulter. Le serveur 1 qui réalise le traitement peut être l'un de ces serveurs qui composent la plateforme 2. L'équipement utilisateur 3 est dans tous les connecté directement ou indirectement (via la plateforme 2) à travers le réseau internet au serveur 1 qui met qui en œuvre le procédé. Il est à noter que la connexion entre le serveur de traitement 1 et la plateforme 2 peut être locale, mais alternativement rien n'interdit qu'elle repasse par le réseau internet 4.

Premier mécanisme : Identification d'une situation Comme le montre la figure 2, l'identification de la situation d'un utilisateur connecté à ladite plateforme se fait parmi une liste de situations de référence, lesquelles peuvent être soit prédéfinies à partir de l'observation des comportements des internautes, soit de façon particulièrement avantageuse automatiquement générées par un autre mécanisme qui sera décrit plus loin.

Pour ce faire, le mécanisme d'identification de situation du procédé selon l'invention utilise des « déclencheurs ». Les déclencheurs, mieux connus sous l'appellation anglo-saxonne « triggers », sont des modules logiciels qui sont aptes à s'activer et provoquer un traitement particulier en fonction d'événements prédéfinis.

Les triggers peuvent être de nombreux types. Dans un premier type, l'événement est une action de l'internaute comme un clic de consultation, un clic de sélection, etc. Dans un second type l'événement est l'expiration d'un délai, par exemple après la dernière visite de l'internaute, ou par rapport à la précédente activation du trigger (dans ce dernier cas il s'active à une fréquence fixe, par exemple toutes les heures). On comprendra que de nombreuses autres configurations sont possibles.

A l'activation d'un trigger donné, les moyens de traitement de données du serveur 1 déclenchent une tentative de détermination de l'état d'au moins un « indice ». Les indices sont divers éléments porteurs de signification pour une situation. Certains indices concernent la « scène situationnelle », c'est-à-dire l'ensemble ou un sous-ensemble des situations des internautes connectés qui se déroulent concomitamment. Il s'agit par exemple de l'heure, de la météo, etc. Alternativement, certains indices concernent la « sphère situationnelle », c'est-à-dire la situation particulière de l'internaute. Il s'agit alors par exemple de l'âge, le genre, la taille de l'internaute, sa navigation (rapide, hésitante, etc.) son état (pressé, en recherche, etc.). Les indices sont donc relatifs à des données personnelles dudit utilisateur connecté à la plateforme 2 et/ou relatifs à des données générales. La combinaison de ces deux « zones » situationnelles offre en pratique de bons résultats pour la détermination fiable de la situation d'un utilisateur.

Naturellement, certains indices relatifs à des résultats espérés (par exemple la conclusion ou non d'une transaction) sont spécialement impliqués, en particulier en vue de l'analyse des situations. La ou les unités de traitement du serveur 1 disposent ainsi d'une collection d'indices observables prédéterminée. Il est à noter qu'observable ne signifie pas forcément déterminable. Une tentative de détermination de l'état d'un indice peut ne pas être fructueuse. Par exemple l'âge de l'internaute n'est pas forcément accessible. L'indice est alors considéré comme « indiscernable ». Il n'est toutefois pas exclu qu'une tentative ultérieure (via le même trigger ou un autre) soit cette fois couronnée de succès.

Une liste des indices à tenter de déterminer est associée à chaque trigger. Si ce trigger est activé, ce seront ces indices et seulement ces indices dont l'état sera observé. A titre d'exemple, un trigger périodique pourra tenter de déterminer la météo ou le nombre de clics par seconde de l'utilisateur. Alternativement, un trigger lié au clic sur le bouton « envoyer » à la fin d'un formulaire pourra tenter de déterminer l'âge et le genre de l'utilisateur en fonction du texte saisi.

En fonction des résultats de ladite tentative de détermination de l'état d'au moins un indice, la ou les unités de traitement génèrent et stockent sur les moyens de stockage du serveur 1 une signature situationnelle de l'utilisateur (si une situation situationnelle existe déjà, elle est seulement mise à jour).

La signature situationnelle d'un utilisateur correspond à l'ensemble des données relatives aux indices, lesquelles permettent de caractériser la situation de l'utilisateur.

Avantageusement, une signature situationnelle est en particulier composée d'une pluralité d'unités d'information chacune étant associée à un indice (avantageusement on trouve deux parties dans une signature situationnelle, les unités étant appelées respectivement « thresholds » si l'indice associé est relatif à la scène situationnelle, et « trackers » si l'indice associé est relatif à la sphère situationnelle), chaque unité d'information pouvant prendre au moins trois valeurs dont une première valeur si l'état déterminé de l'indice associé correspond à un état de référence (valeur « 1 »), une deuxième valeur si l'état déterminé de l'indice associé ne correspond pas à l'état de référence (valeur « 0 »), et une troisième valeur (valeur « X ») si l'état de l'indice associé n'a pas pu être déterminé (que ce soit parce qu'aucune tentative de détermination n'a été faite pour l'indice associé, ou parce que la tentative qui a suivi le déclenchement du trigger n'a pas réussi). Chaque unité d'information est alors un « bit » à trois valeurs.

On comprendra que les notations 0, 1 et X sont purement illustratives et que l'homme du métier pourra choisir la représentation de données de son choix. En particulier, on peut envisager utiliser des unités d'information n'ayant pas un nombre déterminé de valeurs et aptes à stocker par exemple des nombres, des chaînes de caractère, etc. On verra toutefois plus loin l'intérêt d'avoir des unités d'information à n états. En utilisant la notation définie précédemment, 1 X10 01 XX est un exemple de signature situationnelle à 8 unités d'information.

On note en outre que bien qu'ici on ne distingue pas les cas « aucune détermination tentée » / « détermination tentée mais infructueuse » (même valeur « X »), l'information selon laquelle une détermination a été tentée peut être alternativement prise en compte. En effet, bien que l'information que constitue l'état de l'indice n'ait pas pu être obtenue, le fait que la tentative ait échoué peut être porteur d'information. Par exemple cela peut signifier que l'utilisateur a volontairement (voire involontairement) occulté des pans de son profil et donc qu'il peut être quelqu'un cherchant à augmenter sa confidentialité internet.

Il est à noter que certains trackers ou thresholds peuvent s'appuyer sur des intégrateurs de loi de distribution, par exemple de gauss ou de poisson, afin de leur conférer un caractère rémanent. En d'autres termes, les intégrateurs « prévoient » l'état que doit avoir l'indice en fonction des précédentes observations, ce qui évite à court terme la nécessité de redéclencher une tentative de détermination lorsque la précédente s'est faite il y a peu.

La signature situationnelle de l'utilisateur est alors comparée avec une pluralité de « masques ». Chaque masque est associé à une situation de référence, et correspond à un espace de signatures situationnelles. Pour cela, chaque masque est constitué comme une signature d'une pluralité d'unités d'informations, pouvant prendre les valeurs 0, 1, X, mais aussi une quatrième valeur (notée « A ») si l'unité d'information peut être quelconque. L'état de certains indices n'est en effet pas caractéristique de certaines situations.

Par exemple 10A0 AAX1 est un masque à 8 unités d'information qui regroupe les signatures suivantes : 1000 00X1, 1000 01X1, 1000 0XX1, 1000 10X1, 1000 11X1, 1000 1XX1, 1000 X0X1, 1000 X1X1, 1000 XXX1, 101000X1, 101001X1, 10000XX1, 1010 10X1, 1010 11X1, 1010 1XX1, 1010 X0X1, 1010 X1X1, 1010 XXX1, 10X000X1, 10X001X1, 10X00XX1, 10X010X1, 10X011X1, 10X01XX1, 10X0 X0X1, 10X0X1X1, 10X0 XXX1.

La comparaison entre la signature et un masque se fait alors facilement grâce à des portes logiques (on compare chaque unité du masque n'ayant pas pour valeur « A » avec l'unité correspondante sur la signature grâce à XOR, et on applique AND sur les résultats de ces comparaisons). Lorsqu'un masque correspond, on identifie la situation dudit utilisateur connecté à la plateforme 2 comme étant la situation de référence associée à l'au moins un masque contenant ladite signature situationnelle.

Il est à noter qu'une pluralité de masques est avantageusement stockée sur les moyens de stockage du serveur 1, et qu'il n'est pas impossible que certains des masques aient des portées qui se recoupent, en d'autres termes qu'il n'y ait pas unicité du masque correspondant à une situation donnée. Pour résoudre cette difficulté, les masques sont avantageusement testés itérativement selon un roulement : si le test est positif, la situation de référence associée au masque est retenue, sinon le masque suivant est testé. Lorsqu'un nouveau trigger est activé, le même masque de situation est retesté en premier afin de maintenir si possible la stabilité de la situation actuelle.

A l'issue de cette première phase du procédé, on dispose donc d'une situation identifiée comme étant la situation de l'utilisateur.

Deuxième mécanisme : Traitement de la situation Le deuxième mécanisme du procédé selon l'invention consiste en une analyse de la situation identifiée de l'utilisateur par des moyens physiques ou logiques d'analyse situationnelle du serveur 1 de sorte à obtenir des données traitées, qui vont être porteuses de sens pour l'utilisateur, un gestionnaire du site internet, etc. Les moyens d'analyse situationnelle peuvent consister en une application exécutée par les moyens de traitement de données du serveur 1 (on peut envisager un processeur multi-cœur dont des cœurs sont dédiés à cette analyse situationnelle, voir plus loin).

Pour cela, chaque situation de référence est associée à au moins une « stratégie » (avantageusement 1 à 3), c'est-à-dire un ensemble composé d'un ou plusieurs moteurs situationnels (ainsi que les éventuels paramètres de ces moteurs) et de contenus de messages, c'est-à-dire des textes, des contenus graphiques (incluant des images, des vidéos, etc.), des liens URL (Uniform Resource Locator), des éléments de forme (format, paramètres de police, etc.), et tout autre donnée utile à la personnalisation d'un message. Par message (également appelé recommandation) on entend toute forme de communication résultant du traitement des données de connexion et ayant un effet escompté sur la situation.

Tout à fait classiquement, il peut s'agir de messages de compte- rendu adressés au gestionnaire du site (sous la forme de mails par exemple), mais il peut s'agir surtout de messages destinés à l'utilisateur dont la situation est en cours de traitement. Par exemple, ce peut être un bandeau qui s'affiche la page internet qu'il consulte, un mail, un SMS, etc.

Le ou les moteurs situationnels sont des éléments logiciels choisis parmi une bibliothèque de moteurs situationnels. Chaque moteur situationnel est ainsi apte à mettre en œuvre un traitement donné sur une situation d'un utilisateur (le moteur prend en compte des paramètres de toute la scène et la sphère situationnelles : en effet, si la signature situationnelle d'un utilisateur est unique, la situation identifiée ne l'est pas. La prise en compte des unités d'information, c'est-à-dire des états des indices observés, permet de personnaliser le traitement) de sorte à obtenir un ou plusieurs messages ayant un effet escompté sur la situation. Un premier exemple de moteur peut mettre en œuvre une recommandation d'un ou plusieurs produits connexes à ceux visités (on oriente vers les situations du magasin). Un deuxième exemple de moteur peut mettre en œuvre une recommandation de produits achetés par des internautes dans une situation similaire à la situation identifiée de l'utilisateur (on est au niveau personnel). Dans un troisième exemple de moteur, on peut tout simplement recommander des produits à la mode (détection d'une hausse des ventes significatives, on est au niveau de la sociologie de groupe).

II est à noter qu'une même stratégie peut être associée à plusieurs situations et que chaque stratégie peut relever d'un niveau « d'essentialité », c'est-à-dire un critère de priorité qui peut être important en cas de forte affluence d'utilisateurs.

Pour au moins une des stratégies associées avec ladite situation identifiée (on peut les analyser par ordre d'essentialité), les moyens de traitement du serveur 1 mettent en œuvre les moteurs situationnels associés de sorte à obtenir au moins une pile de messages. Avantageusement, on génère au moins deux piles de messages (avantageusement trois), chacun étant associée à un niveau de confidentialité. Par niveau de confidentialité on entend le niveau de publicité du message. Par exemple, dans une mise en œuvre du procédé à deux niveaux de confidentialité, le niveau 1 correspond à des messages personnels, alors que le niveau 2 correspond à des messages globaux (par exemple un bandeau sur le site). Les trois exemples de moteurs décrits précédemment correspondent à trois niveaux de confidentialités distincts : le premier présente un niveau de confidentialité « faible », puisqu'il est destiné à tout utilisateur ; Le deuxième présente un niveau de confidentialité « élevé », puisque la recommandation est personnelle, et n'est donc destinée qu'à l'utilisateur. Le troisième correspond à un niveau de confidentialité « moyen », puisque l'exposition se fait au niveau du groupe. Les trois recommandations produites par ces trois moteurs se retrouveraient donc dans trois piles différentes. Ces piles de messages sont alors dépilées pour « exposer » les messages, c'est-à-dire les transmettre à leur destinataire. Plus précisément, cela consiste à envoyer à destination (selon le cas) de l'équipement 3 dudit utilisateur et/ou de la plateforme 2 (quand il s'agit d'éléments de pages) un sous-ensemble des messages de ladite au moins une pile de messages.

Ce peut être fait via une simple politique LIFO (Last In First Out, « Dernier Entré, Premier Sorti »), mais avantageusement une stratégie dite à jetons est mise en œuvre. Dans cette stratégie, la page courante comprend des zones d'exposition aptes à recevoir un message dans un format donné et présentant des paramètres donnés. Les zones, lorsqu'elles sont disponibles, émettent un jeton comprenant les différents paramètres de la zone. Un moteur situationnel reçoit le jeton et constitue « sur commande » un ou plusieurs messages en fonction de ces paramètres. Les messages disposant du jeton sont alors extraits de la pile avant les autres.

L'exposition du ou des messages affecte la situation (par exemple en provoquant une transaction si elle a eu l'impact escompté sur l'utilisateur), ce qui a des chances d'activer de nouveaux triggers et d'entraîner le changement de la situation dans laquelle se trouve l'utilisateur. Le procédé est ainsi relancé et l'effet des messages sera observé au prochain cycle d'analyse.

Optimisation des capacités de traitement L'activité des internautes n'est pas constante au cours de la journée, et en particulier à des périodes de pics les moyens de traitement de données du serveur 1 peuvent avoir des difficultés à faire face à l'afflux d'information (en d'autres termes le volume du flux à traiter).

Avantageusement le système tient compte de ces variabilités du trafic et régule le procédé. En particulier, le procédé mobilise avantageusement les ressources nécessaires pour identifier les situations de tous les utilisateurs connectés (la première partie du procédé est moins consommatrice de ressources que la seconde), mais n'en analyse qu'une partie selon les capacités disponibles, triés en particulier sur le niveau « d'essentialité » des stratégies mentionné précédemment.

Pour cela, trois niveaux graduels d'activité sont définis (ici appelés « alphafloor », « betafloor » et « gammafloor »), le fonctionnement passant dans un mode dégradé (on laisse tomber certaines situations au-delà d'un seuil) ou différé (des situations jugées intéressantes ne sont pas traités tout de suite à cause de l'engorgement, mais le seront plus tard lorsque l'activité sera plus faible). La précision de l'analyse d'une situation peut également varier en fonction du niveau d'activité : si les ressources manquent on va à l'essentiel (mode essentiellement déductif), et sinon on réalise une analyse précise (mode essentiellement inductif) pour lequel on a plus de réflexe. Dans le cas d'une semi ou non supervisé (voir plus loin), en cas de ressources disponibles on favorise l'apprentissage. Les trois niveaux précédents sont définis en fonction des niveaux d'activité typiques sur le site en nombre d'actions par seconde.

L'alphafloor correspond à un niveau d'activité « élevé ». Par exemple sur un site où l'on observe jusqu'à 1000 connexions simultanée, en supposant qu'un utilisateur produit un clic (ou tout autre action comme une saisie) toutes les 10 secondes en moyenne, l'alphafloor est à 100 Hz.

Le betafloor correspond à un niveau d'activité « moyen ». Par exemple si sur le même site on observe 100000 connexions par jour et on constate qu'un internaute reste 1 min 30 secondes en moyenne, le betafloor est à 10,4 Hz.

Le gammafloor correspond à un niveau d'activité « faible ». Par exemple, si on observe sur le site un ratio de 1 à 100 entre le maximum et le minimum de connexions simultanées sur une journée (soir un minimum de 10 connexions simultanées à 9 secondes par clic), le gammafloor est à 1 ,1 1 Hz.

Dans le cas inverse (plus de capacités de traitement disponibles que nécessaire), le procédé peut utiliser des « Shadows », c'est-à-dire maintenir des situations rémanentes d'anciens utilisateurs, afin d'augmenter la base d'apprentissage. Modes semi-supervisé et non-supervisé

Le procédé nécessite un ensemble de situations de référence pour fonctionner, mais cet ensemble n'est pas figé et peut évoluer. En particulier, les stratégies peuvent comporter des moteurs situationnels configurés pour que des messages soient émis pour signaler en particulier à destinataire d'un gestionnaire du site l'émergence d'une nouvelle situation. Le gestionnaire peut décider d'en faire une nouvelle situation de référence.

Dans un mode semi-supervisé, le système suggère au gestionnaire de nouvelles situations de référence (associées à un masque prédéterminé par le moteur situationnel), et ce dernier peut valider ou non ces propositions. Alternativement, dans un mode non-supervisé (tel que celui représenté par la figure 2), le système est complètement automatique et inclut de lui-même les nouvelles situations de référence.

Il est à noter que l'observe l'apparition de nouvelles situations par « bourgeonnement ». En d'autres termes, ce que les moteurs détectent est l'émergence d'une sous-catégorie d'une situation large (par exemple si une part non négligeables des signatures situationnelles correspondant à une situation de référence s'avèrent présenter des états identiques pour des indices qui étaient classés « A », c'est-à-dire non pris en compte dans le masque). Alternativement, pour une situation de référence donnée, on peut tenter de sélectionner les situations qui ont débouché sur une transaction, afin de détecter les messages efficaces.

Processeurs réflexes

Selon un deuxième aspect, l'invention concerne un système 1 , en particulier un serveur 1 comprenant au moins une unité de traitement de données et des moyens de stockage de données, ladite au moins une unité de traitement étant configurée pour la mise en œuvre du procédé selon le premier aspect lors de la connexion d'un utilisateur à une plateforme 2 d'un site via un équipement 3. Comme l'on a expliqué, le plus souvent le procédé est mis en œuvre par un serveur du site qui est distinct des serveurs qui composent la plateforme 2 (c'est-à-dire les serveurs qui hébergent les pages du site et gèrent le fonctionnement du site), l'équipement 3 de l'utilisateur étant alors connecté audit serveur pour la mise en œuvre du procédé via la plateforme 2.

De façon particulièrement préféré, le deuxième aspect de l'invention concerne un système 1 de traitement de données de connexion à une plateforme 2 d'un site Internet dont un mode de réalisation particulièrement préféré est représenté sur la figure 3. Ce système comprend

- au moins deux modules indépendants 21 , 22 de traitement de données de connexion (modules « SALI2 » dont SALIX et SALIC sont deux versions), les modules de traitement 21 , 22 étant répartis en moins deux groupes complémentaires, les modules 21 , 22 d'un groupe étant configurés pour mettre en œuvre un sous-ensemble des opérations nécessaires pour l'exécution d'un procédé de traitement des données de connexion d'un utilisateur à ladite plateforme 2 comprenant l'identification d'une situation de l'utilisateur, les modules de traitement 21 de chaque groupe recevant des données issues des modules de traitement 22 d'un autre groupe de sorte à compléter la totalité du procédé de traitement de données de connexion ;

- un module répartiteur 10 (« RENZO ») qui reçoit lesdites données de connexion et les transmet aux modules de traitement 21 , 22 ;

- un module réconciliateur 30 (« RENALDO ») qui collecte les données issues des modules de traitement 21 , 22 et délivre des données traitées de connexion à ladite plateforme 2. Ces modules 10, 21 , 22, 30 sont appelés des processeurs réflexes, à cause de leur aptitude à traiter sans a priori les données en entrée. Le principe est donc d'avoir deux (voire plus) groupes de n modules 21 , 22, les modules 21 , 22 d'un groupe effectuant en parallèle la même tâche, et les tâches de chacun des groupes étant complémentaires pour réaliser le traitement des données de connexion. Les différents modules 21 , 22 peuvent être soit des processeurs physiquement indépendants (et reliés par un bus), chacun disposant de ses moyens de traitement et de son espace de stockage, ou alternativement des briques logicielles mises en œuvre sur un équipement donné, les modules partageant alors des mêmes ressources processeur (éventuellement multi-cœur) et un même espace de stockage. Il est à noter que le système 1 peut être réparti sur plusieurs serveurs voire être installé en cloud-computing sur des machines virtuelles Les modules 21 , 22 s'échangent avantageusement des données sous la forme d'un flux dans un langage d'abstraction, par exemple XML (extensible Markup Language), JSON (JavaScript Object Notation), le protocole SOAP (Simple Object Access Protocol), Silvia ou encore Mawerick.

En référence à la figure 4 est représenté schématiquement un module de traitement 21 , 22 (indifféremment du groupe) de type SALI2. Comme l'on voit, il possède avantageusement 7 ports d'entrée/sortie. Il est en effet souhaitable que les modules 21 , 22 soient connectés à une bibliothèque de moteurs situationnels exécutables et/ou à une base de données contenant une ontologie caractéristique dudit site internet afin de pouvoir mettre en œuvre les étapes de procédé précédemment expliquées.

En particulier :

- Le port OBS (observateur) reçoit les données en provenance de la plateforme 2 sous forme de flux XML ;

- Le port COL (collecteur) reçoit les données en provenance des autres modules de traitement 21 , 22 SALI2 sous forme de flux XML ;

- Le port ONT (ontologie) reçoit l'ontologie sous forme de fichier XML ; - Le port LIB (library) contient les bibliothèques de trackers, thresholds et moteurs situationnels (exécutables) ;

- Le port EDI (éditeur) émet les données de sortie sous forme de flux XML ; - Le port DIF (diffuseur) émet les données à destination des modules de traitement 21 , 22 d'autres groupes sous forme de flux XML ;

- Le port MON (monitoring) émet des statistiques. La répartition des tâches entre les groupes de modules 21 , 22 permet une bien meilleure efficacité de traitement par la spécialisation des modules 21 , 22, et le fait que chaque groupe soit alimenté en données assure comme on le voit sur la figure 3 un « feedback ». Les résultats d'une partie du traitement permettent d'améliorer l'autre partie de traitement. Plusieurs clés de répartitions possibles entre les groupes de modules de traitement 21 , 22 vont être décrites plus loin. Il est à noter qu'il est possible de combiner ces approches : le système 1 peut avoir deux groupes de modules 21 , 22 répartis selon une première loi, les modules 21 , 22 d'un groupe étant eux même répartis en deux sous-groupes selon une deuxième loi.

Le travail de tri est effectué par le module répartiteur 10. Ce dernier interprète chaque paquet d'information, et l'adresse aux modules de traitement 21 , 22 adéquats.

Le module réconciliateur 30 reçoit les flux relatifs à des messages à envoyer en fonction des traitements effectués et s'occupe de la publication de ces messages. Il recompose un flux global à destination de la plateforme 2 du site et/ou de l'équipement 3 de l'utilisateur.

Selon une première variante, les modules de traitement 21 d'un groupe sont des modules de pré-traitement configurés pour identifier les situations d'utilisateurs connectés à ladite plateforme 2, et les modules de traitement 22 d'un autre groupe sont des modules de post-traitement configurés pour traiter des situations identifiées d'utilisateurs connectés. Dans cette configuration particulièrement avantageuse, on a avantageusement un module de pré-traitement 21 , et N modules de posttraitement 22 (en particulier 4 ou 8, mais on comprendra qu'on n'est pas limité à ce nombre et que l'on peut en avoir un nombre quelconque), car le traitement des situations obtenues et l'envoi de messages et la partie la plus consommatrice de ressources du procédé.

Le lien de feedback, que l'on voit sur la figure 2, permet que ou les modules de pré-traitement 21 collectent des données issus du ou des modules de post-traitement 22 de sorte à influer sur l'identification des situations. Cela rend possible le mode non-supervisé évoqué précédemment.

Selon une deuxième variante, les modules de traitement 21 d'un groupe mettent en œuvre les opérations en temps réel (les modules de « traitement immédiat »), et les modules 22 d'un autre groupe mettent en œuvre les opérations différées (modules de « traitement différé »). En d'autres termes, certains modules 21 exécutent des tâches nécessitant une action immédiate (par exemple les déclencheurs en lien avec la navigation des utilisateurs, l'envoi de messages à exposition immédiate), alors que les autres modules 22 réalisent des tâches dont l'exécution peut être décalée dans le temps. Les données sont stockées sur les moyens de stockage le temps de pouvoir être traitées. Cette configuration facilite la rémanence des informations et la prise en compte du passé, dans la mesure où à tout instant les modules 21 « temps réel » reçoivent des données relatives à des traitements réalisés en différé (qui sont donc le fruit de données de connexion plus anciennes). La boucle de feedback permet ainsi aux modules de traitement différé 22 de communiquer aux modules de traitement immédiat 21 des « grilles de traitement » via lesquelles le traitement immédiat est adapté. Cette configuration s'adapte en outre très bien aux périodes de forte affluence en transférant des données de traitement immédiat à traitement différé.

Il s'agit du système représenté sur la figure 3 : le « SALIX » est le module de traitement différé 22, et les « SALIC » sont les modules de traitement immédiat 21 . Dans cette configuration particulièrement avantageuse, on a avantageusement un module de traitement différé 22, et N modules de traitement immédiat 21 (le traitement immédiat a la priorité, et est plus consommateur puisque une certaine partie des traitements ne peuvent être faits en différés). Dans une configuration à 4 modules de traitement immédiat 21 , on a alors au total 7 modules 10, 21 , 22, 30, un processeur octo-cœur est donc particulièrement préféré (le huitième cœur gérant le reste des opérations systèmes).

Les figures 5 et 6 représentent plus en détail respectivement un module de traitement immédiat 21 de type SALIC et un module de traitement différé 22 de type SALIX. Sur ces figures on voit les ports OBS, COLL, EDI et DIF (les ports ONT, LIB et MON sont câblés de façon similaire entre les deux types de module).

Un module de traitement immédiat 21 SALIC s'occupe d'identifier toutes les situations des utilisateurs (à réaliser en temps immédiat) via les vecteurs de consultation, sélection, consommation (qui comprennent les données observées pour déterminer les états des indices) reçus par le port observateur.

Le port diffuseur transmet les vecteurs au module de traitement différé 22 SALIX. Le port collecteur réceptionne les vecteurs d'information traitée en différé et les grilles en provenance du module de traitement différé 22 SALIX.

Les trackers (ainsi que les thresholds) génèrent les signatures situationnelles à partir des vecteurs et des grilles. Les moteurs situationnels temps réel associés aux stratégies des situations identifiées sont exécutés, et les messages produits par l'exécution des moteurs envoyés via le port éditeur.

Un module de traitement différé 22 SALIX s'occupe quant à lui des traitements qui n'ont pas besoin d'être faits tout de suite. Le port observateur reçoit exclusivement des données relatives aux services et aux usagers administrateurs. Le port collecteur réceptionne les vecteurs en provenance des modules de traitement immédiat 21 SALIC. Des moteurs situationnels sont mis en œuvre sous le contrôle d'un timer (minuteur) qui définit à quel point le traitement est différé.

Ces moteurs produisent les messages différés (messages à destination des utilisateurs étant envoyés quelques heures suivant sa visite par exemple sous la forme d'un e-mail promotionnel l'incitant à revenir sur le site) et les messages pour les administrateurs du site qui sont émis à destination des supports adéquats via le port éditeur, ainsi que les grilles de traitement qui comme expliqué sont renvoyées (avec certains vecteurs) vers les modules de traitement immédiat 21 SALIC via le port diffuseur.

Selon une troisième variante, chaque groupe de modules 21 , 22 correspond à une « ligne de services ». Il s'agit d'une unité de base de classification de produits au sein d'un site internet au sein du système dit « LSO » pour Lignes/Services/Options. Une ligne de services regroupe plusieurs services. Par exemple la catégorie « Salon » qui va regrouper des services « Tables », « Meubles TV », « Canapés », etc. dans un catalogue de meubles est une ligne de services. De même, la catégorie « Homme », ou « Taille XL » est une ligne de services d'un catalogue de vêtements. Sur un site internet tel un site marchand, on note qu'il est possible de présenter les mêmes produits sous plusieurs modes de classifications, il s'agit alors de lignes de services différentes. Chaque service présente des options. Dans l'exemple précédent, un service « Pantalons » d'une ligne « Homme » contiendra une liste d'options qui sont autant de modèles de pantalons. Chaque option présente un produit avec plusieurs variantes (taille, couleurs, etc.) ; chaque produit est en effet unique (référence catalogue donné), contrairement à l'option. Un même produit peut donc être présenté dans plusieurs contextes LSO. Pour revenir à notre exemple, on peut retrouver le même pantalon dans le service « Pantalons homme » de la ligne « XL ».

On peut ainsi envisager de séparer les modules de traitement 21 , 22 par ligne de services, en particulier pour des sites présentant des produits très divers pour lesquels les situations des utilisateurs vont être très différentes. Il est à noter qu'il est courant pour des gros sites que l'utilisateur soit redirigé vers l'un ou l'autre des serveurs de la plateforme 2 selon la ligne de services sur laquelle il navigue.

En outre, de façon avantageuse, on combine plusieurs de ces variantes. En particulier, les modules de traitement immédiat 21 SALIC de la deuxième variante peuvent être chacun dédié à une ou plusieurs lignes de services. Dans ce cas, le module répartiteur 10 RENZO repartit le flux entrant en le dirigeant vers le module de traitement différé 22 SALIX s'il s'agit de données d'administration ou vers un module de traitement immédiat 21 SALIC s'il s'agit de données de navigation d'un utilisateur, en fonction de la ligne de services dans laquelle il se trouve.