Brevet FR3110320A1 — publié le 20211119

L’invention propose de détecter un utilisateur comme souffrant d’illectronisme, l’utilisateur disposant d’au moins un terminal et nécessitant une assistance adaptée pour l’utilisation d’au moins un service numérique à partir du terminal. On prévoit de : - interroger (S2) une base de données stockant des requêtes issues du terminal pour accéder au service, - parmi lesdites requêtes, identifier au moins des requêtes en échec, relatives à des tentatives échouées de l’utilisateur pour accéder au service, - estimer une fréquence (S31,S32) des requêtes en échec pour évaluer un score d’illectronisme de l’utilisateur (S4), - comparer (S5) le score évalué à un seuil prédéterminé, et - en cas de dépassement du seuil par le score évalué, détecter (S6) l’utilisateur comme souffrant d’illectronisme en vue de proposer (S7) au moins un service spécifique, adapté à l’utilisateur. Figure de l’abrégé : Figure 2 Détection d’utilisateurs sujets à l’illectronisme La présente invention concerne une mise en œuvre d’équipements de télécommunication pour détecter des comportements d’utilisateurs caractérisant leur illectronisme. L’illectronisme, appelé aussi « illettrisme numérique » ou « inhabileté numérique » est la difficulté ou l'incapacité, que rencontre une personne à utiliser les appareils numériques et les outils informatiques en raison d'un manque ou d'une absence totale de connaissances à propos de leur fonctionnement. Des études en 2019 ont montré qu’en France, 15% des personnes de 15 ans ou plus n’ont pas utilisé Internet au cours de l’année écoulée, tandis que 38% des utilisateurs manquent d’au moins une compétence numérique de base et 2% sont même dépourvus de toute compétence. Au total, l’illectronisme concernerait 17% de la population française. Ce chiffre correspond à la moyenne européenne. Par exemple, toujours selon ces études, 25% de la population française ne sait pas s’informer grâce à Internet, 20% est incapable de communiquer grâce à Internet. Les personnes les plus touchées par illectronisme sont notamment les personnes les plus âgées, les moins diplômées, ayant des revenus modestes. L’illectronisme peut accroître leur vulnérabilité sociale. En effet, ne pas savoir accéder correctement à Internet représente un réel handicap, notamment pour accéder aux services publics et effectuer des démarches administratives (déclaration des revenus, gestion d’un compte bancaire, etc.), trouver une formation ou un emploi, garder un lien avec ses proches ou plus généralement ses connaissances, ou simplement acheter un billet de train. La lutte contre l’illectronisme est un enjeu de politique publique comparable à la lutte contre l’illettrisme. Les opérateurs de télécommunication peuvent jouer un rôle important dans cette lutte, notamment en offrant des produits et des services dédiés à cette lutte. Des solutions existent pour permettre à des usagers de mesurer et de développer leurs compétences numériques, mais il n’existe pas aujourd’hui de solution permettant de détecter de façon automatique des utilisateurs d’appareils numériques ou d’outils informatique souffrant d’illectronisme. La présente invention vient améliorer cette situation. Elle propose à cet effet un procédé de détection d’illectronisme d’au moins un utilisateur disposant d’au moins un terminal, le procédé comprenant : - analyser statistiquement des requêtes en échec parmi des requêtes issues du terminal pour accéder à au moins un service, une requête en échec étant une requête pour laquelle l’accès au service a échoué, la détection d’illectronisme étant fonction du résultat de l’analyse. Ainsi, une telle réalisation permet une détection efficace d’illectronisme, sans déranger l’utilisateur dans son interaction avec le terminal. L’analyse statistique précitée peut être effectuée par exemple en étudiant un historique des requêtes (au moyen d’une base de données par exemple), ou encore en temps réel, au fur et à mesure des requêtes reçues du terminal. Ainsi, dans une réalisation, l’analyse statistique peut comporter : - estimer une fréquence des requêtes en échec. La fréquence des requêtes en échec, précitée, peut être estimée par un pourcentage de requêtes erronées par rapport à un ensemble de requêtes sur une période de temps prédéterminée (par exemple mensuelle ou autre). Dans une réalisation, le procédé peut comporter en outre: - parmi lesdites requêtes, identifier au moins des requêtes en échec, relatives à des tentatives échouées de l’utilisateur pour accéder au service. Par exemple, identifier un requête en échec peut comprendre : - vérifier si la durée d’un accès à un service est inférieure à un seuil. L’accès peut notamment être un appel téléphonique, auquel cas par exemple l’appel émis, d’une durée inférieure au seuil précité, était un appel erroné. Dans une réalisation, le procédé peut comprendre : - interroger une base de données stockant des requêtes issues du terminal pour accéder au service. Dans une réalisation, le procédé peut comprendre : - vérifier si le résultat de l’analyse dépasse un seuil un seuil prédéterminé, un dépassement vérifié correspondant à détecter l’illectronisme de l’utilisateur. Ainsi, une telle réalisation permet la détection d’au moins un utilisateur souffrant d’illectronisme, cet utilisateur disposant d’au moins un terminal et nécessitant une assistance adaptée pour l’utilisation d’au moins un service numérique à partir du terminal. Dans un exemple de réalisation, le procédé peut comporter : - interroger une base de données stockant des requêtes issues du terminal pour accéder au service, - parmi lesdites requêtes, identifier au moins des requêtes en échec, relatives à des tentatives échouées de l’utilisateur pour accéder au service, - estimer une fréquence des requêtes en échec pour évaluer un score d’illectronisme de l’utilisateur, - comparer le score évalué à un seuil prédéterminé, et - en cas de dépassement du seuil par le score évalué, détecter l’utilisateur comme souffrant d’illectronisme en vue de proposer au moins un service spécifique, adapté à l’utilisateur. Le service spécifique, précité, peut être de même nature que le service numérique que l’utilisateur cherche à utiliser à partir de son terminal, mais sous forme modifiée, pour être adaptée à l’utilisateur par exemple. En variante, il peut s’agir d’un service différent, tel qu’un tutoriel par exemple, ou autre. Ainsi, une telle mise en œuvre propose de détecter activement les utilisateurs souffrant potentiellement d’illectronisme, et dès lors, de proposer des interfaces d’utilisation adaptées ou des formations spécifiques, adaptées éventuellement à leur niveau d’illectronisme. Ainsi, une telle réalisation contribue à lutter contre l’isolement numérique. Dans une forme de réalisation, les requêtes en échec précitées peuvent comporter au moins des requêtes d’assistance pour accéder au service numérique, émises par le terminal de l’utilisateur. Ainsi, les requêtes en échec précitées caractérisent une situation d’échec de l’utilisateur dans l’utilisation du service numérique. Par exemple, dans une réalisation où la base de données précitée stocke des données de comptes-rendus d’appels téléphoniques émis depuis le terminal, les requêtes en échec de l’utilisateur peuvent comporter typiquement des requêtes d’assistance et les données de comptes-rendus d’appels peuvent comporter des identifiants d’appels vers au moins un service d’assistance vocal pour orienter l’utilisateur dans l’utilisation du service numérique. Ainsi, les appels téléphoniques vers ce type de service d’assistance vocal peuvent être identifiés dans les comptes-rendus d’appels et caractériser une requête en échec de l’utilisateur. En complément ou en variante, dans une réalisation où la base de données stocke encore des données de comptes-rendus d’appels téléphoniques émis depuis le terminal, ainsi que des durées d’appel parmi les données de comptes-rendus d’appels, le procédé peut comporter en outre : - identifier dans la base de données des occurrences d’appels de durées inférieures à un seuil, en tant que tentatives d’appels vers des numéros erronés, - et compter lesdites occurrences pour estimer le score d’illectronisme de l’utilisateur. Ainsi les appels vers de numéros erronés peuvent être identifiés comme des requêtes en échec. En complément ou en variante encore, le service numérique peut être accessible moyennant la saisie d’un identifiant et un mot de passe, et la base de données stocke alors au moins des occurrences relatives à des tentatives de saisies d’identifiants et/ou de mots de passe erronés, en tant que requêtes en échec. Dans une forme de réalisation particulière où le service numérique est accessible moyennant la saisie d’un identifiant et un mot de passe, la base de données précitée peut stocker notamment des requêtes de réinitialisation de mot de passe émises par le terminal de l’utilisateur, en tant que requêtes en échec. Elle peut stocker en outre des requêtes de renvoi d’identifiant (« identifiant oublié ») émises par le terminal de l’utilisateur, ces requêtes pouvant également être considérées en tant que requêtes en échec. Dans une réalisation, les requêtes en échec précitées comportent au moins une requête parmi les requêtes suivantes : - au moins une requête d’assistance pour accéder au service numérique, émises par le terminal de l’utilisateur ; - au moins une requête d’accès comportant un mot de passe erroné, la requête d’accès étant une requête d’accès au service par le terminal ; - au moins une requête de réinitialisation de mot de passe d’accès au service émise par le terminal ; - au moins un appel téléphonique émis depuis le terminal ; - au moins un appel téléphonique émis depuis le terminal vers au moins un service d’assistance vocal relative au service numérique. Dans une réalisation où les requêtes sont émises à destination d’une pluralité de fournisseurs de service distincts pour une pluralité de services respectifs, le score précité peut être évalué par une somme pondérée d’estimations respectives de fréquences de requêtes en échec à destination de ces fournisseurs de service distincts. Dans une telle réalisation où la pluralité de fournisseurs de service distincts comporte par exemple deux fournisseurs de service, le score précité peut être évalué par une relation de type : Où : - u est un identifiant de l’utilisateur ; - S(u), le score de l’utilisateur évalué ; - , un nombre de requêtes en échec auprès d’un premier fournisseur de service de la pluralité de fournisseurs de service distincts, émises par le terminal de l’utilisateur d’identifiant u ; - , un nombre total de requêtes auprès du premier fournisseur de service, émises par le terminal de l’utilisateur d’identifiant u ; - , un nombre de requêtes en échec auprès d’un deuxième fournisseur de service de la pluralité de fournisseurs de service distincts, émises par le terminal de l’utilisateur d’identifiant u ; - , un nombre total de requêtes auprès du deuxième fournisseur de service, émises par le terminal de l’utilisateur d’identifiant u ; - P, un coefficient de pondération compris entre 0 et 1. Par exemple, le premier fournisseur de service ici peut être par exemple un opérateur de télécommunications utilisant un premier serveur stockant des données de comptes-rendus d’appels (CRA), tandis que le deuxième fournisseur de service peut utiliser un serveur stockant les requêtes émises sur Internet (de type http, ou autre) depuis le terminal de l’utilisateur. L’invention vise aussi un programme informatique comportant des instructions pour la mise en œuvre du procédé ci-avant, lorsque ces instructions sont exécutées par un processeur d’un circuit de traitement. Un exemple d’algorithme général de ce programme est illustré sur la figure 2 commentée plus loin. Les instructions du programme informatique peuvent être réparties entre le terminal de l’utilisateur et une plateforme de détection d’illectronisme, ces entités étant visées ci-après. En effet, la présente invention vise aussi une plateforme de détection d’illectronisme d’au moins un utilisateur disposant d’au moins un terminal, la plateforme comprenant - une interface de communication avec au moins un terminal d’un utilisateur, l’interface de communication comprenant un récepteur de requête d’accès à un service du terminal et un émetteur d’accès au service au terminal; - un analyseur statistique (qui peut prendre la forme d’un processeur PROC2 coopérant avec une mémoire MEM2, comme illustré sur la figure 4 commentée plus loin), des requêtes en échec parmi les requêtes issues du terminal pour accéder au service, une requête en échec étant une requête pour laquelle l’accès au service a échoué, la détection d’illectronisme étant fonction du résultat de l’analyse. Dans une dorme de réalisation, cette plateforme peut comporter une interface de communication (distincte de, ou identique à, l’interface de communication précitée) avec au moins une base de données stockant au moins des requêtes d’accès au service, l’interface comprenant un récepteur des données de la base de données. Dans une forme de réalisation, la plateforme de service comprend un assistant déclenché par l’analyseur statistique en fonction du résultat d’analyse, l’assistant fournissant une assistance adaptée pour l’utilisation du au moins un service numérique à partir du terminal. Comme indiqué précédemment, un tutoriel peut être proposé à l’utilisateur pour se familiariser avec l’utilisation de services numériques. En variante, un service spécifique peut être proposé, de même nature que le service numérique que l’utilisateur cherche à utiliser à partir de son terminal, mais sous forme simplifiée pour être adaptée aux difficultés que rencontre l’utilisateur par exemple. Par exemple, le terminal de l’utilisateur peut présenter à son utilisateur un menu interactif simplifié et adapté à l’utilisateur. D’ailleurs, la présente invention vise aussi un terminal comprenant : - une interface de communication avec au moins un fournisseur de service, l’interface de communication comprenant un émetteur de requête d’accès à un service du terminal et un récepteur d’accès au service au terminal ; l’interface de communication comprenant un récepteur d’un signal fonction d’un résultat fourni par un analyseur statistique de requêtes en échec parmi des requêtes issues du terminal pour accéder à au moins un service, une requête en échec étant une requête pour laquelle l’accès au service a échoué, une détection d’illectronisme étant fonction du résultat de l’analyse. Le résultat fourni, précité, peut être simplement un indicateur de score d’illectronisme, ou encore un lien vers un serveur plus adapté à l’utilisateur en fonction de son illectronisme détecté, ou autre. Le signal précité peut être un simple message notamment d’indication du niveau d’illectronisme de l’utilisation (par exemple un simple signal indicateur ou un signal d’information), ou encore un message de conseil de formation, ou un message contenant un lien vers un serveur adapté, ou une commande exécutant l’accès à un serveur plus adapté fournissant le même service mais avec une interface homme-machine simplifiée pour l’utilisateur, ou encore un signal (typiquement un signal d’adaptation) transportant des données et notamment des données d’un menu simplifié destiné à être mis en œuvre par l’interface homme-machine du terminal. Dans une réalisation, le terminal comprend une interface homme-machine, configurée pour être animée par un menu simplifié d’utilisation du service numérique, en fonction d’une information de détection d’illectronisme reçue dans le signal. Ainsi par exemple, en cas de dépassement du seuil par le score évalué, le terminal peut exécuter une routine pour animer l’interface homme-machine avec un menu d’utilisation du service numérique, simplifié pour l’utilisateur (par exemple avec des rubriques simples, sélectionnées pour l’utilisateur et vulgarisées). D’autres avantages et caractéristiques de l’invention apparaitront à la lecture de la description détaillée ci-après d’exemples de réalisation, et à l’examen des dessins annexés, sur lesquels : Fig. 1 illustre schématiquement notamment une plateforme F, en opération pour la mise en œuvre de l’invention. Fig. 2 illustre les étapes principales d’un procédé au sens de l’invention. Fig. 3 illustre schématiquement le circuit de traitement d’un terminal au sens de l’invention. Fig. 4 illustre schématiquement le circuit de traitement d’une plateforme au sens de l’invention. Il est donné ci-après des exemples à titre illustratif de comportements typiques d’utilisateurs souffrant d’illectronisme. Ces personnes peuvent rencontrer des problèmes tels que : - Des difficultés pour accéder à un site internet, par exemple un site donnant la météorologie du jour ; - Des difficultés à saisir un identifiant et un mot de passe, par exemple pour accéder à un espace personnel ; - Des difficultés pour composer un numéro de téléphone (en utilisant le clavier d’un téléphone ou l’écran tactile d’un téléphone mobile), par exemple pour appeler un correspondant, un numéro d’urgence ou un service clients ; - Etc. Il est proposé ci-après une solution permettant: - De détecter automatiquement des utilisateurs souffrant potentiellement d’illectronisme ; - De mettre à disposition de ceux-ci des services spécifiques pour leur faciliter l’usage des outils numériques (par exemple, la téléphonie, l’accès à internet, etc.). A cet effet, il est prévu une plateforme F (figure 1) (qui peut prendre la forme matérielle d’un serveur par exemple), capable d’exploiter plusieurs sources de données afin de détecter automatiquement certains comportements qui sont plus fréquemment observés chez les personnes souffrant d’illectronisme, par exemple les appels vers des supports techniques, ou les demandes de réinitialisation de mots de passe à la suite de saisies de plusieurs mots de passes erronés, ou encore les demandes de renvoi de l’identifiant (cas typique où l’utilisateur a oublié sont identifiant et demande à ce qu’il lui soit renvoyé, par email par exemple), etc. Il est alors possible d’identifier ainsi les utilisateurs pour lesquels ce type de comportement est anormalement élevé (c’est-à-dire, par exemple, très supérieur à la moyenne observée chez l’ensemble des utilisateurs du même réseau). Ainsi, un utilisateur qui a recours de temps en temps à un support technique ou qui demande de temps en temps la réinitialisation d’un de ses mots de passe n’est pas détecté comme souffrant potentiellement d’illectronisme. En revanche, un utilisateur qui a très souvent recours à un support technique et qui demande la réinitialisation de son mot de passe quasiment à chaque fois qu’il tente de se connecter à un espace personnel peut être détecté comme souffrant potentiellement d’illectronisme. Dans l’exemple décrit ci-après, deux sources de données peuvent ainsi être exploitées par la plateforme F : - Les Comptes-Rendus d’Appels (CRA) ; - Les informations de navigations internet. L’exploitation par la plateforme F de ces deux sources de données est décrite ci-dessous. En référence à la figure 1, le terminal TER d’un utilisateur est relié par un réseau RES à une plateforme F qui est raccordée au système d’information SI d’un opérateur de télécommunications, en particulier à la partie du système d’information dans laquelle les Comptes-Rendus d’Appels (CRA) sont générés. Les CRA sont des données numériques qui sont générées automatiquement dans les systèmes d’information d’opérateurs de télécommunication (fixes et mobiles) lors de chaque appel téléphonique (depuis un téléphone fixe ou un téléphone mobile). Ces CRA sont utilisés par les opérateurs notamment pour facturer leurs clients et générer les factures détaillées de leurs clients : ils contiennent donc des informations concernant chaque appel téléphonique émis et reçu par les utilisateurs du réseau RES, typiquement : - Le numéro de téléphone de l’appelant : dans le cas d’un réseau mobile (GSM, UMTS, etc.), ce numéro est par exemple de type MSISDN (Mobile Station ISDN Number, ISDN pour Integrated Services Digital Network); - Le numéro de téléphone de l’appelé ; - L’heure de l’appel ; - La durée de l’appel ; - Etc. Le format de ces CRA n’est pas normalisé (chaque opérateur de télécommunications utilise généralement son propre format de CRA). La plateforme F est capable d’interroger régulièrement le système d’information (SI) de l’opérateur afin de récupérer les CRA générés depuis la dernière interrogation. Par exemple, cette récupération de CRA peut se faire quotidiennement (typiquement chaque nuit). Dès que de nouveaux CRA sont ainsi récupérés, la plateforme F analyse ceux-ci afin de détecter certains appels spécifiques émis (par exemple, les appels vers des numéros correspondant à des supports techniques, typiquement). En notant L1 la liste de ces numéros spécifiques (ou préfixes de numéros) spécifiques qui sont ainsi détectés par F (cette liste étant modifiable à tout moment par l’opérateur), L1 est stockée dans une base de données (BDD) auprès de la plateforme F. Cette liste L1 contient donc des numéros de téléphone (par exemple : +33810 20 20 00, +33810 30 30 30, etc.) ainsi que des préfixes de numéros de téléphones (par exemple : +33810*, +33820*, etc.) caractérisant des demandes d’aide d’utilisateurs auprès de services dédiés. On considère en effet, qu’un utilisateur qui appelle très fréquemment ce type de numéros identifiés comme étant des numéros de supports techniques (c’est-à-dire beaucoup plus que la moyenne des utilisateurs du même réseau) est un utilisateur qui rencontre plus souvent des difficultés lorsque qu’il utilise ses outils numériques (téléphonie, accès à internet, etc.). Par ailleurs, lorsque de nouveaux CRA sont récupérés, la plateforme F identifie également les CRA correspondant à des appels anormalement courts (typiquement d’une durée de quelques secondes). On considère en effet, qu’un utilisateur qui émet très fréquemment (c’est-à-dire beaucoup plus que la moyenne des utilisateurs du même réseau) des appels très courts est un utilisateur qui compose fréquemment des « numéros erronés » (c’est-à-dire qu’il fait souvent une erreur de saisie lorsqu’il compose un numéro de téléphone et appelle ainsi un autre utilisateur que celui souhaité ; dans ce cas la communication est évidemment très courte). En outre, la plateforme F est également capable d’interroger le système d’information (SI) de l’opérateur afin de récupérer régulièrement, chaque jour par exemple (typiquement, chaque nuit), les informations de navigations internet relatives aux utilisateurs du réseau de l’opérateur. En effet, par exemple depuis un téléphone mobile (via un réseau mobile quelconque, par exemple : GSM, UMTS, LTE, etc.) ou un ordinateur (pour tout type de technologie utilisée, par exemple ADSL, fibre optique, ou autre), lorsqu’un utilisateur accède à une page internet (par exemple le portail de l’opérateur), une trace est automatiquement générée dans le système d’information SI de l’opérateur. Cette trace contient notamment un identifiant unique de l’utilisateur (par exemple son identifiant IMSI si l’utilisateur accède à internet depuis un téléphone mobile). Il est rappelé que l’identifiant IMSI (pour International Mobile Subscriber Identity) est un numéro unique qui permet à un réseau de téléphonie mobile (de type GSM, UMTS, LTE, ou autre) d'identifier un utilisateur. Ce numéro est stocké dans la carte SIM (ou USIM en UMTS et LTE) et n'est pas connu de l'utilisateur. En principe, l’utilisateur n’utilise aucun dispositif pour aller sur internet de façon anonyme, c’est-à-dire sans génération de traces permettant de l’identifier dans le réseau de l’opérateur. Si un utilisateur est capable de parcourir internet de façon anonyme, il ne peut pas réellement être considéré comme sujet à l’illectronisme. Lorsque de nouvelles informations de navigations sont ainsi récupérées, la plateforme F les analyse afin de détecter certains comportement, notamment l’accès à des pages d’accès à des environnements personnels nécessitant la saisi d’un identifiant et d’un mot de passe par l’utilisateur. Un utilisateur qui accède à plusieurs reprises et dans un temps limité (par exemple cinq fois de suite pendant quelques minutes) à la même page d’accès à un environnement personnel est considéré comme rencontrant des difficultés pour s’identifier (parce qu’il a oublié son identifiant ou son mot de passe, ou encore parce qu’il n’arrive pas à les saisir correctement, ou encore simplement parce qu’il ne sait pas saisir un identifiant et un mot de passe, ou autres difficultés). Ci-après plus un utilisateur présente ce type de comportement, plus il est considéré qu’il souffre potentiellement d’illectronisme. De même, la plateforme F analyse les informations de navigations relatives à l’accès à des pages correspondant à des demandes de réinitialisation d’un mot de passe (cas où l’utilisateur a oublié son mot de passe) ou de la demande d’un renvoi de l’identifiant (cas où l’utilisateur a oublié son identifiant, ou ignore simplement de quoi il s’agit). Les adresses de ces différentes pages internet sont stockées dans une liste L2, elle-même stockée dans la base de données (BDD) de la plateforme F. Cette liste L2 est modifiable à tout moment par l’opérateur. Par ailleurs, la plateforme F est également capable de détecter l’accès à des pages internet spécifiques (correspondant à l’accès à des environnements personnels, à une demande de réinitialisation d’un mot de passe ou encore à la demande d’un identifiant, etc.) en recherchant la présence de mots clés dans les adresses des pages internet consultées. Ainsi, par exemple, les mots clés suivants peuvent être utilisés pour cette recherche dans des adresses des pages internet consultées: « login », « account », « réinitialiser », etc. Les adresses des pages internet peuvent être matérialisées par des chaines de caractères telles que par exemple des liens URL (Uniform Resource Locator), ou encore des requêtes http (HyperText Transfer Protocol), ou autres, dans lesquelles il est possible de rechercher une correspondance avec des mots-clés prédéterminés. Tous ces mots-clés sont stockés dans la liste L2. On considère en effet que, par exemple, une adresse contenant le mot clé « login » correspond le plus souvent à l’accès à un environnement personnel, ou encore qu’une adresse contenant le mot clé « réinitialiser » correspond le plus souvent à une demande de réinitialisation d’un mot de passe, etc. Là encore, plus un utilisateur donné consulte des pages internet ayant des adresses contenant ce type de mots-clés, plus cet utilisateur est considéré comme souffrant potentiellement d’illectronisme. Ci-après, on décrit le calcul d’un score caractérisant si l’utilisateur est potentiellement souffrant d’illectronisme. On note S le score caractérisant la probabilité qu’un utilisateur donné souffre d’illectronisme (un score S est affecté à chaque utilisateur du réseau de l’opérateur). Les scores de l’ensemble des utilisateurs du réseau sont stockés dans la base de données BDD de la plateforme F. Le score S est par exemple un pourcentage : - Le score minimal (0%) correspond à un utilisateur pour lequel aucun comportement observé ne correspond à l’un des comportements fréquemment observés chez les personnes souffrants d’illectronisme ; - Le score maximal (100%) correspond à un utilisateur pour lequel la totalité des comportements observés correspondent à l’un des comportements fréquemment observés chez les personnes souffrants d’illectronisme. Le calcul du score S est réalisé automatiquement par la plateforme F, et est mis à jour (recalculé) automatiquement, après l’exploitation de nouvelles données récupérées dans le système d’information SI (CRA et/ou informations de navigations internet), typiquement quotidiennement (chaque nuit par exemple). La valeur du score S est calculée par la plateforme F selon une formule prédéterminée par l’opérateur (cette formule est stockée dans la base de données de la plateforme F ; elle est modifiable à tout moment par l’opérateur). Ci-après, on note : - u, un identifiant de l’un des utilisateurs de l’opérateur ; - S(u), le score de l’utilisateur u (i.e. caractérisant si l’utilisateur u souffre ou non d’illectronisme) ; - , le nombre de comportements détectés dans la première source de données (les Comptes-Rendus d’Appels par exemple) pour l’utilisateur u (comportements considérés comme typiques de personnes souffrant d’illectronisme) ; - , le nombre total de comportements analysés dans la première source de données (les Comptes-Rendus d’Appels, dans cet exemple) pour l’utilisateur u ; - , par exemple le nombre de comportements détectés dans la deuxième source de données (les informations de navigations internet) pour l’utilisateur u (comportements considérés comme typiques de personnes souffrant d’illectronisme) ; - , le nombre total de comportements analysés dans la deuxième source de données (les informations de navigations internet) pour l’utilisateur u. Par exemple, le score S(u) de l’utilisateur u peut est calculée selon la formule suivante : La valeur du dénominateur correspondant au nombre de sources de données (soit deux dans cet exemple). Dans une variante possible de l’invention, cette formule utilisée pour le calcul du score S(u) contient un poids (P) permettant de donner plus ou moins d’importance à l’une ou l’autre des deux sources de données. P est un nombre décimal dont la valeur est comprise entre 0 et 1. Dans ce cas, le score S(u) peut est calculé selon la formule suivante : Par exemple, P = 0,25 donne plus de poids à la détection par les CRA dans cet exemple. Ensuite, le score S(u) peut être utilisé par la plateforme comme suit. Il peut être fixé un seuil (paramétrable) à partir duquel un utilisateur u est considéré comme souffrant potentiellement d’illectronisme. La valeur de ce seuil peut être fixée par exemple entre 10% et 50%, par exemple à 20%. Si la valeur de S(u) est inférieure à ce seuil, l’utilisateur u n’est pas considéré comme souffrant d’illectronisme. A l’inverse, si la valeur de S(u) est supérieure à ce seuil, l’utilisateur u est considéré comme souffrant d’illectronisme. Lorsqu’un utilisateur u est considéré comme souffrant d’illectronisme, certains services spécifiques sont proposés, par exemple : - Accès par téléphone à un assistant personnel spécialisé dans l’aide aux personnes souffrant d’illectronisme, répertoriés comme tels dans une base de données ; - Accès à des formations ou des tutoriels en ligne permettant de lutter contre d’illectronisme ; - Etc. De plus, lorsqu’un utilisateur u est considéré comme souffrant d’illectronisme, certains services fournis par l’opérateur peuvent être adaptés afin de faciliter leurs usages. Il peut être prévu par exemple l’installation d’applications sur des terminaux de ces utilisateurs pour modifier l’exécution d’interfaces homme-machine de ces terminaux afin de simplifier les messages de ces interfaces. La modification de l’interface homme-machine peut être programmée en vue d’une simplification de la procédure de saisie d’identifiants/mots de passe, par exemple pour la connexion à un espace personnel proposé par l’opérateur (le mot de passe entré par l’utilisateur peut par exemple s’afficher en clair lors de sa saisie, c’est-à-dire qu’il n’est pas remplacé par une succession de caractères « * » lors de sa saisie, limitant ainsi les risques de saisie erronée). Il peut être prévu en outre une simplification de l’interface homme-machine par exemple du portail de l’opérateur. Dans ce cas, une requête émise par le terminal sollicite la présentation d’une page d’accueil plus sobre, se limitant à des fonctionnalités de bases, éventuellement avec une absence de bandeaux de publicités, et l’affichage d’un point de contact pour un support technique bien mis en évidence à tout moment, etc. En outre, il peut être prévu l’accès automatique à un support technique spécifique dédié aux personnes souffrant d’illectronisme. Lorsque l’utilisateur appelle le service client de l’opérateur, l’utilisateur est orienté (en fonction des coordonnées de son terminal par exemple) vers une personne ayant l’habitude d’assurer un support à des personnes souffrant d’illectronisme. A tout moment, un utilisateur peut contacter l’opérateur (par simple appel téléphonique par exemple) pour activer ou désactiver le calcul automatique de son score S(u). A tout moment, un utilisateur peut contacter l’opérateur (par simple appel téléphonique par exemple) pour demander à l’opérateur de supprimer l’ensemble des données le concernant présentes dans la base de données de la plateforme F (base BDD). Ainsi, il peut être mise en œuvre un service de détection des utilisateurs souffrant d’illectronisme, afin de leur proposer des services spécifiques et adaptés. L’usage des outils numériques ainsi facilité permet alors de lutter contre d’illectronisme et favoriser l’inclusion numérique. On a résumé sur la figure 2 les étapes d’un procédé selon une forme de réalisation possible. Au cours d’une première étape S1 le terminal de l’utilisateur u émet des appels téléphoniques et/ou des requêtes sur Internet. A l’étape S2, le système d’information SI de l’opérateur de télécommunications collecte, de façon connue en soi, les comptes-rendus d’appels CRA et les requêtes émises par le terminal TER pour alimenter la base de données BDD. À l’étape S31, à partir des comptes-rendus d’appels CRA, il peut être estimé une fréquence f1 d’appels de numéros spécifiques d’assistance pour l’utilisation de services numériques (plateformes d’aide en ligne, etc.). Cette fréquence f1 peut être estimée par exemple comme le rapport entre le nombre d’appels vers des plateformes d’assistance et un nombre total d’appels, comme présenté précédemment, ou encore f1 peut être estimée selon le nombre d’appels vers des plateformes d’assistance, par unité de temps (par exemple par jour, par semaine, ou par mois), ou encore le rapport précité peut être déterminé pour une telle unité de temps. A l’étape S32, il peut être estimé en outre une fréquence f2 par exemple de requêtes erronées via Internet et issues du terminal TER, ou encore de requêtes d’initialisation de mot de passe (requêtes identifiées par le terme « réinitialiser », « logon », etc.). Comme pour la fréquence f1, la fréquence f2 peut être estimée par un rapport de nombre de requêtes en échec (erronées ou en demande de mot de passe, ou autre) sur un nombre total de requêtes, et/ou sur une période de temps prédéterminée. A l’étape S4, il peut être calculé le score S(u) de l’utilisateur u, comme une somme pondérée par exemple des fréquences f1, f2, par exemple du type : S(u)=(1-P)f1+Pf2, comme présenté précédemment. A l’étape S5, si le score dépasse un seuil THR prédéterminé (flèche OK en sortie du test S5), par exemple de 20%, alors à l’étape S6, l’utilisateur u du terminal est considéré comme souffrant d’illectronisme. Dans ce cas, il peut être prévu par exemple la présentation de services spécifiques pour l’utilisateur u, par exemple un tutoriel ou équivalent, ou encore l’exécution d’une routine sur le terminal TER en vue d’une animation d’une interface homme-machine (étape S7) avec un menu d’utilisation du service numérique sollicité par l’utilisateur plus simple (avec moins de rubriques par exemple et en ne conservant que les rubriques essentielles pour l’utilisateur éventuellement avec une formulation simplifiée de ces rubriques pour l’utilisateur). A cet effet, un terminal TER pour mettre en œuvre une telle réalisation peut comporter, comme illustré sur la figure 3, un circuit de traitement comprenant au moins : - une interface de communication COM1 avec le réseau RES de l’opérateur, - un processeur PROC1 relié à l’interface COM1 pour traiter notamment une donnée reçue de la plateforme F selon laquelle l’utilisateur u du terminal TER est potentiellement souffrant d’illectronisme, et exécuter une routine en conséquence pour l’animation de l’interface homme-machine IHM selon un mode simplifié, - une mémoire MEM1 reliée au processeur PROC1 pour stocker au moins les instructions de la routine précitée, et - l’interface homme-machine IHM (par exemple un écran tactile affichant des rubriques d’utilisation d’un service numérique) par exemple pour proposer à l’utilisateur u un menu simplifié de navigation pour l’utilisation du service numérique demandé. La plateforme F comporte par ailleurs un circuit de traitement propre, comprenant au moins : - une interface de communication COM2 avec le réseau RES de l’opérateur, ainsi que les données issues de la base de données BDD, - un processeur PROC2 pour exécuter un programme informatique au sens de la présente invention pour la mise en œuvre du procédé selon par exemple le mode de réalisation illustré sur la figure 2, et - une mémoire MEM2 accessible au processeur PROC2 et stockant notamment les instructions du programme informatique précité. Procédé, mis en œuvre par un circuit de traitement, de détection d’illectronisme d’au moins un utilisateur disposant d’au moins un terminal, le procédé comprenant : - analyser statistiquement des requêtes en échec parmi des requêtes issues du terminal pour accéder à au moins un service, une requête en échec étant une requête pour laquelle l’accès au service a échoué, la détection d’illectronisme étant fonction du résultat de l’analyse. Procédé selon la revendication 1, dans lequel l’analyse statistique comporte : - estimer une fréquence des requêtes en échec. Procédé selon l’une des revendications 1 ou 2, dans lequel le procédé comprend : - parmi lesdites requêtes, identifier au moins des requêtes en échec, relatives à des tentatives échouées de l’utilisateur pour accéder au service. Procédé selon la revendication 3, dans lequel identifier un requête en échec comprend : - vérifier si la durée d’un accès à un service est inférieure à un seuil. Procédé selon l’une des revendications 1 à 4, dans lequel le procédé comprend : - interroger une base de données stockant des requêtes issues du terminal pour accéder au service. Procédé selon l’une des revendications 1 à 5, dans lequel le procédé comprend : - vérifier si le résultat de l’analyse dépasse un seuil prédéterminé, un dépassement vérifié correspondant à détecter l’illectronisme de l’utilisateur. Procédé selon l’une des revendications 1 à 6, dans lequel les requêtes en échec comportent une parmi les requêtes suivantes : - au moins une requête d’assistance pour accéder au service numérique, émises par le terminal de l’utilisateur ; - au moins une requête d’accès comportant un mot de passe erroné, la requête d’accès étant une requête d’accès au service par le terminal ; - au moins une requête de réinitialisation de mot de passe d’accès au service émise par le terminal ; - au moins un appel téléphonique émis depuis le terminal ; - au moins un appel téléphonique émis depuis le terminal vers au moins un service d’assistance vocal relative au service numérique. Procédé selon l'une des revendications précédentes, dans lequel les requêtes sont émises à destination d’une pluralité de fournisseurs de service distincts pour une pluralité de services respectifs, et dans lequel le score est évalué par une somme pondérée d’estimations respectives de fréquences de requêtes en échec à destination desdits fournisseurs de service distincts. Procédé selon la revendication 7, dans lequel la pluralité de fournisseurs de service distincts comporte deux fournisseurs de service et le score est évalué par une relation de type : Où : - u est un identifiant de l’utilisateur ; - S(u), le score de l’utilisateur évalué ; - , un nombre de requêtes en échec auprès d’un premier fournisseur de service de la pluralité de fournisseurs de service distincts, émises par le terminal de l’utilisateur d’identifiant u ; - , un nombre total de requêtes auprès du premier fournisseur de service, émises par le terminal de l’utilisateur d’identifiant u ; - , un nombre de requêtes en échec auprès d’un deuxième fournisseur de service de la pluralité de fournisseurs de service distincts, émises par le terminal de l’utilisateur d’identifiant u ; - , un nombre total de requêtes auprès du deuxième fournisseur de service, émises par le terminal de l’utilisateur d’identifiant u ; - P, un coefficient de pondération compris entre 0 et 1. Programme informatique comportant des instructions pour la mise en œuvre du procédé selon l’une des revendications 1 à 9, lorsque lesdites instructions sont exécutées par un processeur d’un circuit de traitement. Plateforme (F) de détection d’illectronisme d’au moins un utilisateur disposant d’au moins un terminal, la plateforme comprenant - une interface de communication (COM2) avec au moins un terminal d’un utilisateur, l’interface de communication comprenant un récepteur de requête d’accès à un service du terminal et un émetteur d’accès au service au terminal; - un analyseur statistique (PROC2, MEM2) des requêtes en échec parmi les requêtes issues du terminal pour accéder au service, une requête en échec étant une requête pour laquelle l’accès au service a échoué, la détection d’illectronisme étant fonction du résultat de l’analyse. Plateforme selon la revendication précédente, comprenant une interface de communication avec au moins une base de données (BDD) stockant au moins des requêtes d’accès au service, l’interface (COM2) comprenant un récepteur des données de la base de données. Plateforme selon l’une des revendications 11 ou 12, comprenant un assistant déclenché par l’analyseur statistique en fonction du résultat d’analyse, l’assistant fournissant une assistance adaptée pour l’utilisation du au moins un service numérique à partir du terminal. Terminal (TER) comprenant : - une interface de communication (COM1) avec au moins fournisseur de service, l’interface de communication comprenant un émetteur de requête d’accès à un service du terminal et un récepteur d’accès au service au terminal ; l’interface de communication comprenant un récepteur d’un signal fonction d’un résultat fourni par un analyseur statistique de requêtes en échec parmi des requêtes issues du terminal pour accéder à au moins un service, une requête en échec étant une requête pour laquelle l’accès au service a échoué, une détection d’illectronisme étant fonction du résultat de l’analyse. Terminal selon la revendication précédente comprenant une interface homme-machine (IHM), l’interface homme-machine étant configurée pour être animée par un menu simplifié d’utilisation du service numérique, en fonction d’une information de détection d’illectronisme reçue dans le signal.