FR 3111504 A1 20211217 FR 2006267 A 20200616 Procédé d’accès et dispositif de gestion d’accès à une session de communication sécurisée entre des terminaux de communication participants par un terminal de communication requérant L'invention concerne l’accès à une session de communication sécurisée entre des terminaux de communication participants par un terminal d’accès requérant. Un objet de l’invention est un procédé d’accès à une première session de communication sécurisée, dite première session, en cours entre des terminaux de communications participants, dit terminaux participants, par un terminal de communication requérant, dit terminal requérant, le procédé d’accès comportant - déclencher une entrée dans la première session en cours du terminal requérant dès réception d’une acceptation d’un des terminaux participants suite à une transmission d’un message de demande d’accès émis par le terminal requérant à destination d’au moins un terminal participant de la première session. Ainsi, le terminal requérant accédera facilement à la première session de communication sécurisée même si le terminal requérant ne suit pas la procédure d’accès sécurisée. Figure pour l’abrégé : Figure 1a Procédé d’accès et dispositif de gestion d’accès à une session de communication sécurisée entre des terminaux de communication participants par un terminal de communication requérant L'invention concerne l’accès à une session de communication sécurisée entre des terminaux de communication participants par un terminal d’accès requérant. Par session de communication sécurisée est notamment entendu un espace numérique partagé sécurisé tel qu’une conférence téléphonique, une visioconférence, un espace collaboratif virtuel, etc. qui nécessite l’usage de clefs d’accès pour chacun des terminaux de communication participants. État de la technique Ce type de session de communication sécurisée nécessite de définir préalablement à l’établissement de la session de communication la liste des participants : par exemple identifiant utilisateurs et/ou terminaux participants. Ainsi, seuls les participants identifiés dans la liste seront autorisés à établir et/ou accéder à la session de communication sécurisée. Pour ajouter un degré de sécurité supplémentaire, il peut aussi être prévu que l’établissement et/ou l’accès à la session de communication sécurisée soit en outre conditionnée à la fourniture par le terminal de communication participant souhaitant établir et/ou accéder à la session de communication sécurisée d’un clef composé notamment par un code d’accès (tel qu’un code numérique, un code alphanumérique, aussi appelé mot de passe, un schéma, un code composé d’une succession d’images, etc.) et/ou des données biométriques… Ainsi, seuls les participants préalablement inscrits peuvent accéder à cette session de communication sécurisés et, si nécessaire, doivent pouvoir présenter le code d’accès pour être autoriser à y accéder. Or, un participant peut avoir oublié ou perdu son code d’accès. Cela peut s’avérer problématique car les contenus (conversation, documents textuels, audio et/ou vidéo, etc.) que le participant devait partager durant cette session de communication sécurisée ne seront alors pas accessibles par les autres participants. Et, lorsque la session de communication sécurisée permet la génération d’au moins un contenu final, ce contenu final sera erroné car il ne sera pas fonctions des contenus du participant qui n’a pas accédé à la session de communication sécurisée mais seulement des contenus partagés par les participants ayant accédé cette session. Une solution serait l’utilisation d’un système de récupération du code d’accès. Mais, si un système de récupération du code d’accès n’est pas prévu en lien avec l’accès sécurisé à la session de communication sécurisée ou si le participant ne dispose pas des moyens nécessaire à cette récupération du code d’accès (par exemple, s’il n’a pas avec lui le téléphone mobile recevant le code temporaire par SMS), il ne sera pas autorisé à accéder à la session de communication sécurisée. En outre, la liste des participants peut être erronée : une personne et/ou un dispositif de communication ayant été omis dans la liste. Dans ce cas aussi, la personne omise ne sera pas autorisé à accéder à la session de communication sécurisée : il ne pourra donc pas contribuer à la session et si celle-ci est génératrice d’un contenu final, ce contenu final sera erroné. Une solution, si une telle personne a connaissance de la session de communication ou a été avertie par un participant de la session de communication, serait qu’il contacte la personne administrant la liste des participants et que celle-ci l’ajoute à cette liste de participants afin de pouvoir accéder à la session de communication sécurisée. Mais ce processus est laborieux car nécessite d’abord que la personne omise ait connaissance de la session de communication sécurisée planifiée, puis que la personne omise connaisse la personne administrant la liste de participants et au moins un moyen de la contacter (numéro de téléphone, adresse email, etc.), et que la personne administrant la liste de participants soit contacter par la personne omise avant la session de communication sécurisée pour l’intégrer à la liste des participants. En outre, même dans ce cas, il subsiste un risque d’erreur que la personne omise soit intégrer dans une autre liste lorsque la personne administrant gère plusieurs liste de participants à des sessions de communication sécurisée distinctes. Un des buts de la présente invention est de remédier à des inconvénients par rapport à l'état de la technique. Un objet de l’invention est un procédé d’accès à une première session de communication sécurisée, dite première session, en cours entre des terminaux de communications participants, dit terminaux participants, par un terminal de communication requérant, dit terminal requérant, le procédé d’accès comportant - déclencher une entrée dans la première session en cours du terminal requérant dès réception d’une acceptation d’un des terminaux participants suite à une transmission d’un message de demande d’accès émis par le terminal requérant à destination d’au moins un terminal participant de la première session. Ainsi, le terminal requérant accédera facilement à la première session de communication sécurisée même si le terminal requérant ne suis pas la procédure d’accès sécurisée (soit que le terminal requérant ne soit pas un terminal de la liste de participants autorisés à accéder à la première session de communication sécurisée, soit que le terminal requérant n’ait pas le code d’accès à la première session de communication sécurisée). En outre, le terminal requérant accédant à la première session de communication sécurisée aura accès aux mêmes échanges effectués dans la première session que n’importe lequel des terminaux participants à la première session. Avantageusement, le procédé d’accès comportant - recevoir l’acceptation d’un terminal participant. Ainsi, l’acceptation est gérée directement par le procédé d’accès évitant une surcharge de réseau si l’acceptation est d’abord transmise au terminal requérant qui doit ensuite la transmettre au procédé d’accès pour déclencher l’entrée dans la première session du terminal requérant. Avantageusement, le procédé d’accès comportant : - recevoir une requête d’accès d’un terminal requérant, la requête d’accès comportant le message de demande d’accès, et - émettre le message de demande d’accès à destination d’au moins un terminal participants de la première session. Ainsi, le terminal participant dispose des éléments nécessaires pour la transmission de l’acceptation directement au procédé d’accès puisque la demande d’accès provient du procédé d’accès et non directement du terminal requérant. En outre, le terminal requérant peut ainsi effectuer une demande d’accès à une première session même s’il ne dispose pas de moyens (numéro de téléphone, adresse email, identifiant utilisateur dans un réseau social, etc.) pour contacter directement un participant à la première session. Avantageusement, émettre le message de demande d’accès à destination du au moins un terminal participant de la première session comporte une des étapes suivantes : - diffuser le message à destination de l’ensemble des terminaux participants préalablement à un accès du terminal requérant à la première session; - émettre le message par communication asynchrone à destination d’au moins un des terminaux participants; - émettre le message à destination d’au moins un terminal participant de la première session en dehors de la première session. Ainsi, quel que soit le mode d’émission du message de demande d’accès, le message est reçu par au moins un participant et le terminal requérant n’a pas connaissance des échanges ayant lieu dans la première session avant d’y accéder suite à l’acceptation. En outre, la diffusion du message permet ainsi de maximiser la possibilité d’une acceptation de la demande d’accès. De plus, avec l’émission du message en dehors de la première session, une suspension des échanges dans la première session peut ainsi être évité. Avantageusement, le message de demande d’accès comportant au moins une données parmi les données suivantes : - une donnée sonore courte d’avertissement, - un identifiant associé au terminal requérant, - un identifiant associé à un terminal participant à la session de communication sécurisée, - un identifiant de la première session à laquelle le terminal requérant demande l’accès, - un message textuel, audio ou vidéo d’un utilisateur du terminal requérant. Avantageusement, le procédé d’accès comportant - établir, préalablement au déclenchement de l’entrée dans la première session du terminal requérant, une deuxième session de communication synchrone entre le terminal requérant et un des terminaux participants à la première session sur requête d’établissement dudit un des terminaux participants suite à une transmission d’un message de demande d’accès émis par le terminal requérant à destination d’au moins un terminal participants de la session de communication. Avantageusement, le procédé d’accès comportant - clore la deuxième session dès mise en œuvre par le procédé d’accès d’une étape parmi les suivantes : + la réception d’une acceptation par le terminal participant de la deuxième session, + le déclenchement de l’entrée dans la première session du terminal requérant. Un autre objet de l’invention est un procédé de demande d’accès à une première session de communication sécurisée, dite première session, en cours entre des terminaux de communications participants, dit terminaux participants, par un terminal de communication requérant, dit terminal requérant, le procédé de demande d’accès comportant - entrer dans la première session en cours du terminal requérant déclenchée dès réception d’une acceptation d’un des terminaux participants suite à une transmission d’un message de demande d’accès émis par le terminal requérant à destination d’au moins un terminal participant de la première session. Un objet de l’invention est aussi un procédé d’administration d’accès à une première session de communication sécurisée, dite première session, en cours entre des terminaux de communications participants, dit terminaux participants, par un terminal de communication requérant, dit terminal requérant, le procédé d’administration d’accès comportant - émettre une acceptation d’un des terminaux participants suite à une transmission d’un message de demande d’accès émis par le terminal requérant à destination d’au moins un terminal participant de la première session, l’acceptation envoyée déclenchant, dès réception, une entrée dans la première session en cours du terminal requérant. Avantageusement, selon une implémentation de l'invention, les différentes étapes du procédé selon l'invention sont mises en œuvre par un logiciel ou programme d'ordinateur, ce logiciel comprenant des instructions logicielles destinées à être exécutées par un processeur de données d'un dispositif faisant partie d’une architecture de communication et étant conçus pour commander l'exécution des différentes étapes de ce procédé. L'invention vise donc aussi un programme comprenant des instructions de code de programme pour l’exécution des étapes du procédé d’accès à une première session de communication sécurisée et/ou du procédé de demande d’accès et/ou du procédé d’administration d’accès lorsque ledit programme est exécuté par un processeur. Ce programme peut utiliser n'importe quel langage de programmation et être sous la forme de code source, code objet ou code intermédiaire entre code source et code objet tel que dans une forme partiellement compilée ou dans n'importe quelle autre forme souhaitable. Un objet de l’invention est encore un dispositif de gestion d’accès à une première session de communication sécurisée, dite première session, en cours entre des terminaux de communications participants, dit terminaux participants, par un terminal de communication requérant, dit terminal requérant, le dispositif de gestion d’accès comportant - un contrôleur apte à déclencher une entrée dans la première session en cours du terminal requérant dès réception d’une acceptation d’un des terminaux participants suite à une transmission d’un message de demande d’accès émis par le terminal requérant à destination d’au moins un terminal participant de la première session. Un objet de l’invention est également un terminal de communication requérant, dit terminal requérant, apte à demander un accès à une première session de communication sécurisée, dite première session, en cours entre des terminaux de communications participants, dit terminaux participants, par un terminal de communication requérant, dit terminal requérant, le terminal requérant comportant - un connecteur apte à entrer le terminal requérant dans la première session en cours, le connecteur étant déclenché dès réception d’une acceptation d’un des terminaux participants suite à une transmission d’un message de demande d’accès émis par le terminal requérant à destination d’au moins un terminal participant de la première session. Avantageusement, le terminal requérant comportant - un générateur d’un message de demande d’accès apte à être émis par le terminal requérant à destination d’au moins un terminal participant de la première session. Un objet de l’invention est en outre un terminal de communication participant, dit terminal participant, à une première session de communication sécurisée dite première session, en cours entre des terminaux de communications participants, dit terminaux participants, le terminal participant comportant - un connecteur apte à établir la première session entre le terminal participant et au moins un autre terminal participant, - un validateur apte à accepter un accès à la première session suite à une transmission d’un message de demande d’accès émis par le terminal requérant à destination d’au moins un terminal participant de la première session, le validateur déclenchant une entrée dans la première session en cours du terminal requérant. Avantageusement, le terminal participant comportant - un connecteur apte à établir une deuxième session de communication synchrone avec le terminal requérant préalablement à l’acceptation par le validateur. Les caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description, faite à titre d'exemple, et des figures s’y rapportant qui représentent : , un schéma simplifié d’un procédé de gestion d’accès à une première session de communication sécurisée, , un schéma simplifié d’un procédé d’accès à une première session de communication sécurisée par un terminal requérant selon l’invention, , un schéma simplifié d’un procédé de demande d’accès à une première session de communication sécurisée par un terminal requérant selon l’invention, , un schéma simplifié d’un procédé d’administration d’accès à une première session de communication sécurisée par un terminal requérant selon l’invention, , un schéma simplifié d’un diagramme d’échanges dans une architecture de communication mettant en œuvre un procédé d’accès à une première session de communication sécurisée par un terminal requérant selon l’invention, , un schéma simplifié d’une architecture de communication comportant un dispositif de gestion d’accès à une première session de communication sécurisée par un terminal requérant selon l’invention, , un schéma simplifié d’utilisation d’un procédé de gestion d’accès dans un cas d’usage particulier de l’invention, , un schéma simplifié d’utilisation d’une éventuelle première étape d’un procédé de demande d’accès selon l’invention dans le cas d’usage de l’invention de la , , un schéma simplifié d’utilisation d’une éventuelle deuxième étape d’un procédé de demande d’accès selon l’invention dans le cas d’usage de l’invention de la , , un schéma simplifié d’utilisation d’un procédé d’administration d’accès selon l’invention dans le cas d’usage de l’invention de la , , un schéma simplifié d’utilisation d’une éventuelle deuxième étape d’un procédé de demande d’accès selon l’invention dans le cas d’usage de l’invention de la . Les figures 1a et 1b illustrent un procédé de gestion d’accès à une première session de communication sécurisée. La montre le procédé de gestion d’accès tel qu’il peut exister dans l’art antérieur. La montre des étapes qui peuvent être intégrées seules ou en combinaison au procédé de gestion de la suite à l’établissement de la première session. La illustre donc un schéma simplifié d’un procédé de gestion d’accès à une première session de communication sécurisée. Le procédé de gestion d’accès à la première session de communication sécurisée SS 1X _MNGT comporte un établissement de la première session de communication sécurisée SS 1X _STB, notamment, suite à une requête d’établissement d’une session de communication sécurisée ss 1X _oreq d’un premier terminal de communication participant TP 1 . Le premier terminal de communication participant TP 1 est un terminal de communication de la liste de participants associée à la première session de communication sécurisée SS 1X . Dans ce cas particulier, l’établissement de la première session SS 1X _STB implique un accès du premier terminal participant TP1 à la première session SS 1X . En particulier, le procédé de gestion d’accès SS 1X _MNGT comporte une fourniture SS 1X _SACC d’un accès sécurisé à la première session SS 1X à au moins un terminal participant de la liste sur demande ultérieurement d’un accès sécurisé ss 1x _sreq à la première session par le au moins un terminal participant de la liste . Suite à la fourniture d’un accès sécurisé à la première session SS 1X _SACC, le au moins un terminal participant TPn accède à la première session SS 1X . Les terminaux participants TP 1 , {TP n } n accédant à la première session SS 1X échangent entre eux des données tels que des messages textuels, des communications audio et/ou vidéo, des contenus, etc. via cette première session SS 1X . Le procédé de gestion SS1X_MNGT est mis en œuvre - soit par un dispositif de gestion distinct des terminaux participants TP n , notamment implémenté dans un serveur de communication d’un réseau de communication ; - soit par un dispositif de gestion implémenté dans le terminal administrateur de la première session ; - soit par un dispositif de gestion implémenté dans le premier terminal participant TP 1 ayant requis l’établissement de la première session. Un mode de réalisation particulier du procédé de gestion SS1X_MNGT est un programme comprenant des instructions de code de programme pour l’exécution des étapes du procédé de gestion SS 1X _MNGT lorsque ledit programme est exécuté par un processeur. La illustre un schéma simplifié d’un procédé d’accès à une première session de communication sécurisée par un terminal requérant selon l’invention. Le procédé d’accès SS 1X _ACC est un procédé d’accès à une première session de communication sécurisée SS 1X dite première session, en cours entre des terminaux de communications participants , dit terminaux participants, par un terminal de communication requérant TR, dit terminal requérant. Le procédé d’accès SS 1X _ACC comporte - déclencher une entrée ENT_TRG dans la première session SS 1X en cours du terminal requérant TR dès réception d’une acceptation OK_REC d’un des terminaux participants TP i suite à une transmission DAC_TR d’un message de demande d’accès dacc_mssg émis par le terminal requérant TR à destination d’au moins un terminal participant de la première session ,. Dans le cas où l’accès à la première session de communication sécurisée est conditionné à l’appartenance à une liste de terminaux de communication participants associée à cette première session pour sécuriser la première session (par exemple, éviter que des terminaux tiers, c’est-à-dire n’appartenant pas à cette liste accèdent aux échanges effectués durant cette première session), le terminal requérant est notamment un terminal de communication n’appartenant pas à la liste de participants associée à la première session de communication sécurisée. Dans le cas où, pour sécuriser la première session, les terminaux participants doivent en outre fournir un code d’accès pour être autorisé à accéder à la première session, le terminal requérant peut aussi être un des terminaux participants ne disposant pas du code d’accès lors de sa demande d’accès : soit que l’utilisateur du terminal d’accès est oublié le code d’accès à la première session, soit que le code d’accès préalablement enregistré par le terminal requérant ait été perdu, soit que le code d’accès soit fourni à l’utilisateur du terminal requérant sur un terminal de communication de l’utilisateur du terminal requérant distinct du terminal requérant dont l’utilisateur ne dispose pas au moment de la demande d’accès (en particulier, le terminal requérant est un ordinateur ou une tablette au moyen duquel un utilisateur demande l’accès à un espace collaboratif par exemple alors qu’il est en déplacement, cet espace collaboratif envoi au téléphone mobile de l’utilisateur un code d’accès. Si l’utilisateur a oublié son téléphone mobile, par exemple chez lui, il ne pourra pas accédé à cet espace.). En particulier, le procédé d’accès SS 1X _ACC comporte - recevoir l’acceptation OK_REC d’un terminal participant TPi. En particulier, le procédé d’accès SS 1X _ACC comportant : - recevoir DACC_REC une requête d’accès acc_req d’un terminal requérant TR, la requête d’accès acc_req comportant le message de demande d’accès dacc_mssg , et - émettre DACC_TR le message de demande d’accès dacc_mssg à destination d’au moins un terminal participants de la première session . En particulier, l’émission DACC_TR du message de demande d’accès à destination du au moins un terminal participant de la première session SS 1X comporte: - diffuser le message à destination de l’ensemble des terminaux participants préalablement à un accès du terminal requérant à la première session. Dans un mode de réalisation alternatif, l’émission DACC_TR du message de demande d’accès à destination du au moins un terminal participant de la première session SS 1X comporte: - émettre le message par communication asynchrone à destination d’au moins un des terminaux participants. En particulier, l’émission DACC_TR du message de demande d’accès à destination du au moins un terminal participant de la première session SS 1X comporte: - émettre le message à destination d’au moins un terminal participant de la première session en dehors de la première session. En particulier, le message de demande d’accès dacc_mssg comporte au moins une données parmi les données suivantes : - une donnée sonore courte d’avertissement, notamment un jingle, une sonnerie, un timbre avertissement…, tel qu’un gong d’entrée, un dring de sonnette d’entrée, une donnée audio correspond à un « toc toc » à une porte, etc. ; - un identifiant associé au terminal requérant, tel qu’un numéro de téléphone, un identifiant IMEI, etc. un nom, pseudonyme ou adresse email d’un utilisateur du terminal requérant, etc. ; - un identifiant associé à un terminal participant à la session de communication sécurisée, - un identifiant de la première session à laquelle le terminal requérant demande l’accès, - un message textuel, audio ou vidéo d’un utilisateur du terminal requérant. En particulier, le procédé d’accès SS 1X _ACC comporte - établir SS 2 _STB, préalablement au déclenchement de l’entrée ENT_TRG dans la première session SS 1X du terminal requérant TR, une deuxième session SS 2 de communication synchrone entre le terminal requérant TR et un des terminaux participants TPi à la première session sur requête d’établissement ss 2 _req dudit un des terminaux participants TP i suite à une transmission DACC_TR d’un message de demande d’accès émis par le terminal requérant à destination d’au moins un terminal participants de la session de communication. Alors, le procédé d’accès SS1X_ACC comporte, en particulier, une mise en œuvre d’une communication SS 2 _COM via la deuxième session SS 2 entre le terminal participant TPi et le terminal requérant TR. Ils peuvent ainsi échanger notamment des messages ss 2 _mssg 1 , ss 2 _mssg 2 … Par ces échanges, le terminal participant TPi et/ou l’utilisateur du terminal participant TPi peut demander au terminal requérant TR et/ou à l’utilisateur du terminal requérant TR des informations complémentaires. Par exemple, lorsque seul le numéro de téléphone du terminal requérant est fourni par le message de demande d’accès dacc_mssg, le terminal participant TPi et/ou son utilisateur peut demander le nome de l’utilisateur du terminal requérant et d’éventuelles autres informations sur le terminal requérant (capacités techniques par exemple pour vérifier sa compatibilité pour accéder à tout ou partie de la première session – contenu, type de communication vidéo, etc.) ou sur l’utilisateur du terminal requérant (rattachement à une école, un niveau scolaire, une entreprise, une équipe, etc. ; compétences ; âge, etc.). Les informations complémentaires permettront à l’utilisateur du terminal participant TPi ou au terminal participant de mettre en œuvre un procédé de décision pour accepter ou non la demande d’accès du terminal requérant. En particulier, le procédé d’accès SS 1X _ACC comporte - clore SS 2 _CL la deuxième session dès mise en œuvre par le procédé d’accès SS 1X _ACC d’une étape parmi les suivantes : + la réception d’une acceptation OK_REC par le terminal participant TPi de la deuxième session SS 2 , + le déclenchement de l’entrée ENT_TRG dans la première session SS 1X du terminal requérant TR. En particulier, la réception d’une acceptation OK_REC ou le déclenchement de l’entrée ENT_TRG commande ss 2 _stp la clôture de la deuxième session SS 2 _CL. En particulier, le procédé de d’accès SS 1X _ACC comporte gérer une deuxième session de communication SS 2 _MNGT, dite deuxième session, distincte de la première session. La deuxième session SS 2 permet au terminal requérant TR d’échanger avec au moins un terminal participant à la première session TP i . La gestion d’une deuxième session SS 2 _MNGT comporte notamment la mise en œuvre de la communication SS 2 _COM via la deuxième session SS 2 entre le terminal participant TPi et le terminal requérant TR. En particulier, la gestion d’une deuxième session SS 2 _MNGT comporte établir la deuxième session SS 2 _STB et/ou clore la deuxième session SS 2 _CL. En particulier, les étapes de la gestion d’une deuxième session SS 2 _MNGT sont mises en œuvre par le procédé d’accès SS 1X _ACC. Suite au déclenchement de l’entrée ENT_TRG dans la première session SS 1X du terminal requérant TR, le terminal requérant TR accède à la première session SS 1X . Les terminaux participants TP 1 , {TP n } n et le terminal requérant TR accédant à la première session SS 1X échangent entre eux des données tels que des messages textuels, des communications audio et/ou vidéo, des contenus, etc. via cette première session SS 1X . En particulier, le procédé d’accès SS1X_ACC est implémenté dans le procédé de gestion d’accès SS1X_MNGT, notamment tel qu’illustré dans la , suite à l’établissement de la première session SS1X_STB. Dans un mode de réalisation particulier, le procédé de gestion SS 1X _MNGT comporte créer une première session de communication sécurisée SS 1X _CREA préalablement à son établissement SS 1X _STB. La création SS 1X _CREA de la première session est effectuée sur demande d’un terminal participant dit administrateur de la première session, par exemple le premier terminal participant TP 1 . Lors de cette création SS 1X _CREA est générée une liste de participants dont au moins un identifiant associé à chacun des participants est fourni par le terminal administrateur. L’identifiant associé à un participant est notamment un identifiant relatif à un utilisateur participant disposant d’un terminal de communication au moyen duquel accédé à la première session et/ou un terminal de communication participant. Par exemple, lors de la création d’une première session pour une conférence téléphonique (audioconférence ou visioconférence), les identifiants des participants sont notamment des numéros des téléphones participants. Autre exemple, lors de la création d’une première session pour un espace collaboratif permettant à la fois des échanges textuels et/ou audio et/ou vidéo en plus d’un partage de contenu(s), les identifiants des participants sont notamment des adresses email des utilisateurs participants. Une fois la première session créée, le procédé de gestion SS 1X _MNGT établit la première session SS 1X _STB soit (première option) automatiquement à une date et/ou un horaire de début de session associé(e)(s) à la première session, soit (deuxième option) dès réception par le procédé de gestion SS 1X _MNGT d’une requête de première session ss 1x _oreq d’un premier terminal participant TP 1 , etc. L’exemple de la correspond à cette deuxième option. En particulier, le procédé de gestion SS 1X _MNGT vérifie que la requête de première session ss 1X _oreq provienne du terminal administrateur ayant contribué à création de la première session avant d’établir la première session SS 1X _STB. Une fois la première session établit, le procédé de gestion SS 1X _MNGT fournit un accès sécurisé SS 1X _SACC à la première session à un terminal de communication participant, dit terminal participant, dès demande d’accès sécurisée ss 1X _sreq par un terminal participant TP n . Par terminal participant est, notamment, entendu un terminal de communication dont un identifiant fait partie de la liste des participants associée à la première session ou dont l’utilisateur a un identifiant qui fait partie de la liste des participants associée à la première session. En particulier, la fourniture d’accès à la première session SS 1X _SACC comporte vérifier si le terminal de communication dont provient la demande d’accès sécurisée ss 1X _sreq est un terminal de communication relatif à l’un des participant de la liste des participants. Par un terminal relatif à l’un des participants de la liste des participant est notamment entendu un terminal correspondant à un des terminaux de la liste des participants (lorsque cette liste comportant des identifiants de terminaux) et/ou un terminal dont dispose un utilisateur correspondant à un des utilisateurs de la liste des participants (lorsque cette liste comporte des identifiants relatifs à des utilisateurs : adresse email, nom, pseudo, etc.)… Il est à noter que la liste des participants peut aussi comporter à la fois des identifiants de terminaux (numéro de téléphone, adresse IP, IMEI…), des identifiants d’utilisateurs (adresse email, nom, pseudo, etc.)… En particulier, le procédé de gestion SS 1X _MNGT active le procédé d’accès SS 1X _ACC dès qu’au moins un terminal participant TP i accède à la première session, soit le terminal administrateur lorsque la première session est établit SS 1X _STB à sa demande ss 1X _oreq ou tout autre terminal participant TP n, n=1…N lorsque la première session est établit automatiquement par exemple à une heure donnée. Le déclenchement de l’entrée ENT_TRG d’un terminal requérant TR mis en œuvre par le procédé d’accès SS 1X _ACC résulte d’une acception ok_cmd par un terminal participant TP i suite à une transmission d’un message de demande d’accès dacc_mssg par le terminal requérant TR. En particulier, le procédé d’accès SS 1X _ACC comporte recevoir DACC_REC une requête d’accès acc_req(dacc_mssg) du terminal requérant puis transmettre DACC_TR le message de demande d’accès dacc_mssg à au moins un terminal participant TPi. Ainsi, si le terminal requérant TR ne connait pas les terminaux participants TP n , ni leurs utilisateurs UP n , sa demande d’accès sera tout de même étudiée voire acceptée et, dans ce cas, il accédera tout de même à la première session SS 1X . De manière alternative, à condition que le terminal requérant TR connaisse au moins un terminal participant TP i ou un utilisateur participant UP i (doté d’un terminal participant TP i ) à la première session SS 1X , la requête d’accès acc_req est transmise directement du terminal requérant TR au terminal participant TP i ou à l’utilisateur participant UP i (doté d’un terminal participant TP i ). Et, le terminal participant TPi acceptant la demande d’accès commande directement ou indirectement ok_cmd le déclenchement ENT_TRG par le procédé d’accès SS 1X _ACC de l’entrée du terminal requérant TR dans la première session SS 1X . En particulier, le déclenchement ENT_TRG est commandé directement ok_cmd par le terminal participant TP i . De manière alternative, le procédé d’accès SS 1X _ACC comporte recevoir OK_REC une acceptation ok_cmd du terminal participant TPi. La réception d’une acceptation OK_REC commande ent_ok le déclenchement de l’entrée dans la première session ENT_TRG. Eventuellement, l’acceptation ok_cmd comporte, outre la validation de l’entrée dans la première session SS1X du terminal requérant (par exemple, sous la forme d’un identifiant associé au terminal requérant et, éventuellement, d’un identifiant de la première session), des données relatives à l’accès accordé. Par exemple, l’accès à la première session SS 1X pour le terminal requérant TR peut être : - total, c’est-à-dire identique aux accès accordés aux autres participants ; - un accès d’une catégorie prédéfinie, telle que la catégorie invité, ou n ième catégorie (notamment lorsque les participants sont déjà eux-mêmes divisé en plusieurs catégories pour des accès différenciés : accès en: + échanges textuels et/ou audio et/ou vidéo, et/ou + lecture, et/ou en écriture de contenus, et/ou + partage ou non de contenus) ; - limité (accès en échange textuel uniquement, et écoute/visualisation des échanges des terminaux participants et/ou accès en lecture aux contenus partagés, sans partage de document par le terminal requérant), etc. Dans un mode de réalisation particulier, éventuellement complémentaire au mode de réalisation particulier précédent, le(s) termina(l)(ux) participant(s) TPi ayant reçu le message de demande d’accès dacc_mssg du terminal requérant TR peut échanger de manière synchrone ou asynchrone avec le terminal requérant TR préalablement à l’acceptation ok_cmd . Le(s) termina(l)(ux) participant(s) TPi peu(ven)t notamment envoyer au terminal requérant un premier message mssg1. En particulier, le premier message mssg1 du(d’un des) termina(l)(ux) participant(s) TP i comporte une requête relative au terminal requérant TR notamment à ses capacités en terme de périphérique (caméra, microphone, taille d’écran, etc.), en terme de mémoire, en terme de traitements (logiciels, plug-in…), etc. et/ou à l’utilisateur du terminal requérant (identité, localisation, âge, compétence(s), niveau dans la(les) compétence(s), etc.). Dans ce cas, le terminal requérant TR peut transmettre en retour ou en réponse un deuxième message mssg2 comportant notamment une ou des réponses aux requêtes du premier message mssg1. L’échange peut se poursuivre par des messages supplémentaires entre le(s) termina(l)(ux) participant(s) TPi et le terminal requérant TR. Notamment, l’échange est clos notamment par l’acception ok_cmd par un des terminaux participants TP i échangeant avec le terminal requérant TR. En particulier, un des messages mssg provenant du terminal participant TPi comporte la commande d’acceptation ok_cmd . Dans ce dernier cas, le terminal requérant TR commande ok_cmd le déclenchement de son entrée dans la première session ENT_TRG en transmettant la commande d’acceptation contenue dans le premier message mssg1 vers le procédé d’accès SS 1X _ACC. Un mode de réalisation particulier du procédé d’accès SS 1X _ACC est un programme comprenant des instructions de code de programme pour l’exécution des étapes du procédé d’accès SS 1X _ACC lorsque ledit programme est exécuté par un processeur. Un mode de réalisation particulier du procédé de gestion SS1X_MNGT est un programme comprenant des instructions de code de programme pour l’exécution des étapes du procédé de gestion SS 1X _MNGT et du procédé d’accès SS 1X _ACC lorsque ledit programme est exécuté par un processeur. La figure 2 illustre un schéma simplifié d’un procédé de demande d’accès à une première session de communication sécurisée par un terminal requérant selon l’invention. Le procédé de demande d’accès SS 1X _DACC est un procédé de demande d’accès à une première session de communication sécurisée, dite première session, en cours entre des terminaux de communications participants TP i , dit terminaux participants, par un terminal de communication requérant TR, dit terminal requérant. Le procédé de demande d’accès SS 1X _DACC comporte - entrer SS 1X _ENT dans la première session en cours SS 1X du terminal requérant TR déclenchée acc_cmd dès réception d’une acceptation d’un des terminaux participants suite à une transmission d’un message de demande d’accès dacc_mssg émis par le terminal requérant TR à destination d’au moins un terminal participant TPi de la première session. En particulier, le procédé de demande d’accès SS 1X _DACC comporte : - émettre DACC_EM une requête d’accès acc_req du terminal requérant TR à destination d’au moins un terminal participant de la première session SS 1X , la requête d’accès acc_req comportant le message de demande d’accès dacc_mssg . En particulier, l’émission DACC_EM du message de demande d’accès à destination du au moins un terminal participant de la première session SS 1X comporte: - diffuser le message à destination de l’ensemble des terminaux participants préalablement à un accès du terminal requérant à la première session. Dans un mode de réalisation alternatif, l’émission DACC_EM du message de demande d’accès à destination du au moins un terminal participant de la première session SS 1X comporte: - émettre le message par communication asynchrone à destination d’au moins un des terminaux participants. En particulier, l’émission DACC_EM du message de demande d’accès à destination du au moins un terminal participant de la première session SS 1X comporte: - émettre le message à destination d’au moins un terminal participant de la première session en dehors de la première session. En particulier, le message de demande d’accès dacc_mssg comporte au moins une données parmi les données suivantes : - une donnée sonore courte d’avertissement, notamment un jingle, une sonnerie, un timbre avertissement…, tel qu’un gong d’entrée, un dring de sonnette d’entrée, une donnée audio correspond à un « toc toc » à une porte, etc. ; - un identifiant associé au terminal requérant, tel qu’un numéro de téléphone, un identifiant IMEI, etc. un nom, pseudonyme ou adresse email d’un utilisateur du terminal requérant, etc. ; - un identifiant associé à un terminal participant à la session de communication sécurisée, - un identifiant de la première session à laquelle le terminal requérant demande l’accès, - un message textuel, audio ou vidéo d’un utilisateur du terminal requérant. En particulier, le procédé de demande d’accès SS 1X _DACC comporte - connecté SS 2 _CNX le terminal requérant TR, préalablement à l’entrée SS 1X _ENT dans la première session SS 1X du terminal requérant TR, à une deuxième session SS 2 de communication synchrone établie avec un des terminaux participants TPi à la première session suite à l’émission DACC_EM du message de demande d’accès émis par le terminal requérant à destination d’au moins un terminal participants de la session de communication. Alors, le procédé de demande d’accès SS1X_DACC comporte, en particulier, une mise en œuvre d’une communication SS 2 _COM via la deuxième session SS 2 entre le terminal participant TPi et le terminal requérant TR. Ils peuvent ainsi échanger notamment des messages ss 2 _mssg 1 , ss 2 _mssg 2 … Par ces échanges, le terminal participant TPi et/ou l’utilisateur du terminal participant TPi peut demander au terminal requérant TR et/ou à l’utilisateur du terminal requérant TR des informations complémentaires. Par exemple, lorsque seul le numéro de téléphone du terminal requérant est fourni par le message de demande d’accès dacc_mssg, le terminal participant TPi et/ou son utilisateur peut demander le nome de l’utilisateur du terminal requérant et d’éventuelles autres informations sur le terminal requérant (capacités techniques par exemple pour vérifier sa compatibilité pour accéder à tout ou partie de la première session – contenu, type de communication vidéo, etc.) ou sur l’utilisateur du terminal requérant (rattachement à une école, un niveau scolaire, une entreprise, une équipe, etc. ; compétences ; âge, etc.). Les informations complémentaires permettront à l’utilisateur du terminal participant TPi ou au terminal participant de mettre en œuvre un procédé de décision pour accepter ou non la demande d’accès du terminal requérant. En particulier, le procédé de demande d’accès SS 1X _DACC comporte - déconnecter SS 2 _DCNX de la deuxième session du terminal requérant dès clôture de la deuxième session par un procédé de gestion de la deuxième session SS2_MNGT suite à: + une acceptation OK_REC de l’entrée dans la première session SS 1X du terminal requérant TR par le terminal participant TPi de la deuxième session SS 2 , + l’entrée ENT_TRG dans la première session SS 1X du terminal requérant TR. En particulier, le procédé de demande d’accès SS1X_DACC comporte participer en tant qu’appelant SS 2 _CE à une deuxième session de communication, dite deuxième session, distincte de la première session. La deuxième session SS 2 permet au terminal requérant TR d’échanger avec au moins un terminal participant à la première session TP i . La participation en tant qu’appelant à une deuxième session SS 2 _CE comporte notamment la mise en œuvre de la communication SS 2 _COM via la deuxième session SS 2 entre le terminal participant TPi et le terminal requérant TR. En particulier, la participation en tant qu’appelant à une deuxième session SS 2 _CE comporte connecter SS 2 _CNX et/ou déconnecter SS 2 _DCNX le terminal requérant TR de la deuxième session SS 2 . En particulier, les étapes de la participation en tant qu’appelant à une deuxième session SS 2 _CE sont mises en œuvre par le procédé de demande d’accès SS 1X _DACC. Suite à l’entrée SS1X_ENT dans la première session SS 1X du terminal requérant TR, le terminal requérant TR accède à la première session SS 1X . Les terminaux participants TP 1 , {TP n } n et le terminal requérant TR accédant à la première session SS 1X échangent entre eux des données tels que des messages textuels, des communications audio et/ou vidéo, des contenus, etc. via cette première session SS 1X . Dans un mode de réalisation particulier, l’entrée SS 1X _ENT d’un terminal requérant TR résulte d’une acception acc_cmd par un terminal participant TP i suite à une émission d’un message de demande d’accès dacc_mssg par le terminal requérant TR. En particulier, le procédé de demande d’accès SS 1X _DACC comporte émettre DACC_EM une requête d’accès acc_req(dacc_mssg) du terminal requérant à destination d’au moins un terminal participant TPi notamment via le procédé d’accès SS 1X _ACC. De manière alternative, à condition que le terminal requérant TR connaisse au moins un terminal participant TP i ou un utilisateur participant UP i (doté d’un terminal participant TP i ) à la première session SS 1X , la requête d’accès acc_req est transmise directement du terminal requérant TR au terminal participant TP i ou à l’utilisateur participant UP i (doté d’un terminal participant TP i ). Et, le terminal participant TPi acceptant la demande d’accès commande directement ou indirectement (notamment, via le procédé d’accès SS 1X _ACC) ok_cmd l’entrée dans la première session du terminal requérant SS1X_ENT En particulier, l’entrée SS 1X _ENT est commandée directement acc_cmd par le terminal participant TP i . De manière alternative, le procédé d’accès SS 1X _ACC recevant une acceptation ok_cmd du terminal participant TPi commande acc_cmd l’entrée SS 1X _ENT. Dans un mode de réalisation particulier, éventuellement complémentaire au mode de réalisation particulier précédent, le(s) termina(l)(ux) participant(s) TPi ayant reçu le message de demande d’accès dacc_mssg du terminal requérant TR peu(ven)t échanger de manière synchrone ou asynchrone avec le terminal requérant TR préalablement à l’acceptation déclenchant la commande d’entrée acc_cmd . Le terminal requérant TR peut notamment recevoir SS 2 _REC d(u)(es) termina(l)(ux) participant(s) TPi un premier message mssg1, notamment via une deuxième session SS 2 - le premier message mssg1 est alors, par exemple, relayé du terminal participant TP i au terminal requérant TR par une gestion de la deuxième session SS 2 _MNGT. En particulier, le premier message mssg1 comporte une requête relative au terminal requérant TR notamment à ses capacités en termes de périphérique (caméra, microphone, taille d’écran, etc.), en termes de mémoire, en termes de traitements (logiciels, plug-in…), etc. et/ou à l’utilisateur du terminal requérant (identité, localisation, âge, compétence(s), niveau dans la(les) compétence(s), etc.). Dans ce cas, le terminal requérant TR peut émettre SS 2 _EM en retour ou en réponse un deuxième message mssg2 comportant notamment une ou des réponses aux requêtes du premier message mssg1, notamment via la deuxième session SS 2 si le premier message mssg1 a été transmis via celle-ci – le deuxième message mssg2 est alors, par exemple, relayé du terminal requérant TR au terminal participant TP i par la gestion de la deuxième session SS 2 _MNGT. L’échange peut se poursuivre par des messages supplémentaires entre le(s) termina(l)(ux) participant(s) TPi et le terminal requérant TR. Notamment, l’échange est clos notamment par la commande d’acception acc_cmd par un des terminaux participants TP i échangeant avec le terminal requérant TR. En particulier, un des messages mssg provenant du terminal participant TPi comporte la commande d’acceptation acc_cmd, ok_cmd . Dans ce dernier cas, le terminal requérant TR commande acc_cmd son entrée dans la première session SS 1X _ENT en transmettant la commande d’acceptation acc_cmd, ok_cmd contenue dans le message reçu mssg soit directement à l’entrée SS1X_ENT soit vers le procédé d’accès SS 1X _ACC. Un mode de réalisation particulier du procédé de demande d’accès SS 1X _DACC est un programme comprenant des instructions de code de programme pour l’exécution des étapes du procédé de demande d’accès SS 1X _DACC lorsque ledit programme est exécuté par un processeur. La illustre un schéma simplifié d’un procédé d’administration d’accès à une première session de communication sécurisée par un terminal requérant selon l’invention. Le procédé d’administration d’accès SS 1X _ADM administre un accès à une première session de communication sécurisée SS 1X , dite première session, en cours entre des terminaux de communications participants TPn, dit terminaux participants, par un terminal de communication requérant TR, dit terminal requérant. Le procédé d’administration d’accès SS 1X _ADM comporte - émettre une acceptation OK_EM d’un des terminaux participants TP i suite à une transmission d’un message de demande d’accès dacc_mssg émis par le terminal requérant TR à destination d’au moins un terminal participant TP i de la première session, l’acceptation ok_cmd envoyée déclenchant, dès réception, une entrée dans la première session en cours du terminal requérant. En particulier, le procédé d’administration d’accès SS 1X _ADM comporte : - recevoir DACC_REC un message de demande d’accès dacc_mssg d’un terminal requérant TR. Notamment, la réception DACC_REC est une réception d’une requête d’accès acc_req comportant le message de demande d’accès dacc_mssg Eventuellement, le message de de demande d’accès dacc_mssg est relayé par un procédé d’accès SS1X_ACC, par exemple tel que décrit en lien avec la . En particulier, le message de demande d’accès dacc_mssg comporte au moins une données parmi les données suivantes : - une donnée sonore courte d’avertissement, notamment un jingle, une sonnerie, un timbre avertissement…, tel qu’un gong d’entrée, un dring de sonnette d’entrée, une donnée audio correspond à un « toc toc » à une porte, etc. ; - un identifiant associé au terminal requérant, tel qu’un numéro de téléphone, un identifiant IMEI, etc. un nom, pseudonyme ou adresse email d’un utilisateur du terminal requérant, etc. ; - un identifiant associé à un terminal participant à la session de communication sécurisée, - un identifiant de la première session à laquelle le terminal requérant demande l’accès, - un message textuel, audio ou vidéo d’un utilisateur du terminal requérant. En particulier, l’émission de l’acceptation OK_EM est activé ok_act par l’utilisateur participant UPi disposant du terminal participant TPi mettant en œuvre le procédé d’administration d’accès SS 1X _ADM. A titre d’exemple, le message de demande d’accès dacc_mssg comporte un gong d’entrée et le nom de l’utilisateur requérant UR du terminal requérant TR. Le message de demande d’accès dacc_mssg sera reproduit par le terminal participant TPi. Et, l’utilisateur participant UPi disposant du terminal participant TPi effectuera une action d’approbation ok_act: approbation orale, appui sur une touche OK sur un clavier physique ou virtuel, hochement de tête. Le procédé d’administration d’accès SS 1X _ADM comporte éventuellement une capture UP_CPT de l’action d’approbation ok_act qui active l’émission de l’acceptation OK_EM. En particulier, le procédé d’administration d’accès SS 1X _ADM comporte - requérir SS 2 _STBR un établissement, préalablement au déclenchement de l’entrée ENT_TRG dans la première session SS 1X du terminal requérant TR, d’une deuxième session SS 2 de communication synchrone entre le terminal requérant TR et un des terminaux participants TPi à la première session sur requête d’établissement ss 2 _req dudit un des terminaux participants TP i suite à la réception DACC_REC du message de demande d’accès émis par le terminal requérant TR. Alors, le procédé d’administration d’accès SS 1X _ADM comporte, en particulier, une mise en œuvre d’une communication SS 2 _COM via la deuxième session SS 2 entre le terminal participant TPi et le terminal requérant TR. Ils peuvent ainsi échanger notamment des messages ss 2 _mssg 1 , ss 2 _mssg 2 … Par ces échanges, le terminal participant TPi et/ou l’utilisateur du terminal participant TPi peut demander au terminal requérant TR et/ou à l’utilisateur du terminal requérant TR des informations complémentaires. Les informations complémentaires permettront à l’utilisateur du terminal participant TPi ou au terminal participant de mettre en œuvre un procédé de décision pour accepter ou non la demande d’accès du terminal requérant. En particulier, le procédé d’administration d’accès SS 1X _ADM comporte - déconnecter SS 2 _DCNX le terminal participant TPi de la deuxième session SS 2 dès mise en œuvre par le procédé d’accès SS 1X _ACC d’une étape parmi les suivantes : + la réception d’une acceptation OK_REC par le terminal participant TPi de la deuxième session SS 2 , + le déclenchement de l’entrée ENT_TRG dans la première session SS 1X du terminal requérant TR. En particulier, le procédé d’administration d’accès SS 1X _ADM comporte participer en tant qu’appelant SS 2 _CG à une deuxième session de communication, dite deuxième session, distincte de la première session. La deuxième session SS 2 permet au terminal participant TPi d’échanger avec le terminal requérant. La participation en tant qu’appelant à une deuxième session SS 2 _CG comporte notamment la mise en œuvre de la communication SS 2 _COM via la deuxième session SS 2 entre le terminal participant TPi et le terminal requérant TR. En particulier, la participation en tant qu’appelant à une deuxième session SS 2 _CG comporte requérir l’établissement de la deuxième session SS 2 _STBR et/ou déconnecter le terminal participant TP i de la deuxième session SS 2 _DCNX. En particulier, les étapes de la participation en tant qu’appelant à une deuxième session SS 2 _CG sont mises en œuvre par le procédé d’administration d’accès SS 1X _ADM. Suite au l’émission de l’acceptation OK_EM déclenchant, par le procédé d’accès SS 1X _ACC, l’entrée ENT_TRG dans la première session SS 1X du terminal requérant TR, le terminal requérant TR accède à la première session SS 1X . Les terminaux participants TP 1 , {TP n } n et le terminal requérant TR accédant à la première session SS 1X échangent entre eux des données tels que des messages textuels, des communications audio et/ou vidéo, des contenus, etc. via cette première session SS 1X . Le déclenchement de l’entrée ENT_TRG d’un terminal requérant TR mis en œuvre par le procédé d’accès SS 1X _ACC résulte d’une émission OK_EM, par un terminal participant TP i, d’une acception ok_cmd reçue, notamment par le procédé d’accès SS1X_ACC, suite à une transmission d’un message de demande d’accès dacc_mssg par le terminal requérant TR. En particulier, le procédé d’administration d’accès SS 1X _ADM comporte recevoir DACC_REC un message de demande d’accès dacc_mssg d’un terminal requérant TR, notamment sous la forme d’une requête d’accès acc_req(dacc_mssg) du terminal requérant comportant le message de demande d’accès dacc_mssg . En particulier, le message de demande d’accès dacc_mssg reçu DACC_REC par le procédé d’administration d’accès SS1X_ADM est envoyé par un procédé de demande d’accès SS1X_DACC tel que décrit notamment en lien à la et relayé (c’est-à-dire reçu du terminal requérant puis émis vers au moins un terminal participant TPi) par un procédé d’accès SS1X_ACC tel que décrit notamment en lien avec la . De manière alternative, à condition que le terminal requérant TR connaisse au moins un terminal participant TP i ou un utilisateur participant UP i (doté d’un terminal participant TP i ) à la première session SS 1X , la requête d’accès acc_req est reçu DACC_REC directement par le terminal participant TP i du terminal requérant TR. Et, le terminal participant TPi acceptant la demande d’accès commande directement ou indirectement ok_cmd le déclenchement ENT_TRG par le procédé d’accès SS 1X _ACC de l’entrée du terminal requérant TR dans la première session SS 1X . En particulier, le déclenchement ENT_TRG est commandé directement ok_cmd par le terminal participant TP i par une émission OK_EM de l’acception au procédé d’accès SS 1X _ACC. De manière alternative, le procédé d’accès SS 1X _ACC comporte recevoir OK_REC une acceptation ok_cmd du terminal participant TPi. La réception d’une acceptation OK_REC commande ent_ok le déclenchement de l’entrée dans la première session ENT_TRG. Eventuellement, l’acceptation OK_EM comporte, outre une validation de l’entrée dans la première session SS1X du terminal requérant ok_cmd (SS 1X ,TR) (par exemple, sous la forme d’un identifiant associé au terminal requérant et, éventuellement, d’un identifiant de la première session), des données relatives à l’accès accordé ok_cmd (SS 1X ,TR,acc_ty TR ). Par exemple, l’accès acc_ty TR à la première session SS 1X pour le terminal requérant TR peut être : - total, c’est-à-dire identique aux accès accordés aux autres participants ; - un accès d’une catégorie prédéfinie, telle que la catégorie invité, ou n ième catégorie (notamment lorsque les participants sont déjà eux-mêmes divisé en plusieurs catégories pour des accès différenciés : accès en: + échanges textuels et/ou audio et/ou vidéo, et/ou + lecture, et/ou en écriture de contenus, et/ou + partage ou non de contenus) ; - limité (accès en échange textuel uniquement, et écoute/visualisation des échanges des terminaux participants et/ou accès en lecture aux contenus partagés, sans partage de document par le terminal requérant), etc. Dans un mode de réalisation particulier, éventuellement complémentaire au mode de réalisation particulier précédent, le terminal participant TPi ayant reçu le message de demande d’accès dacc_mssg du terminal requérant TR peut échanger de manière synchrone ou asynchrone avec le terminal requérant TR préalablement à l’émission OK_EM de l’acceptation ok_cmd . Le terminal participant TPi peut notamment envoyer au terminal requérant un premier message mssg1. En particulier, le premier message mssg1 du terminal participant TP i comporte une requête relative au terminal requérant TR notamment à ses capacités en terme de périphérique (caméra, microphone, taille d’écran, etc.), en terme de mémoire, en terme de traitements (logiciels, plug-in…), etc. et/ou à l’utilisateur du terminal requérant (identité, localisation, âge, compétence(s), niveau dans la(les) compétence(s), etc.). Dans ce cas, le terminal requérant TR peut transmettre en retour ou en réponse un deuxième message mssg2 comportant notamment une ou des réponses aux requêtes du premier message mssg1. L’échange peut se poursuivre par des messages supplémentaires entre le terminal participant TPi et le terminal requérant TR. Notamment, l’échange est clos notamment par l’acception ok_cmd par le terminal participant TP i échangeant avec le terminal requérant TR. En particulier, un des messages mssg provenant du terminal participant TPi comporte la commande d’acceptation ok_cmd . Dans ce dernier cas, le terminal requérant TR commande ok_cmd le déclenchement de son entrée dans la première session ENT_TRG en transmettant la commande d’acceptation contenue dans le premier message mssg1 vers le procédé d’accès SS 1X _ACC. Un mode de réalisation particulier du procédé d’administration d’accès SS 1X _ADM est un programme comprenant des instructions de code de programme pour l’exécution des étapes du procédé d’administration d’accès SS 1X _ADM lorsque ledit programme est exécuté par un processeur. Dans un mode de réalisation particulier de l’invention, l’invention concerne un programme comprenant des instructions de code de programme pour l’exécution des étapes du procédé d’accès à une première session de communication sécurisée et/ou du procédé de demande d’accès et/ou du procédé d’administration d’accès lorsque ledit programme est exécuté par un processeur. La figure 4 illustre un schéma simplifié d’un diagramme d’échanges dans une architecture de communication mettant en œuvre un procédé d’accès à une première session de communication sécurisée par un terminal requérant selon l’invention. Le mode de réalisation de la prévoit l’utilisation d’un serveur de communication SCOM mettant en œuvre un procédé d’accès SS1X_ACC selon l’invention, notamment un procédé d’accès SS1X_ACC tel qu’illustré par la et/ou un procédé de gestion d’accès SS1X_MNGT implémentant éventuellement le procédé d’accès SS1X_ACC. Le serveur de communication SCOM est ou comporte un dispositif de gestion distinct des terminaux participants TPn à la première session de communication sécurisée SS1X et du terminal de communication requérant TR. Une première session de communication sécurisée SS1X est établit par le serveur de communication SCOM (comme le montre la phase I de la ). Notamment, le procédé de gestion d’accès SS1X_MNGT mis en œuvre par le serveur de communication SCOM comporte l’établissement de la première session de communication sécurisée SS1X. Eventuellement, la première session de communication sécurisée SS1X est établit sur requête d’établissement de la première session ss1X_oreq provenant d’un terminal participant : le premier terminal participant TP1 dans le cas de la . Le premier terminal participant TP1 est notamment un terminal de communication administrateur de la première session, c’est-à-dire le terminal de communication ayant défini une liste des participants à la première session SS1X et/ou le(s) type(s) d’accès autorisé(s) pour au moins un des participants (un même type d’accès prédéfini pouvant être autorisé pour un ou plusieurs voire la totalité des participants). Le premier terminal TP1 ayant accès à la première session SS 1X peut préparer le travail envisagé dans la première session par exemple en y partageant des contenus c et/ou en y déposant un message d’accueil des autres participants. A tout instant de la première session SS1X, au moins un des terminaux participants TP i , {TP n } (distincts du premier terminal dans l’exemple de la figure 4) demande ss 1X _sreq l’accès sécurisé à la première session au serveur de communication SCOM. En particulier, le procédé de gestion d’accès SS1X_MNGT vérifie AUTH_V si le terminal participant en question TP i , {TP n } est autorisé à accéder à la première session SS1X préalablement à la fourniture de l’accès sécurisé SS1X_ACC à la première session SS1X au terminal participant TP i , {TP n } requérant cet accès sécurisé. Cette vérification d’autorisation AUTH_V comporte notamment au moins une parmi les étapes de vérification suivante : - vérifier LST_V si le terminal participant en question TP i , {TP n } est un terminal de la liste des participants et/ou un terminal à disposition d’un utilisateur de la liste des participants ; - vérifier CDA_V si le code d’accès fournit par le terminal participant en question TP i , {TP n } correspond à un code d’accès à la première session. Le serveur de communication SCOM fournit l’accès sécurisé à la première session SS1X terminal participant en question TPi, {TPn} (comme le montre la phase II de la ). Le premier terminal TP1 et les autres terminaux participants TPi, {TPn} ayant accès à la première session SS1X peuvent alors échanger entre eux et/ou partager des contenus suivant le type de la première session de communication : conférence téléphonique, et/ou conférence textuelle ou « chat room » en anglais, et/ou conférence audio, et/ou visioconférence, et/ou espace collaboratif avec notamment partage de document en lecture et/ou écriture. Durant cette première session SS1X, un terminal requérant TR peut, à tout instant, demander l’accès à la première session notamment au serveur de communication SCOM comme illustré par la . Pour cela, il émet un message de demande d’accès daccc_mssg éventuellement dans une requête d’accès acc_req. Cette émission d’un message de demande d’accès daccc_mssg par le terminal requérant est notamment une étape d’un procédé de demande d’accès SS1X_DACC (notamment tel qu’illustré par la ) mis en œuvre par le terminal requérant. Le serveur de communication SCOM recevant le message de demande d’accès daccc_mssg le transmet à au moins un terminal participant TP 1 , TP i , TP n . Eventuellement, la réception puis l’émission à destination d’un terminal participant TP 1 , TP i , TP n du message de demande d’accès daccc_mssg est une étape d’un procédé d’accès SS1X_ACC, notamment tel qu’illustré par la ,et/ou d’un procédé de gestion d’accès SS1X_MNGT (implémentant éventuellement des étapes d’un procédé d’accès SS1X_ACC) mis en œuvre par le serveur de communication SCOM. Suite à cette demande, au moins un terminal participant TPi peut émettre une acceptation ok_cmd de cette demande vers le serveur de communication SCOM. Eventuellement, l’émission d’une acceptation par le terminal participant TPi au serveur de communication SCOM est une étape d’un procédé d’administration d’accès SS1X_ADM, notamment tel qu’illustré par la . Dans ce cas, le serveur de communication SCOM commande un accès acc_cmd par le terminal requérant à la première session SS1X qui déclenche l’entrée du terminal requérant TR dans la première session SS1X (phase III illustrée par la ). Le premier terminal TP1, les autres terminaux participants TPi, {TPn} et le terminal requérant ayant accès à la première session SS1X peuvent alors échanger entre eux et/ou partager des contenus suivant le type de la première session de communication et/ou leur type d’accès. Préalablement à l’émission d’une acceptation ok_cmd par le terminal participant TP i , le terminal participant peut requérir un établissement ss 2 _req d’une deuxième session de communication entre le terminal participant TP i et le terminal requérant TR au serveur de communication SCOM. Le serveur de communication SCOM établit la deuxième session SS2. Ainsi, le terminal participant TP i et le terminal requérant TR peuvent échanger pour permettre notamment au terminal participant TPi et/ou à son utilisateur UPi de déterminer APV_DT si l’accès par le terminal requérant à la première session est approuvé ou non. Les échanges sont notamment des échanges de messages ss 2 _mssg 1 , ss 2 _mssg 2 … En particulier, la réception par le serveur de communication SCOM de l’acceptation ok_cmd ou le déclenchement par le serveur de communication SCOM de l’entrée du terminal requérant TR clôt ss 2 _stp la deuxième session. La illustre un schéma simplifié d’une architecture de communication comportant un dispositif de gestion d’accès à une première session de communication sécurisée par un terminal requérant selon l’invention. Le dispositif de gestion d’accès 31 est apte à gérer l’accès à une première session de communication sécurisée, dite première session, en cours entre des terminaux de communications participants 1 1 ..1n, 1i, dit terminaux participants, par un terminal de communication requérant 2, dit terminal requérant. Le dispositif de gestion d’accès 31 comporte - un contrôleur 312 apte à déclencher une entrée dans la première session en cours du terminal requérant 2 dès réception d’une acceptation ok_cmd d’un des terminaux participants 1 1 ..1n, 1i (le terminal 1i sur l’exemple illustré par la figure 5) suite à une transmission d’un message de demande d’accès dacc_mssg émis par le terminal requérant 2 à destination d’au moins un terminal participant de la première session 1 1 ..1n, 1i. L’architecture de communication illustrée par la comporte - plusieurs terminaux participants 1 1, 1 2 ...1n, 1i à la première session de communication sécurisée SS 1X via un réseau de communication 4, - un terminal de communication requérant 2 l’accès à la première session SS 1X, et - un dispositif de gestion d’accès 31. En particulier, le dispositif de gestion d’accès 31 est implémenté dans un serveur de communication, c’est-à-dire un dispositif apte à gérer au moins une session de communication via le réseau de communication 4. En particulier, le dispositif de gestion d’accès 31 est, ou comporte, ou est implémenté dans un dispositif de gestion d’une première session de communication sécurisée via le réseau de communication 4. Dans l’exemple de la , le dispositif de gestion d’accès implémente un dispositif de gestion d’une première session de communication sécurisée 310. En particulier, le dispositif de gestion d’accès 31 comporte une base de premières sessions sécurisées 313 dans laquelle sont enregistré des listes de participants en association avec des premières sessions de communication sécurisées. Eventuellement, sont en outre enregistrées dans la base de premières sessions sécurisées 313 des dates et/ou horaires prédéfinis de début et/ou de fin de premières sessions sécurisées en association avec une première session. En particulier, le dispositif de gestion d’accès 31 comporte un générateur 310 O apte à établir ss 1X _stb une première session de communication sécurisée SS 1X . Eventuellement, le générateur 310 O reçoit une requête d’établissement ss 1X _oreq d’un premier terminal participant 1 1 . Alors le générateur 310 O est apte à établir ss 1X _stb la première session de communication sécurisée SS 1X dès réception de la requête d’établissement ss 1X _oreq. En particulier, le dispositif de gestion d’accès 31 comporte un connecteur 310A apte à fournir un accès sécurisé ss1X_sacc à la première session de communication sécurisée SS1X à d’autres terminaux participants 12...1n, 1i sur requête d’accès sécurisé ss1X_sreq de ces terminaux participants 12...1n, 1i. Alors, au moins un des terminaux participants comporte notamment un générateur/émetteur de requête d’établissement de première session sécurisé (non illustré). C’est le cas, en particulier, du premier terminal participant 11 de la . Et, les terminaux participants comportant notamment un générateur/émetteur de requête d’accès à la première session sécurisée (non illustré). C’est le cas, en particulier, des autres terminaux participants 12...1n, 1i de la . En particulier, le dispositif de gestion 31 comporte en outre un relai de demande d’accès 311 apte à transmettre à au moins un des terminaux participants 1 2 ...1n, 1i un message de demande d’accès dacc_mssg reçu d’un terminal requérant 2. Notamment le relai comporte un récepteur (non illustré) de message de demande d’accès dacc_mssg et/ou de requête d’accès acc_req provenant du terminal requérant, la requête d’accès acc_req(dacc_mssg) comportant le message de demande d’accès. Eventuellement, le relai comporte un émetteur (non illustré) de message de demande d’accès dacc_mssg à destination d’au moins un des terminaux participants 1 2 ...1n, 1i via la première session SS 1X ou en dehors, par communication synchrone, asynchrone ou diffusion. Le relai comporte aussi, notamment, un extracteur (non illustré) de message d’une requête apte à extraire un message de demande d’accès dacc_mssg d’une requête d’accès acc_req . L’extracteur est implémenté entre le récepteur de requête et l’émetteur de message de demande d’accès pour fournir à l’émetteur le message de demande d’accès extrait de la requête d’accès reçue. La illustre aussi un terminal de communication requérant 2, dit terminal requérant, apte à demander un accès à une première session de communication sécurisée SS 1X , dite première session, en cours entre des terminaux de communications participants 1 1, 1 2 ...1n, 1i, dit terminaux participants, par le terminal de communication requérant 2, dit terminal requérant. Le terminal requérant 2 comporte - un connecteur 22 apte à entrer le terminal requérant 2 dans la première session en cours SS 1X , le connecteur 22 étant déclenché acc_cmd dès réception d’une acceptation ok_cmd d’un des terminaux participants 1i suite à une transmission d’un message de demande d’accès dacc_mssg émis par le terminal requérant 2 à destination d’au moins un terminal participant de la première session 1 1, 1 2 ...1n, 1i. En particulier, le terminal requérant 2 comporte - un générateur 21 d’un message de demande d’accès dacc_mssg apte à être émis par le terminal requérant 2 à destination d’au moins un terminal participant de la première session 1 1, 1 2 ...1n, 1i. Eventuellement, le générateur 21 est apte à générer une requête d’accès acc_req comportant le de demande d’accès dacc_mssg . Le générateur 21 génère un signal d’accès acc_sg tel que le message de demande d’accès dacc_mssg ou la requête d’accès acc_req suite à une action dact de l’utilisateur requérant UR. En particulier, le terminal requérant 2 comporte au moins une interface homme-machine de sortie, dite interface de sortie, ou moyen de reproduction 24, tel qu’un écran, au moins un haut-parleur… et/ou au moins une interface homme-machine d’entrée ou de saisie (non illustrée), dite interface d’entrée, tel qu’un clavier, une souris, un écran tactile, un microphone, une caméra… Dans le cas où le générateur 21 génère un signal d’accès acc_sg suite à une action dact de l’utilisateur requérant UR, le générateur 21 reçoit d’une interface d’entrée des données relatives à l’action dact relative à cette interface d’entrée de l’utilisateur requérant UR. Par exemple, l’utilisateur requérant actionne un bouton avertisseur (équivalent d’une sonnette d’entrée) sur cette interface d’entrée ou frappe l’écran tactile de manière semblable au frappement de la porte (« toc toc »)… La illustre également des terminaux de communication participants 1 1, 1 2 ...1n, 1i. Un terminal de communication participant 1 1, 1 2 ...1n, 1i, dit terminal participant, est un terminal de communication apte à accéder à une première session de communication sécurisée SS 1X dite première session, en cours entre des terminaux de communications participants1 1, 1 2 ...1n, 1i, dit terminaux participants. Un terminal participant 1 1, 1 2 ...1n, 1i comporte - un connecteur 12i (illustré dans la uniquement pour le terminal participant 1i) apte à établir la première session SS 1X entre le terminal participant 1i et au moins un autre terminal participant 1 1, 1 2 ...1n, - un validateur 16i (illustré dans la uniquement pour le terminal participant 1i) apte à accepter un accès ok_cmd à la première session SS 1X suite à une transmission d’un message de demande d’accès dacc_mssg émis par le terminal requérant 2 à destination d’au moins un terminal participant 1i de la première session, le validateur 16i déclenchant une entrée acc_cmd dans la première session SS 1X en cours du terminal requérant 2. En particulier, le terminal participant 1i comporte un récepteur 11i d’un message de demande d’accès dacc_mssg à la première session SS1X provenant du terminal requérant 2. En particulier, le terminal participant 1i comporte au moins une interface homme-machine de sortie, dite interface de sortie, ou moyen de reproduction 14i, tel qu’un écran, au moins un haut-parleur… et/ou au moins une interface homme-machine d’entrée ou de saisie (non illustrée), dite interface d’entrée, tel qu’un clavier, une souris, un écran tactile, un microphone, une caméra… Le récepteur 11i fournit éventuellement le message de demande d’accès dacc_mssg à l’interface de sortie 14i de tel sorte que le message de demande d’accès dacc_mssg puisse être perçu (lu, entendu…) par l’utilisateur participant UPi du terminal participant TPi. En particulier, le validateur 16i reçoit, directement ou via une interface d’entrée (non illustrée) du terminal participant TPi, une action d’acceptation ok_act de l’utilisateur participant UPi en réponse notamment au message de demande d’accès dacc_mssg fournit à l’utilisateur participant UPi par l’interface de sortie 14i. En particulier, le terminal participant 1i comporte - un connecteur 130i apte à établir une deuxième session SS 2 de communication synchrone avec le terminal requérant 2 préalablement à l’acceptation ok_cmd par le validateur 16i. En particulier, le terminal participant 1i comporte un générateur 15i de requête d’établissement d’une deuxième session ss 2 _req. Le générateur 15i émet la requête d’établissement d’une deuxième session ss 2 _req à destination d’un dispositif de gestion de deuxième session 32 notamment implémenté dans un serveur de communication 3. Ainsi, le dispositif de gestion de première session de communication sécurisée 31 et le dispositif de gestion de deuxième session 32 peuvent, par exemple, être implémentée dans un serveur de communication 3. En particulier, le dispositif de gestion d’accès 32 comporte un générateur 320 apte à établir ss 2 _stb une deuxième session de communication SS 2 entre le terminal requérant 2 et le terminal participant 1i. En particulier, le terminal participant 1i et le terminal requérant 2 comportent chacun un dispositif de communication, respectivement 13i, 23, via la deuxième session SS 2 . Les dispositifs de communication 13i, 23 comportent des connecteurs 130i, 230 à la deuxième session SS 2 , et éventuellement des émetteurs 131i, 231 et/ou des récepteurs 132i, 232 par exemple de messages mssg 1 , mssg 2 … qui sont transmis via la deuxième session SS2 sous les noms de ss 2 _mssg 1 , ss 2 _mssg 2 … En particulier, le générateur 15i de requête d’établissement de deuxième session SS 2 active xtrg le dispositif de communication via la deuxième session 13i du terminal participant 1i. En particulier, les messages mssg 1 , mssg 2 … transmis via la deuxième session sont entrées via les interfaces d’entrée respectivement 131i, 231 et reproduits par les interfaces de sortie respectivement 132i, 232 à l’intention respectivement de l’utilisateur participant UPi et de l’utilisateur requérant UR. En particulier, le validateur 16i comporte un analyseur apte à décider en fonction du message de demande d’accès dacc_mssg , et/ou des messages échangés via la deuxième session ss 2 _mssg 1 , ss 2 _mssg 1 …, notamment ceux reçus du terminal requérant 2, et/ou d’une action ok_act de l’utilisateur participant UPi d’une acceptation d’accès du terminal requérant 2 à la première session SS 1X . Dans le cas où l’analyseur décide d’une acceptation, le validateur 16i émet une acceptation ok_cmd vers le dispositif de gestion de la première session 31, en particulier vers le contrôleur 312. Les figures 6a à 6e illustrent une utilisation de l’invention dans le cas où la première session sécurisée est un espace collaboratif comportant un espace d’échange textuel, une visioconférence et un espace de partage de document entre des utilisateurs participants UP 1 , UP 2 … UP n doté chacun d’au moins un terminal de communication participant pour accéder à cet espace collaboratif. La illustre un schéma simplifié d’utilisation d’un procédé de gestion d’accès dans un cas d’usage particulier de l’invention. La représente un écran du terminal participant d’un premier utilisateur participant UP1. L’écran comporte éventuellement plusieurs fenêtres dont une fenêtre associée à la première session SS 1X_ WD et éventuellement en sous-fenêtres: - une sous-fenêtre d’échange textuel SS 1X _xWD UP1 dans laquelle est reproduite les messages textuels échangés par les différents participants à la première session notamment dans l’ordre chronologique (dans l’exemple de la : les messages du premier utilisateur participant mssg 1,UP1 , mssg 4,UP1 , un message du deuxième utilisateur participant mssg 2,UP2 , un message d’un n ième utilisateur participant mssg 3,UPn …); et/ou - une sous-fenêtre de partage SS 1X _pWD, la sous-fenêtre de partage SS 1X _pWD comportant notamment elle-même une ou plusieurs sous-fenêtre, par exemple + une sous-fenêtre dans laquelle un flux Visio est reproduit, en l’occurrence le flux Visio du premier utilisateur participant UP 1 , et/ou + une sous-fenêtre dans laquelle un contenu est partagé, en l’occurrence un j ième contenu c j,UP1 du premier utilisateur participant UP 1 , + etc. La figure 6b illustre un schéma simplifié d’utilisation d’une éventuelle première étape d’un procédé de demande d’accès selon l’invention dans le cas d’usage de l’invention de la figure 6a. La représente un écran du terminal requérant d’un utilisateur requérant UR. L’utilisateur requérant a connaissance de la première session et, par exemple, saisie une adresse de la première session (tel qu’une adresse de type url dans son navigateur). Son écran affiche alors une première fenêtre d’entrée dans la première session SS1X_EWD1. Cette première fenêtre d’entrée de session SS 1X _EWD 1 comporte notamment une zone de saisie d’un identifiant id_cptz de l’utilisateur requérant UR et/ou d’un identifiant de son terminal et/ou une zone de saisie d’un code d’accès cd_cptz. L’utilisateur requérant UR n’ayant pas le code d’accès ou ne faisant pas partie de la liste des participants ne peut y saisir l’identifiant ID et/ou le code d’accès CD demandé(s) pour accéder de manière sécurisé à la première session SS 1X . La première fenêtre d’entrée de session SS 1X _EWD 1 comporte notamment un bouton virtuel d’avertissement kk_cptz sur lequel l’utilisateur requérant peut agir dact pour émettre un message de demande d’accès. Dans une variante non illustrée de l’invention, l’utilisateur requérant UR ayant préalablement été identifié comme n’appartenant pas à la liste des participants, la fenêtre d’entrée comporte uniquement un élément d’interaction tel que le bouton virtuel d’avertissement kk_cptz, ou une capture d’une gestuelle de frapper à une porte, ou une capture d’une interpellation orale « Bonjour ! Y-t-il quelqu’un ? », « Allo », ou etc. La illustre un schéma simplifié d’utilisation d’une éventuelle deuxième étape d’un procédé de demande d’accès selon l’invention dans le cas d’usage de l’invention de la . Eventuellement, suite à l’action de l’utilisateur requérant dact relativement à la première fenêtre d’entrée de session SS 1X _EWD 1 , une deuxième fenêtre d’entrée SS 1X _EWD 2 est reproduite permettant à l’utilisateur requérant UR de compléter le message de demande d’accès dacc_cpl . Notamment, l’utilisateur requérant peut ajouter son nom, la raison de sa demande d’accès, etc. Et, le message de demande d’accès dacc_mssg ainsi constitué par l’action dact de l’utilisateur et/ou un complément dacc_cpl est transmis du terminal requérant à au moins un terminal participant d’un des utilisateurs participants U1…UPn. La figure 6d illustre un schéma simplifié d’utilisation d’un procédé d’administration d’accès selon l’invention dans le cas d’usage de l’invention de la figure 6a. Au moins un des terminaux participants des utilisateurs participants UP1…UPn reçoit le message de demande d’accès et le reproduit dans une fenêtre de demande d’accès DACC_WD. La illustre l’écran du terminal participant de l’utilisateur participant i UPi. A cet instant, les échanges se sont poursuivi par rapport à ceux illustrés par la : de nouveaux messages sont reproduits : mssg5,UP2, mssg6,UP3, mssg7,UP2, mssg8,UPi, mssg9,UP1 dans la sous-fenêtre d’échange textuel SS1X_xWDUPi Si l’utilisateur participant i UPi établit une deuxième session avec le terminal requérant de l’utilisateur requérant UR, les échanges relatifs à cette deuxième session sont reproduits en lien avec la fenêtre de demande d’accès DACC_WD. Par exemple, si ces échanges sont vocaux, ils ne seront possible que si la fenêtre de demande d’accès DACC_WD est activée (par exemple par sélection par l’utilisateur participant i UPi). Dans un autre exemple, les échanges sont reproduit sous forme textuelle dans la fenêtre de demande d’accès DACC_WD au moins si ce sont des échanges textuels, voire également par conversion vocal en texte lorsqu’ils sont vocaux et/ou audio. Dans l’exemple de la , un flux Visio provenant du terminal requérant de l’utilisateur requérant SS2_VUR est reproduit. Ainsi, l’utilisateur requérant UR a l’impression de s’adresser à un utilisateur participant comme via un visiophone ou un interphone à l’entrée d’une salle sécurisée ou d’un domicile. La fenêtre de demande d’accès DACC_WD comporte au moins un élément d’interaction OK_BT permettant à l’utilisateur participant UPi d’accepter la demande d’accès de l’utilisateur requérant. Cet élément d’interaction est notamment un bouton physique ou virtuel d’acceptation, et/ou une caméra captant un hochement de tête, et/ou un microphone captant une acceptation orale, etc. La figure 6e illustre un schéma simplifié d’utilisation d’une éventuelle deuxième étape d’un procédé de demande d’accès selon l’invention dans le cas d’usage de l’invention de la figure 6a. La représente un écran du terminal requérant de l’utilisateur requérant UR. L’écran comporte éventuellement plusieurs fenêtres dont une fenêtre associée à la première session SS 1X_ WD et éventuellement en sous-fenêtres: - une sous-fenêtre d’échange textuel SS 1X _xWD UR dans laquelle est reproduite les messages textuels échangés par les différents participants à la première session notamment dans l’ordre chronologique (dans l’exemple de la : l’ensemble des messages des échanges démarrés la et poursuivis ensuite notamment à la dont un message du terminal requérant la première session SS 1X mssg 10,UPR , mssg 4,UP1 …); et/ou - une sous-fenêtre de partage SS 1X _pWD, la sous-fenêtre de partage SS 1X _pWD comportant notamment elle-même une ou plusieurs sous-fenêtre, par exemple + une sous-fenêtre dans laquelle un flux Visio est reproduit, en l’occurrence le flux Visio du premier utilisateur participant UP 1 , et/ou + une sous-fenêtre dans laquelle un contenu est partagé, en l’occurrence un j ième contenu c j,UP1 du premier utilisateur participant UP 1 , + etc. En utilisant l’invention, un utilisateur requérant qui connait la localisation de l’espace numérique partagé sécurisé (par exemple, l’url d’accès, le nom de la salle virtuelle, etc.) mais qui n’est pas en mesure de saisir ses identifiants et/ou mots de passe en raison d’un oubli, d’une perte, etc. a la possibilité de demander l’accès (notamment sous la forme d’un appel vocal, sonore, hépatique, visuel, etc.) en direction de cet espace qu’il cherche rejoindre via un canal sécurisé. Cet appel, visible depuis l’intérieur de cet espace permet à toute personne déjà présente d’accepter son entrée dans/ son accès à cet espace. L’invention est applicable à tout espace numérique partagé sécurisé dès lors que celui-ci nécessite une clef d’accès (peu importe sa forme). Ainsi, seule une personne aura besoin de sa clef pour accéder à cet espace avant de valider (par acceptation ok_cmd ) l’accès des autres participants un à un en les reconnaissant à l’aide de leur voix lorsque le message de demande d’accès comporte un message vocal, de leur visage lorsque le message de demande d’accès comporte une photo ou une vidéo de l’utilisateur requérant, leur matériel d’accès, une question secrète ou tout autre élément de reconnaissance. L'invention vise aussi un support. Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique ou encore un moyen d'enregistrement magnétique, par exemple une disquette ou un disque dur. D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau notamment de type Internet. Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. Dans une autre implémentation, l'invention est mise en œuvre au moyen de composants logiciels et/ou matériels. Dans cette optique le terme module peut correspondre aussi bien à un composant logiciel ou à un composant matériel. Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel apte à mettre en œuvre une fonction ou un ensemble de fonction selon la description ci-dessus. Un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en œuvre une fonction ou un ensemble de fonctions. Procédé d’accès à une première session de communication sécurisée, dite première session, en cours entre des terminaux de communications participants, dit terminaux participants, par un terminal de communication requérant, dit terminal requérant, le procédé d’accès comportant - déclencher une entrée dans la première session en cours du terminal requérant dès réception d’une acceptation d’un des terminaux participants suite à une transmission d’un message de demande d’accès émis par le terminal requérant à destination d’au moins un terminal participant de la première session. Procédé d’accès à une première session de communication sécurisée selon la revendication précédente, le procédé d’accès comportant - recevoir l’acceptation d’un terminal participant. Procédé d’accès à une première session de communication sécurisée selon l’une quelconque des revendications précédentes, le procédé d’accès comportant : - recevoir une requête d’accès d’un terminal requérant, la requête d’accès comportant le message de demande d’accès, et - émettre le message de demande d’accès à destination d’au moins un terminal participants de la première session. Procédé d’accès à une première session de communication sécurisée selon l’une quelconque des revendications précédentes, dans lequel émettre le message de demande d’accès à destination du au moins un terminal participant de la première session comporte une des étapes suivantes : - diffuser le message à destination de l’ensemble des terminaux participants préalablement à un accès du terminal requérant à la première session; - émettre le message par communication asynchrone à destination d’au moins un des terminaux participants; - émettre le message à destination d’au moins un terminal participant de la première session en dehors de la première session. Procédé d’accès à une première session de communication sécurisée selon l’une quelconque des revendications précédentes, le message de demande d’accès comportant au moins une données parmi les données suivantes : - une donnée sonore courte d’avertissement, - un identifiant associé au terminal requérant, - un identifiant associé à un terminal participant à la session de communication sécurisée, - un identifiant de la première session à laquelle le terminal requérant demande l’accès, - un message textuel, audio ou vidéo d’un utilisateur du terminal requérant. Procédé d’accès à une première session de communication sécurisée selon l’une quelconque des revendications précédentes, le procédé d’accès comportant - établir, préalablement au déclenchement de l’entrée dans la première session du terminal requérant, une deuxième session de communication synchrone entre le terminal requérant et un des terminaux participants à la première session sur requête d’établissement dudit un des terminaux participants suite à une transmission d’un message de demande d’accès émis par le terminal requérant à destination d’au moins un terminal participants de la session de communication. Procédé d’accès à une première session de communication sécurisée selon la revendication précédente, le procédé d’accès comportant - clore la deuxième session dès mise en œuvre par le procédé d’accès d’une étape parmi les suivantes : + la réception d’une acceptation par le terminal participant de la deuxième session, + le déclenchement de l’entrée dans la première session du terminal requérant. Procédé de demande d’accès à une première session de communication sécurisée, dite première session, en cours entre des terminaux de communications participants, dit terminaux participants, par un terminal de communication requérant, dit terminal requérant, le procédé de demande d’accès comportant - entrer dans la première session en cours du terminal requérant déclenchée dès réception d’une acceptation d’un des terminaux participants suite à une transmission d’un message de demande d’accès émis par le terminal requérant à destination d’au moins un terminal participant de la première session. Procédé d’administration d’accès à une première session de communication sécurisée, dite première session, en cours entre des terminaux de communications participants, dit terminaux participants, par un terminal de communication requérant, dit terminal requérant, le procédé d’administration d’accès comportant - émettre une acceptation d’un des terminaux participants suite à une transmission d’un message de demande d’accès émis par le terminal requérant à destination d’au moins un terminal participant de la première session, l’acceptation envoyée déclenchant, dès réception, une entrée dans la première session en cours du terminal requérant. Programme comprenant des instructions de code de programme pour l’exécution des étapes du procédé d’accès à une première session de communication sécurisée selon l’une quelconque des revendications 1 à 7 et/ou du procédé de demande d’accès selon la revendication 8 et/ou du procédé d’administration d’accès selon la revendication 9 lorsque ledit programme est exécuté par un processeur. Dispositif de gestion d’accès à une première session de communication sécurisée, dite première session, en cours entre des terminaux de communications participants, dit terminaux participants, par un terminal de communication requérant, dit terminal requérant, le dispositif de gestion d’accès comportant - un contrôleur apte à déclencher une entrée dans la première session en cours du terminal requérant dès réception d’une acceptation d’un des terminaux participants suite à une transmission d’un message de demande d’accès émis par le terminal requérant à destination d’au moins un terminal participant de la première session. Terminal de communication requérant, dit terminal requérant, apte à demander un accès à une première session de communication sécurisée, dite première session, en cours entre des terminaux de communications participants, dit terminaux participants, par un terminal de communication requérant, dit terminal requérant, le terminal requérant comportant - un connecteur apte à entrer le terminal requérant dans la première session en cours, le connecteur étant déclenché dès réception d’une acceptation d’un des terminaux participants suite à une transmission d’un message de demande d’accès émis par le terminal requérant à destination d’au moins un terminal participant de la première session. Terminal requérant selon la revendication précédente, le terminal requérant comportant - un générateur d’un message de demande d’accès apte à être émis par le terminal requérant à destination d’au moins un terminal participant de la première session. Terminal de communication participant, dit terminal participant, à une première session de communication sécurisée dite première session, en cours entre des terminaux de communications participants, dit terminaux participants, le terminal participant comportant - un connecteur apte à établir la première session entre le terminal participant et au moins un autre terminal participant, - un validateur apte à accepter un accès à la première session suite à une transmission d’un message de demande d’accès émis par le terminal requérant à destination d’au moins un terminal participant de la première session, le validateur déclenchant une entrée dans la première session en cours du terminal requérant. Terminal participant selon la revendication précédente, le terminal participant comportant - un connecteur apte à établir une deuxième session de communication synchrone avec le terminal requérant préalablement à l’acceptation par le validateur.