Brevet FR3005541A1 — publié le 20141114

PROCEDE DE GESTION D'UN SERVICE DE MESSAGERIE La présente invention concerne le domaine de la gestion de service de messagerie et notamment le domaine de la messagerie instantanée pour la prise de décision. Les interactions sociales (sur terminal fixe ou mobile) peuvent prendre différentes formes : courriel (ou email), SMS (« Short Messaging Service » en anglais), forum, blog, mur (ou « wall » en anglais), messagerie instantanée (ou « chat ») ou encore gazouillis (ou « tweet » en anglais). Le courriel peut permettre des communications libres et privées en mode asynchrone : l'auteur peut envoyer son message à tout moment et les destinataires peuvent en prendre connaissance et éventuellement y répondre à n'importe quel moment. La composition d'un courriel nécessite la connaissance de l'adresse (ou des adresses) de courriel des destinataires. Le SMS permet des communications libres et privées en mode asynchrone entre deux personnes dans le domaine de la téléphonie mobile. La composition d'un SMS nécessite la connaissance du numéro de téléphone mobile de son interlocuteur. Pour participer à un forum, les participants doivent s'inscrire à la plateforme de forum. Cette inscription permet notamment l'identification des participants et la modération des communications. Une fois leur inscription faite, les participants échangent des messages principalement asynchrones et souvent publics : un participant peut poster un message à n'importe quel moment, les autres participants pouvant y répondre quand ils le souhaitent, sans contrainte de délai. Le forum est un espace d'échange où différentes personnes peuvent se retrouver sur un thème donné. Le forum est le plus souvent repéré par une adresse web (URL) et des modalités d'accès peuvent en restreindre l'accès (autorisation accordée par le propriétaire ou un administrateur, authentification nécessaire, modération, etc.). Un blog s'apparente à un forum dans lequel le propriétaire est le principal participant, les tiers pouvant toutefois avoir l'autorisation de commenter des messages). Le contenu des blogs est le plus souvent public (librement accessible en lecture). Un « mur social » d'une personne s'apparente à un forum personnel. L'inscription d'un nouvel utilisateur à un mur est conditionnée par l'acceptation de cette personne comme « ami » par le propriétaire de ce mur. Le courriel, le SMS, le forum, le blog et le mur social sont principalement des services asynchrones. En effet, ces services ne requièrent pas la connexion simultanée des participants/intervenants pour fonctionner (ex. un courriel peut être envoyé à n'importe quel moment sans que tous les participants soient connectés). De plus, la connexion simultanée de plusieurs utilisateurs ne modifie pas le fonctionnement de ces services. Bien entendu, ces services tendent, grâce aux évolutions techniques et à l'évolution des usages, à réduire l'intervalle de temps minimal entre deux communications ou échanges. Lorsque ce temps est très faible (ex. de l'ordre de quelques secondes), il est possible de considérer que ces services sont « quasi-synchrones ». La messagerie instantanée (ou « chat » ci-après) est souvent considérée comme synchrone. En effet, la disponibilité et la connexion simultanée des interlocuteurs est le plus souvent nécessaire au fonctionnement de ce type de messagerie. Pour permettre une session de messagerie instantanée, il est le plus souvent nécessaire de connaitre l'identifiant de chaque participant. La messagerie instantanée restreint l'accès à la discussion aux seuls utilisateurs invités par l'initiateur du chat. Les gazouillis s'apparentent à un mur social accessible à tous ou encore à un chat ouvert au public. Cependant, de tels services ne sont pas exemptes de défauts. En effet, si ces modes de communications permettent d'échanger des points de vue ou des avis, ils ne permettent pas, de manière satisfaisante, de parvenir, rapidement, à une décision commune. Ainsi, afin de s'assurer du fait qu'un consensus a été trouvé, il est souvent nécessaire de reposer plusieurs fois la question pour valider les points de vue ou les ambigüités dans les réponses. Par exemple, si le courriel peut permettre d'exposer facilement une problématique à un groupe de personnes, chaque personne de ce groupe peut se positionner par rapport à cette problématique tout en étayant sa position. La grande liberté du courriel autorise les participants à digresser sans répondre à la problématique initiale, voire même d'exposer de nouvelles problématiques au groupe. L'initiateur de la problématique est souvent submergé de réponses et dans l'incapacité de synthétiser de manière correcte les échanges. De plus, en cas de changements multiple d'avis des différents interlocuteurs, une synthèse peut être difficile à réaliser. Si le forum peut permettre d'exposer une problématique aux membres de celui-ci, il n'est pas possible de solliciter des personnes extérieures à ce forum. La difficulté de la synthèse évoquée précédemment dans le cadre du courriel est également applicable dans le cadre du forum. Le blog étant un forum public, il n'est pas possible pour l'initiateur de la problématique de sélectionner, selon ses désirs, le groupe de personnes pouvant participer à la prise de décision. Il en est de même pour les gazouillis. Le mur est assez similaire au blog même si les participants potentiels sont plus restreints. Le chat étant un mode de communication synchrone, il est nécessaire que l'ensemble des participants soient simultanément connectées. Cette hypothèse est le plus souvent peu vérifiée au-delà de quelques personnes. La difficulté de la synthèse évoquée précédemment est également applicable dans le cadre du chat. Il existe également des possibilités de sondages en ligne (comme DoodleTM ou Google SurveyTM) permettant à un groupe de parvenir ensemble à une décision commune. Néanmoins, aucune interaction ou discussion des personnes sollicitées n'est possible : en effet, les participants sont contraints par les questions posées et le mode de réponse attendu. Il y a ainsi un besoin pour proposer une méthode de gestion d'un service de messagerie permettant une aide à la prise de décision rapide, interactive et efficace pour un groupe utilisant ce service. La présente invention vient donc améliorer la situation de l'état de la technique. A cet effet, la présente invention propose un procédé de gestion de service de messagerie entre plusieurs terminaux utilisateurs, mis en oeuvre par un serveur, dans lequel : - le serveur reçoit d'un terminal d'un premier utilisateur un message d'interrogation comportant au moins un destinataire et une requête de réponse du destinataire, et - le serveur transmet au terminal de ce destinataire des données d'interface utilisateur pour générer une interface utilisateur sur le terminal du destinataire. En particulier, le message d'interrogation comporte une information de type d'interrogation parmi une pluralité de types d'interrogation possibles, et, en fonction de cette information, le serveur transmet un jeu de données d'interface utilisateur adapté au type d'interrogation. Un « message d'interrogation » est un ensemble de données, par exemple une suite d'octets électroniques, représentatif pour le serveur d'une interrogation soulevé par le premier utilisateur (appelé notamment « initiateur ») et devant être partagé avec un certain nombre de destinataires. Avantageusement, « l'information de type d'interrogation » est une information permettant de déterminer le type de réponses attendues par le premier utilisateur. Par exemple, cette information peut être représentative d'une question ou d'une interrogation pour laquelle la réponse attendue est de type « oui » ou « non ». De plus, la réponse attendue peut également être une date ou une plage horaire. La réponse attendue peut être en outre un chiffre ou un nombre. Ainsi, le serveur peut déterminer le jeu de données d'interface utilisateur le plus adapté pour le type d'interrogation souhaité par le premier utilisateur. On appelle « le jeu de données d'interface utilisateur » un ensemble de données (par exemple sous format électronique) permettant de générer au niveau du terminal une interface utilisateur adaptée à la réponse attendue. Ce jeu de données peut comporter un simple identifiant permettant au terminal de déterminer l'interface utilisateur qui convient pour formuler le type de réponse attendue, l'interface utilisateur étant stockée auprès du terminal. Ce jeu de données peut également comporter des images ou des données structurées de taille importante. Ce jeu de données peut également comporter les réponses ou des intervalles de réponses attendues. Par ailleurs, le service de messagerie peut typiquement être un service de messagerie instantanée. Avantageusement, l'information de type d'interrogation peut être un identifiant de type d'interrogation. Ainsi, le serveur est en mesure, en fonction de cet identifiant, de déterminer le jeu de données d'interface à communiquer au terminal du destinataire. Par exemple, le serveur peut être apte à identifier dans sa mémoire les données graphiques d'interface associées à cet identifiant de type d'interrogation. En variante, le serveur peut réaliser une analyse « sémantique » du message d'interrogation et y identifier des mots-clés d'interrogation, nécessitant une réponse selon un type prédéterminé. Dans un mode de réalisation, chaque jeu de données d'interface utilisateur peut être prédéterminé pour structurer une réponse correspondante du terminal destinataire. Ainsi, en choisissant un jeu d'interface d'utilisateur correspondant à un type de réponse attendue, le serveur peut restreindre les réponses des destinataires pour faciliter une synthèse ultérieure. A titre d'illustration, - si le premier utilisateur (initiateur) pose la question/interrogation « quel est votre poids ? », le jeu d'interface choisi peut restreindre les choix des réponses parmi les chiffres et les nombres en présentant à l'utilisateur destinataire une interface utilisateur ne comprenant qu'un clavier numérique ; - si le premier utilisateur pose la question/interrogation « quand êtes-vous disponible ? », le jeu d'interface que choisit le serveur peut restreindre les choix des réponses parmi les dates en présentant à l'utilisateur destinataire une interface utilisateur ne comprenant qu'un calendrier ; - si le premier utilisateur pose la question/interrogation « que préférerez-vous mangez ce midi ? », le jeu d'interface que choisit le serveur peut restreindre les choix des réponses parmi une liste de spécialités culinaires en présentant à l'utilisateur destinataire une interface utilisateur ne comprenant qu'une liste contrainte de réponse possible dans ces spécialités ; - etc. Plus généralement, les types d'interrogation possibles peuvent comporter au moins : - une plage horaire à choisir par le destinataire, parmi une pluralité de plages, - une réponse à choisir par le destinataire, parmi un nombre limité de réponses possibles, - un contenu multimédia à choisir par le destinataire, parmi une pluralité de contenus (images, vidéos, musiques, ou autres), - une suite de caractères numériques à entrer par le destinataire, en réponse à une question attendant une valeur numérique, et - une suite de caractères alphanumériques à entrer par le destinataire, en réponse à une question attendant un texte libre. Ainsi, dans un mode de réalisation possible, les données d'interface utilisateur peuvent également comporter, pour une interrogation sur une plage horaire, des données pour un affichage sur le terminal du destinataire d'une pluralité de plages horaires et des données pour sélectionner auprès du terminal au moins une plage horaire parmi ladite pluralité de plages horaires affichées. Dans un mode de réalisation possible, les données d'interface utilisateur peuvent comporter, pour une interrogation sur un nombre limité de réponses possibles, un affichage sur le terminal du destinataire d'une pluralité de réponses sous formes de successions respectives de caractères alphanumériques et des données pour sélectionner auprès du terminal l'une au moins des successions de caractères alphanumériques. Dans un autre mode de réalisation, les données d'interface utilisateur peuvent comporter, pour une suite de caractères numériques à entrer, des données d'affichage sur le terminal du destinataire d'un pavé numérique et des données pour sélectionner auprès du terminal des chiffres du pavé. De même, les données d'interface utilisateur peuvent comporter, pour une suite de caractères alphanumériques à entrer, des données d'affichage, sur le terminal du destinataire, d'un clavier alphanumérique et des données pour sélectionner auprès du terminal des caractères du clavier. Dans un autre mode de réalisation, les données d'interface utilisateur peuvent comporter, pour une interrogation sur un nombre limité de contenus multimédias possibles, un affichage, sur le terminal du destinataire, d'une pluralité de contenus multimédias pour sélectionner auprès du terminal l'un au moins de ces contenus. Dans une réalisation, le procédé peut comporter en outre une étape de sélection, sur un terminal d'un utilisateur destinataire, entre une réponse adaptée au type d'interrogation et une réponse sous la forme d'un commentaire libre, non structuré. Dans une forme de réalisation possible, chaque jeu de données d'interface utilisateur peut comporter : - des données adaptées au type d'interrogation, et - des données adaptées à une réponse sous la forme d'un commentaire libre, non structuré. Les « données adaptées à une réponse sous la forme d'un commentaire libre » permettent à un utilisateur donné de se soustraire de la contrainte imposée par le format de la réponse attendue par le premier utilisateur afin d'interagir de manière plus dynamique avec les autres participants du service de messagerie. 3005 5 4 1 8 Le serveur peut également communiquer à un terminal d'un utilisateur donné une adresse unique pour utiliser le service de messagerie via le réseau Internet, l'adresse unique comportant un identifiant de service de messagerie, ledit identifiant permettant d'identifier l'utilisateur donné pendant une mise en oeuvre par le serveur 5 du service de messagerie auquel participe le terminal de l'utilisateur donné. L' « identifiant de service de messagerie » est un identifiant contenu par exemple dans une adresse de type URL (pour « Uniform Resource Locator» en anglais) ou Web. Cette caractéristique d'adresse unique est avantageuse en tant que telle, et ce 10 indépendamment d'un type de réponse attendu à un message d'interrogation. A ce titre, cette caractéristique précitée peut faire l'objet d'une protection séparée. Par exemple, pour l'adresse URL http://domain.tId/?id=56f7864e8975b, l'identifiant de service de messagerie peut être « 56f7864e8975b ». Dans cette hypothèse, cet identifiant peut permettre d'identifier l'utilisateur donné : 15 - si, par exemple, l'identifiant « 56f7864e8975b » est associé dans une base de données du serveur avec l'identité de l'utilisateur donné ; - si, par exemple, l'identifiant « 56f7864e8975b » est ou comporte une information chiffrée contenant l'identité de l'utilisateur donné. De plus, d'autres situations sont également possibles. Par exemple, pour l'adresse 20 URL http://domain.t1d/?id=56f7864e8975b&user=dest1@domainttld, l'identifiant de service de messagerie peut être « id=56f7864e8975b&user=dest1@domain111d». Ainsi, cet identifiant peut permettre de connaitre l'identité de l'utilisateur donné (définie par « dest1@domain1.tld »). 25 Le service de messagerie pouvant être un service de messagerie instantanée, l'identifiant de service de messagerie peut alors permettre d'identifier un espace de messagerie instantanée. On appelle « espace de messagerie instantanée » un « espace d'échange » (ou 3005 5 4 1 9 « chat room » en anglais). Cette notion peut couvrir un grand nombre de situations. L'espace d'échange peut notamment être un espace virtuel permettant à un nombre donné de participants d'échanger leurs avis de manière électronique. Par exemple, pour l'adresse URL http://domain.tId/?id=56f7864e8975b, l'identifiant 5 « 56f7864e8975b » peut permettre d'identifier un espace de messagerie instantanée : - si, par exemple, l'identifiant « 56f7864e8975b » est associé dans une base de données du serveur avec cet espace de messagerie instantanée ; - si, par exemple, l'identifiant « 56f7864e8975b » est ou comporte une 10 information chiffré contenant un identifiant représentatif de cet espace de messagerie instantanée. De plus, d'autres situations sont également possibles. Par exemple, pour l'adresse URL http://domain.tId/?id=56f7864e8975b&room=room1, l'identifiant de service de messagerie peut être « id=56f7864e8975b&room=room1». 15 Ainsi, cet identifiant peut permettre de connaitre l'espace de messagerie instantanée (définie par « room1 »). On comprendra alors qu'il est possible de combiner les deux réalisations ci-dessus pour déterminer à la fois l'espace de messagerie instantanée et l'utilisateur à 20 partir d'un ou plusieurs identifiants présents dans un lien URL tel que décrit ci- dessus. Dans un mode de réalisation, l'utilisateur donné peut être un destinataire, le 25 premier utilisateur transmettant alors au serveur, via son terminal, au moins une coordonnée de contact du terminal de l'utilisateur donné. De plus, l'adresse unique peut comporter un identifiant de contact correspondant à ladite coordonnée de contact. Une « coordonnée de contact » est une information permettant au serveur de contacter l'utilisateur donné. Cette coordonnée de contact peut être notamment : - un numéro de téléphone ; - une adresse de courriel ; - un identifiant associé dans une base de données du serveur à une coordonnée de contact précédemment listée (ex. un numéro client). Ainsi, si la coordonnée de contact est le numéro de téléphone 0123456789, l'identifiant de contact peut être 0123456789 ou un identifiant associé, dans une base de données du serveur, à ce numéro de téléphone. Dans un mode de réalisation particulier : - sur réception de la part du terminal du premier utilisateur d'une requête de service de messagerie avec au moins l'utilisateur donné comme participant au service de messagerie, la requête comportant une coordonnée de contact du terminal de l'utilisateur donné, le serveur peut initier le service de messagerie en générant un identifiant du service initié et allouer au terminal de l'utilisateur donné une adresse unique comportant un identifiant correspondant à sa coordonnée de contact, - le serveur peut transmettre l'adresse unique au terminal de l'utilisateur donné, et - le serveur peut recevoir sur ladite adresse unique une requête du terminal de l'utilisateur donné pour participer au service de messagerie initié. De plus, le serveur peut affecter à plusieurs utilisateurs participant à un même service de messagerie une adresse unique et propre chacune à un utilisateur donné. Ainsi, la sécurité du service de messagerie et l'authentification des utilisateurs sont assurés. 3005 541 11 Dans un mode de réalisation de l'invention : - sur réception de la part du terminal du premier utilisateur d'une requête de service de messagerie avec au moins un utilisateur donné comme participant au service de messagerie, la requête pouvant comporter une coordonnée de 5 contact d'un terminal de l'utilisateur donné, le serveur peut stocker en mémoire ladite coordonnée de contact, - le serveur peut mettre en oeuvre le service de messagerie en stockant un historique des messages échangés pendant le service de messagerie, en correspondance de la coordonnée de contact du terminal de l'utilisateur 10 donné, - sur réception d'une requête d'enregistrement au service de messagerie par l'utilisateur donné, le serveur peut stocker des données comportant au moins ladite coordonnée de contact du terminal de l'utilisateur, et peut associer auxdites données ledit historique. 15 La « requête d'enregistrement » peut comprendre : - la création d'un nouveau compte sur le service de messagerie à l'aide ou en association avec la coordonnée de contact ; ou - l'association ou l'enregistrement de la coordonnée de contact avec un compte préexistant. 20 Ainsi, il est possible de combiner ou de fusionner des historiques différents, mais associés à des coordonnées de contact distincts d'un même utilisateur. Cet aspect particulier est avantageux en tant que tel et peut faire l'objet d'une protection séparée. 25 Sur réception d'une nouvelle requête de service de messagerie avec au moins l'utilisateur donné comme participant au service, la requête pouvant comporter des données d'identification de l'utilisateur donné, le serveur peut identifier l'utilisateur donné et, pendant une nouvelle mise en oeuvre du service de messagerie, le serveur peut transmettre ledit historique au terminal de l'utilisateur donné. En outre, le serveur peut transmettre l'historique au terminal de l'utilisateur donné à la suite d'un ou plusieurs messages en cours pendant la nouvelle mise en oeuvre du service de messagerie. Le service de messagerie peut être identifié par une adresse de courriel. Un courriel pouvant comporter une adresse de destinataire correspondant à l'adresse de courriel du service peut être reçu par le serveur, et, sur réception dudit courriel par le serveur, le serveur peut mettre en oeuvre le service de messagerie entre des destinataires pour lesquels une adresse de courriel est présente dans ledit courriel. Ainsi, le transfert d'un échange de courriels faisant apparaitre les adresses de courriel des personnes ayant participé à l'échange dans l'historique des messages, ce procédé peut être utile afin d'inviter ces personnes au service de messagerie. Cet aspect de l'invention est avantageux en tant que tel et peut faire l'objet d'une protection séparée. Dans un mode de réalisation, le serveur peut transmettre au moins une partie du corps dudit courriel aux terminaux des utilisateurs participant au service de messagerie, pendant la mise en oeuvre du service. Ainsi, il est possible d'identifier dans le corps du courriel une phrase ou une expression apte à illustrer la problématique soulevée par l'initiateur de l'échange ou soulevé en cours d'échange. A titre d'illustration, cette phrase peut être le sujet du courriel initial. Un programme informatique, mettant en oeuvre tout ou partie du procédé décrit ci- avant, installé sur un équipement préexistant, est en lui-même avantageux. Ainsi, la présente invention vise également un programme informatique comportant des instructions pour la mise en oeuvre du procédé précédemment décrit, lorsque ce programme est exécuté par un processeur. Ce programme peut utiliser n'importe quel langage de programmation (par exemple, un langage objet ou autre), et être sous la forme d'un code source interprétable, d'un code partiellement compilé ou d'un code totalement compilé. Les figures 1 et 4a décrites en détails ci-après, peuvent former l'organigramme de l'algorithme général d'un tel programme informatique. Un serveur, par exemple un serveur de messagerie, peut être avantageux, en lui-même, dès lors qu'il permet de mettre en oeuvre le procédé précédemment décrit. Ainsi, la présente invention vise également un serveur, comportant des moyens (typiquement un processeur, une mémoire de travail et une ou plusieurs interfaces de communication via un réseau de télécommunication) pour la mise en oeuvre du procédé précédemment décrit. D'autres caractéristiques et avantages de l'invention apparaîtront encore à la lecture de la description qui va suivre. Celle-ci est purement illustrative et doit être lue en regard des dessins annexés sur lesquels : - la figure 1 illustre un organigramme décrivant une réalisation particulière de l'invention ; - la figure 2 illustre un exemple d'écran permettant la sélection d'un type d'interrogation dans un mode de réalisation selon l'invention ; - la figure 3 illustre un exemple d'écran pour la consultation du service de communication selon un mode de réalisation de l'invention ainsi qu'une interface de réponse ; - la figure 4a illustre un diagramme d'état décrivant une réalisation particulière d'un algorithme de décomposition (ou « parser » en anglais) pour la création automatique d'un message d'interrogation ; - la figure 4b illustre un exemple de courriel décomposé à l'aide de l'algorithme de décomposition précédent ; - la figure 5 représente un exemple de dispositif dans un mode de réalisation 3005 5 4 1 14 de l'invention. La figure 1 illustre un organigramme décrivant une réalisation particulière de l'invention. 5 Lors de la création d'un message d'interrogation (ou d'un « sondage interactif »), un serveur reçoit un message contenant la demande d'interrogation. Cette demande comprend : - une liste d'utilisateurs destinataire LIS _DES 101. Les destinataires peuvent être désignés à l'aide d'un identifiant de service connu du service ou encore 10 un identifiant externe au service tel qu'une adresse de courriel, un numéro de téléphone, ou tout autre identifiant unique. Cet identifiant peut être, par exemple, la coordonnée de contact définie ci-avant ; - un couple 102 comprenant un identifiant ID_TYP permettant de connaitre le type d'interrogation souhaité par l'initiateur du message ainsi que, le cas 15 échéant, certains éléments de réponses EL_RESP (notamment dans le cadre d'une interrogation à choix multiples). A titre purement d'illustration, l'identifiant ID_TYP peut être : - 1 pour une réponse attendue de type « oui/non », - 2 pour une réponse attendue de type « texte », 20 - 3 pour une réponse attendue de type « nombre », - 4 pour des réponses attendues dans une liste donnée (i.e. réponses de type QCM), la réponse souhaitée pouvant être unique ou multiple. - 5 pour une réponse attendue de type « date/heure » ; - un message texte permettant de qualifier l'interrogation 103, la 25 problématique, le sujet de discussion. Ce message peut être, par exemple, la question posée aux destinataires (comme « que voulez-vous manger ? », « vers quelle heure êtes-vous disponible ? », etc.). Ce message peut être un champ texte, mais peut également être un média comme une photo, un fichier audio ou une vidéo. Des combinaisons sont également possibles ; - de manière optionnelle, d'autres champs OTH (comme les réponses déjà recueillies de certains destinataires) 104. La figure 2 illustre un exemple d'écran 200 permettant la sélection, par l'initiateur, des éléments précédents 101, 102, 103 et 104. En effet, l'initiateur peut indiquer dans le champ 201 la liste des destinataires (i.e. futurs participants, 202, 203). Les identifiants des utilisateurs peuvent être issus d'une base de données externe comportant les utilisateurs du service de sondage interactif. Ces identifiants peuvent également être issus d'une base de données locale comme un annuaire d'un téléphone portable. De plus, l'initiateur peut indiquer dans le champ 204 le sujet de l'interrogation (ex. un phrase permettant d'illustrer ou de qualifier la problématique posée, comme « Voulez-vous aller manger ? » ou encore « Où voulez-vous partir en vacances ? »). Ce sujet de l'interrogation est souvent terminé par un point d'interrogation. Enfin, l'initiateur de l'interrogation peut indiquer le type de réponse attendue. A titre d'illustration, la sélection d'une icône peut permettre à l'utilisateur d'indiquer le 15 type de réponse attendue : - icône 205 pour indiquer que la réponse attendue est soit « oui » soit « non » ; - icône 206 pour indiquer que la réponse attendue est comprise dans une liste définie. Cette liste peut être établie par l'initiateur après la sélection de l'icône 20 206; - icône 207 pour indiquer que la réponse attendue est une date ou une heure ; - icône 208 pour indiquer que la réponse attendue est un texte libre ; - icône 209 pour indiquer que la réponse attendue est un chiffre ou un nombre ; 25 - icône 210 pour indiquer un autre choix (ex. une combinaison de réponses décrites précédemment). Une fois la demande d'interrogation reçue, le serveur peut créer un « espace d'échange » (ou « chat » en anglais) pour permettre aux différents participants de partager leurs opinions, à la manière d'une messagerie instantanée, et de répondre à l'interrogation posée, à la manière d'un sondage. Les différents destinataires peuvent être notifiés de la création de cet espace d'échange (étape 105 de la figure 1) sur le serveur. Ainsi, pour chaque destinataire, le procédé suivant est déroulé. Si l'identifiant de ce destinataire (contenu dans le message d'interrogation) est connu par le service de messagerie (i.e. s'il a un compte enregistré auprès du service de sondage interactif, test 106, sortie KNO), une notification peut lui être envoyée (étape 107), par exemple : - sur une adresse de courriel associée avec cet identifiant dans une base de données du serveur ; - sur un numéro de téléphone associé avec cet identifiant dans une base de données du serveur ; - via un système de notification intégré aux applications des téléphones mobiles (iPhone IO, Android IO, etc.) si l'utilisateur a installé une telle application. Dans les deux premiers cas, la notification peut contenir un lien hypertexte vers une page Web hébergeant l'« espace d'échange ». L'utilisateur peut s'identifier grâce à son compte (automatiquement grâce à l'information contenue dans le lien hypertexte ou encore manuellement) pour accéder à cette page. Ce lien hypertexte peut être du type : http://www.domain.t1d/?id=identifiant1&auth=721a9b52bfceac6e3b9b93cfa. Le paramètre « id » permet de communiquer l'identifiant de l'utilisateur. Le paramètre « auth » est un numéro unique permettant d'authentifier l'utilisateur ainsi que l'espace d'échange souhaité. A titre d'illustration, ce numéro peut être un hachage de type MD5 du mot de passe de l'utilisateur concaténé avec l'identifiant de l'espace d'échange. La notification peut également permettre de lancer une application installée sur un terminal mobile (étape 108). La consultation de l'espace d'échange se fera alors via cette application. Par exemple, un lien hypertexte de type « myapp:\\ » peut permettre de lancer l'application « myapp » sur un téléphone de type iPhone IO. Si l'identifiant du destinataire contenu dans le message n'est pas connu par le service de sondage interactif, une notification est adressée à cet identifiant (étape 109) via un moyen de communication adapté (ex. par courriel si l'identifiant est une adresse de courriel, par SMS si l'identifiant est un numéro de téléphone, etc.). Cette notification contient, par exemple, un lien hypertexte vers une page Web hébergeant l'espace d'échange (étape 111). Il est également possible que le destinataire ait en réalité un compte sur le service de communication alors même que l'identifiant présent dans la liste 101 n'est pas connu du service. Cette situation peut notamment arriver si le destinataire possède de multiples adresses de courriels, certaines n'ayant pas été déclarées auprès du service. Si le destinataire a en réalité un compte (test 110, sortie HAV_ACC), celui-ci peut le renseigner lors de l'accès au service. Dès lors, il est possible d'ajouter à ce compte une indication selon laquelle l'utilisateur de ce compte est autorisé à participer à l'espace d'échange qui vient d'être créé : cela revient, par exemple, à ajouter à ce compte l'identifiant précédemment associé à aucun compte. Cet ajout permet au destinataire (dès lors identifié avec son compte) de participer aux échanges dans cet espace d'échange au travers de son compte. Il est également possible de fusionner (étape 112) l'historique des lieux de discussion auxquels a participé l'identifiant nouvellement associé à ce compte et l'historique des lieux de discussion auxquels a participé l'utilisateur identifié (i.e. l'identifiant de son compte) : ainsi, l'utilisateur peut avoir accès à toutes les discussions auxquelles il a participé précédemment (même lorsqu'il n'était pas authentifié sur un compte). Si l'utilisateur à une application installée sur son terminal mobile (test 113, sortie HAV_APP), une consultation de l'espace d'échange peut être réalisée via l'application mobile (étape 108). Si l'utilisateur n'a pas d'application installée sur son terminal mobile (test 113, sortie NO_APP), une consultation Web peut être envisagée (ex. fourniture dans la notification d'une URL d'accès à l'espace d'échange). Si l'utilisateur n'a pas de compte (test 110, sortie KO), une consultation Web peut également être envisagée (étape 111). La consultation Web (étape 111) peut reposer sur la fourniture, dans la notification envoyée à l'utilisateur, d'un lien hypertexte (ou URL) contenant un ou plusieurs paramètres caractérisant l'espace d'échange et l'identifiant de l'utilisateur transmis. Pour des raisons de confidentialité, il est possible que ces données ne soient pas présentes en clair dans le lien (ex. opération de masquage, hachage ou « hash » en anglais). Ce lien hypertexte peut être du type : http://www.domain.t1d/?id=identifiant1&auth=721a9b52bfceac6e3b9b93cfa. Le paramètre « id » permet de communiquer l'identifiant de l'utilisateur. Le paramètre « auth » est un numéro unique permettant d'authentifier l'utilisateur ainsi que l'espace d'échange souhaité. A titre d'illustration, ce numéro peut être un hachage de type MD5 du mot de passe de l'utilisateur concaténé avec l'identifiant de l'espace d'échange. Une fois que l'utilisateur a accès à cet espace d'échange (via une application mobile ou via une application/page Web), il lui est possible de participer à la prise de décision ou d'échanger de manière libre. En fonction des paramétrages de l'espace d'échange, l'utilisateur peut : - participer aux discussions en soumettant (étape 115) aux autres participants un commentaire libre (sous forme d'un texte, d'une image, etc.). Ces commentaires sont considérés comme étant des données « non structurées » ou « libres » car elles n'ont pas de signification particulière pour la prise de décision (test 114, sortie UNSTR) ; - répondre à l'interrogation posée par l'initiateur de l'espace d'échange. Cette réponse est considérée comme étant une donnée « structurée » car elle a une signification particulière pour la prise de décision finale (test 114, sortie STRUC). Afin de répondre à l'interrogation posée de manière structurée, l'utilisateur peut sélectionner sa réponse dans une liste de réponses possibles (ex. réponse « oui/non », réponses à choix multiples, choix d'une date dans un calendrier) ou indiquer, explicitement, que sa réponse est structurée (ex. réponse sous forme de nombre ou de texte). Le choix entre une réponse « structurée » ou « non structurée » peut être réalisé au moyen d'un bouton autorisant la bascule d'un mode à l'autre. De plus, il est également possible que le serveur ou l'application détermine automatiquement si la réponse est « structurée » ou « non structurée ». A titre d'illustration, si une date est attendue (ex. « à quelle heure souhaitez-vous manger ? ») il est possible de reconnaitre automatiquement les réponses des utilisateurs en analysant si leur format (ex. structure sémantique, type de caractères, etc.) est compatible avec la structure des réponses attendues (ex. « vers 17h » peut être considéré comme structuré alors que « je n'ai pas faim » peut ne pas être considéré comme structuré) A titre d'exemple, une réponse structurée peut comporter un drapeau binaire (ou « flag » en anglais) afin d'indiquer cette structuration. Lors de la réception d'un message structuré (étape 116), le serveur est apte à l'enregistrer de manière spécifique (ex. enregistrement de la réponse dans une base de données en indiquant l'identifiant de l'utilisateur ayant répondu et le caractère structuré de cette réponse). De plus, si l'utilisateur a déjà répondu de manière structurée à l'interrogation courante, il est possible de remplacer ces réponses par la dernière réponse de l'utilisateur (étape 117). Par exemple, un drapeau binaire ou un champ particulier dans la base de données peut exister afin d'indiquer que ces anciennes réponses correspondent à des réponses « périmées » (i.e. ne devant plus être prise en compte pour la prise de décision). Par ailleurs, il n'est pas nécessaire de remplacer les anciennes réponses faites par l'utilisateur. Cela peut être notamment utile si plusieurs réponses sont attendues par utilisateurs. De plus, il est possible de ne pas remplacer les réponses des utilisateurs en fonction de critères complexes. Par exemple, seules les réponses soumises au-delà d'un certain délai sont remplacées (i.e. deviennent « obsolètes »). Il est également possible de conserver les N dernières réponses de l'utilisateur : les réponses au-delà de la Nè" réponse sont marquées comme étant obsolètes. Enfin, il est possible de réaliser une synthèse des réponses structurées (et non « périmées ») des utilisateurs. Cette synthèse peut comprendre la création de statistiques en lien avec ces réponses, comme : - un pourcentage d'occurrences des différentes réponses « non périmées » faites par les différents participants au sein de l'espace d'échange ; - une moyenne des réponses « non périmées » faites par les différents participants au sein de l'espace d'échange (pour les réponses de type « nombre ») ; - un variance des réponses faites par les différents participants au sein de l'espace d'échange (pour les réponses de type « nombre ») ; - le nombre de participants disponibles par créneaux horaires proposés (pour les réponses de type « date ») ; - etc. Lors de la soumission d'un commentaire « libre » ou « non structuré » (étape 115), ce commentaire est enregistré dans une base de données. Cette base de données peut comprendre un drapeau binaire ou un champ particulier afin d'indiquer que le commentaire enregistré est « non structuré ». Lors de l'affichage des messages et réponses des différents participants (étape 119), il est possible de prévoir que l'affichage des données structurées et des données non-structurées s'affichent visuellement de manière différente (ex. modification de la couleur ou des formes encadrant les différentes participations). Cet affichage différent permet une meilleure appréhension de la signification des messages et des réponses par les participants. Par ailleurs, le mode de réponse en « commentaire libre » présente de nombreux cas d'usage où les participants peuvent notamment créer ensemble une liste (liste de tâches à accomplir, liste de cadeaux, liste de prénoms pour un enfant, liste de personnes à inviter à une fête, ou autres). Dans ce cas, une seule personne peut être intéressée à contribuer à apporter plusieurs éléments distincts à cette liste. La réponse multiple consiste donc en une option possible. Typiquement, une réponse d'un deuxième participant ne vient pas effacer la réponse antérieure d'un premier participant, mais au contraire vient s'y ajouter. De plus, dans le cas de construction de listes, un deuxième participant peut vouloir marquer son accord avec un élément proposé par un premier participant (cette fonctionnalité pouvant s'exécuter par la fonction « j'aime » ou « +1 », connue de Facebook0 ou Google+0). Ainsi, la réponse en « commentaire libre » se prête bien à ce que les participants puissent proposer autant de réponses qu'ils le souhaitent et puissent voter pour les réponses des autres participants (avec un affichage simple de ces mentions dans une page d'écran de synthèse). Il est alors possible de transformer un commentaire en réponse en votant sur ce commentaire. Un élément proposé peut être aussi ajouté ou enlevé de la liste précitée, en votant pour ou contre, respectivement. La figure 3 illustre un exemple d'écran 300 pour la consultation du service de communication selon un mode de réalisation de l'invention ainsi qu'une interface de réponse. Cet écran 300 peut comprendre par exemple trois zones : - une zone 301 pour la visualisation des échanges associés à l'espace d'échange ; - une zone 302 permettant au participant de répondre à l'interrogation soulevée par l'initiateur ; - une zone 303 permettant la visualisation d'une synthèse des réponses des participants dans cet espace d'échange. Les différentes zones 301, 302 et 303 ne sont pas nécessairement affichées en même temps : un bouton (ou une zone sensible de l'écran) peut permettre l'affichage 5 ou le masquage d'une ou plusieurs zones sur demande. La zone 301 comprend un champ 304 affichant le sujet de l'interrogation (i.e. la question soulevée par l'initiateur ou la phrase illustrant/qualifiant l'interrogation). Ce champ reprend sensiblement les informations du champ 204 de la figure 2. En dessous du champ 304, les différents échanges ou réponses réalisés par les 10 participants sont présentées. Cette présentation est réalisée par ordre chronologique, les échanges ou les réponses les plus récentes étant situés en bas. Bien entendu, une autre présentation est possible (comme une présentation par ordre chronologique, les échanges ou les réponses les plus récentes étant situés en haut). 15 Pour chacun de ces échanges ou réponses, est indiqué : - le nom ou l'identité 306, 309, 312 ou 305 des participants accompagné éventuellement d'une image représentatif de celui-ci (ou « avatar » en anglais) ; - du contenu de l'échange ou de la réponse. Par exemple : 20 - les réponses « non périmées » (313 ou 306) des participants. Ces réponses sont représentées par des bulles possédant, éventuellement, une première couleur prédéterminée ; - les réponses « périmées » (307) des participants. Ces réponses sont représentées par des bulles barrées possédant, éventuellement, une 25 deuxième couleur prédéterminée ; - les commentaires libres ou simple échange 310. Ces réponses sont représentées dans un rectangle. - la date (308, 311, 314, 307) de l'échange ou de la réponse. Cette date est la date de la soumission de l'échange ou de la réponse. Néanmoins, dans le 30 cadre d'une réponse périmée, il peut être également indiqué la date et l'heure à laquelle cette réponse est devenue « périmée » (i.e. la date et l'heure de soumission d'une nouvelle réponse par ce même utilisateur). En l'espèce, pour l'utilisateur DEST1, la réponse 313 soumise le 25/04/13 à 11h45 vient remplacer la réponse soumise le 25/04/13 à 11h00. La zone 302 comprend une interface permettant de répondre simplement à l'interrogation soulevée par l'initiateur. A titre d'illustration, la zone 302 présente une interface de réponse permettant de choisir une réponse parmi deux réponses proposées par l'initiateur : « REP1 » 323 ou « REP2 » 321. D'autres interfaces graphiques sont possibles comme une liste déroulante. Ces interfaces peuvent dépendre du type de réponses attendues. L'utilisateur courant DEST2 ayant sélectionné la réponse REP2 comme dernière réponse (voir élément 306), le bouton 321 est mis en surbrillance. De plus, une flèche 322 peut également indiquer à l'utilisateur courant sa dernière sélection. La zone 303 comprend une synthèse des différentes réponses des participants. Par exemple, une synthèse sous forme de pourcentage des différentes réponses 331 et 333 peut être proposée. Une représentation graphique de ces pourcentages (sous forme de barres de progression 332 et 334) est également possible. La figure 4a illustre un diagramme d'état décrivant une réalisation particulière d'un algorithme de décomposition (ou « parser » en anglais) pour la création automatique d'un message d'interrogation. Il peut arriver des situations dans lesquelles différents interlocuteurs échangent sur un sujet par courriel électronique et lors de cet échange, il apparait qu'une problématique complexe nécessitant une prise de décision collective apparaisse. Dans une telle hypothèse, un utilisateur peut envoyer/transférer l'échange 401 de courriels à une adresse de courriel (comme parser@domain.tld ou parser_ouinon@domain.tld ou parser_date@domain.t1d, où domain.tld est le domaine DNS du service « parser »). Cet échange de courrier peut être formaté comme illustré par le courriel par la figure 4b : les différents échanges sont présentés chronologiquement, les plus anciens étant vers le bas : - l'échange 451 est plus récent ; - l'échange 452 a été envoyé avant l'échange 451 ; - l'échange 453 a été envoyé avant l'échange 452; - l'échange 454 a été envoyé avant l'échange 453. L'algorithme de décomposition 402 peut alors décomposer ce courriel transféré en identifiant les différents participants (étape 403), par exemple en analysant les signatures ou en extrayant les adresses emails dans les champs : - FROM 455 de l'avant dernier échange ; - TO 456 de l'avant dernier échange. En effet, le dernier échange n'est pas représentatif de la conversation car il ne sert qu'à transférer la conversation au service de décomposition. Ainsi, une liste des participants 404 peut être constituée. De plus, l'algorithme de décomposition 402 peut extraire (étape 405) le sujet de la problématique soulevée par la discussion par courriel. A titre d'illustration, cette problématique peut se trouver dans l'échange initial 454 dans la première phrase du corps du courriel (élément 458) ou dans le sujet (élément 457). Ainsi, une phrase 406 illustrant/qualifiant l'interrogation peut être identifiée. L'algorithme de décomposition 402 peut également extraire (étape 407) le type de réponse attendue. Cette identification peut être réalisée en fonction : - de l'adresse de courriel utilisée pour transférer l'échange de courriel 450. Par exemple, si l'adresse utilisée est parser_ouinon@domain.t1d, le type de réponse attendue est « oui » ou « non ». Si l'adresse utilisée est parser_date@domain.t1d, le type de réponse attendue est une réponse de type date, etc. - du contenu des différents échanges transmis à l'algorithme. Il est possible de rechercher dans le contenu des échanges des marqueurs syntaxiques, grammaticaux, ou encore lexicaux permettant d'identifier le type de réponse attendue. A titre d'illustration, il est possible d'identifier dans l'échange 450 une concentration importante de dates, comme les éléments 459, 461, 460, ou encore 462. Des outils d'analyse de langage naturel peuvent être utilisés. Ainsi, il est possible d'identifier le type de réponse attendue ID_TYP ainsi qu'une liste éventuelle de réponses possibles (élément 408). Bien entendu, l'utilisateur peut modifier certaines réponses possibles ou le type de réponse attendue si l'algorithme de reconnaissance utilisé n'a pas fonctionné de manière adéquate. Enfin, et de manière optionnelle, il est possible d'extraire les réponses des participants en fonction des réponses précédemment identifiées afin de « pré-remplir » l'espace d'échange. Par exemple : - le participant DEST1 a répondu « 4 au 10 février » (voir bloc 459) ; - le participant DEST2 n'a pas répondu ; - le participant DEST3 a répondu « 4 au 10 février » et « 18 au 24 février » (voir bloc 460 et 461) ; - le participant DEST4 a répondu « 18 au 24 février » (voir bloc 462). A l'aide des éléments 404, 406, 408 et 410, il est alors possible de dérouler le procédé décrit en figure 1 (en utilisant ces éléments en lieu et place des éléments 101, 102, 103 et 104). La figure 5 représente un exemple de dispositif dans un mode de réalisation de l'invention. Dans ce mode de réalisation, le dispositif comporte un ordinateur ou serveur 500, comprenant une mémoire 505 pour stocker des instructions permettant la mise en oeuvre du procédé, les données de mesures reçues, et des données temporaires pour réaliser les différentes étapes du procédé tel que décrit précédemment. L'ordinateur comporte en outre un circuit 504. Ce circuit peut être, par exemple : - un processeur apte à interpréter des instructions sous la forme de programme informatique, ou - une carte électronique dont les étapes du procédé de l'invention sont décrites dans le silicium, ou encore - une puce électronique programmable comme une puce FPGA (pour « Field-Programmable Gate Array » en anglais). Cet ordinateur comporte une interface d'entrée 503 pour la réception de données d'interrogations ou des données de réponses, et une interface de sortie 506 pour la fourniture aux utilisateurs des informations relative aux services de communication (i.e. messages des autres utilisateurs, synthèse des résultats, etc.). Cette interface de sortie peut être par exemple connectée à Internet. Enfin, l'ordinateur peut comporter, pour permettre une interaction aisée avec un administrateur, un écran 501 et un clavier 502. Par ailleurs, le schéma fonctionnel présenté sur la figure 1 est un exemple typique d'un programme dont certaines instructions peuvent être réalisées auprès du dispositif décrit. A ce titre, la figure 1 peut correspondre à l'organigramme de l'algorithme général d'un programme informatique au sens de l'invention. Bien entendu, la présente invention ne se limite pas aux formes de réalisation décrites ci-avant à titre d'exemples ; elle s'étend à d'autres variantes. D'autres réalisations sont possibles. Par exemple, la création de la synthèse indiquée en figure 1 (élément 118) peut être également effectuée coté « utilisateur » au regard des différentes réponses indiquées comme telles et transmises au dispositif utilisateur. REVENDICATIONS1. Procédé de gestion de service de messagerie entre plusieurs terminaux utilisateurs, mis en oeuvre par un serveur, dans lequel : - le serveur reçoit d'un terminal d'un premier utilisateur un message d'interrogation comportant au moins un destinataire et une requête de réponse du destinataire, et - le serveur transmet au terminal du au moins un destinataire des données d'interface utilisateur pour générer une interface utilisateur sur le terminal du destinataire, caractérisé en ce que le message d'interrogation comporte une information de type d'interrogation parmi une pluralité de types d'interrogation possibles, et en ce que, en fonction de ladite information, le serveur transmet un jeu de données d'interface utilisateur adapté au type d'interrogation. 2. Procédé selon la revendication 1, caractérisé en ce que le service de messagerie est un service de messagerie instantanée. 3. Procédé selon l'une des revendications 1 et 2, caractérisé en ce que l'information de type d'interrogation est un identifiant de type d'interrogation. 4. Procédé selon l'une des revendications précédentes, caractérisé en ce que chaque jeu de données d'interface utilisateur est prédéterminé pour structurer une réponse correspondante du terminal destinataire. 5. Procédé selon l'une des revendications précédentes, caractérisé en ce que les types d'interrogation possibles comportent au moins : - une plage horaire à choisir par le destinataire, parmi une pluralité de plages, - une réponse à choisir par le destinataire, parmi un nombre limité de réponses possibles,- un contenu multimédia à choisir par le destinataire, parmi une pluralité de contenus, - une suite de caractères numériques à entrer par le destinataire, en réponse à une question attendant une valeur numérique, et - une suite de caractères alphanumériques à entrer par le destinataire, en réponse à une question attendant un texte libre. 6. Procédé selon la revendication 5, caractérisé en ce que les données d'interface utilisateur comportent, pour une interrogation sur une plage horaire, des données pour un affichage sur le terminal du destinataire d'une pluralité de plages horaires et des données pour sélectionner auprès du terminal au moins une plage horaire parmi ladite pluralité de plages horaires affichées. 7. Procédé selon la revendication 5, caractérisé en ce que les données d'interface utilisateur comportent, pour une interrogation sur un nombre limité de réponses possibles, un affichage sur le terminal du destinataire d'une pluralité de réponses sous formes de successions respectives de caractères alphanumériques et des données pour sélectionner auprès du terminal l'une au moins des successions de caractères alphanumériques. 8. Procédé selon la revendication 5, caractérisé en ce que les données d'interface utilisateur comportent, pour une suite de caractères numériques à entrer, des données d'affichage sur le terminal du destinataire d'un pavé numérique et des données pour sélectionner auprès du terminal des chiffres du pavé. 9. Procédé selon la revendication 5, caractérisé en ce que les données d'interface utilisateur comportent, pour une interrogation sur un nombre limité de contenus multimédias possibles, un affichage, sur le terminal du destinataire, d'une pluralité de contenus multimédias pour sélectionner auprès du terminal l'un au moins desdits contenus. 10. Procédé selon l'une des revendications précédentes, caractérisé en ce que le procédé comporte en outre une étape de sélection, sur un terminal d'un utilisateur destinataire, entre une réponse adaptée au type d'interrogation et une réponse sous la forme d'un commentaire libre, non structuré. 11. Procédé selon l'une des revendications précédentes, caractérisé en ce que chaque jeu de données d'interface utilisateur comporte : - des données adaptées au type d'interrogation, et - des données adaptées à une réponse sous la forme d'un commentaire libre, non structuré. 12. Procédé selon l'une des revendications précédentes, caractérisé en ce que le serveur communique à un terminal d'un utilisateur donné une adresse unique pour utiliser le service de messagerie via le réseau Internet, l'adresse unique comportant un identifiant de service de messagerie, ledit identifiant permettant d'identifier l'utilisateur donné pendant une mise en oeuvre par le serveur du service de messagerie auquel participe le terminal de l'utilisateur donné. 13. Procédé selon la revendication 12, caractérisé en ce que, le service de messagerie étant un service de messagerie instantanée, l'identifiant de service de messagerie permet d'identifier un espace de messagerie instantanée. 14. Procédé selon l'une des revendications 12 et 13, caractérisé en ce que l'utilisateur donné est un destinataire, le premier utilisateur transmettant au serveur, via son terminal, au moins une coordonnée de contact du terminal de l'utilisateur donné, et dans lequel l'adresse unique comporte un identifiant de contact correspondant à ladite coordonnée de contact. 15. Procédé selon la revendication 14, caractérisé en ce que :- sur réception de la part du terminal du premier utilisateur d'une requête de service de messagerie avec au moins l'utilisateur donné comme participant au service de messagerie, la requête comportant une coordonnée de contact du terminal de l'utilisateur donné, le serveur initie le service de messagerie en générant un identifiant du service initié et alloue au terminal de l'utilisateur donné une adresse unique comportant un identifiant correspondant à sa coordonnée de contact, - le serveur transmet l'adresse unique au terminal de l'utilisateur donné, et - le serveur reçoit sur ladite adresse unique une requête du terminal de l'utilisateur donné pour participer au service de messagerie initié. 16. Procédé selon l'une des revendications 12 à 15, caractérisé en ce que le serveur affecte à plusieurs utilisateurs participant à un même service de messagerie une adresse unique et propre chacune à un utilisateur donné. 17. Procédé selon l'une des revendications précédentes, caractérisé en ce que : - sur réception de la part du terminal du premier utilisateur d'une requête de service de messagerie avec au moins un utilisateur donné comme participant au service de messagerie, la requête comportant une coordonnée de contact d'un terminal de l'utilisateur donné, le serveur stocke en mémoire ladite coordonnée de contact, - le serveur met en oeuvre le service de messagerie en stockant un historique des messages échangés pendant le service de messagerie, en correspondance de la coordonnée de contact du terminal de l'utilisateur donné, - sur réception d'une requête d'enregistrement au service de messagerie par l'utilisateur donné, le serveur stocke des données comportant au moins ladite coordonnée de contact du terminal de l'utilisateur, et associe auxdites données ledit historique.30 18. Procédé selon la revendication 17, caractérisé en ce que, sur réception d'une nouvelle requête de service de messagerie avec au moins l'utilisateur donné comme participant au service, la requête comportant des données d'identification de l'utilisateur donné, le serveur identifie l'utilisateur donné et, pendant une nouvelle mise en oeuvre du service de messagerie, le serveur transmet ledit historique au terminal de l'utilisateur donné. 19. Procédé selon la revendication 18, caractérisé en ce que le serveur transmet l'historique au terminal de l'utilisateur donné à la suite d'un ou plusieurs messages en cours pendant la nouvelle mise en oeuvre du service de messagerie. 20. Procédé selon l'une des revendications précédentes, caractérisé en ce que le service de messagerie est identifié par une adresse de courriel, et en ce qu'un courriel comportant une adresse de destinataire correspondant à l'adresse de courriel du service est reçu par le serveur, et, sur réception dudit courriel par le serveur, le serveur met en oeuvre le service de messagerie entre des destinataires pour lesquels une adresse de courriel est présente dans ledit courriel. 21. Procédé selon la revendication 20, caractérisé en ce que le serveur transmet au moins une partie du corps dudit courriel aux terminaux des utilisateurs participant au service de messagerie, pendant la mise en oeuvre du service. 22. Programme informatique, caractérisé en ce qu'il comporte des instructions pour la mise en oeuvre du procédé selon l'une des revendications précédentes, quand les instructions sont exécutées par un processeur. 23. Serveur, caractérisé en ce qu'il comporte des moyens pour la mise en oeuvre du procédé selon l'une des revendications 1 à 21.